ABAP Programming Standards Document Ver 3343411325851709

SAP R/3 Implementation
ABAP Programming Standards
Version: 3
TABLE OF CONTENTS
3.3.5.2.1 Menu Standards............................................................................................................................20 3.3.5.2.2 Tabstrips in SAP Release 4.X......................................................................................................21 6.5.1.9.1 Inner Join......................................................................................................................................66 6.5.1.9.2 Left Outer Join..............................................................................................................................66
156449847.doc Page
i
Version: 3 04 March 2003
1. Document Revision History

Date
29 January 2003 05 February 2003 04 March 2003
Version #
1 2 3
Requester
Vineet Bhatia Vineet Bhatia Vineet Bhatia
Change Description
Initial Version Change to CTS Naming Standards Prefix Addition of Standards for Report Header and Footer
156449847.doc Page
1
2. Introduction
This document is a compilation of possible ABAP programming and efficiency standards and will provide guidance in creating readable, maintainable code. It is intended for all developers in the SAP R/3 Implementation Project Diamond at Novartis, USA. The ABAP language is an event driven, top-down programming language. The ABAP processor controls the execution of an event. For example, the event AT SELECTION-SCREEN is executed when the user presses ENTER on the selection screen and the event START-OF-SELECTION is executed when the user executes the program. As the ABAP language incorporates many event keywords, it is necessary to implement in-house ABAP coding standards to create consistent and efficient maintainable code. As a standard, The Object Browser should be used for all development in the SAP system. A Source Code Change Process should be in place and adhered to prior to making changes to production ABAP programs and SAP source code. The reader is also referred to the section dealing with the Naming standards required by this project when dealing with the CTS (Correction and Transport System), this is contained within the Appendix of this document.
156449847.doc Page
2
3. General Programming Standards

3.1 Naming Conventions of ABAP Developments
All custom ABAP program names should follow the naming standards stated below. Each ABAP program should adhere to the ABAP internal naming conventions set forth in this document.
Standard naming conventions are in place and should be used at all times as detailed below for both tables, structures and ABAP etc:Z (1) Type (1) Proc1 (2) Req Num (2) Underscore (1) Brief Desc (23)
Z (character number 1): Custom ABAP programs need to begin with Z. Types (character number 2): This will be used to mention the type of ABAP program. Possible values are as follows: N : Include T : Table S : Structure R : Report C : Conversions for legacy data upload I : Interface M : Module Pool for Dialogs L : Layout Set/Form Proc1 (characters 3 and 4): This will be used to mention the main SAP module. FI : Financial Accounting CO: Controlling MM : Materials Management SD : Sales and Distribution PP: Production Planning PM: Plant Maintenance PS: Project Systems CS: Customer Service GN : General This will be derived from character 3 and 4 of the Functional specification. Req Num (character 5, 6): The Requirement Number will be the running serial number within a SAP Module. The SAP Module and the requirement number together will help as an index in collation all development objects such as Functional specification, Technical specification, Unit test Plan, ABAP development objects program/tables/etc. Underscore (character 7):
156449847.doc Page
3
The _ symbol will be defined as separator. Brief Desc (characters 8 - 30): Characters 8 30 can be used to briefly describe the functionality. This can also be used to distinguish several objects of the same type for a common worklist item, such as multiple structures used for the same dialog module. Examples: ZCMM19_material upload Conversion program for uploading material masters in materials management module. ZSMM23_01_Pur_history, ZSMM23_02_Pur_history 2 number structures developed for definition of field catalogs for ALV report program to show purchasing history. These structures are created for requirement number 23 within the main SAP Module in the main ABAP development worklist. Project Policy on Standard SAP changes To be determined, and included in this document later in the next version.
3.1.1
Internal data declaration:(see section 4)
3.1.2
Development Classes
Development classes group together development objects (e.g. programs, tables, function modules) which can be corrected and migrated together across instances. A development class can, for example, consist of a transaction or a group of related transactions along with programs, DDIC objects, menu painters, screen painters, lock objects, message classes, match codes, etc. All custom development should be assigned to a custom development class. Temporary objects may be assigned to class $TMP. Objects defined under the $TMP development class will not be migrated. Development classes follow the naming convention: Development Class ZDMC ZNCA ZNCC ZNCD ZNCE ZNCF ZNCK ZNCL ZNCM ZNCO ZNCP ZNCQ ZNCS Description Extension of Authorization Fields Novartis Consumer Health - AM - Assets Accounting Novartis Consumer Health - PPC - Production Planning & Contr Novartis Consumer Health - DASS Novartis Consumer Health - RIVA Novartis Consumer Health - FI - Financial Accounting Novartis Consumer Health - Cost Accounting Novartis Consumer Health - Inventory Management Novartis Consumer Health - MM - Materials Management Novartis Consumer Health - Workflow Novartis Consumer Health - Human Resources Novartis Consumer Health - QSS - Quality Assurance Novartis Consumer Health - Basis Version: 3 04 March 2003
4
156449847.doc Page
Development Class ZNCT ZNCV ZNCX ZNCZ
Description Novartis Consumer Health - Temp. Dev. (Conversion programs) Novartis Consumer Health - Sales & Distribution Novartis Consumer Health - Material Master Data Management Novartis Consumer Health - Cross application
3.1.3
Function Groups
Function groups allow for grouping related function modules and their components into a common area. Also, common variables may be shared by all function modules within a function group. Function groups should adhere to the following naming convention: Z_CCaxxxxxxxxxxxxxxxxxxxxx CC Country Code a - Application ID x - Open
3.1.4
Functions Modules
The SAP function modules are programs written in ABAP that form logical units in function groups. They can be shared by multiple ABAP programs and by other function modules. They are managed centrally in the function library. Function modules are grouped together using the function groups. Function modules may be defined to one and only one function group. SAP-supplied function groups should never be used to define new function modules. Function modules are similar to programs, the primary difference is they can be called using remote function calls from the operating system, can be called variably within and across programs, and are not typically built for reporting using selection criteria. Function module names can be a maximum of 30 characters. The following naming convention should be used: Z_CCa_xxxxxxxxxxxxxxxxxxxxxxxx CC Country Code a - Application ID x - Open (separate words with underscores) Remarks: All function modules should follow programming standards outlined in this document. There is no difference between programs and function modules when considering logic flows, syntax, unit testing, and variable naming.
3.1.5
Functions Modules Tables Declaration

Tables must be declared in GLOBAL DATA
156449847.doc Page
5
3.1.6
Layout Sets
SAPscript is a tool in R/3 for formatting text documents. The formatting rules are stored in R/3 objects called a Layout set. Layout sets can be used to format R/3 standards text or to format the output of ABAP reports. In particular, SAPscript can be used to format R/3 forms (Purchase Order/ GRN / Invoice / etc) when they are displayed on the screen or printed on a printer. A maximum of 16 characters can be used to name Layout Sets. The following naming convention should be used: ZCCaxxxxxxxxxxxx CC Country Code a - Application ID x - Open (use underscores to separate words and make as meaningful as possible).
3.1.7
Standard Text
These are standard pieces of text that can be slotted into a layout set and can contain pieces of standard text that can be called by any layout set. An example where standard text would be used would be to hold an address for an invoice approval slip. The address is contained within the standard text and can be called in the layout set to display the address when required. If the address changes, only the standard text needs to be modified for the changes to be effective immediately where it is called. The menu path for standard text is Tools/Word Processing/Standard Text or transaction SO10. The transport procedure is slightly different again in that you have to create a blank correction or repair, and attach the standard text to it. The correction/repair can then be released in the normal way.
3.1.8
Messages
The ability to display messages should also follow the principles of maintainability and be stored as individual messages. Message classes exist with messages already in them. There are already an extensive number of messages in each of the classes therefore, more than likely, you will find the message you require. You can also create a new message and store it in an appropriate class. Message Classes: Message Classes should adhere to the following naming convention: ZCCaxxxxxxxxxxxxxxxx CC Country Code a - Application ID x - Open INDIVIDUAL MESSAGES: Each message is given a sequential number and called by that number from the program, with the severity of the warning being decided each time the message is called.
156449847.doc Page
6
3.1.10
Lock Object
When creating a Lock Object, the file name must begin with EZ and can be a maximum of 16 characters long. EZCCa_tttttttttttt CC Country Code A Application ID t - primary table name (where multiple Lock Objects are required for the same primary table, assign a unique digit to the final position).
3.1.11
Transaction Codes
Each SAP transaction is identified by a unique transaction code which is listed in two SAP tables. Table TSTC contains the attributes of the transaction, while table TSTCT contains the short text associated with the transaction. Transaction codes should adhere to the following naming convention: ZCCaxx CC Country Code a Application ID x Open All reports should be executed from an area menu or from the reporting tree.
3.1.12
Using Logical File Names

1. Use Tcode FILE to create logical file names. For conversions the Logical File path is ZIDT.
156449847.doc Page
7
156449847.doc Page
8
2. Choose Logical file name definition, cross-client
156449847.doc Page
9
3. Create new entry for your program as following Logical file : <program name>_FILE1 Name : <short description> Physical file <file name><DATE> Data format ASC Application area FI Logical path ZIDT
156449847.doc Page
10
4. Use the following Func.Module in your program to get the physical file name. CALL FUNCTION 'FILE_GET_NAME' EXPORTING * CLIENT = SY-MANDT LOGICAL_FILENAME = <program_name>_FILE1 * OPERATING_SYSTEM = SY-OPSYS * PARAMETER_1 ='' * PARAMETER_2 ='' * PARAMETER_3 ='' * USE_PRESENTATION_SERVER = ' ' * WITH_FILE_EXTENSION = ' ' * USE_BUFFER ='' IMPORTING * EMERGENCY_FLAG = * FILE_FORMAT = FILE_NAME = loadfile EXCEPTIONS FILE_NOT_FOUND =1 OTHERS = 2. IF SY-SUBRC <> 0. * MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO * WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4. ENDIF. : : : : : START-OF-SELECTION. open dataset loadfile for output in text mode message ws_message.
3.2 Program Attributes

3.2.1 Title
Program attributes are set from the Attributes option on the initial ABAP editor screen. All program attributes for an ABAP are to be set as follows: Title The title should be a short concise description. This is the title which appears in the header section of a report when it is executed. Example: Create BDC Session for Transaction MM01 - Create Material Master
3.2.2
Type
The following types are available: Executable program for reports/interfaces
156449847.doc Page
11
Include programs. These are not directly executable and are included in other executable or non-executable programs. Module pool processing the flow logic of a dynpro. Function group. Subroutine Pools. Interface pools Class pools Blank
3.2.3
Status
SAP standard production program. Customer production program. System Program. Test Program. In SAP implementation, all programs are developed as Customer Production Programs.
3.2.4 3.2.5
Application
The ABAP Application should be set as mentioned in the functional specification name.
Authorization Group
Used to restrict access to users without a matching authorization group in their profile. Checks are performed before report execution, and before access to utility functions, report attributes, and the ABAP editor.
3.2.6
Logical Database
Assigns the logical database to be evaluated by the program. The workbench provides access to all logical database programs delivered by SAP.
3.2.7
From Application
Used in conjunction with the logical database field. The tables retrieved to access the particular logical database depend upon this entry.
156449847.doc Page
12
3.2.8
Screen
This is for report programs only. If a Screen is not specified the system will create a selection screen based on the logical database (if specified), the program parameters and select-options. To use an existing selection screen, enter the version in this field. Versions are connected to the programming of logical databases. Use the workbench to analyze logical database screen versions.
3.2.9
Editor Lock
To be set while a program is being created or modified. It allows only the user ID to set the flag to modify the program. This is to prevent alteration of a program while a programmer makes modifications to it. The Editor Lock should not be flagged on.
3.2.10
Fixed Point Arithmetic

If flagged, all calculations in the program are done using fixed point arithmetic. If the field is not checked, decimal places are only taken into consideration for output, not for calculations. All programs should have this flag checked.
3.2.11
Start via Variant

If checked, the program can only be executed via a variant.
3.3
3.3.1
Update programs, Comments, Formatting, Structure

