Beruflich Dokumente
Kultur Dokumente
Version: 3
TABLE OF CONTENTS
1.
2. INTRODUCTION.....................................................................................................................................................2
3.
279114320.doc
Page
Version: 3
04 March 2003
i
4.
5.
DATA TYPES.......................................................................................................................................... 33
DATA FIELDS......................................................................................................................................... 33
ABBREVIATIONS.................................................................................................................................... 34
STANDARD HEADER AND FOOTER.......................................................................................................... 34
ABAP DICTIONARY........................................................................................................................................36
5.1
TABLES................................................................................................................................................ 36
5.1.1 Transparent Tables..................................................................................................................................36
5.1.2 Views........................................................................................................................................................36
5.1.3 Index........................................................................................................................................................36
5.2
STRUCTURES......................................................................................................................................... 37
5.3
DATA ELEMENTS................................................................................................................................... 38
5.4
DOMAINS.............................................................................................................................................. 38
5.5
SEARCH HELPS SAP RELEASE 4.X (REPLACES MATCHCODES)..............................................................38
5.6
TABLE BUFFERING................................................................................................................................ 39
5.7
DATA TYPE CONVERSION...................................................................................................................... 39
6.
279114320.doc
Page
Version: 3
04 March 2003
ii
6.5.1.1
Data Selection from Transparent and Pool Tables.........................................................................63
6.5.1.2
Data Selection from Cluster Tables................................................................................................63
6.5.1.3
SELECT Aggregates......................................................................................................................64
6.5.1.4
SELECT with BUFFER support....................................................................................................65
6.5.1.5
Group Level Data Access..............................................................................................................65
6.5.1.6
Column Update...............................................................................................................................66
6.5.1.7
Filling Internal Tables....................................................................................................................66
6.5.1.8
UP TO nn ROWS............................................................................................................................67
6.5.1.9
ABAP Open SQL Enhancements SAP Release 4.x....................................................................67
6.5.1.9.1 Inner Join..................................................................................................................................67
6.5.1.9.2 Left Outer Join..........................................................................................................................68
6.5.1.10
Catch / Endcatch........................................................................................................................68
6.5.2 Native SQL..............................................................................................................................................69
6.6
STRING MANIPULATION......................................................................................................................... 69
6.6.1 CONCATENATE.....................................................................................................................................69
6.6.2 Removing Leading Spaces......................................................................................................................70
6.6.3 SPLIT.......................................................................................................................................................71
6.6.4 STRLEN...................................................................................................................................................71
6.7
FIELD-SYMBOLS............................................................................................................................. 72
6.8
GENERAL STATEMENTS........................................................................................................................ 73
6.9
SAP RELEASE 4.0X OBJECT ORIENTED PROGRAMMING.........................................................................74
7.
APPENDIX.....................................................................................................................................................................I
1/ CONVERSION PROCESS.......................................................................................................................................I
1.
1.1
1.2
1.3
2.
3.
4.
2/ EDI MODIFICATIONS.........................................................................................................................................IV
3/ CORRECTION AND TRANSPORT SYSTEM (CTS) NAMING STANDARDS.............................................V
1.
2.
INTRODUCTION........................................................................................................................................... V
STANDARD OUTLINE.................................................................................................................................. V
279114320.doc
Page
Version: 3
04 March 2003
iii
Version
#
1
2
3
Requester
Vineet Bhatia
Vineet Bhatia
Vineet Bhatia
Initial Version
Change to CTS Naming Standards Prefix
Addition of Standards for Report Header
and Footer
279114320.doc
Page
Change Description
Version: 3
04 March 2003
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.
279114320.doc
Page
Version: 3
04 March 2003
2
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)
279114320.doc
Page
Version: 3
04 March 2003
3
3.1.1
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
279114320.doc
Page
Version: 3
04 March 2003
4
Development Class
ZNCT
ZNCV
ZNCX
ZNCZ
3.1.3
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
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
279114320.doc
Page
Version: 3
04 March 2003
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.
279114320.doc
Page
Version: 3
04 March 2003
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
279114320.doc
Page
Version: 3
04 March 2003
7
279114320.doc
Page
Version: 3
04 March 2003
8
279114320.doc
Page
Version: 3
04 March 2003
9
279114320.doc
Page
Version: 3
04 March 2003
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.
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:
279114320.doc
Page
Version: 3
04 March 2003
11
3.2.3
3.2.4
Include programs. These are not directly executable and are included in other executable or
non-executable programs.
Function group.
Subroutine Pools.
Interface pools
Class pools
Blank
Status
System Program.
Test Program.
Application
The ABAP Application should be set as mentioned in the functional specification name.
3.2.5
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.
279114320.doc
Page
Version: 3
04 March 2003
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
3.2.11
3.3
3.3.1
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.
279114320.doc
Page
Version: 3
04 March 2003
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
DevK9000045
DevK9000045 ENDIF.
Exit.
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.
Example:
******************************************
function module formats and posts
MB01 - Post Goods Receipt
******************************************
FUNCTION POST_GOODS_RECEIPT
279114320.doc
Page
* This
* transaction
* via CALL transaction
CALL
EXPORTING
TCODE = W_TCODE
Version: 3
04 March 2003
14
IMPORTING
DYNPROTAB = I_BDC.
3.3.3
Formatting
3.3.3.1
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.
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.
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
279114320.doc
Page
FORM
Insert a
Version: 3
04 March 2003
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.
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
279114320.doc
Page
Version: 3
04 March 2003
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
279114320.doc
Page
Version: 3
04 March 2003
17
SELECT-OPTIONS
CONSTANTS
DATA
RANGES
FIELD-GROUPS
FIELDS
FIELD-SYMBOLS
* Event elements
INITIALIZATION
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
3.3.5
3.3.5.1
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.
279114320.doc
Page
Version: 3
04 March 2003
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
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.
279114320.doc
Page
Version: 3
04 March 2003
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
Edit
Select all
Goto
See
below
Deselect
all
Select
block
Choose
----------Back
Extras
See
below
Environment
See below
View
See
below
Settings
See
below
Utilities
See
below
System
Create
sessions
End
session
User
profile
Services
-------------Cut
Utilities
Copy
-------------Paste
Workflow
Links
--------------
--------------
Delete
Insert
line
List
Private
notes
Own
spool
requests
Own jobs
279114320.doc
Page
Help
Applica
tion
Help
SAP
Library
Glossar
y
-------------Release
notes
-------------SAPNet
-------------Feedbac
k
-------------Settings
Version: 3
04 March 2003
20
Exit
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.3
279114320.doc
Page
Version: 3
04 March 2003
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
Locking should preferably be done at the record level for the required set of fields
only.
279114320.doc
Page
Version: 3
04 March 2003
22
3.3.5.4
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.
ENQUEUE_READ function can be used to check whether a lock has been obtained,
however it should be avoided.
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.
279114320.doc
Page
Version: 3
04 March 2003
23
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
3.3.5.6
Function Code
Function Type
ADD
ADD
CHANGE
CHNG
DELETE
DELT
DISPLAY
DISP
SAVE
SAVE
BACK
BACK
CANCEL
CANC
EXIT
EXIT
CHOOSE
CHSE
FIRST PAGE
P--
PREVIOUS PAGE
P-
NEXT PAGE
P+
LAST PAGE
P++
PRNT
279114320.doc
Page
Version: 3
04 March 2003
24
Back
Exit
Cancel
Effect
Exits
processing
Jump target
Screen
calling
task
Save
option(dialogu
e window)
Yes
Yes
No
Checks
Yes
Yes
No
Sequence of
save/check
---
Example title
of dialogue
window
Back
Cancel
editing
Diagnosis text
in dialogue
window
No diagnosis text
No diagnosis text
Unsaved
data will be
lost (e.g.)
Example text
in dialogue
window
Unsaved
data will be
lost.
the
--- blank
line --Do you want
to cancel the
editing? (1st
line
is
diagnosis
text)
Pushbuttons
in dialogue
window
(default
answer
underlined)
Yes, No
Function
module
popup_to_confirm_step
popup_to_confirm_step
popup_to_co
nfirm_loss_
of_ data
Action menu
Goto
<object>
Edit
F-key
F3 (V3)
F15 (V15)
F12 (V12)
279114320.doc
Page
Version: 3
04 March 2003
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
Error
Information
Status
Warning
Exit
DELETE
Title Delete Processing
Message text - Do you want to delete the records?
279114320.doc
Page
Version: 3
04 March 2003
26
TABLE LOCK
Transaction aborted. Unable to Lock the Database Tables
Object required is locked by another user
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)
279114320.doc
Page
Version: 3
04 March 2003
27
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
3.3.5.9
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 .
279114320.doc
Page
Version: 3
04 March 2003
28
3.4
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.
ALV Reports
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:
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.
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
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.
279114320.doc
Page
Version: 3
04 March 2003
29
3.5
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 .
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.
Date
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
279114320.doc
Page
Version: 3
04 March 2003
30
NE 0.
Exit.
DEVK900088
DEVK900088
DEVK900088
ENDIF.
Or
Begin of DEVK900088
SELECT SINGLE * FROM LFA1
WHERE KUNNR EQ I_TAB-KUNNR.
SUBRC NE 0.
IF SYExit.
ENDIF.
End of DEVK900088
3.6
3.7
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.
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.
279114320.doc
Page
Version: 3
04 March 2003
31
No hard coding should be done in include text and address window in Smart Forms.
279114320.doc
Page
Version: 3
04 March 2003
32
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.
ABAP variable names can be a maximum of 30 characters long for DATA fields
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
279114320.doc
Page
Values
Meaning
C_
For Constants
P_
S_
For Parameters
For Select-Options
Version: 3
04 March 2003
33
RB_
CB_
PB_
V_
T_
L_
X_
WA_
E_
CL_
CO_
GR_
CI_
R_
Fld_
Cnt_
Flg
3+
Freely Definable
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
Version: 3
04 March 2003
34
pic00235.pcx
279114320.doc
Page
Version: 3
04 March 2003
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 -
279114320.doc
Page
Version: 3
04 March 2003
36
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
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
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>
279114320.doc
Page
Version: 3
04 March 2003
37
5.3
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
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
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.
279114320.doc
Page
Version: 3
04 March 2003
38
Considerations:
5.7
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.
External
Data Type
Description
ACCP
N(6)
CHAR n
C(n)
Character strings
CLNT
C(3)
Client
CUKY
C(5)
DEC n, m, s
P((n+2)/2) DECIMAL m
DATS
D(8)
FLTP
F(8)
INT1
1-byte integer
INT2
2-byte integer
INT4
4-byte integer
LANG
C(2)
Language key
LRAW
X(n)
LCHR
C(n)
279114320.doc
Page
Version: 3
04 March 2003
39
External
Data Type
Description
INT2 field
NUMC n
N(n)
QUAN n, m,
s
P((n+2)/2) DECIMAL m
RAW n
X(n)
TIMS
T(6)
UNIT
C(n)
VARC n
C(n)
n: no. of
places
m: number of decimal
places.
s: sign flag
Considerations:
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.
279114320.doc
Page
Version: 3
04 March 2003
40
6.1.1
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.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:
279114320.doc
Page
Version: 3
04 March 2003
41
6.1.1.2
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.
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.
279114320.doc
Page
Version: 3
04 March 2003
42
Example:
INSERT I_TAB INDEX 6.
Considerations:
Example:
INSERT LINES OF I_TAB1 FROM 3 TO 5 INTO I_TAB2 INDEX 4.
6.1.2
6.1.2.1
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:
6.1.2.2
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.
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
279114320.doc
Page
Version: 3
04 March 2003
43
More Efficient
*Key access with LOOP/CHECK
LOOP AT TAB.
CHECK TAB-K = KVAL.
" ...
ENDLOOP.
6.1.2.3
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.
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:
6.1.2.4
Correct Method
Loop at itab where .
Wa_itab = itab.
At end of plant.
Endat.
Endloop.
279114320.doc
Page
Version: 3
04 March 2003
44
6.1.3
6.1.3.1
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.
8.
WHEN 4.
INSERT ITAB INDEX SY-TABIX.
APPEND I_TAB.
WHEN
..
ENDCASE
* For Internal Tables with less than 50 entries the COLLECT is acceptable.
6.1.3.2
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.
Modify
Use the MODIFY command to change a line within an Internal Table
Example:
279114320.doc
Page
Version: 3
04 March 2003
45
LOOP AT I_TAB.
C_INITIALIZE TO I_TAB-INITIALIZE.
ENDLOOP.
6.1.3.3
MOVE
MODIFY I_TAB.
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] WHERE.
Considerations:
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.
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.
6.1.4
Upper case characters can be sorted before lower case letters or, lower case can
be sorted before upper case.
279114320.doc
Page
Version: 3
04 March 2003
46
Example:
More Efficient
SORT ITAB BY FLD1 FLD2
Less Efficient
SORT ITAB.
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:
6.1.5
6.1.5.1
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
279114320.doc
Page
Version: 3
04 March 2003
47
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.
Standard
RANGES R_tab for lfb1-Bukrs
Non-Standard
DATA:
279114320.doc
Page
Version: 3
04 March 2003
48
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.
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:
6.1.6
FIELD GROUPS
SAP R/3 Requirements:
279114320.doc
Page
Version: 3
04 March 2003
49
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:
6.1.7
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.
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.
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
279114320.doc
Page
Version: 3
04 March 2003
50
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.
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
279114320.doc
Page
Version: 3
04 March 2003
51
6.1.9
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.
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
279114320.doc
Page
Version: 3
04 March 2003
52
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
6.1.12
to ...
" abc
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
279114320.doc
Page
Version: 3
04 March 2003
53
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.
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.
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,
END OF 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.
279114320.doc
Page
Version: 3
04 March 2003
54
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
Version: 3
04 March 2003
55
Ease of programming
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
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.
279114320.doc
Page
Version: 3
04 March 2003
56
6.4
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.
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.
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:
Subroutine Type
Microseconds
Internal PERFORM
External PERFORM
CALL FUNCTION
CALL DIALOG
6.4.1
3
20-50
20-100
10,000-150,000
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.
279114320.doc
Page
Version: 3
04 March 2003
57
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:
6.4.2
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
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.
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:
279114320.doc
Page
Version: 3
04 March 2003
58
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.
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.
279114320.doc
Page
Version: 3
04 March 2003
59
6.4.4
Commands which go back after execution use additional ROLL area, therefore, to
protect system performance; complete one SUBMIT. AND RETURN prior to
initiating another.
6.5 SQL
6.5.1
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.
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.
279114320.doc
Page
Version: 3
04 March 2003
60
6.5.1.1
ENDSELECT.
6.5.1.2
279114320.doc
Page
Version: 3
04 March 2003
61
Example: For cluster table BSEG with keys MANDT, BUKRS, BELNR, GJAHR, and
BUZEI:
* Use
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:
279114320.doc
Page
Version: 3
04 March 2003
62
6.5.1.4
6.5.1.5
*242 microsec
Version: 3
04 March 2003
63
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
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
6.5.1.7
Version: 3
04 March 2003
64
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 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
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, SBOOK-CUSTOMID)
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.
279114320.doc
Page
Version: 3
04 March 2003
65
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 SYSUBRC. 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
279114320.doc
Page
Version: 3
04 March 2003
66
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.
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.
CONCATENATE
Use the CONCATENATE statement instead of programming a string concatenation.
Example:
279114320.doc
Page
Version: 3
04 March 2003
67
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
CONCATENATE
STRING_SPLIT
STRING_LENGTH
STRLEN()
WRITE TO CENTERED
WRITE TO RIGHT-JUSTIFIED
Example:
6.6.2
DELETING LEADING
Editor line n.
SHIFT W_CLA LEFT DELETING LEADING SPACE.
* More Efficient
279114320.doc
Page
Version: 3
04 March 2003
68
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:
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.
279114320.doc
Page
Version: 3
04 March 2003
69
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:
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:
P_FL_IN(70).
DATA:
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.
279114320.doc
Page
Version: 3
04 March 2003
70
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
NAME
COMPANY
STATE
001
002
003
004
005
006
007
008
009
010
Doe, J
Doe, M
Jones, A.
Jones, B.
Jones, C.
Jones, D.
Jones, E.
Smith, A.
Smith, B.
Smith, C.
ABC
ABC
XYZ
ABC
ABC
XYZ
ABC
ABC
ABC
ABC
TX
OK
TX
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.
Example:
279114320.doc
Page
Version: 3
04 March 2003
71
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.
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
Version: 3
04 March 2003
72
279114320.doc
Page
Version: 3
04 March 2003
73
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.
When SELECTing data from text table ensure that the language is included in the
where clause using SY-LANGU.
279114320.doc
Page
Version: 3
04 March 2003
74
Appendix
1/ Conversion Process
The purpose of this Appendix is to provide clear guidelines for building Conversion
Programs and Conversion Reporting.
1.
IN TEXT MODE
279114320.doc
Page
Version: 3
04 March 2003
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
Text mode
ASCII
Binary mode
ASCII
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 #.
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).
279114320.doc
Page
Version: 3
04 March 2003
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.
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.
279114320.doc
Page
Version: 3
04 March 2003
iii
2/ EDI Modifications
When modifying SAP supplied EDI function modules, the following steps should be
followed:
1.
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 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.
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).
279114320.doc
Page
Disadvantages
SAP lack of support for customer function
modules
Migration of upgraded enhancements in
SAP standard function modules to customer
function modules.
Version: 3
04 March 2003
iv
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
279114320.doc
Page
Version: 3
04 March 2003
v
12
13.16
17.24
25+
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.
279114320.doc
Page
Version: 3
04 March 2003
vi
Program/Transaction Code
Financial Accounting
Accounting documents
RFBIBL00
Financial Accounting
Assets
Financial Accounting
Financial Accounting
Financial Accounting
FI-Bank Data
RFBVAT_0
FI-General Ledger
FI-General Ledger
FI-General Ledger
RFBVCA_0
RFBVD_ _2
RFBVGB_0
RFBVIT_0
RFBVES_0
RFBVCH_0
Human Resources
RPUSTD00
Human Resources
Human Resources
Payroll account
Personnel planning data
RPULKT00
RHALTD00
Materials Management
Create characteristics
Create classes
Create classification
Change classification
Material master
Purchase information records
Purchase requisitions
Open purchase order
RCCTBI01
RCCLBI01
RCCLBI02
RCCLRI03
RMDATIND
RM06IBI0
RM06BBI0
RM06EEI0 Purchase Order
RM06EEI1 Order Development
RSTXLITF Long Texts
RM07RRES
RM07MMBL
RFBIKR00
CG31
Materials Management
Materials Management
Materials Management
Materials Management
Materials Management
Materials Management
Materials Management
Materials Management
Materials Management
Materials Management
Reservations
Stocks (Inventory Management)
Vendor master
Phrases
279114320.doc
Page
Version: 3
04 March 2003
vi
Business Object
Program/Transaction Code
Sources
Substances
CG32
CG33
Plant Maintenance
Measuring point
RIIBIP00/IBIP
Plant
Plant
Plant
Plant
Plant
Plant
Plant
Plant
Plant
Plant
Plant
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
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
Production Planning
Demand management
SAP-EIS
RKCFILE0
RV14BTCI
Customer master
Open sales orders
Invoicing external transactions
RFBIDE00
RVINVB00
RVAFSS00
Storage bins
Stocks on Storage Bins
RLPLAT00
RLBEST00
(EH&S)
Maintenance
Maintenance
Maintenance
Maintenance
Maintenance
Maintenance
Maintenance
Maintenance
Maintenance
Maintenance
Maintenance
279114320.doc
Page
Version: 3
04 March 2003
vii
Business Object
Program/Transaction Code
279114320.doc
Page
Version: 3
04 March 2003
viii