Update programs
All transaction update programs are to offer the user the option of running the ABAP either in BDC Session or Call Transaction mode, unless a specific mode or a combination of them like Call Transaction for all records and BDC Session for failed records is specified in the Technical Requirement Specification. Ensure that a duplicate record existence check must be made in every data upload program
3.3.2
Comments
Internal commenting of an ABAP Program is essential for program maintenance and must be done for all programs. Informative comments should precede each part of source code and supplement what can be read from the code itself. This ABAP documentation must contain references to the initial specification and changes made subsequently. ABAP code is fairly self-documenting. However, it is prudent to provide future programmers with documentation of purpose, changes, enhancements, additions, and deletions. Explain the purpose, design, structure and any testing hints at the top of the program. Include any key decisions and assumptions made. Maintain a chronological history of modification notes; with the latest change being the last entry in the modification log. The documentation block should be placed at the top
156449847.doc Page
13
of the main program. An overall description of the program should be given at the top of the program and should have the following format: Example:
*--------------------------------------------------------------**************************************************************** * Confidential and Proprietary * Copyright ALSTOM, Australia * All Rights Reserved ***************************************************************** * * * Program Name: Zxxxxxxx Created by: ________ Created on: mm/dd/yyyy. Version: n.n *--------------------------------------------------------------* Modification Log: * Date Author Correction 29/05/01 Shivapriya DEV190001 *---------------------------------------------------------------
Description Added
If a modification is made to a tested ABAP program, an entry should be made in the modification log with the date, programmers initials, correction number, and brief description. Also, in the program code, a comment should be added to the effected lines indicating the correction number.
Example: IF SY-SUBRC NE 0. DevK9000045 Or Begin of DevK9000045 IF SY-SUBRC NE 0. EXIT. ENDIF. End of DevK9000045 ABAP code should be written modular rather than in line paragraph or form style. Complex and large coding structures should be commented by using a blocked off comment section preceding the structure. DevK9000045 DevK9000045 ENDIF. Exit.
Example: ****************************************** function module formats and posts MB01 - Post Goods Receipt ****************************************** FUNCTION POST_GOODS_RECEIPT * This * transaction * via CALL transaction CALL EXPORTING TCODE = W_TCODE
156449847.doc Page
14
IMPORTING DYNPROTAB = I_BDC.
3.3.3
3.3.3.1
Formatting
Forms
A large and complex string of coding statements should be broken up and placed in FORMs to provide easy readability and maintainability. FORMs are subroutines, which allow a programmer to define a process once in a program and call that routine from different places within the program. If a block of code is executed more than once, it should be placed in a subroutine. This makes the code more readable, requires less indentation, and is easier to debug since the debugger can jump through an entire subroutine via a PF key. Each FORM should serve only one function. FORMs should be placed at the end of the ABAP. All FORM paragraphs should generally be positioned in the order they are called. The function of the form should be described in the comment section. In the case of FORMs that use parameters, the parameters should also be described. FORM names should begin with F_. This will display all the program objects together when using Workbench. The rest of the FORM name should describe what the FORM is doing. Use the SAP default FORM comment box. To use this feature, code the PERFORM statement and then double click on the new form name. The FORM and ENDFORM statements and a default comment box will be generated at the end of the ABAP. If any parameters are passed in the PERFORM, comment lines allowing individual description of these parameters will be generated as well. With 3.0, the format parameters must be typed using TYPE or LIKE keywords. This is a new performance feature in 3.0 and also allows correcting typing errors before runtime. Pass input parameters as using parameters and output parameters as CHANGING parameters. The formal parameter does not occupy a memory of its own. If in doubt, pass the parameters by value. To avoid shadowing problems, always name your formal parameters different than the actual parameters. If Subroutines defined by FORM use/require global variables then define local fields for use locally within a subroutine and not use global fields
Example: *----------------------------------------* F_xxxxxxxxxxxxxx *-----------------------------------------* descriptive text here * * FORM Insert a
156449847.doc Page
15
*----------------------------------------* F_xxxxxxxxxxxxxx
FORM
Includes should be used to break down large programs into sections that can be maintained more easily and to create program sections that can be shared by several programs. INCLUDE statements should be commented individually by using the comment indication *. Code contained within the INCLUDE statement should adhere to programming standards and naming conventions.
Example: * Insert a descriptive text to describe the INCLUDE xxxxxxxx. * INCLUDE
For overall legibility, an ABAP Program should be neatly indented. The PRETTY PRINTER command (PP typed in the command line) can be used to indent each nested command structure by 2 positions with the settings indent and convert to Uppercase. Statements with multiple objects should be indented and aligned for clarity.
3.3.3.2
Text Elements
Each ABAP program should have associated text elements and constants from the source code placed within the Text Elements section of the ABAP Editor: Titles and Headings - The heading should always be completed in as much detail as possible. Use No Standard Page Heading phrase and code a custom header. Selection Texts - All system SELECT-OPTIONS and PARAMETERS are limited to 8 characters and as a consequence should always have selection texts set to improve user understanding. All Selection Texts should be in lower-case with the first word starting with a capital letter. Text-Symbols - All text symbols used for headers should have numbers H01, H02, H03.etc. As far as possible, use one text for one report header line. All Text Symbols used for messages should have numbers M01, M02, M03etc. Example: WRITE: / TEXT-001. The advantage of this method is ease of maintainability if TEXT-001 is coded several times in the program and needs to be changed. Formatting Commands Example:
Correct
WRITE: / 01 10 15 xxxxxxx1, xxxxxxx2, xxxxxxx3.
Incorrect
156449847.doc Page
16
WRITE: / 01
xxxxxxx1, 10
xxxxxxx2, 15 xxxxxxx3.
Use one line per object when defining multiple objects of the same entity. Describe those objects on that same line.
Example: Correct TABLES: T1, description T2, description T3. description
Incorrect
TABLES: T1, T2, T3. Each ABAP command consists of a sentence ending with a period. SAP allows multiple commands to be on one line; however, as a standard start each new command on a new line. This will allow for easier deleting, commenting, and debugging.
Example:
Correct
IF W_X = 3 AND W_Y = 2 AND W_Z = 1. PERFORM. ENDIF.
Incorrect
IF W_X = 3 AND W_Y =2 AND W_Z = 1 PERFORM. ENDIF.
3.3.4
ABAP Coding Structure

Data Definition Data elements must be grouped in logical groups. For example, constants declared together, variables grouped together, counters grouped together. For large groupings, put items in alphabetical order for supportability. Where clarification is needed, variable names must have in-line comments. Each variable must be declared on a separate line. For readability, different components of the names must be separated by underscores. Use Like when defining data elements whenever possible. This will ensure field width and other domain attributes are correct following upgrades. Coding Structure The standard structure for ABAP Report coding is: REPORT Header documentation TYPES OR TYPE-POOLS TABLES PARAMETERS
156449847.doc Page
17
SELECT-OPTIONS CONSTANTS DATA RANGES FIELD-GROUPS FIELDS FIELD-SYMBOLS * Event elements AT SELECTION-SCREEN ON PARAMETERS AT SELECTION-SCREEN ON BLOCK AT SELECTION-SCREEN START-OF-SELECTION GET END-OF-SELECTION TOP-OF-PAGE END-OF-PAGE Control elements INITIALIZATION
TOP-OF-PAGE DURING LINE-SELECTION AT LINE-SELECTION AT PFnn AT USER-COMMAND Subroutines FORM / ENDFORM
3.3.5
Module Program Structure

Module programs should only contain Include statements and any necessary comments. The module pool is also a means of linking all the associated screens, menus and function keys of the interface as a transaction.
3.3.5.1
Screen Flow Logic

Place the AT EXIT-COMMAND at the beginning of the flow logic in the PAI. Example: PROCESS AFTER INPUT. MODULE EXIT_1170 AT EXIT-COMMAND. MODULE PAI_1170. Use FIELD and CHAIN statements to keep fields in error open for correction.
Example: PROCESS AFTER INPUT. MODULE EXIT_1170 AT EXIT-COMMAND. CHAIN. FIELD BTCH1170-JOBNAME. FIELD BTCH1170-USERNAME. 156449847.doc Page
18
FIELD BTCH1170-FROM_DATE. FIELD BTCH1170-FROM_TIME. MODULE PAI_1170. ENDCHAIN. When using the AT CURSOR SELECTION, code it after the AT EXIT-COMMAND.
3.3.5.2
Screens and Screen Style Standards

When designing SCREENS, place fields on the screen in the sequence in which they are most frequently used. Align all labels and fields with neighboring lines and BOX any related screen fields together. Position the cursor to the most frequently used field on the initial screen display. For screen fields that require text input, place literal labels on the left and the data entry fields on the right of the label. For screen fields that use graphical elements, place the literal label to the right of the graphic element.
Apart for the general guidelines given above, the following list describes the common style and functionality that must be incorporated into each online transaction screen. This information supplements the SAP R/3 Mini Style Guide in SAP On-line documentation, which should also be adhered to. Screen literals Whilst all screens are being constructed in English, it is vital that the screens be produced using the field text associated with the data elements to ease translation to other languages. Parameters Maximum fields that have parameters defined should use the GET ID and SET ID flags in screen painter to allow the storage and retrieval of the parameter values. Keyboard shortcuts All functions must be accessible using a keyboard shortcut, by using the tab key to skip between fields, assigning a function key (or ctrl and a key) to common tasks, or by allowing access through the menus, which can be accessed using alt-<key lettter > (normal menu navigation ). See also the following section on menu definition) Tab strips Tab strips can be used effectively to show the user the different facets of an object. However, they should not be used to maintain different objects within the same screen, and specifically must not be used to switch between objects at different levels within a logical hierarchy. Toolbar buttons Where screens have a selection of filter fields, the Execute Button (F8) should be used to produce the list.
156449847.doc Page
19
Push buttons Except in exceptional circumstances, Buttons should be positioned on the application toolbar and identified by a suitable icon. Floating Tool tip text should be defined for all buttons to ease identification. Hyperlinks Where fields shown on a screen have a sensible link to another transaction (for example the maintenance transaction for the Service code field), then allow the user to double click on the field to invoke the associated transaction, passing the contents of the field to the new transaction. Back will return to the original transaction with all fields populated as they were before leaving it. Variants All screens containing lists should be capable of saving display variants that may be retrieved by the user in the normal way and be capable of allowing the user to define a default variant. All report selection must be capable of creating and retrieving report selection variants. Layout Transactions that will be used extensively must be quick and easy to use with a minimum of screen changes, button clicks or keystrokes. Screens should be laid out to present a clear, uncluttered view with data presented in logical groups within separate frames.
3.3.5.2.1Menu Standards A menu must be defined for each screen that follows the standard SAP style of menus including all of the appropriate menu elements. <object> <object> Other <object> Create Change Display Copy -------------Save -------------Print -------------Delete Edit Select all Deselect all Select block Choose -------------Cut Copy -------------Paste -------------Insert Goto See below ----------Back Extras See below Environment See below View See below Settings See below Utilities See below System Create sessions End session User profile Services Utilities List Workflow Links Private notes Own spool requests Own jobs Help Applica tion Help SAP Library Glossar y -------------Release notes -------------SAPNet -------------Feedbac k -------------Settings
156449847.doc Page
20
Exit
line Delete line Sort... -------------Cancel
Short message Status Log off
Goto is a mandatory element and should be used to invoke features within the current transaction that are mandatory (or are almost certainly used) to enter all the required data for the object being processed The Extras menu is not always required, but where appropriate is used for other features or actions related to the object being processed that are used less frequently for additional (non-mandatory) information. The Environment menu is not always required, but where appropriate is used for linking to other appropriate functions within the current application area. The View menu is not always required, but where appropriate is used to allow the user to switch between different views that are available for the current object (e.g single or multiline displays, or graphical or text) The Settings menu is not always required, but where appropriate is used to allow the user to set user-defined transaction parameters (e.g. the number of seconds between automatic screen refreshes) The Utilities menu is not always required, but where appropriate contains functions that allow not only the processing of the current object, but also cross-object processing such as copying information from one object to another.
3.3.5.2.2Tabstrips in SAP Release 4.X Tabstrips are new objects in SAP 4.X that provide an easy way to define different application components on the same screen and switch between them. Their intuitive design also makes them easier for end users. TabStrips enable the programmer to make it easier for users to navigate between components of complicated applications. Moreover, not only are TabStrips batch input compatible, but they can also be used whenever components or logical views of a single object occur on different screens. However, Tabstrips should not be used to represent different objects.
3.3.5.3
Locking and Unlocking in Dialog/Interface Programs

Lock Object Creation Related tables can be incorporated in a lock object instead of having lock objects per table. Applying the Lock
156449847.doc Page
21
Call the ENQUEUE function before the SELECT Statement for the transactional data to be changed/deleted. Example Call Function ENQUEUE_E<lock_object_name> EXPORTING _SCOPE =2 MODE = E <key_field1> = <value1> . . . EXCEPTIONS FOREIGN_LOCK =1 SYSTEM_FAILURE =2 . If SY-SUBRC = 1. Lock Error Handling procedure. Note- System Field SY-MSGV1 will have the user name by whom the table record is locked. ENDIF. SELECT statement System Variable SY-SUBRC is being checked for trapping exceptions. Only (E) Exclusive locks to be used until otherwise stated specifically. Use the standard setting _SCOPE = 2 for ENQUEUE function module
Locking Stages Numbering / Key External Internal External / Internal External / Internal Process Create Create Change / Delete Select and delete in a multirecords / multi-purpose transaction Lock / Get No: Start of Unit End of Unit Start of Unit After record is selected and delete button is pressed
Use the Function Module DEQUEUE_E<lock_object_name> to unlock the records locked as above before leaving the program. Note: Call Function DEQUEUE_ALL is not required as COMMIT WORK releases all the locks in the LUW (reference reading recommended on LUW). The following points should be considered while locking and unlocking. Locking should preferably be done at the record level for the required set of fields only.
156449847.doc Page
22
Locking should ideally be done outside a loop statement at a higher level for cases where there is a possibility of the no. of records being high, as it may lead to the problem of overflow in the lock table. The Dequeue processing should take place only after the Commit Work Statement. Records enqueued should also be dequeued when the program is terminated through Exit/Cancel etc. However this should not happen when you call another program because the call will come back to the calling program. There is no need to output a message when a lock is released. ENQUEUE_READ function can be used to check whether a lock has been obtained, however it should be avoided.
3.3.5.4
Database Update Techniques

The main update technique for bundling database changes in a single database LUW is to use CALL FUNCTION... IN UPDATE TASK. When the program encounters the COMMIT WORK statement, work process that is processing the current dialog step starts an asynchronous update work process. Inside the update task, no message handling required as SAP automatically does ROLLBACK in case of errors and sends an Express Document in the user SAP office mailbox. Where more than one update is carried out during Save the updates should all be carried out in a single UPDATE function call within save processing for better code organisation. A success message must be given just after all the validations before applying the records to the database are successfully completed. The program flow will be as follows : Code for Validations . Message type S Document successfully posted. Call Function <Function module> in UPDATE TASK
COMMIT WORK
3.3.5.5
GUI Status
For each GUI, use SAP defaults proposed by Menu Painter within Workbench for Menu. Create a title bar for each screen within a transaction that identifies what function and area the screen is to be used for. The standard set of PF Keys should use the SAP defaults proposed by Menu Painter from Workbench. Version: 3 04 March 2003
23
156449847.doc Page
On all initial entry screens, be sure the BACK, CANCEL, and EXIT functions are activated. The following functions should have a standard function code associated to them:
Function
ADD CHANGE DELETE DISPLAY SAVE BACK CANCEL EXIT CHOOSE FIRST PAGE PREVIOUS PAGE NEXT PAGE LAST PAGE PRINT
Function Code
ADD CHNG DELT DISP SAVE BACK CANC EXIT CHSE P-PP+ P++ PRNT E E
Function Type
3.3.5.6
Back, Exit and Cancel Navigation

For understanding of the above, allocate logical numbering of the screen before hand.
156449847.doc Page
24
Back Effect Jump target Exits object component Returns to previous level
Exit Exits task (application) Screen calling the task
Cancel Exits processing Screen calling task No the
Save option(dialogu e window) Checks Sequence of save/check Example title of dialogue window Diagnosis text in dialogue window Example text in dialogue window
Yes
Yes
Yes Checks first, save option later Back
Yes Save option first,checks later Exit G/L document
No --Cancel editing Unsaved data will be lost (e.g.) Unsaved data will be lost. --- blank line --Do you want to cancel the editing? (1st line is diagnosis text)
No diagnosis text
No diagnosis text
Do you want to post the held document? Or Do you want to post the held document 4712?
Do you want to post the held document? Or Do you want to post the held document 4712?
Pushbuttons in dialogue window (default answer underlined) Function module Action menu F-key
Yes, No, Cancel
Yes, No, Cancel
Yes, No
popup_to_confirm_step
popup_to_confirm_step
popup_to_co nfirm_loss_ of_ data Edit F12 (V12)
Goto F3 (V3)
<object> F15 (V15)
156449847.doc Page
25
3.3.5.7
Messages
Messages can be used to communicate with users. They are mostly used for error handling during processing of other user dialogs You send messages using the ABAP statement MESSAGE. The statement specifies the message class, number, and type of the message. All Message statements supplemented in code with comment that describes the text of the message. The message class and number are used to identify the message in table T100. The message type is one of A, E, I, S, W, or X, . Message processing depends on the message type specified in the MESSAGE statement, and the program context in which the statement occurs. Message Types A Termination The message appears in a dialog box, and the program terminates. When the user has confirmed the message, control returns to the next-highest area menu. Depending on the program context, an error dialog appears or the program terminates. The message appears in a dialog box. Once the user has confirmed the message, the program continues immediately after the MESSAGE statement. The program continues normally after the MESSAGE statement, and the message is displayed in the status bar of the next screen. Depending on the program context, an error dialog appears or the program terminates. No message is displayed, and the program terminates with a short dump. Program terminations with a short dump normally only occur when a runtime error occurs. Message type X allows you to force a program termination. The short dump contains the message ID.
E I
Error Information
Status
W X
Warning Exit
Guidelines for Message handling BACK / EXIT Title - Exit Processing Message text - Do you wish to save your data first?
DELETE Title Delete Processing Message text - Do you want to delete the records?
156449847.doc Page
26
TABLE LOCK Transaction aborted. Unable to Lock the Database Tables Object required is locked by another user (used for Abort message) (used for Error message)
DATABASE UPDATION & Record(s) successfully & (Eg. 1 Record successfully created) & Record(s) successfully created & Record(s) successfully updated & Record(s) successfully deleted & Record has already been deleted & Record(s) not deleted (Eg. Reason code is used in other tables. Record(s) not deleted) No changes made
DATABASE SELECTION No record(s) found matching the selection criteria TABLE CONTROL LINE SELECTION Position the cursor on a valid entry Select a record from the list Select a & record from the list & (Eg. Select a Journey record from the list to allocate) Multiple selections not allowed
MANDATORY FIELDS SAP message should come if a field is defined Mandatory (Eg. Make an entry in all required fields) Program specific Please enter & (eg. Please enter Service Group) Validation Checks SAP message should come wherever foreign key is defined through check table.
Program specific If SAP foreign key is disabled/does not exist then handle programmatically eg. Reason code does not exist Reason Code does not exist for Reason code type
Program Checks & exists for the & & & (eg. Service Group exists for the Plant, Reason Code exists for the Reason code type) 156449847.doc Page
27
Start time is later than end time From date is later than to date From date is in past From date is in future
Program specific Example Effective from date is overlapping for plant and daily schedule Effective from date for Daily schedule and Rota set to Date from
3.3.5.8
Validations and Data Volumes in Dialog Programs

Avoid redundant code for validation of screen inputs when the data dictionary is already handling it through check tables. Attention should be paid in terms of which all user-commands and transactions (Display etc.) do not require validations. In a dialog job it is necessary to distribute the validations across screens instead of cumulating at one place like SAVE etc. The programmer should be aware of the volume of data to be handled in the dialog program and its growth rate during the Technical specification stage. The algorithm in the Technical spec should be reviewed with the functional consultant and a peer.
3.3.5.9
Program call through a Function Module

Normally Set/Get parameters are used to pass data between calling & called program. But if a program is called by a number of programs, it becomes easier if the called program is coded as a function module. Parameter passing can then be done through the export/import interface of function module.
The following are the steps to achieve the above : Create a Function group for the function module. Go to the Object Editor (SE80) and within the created function group create the screens, includes, GUI status & title as required by the called program. The top include will be automatically created for the function group. Go the main program of the function group and add the include statements for includes like I01, O01, F01, etc. Write the processing logic for the screens just like any other dialog program .
156449847.doc Page
28
Finally within the Function group create the function module. Call to the initial screen of the transaction will be made by the function module. The PBO logic of the initial screen will be written in the function module before the call. The parameters which need to be passed to or returned by the calling program will be defined in the import/export parameters of the function call.
3.4
ALV Reports
Caution : ALV reports can not be run in background. In ALV reports use GUI TITLE for setting the title of the report and GUI STATUS for the menu bar. Always use data elements for ALV Column headings and Selection Screen block heading to avoid hard coding. For ALV Reports, always follow the following instruction for field catalog:
Y indicates presence of text in respective field label Output in ALV Medium text Report for field Short text of of Data Long text of catalog field Data Element Element Data Element Heading colddictxt Y Long Text Y Y Y As set (L, M, S ) Y Y Y Y Set R - Heading Y Y As set (L, M, S ) Print Preview of ALV report Long Text Short Heading Medium
Always use dictionary structure(s) as per output requirement of ALV report. This will provide a clean code. Structure description should say to be used only for the specified program. Only a maximum of 9 columns can be sorted in an ALV Report. Column heading of ALV report comes from the field label of data element. The following are four types of field labels associated with a data element Short, Medium, Long and Heading
The following rules apply for determining which text will be selected as field label. If Heading exists then default column heading will be Heading text of the field label.
156449847.doc Page
29
If Heading doesnt exist then default column heading will be Short text of the field label . If Heading and short both do not exist then default column heading will be Medium text of field label . If nothing else exists Long will be used.
3.5
Core Modifications
Prior to making SAP source code modifications, a Source Code Change Process must be in place and requirements should be approved. As a standard, only SAP authorized repairs should be allowed to the SAP code. When making modifications to SAP core programs, it is very important to document the changes made within the program. Within the comments section at the beginning of the program, include the following as part of a modification log: Repair number of the modification (system assigned) Name/initials of person making the modification Date Description of the modification
Example: **************************************************** Program xxxxxxxx *Description: *--------------------------------------------------* *Repair No. Date Author Description * ../../.. ***************************************************
Within the body of the program, comment every addition of code or change in code. Include in the comments the repair number, initials, date, and description of add/change. No code should be deleted from any SAP core program. Lines of code that are no longer used should be commented out.
Example: **************************************************** *Repair number: MS1K900088 * Description: Add code to *************************************************** SELECT SINGLE * FROM LFA1 WHERE KUNNR EQ I_TAB-KUNNR. DEVK900088 IF SY-SUBRC
156449847.doc Page
30
NE 0. DEVK900088 DEVK900088 DEVK900088 Or Begin of DEVK900088 SELECT SINGLE * FROM LFA1 WHERE KUNNR EQ I_TAB-KUNNR. SY-SUBRC NE 0. ENDIF. End of DEVK900088
Exit. ENDIF.
IF Exit.
3.6
Creation of additional tabs in SAP Standard Programs with Tab-strips

The steps for creating additional tabs in SAP Standard Programs with tab-strips are as follows Execute Transaction code VFBS Create function codes Specify the program name (SE38) and the subroutine name. Call a function module in the subroutine. Call a screen in the function module. Create the screen and code in the function group of this function module.
3.7
Smart Forms
The SAP Smart Forms is used for creating and maintaining forms for mass printing. They replace the SAPscript forms, however SAPscript forms will also be supported by SAP in future. SAP Smart Forms allow you to execute simple modifications to the form and in the form logic by using simple graphical tools. The following points should be considered when creating or maintaining Smart Forms : A backup of the layout prepared through Smart Form should be kept in the system with the name y<formname>_bk<nn> (nn being the sequence no. of the backup). This is important as version management is not supported for these forms. The currency field to be printed using Smart Forms should be defined as a field of the same type in the global definitions.
156449847.doc Page
31
No hard coding should be done in include text and address window in Smart Forms.
156449847.doc Page
32
4. ABAP Internal Names

4.1 Data Types
All data types used by a program should be first defined to the ABAP Dictionary as a TYPE-GROUP. One or more TYPE-GROUPS can be used by the TYPE-POOLS statement. With release 3.0 there is a clear distinction between the data type and the data object: Data types are declared using the keyword TYPE. Data types are pure type descriptions. They do not require any storage space. A data type characterizes the technical properties of all data objects, which have this type. Data objects are concrete instances of data types. Each data object has a particular type and requires all appropriate storage space. User defined data types can be created using TYPES statement. They can be either elementary or structured. User defined data types allow you to create all application specific type universally. This structure can be defined centrally and thus made known to the ABAP programming environment.
4.2 Data Fields

SAP R/3 Requirements: ABAP variable names can be a maximum of 30 characters long for DATA fields SELECT-OPTIONS and PARAMETERS can be a maximum of 8 characters long.
Standards: All variables should be defined using the type declared in the TYPE pool. When custom variables have a corresponding SAP variable, use the name that reflects that particular SAP data element or field name. Do not use variable names containing -. as they can be confused with table fields. Underscores should be used to separate words contained in variable/constant names. In addition, make the names descriptive. For program readability and maintainability, remove defined fields, which are never referenced, and code, which can never be logically executed. Whenever possible, the LIKE parameter should be used to define work fields.
Position
1-2
Description
Variable Description
Values
C_ P_ S_
Meaning
For Constants For Parameters For Select-Options Version: 3 04 March 2003
156449847.doc Page
33
RB_ CB_ PB_ V_ T_ L_ X_ WA_ E_ CL_ CO_ GR_ CI_ R_ Fld_ Cnt_ Flg 3+ Freely Definable
For Radio buttons For Checkbox For pushbuttons For Global Variables For Internal Tables For Local Variable For Types/ Structures For Work Areas for Internal Tables (Also for Layouts in ALV) For Events For Classes For Container For Grid For Class Instance For Range For Field For Counters For Flags use abbreviations for clear and concise names.
4.3 Abbreviations
When defining Data Fields, use clear and understandable names. In cases where abbreviations are used, utilize an agreed upon set of standard abbreviations. It is important that abbreviations are used consistently in all names. To determine an abbreviation for words not listed below, strip out all vowels and insignificant characters. Names, which begin with a vowel, retain the vowel in the abbreviation. Add vowels back in when abbreviations for two different names are alike. Abbreviations will be based on English names.
Name Customer Cost Name Vendor Last First Middle Employee Identification Quantity Counter
Abbreviation Cus Cst Nm Vnd Lst Frst mdl Emp Id Qty Cnt
4.4 Standard Header and Footer

All programs that produce reports (ie/ Reports, Interfaces, Conversions) should use a Standard Header and Footer. The Standard Header should be as follows: Color: col_heading intensified on 156449847.doc Page
34
Company Name: Should be in upper case - Centered Report Description: Each word in Sentence Case - centered and aligned with Company name. A line at the end of the Header. Footer should comprise of a line at the end of the page.
pic00235.pcx
156449847.doc Page
35
5. ABAP DICTIONARY
When creating a custom table, carefully plan its design and structure. Define the table fields appropriately. Always place the key fields starting with MANDT (client) field at the front of the record layout. Use the SAP database administrator to help design the table and its attributes, index, and buffer settings.
5.1 Tables
When defining custom tables always place the key fields at the front of the record structure.
5.1.1
Transparent Tables
When creating custom tables, Transparent Tables should be used in most cases. A Transparent table is a table with system structure, which gives an identical structure inside SAP as outside. Therefore the table can be accessed by both internal and external applications. All updates to SAP Tables should be performed within SAP.
5.1.2
Views
For reporting purposes, use VIEW tables to effectively join related tables that are taking large amounts of time for data retrieval. A database View is not physically stored, but it is a table derived from multiple tables. Database Views allow fields from several tables to be accessed in one view. Generally, accessing a database view is faster then selecting tables individually. With Release 4.X views can be buffered in the same manner as tables.
5.1.3
Index
The purpose of an Index is to quicken the scanning process when searching for specific records in a table. An Index is a copy of a table reduced to particular sorted fields to enable faster access to needed data. Indexes may be developed when the required access to a database table is based on fields other than the primary key of the table. Only include fields in an index if they reduce the selected data significantly. As indexes are adjusted each time table contents are changed, create secondary indexes discerningly to minimize the impact on the system. When SELECTing data from a table, look at the structure of all of the available indexes and tailor the WHERE clause to take advantage of the most selective index. Use all fields in the WHERE clause in the same order for an index, as skipping one field disables the index. Place the most common columns at the beginning of an index. The most common columns are those where reports are selecting columns with no ranges Version: 3 04 March 2003
36
156449847.doc Page
the WHERE clause for these columns is an equal to expression. Rearrange columns of an index to match the selection criteria. For example, if a SELECT statement is written to include columns 1 and 2 with equal to expressions in the where clause and column 3 and 4 are selected with value ranges, then the index should be created with columns in the sequence of 1, 2, 3, 4. Place Columns toward the end of the index if they are either infrequently used in SELECTS or are part of reporting SELECTS that involve ranges of values. Be sure to order the columns in the WHERE clause of a SELECT in the same order as an index table. Indexes should be small (few fields). Some optimizers are able to combine two or more indexes to execute a query. This is not possible with wide indexes. Multiple indexes of one table should be disjoint (have few common fields), in order not to confuse the optimizer which index to use. Each index slows the inserts into the table down. Updates are only slowed down if indexed fields are updated. On the other hand, the indexes increase the efficiency of reads. These tradeoffs must be weighed against one another. In general, frequently updated tables should have only few indexes while frequently selected tables might have more. Remove unused indexes or ones that change due to report design changes.
Caution: The creation of an index can affect performance adversely. The most suitable index for the select criteria might not be the index chosen for use by the database optimizer. Creating Indexes should be done carefully and jointly with the SAP Database Administrator. Validate the use of table indexes by performing a SQL Trace.
1.2
Structures
Identify the fields that are used in constructing a screen in Dialog program Create Structures in the Data Dictionary. Add the fields that are required in the structure. You can copy the fields contained in a dictionary structures, table or views with Edit / Include / Insert / Copy components Maintain the foreign Keys of the Structure The reference field and reference table must be specified for components of type CURR (currency) and QUAN (quantity). Attach a Search Help to a structure field that can be used by all screen fields that refer to the structure field In ABAP programs you can access the fields directly with <Structure name><Field name>
156449847.doc Page
37
All screen and ALV Reports (for meeting the requirement of Field Catalog) should use Dictionary structures for screen fields instead of using table definitions or program variables
5.3
Data Elements
A data element defines the description for the field. The semantic information (description and field labels) is assigned to the data element along with any on-line documentation. If possible, use the standard SAP Data Elements such as BUKRS, BELNR etc. The data element is the functional name associated with a domain; e.g., one of the data elements associated with domain CHAR30 may be ADDRESS. Whenever ADDRESS is entered as a data element, the characteristics of the domain CHAR30 appear.
5.4
Domains
A domain describes the physical format of the data such as the type and length of the data. Fields referring to a domain (via the data elements assigned to them) assumed the data format defined by the domain.
5.5
Search Helps SAP Release 4.X (replaces matchcodes)

SEARCH HELPS are a new feature in 4.X. They are more powerful than input help created using matchcodes and help views. A SEARCH HELP is an object that describes the procedure for possible values help. The 4.X upgrade will automatically convert matchcodes and help views to search helps. (The existing matchcodes and help views will NOT be deleted.) A SEARCH HELP is an improved method of displaying allowable values for an input field which can return multiple values to the underlying screen. A search help exit is a function module with a standard interface called from each step in the help process. These should only be used in exceptional cases, as they make input help harder to maintain. Notes: For more information, there is a search help conversion program called RUTHVMIG.
5.6
Table Buffering
Database tables can be stored locally on each application server. Performance time may be improved because reading from the buffer avoids directly accessing the database. Within SAP, only POOLED and TRANSPARENT tables allow buffering. The decision to buffer a table should be made by the SAP Database Administrator.
156449847.doc Page
38
Considerations: Only buffer a table that has read-only accesses made against it and is referenced frequently. Only buffer those tables that contain the business and other transaction processing rules, that are setup during the implementation of the SAP R/3 system and are changed very infrequently. Tables that contain master and transaction data should not be buffered. Only buffer tables that are modifiable, if write access occurs infrequently. Changes to buffered tables get automatically logged in the database and are transferred to the application servers at regular intervals. If buffered tables are modified frequently, the additional processing needed may cancel any performance gains attained by buffering. Native SQL. These commands always bypass the buffer and access the database directly. If native SQL was to update a buffered table directly, the buffer status is not changed; this could result in inconsistencies between data in the buffer and the database.
5.7
Data Type Conversion

Understanding and using data type comparisons and conversions is very important in ABAP. Following is a list from SAP R/3 system that lists how external data types are mapped to the ABAP data types using standard domains.
External Data Type

ACCP CHAR n CLNT CUKY
ABAP Data Type

N(6) C(n) C(3) C(5)
Description
Posting period YYYYMM Character strings Client Currency key, referenced by CURR fields Currency field, stored as DEC Counter or amount field w/ comma & sign Date field (YYYYMMDD) stored as char(8) Floating point number, accurate to 8 bytes 1-byte integer 2-byte integer 4-byte integer Language key Uninterpreted sequence of bytes Long character string, requires preceding Version: 3 04 March 2003
CURR n, m, s P((n+2)/2) DECIMAL m DEC n, m, s DATS FLTP INT1 INT2 INT4 LANG LRAW LCHR 156449847.doc Page
39
P((n+2)/2) DECIMAL m D(8) F(8) I I I C(2) X(n) C(n)
External Data Type

NUMC n QUAN n, m, s RAW n TIMS UNIT VARC n n: no. of places
ABAP Data Type

INT2 field N(n) P((n+2)/2) DECIMAL m X(n) T(6) C(n) C(n) m: number of decimal places.
Description
Character field with only digits Quantity field, points to a unit field with format UNIT Long byte string needs preceding INT2 field Time field (hhmmss), stored as char(6) Unit key for QUAN fields Long character string, not supported from Release 3.0 s: sign flag
Considerations: When non-standard conversions are needed to display differently than SAPs internal format or vice-versa, create a Conversion Exit for the Domain. This should be done by creating two function modules in the same function group. one module to convert from display format to internal format. the other to convert from internal format to the external format.
Data types of P and I are treated the same on all SAP supported platforms. Note that floating points have an accuracy up to 15 decimal places on all platforms, and that the rounding behavior may change. SAP advises that when two floatingpoint numbers need to be tested for equality, that the difference is very small. Reports have been made that errors occur when a field having decimal places is compared to 0 because SAP interprets any number less than 0.5 as equal to 0. As a standard, create a constant: C_ZERO with the correct number of decimal places and use it for comparisons instead of hard coding the constant in the processing logic.
Example: DATA: C_ZERO
TYPE PDECIMALS 2
VALUE 0.00
Creating constants will also help with debugging and testing conditions. The debugger will allow the C_ZERO value to be changed to test various conditions easily. Use program RSANAL00 to execute conversions by an ABAP.
156449847.doc Page
40
6. ABAP CODING TECHNIQUES

6.1 INTERNAL TABLES
An Internal Table is a group of records created at runtime. It is recommended to define all internal tables using user-defined data types and without a header line. Example: TYPES: Begin of T_definition Driver like driverduty-driver, End of T_definition DATA: I_table TYPE STANDARD table of T_definition. Considerations: The initial size addition is similar to the OCCURS parameter in version 3.X. When the initial size is not known, it makes more sense to leave it to SAP to determine by specifying initial size 0.
6.1.1
Filling an Internal Table

Information regarding using select statements: select single should only be used if the entire key is known 2) select (fields) should be used if you are extracting less than 1/3 of the database fields or a maximum of 16 fields
6.1.1.1
Select Into
When an Internal Table needs to be created directly from one database table, use the SELECT INTO to fill the Internal Table. The contents of I_T001 will be replaced by the selected data so a REFRESH is not needed. Example: SELECT * FROM T001 INTO TABLE I_T001. If an Internal Table is to be created directly from database tables and the contents currently in the Internal Table need to be kept, add the APPENDING TABLE parameter. Example: SELECT SINGLE * FROM T001W APPENDING TABLE I_MARA WHERE WERKS = W_ WERKS. Considerations:
156449847.doc Page
41
This is only relevant for Internal Tables that are as wide or wider than the database table being SELECTed. It is always faster to use the INTO TABLE version of a SELECT statement than to use APPEND statements.
6.1.1.2
Append
Append adds a new entry to an Internal Table. The system does not check if a record with the same key exists. Considerations: As APPEND adds new entries to an Internal Table, duplicate entries may occur. If the internal table already contains the number of entries allocated by the system (Initial size 0 addition), the additional entries are rolled to the paging area, resulting in longer runtimes. When using Internal Tables with a header line, avoid unnecessary assignments to the header line. Use statements, which have an explicit work area.
Example:
More Efficient
APPEND W_TAB TO I_TAB.
Less Efficient
I_TAB = W_TAB. APPEND I_TAB Use the CLEAR command after the APPEND command to clear the contents of the internal table's header record. As of Release 3.0C, the addition LINES OF can be added to the APPEND statement. The statement is used to add a block of lines to an Internal Table. When appropriate, use APPEND with the block command instead of APPENDING single lines during a LOOP. The block command is faster and easier to read.
Example:
More Efficient
APPEND LINES OF I_TAB1 TO I_TAB2.
Less Efficient
LOOP AT I_TAB1. APPEND I_TAB1 TO I_TAB2 ENDLOOP.
6.1.1.3
Insert
Use INSERT to add single rows or blocks of rows to an Internal Table as a specific position.
156449847.doc Page
42
Example: INSERT I_TAB INDEX 6. Considerations: When a block of lines is to be inserted at a specific position, use the LINES OF parameter of the INSERT statement. INSERTing a block of lines is faster than INSERTing one row at a time during a LOOP. This example will insert rows 3 through 7 from I_TAB1 into I_TAB2 as rows 4, 5, 6, and line 4 from I_TAB2 will become line 7 after the INSERT.
Example:
INSERT LINES OF I_TAB1 FROM 3 TO 5 INTO I_TAB2 INDEX 4.
6.1.2
6.1.2.1
Retrieving from an Internal Table

Read Table
READ TABLE is used to read a single row from an Internal Table. READ TABLE I_TAB is used to read a Internal Table using the Internal Tables header line as the output area. READ TABLE I_TAB INTO WA is used to read an Internal Table and use the work area as the output area. Considerations: When reading a single record in an Internal Table, the READ TABLE WITH KEY.. is not a direct READ. Therefore, SORT the table on the key (to be used for equality) in ACSENDING ORDER beforehand and use READ TABLE WITH KEY.. BINARY SEARCH. The binary search will fail in case the table (key) is sorted in a DESCENDING order. When the BINARY SEARCH is used, the system starts the search in the middle of the table. It then checks the first half or second half depending if the key fields are bigger or smaller than the middle entry.
6.1.2.2
LOOP
LOOP WHERE is faster than LOOP/CHECK because LOOP WHERE evaluates the specified condition internally. Example:
More Efficient
*Key access with LOOP WHERE LOOP AT TAB WHERE K = KVAL. " ... ENDLOOP.
Less Efficient
156449847.doc Page
43
More Efficient
*Key access with LOOP/CHECK LOOP AT TAB. CHECK TAB-K = KVAL. " ... ENDLOOP. Make the comparison operators share a common type; as with any logical expression, the performance is better if the operands of a comparison share a common type. Performance can be further enhanced if the LOOP WHERE is combined with FROM i1 and/or TO i2.
6.1.2.3
Nested Loops
Performance in reading the internal tables can be enhanced by using the combination of Read table and Loop statements. Read table will locate the index of the record and loop statement can be used with the addition From. Caution: The nested loop table should be sorted on the basis of where clause fields. It has to be ensured that sorting a table on a particular field should not affect the program flow at a subsequent location in the program flow where a different sort is expected. Therefore, in such cases the internal table must be resorted as per fields expected.
Example:
More Efficient
Sort I_tab by f1. Read table I_tab with key f1 = w_f1. If sy-subrc = 0. w_index = sy-tabix. Endif. LOOP AT I_tab from w_index. If w_f1 <> I_tab-f1. Exit. Endif. Processing within loop ENDLOOP.
6.1.2.4
Events inside the LOOP

While using events like At start of, At end of, At first, At Last, On change of in side the loop, always transfer the header record into a work area. Because when control comes to At end of or At start of , all the character field of header line becomes star(*).
156449847.doc Page
44
Example
Correct Method
Loop at itab where . Wa_itab = itab. At end of plant. Endat. Endloop.
6.1.3
6.1.3.1
Modifying an Internal Table

Collect
The COLLECT statement scans the Internal Table for an entry where the default key matches that of the entry in the Work area / Internal Tables header record. If a match is found, the system sums any field of type F, P, I, N in that record; if no record exists the header record is inserted into the Internal Table. When adding data to SAP tables (as opposed to totaling numbers), use the APPEND statement instead of the COLLECT statement. This improves speed and avoids comparisons to existing data Considerations: When working with Internal Tables, recall that the COLLECT statement is very CPU intensive. When COLLECTing on an Internal Table with greater than 50 entries, use the following alternative code: .. READ TABLE I_TAB WITH KEY .. BINARY SEARCH. CASE SY-SUBRC. WHEN 0. I_TAB-AMT = I_TAB-AMT + W_NEW_AMT. MODIFY I_TAB INDEX SY-TABIX. WHEN 4. INSERT ITAB INDEX SY-TABIX. APPEND I_TAB. .. ENDCASE WHEN
8.
* For Internal Tables with less than 50 entries the COLLECT is acceptable.
156449847.doc Page
45
After the COLLECT statement has been executed, the index of the modified or new entry is written to the system field SY-TABIX. When you fill an internal table, do not use COLLECT in combination with any other table-filling statements (APPEND, INSERT, and/or MODIFY). If you mix COLLECT with the other statements, COLLECT cannot use its hash algorithm. In this case COLLECT resorts to a normal linear search, which is dramatically slower.
6.1.3.2
Modify
Use the MODIFY command to change a line within an Internal Table Example: LOOP AT I_TAB. C_INITIALIZE TO I_TAB-INITIALIZE. ENDLOOP. MOVE MODIFY I_TAB.
6.1.3.3
Delete
Use the DELETE command to delete a row or group of rows from an Internal Table. When DELETEing a group of rows from an Internal Table, delete them using a DELETE WHERE clause instead of a single row at a time during a LOOP, unless other activity takes place during the LOOP. Example: DELETE I_TAB WHERE WERKS EQ C_0010. If possible, WHERE should be used together with FROM...and/or TO ... to enhance performance even more. Example: DELETE I_TAB [FROM] [TO] Considerations: To delete all rows in an Internal Table, use the REFRESH statement. When working with Internal Tables, use the FREE command to release the memory after the Internal Table has served its purpose and will not be used again. WHERE.
Example: If Table I_TAB is 10MB, use FREE I_TAB. If an Internal Table is defined locally in a subroutine, the allocated memory is released upon completion of the subroutine, so the REFRESH statement is not needed.
156449847.doc Page
46
6.1.4
Sorting Internal Tables

Qualify all SORT statements with the BY option and limit the sorting of data to fields that must be used to satisfy the requirements. SORTs, in general, are expensive. Considerations: Be aware of the effect on character sequence using SORT. Upper case characters can be sorted before lower case letters or, lower case can be sorted before upper case. The sort might place letters before numbers or vice versa.
SORTED Internal Tables When SORTing Internal Tables, specify the fields to be SORTed.
Example:
More Efficient
SORT ITAB BY FLD1 FLD2
Less Efficient
SORT ITAB. Building SORTED Tables
If the amount of data is less than 20 entries, or if read access to the Internal Table is needed while the ITAB is being filled, use a one-step approach using READ/INSERT. If the data amount is larger and read-access is only needed to the completely filled table, use the two-step process. Example:
One-step Approach: READ/INSERT

* I_DEST is filled with 1000 entries REFRESH I_DEST. LOOP AT TAB_SRC INTO WA_SRC. READ TABLE I_DEST WITH KEY K = TAB_SRC-K BINARY SEARCH. INSERT WA_SRC INTO I_DEST INDEX SY-TABIX. ENDLOOP.
*Use on small tables (<= 20 rows)
Two-step Approach: APPEND, SORT

* I_DEST is filled with 1000 entries REFRESH I_DEST. LOOP AT TAB_SRC INTO WA_SRC. APPEND WA_SRC TO I_DEST. ENDLOOP. SORT TAB_DEST BY K. *Use on large tables
156449847.doc Page
47
6.1.5
6.1.5.1
General Internal Table Techniques

DESCRIBE
DESCRIBE determines the number of entries in an Internal Table. Example:
More Efficient
DESCRIBE TABLE I_TAB LINES W_LNE_CNTR
Less Efficient
LOOP AT I_TAB. W_LNE_CNTR = W_LNE_CNT + 1. ENDLOOP
6.1.5.2
RANGES
The RANGES statement creates Internal Tables that have the structure of a SELECTOPTION table, but the RANGES do not have the same functionality. The structure created by the RANGES statement is: Example: BEGIN OF R_tab, SIGN(1), OPTION(2), LOW LIKE .., HIGH LIKE .., END OF R_tab.
As a standard, when using the IN operator in combination with SUBMIT, SELECT, CHECK, WHILE, or IF, always define the associated Internal Table using SELECTOPTIONS or RANGES Never define the selection criteria in an Internal Table directly. Using RANGES will make for easier maintainability, readability, and conforms to SAP recommendations. As a standard, when an Internal Table is to be used as above, use the RANGES definition to define the range. Example:
Standard
RANGES R_tab for lfb1-Bukrs
Non-Standard
156449847.doc Page
48
DATA:
BEGIN OF I_TAB, OCCURS nn, SIGN(1), OPTION(2), LOW LIKE .., HIGH LIKE .., END OF I_TAB,.
Considerations when using RANGES: RANGES are not selection screen fields. RANGES are not passed to the logical database programs. RANGES do not support the short form of logical expressions, RANGES are to be used in the WHERE clause of OPEN SQL statements in expressions with the IN parameter.
6.1.5.3
Miscellaneous
More Efficient
APPEND WA_ TO ITAB.
Less Efficient
MOVE WA_ TO ITAB. APPEND ITAB.
More Efficient
INSERT WA_ INTO ITAB.
Less Efficient
MOVE WA_ TO ITAB. INSERT ITAB.
More Efficient
COLLECT WA_ INTO ITAB.
Less Efficient
MOVE WA_ TO ITAB. COLLECT ITAB.
156449847.doc Page
49
Use the FREE statement to release the memory allocated to Internal Tables. The FREE statement should follow the last statement used to process the data in the table. Use the FREE statement where you no longer need the internal table in your program.
As noted above in APPEND, when using Internal Tables with a header line, avoid unnecessary assignments to the header line. Use statements that have an explicit work area: Examples: When performing control break logic on Internal Tables and FIELD-GROUPS, make use of the AT NEW, AT END OF, ON CHANGE OF, and SUM commands. The use of ABAPs control break commands will provide easier readability and maintainability versus coding the break logic without the benefit of the commands. When using the control break logic statements, one must necessarily use the work area instead of internal table header.
6.1.6
FIELD GROUPS
SAP R/3 Requirements: FIELD-GROUPS combines several existing fields together under one name. Used in conjunction with INSERT, EXTRACT, and LOOP. Conceptually, it is similar to processing Internal Tables. Considerations: FIELD-GROUP are used to build internal tables that have a common key structure but different arguments. They are supported by 3.0 and more efficient than internal tables because of compression. FIELD-GROUP should be used to process large amounts of data. Smaller amounts of data should be stored in Internal Tables. As soon as the first dataset for a FIELD-GROUP has been extracted with EXTRACT, the FIELD-GROUP can no longer be extended with INSERT. FIELD-GROUPS can only have records added to them before a sort or loop command is performed.
6.1.7
Generation of Error Log from a Dialog Program

If a list is required (e.g an Error or Confirmation Log) from dialog processing, use the statement LEAVE TO LIST-PROCESSING. Its effect is to start the list processor and display the basic list after the PAI processing of the current screen. Then its possible to use all the usual list layout commands like WRITE, SKIP, etc. All list programming options are possible, e.g line selection, function keys, windows. List processing can be exited by using the BACK/EXIT/CANCEL of the GUI status defined for the list using SET PF_STATUS ... By default, the dialog processor returns to the PBO of the screen from where the list was called.
156449847.doc Page
50
Example
Sample Code
set pf-status '24BM_ERR'. leave to list-processing. write text-004. loop at i_return where type = 'E'. * Data to be displayed write at / i_return-message endloop.
6.1.8
Display of Traffic Lights

Traffic lights (Red, Yellow and Green) might have to be displayed for different error situations i.e. Red for Error, Yellow for Warning and Green in case there is no error or warning. The following piece of code demonstrates the method:
Sample Code
* Type defined for module level validations types:begin of t_module, * The field (statusicon) represents the icon for traffic lights statusicon type icons-text, " for status icon include structure zcramodhd. types: end of t_module. Data w_icon_stat type icons-text. Data I_module type standard table of t_module with header line. * Creating the traffic lights in the status field depending on the corrstat (Error Status field) of the record in the table zcramodhd clear: w_stat, w_icon_stat. w_stat = i_module-corrstat. perform f_get_lights using w_stat changing w_icon_stat. i_module-statusicon = w_icon_stat. form f_get_lights using p_w_stat changing p_w_icon_stat. data: l_stat like zcramodhd-corrstat, l_icon_stat type icons-text, l_icon_name(60) type c. l_stat = p_w_stat. l_icon_stat = p_w_icon_stat. if l_stat = c_e. l_icon_name = c_red. elseif l_stat = c_w. 156449847.doc Page
51
l_icon_name = c_yellow. elseif l_stat = space. l_icon_name = c_green. endif. * This function module will return the icon (l_icon_stat) call function 'ICON_CREATE' exporting name = l_icon_name importing result = l_icon_stat exceptions if sy-subrc <> 0. * Status light not created. Error Message endif. p_w_stat = l_stat. p_w_icon_stat = l_icon_stat. endform. " F_GET_LIGHTS
6.1.9
Generation of Sequence Numbers

Depending on the business requirements the generation of sequence numbers can take place in the following ways: If the number to be generated is independent of any other entity, the number can obtained by using a standard or user-defined function module which gets the next available number for the domain. Example * For external number range get the next number available call function 'GET_NEXT_NUMBER' exporting domname = c_domn_name_id importing nxtnum = w_rcid exceptions invalid_number_range = 1 invalid_parameter_type = 2 others = 3.
When using the standard or user defined function modules to generate the next sequence number, there can be a number loss in case of an error. This loss of number is not acceptable in statutory transactions like GR, IR,etc. where one should try to confirm the validations in test mode before generating the number. To keep the loss to a minimum, the number should be generated after all validations and just before the enqueue function for logical locking if the number field is part of the lock key else just before the update statement.
156449847.doc Page
52
If the number is to be internally generated without a number range we get the last used number from the database table, increment it by one to get the next number, and lock it immediately. Example * Get the last used value of plant recid for plant and date select max( plntrecid ) into w_plantid from /slssv/cplntrec where plant = p_plant and lddate = p_date. w_plantid = w_plantid + 1. Immediately enqueue w_plantid.
6.1.10
Use of Packed Numbers

Use caution when performing arithmetic with packed numbers. Be aware that if the numbers are defined with a different number of decimal places you may get unexpected results. ABAP performs the arithmetic ignoring the decimal places and inserts the decimal on the answer. Careful testing is essential. All Packed fields are treated as whole numbers. Calculations involving decimal places require additional programming to include multiplication or division by 10, 100, 1000, etc.. The DECIMALS specification with the DATA declaration is effective only for output with the WRITE statement. If, however, fixed point arithmetic (program attributes) is active, the DECIMALS specification is also taken into account. In this case, intermediate results are calculated with maximum accuracy (31 decimal places). This applies particularly to division. For this reason, you should always set the program attribute "Fixed point arithmetic", unless there are technical requirements needing floating-point.
6.1.11
Adding Leading Zeros

To display a numeric value in a layout or a report with all leading zeros, instead of using your own code use the function module CONVERSION_EXIT_ALPHA_INPUT. This function converts a padded value to a value with leading zeros. e.g. If you give the input as 123 & the field length is 10 then this module will give the output as 0000000123.
6.1.12
Handling Dates in BDC Session

Date values in a BDC session should always be converted to a value as per the user master so as to maintain consistency. To achieve the above, make use of the function module DATE_STRING_CONVERT. In the input parameters of this function we specify the format of the existing date and its value. The output of the function module is the date as per the User Master. e.g. FORM abc. data: ws_date like sy-datum.
156449847.doc Page
53
: : *--- Fix date. CALL FUNCTION 'DATE_STRING_CONVERT' EXPORTING DATE_FORMAT = '4' "4 = YYYY.MM.DD DATE_STRING = date_value * START_DATE = SY-DATUM IMPORTING RESULT_DATE = ws_date. write ws_date ENDFORM. to ... " abc
Here ws_date contains date_value as the format in the User Master.
6.1.13
IF Comparison
Before doing IF comparisons on elements of different types (i.e., numeric to character), move one element to a variable of the same type as the other element so that you will not experience unexpected results. While ABAP will automatically convert elements of unlike types for you, the end result may not be what the programmer expects. When comparing quantity fields, make sure the quantities are in the same unit of measure. Note that this is normally done by looking at which field is used NOT by coding in a unit conversion or validation.
6.2 Internal Tables - SAP Release 4.x

Table Declaration and Memory Allocation
Types: BEGIN OF <type>, <fieldnames> , END OF <type>. Data: <itab> TYPE <itabkind> of <type> [with [UNIQUE]/NON UNIQUE] <keydef> [INITIAL SIZE <n>], <work area> TYPE <type>.
Examples Standard - Non-Unique Key, accessed by key or indexing (predominantly by indexing, also known as Index Tables). When the key is used, the time increases linearly with the number of table entries.
TYPES: BEGIN OF T_MAT, WERKS LIKE MSEG-WERKS, MATNR LIKE MSEG-MATNR, END OF T_MAT. DATA: I_MAT TYPE STANDARD TABLE OF T_MAT WITH KEY NON-UNIQUE MATNR INITIAL SIZE 0, WA_MAT TYPE T_MAT.
Sorted - Key is either Unique or Non-Unique, accessed primary by key or indexing (predominantly by Key). When the key is used, the time is logarithmic in relation to the number of table entries.
TYPES: BEGIN OF T_MAT, WERKS LIKE MSEG-WERKS, MATNR LIKE MSEG-MATNR, END OF T_MAT. DATA: I_MAT TYPE SORTED TABLE OF T_MAT WITH UNIQUE KEY WERKS INITIAL SIZE 10000, WA_MAT TYPE T_MAT.
Hashed - Unique Key, accessed only by Key. Response time is constant and does not depend on the number of entries.
TYPES: BEGIN OF T_MAT, WERKS LIKE MSEG-WERKS, MATNR LIKE MSEG-MATNR, DATA: I_MAT TYPE HASHED TABLE OF T_MAT WITH KEY WERKS INITIAL SIZE 10000,
156449847.doc Page
54
END OF T_MAT.
WA_MAT TYPE T_MAT.
The table type defines how ABAP accesses individual table entries. There are now three different types of internal tables in SAP Release 4.x: standard, sorted and hashed. In a standard table, records can be accessed using either the table index or the key. If a key is used, the response time is in linear relation to the number of table entries. The key of a standard table is always NON-UNIQUE. Standard tables are generically known as index tables. In a sorted table, the entries are always saved sorted according to the key. It is possible to access the table using either the table index or the key. When the key is used, the response time is in logarithmic relation to the number of table entries, since the system uses a binary search. The key or a sorted table can be either UNIQUE or NONUNIQUE. Sorted tables are generically known as index tables. Hashed tables can only be accessed using their key. The response time is constant, and does not depend on the number of table entries, since the system uses a hash algorithm to access entries. The key of a hashed table must always be unique. Sorted or hashed tables using index operations (INSERT , INDEX, APPEND) cannot be filled. Also it is not possible to SORT a sorted table. There are two types of keys for internal tables. Standard key consists of all of the nonnumeric fields from the internal table that are not internal tables. User-defined key can consist of any fields from the internal table that are not internal tables. The additions UNIQUE and NON-UNIQUE determine whether the table with type <itabtype> may contain entries with duplicate keys.
6.2.1
Memory Allocation for Internal Tables in SAP 4.x

Due to all of the internal table nesting that occurs, SAP has needed to take better control of the memory allocation process for internal tables. In Release 3.X, the memory for internal tables was allocated in 8KB blocks. In Release 4.X there will be a new algorithm to allocate memory. Essentially, internal tables will now be expected to declare their table type with an: < initial size> * <row length> = initial allocation. If that initial allocation is exceeded, the above equation will be repeated up to 3 times. After that initial allocation has been exceeded 3 times, memory is simply allocated in 12KB blocks. Likewise, if no initial size is specified, SAP guesses (i.e. uses an undisclosed algorithm).
6.3 Code to add Function Key to Reports

Use the following code to add Function keys to Reports. The code helps in creating function buttons in a report without the use of PF-STATUS. *--------------------------------------------------------------------------------------*table for function button 156449847.doc Page
55
tables: sscrfields, d0100. : : *********************************************************************** * * SELECTION SCREEN *********************************************************************** * *button to check sm35 selection-screen function key 1. *button to check sm35 *for more buttons use key 2 and key 3 and key 4. : : INITIALIZATION. * prepare SM35 button sscrfields-functxt_01 = 'View SM35'. "for key 1 : : at selection-screen. if sscrfields-ucomm = 'FC01'. D0100-MAPN = PA_GROUP. SET PARAMETER ID 'MPN' FIELD D0100-MAPN. CALL TRANSACTION 'SM35' AND SKIP FIRST SCREEN. endif. -------------------------------------------------------------------------------------The limitation to the above code is that max 4(four) function keys can be added to the selection screen.
6.4 Logical Database

In most cases, it is likely that coding database retrievals with SELECT statements will prove more efficient than using a Logical Database (LDB) program. A LDB program reads tables with nested SELECT loops. The depth of the SELECT into the LDB hierarchy depends on the GET statement in the ABAP corresponding to the tables located at the lowest level of the LDB hierarchy. If a program does not need information from a superior table in the hierarchy, unnecessary reads will occur. Before using a LDB, be sure the logic cannot be coded more efficiently using SELECT. The Logical Database allows reading of hierarchically related tables using GET statements. The advantages of the logical databases are: Ease of programming Selection screen and filtering of the data Authorization checking
If a LDB is chosen, the most efficient logical database possible should be used. Study the selection criteria and which secondary indexes are used for that view. Provide the
156449847.doc Page
56
appropriate selection criteria to limit the number of database reads. Force users to provide selection criteria by evaluating the selection criteria entered on the selection screen during AT SELECTION-SCREEN event. Use Matchcodes for selection and report sorting. Considerations: Access to database information via GET provides automatic security checking and checking on key fields from the selection screen. The SELECT statement will require both of these operations to be coded. When getting information from a hierarchy database via a logical database view, the order in which you check statements is important. Attempt to eliminate any data which is not required at the earliest stage possible. An ABAP report can work with only one logical database, but every logical database can be shared by several reports. When using a logical database, the selection screen of the report is called automatically by the logical database program. When using the SELECT statements the selection screen must be programmed. Even if a logical database will not be attached to your ABAP Report, transaction SE36 is useful to learn. - especially the secondary index tables and relationships between tables. Logical Database Programs cannot be attached to Function Modules. When using Logical Databases, you must take into consideration the following: Determine if some of the selection screen fields can be required fields. This would force the users to put in a value into these fields limiting the number of rows retrieved within the logical database program. The selection screen can be dynamically modified by the program using the logical database and using AT SELECTION-SCREEN output event. Use the GET dbtab <fields> option to retrieve only the fields needed by your program. This option requires the initialization event to populate all internal tables with the table name and the field name. Use help on GET for additional information.
6.4
Subroutines
The three subroutine alternatives are: FORM routines Include programs Call functions Calling ABAP subroutines can create conflicts between the goals of transparency, maintainability and performance. In each individual case, consider the following:
156449847.doc Page
57
How often is the form called? How much time is required by the respective module call? The guideline values for resource consumption:
Subroutine Type
Internal PERFORM External PERFORM CALL FUNCTION CALL DIALOG
Microseconds
3 20-50 20-100 10,000-150,000
6.4.1
Forms
FORMS are subroutines that allow a programmer to define a process once in a program and call that routine from different places within the program or from other programs. A FORM should be used for large coding blocks. Common sections of code accessed from several points in an ABAP should also be put into FORMS. If a block of code is executed more than once, it should be placed in a subroutine at the bottom of the code. This makes the code more readable, requires less indentation, and is easier to debug since the debugger can jump through an entire subroutine via a PF key. For good modularization, the decision of whether or not to PERFORM a subroutine should be made before the subroutine is called. Example:
More Efficient
IF f1 NE 0. PERFORM sub1. ENDIF. FORM sub1. . ENDFORM.
Less Efficient
PERFORM sub1. FORM sub1. IF f1 NE 0. EXIT. ENDIF. ENDFORM..
Considerations: Dont use PERFORM<form name>(<program name>) unnecessarily. Overall runtime will be increased because the entire program containing the actual perform must be loaded into memory. For manageability, subroutines should be created with the concept of a black box in mind. The routine will have certain input and output parameters, and knowledge Version: 3 04 March 2003
58
156449847.doc Page
of the parameters should be sufficient to use the routine. Subroutines should not, as a rule, reference global data. Alterations made to global data within the black box produce less manageable code. Calling a subroutine without parameters requires minimal extra CPU time. The more parameters passed, the more CPU time a subroutine call requires. Passing by reference requires less CPU time than passing by value. The amount of CPU time required to pass a single parameter by value is dependent on the size (field length) of the parameter. Formal parameters must be fully typed.
6.4.2
Includes
An INCLUDE is a section of code which has been separated due to program size or it is in common use by several programs. Effective use of includes can reduce development and maintenance time. Consideration: A program that uses include incorporates it at generation time, so if the include is altered all the programs that use it must be re-generated. SAP has to regenerate if the last update date and the regeneration date of the program are not the same.
6.4.3
Function Modules
For speed, internal routines are the fastest. Functions should be used for general routines so maintenance can be performed collectively. The routines are loaded into a buffer so their first access is very slow. The most frequently accessed functions are held sequentially in memory, and as new routines are used the least frequent routines are dropped. For speed internal routines are quicker than Functions. Create function calls discerningly. Perform does not require the load of includes, etc. that call functions do. Therefore, create function calls when code is used by multiple programs, otherwise use perform. Consideration: A Function module and the calling program have separate work areas. The separated work area means there is no data interface between the function module and the calling program. They are limited to the passing of import and export parameters. This improves abstraction and manageability at the cost of efficiency. A CALL to a Function Module causes the loading of the entire Function Group. Therefore, always limit the number of function modules within a group to less than five.
Error handling in Function Modules If the Exceptions are commented then the Function module will display the error if the message command is written in it otherwise the display of the message will be the responsibility of the calling program.
156449847.doc Page
59
It is recommended that the Exceptions should not be commented and rather they should be handled in the calling program by checking the value of sy-subrc. Example Call function . Exporting Importing Tables Exceptions if sy-subrc <> 0. message id sy-msgid type sy-msgty number sy-msgno with sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4. endif.
The system variables in the message in the example above are populated in the function module. It can however with substituted with a program specific message.
6.4.4
Submit, Call, Leave To

The commands SUBMIT and SUBMIT AND RETURN can be used to start another report and CALL and LEAVE TO can be used to start another transaction. These commands can be very useful to build integrated functions. Considerations: Commands which go back after execution use additional ROLL area, therefore, to protect system performance; complete one SUBMIT. AND RETURN prior to initiating another. LEAVE TO cannot be used in a transaction using BDC processing.
6.5 SQL
6.5.1 ABAP Open SQL
The SAP programming language ABAP has its own dialect of SQL. This is a rudimentary SQL language designed for database compatibility and independence. The design philosophy was to reduce SQL functionality to such a level that code written using ABAP OPEN SQL was suitable for execution against all of the major databases used by SAP, thus improving portability. When using the SELECT statement, study the key and always provide as much of the left-most part of the key as possible. If the entire key can be qualified, code a SELECT SINGLE not just a SELECT Order the columns in the WHERE clause in the same order as the key.
156449847.doc Page
60
Avoid the use of LIKE with a pattern in an ABAP OPEN SQL statement when accessing a large table .It is less efficient and can cause scanning of the table. Fields that are compared in SELECT statements should have similar attributes. If they dont the system will have to convert the data every time a comparison is made. When the data fields cant be matched via table definitions, move the data to a temporary field in the program before doing the compare (if you will be using the same field for several comparisons) Familiarize yourself with the data being processed before using the SELECT statement. Table types greatly influence how the ABAP program should process the data. When using ABAP OPEN SQL, the user is restricted to data pertaining to the client they are currently logged into unless the table is client independent or client-specified is used. When SELECTing data from a table, look at the structure of all of the available indexes and tailor the WHERE clause to take advantage of the most selective index. As of Release 3.0, specific fields can be selected instead of using the SELECT * statement. Specifying fields in the SELECT statement reduces the amount of data to be retrieved from the database. Therefore to improve performance select only the fields that are required.
6.5.1.1
Data Selection from Transparent and Pool Tables

When selecting from a Transparent or Pool Table, always qualify the SELECT statement as fully as possible with the WHERE option. This includes data fields that may not be part of the key. This allows the database to evaluate the records and return only the records matching the selection criteria. Example:
* More efficient for Transparent & Pool tables

SELECT * FROM ZZLT2 WHERE RLDNR = W_LDGR AND RRCTY = 0 AND RVERS = 001 AND RYEAR = W_YR AND BUKRS = W_CMPNY AND RACCT = W_ACCT AND RCNTR = W_CNTR. . ENDSELECT
Will work, but requires more memory & buffers

SELECT * FROM ZZLT2 WHERE RLDNR = W_LDGR AND RRCTY = 0 AND RVERS = 001 AND RYEAR = W_YR. CHECK W_CMPNY. CHECK W_ACCT. CHECK W_CNTR. ENDSELECT.
156449847.doc Page
61
6.5.1.2
Data Selection from Cluster Tables

When working with Cluster tables, only qualify the SELECT statements with fields that are part of the key. If the table is a cluster table, use the CHECK command to eliminate records after the selection has been narrowed via the WHERE clause for key fields. Cluster tables cannot be processed by the database directly, compared to transparent tables. In most cases forcing the database to unpack and check fields (as with SELECT statements containing non-key fields in WHERE clauses) is less efficient then qualifying only with key fields and letting ABAP check non-key fields after the data is returned. Example: For cluster table BSEG with keys MANDT, BUKRS, BELNR, GJAHR, and BUZEI:
* Use
the Check statement to evaluate non key fields when selecting from Cluster tables
SELECT * FROM BSEG WHERE BUKRS = BSIK-BUKRS AND REBZG = BSIK-BELNR. CHECK BSIK-LIFNR = BSEG-LIFNR. CHECK BSEG-SHKZG = S. CHECK BSEG-KOART = K. .. ENDSELECT. *Works more efficiently for cluster tables, especially in multiple application server environments.
* With Cluster tables dont specify non-key fields in the WHERE clause
SELECT * FROM BSEG WHERE BELNR = BSIK-BELNR AND BUKRS = BSIK-BUKRS AND LIFNR = BSIK-LIFNR AND SHKZG = S AND KOART = K. .. ENDSELECT. *Will work, but requires a lot of available memory, buffer space and database time to unpack non-keyed data for verification/inclusion. This work takes place at the database level and can be costly. Can overload single DB servers and slow performance for all user.
156449847.doc Page
62
6.5.1.3
SELECT Aggregates
When you need to find the maximum, minimum, sum, and average value or the count of a database column, use a select list with aggregate functions instead of computing the aggregates yourself. The network load is considerably less. Example:
Select using an aggregate function

SELECT MAX(MSGNR) FROM T100 INTO C4A WHERE SPRSL = D AND ARBGB = 00. *More Efficient
Select. Where + Check

C4A = 000. SELECT * FROM T100 WHERE SPRSL = D. CHECK T100-MSGNR > C4A. C4A = T100-MSGNR. ENDSELECT. *Will work, but not Optimally
6.5.1.4
SELECT with BUFFER support.

If buffering is allowed for a table in the ABAP Dictionary, the SELECT statement always reads the data from the buffer in the database interface of the current application server. However, as a rule, only data that does not change frequently should be buffered, and using the buffer where appropriate improves performance. This option should be used where really necessary. Selecting from buffered tables is intended for tables that are frequently used and readonly. Adding the BYPASSING BUFFER parameter to the SELECT statement is less efficient. Example:
Select without buffer support
156449847.doc Page
63
SELECT * FROM T100 BYPASSING BUFFER WHERE SPRSL = D AND ARBGB = 00 AND MSGNR = 999. *4,395 microsec
Select with buffer support

SELECT * FROM T100 WHERE SPRSL = D AND ARBGB = 00 AND MSGNR = 999. *242 microsec
6.5.1.5
Group Level Data Access

In general, external table I/O (table reads, inserts, updates) are much more efficient when done at a group level. Group-level table accesses are less expensive in terms of disk I/O and CPU cycles, and they are usually cleaner and easier to read. Example 1:
Select into Table

REFRESH I_T006. SELECT * FROM T006 INTO TABLE I_T006. *Faster
Select and the append statement

REFRESH I_T006. SELECT * FROM T006 INTO I_T006. APPEND I_T006. ENDSELECT. *Will work, but if possible, use INTO TABLE Example 2: The group update will find all matching rows in the external table and update them with the rows in the internal table.
Group Update using Table

UPDATE TADIR USING TABLE I_OBJECTS. * More Efficient
Non-group update
LOOP AT I_OBJECTS. SELECT * FROM TADIR WHERE PGMID = I_OBJECTS-PGMID AND OBJECT = I_OBJECTS-OBJECT AND OJB_NAME = I_OBJECTS-OBJ_NAME. TADIR = INT_OBJECTS. UPDATE TADIR. ENDSELECT. ENDLOOP. * Less Efficient
156449847.doc Page
64
6.5.1.6
Column Update
When possible, use column updates instead of single-row updates to update database tables Example:
Column update
UPDATE VERI_CLNT SET FUNCTINT = FUNCTINT + 1 * More Efficient
Single line update

SELECT * FROM VERI_CLNT. VERI_CLNT-FUNCTINT = VERI_CLNT-FUNCTINT + 1. UPDATE VERI_CLNT. ENDSELECT. * Will work, but Less Efficient
6.5.1.7
Filling Internal Tables

It is always faster to use the INTO TABLE version of a SELECT statement than to use APPEND statements Example 1:
Select Into Table

SELECT * FROM T006 INTO TABLE I_T006. * More Efficient
Select + Append Statement

REFRESH X006. SELECT * FROM T006 INTO I_T006. APPEND I_T006. ENDSELECT. * More Efficient
As a general rule, use database views or the INTO TABLE version of a SELECT statement with the addition FOR ALL ENTRIES IN TABLE ITAB rather than using nested SELECT statements. The latter (for all entries) is less efficient than using database views but is more efficient than nested selects. When using For All Entries in Table ITAB, it must be ensured that ITAB is not initial.
6.5.1.8
UP TO nn ROWS
The ABAP UP TO nn construct causes as many FETCHs to be executed until sufficient rows have been returned to satisfy the nn requirement. When coding a construct of this type, use SQL Trace to examine the output to see how many records can
156449847.doc Page
65
be retrieved with a single FETCH and adjust your Initial Size and UP TO values appropriately. When examining the trace screen, look for the FETCH xx Array: nnn statement. This gives the optimum value for the size of the UP TO and Initial Size in the program
6.5.1.9
ABAP Open SQL Enhancements SAP Release 4.x
6.5.1.9.1Inner Join Inner Join Provides the capability to produce a set of results from multiple tables via one SELECT statement. SELECT F1~CARRID F1~CONNID F1~FLDATE F2~CUSTOMID INTO (SFLIGHT-CARRID, SFLIGHT-CONNID, SFLIGHT-FLDATE, SBOOKCUSTOMID) FROM SFLIGHT AS F1 INNER JOIN SBOOK AS F2 ON F1~CARRID = F2~CARRID AND F1~CONNID = F2~CONNID AND F1~FLDATE = F2~FLDATE. The INNER JOIN provides the capability to produce a set of results from multiple tables via one SELECT statement (as opposed to nested selects). Views created in the data dictionary can be considered as inner joins. Since views are buffered, there will be instances when a view will be used over an inner join depending on the tables. Further investigation per situation should be done using the Runtime Analysis Tool in SE30. If field names are used in the field list that occur in both tables of the inner join, they must be made unique by either prefixing them with an alias name and a tilde OR the table name and a tilde. Overall, the result of an inner join is the same, regardless of whether the condition is expressed in the ON or WHERE clause. Using a join has the added advantage that only one statement is executed in the database. However, it has the disadvantage that redundant data from the outer table appears in the result if there is a 1:N relationship between the outer and inner tables. For this reason, when a join is used, only necessary fields should be specified. Likewise, the performance of a join depends heavily on the performance of the database optimizer that is used, especially if there are more than 2 tables in the join. 6.5.1.9.2Left Outer Join Outer Join Similar to an Inner Join, except the result of a LEFT OUTER JOIN depends on whether the condition is specified in the ON or the WHERE clause. SELECT F1~CARRID F1~CONNID F1~FLDATE F2~CUSTOMID INTO (SFLIGHT-CARRID, SFLIGHT-CONNID, SFLIGHT-FLDATE, SBOOKCUSTOMID) FROM SFLIGHT AS F1 LEFT OUTER JOIN SBOOK AS F2 ON F1~CARRID = F2~CARRID AND F1~CONNID = F2~CONNID AND F1~FLDATE = F2~FLDATE ORDER BY F1~CARRID F1~CONNID F1~FLDATE. Unlike an INNER JOIN, the result of a LEFT OUTER JOIN depends on whether the condition is specified in the ON or the WHERE clause. Without a WHERE clause the resulting table will always contain all the lines of the left table, whereas with a WHERE clause, records from the left table can be taken out. 156449847.doc Page
66
Table entries appear in the join result even if there is no corresponding record in the right-hand table. This is the equivalent of the nested SELECT statement in the result set. There are restrictions on the LEFT OUTER JOIN. For example, the only logical expressions allowed with the ON clause are = & AND. Also, the ON clause must contain fields from the right-hand table and the ON clause must contain at least one field comparison of the form tab1~field1 = tab2~field1. In addition, the WHERE clause can only contain fields from the left-hand table.
6.5.1.10
Catch / Endcatch
Catch/Endcatch - The CATCH and ENDCATCH statements allow for the implementation of global exception handling. CATCH SYSTEM-EXCEPTIONS CONVT_NO_NUMBER = 1 BCD_ZERODIVIDE = 2 OTHERS = 3. ENDCATCH. CASE SY-SUBRC. WHEN 1. WRITE: / 'Numeric conversion error.'. WHEN 2. WRITE: / 'Divide by zero error.'. WHEN 3. WRITE: / 'Unknown run time error has occurred.'. ENDCASE. The CATCH and ENDCATCH statements allow for the implementation of global exception handling. They form a processing block to allow the trapping of ABAP runtime errors (and errors from function modules and methods with 4.0C). The CATCHENDCATCH statements can be nested to any depth. If the relevant runtime error occurs in the CATCH processing block, the system jumps from the ABAP statement where the error occurred directly to the ENDCATCH statement regardless how many control structure levels exist (e.g., IF, DO, SELECT, CATCH). In addition, the return value <rcn> assigned to the system exception <excptn> is placed in the system field SY-SUBRC. If there is more than one expression <exceptn> = <rcn>, the <rcn> the first expression is returned. This is particularly important if two different ERROR classes contain the same runtime error.
6.5.2
Native SQL
The use of native SQL provides the programmer with greater flexibility but increases the responsibility to produce efficient code. In addition, native SQL can improve performance but increases responsibility. Personnel need to be multiskilled as maintenance becomes more difficult. Considerations: The buffering of tables will not be beneficial if Native SQL is used. Unlike ABAP OPEN SQL, the programmer needs to be concerned with the MANDT field. In ABAP OPEN SQL, WHERE MANDT = is added to the SELECT statement; with native SQL, the programmer needs to code WHERE MANDT = :SY-MANDT.
156449847.doc Page
67
The use of native SQL for INSERT, UPDATE, and DELETE operations is not recommended for standard SAP tables. As native SQL directly accesses the underlying database and bypasses the buffer for SAP buffered tables, native SQL should only be used for read-only tables. With the use of SQL, there is a potential loss of portability.
6.6 String Manipulation

6.6.1 CONCATENATE
Use the CONCATENATE statement instead of programming a string concatenation. Example:
Use of the CONCATENATE statement

MOVE Jane TO W_MA. MOVE Miller TO W_MB. MOVE New York City TO w_MC. CONCATENATE Mrs. w_MA w_MB from w_MC INTO CHA SEPARATED BY SPACE. Mrs. Jane Miller from New York City is the final value of CHA * More Efficient
Moving with Offset

MOVE Jane TO w_MA. MOVE Miller TO w_MC. I1 = STRLEN( w_MA ). I2 = STRLEN( w_MB ) MOVE Mrs. TO W_CHA. MOVE w_MA TO CHA+5. I1 = I1 + 6. MOVE w_MB TO CHA+11. 1 = I1 + 12 + 1. MOVE from TO CHA+I1.I1 = I1 + 5. MOVE w_MC TO CHA+11. Mrs. Jane Miller from New York City is the final value of CHA * Less Efficient Some string manipulation functions have become obsolete in Release 3.0 and can be replaced by an ABAP statement or functions: STRING_CONCATENATE SPLIT STRING_CENTERED STRING_MOVE_RIGHT Example: CONCATENATE STRING_SPLIT STRING_LENGTH STRLEN() WRITE TO CENTERED WRITE TO RIGHT-JUSTIFIED
Use of the CONCATENATE Statement
156449847.doc Page
68
CONCATENATE T100-ARBGB T100-MSGNR T100-TEXT INTO w_CLA. * Standard in Release 3.0
Use of a CONCATENATE function module

CALL FUNCTION STRING_CONCATENATE_3 EXPORTING STRING1 = T100-ARBGB STRING2 = T100-MSGNR STRING3 = T100-TEXT IMPORTING STRING = w_CLA EXCEPTIONS TOO_SMALL = 01. * Obsolete in Release 3.0
6.6.2
Removing Leading Spaces

If leading spaces in a string are to be deleted, use the ABAP statement SHIFT LEFT DELETING LEADING
Avoid using SHIFT inside a WHILE loop. Example:
Using SHIFT LEFT DELETING LEADING

W_CLA contains the sting Editor line n. SHIFT W_CLA LEFT DELETING LEADING SPACE. * More Efficient
Shifting by SY-FDPOS places

W_CLA contains the sting Editor line n. IF W_CLA CN SPACE. ENDIF. SHIFT W_CLA BY SY-FDPOS PLACES LEFT. * Less Efficient
6.6.3
SPLIT
Use the SPLIT statement instead of programming a string split. Example:
Use of the SPLIT statement

156449847.doc Page
69
* W_CMA contains '(410)-45174-66354312' and shall be split into * W_AREA_CD, W_TEL_NBR1, TEL_NBR2 SPLIT W_CMA AT '-' INTO W_AREA_CODE W_TEL_NBR1 W_TEL_NBR2. * More Efficient
Use of SEARCH and MOVE with offset

*W_CMA contains '(410)-45174-66354312' and shall be split into *AREA_CD, TEL_NBR1, TEL_NBR2. SEARCH W_CMA FOR '-'. MOVE W_CMA(SY-FDPOS) TO W_AREA_CD. I1 = SY-FDPOS + 2. SEARCH W_CMA FOR '-' STARTING AT I1. I1 = I1 - 1. MOVE W_CMA+I1(SY-FDPOS) TO TEL_NBR1. I1 = I1 + SY-FDPOS + 1. MOVE W_CMA+I1 TO TEL_NBR2. * Less Efficient
6.6.4
STRLEN
The ABAP function STRLEN returns the length of a string up to the last character that is not a space. Example * Display the length of the variables w_word1, w_word2 and w_word3 DATA: W_INT TYPE I, W_WORD1(20) VALUE 'ABCDE'. W_WORD2(20). W_WORD3(20) VALUE ' 4 '. W_INT = STRLEN( W_WORD1 ). WRITE W_INT. W_INT = STRLEN( W_WORD2 ). WRITE / W_INT. W_INT = STRLEN( W_WORD3 ). WRITE / W_INT. The results are 5 , 0, and 1 respectively.
6.7
FIELD-SYMBOLS
Use the ASSIGN and FIELD-SYMBOLS statements to provide the powerful functionality of pointers. FIELD-SYMBOLS are place holders for fields. A FIELDSYMBOL does not occupy memory, but points to a position that has been ASSIGNed to the FIELD-SYMBOL at runtime. After the FIELD-SYMBOL has been ASSIGNed to an object, it can be worked with the same way as the object itself. Example:
156449847.doc Page
70
A data string contains two types of fields. Field 1 contains the length of Field 2; Field 3 contains the length of Field 4. This occurs until the length field contains 0 or the total length is over 3000. PARAMETERS: DATA: P_FL_IN(70). INPT_RCRD(3000),
POSITION LENGTH TYPE N. FIELD-SYMBOLS <ENTRY>.
TYPE I,
DO. READ DATASET P_FL_IN INTO INPT_RCRD. SUBRC NE 0. EXIT. LENGTH = INPT_RCRD+POSITION(3).
IF SYENDIF. IF LENGTH = 0. EXIT.
ENDIF. ADD 3 TO POSITION. ASSIGN INPT_RCRD+POSITION(LENGTH) TO <ENTRY>. WRITE <ENTRY>. IF POSITION >= 3000. EXIT. ENDIF. ENDDO. Considerations:
As FIELD-SYMBOL references are only established at runtime, the syntax does not always detect errors such as type conflicts. This could cause runtime errors or incorrect data assignments. As of Release 3.0, to avoid the possibility of a type conflict, you can declare FIELD-SYMBOLS with a TYPE.
6.8
General Statements
Logical expressions are evaluated from left to right. The evaluation is ended when the final result has been established (elimination or complete inclusion). Therefore, when using AND or OR operator (in IF, WHERE, etc.), the most likely elimination criterion should be specified first. The opposite will be true for negative comparisons and some OR conditions.
Example: The following table is to be read with printing of employees from ABC company in Georgia:
EMPLOYEE
001 002 003
NAME
Doe, J Doe, M Jones, A.
COMPANY
ABC ABC XYZ
STATE
TX OK TX
156449847.doc Page
71
004 005 006 007 008 009 010
Jones, B. Jones, C. Jones, D. Jones, E. Smith, A. Smith, B. Smith, C.
ABC ABC XYZ ABC ABC ABC ABC
GA TX GA TX GA TX OK
Less Efficient
IF COMPANY = ABC AND STATE = GA. WRITE ENDIF. Will work, but will need to evaluate both the company and state fields for eight of ten records.
More Efficient
IF STATE = GA AND COMPANY = ABC. WRITE ENDIF. Will need more time to process, since it can eliminate all records without STATE = GA and therefore will need to evaluate both company and state for only 3 records. Use special operators CO (Contains Only), CA (Contains Any), CS (Contains String) instead of programming the operations yourself. If ABAP statements are executed per character on long strings, CPU consumption can rise substantially.
Example:
Do-Loop with Field-Symbols

ASSIGN CHA(1) TO <C>. DO 200 TIMES. IF <C> = ( OR <C> = ). .. any actions EXIT. ENDIF. ASSIGN <C>+1 TO <C>. ENDDO. 1263 microsec
Using the CA Operator

IF CHA(200) CA (). any actions. ENDIF. 443 microsec
When testing fields equal to something, use either the nested IF or the CASE statement. CASE is better for two reasons. It is easier to read and after about five nested IFs the performance of the CASE is more efficient.
156449847.doc Page
72
When records a and b have the exact same structure, it is more efficient to MOVE a to b than to MOVE-CORRESPONDING a to b, if records a and b have the exact same structure.
Example:
More Efficient
MOVE BSEG TO *BSEG
Less Efficient
MOVE-CORRESPONDING BSEG TO *BSEG
6.9 SAP Release 4.0X Object Oriented Programming

Example: REPORT Flightdemo. TYPES: tpassenger(20). CLASS c_flight DEFINITION. PUBLIC SECTION. DATA: carrid like spfli-carrid, connid like spfli-connid, fldate like spfli-fldate. METHODS: book IMPORTING passenger TYPE tpassenger. PRIVATE SECTION. DATA: passengerlist type tpassenger occurs 10. ENDCLASS.s CLASS c_flight IMPLEMENTATION. METHOD book. APPEND passenger to passengerlist. ENDMETHOD. ENDCLASS. START-OF-SELECTION. DATA: flight TYPE REF to c_flight. CREATE OBJECT flight. Flight->carrid = LH. Flight->connid = 0567. Flight->fldate = 19970908. CALL METHOD flight->book EXPORTING passenger = Peter Miller. Object Orientated Programming (OOP) re-defines modularization and can produce software more tolerant of change. Classes Define Objects Sections Public components are visible outside the class Protected components are visible to subclasses of that class Private components are only visible within the class itself. Attributes and Methods Assigned to a section
156449847.doc Page
73
Attributes define the internal state of an object, defined using a DATA statement. Store an objects properties Reference other objects Virtual, controlled by set/get methods and Read Only Methods Operations that are applied to objects. Interface is similar to function modules. Import and export parameters Pass a return value and can raise exceptions. Objects Instances of Classes Objects belong to classes and have the same attributes and respond to the same methods as other objects in that class. Objects have: State, as described by its attributes, behavior, described by its methods, and an identity. Objects may interact: by accessing public attributes, by calling methods, or by raising and handling events.
156449847.doc Page
74
7. Hints and Tips

You can use the Edit and Pattern Statement to set up statements, for example WRITE or CASE. You will get the shell of your statement already set up and you just have to enter your variables. If problems occur with data in your internal tables, check that the fields are declared in the data declaration section in the same order that they occur in the original table. Also, check to see that when you are grabbing the values for the internal table that the fields are in the same order as in the declared table statement. Use the Pretty Printer to line up your code so that statements such as if-endif are easy to read. Select Pretty Printer with the settings indent and convert to Lowercase. Copy and paste working code from other reports as much as possible to save time and avoid errors. Put all words and names that appear on your reports into text elements so that they can be maintained easily. When inputting OSS notes, if you have to input large sections of code, copy the OSS note to .txt format and then using the Tools and Upload functionality, upload the code directly into your program therefore reducing the chance of any spelling errors or mistakes. Before a piece of code goes live, it is always a good idea to ask another programmer to do a code review for you. They can either look at the program in their own time or you can go through the program with them. The checker maybe able to see any problems or possible performance enhancements of your code and may be able to offer advice. Do not declare the initial size of an internal table. Leave this as 0 of which the system will dynamically allocate memory to however many are required. It is more efficient than declaring occurrence of 1000 and the system allocates memory for 1000 but you only use a few. When declaring a field, try to use the LIKE statement to give your variable the same characteristics of an already defined variable. Always check ABAP statements return value SY-SUBRC, whether an operation was successful. Can be used in READ, INSERT, MODIFY, DELETE, SELECT, CALL FUNCTION etc. For more details refer to the ABAP code review checklist which is given in the Appendix below. Use Perform instead of a new print program for layout jobs. Remove redundant code from the program in the final delivery. When SELECTing data from text table ensure that the language is included in the where clause using SY-LANGU. Version: 3 04 March 2003
75
156449847.doc Page
Appendix 1/ Conversion Process

The purpose of this Appendix is to provide clear guidelines for building Conversion Programs and Conversion Reporting.
1.
Building Conversion Programs

SAP provides a number of Standard Upload Conversion programs. If no Standard Conversion program exists a Custom ABAP program will be built. Where a Standard Conversion program does exist, the program requires the input data in a specified structure/format. Consequently, a custom ABAP program must be built to manipulate and map the data. Therefore the standard process will be the development of a Custom ABAP program to produce a file that meets the SAP Standard Upload programs requirements. The new file will be passed into the Standard ABAP. A list of standard SAP programs for data upload is provided later.
1.1 File Upload

In interface programs, when you upload the data from file to internal table then all the fields should be character type only otherwise it may cause a short dump. Once the data is there in the character fields it is then validated for containing values as per its required field type. Incorrect records are rejected as errors and correct records are passed ahead for further processing. This prevents any short dumps. Also, translate to upper case all character fields (exclude descriptive text fields) of inbound files first, and then use them in validations against SAP tables.
1.2 File Transfer

When a transfer of the file from workstation to application server is required then transfer mode should always be ASCII only. When the file is opened for reading the data from application server then use in text mode. Eg. open dataset p_ifile for input in text mode. Where p_ifile is file name with path.
IN TEXT MODE
156449847.doc Page
i
Effect: If this addition is used, the contents of the file are structured in lines. Each time the READ DATASET or TRANSFER statement are used, the system reads or writes a single line.
IN BINARY MODE
Effect: The contents of the file are not structured in lines in the READ DATASET or TRANSFER operations. Instead, they are input or output as a stream. There is no need to specify the IN BINARY MODE addition explicitly. Note Only one of the additions IN TEXT MODE and IN BINARY MODE can be used in a single statement. Mode of upload the data Binary Binary ASCII ASCII Mode of opening the file Binary mode Text mode Binary mode Text mode Result # appears as a last character in each record # appears as a last character in each record # appears as a last character in each record Without #.
1.3 Text file for .CSV File

While uploading the file (*.CSV, Comma separated file) in interface job, if contents of any of the text field in the input file contains comma , it must be separately taken care of (automatically taken care in MS Excel) and the text should have identifier to signify the start and end of text field data. Eg. Data Record no. 1 Data Record no. 2 Data Record no. 3 : Plant, Schedule Code, Schedule Description, Date : P100,DLY100,Daily Schedule,01012001 : P100,DLY200,Monday, Tuesday,Schedule,01012001 : P100,DLY200,Monday, Tuesday,Schedule,01012001
Note: Record no. 2 in the field schedule description contains as an identifier, quotes signify the start and end of the schedule description and comma inside the quotes is data itself and not a field separator. Note: Record no. 3 doesnt contain quotes for schedule description. As a result system will consider Monday as Schedule Description and Tuesday as Date.
2.
Conversion Reporting
Each Conversion program should generate the following reports: 1/ Conversion Statistics Report: This is a breakdown of conversion statistics (ie/ Total number of records in the input file; total number of records processed; total number of records containing errors).
156449847.doc Page
ii
2/ Major Error Report: This is a list of all the records, which contained major errors (ie/ No value for a mandatory field; incorrect/non SAP Standard value for a mandatory field; incorrect/non SAP standard value for any field with a check table). It should also detail records which have failed because Select statements have not been able to return an SAP value (eg/ Purchase Order Conversion will take a legacy system Vendor number and use it to try to find the SAP Vendor Number). A page break should exist between these reports. Each of the conversion programs should use the same Report format.
3.
BDC Sessions vs. Call Transactions

If the requirements deem that BDC sessions are not needed in a finished state (for user review/comfort), use CALL TRANSACTION and create a BDC session for error transactions with errors.
4.
Conversion Testing
All Custom Conversion ABAPs should be unit tested prior to being signed off as completed. It is assumed that in cases where the Conversion process comprises a SAP Standard and a Custom ABAP ABAP, both will be unit tested. The text file will be passed through the SAP Standard ABAP, all the way to executing the BDC Session. Test scripts and data should be provided to the Conversion functional and technical Designers.
156449847.doc Page
iii
2/ EDI Modifications
When modifying SAP supplied EDI function modules, the following steps should be followed: 1. Copy SAP standard function module
An exact copy of SAPs standard EDI function modules will be made for those transactions that Novartis will be using. These copies will keep the same name as the original, but will be prefixed with Z_CCa ( CC = Country Code, a = application ID). The name of the function module will serve as the link back to the SAP original version. 2. Modifications and commenting
Modifications are made directly in the code of the customer function module. The modification should be commented in such a way as to allow easy readability and tracking of updates. Modifications should only include adding lines of code and commenting out of SAP code, if necessary. SAP standard code should never be deleted or changed. The modifications should be commented and marked with a search string as described in Section 4 above. 3. OSS notes should be applied simultaneously to SAP standard and custom function modules
This will ensure that both function modules are kept in sync. It also ensures that the only differences in the two function modules are the commented modifications made as a result of as GAP. This will make it easier in the future to identify SAP bugs independently from the modifications made at Novartis. The advantages and disadvantages to this method are outlined in the following table: Advantages Ease of code maintenance and modification Minimal upgrade impact. Customer function modules will remain unchanged. - no chance of overwrite. Performance can be fine-tuned more easily by removing unnecessary generic lookups (depends on customer-specific needs). Disadvantages SAP lack of support for customer function modules Migration of upgraded enhancements in SAP standard function modules to customer function modules.
156449847.doc Page
iv
3/ Correction and Transport System (CTS) Naming Standards

1. Introduction
The purpose of this document is to outline the naming convention that should be followed for the creation of Transports for ABAP development jobs in the development environment. A rigorous naming convention is the cornerstone of effective version management and change control in an SAP landscape. The Transport description will allow the technical team to audit / track / group changes in the system. It will also allow the technical team to identify and correct errors when they occur. In short a good naming standard will allow the technical team and the Basis engineers to better support the project. It should be noted that the basis team will be instructed not to move any transports from Development which do not comply with the naming standard outlined below.
2.
Standard Outline
This section will review some of the main fields of relevance in the transport, and which are regularly used as a basis for reporting. Transport No. The transport no is automatically assigned by the SAP system to each CTS. Sample Transport No: DO3K003428
The first 3 letters refer to the Instance where the transport is being created, (transport nos are client independent). K Delimiter. Finally a sequential 6 digit number that identifies the transport. For info. SAP supplied transports e.g. for Service Packs/ Hot Packets follow the SAP naming convention i.e. These are not prefixed with our system Id Short Description This field is the main focus of this document. The short description is a 60 character free text field which is completed by the creator of the transport request. This is one of the primary fields used by the technical team for reporting. Outlined below is the structure which must be followed when creating a Transport request. Position 1-3 4 5.6 7 8-11 Text Valid 3-character prefix e.g. NCC Dash - SAP module name (Pick from Functional spec name) Dash - Type of program (Pick from Functional spec name
156449847.doc Page
v
12 13.16 17.24 25+
e.g. CON, REP, etc.) followed by a space Dash - Valid sequence number (Prefix 0 to the 3 digit number obtained from Functional spec name) Valid date in YYYYMMDD format Valid R/3 user id, followed by space, followed by free form text.
Example: NCC-FI-CON 000220030121ROUTRAB1 Chart of Accounts Conversion The 3-character prefix for the transport description should be chosen from the following table: Prefix CAT DMC DNT DVC GUE NCC OSS USC UUE Description CATT SCRIPTS DEDUCTION MANAGEMENT DO NOT TRANSPORT! DEVELOPMENT CLASSES GLOBAL USER EXIT NOVARTIS CONSUMER CORE OSS NOTES US SECURITY AND CONTROLS US USER EXIT
Note: When creating Transport Requests for any User Exit jobs, please use the prefix GUE. The following aspects related to organization of CTS should be adhered to: Objects of the same program in one transport request. Objects for global use in separate request one for each ABAP object. Create related group of global objects in one request.
156449847.doc Page
vi
4/ SAP Standard Conversion Programs

Business Object Program/Transaction Code RFBIBL00 RAALTD01 (Batch Input) RAALTD11 (Direct Input) RFBISA00 RFBIDE00 RFBIKR00 RFBVAT_0 RFBVCA_0 RFBVD_ _2 RFBVGB_0 RFBVIT_0 RFBVES_0 RFBVCH_0 RPUSTD00 RPULKT00 RHALTD00 RCCTBI01 RCCLBI01 RCCLBI02 RCCLRI03 RMDATIND RM06IBI0 RM06BBI0 RM06EEI0 Purchase Order RM06EEI1 Order Development RSTXLITF Long Texts RM07RRES RM07MMBL RFBIKR00 CG31
Financial Accounting
Financial Accounting Financial Accounting Financial Accounting Financial Accounting
Accounting documents Assets G/L account master Customer master Vendor master Transfer of Bank Data (Austrian) Transfer of Bank Data (Canada) Transfer of Bank Data (Germany) Transfer of Bank Data (Great Britain) Transfer of Bank Data (Italian) Transfer of Bank Data (Spanish) Transfer of Bank Data (Swiss) Master data (Organizational Units) Payroll account Personnel planning data Create characteristics Create classes Create classification Change classification Material master Purchase information records Purchase requisitions Open purchase order Reservations Stocks (Inventory Management) Vendor master Phrases
FI-Bank Data
FI-General Ledger FI-General Ledger FI-General Ledger
Human Resources
Human Resources Human Resources
Materials Management
Materials Management Materials Management Materials Management Materials Management Materials Management Materials Management
Materials Management Materials Management Materials Management
Materials Management
156449847.doc
Page

vi
Business Object
Program/Transaction Code CG32 CG33 RIIBIP00/IBIP RIIBIP00/IBIP RIIBIP00/IBIP RIIBIP00/IBIP RIIBIP00/IBIP RIIBIP00/IBIP RIIBIP00/IBIP RIIBIP00/IBIP RIIBIP00/IBIP RIIBIP00/IBIP RIIBIP00/IBIP RIIBIP00/IBIP RCSBI010 RCSBI020 RCSBI030 RCSBI040 RCPTRA01 RCVBI010 RMMM60BI (Batch Input) RM60IN00 (Direct Input) RKCFILE0 RV14BTCI RFBIDE00 RVINVB00 RVAFSS00 RLPLAT00 RLBEST00 Version: 3 04 March 2003
vii
(EH&S)
Sources Substances Measuring point Measurement document Notifications - general Functional location Object link Equipment Maintenance plan Scheduling maintenance plan Order confirmation Equipment task list General maintenance task list Functional location task list Create bill of material Change bill of material Create variant bill of material Create bill of material with long texts Routings/task lists Documentation info record Demand management
Plant Maintenance
Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Maintenance Maintenance Maintenance Maintenance Maintenance Maintenance Maintenance Maintenance Maintenance Maintenance Maintenance
Production Master Data

Production Master Data Production Master Data Production Master Data Production Master Data
Production Planning SAP-EIS Sales and Distribution

Sales and Distribution
Several records for SAP-EIS Condition records (pricing) Customer master Open sales orders Invoicing external transactions Storage bins Stocks on Storage Bins
Sales and Distribution on Warehouse Management
156449847.doc Page
Business Object
Program/Transaction Code
156449847.doc Page
viii

ABAP Programming Standards Document Ver 3343411325851709

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

ABAP Programming Standards Document Ver 3343411325851709

Uploaded by

Copyright:

Available Formats

SAP R/3 Implementation

ABAP Programming Standards

Version: 3 04 March 2003

1. Document Revision History

Version: 3 04 March 2003

Version: 3 04 March 2003

3. General Programming Standards

Version: 3 04 March 2003

Internal data declaration:(see section 4)

Development Class ZNCT ZNCV ZNCX ZNCZ

Functions Modules Tables Declaration

Version: 3 04 March 2003

Version: 3 04 March 2003

Using Logical File Names

Version: 3 04 March 2003

Version: 3 04 March 2003

2. Choose Logical file name definition, cross-client

Version: 3 04 March 2003

Version: 3 04 March 2003

3.2 Program Attributes

Version: 3 04 March 2003

Version: 3 04 March 2003

Fixed Point Arithmetic

Start via Variant

Update programs, Comments, Formatting, Structure

Version: 3 04 March 2003

Version: 3 04 March 2003

IMPORTING DYNPROTAB = I_BDC.

Example: *----------------------------------------* F_xxxxxxxxxxxxxx *-----------------------------------------* descriptive text here * * FORM Insert a

Version: 3 04 March 2003

Example: * Insert a descriptive text to describe the INCLUDE xxxxxxxx. * INCLUDE

Version: 3 04 March 2003

Example: Correct TABLES: T1, description T2, description T3. description

ABAP Coding Structure

Version: 3 04 March 2003

TOP-OF-PAGE DURING LINE-SELECTION AT LINE-SELECTION AT PFnn AT USER-COMMAND Subroutines FORM / ENDFORM

Module Program Structure

Screen Flow Logic

Version: 3 04 March 2003

Screens and Screen Style Standards

Version: 3 04 March 2003

Version: 3 04 March 2003

line Delete line Sort... -------------Cancel

Short message Status Log off

Locking and Unlocking in Dialog/Interface Programs

Version: 3 04 March 2003

Version: 3 04 March 2003

Database Update Techniques

Back, Exit and Cancel Navigation

Version: 3 04 March 2003

Exit Exits task (application) Screen calling the task

Cancel Exits processing Screen calling task No the

Yes Checks first, save option later Back

Yes Save option first,checks later Exit G/L document

Yes, No, Cancel

Yes, No, Cancel

popup_to_co nfirm_loss_ of_ data Edit F12 (V12)

<object> F15 (V15)

Version: 3 04 March 2003

Version: 3 04 March 2003

Version: 3 04 March 2003

Validations and Data Volumes in Dialog Programs

Program call through a Function Module

Version: 3 04 March 2003

Example: ---------------------------------------- F_xxxxxxxxxxxxxx ----------------------------------------- descriptive text here * * FORM Insert a