Abap Cook Book1

ABAP COOK BOOK
FOR ALL
DEVELOPMENTS
Index
1. Self-registration
2. Introduction to HP Systems & Land scape
2.1. Overview
2.2. R/3 systems in HP Landscape APJ, EMEA,SAIL,AMS
2.3. USER Credentials SAMM
2.4. Standard templates
3. Development Standards
3.1. Technical spec. Templates
3.2. Naming convention
3.3. ABAP Documentation Standards
3.4. Custom Program Standards
3.5. Custom ABAP Security
3.6. Unit Test cases & Documents
3.7. Implementing Solution Guidelines
3.8. PCR process code review
3.9. Transport management
3.10. Compliance of custom code
3.11. Project updates
4. Appendix
5. Conclusions
1. Self-Registration
Welcome to HP ES, SAP Technical team, we are request you to enroll your
information in below share point location.
Things to update
a. Name
b. Employee number
c. Official Email ID
d. Experience in ABAP
e. Domain experience
f. Area of expertise
2. Overview
2.1 overview
We have region wise categorized EMEA, SAIL and APJ systems inside HP
landscape. All the projects categorized and specific region wise HP internal
customers.
2.2. R/3 systems in HP Land space
SCIT ASSETS
A. EMEA
ASSET BOX CLIENT TYPE
FUSION EMEA D47/R42 010 Development

U26 010 Integration Test
S01 010 Staging/ Regression
R01 010 Production
SAIL PDN 001 R & D Project

PDN 002 Development
P2T 001 Integration Test
REL 001 QA /Regression
CPO 001 Production
B.APJ:
FUSION APJ
PD1 016 Development
TS6 016 Integration Test
FT5 016 Staging/Regression
APL 016 Production
RSAP DAP 003 Development
QAP 003 Integration Test
TAP 003 QA /Regression
PAP 003 Production

C.AMS
FUSION AMS C30 007 Development

C50 007 Integration Test
C10 007 QA/Reg/ Staging
R00 007 Production
VELOCITY D7A 300 Development

D7B 300 Integration Test
D7D 300 QA /Regression
D7C 300 Production
PROCESS FLOW
Construction Development Implementation
R & D Project Box Integration Testing Box Staging Box

Development QA/Testing Regression Production
EMEA
FUSION
U26 S01 RO1
D47
SAIL
PDN P2T REL CPO
APJ
FUSION
PD1 TS6 FT5 APL
RSAP
DAP QAP TAP PAP
AMS
FUSION
C30 C50 C10 R00
VELOCITY
D7A D7B D7D D7E

2.3 SAMM Tool
System Authorizations, Access Procedures
SCIT SAP Account Management & Maintenance- (SAMM)
The SAMM tool is used by end users and approvers to manage your SAP access needs. The sections
below will help guide you through the various requests that can be made using this tool.
Requesting a New User Account
If you DO NOT already have a USER ID in the system you need access to, use this link to request a
NEW USER ID.
http://intranet.hp.com/HPIT/WW/SCIT/Ops/Pages/SapAccess_ZUSRV2.aspx
You will have the option to either Select a User Group/Approver directly or COPY User from an existing
user ID. Please ensure the user ID you are copying from is appropriate.
NOTE: If you select to create a new account in multiple systems at once, you will NOT be able to take
advantage of the COPY User functionality. You will have to select an appropriate User Group from the
drop down list in the tool.
User Maintenance Request
If you ALREADY HAVE a User ID in the system you need access to, but need to
update/change the USER ID, use this link to request a variety of actions including:
Password reset (will also automatically unlock your User ID if it is locked due to incorrect logon
attempts)
*Note your PW will be sent to you automatically within 10 minutes.
Unlock user ID only (no password reset)
*Note: your User ID will be unlocked immediately if locked due to incorrect logon attempts.
NOTE: If your User ID has an ADMIN lock on it, you will get a Request ID sent to you and your
approver.
Your Approver must place an SST/HPSC ticket with the local Security team for assistance.
Extend validity if your User ID is expired (error message: "User account not in validity date"
when trying to log in)
Update User Access - used to request additional (or remove) access from your User ID
References & Documentation
This section contains links to helpful references and documentation for end users as well as
Approvers.
SAPGUI Installation
Instance Selector (SAPGUI Setup)
Global Groups (notification of system downtimes)
SAMM End User Guide (please use link below)
SAMM End User & Approver Guide
SAMM Frequently Asked Questions
Password Security & Password Management Policy & Standards
Corporate Common SOD Matrix Please NOTE you must sign in to this Sharepoint (Top
Right hand corner of screen click on "Sign In" button)
IT USERS ONLY - Devkey/Object Key, Service Connection Requests
AMERICAS APPROVERS ONLY - REFERENCE INFO
2.9 Standard templates
3. Documentation Standards
3.1 Technical Specification
Mandatory format to fill for all developments
Function specification
Templates for HP standard Technical specification
TDS_RVC_LO002_Z_C
REATE_TR.doc

UTD_Z_CREATE_DISPL
AY_TO_ST12584.doc

3.2 Naming standards
This documents consists of two sections. Section one contains the object naming conventions, and
section two contains several physical implementation guidelines.
SECTION I - Naming Conventions
ABAP Dictionary naming conventions have been defined for each of the following object types:
Table
Structure
View
Append Structure
Field
Data Element
Domain
Lock Object
Search Help
Secondary Index
BAPI Fields
Note : The names for each of the above should be singular and stored in upper case in SAP. Current site
code usage:
Ga = Global + originating site code
1 = EMEA
2 = PRMO
3 = NA
4 = NA Rep
7 = AP
8 = AP Rep
9 = EMEA Rep
Database Table
Definition A table definition in the ABAP Dictionary has the following

components:
Table fields: The field names and the data types of the fields
contained in the table are defined here.
Foreign keys: The foreign keys define the relationships between
this table and other tables.
Technical settings: The technical settings define how the table is
created on the database.
Indexes: Indexes can be defined for the table to speed up data
selection from the table.
Format Zyx
Z = Fixed text for custom object designation
y = Site code (1 or 2 characters. site code OR Global + site code)
x = Free form alpha characters describing table function. Project

names in the table name are not recommended unless they describe
the functionalitye.g. EDW describes both the project and
functionality.
Examples Z1ORDER_HISTORY Formatted: Strikethrough

ZG1MATERIAL_CONFIG
Structure
Definition A structure is used as a placeholder for data produced when
calculations are carried out within programs, or when data is
transferred between programs. While data in a table is stored
permanently in the database, a structure contains data only during
the runtime of a program. Therefore, a structure is defined almost like
a table, except no underlying physical database table is generated for
it.
Note: There is a different Naming Convention for IM/3 Interface
Structures than for ordinary DDIC Structures. Reason for the different
standard is: IM/3 Interface Structures are being generated out of
IM/3. In the current IM/3 versions structure names must not be longer
than 10 characters and must not contain any special characters
IM3 Standard
Format ZyS_xn
S_ = Fixed text for structure designation

x = Alphanumeric characters referring to the primary table name on
which the structure is based. If it is based on multiple tables or not
based on a table, use alpha characters describing table function.
Project names in the table name are not recommended unless they
describe the functionalitye.g. EDW describes both the project and
functionality.
n = Optional numeric counter if necessary to make the object name

unique
Examples ZG3S_KNA1 for standard SAP table KNA1
Z1S_BWRFMD BW Reference Models
Z7S_CUFLFI Customer Flat File
Table Types
Definition A table type describes the structure and functional attributes of an
internal table in an ABAP program. Defines the structure of a row of
the table type (row type), the options for accessing data in the defined
internal table (access mode) and the key of the table type.
In ABAP programs you can reference a table type defined in the
ABAP Dictionary with the command DATA <inttab> TYPE TTYP. An
internal table <inttab> is created in the program with the attributes
defined for TTYP in the ABAP Dictionary.
Format ZyT_x
x = Free form alpha characters describing table type function.
Examples Z1T_VBAK
Type Groups
Definition The ABAP Dictionary supports the definition of user-defined types
(data elements, structures and table types). You can also define the
structure of database objects (tables, indexes and views) in the ABAP
Dictionary. These objects can then be automatically created in the
database with this definition.
Format Zyx
x = Free form alpha characters describing Type function.
Examples ZG1EX User Exit type group

View
Definition A view is a virtual table that logically relates to one or more tables.
That is, the data of a view is not actually physically stored, but
derived from one or more other tables. A view can be tailored to the
needs of a specific application, making it possible to directly access
specific data. The structure of such a view is defined by specifying
the tables and fields to be contained in the view. A view can also be
used to summarize data, which is distributed among several tables. In
addition, superfluous fields can be suppressed, keeping interfaces to
a minimum. This process could involve suppressing the display of
one or more fields of a base table (projection), transferring only
certain records from a base table to the view (selection), or
assembling complex views from several tables, which are linked by
the relational join operation.
Format ZyV_xn

V_ =Fixed text for view designation
x = Name of the view based on primary key of table
n = Optional numeric counter if necessary to make the object name

unique
Examples ZG1V_KNA1 for standard SAP table KNA1
ZG1V_KNA101 for standard SAP table KNA1
Z1V_TFGFCST for custom table Z1TFGFCST
Z3V_FCSTQT for multi-table custom view for forecast quantities
Append Structure
Definition An Append Structure is used to extend a standard SAP table with
custom fields. It is not a separate dictionary object like a Structure,
but is defined/maintained only through the table definition screen. The
primary advantage of using an Append Structure is that it is protected
from being overwritten when the system is upgraded. Therefore, after
an upgrade the fields in an Append Structure are added to the new
standard tables, thereby maintaining any custom extensions that may
have been added to SAP standard tables.
Format During the process of creating an Append Structure, the system
proposes a default name. The current standard is to accept the
proposed name.
Examples ZAVBAK
Field
Definition It is important to note that a field is not an object in the ABAP
Dictionary. It has no associated description, but it provides the link
between a table and a data element, which contains a description.
The data element provides the link to a domain, which contains the
physical characteristics of the field. In other words, physical
characteristics are inherited from the domain to the data element.
Then both physical characteristics and description are inherited from
the data element to the field.
If possible, use the data element name as all or part of the field
name, so that it will inherit its name from the data element.
Notes:
SAP does not require field names in a custom table to be

prefixed with a custom designation (e.g., "ZZ") because fields
are not objects. Fields are always referenced with the table
name, which contains the custom designation.
If there is a 1:1:1 relationship between a particular Domain,
Data Element, and Field, SAP recommends using the same
name for all.
When adding fields that use existing data elements and
domains, the existing field names should also be used as
they appear in the parent table. This will aid in ABAP
programming through the use of the MOVE
CORRESPONDING command. In the case where SAP uses
a different Data Element name than the Domain, use the SAP
Data Element name. Ex. In SAP table PLAF Data Element
PLWRK uses Domain WERKS.
When the Data Element is used more than once in the table,
contact a Data Administrator to determine an appropriate field
name.
Format Extended SAP Table Field
ZZx
ZZ = Fixed text for custom object designation
x = Alphanumeric Characters from data element
Custom Table Field
x = Alphanumeric Characters from data element
Examples Table type Field name Data element Domain
SAP ZZWERKS WERKS WERKS

Custom WERKS WERKS WERKS
SAP ZZDELFLAG ZG3DELFL ZG3FLAG
Custom DELFLAG Z1DELFL Z1FLAG
Data Element
Definition A Data Element stores field descriptions. All fields assigned to a data element will have
the same description. Data Elements also store the domain name which contain the
physical characteristics of a field.
The Data Element should contain a more detailed description than the Domain. It
should describe the business functionality of the field. The last word of the description
should contain a Data Class word (Amount, Code, Flag, etc). See the Data Class
Words standard for a full list:
http://supplychainit.hp.com/eda/DataDesign/Data%20Class%20Words%20Standard%20Statement.10.03.doc
The Data Element Name should contain 1 - 3 character standard abbreviations of the
original Data Element description. If more than 3 qualifiers are needed to describe an
attribute, use the first character of the 2-character abbreviation of the least significant
word. See the Standard Abbreviations:
http://supplychainit.hp.com/eda/DataDesign/Abbreviations.htm
Notes:
Data Elements are reusable objects; i.e., multiple fields can be based on the
same Data Element. However, although the contextual meaning of the fields
may change, this can only be reflected by extensions to the Data Elements
description.
If there is a 1:1:1 relationship between a particular Domain, Data Element, and
Field, SAP recommends using the same name for all.
Format Zyx
x = Alpha characters based on the standard abbreviations of the Data Element

description
Examples Z7ORHDSTCD Order Hold Status Code

ZG1ATTGNO Asset Tag Number
Data Element Supplement
Definition Data Element Supplements are used to create screen-specific
documentation for a field. This documentation will be displayed when help
is requested for that screen-specific field. Changes made to Data Element
Long Descriptions are maintainable in SAP Release 3.0.
Format Data Element Supplement Names must be a number equal to 9000 or

greater.
Examples N/A
Domain
Definition A Domain stores physical characteristics of a field; i.e., Data Type, Length, and Range
of Values, Validation Table are defined for a Domain.
The last word of the Domain description should contain a Data Class word (Amount,
Code, Flag, etc). See the Data Class Words standard for a full list:
http://supplychainit.hp.com/eda/DataDesign/Data%20Class%20Words%20Standard%20Statement.10.03.doc
The Domain Name should contain 1 - 3 character standard abbreviations of the

Domain description. If more than 3 qualifiers are needed to describe an attribute, use
the first character of the 2-character abbreviation of the least significant word. See the
Standard Abbreviations:
http://supplychainit.hp.com/eda/DataDesign/Abbreviations.htm
Notes:
Domains are reusable objects; i.e., multiple Data Elements can be based on
the same Domain.
If there is a 1:1:1 relationship between a particular Domain, Data Element, and
Field, SAP recommends using the same name for all
Standard SAP-defined Domains should be used instead of custom-developed
Domains where possible. Some are generic in that they are not associated
with a Check Table, which is used to verify range of values. An example of a
generic SAP Domain is NUMC09.
SAP has recommended not using the INT data type for any primary key fields.
Format Zyx
x = Alpha characters based on the standard abbreviations of the Domain description
Examples Z7ORHSTCD Order Hold Status Code
ZG3APOPCTY APO Procurement Type

Lock Object
Definition Lock Objects prevent two or more users from simultaneously accessing the
same logical unit of data. Locks on the data are set or released by calling
certain function modules in an ABAP program. These functions are
automatically generated during the creation of the lock objects. Lock
objects must be defined in the ABAP Dictionary.
Format Ext
E = Fixed text for Lock Object designation
x = Name of the custom table (including the Z and site code)
t = Lock type
E = Exclusive and Cumulative
S = Shared
X = Exclusive
Examples EZ3TSLSORDX for a lock object for the table Z3TSLSORD
Search Help
Definition Help views are used to output additional information when the online help
system is called.
Format Format for SAP Standard Tables
Zyx
x = Name of the standard object the Search Help is based on
Format for Custom Tables / Objects
x = Name of the custom object the Search Help is based on.

Examples ZG3KNA1 for SAP standard table KNA1
Z3TFGFCST for custom table Z3TFGFCST
Secondary Index
Definition The function of an index is to speed up the retrieval of data from a table. An
index is usually created on specific fields on the table based on the retrieval
search criteria. A distinction is made between primary and secondary
indexes to a table. The primary index consists of the key fields of the table
and a pointer to the non-key-fields of the table. The primary index is
generated automatically when a table is created. It is also possible to define
further indexes to a table in the ABAP Dictionary, which are then referred to
as secondary indexes.
Format Zn
Z = Custom Designation
n = A Number from 1-9

Examples Z1
Z2
BAPI Fields
Definition BAPIs are interfaces for Business Objects. Together with the Business
Objects, BAPIs define and document the interface standard at the business
level. BAPI fields are merely fields within a structure in the ABAP Dictionary.
A BAPI structure is used to pass data to and from a BAPI function module.
Because the structure has visibility outside of SAP, it makes sense to use
meaningful descriptive names for the structure fields.
Format Program BAPIFELD, offered in SAP 4.6, generates English defaults for
external BAPI structures. The recommended default values should be used
when creating BAPI related structures.
Examples N/A
SECTION II - Implementation Guidelines
Table Audit Data

Table Normalization
Development Class
Table Class
Table Audit Data

A standard set of audit fields should be considered for use in custom developed tables, which require audit
functionality. If an entire structure is not needed for audit purposes, use only a subset of the structure,
reusing existing audit data elements.
Example data structure is defined as follows:
Field Name Data Type Length Short Text
CRNAME CHAR 12 Created by user; i.e., the creator's userid
CRDATE DATS 8 Creation date
CRTIME TIMS 6 Time of creation
UPDNAME CHAR 12 Last changed by
UPDDATE DATS 8 Date when object was last changed
UPDTIME TIMS 6 Time of last change
TRNSCODE CHAR 20 Transaction code
PRMNAME CHAR 40 Program Name
Table Normalization
SAP recommends normalizing custom tables and only denormalizing them in one of the following two
cases:
1. If a performance problem has been identified.

2. When estimated volumes, access path analysis, and operational standards justify the need for it.
The reason SAP recommends the use of prudence when denormalizing data is because the use of triggers
and stored procedures are not available to ensure the integrity of the redundant data often inherent in
denormalizing data. As a result, programs must be used to keep the redundant data in sync, and all it will
take to corrupt the data is one poorly written program. Denormalization also reduces data usefulness,
flexibility and limits access paths, making it less compatible with user query tools.
Therefore, the going in position for each custom table is that it should be in Third Normal Form when initially
implemented unless its denormalization can be justified.
Development Class
See Object naming standards for Development Class
Table Class
The Table Class determines the tablespaces in which the tables and indexes will be physically stored.
Therefore, if tables are to be successfully created in the tablespaces assigned to a particular project, they
must be created using the Table Class associated with the tablespaces.
Two tablespaces are associated with each USERn Table Class: one for data and ano ther for indexes.
When physical database objects are activated with a particular Table Class, they are stored in the
tablespaces associated with the Table Class.
Please contact the Regional Basis for assignment to a Table Class before defining any cus tom tables in
SAP. If all existing USERn Table Classes are inappropriate for the new project, SAP System Administration
must create a new USERn Table Class and relate it to two new tablespaces before the project can begin
custom table development.
Delivery Class
The delivery class indicates whether a table is an application table, control table, or system table. It also
indicates whether the table is maintained by the user or by SAP, and whether it is delivered by SAP with or
without contents.
The specified entries into this field are as follows:
C = Customized Check table

A = Application table for Master transaction data
Authority/Responsibility
The creation and transport of all custom ABAP Dictionary objects is the responsibility of the assigned SAP
developer. Adherence to this standard is monitored at the regional level by the designated transport
approvers.
3.3 ABAP Documentation Standards

General
This section consists of two parts:
1. Source Code Documentation.

2. On-Line Program Documentation.
Part 1 - Source Code Documentation
Source code documentation is intended to help the IT support and development teams understand the
technical implementation of a program. At some point in time, someone else will more than likely need to
understand your source code in order to modify its behavior. Source code documentation helps:
1. Improve the readability of the program

2. Reduce the time required to understand the source code
3. Document relevant thoughts, concerns, assumptions, and intentions that are not self evident
The standard components of this documentation are:
A standardized comment block with a revision history

General source code comments
General FORM documentation
SAP Exit documentation (Userexit / Function Exit)
Programming conventions / guidelines
General guidelines are provide below for each of the standard components.
Comment Block
All custom programs should include the following comment block at the very top of the program.
***********************************************************************
* Title : *
* Author Name : *
* Create Date : *
* Reference Number : *
* Specification Name : *
* Purpose : *
* Developer Notes : *
*---------------------------------------------------------------------*
* Revision History *
* Date Programmer Name Reference Number *
* User-ID Description *
* ---------- ---------------------- ------------------------ *

* xx/xx/xx xxxxxxxxxxxxxxxxx xxxxxxxxxx *
* xxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx*
***********************************************************************
Title: This is the title of the program
Author Name: Original Developer
Create Date: Origin date
Reference Num: Reference number which identifies the request. EtcOVSD, OVSC, Teamplay
Specification Name: The repository file name of the Specification that contains the program
specifications
Purpose: This section should describe the overall functional purpose of the program, and how it works, in
concise terms
Developer Notes: Special notes for future developers. This may include areas for potential
improvement, unit testing hints, etc.
Revision History
All program changes should be documented in the "Revision History" section of the comment block. The
revision history entry should contain a header line that contains the date, programmer name, and
reference (SR number, project name, etc.). Comment the changed lines of code with the same reference
number. The reference number therefore links the revision history entry with the related source code
changes. After the changes have been in production for a couple of months it is suggested that
superfluous comments be removed from the source code in order to maintain the readability of the
program.
*If a lot of program changes are being implemented it may be more efficient to avoid commenting every
changed line with a reference number. Comment lines can instead be added to mark the beginning and
end of changed sections. For extensive changes that make even that difficult, the reference column can
indicate to see the version management to identify the changes.
Following the header line you should describe the purpose of the code changes, i.e. why the code was
changed. For readability it helps if you indent these lines of text by one or two characters. Don't be afraid
to enter too much information! What you consider as common knowledge today may be forgotten in just
a few months. Help us remember. Include these things:
Why the code was changed

The problem you were trying to prevent or fix, and how the code changes accomplish that
The reason why certain functionality was added or removed from the program
Examples
Changes or additions to any external dependencies
What site or business unit requested the change
Special procedure for modularized program
Sometimes changes are made to subroutines to modify the behavior of a module pool (transaction) or
function module. These subroutines are usually contained in form includes. If the subroutine changes
are not also documented at the top of the main program, it can be difficult to ascertain where the relevant
changes were made. Therefore, you should create two revision history entries in this case. One in the
form include that contains the subroutine, and one at the top of the main program - indicating the
subroutine and include program that was modified. In this way the main program contains a complete
reference list of all the modifications made to its various includes.
General Comment Lines

These are helpful comments within the source code to help other programmers understand what the code
is, or is not, doing. Comment lines should be short and to the point. Obviously not every line of code
deserves to be documented, and you should not document obvious lines of code. Too many comments
can clutter a program making it difficult to read. Here are some guidelines that you can follow:
Document internal data fields, structures, table definitions, and parameters by describing what
they will be used for.
Document the contents of referenced message texts and text symbols. For example:
*Invalid Purchase Order Number for this
Sold-to Party
MESSAGE E046.
WRITE "Sold-to Party"(001).
MESSAGE E005. "Please enter a unit of
measure
Document complex or lengthy statements such as table joins, compound tests, compound
calculations, complex conditional processing, nested operations, etc.
Document lines or sections that were difficult to code, or where you had to refer to the help (the
reader will likely have the same problem).
Document, or better yet, avoid tricky code.
Document expected database access paths (table indexes, sequence of table joins) if they are
considered important.
Document the end of lengthy operations such as ENDIF, ENDLOOP, ENDFORM. For example:
ENDIF. "if quantity greater than
zero
ENDLOOP. "Loop at sales order items
ENDFORM. "validate input data
Document the purpose of external performs or function calls.

If the program can be broken down into logical steps then comment the beginning of each step
with a description of what that step is going to accomplish.
If the program performs logic based on certain values, especially literals (hard coded values),
then document what those values mean. If other values are not included for a specific reason
then document those too.
Frequently, data is being collected that will be processed later in the program. In this case it is
helpful to note how and when the data will be used. For example: "Select all company codes so
that later these can be compared with x in routine y".
If there is a specific reason why you did, or did not, code something a certain way, and there was
more than one option, document your thinking.
Any other relevant thoughts, concerns, assumptions, or intentions that are not self evident.
Form Documentation
Subroutines should be created for logical blocks of code when they are; performed more than once, or
are lengthy and would aid readability. For the latter you should consider breaking the code down into
smaller manageable units since subroutines should generally be kept short (no more than a few pages)
so that their mechanics can be easily grasped. You should also avoid over modularization, i.e. creating
subroutines for very simple operations (unless they are duplicated extensively), or shor t routines that are
only called once (those tend to make program navigation more difficult). The goal is to strike a balance
between good program modularity and easy program navigation.
Form documentation consists of three parts:
1. A comment block that documents the functional purpose of the routine (what the routine is
accomplishing), as well as the meaning of all its parameters. Subroutines should have one
clearly defined purpose or task. The comment block should be coded directly above the
subroutine.
Note: Pretty Printer will automatically insert the basic structure of the comment block. You can also
create the form interface (if it does not already exist yet) by double clicking on the form name in the
PERFORM statement.
*---------------------------------------------------------------------*
* FORM name *
*---------------------------------------------------------------------*
* Functional Purpose *
*---------------------------------------------------------------------*
* --> Parameter x (Using documentation) *
* <-- Parameter y (Changing documentation) *
*---------------------------------------------------------------------*
1. A meaningful FORM name

2. A clear yet simple interface. The form interface defines what input data is required by the
subroutine, and what data may be changed by the subroutine. Therefore, you should:
Always create a form interface when the subroutine changes data
Pass input parameters as USING parameters and output parameters as CHANGING
parameters
Assign a type (or like) to all parameters - using the strictest description possible
Keep the number of parameters to a minimum. If you are using more than 7 parameters
you should consider a re-design.
Avoid referring to global data within the subroutine. Note, however, that you can avoid
changing global data within the subroutine by using the LOCAL keyword. You can also
create local data that is not initialized with each perform by using the STATIC keyword.
SAP Exits
Custom exit routines must include their own special comment block and revision history that appears
directly above the FORM. This is in addition to the comment block at the top of the include program.
When a form is first created (or later changed) a simple entry should be made in the modification history
comment block at the top of the include program. Such as:
* ---------- ---------------------- ------------------------ *
* 01/01/00 Eric Dawley 123456
* Created form ZZ_CHECK_MATNR
* 01/01/00 Eric Dawley 456789
* Modified form ZZ_DEFAULT_ZZFIELD
This gives an overview of the modifications made to the various forms within the include program. The
detailed revision history entry should be created in the corresponding FORM comment block below.
*---------------------------------------------------------------------*
* FORM name *
*---------------------------------------------------------------------*
* Author Name : *
* Create Date : *
* Reference Number: *
* Specification Name: *
* SAP Exit : *
* FORM Purpose : *
* : *
*---------------------------------------------------------------------*
* --> Parameter x (using documentation) *
* <-- Parameter y (changing documentation) *
*---------------------------------------------------------------------*
* Revision History *
* User-ID
* ---------- ---------------------- ------------------------ *
* xx/xx/xx xxxxxxxxxxxxxxxxx xxxxxxxxxx *

* xxxxxxxxxxxxxxxxx *
*---------------------------------------------------------------------*
Reference Number: This should be the original service request number (or equivalent)
Specification Name: The repository file name of the specification that contains the exit routine
specification
SAP Exit: The name of the calling SAP userexit or function exit
FORM Purpose: This section should describe the overall functional purpose of the form, and how it
works, in concise terms. Also include the following items as appropriate:
- Why we had to create the code

- What business process does the code support?
- What problem are we trying to avoid?
- Examples
Additional guidelines for exit routines:
Declare all tables and global data in the top include userexit. Do not declare global data in a form
include outside of a form.
All custom global data names must be prefixed with the letters ZZ
All custom form names must begin with the letters ZZ
Only code PERFORM statements within the SAP exit routine. For function exits, the custom
code can be entered directly into the ZX include (within the function module) if the global interface
flag has not been set and passing the interface data would be cumbersome.
Minimize the usage of the system Literal table
Only modularize your routines when it is absolutely necessary, or consider implementing your
code in a function module instead
Do not use hard coded strings as MESSAGE variables
Programming Conventions
Readability of the source code can be improved dramatically by following certain standard programming
conventions and style guidelines as follows:
Type 1 (executable) programs should be arranged in the following generally accepted sequence:
1. Report statement
2. Table declarations
3. Data declarations
4. Data INCLUDES
5. Selection screen definition
6. Initialization
7. At selection-screen
8. Top-of-page, End-of-page
9. At line-selection, At user-command
10. Start-of-selection
11. End-of-selection
12. Forms
13. Form INCLUDES
Note: Top includes and form includes should not normally be created unless more than one program
needs the same data or forms, or it becomes necessary to break the program down into includes for
readability and maintainability, i.e. for very large programs.
Line up your code

Use Pretty Printer
Line up DATA statements to permit easier readability - Indent sub-structure elements two spaces
Do not use Pretty Printer on standard SAP delivered programs
The Insert Statement function usually inserts aligned code
Split and indent lengthy statements into multiple lines. Example for SELECT:
SELECT fields
INTO itab
FROM dtab
WHERE f1 = v1
AND f2 = v2.
Use white space to separate blocks of code

Avoid putting more than one command on a single line (helps debug too)
Avoid deeply nested operations
Delete dead code that is never accessed
To aid readability, consider deleting superfluous lines of code that have been commented out
after they have been in production 1-2 months keep those considered important
Delete, or comment out, TABLE and DATA definitions that are no longer used in the program
Create data fields with meaningful names
Use the following naming conventions for specific data types. Most of all, be consistent.
Data Names
Data Type Prefix Suffix Example
Internal tables declared T, X, Y or Z Type DDIC XVBAK LIKE VBAK

like a DDIC structure structure
Other internal tables T, T_ Meaningful name T_ITEMS
RANGES R_ For DDIC field R_VKORG FOR VKORG
CONSTANTS C_ or
CONST_
SELECT-OPTIONS S_ For DDIC field S_KUNNR FOR VBAK-KUNNR
PARAMETERS P_ Type DDIC field P_MATNR LIKE MARA-MATNR

PARAMETERS - CB_ AS CHECKBOX CB_DOWN AS CHECKBOX
Check box
PARAMETERS - RB_ RADIOBUTTON RB_NORM RADIOBUTTON

Radio Button GROUP xxxx GROUP rad1
Global data fields G_ [Type DDIC field] G_COUNT TYPE I
Local fields you L_ [Type DDIC field] L_BELNR LIKE BKPF-BELNR

declare with DATA in a
FORM
Field Symbol FS_ TYPE ANY FIELD-SYMBOLS: <fs_1> TYPE

ANY
Field Group FG_ [Type DDIC field] FG_VBAK
TYPES TY_ [Type DDIC field] TY_VBAK
Import or using fields I_, P_ or Same as passed US_AUART

US_ field
Export or changing E_, P_ or Same as passed CH_SPART

fields CH_ field
Other generally W_, WA, [Type DDIC field] WA_NETPR LIKE VBAP-NETPR
accepted prefixes for TEMP, etc.
Global and Local
DATA work area fields
Part 2 On-Line Program Documentation

As code changes are made to the source code, the program documentation must also be maintained.
Program documentation is intended to describe, in detail, the functional purpose of the program, how to
execute it, and how to interpret the output. Program documentation should be written in laymen's terms
avoiding technical descriptions (although technical descriptions can be provided in parentheses as
references).
The audience for this documentation may include:
End Users
Business or Functional Analysts
Support teams
Programmers
Since not everyone in the audience may be capable of reading ABAP source code, the program
documentation is usually their primary resource for understanding the program's purpose, requirements,
and output. Even if they know ABAP, program documentation can convey basic information about a
program quicker than by reading the source code.
The following section provides content guidelines for documentation within the template provided by SAP
in the documentation editor. You are free to add additional paragraph sections as appropriate.
Purpose
This section should describe:
The program's overall functional purpose in detail

How the program is used by the business, and how it fits in the overall business process
The overall processing logic of the program in laymen's terms, including:
- Processing limitations
- Significant conditional processing
- Hard coded values
- Design assumptions
- Exception handling
Prerequisites
Pre-requisites such as:

Related configuration and control table values
Data input sources or process triggers, e.g. database updates, input files,
screens
Dependencies or Integration with other programs
Authorization checking
Scheduling & automation requirements
Re-start handling procedures
Subsequent program processing
Features
Selection
How to use all of the available execution features:
- Select-options
- Parameters
- Performance expectations and hints
- Input suggestions and examples
Standard Variants
Describe the standard variants and their intended usage

Output
Print output
- Sort options
- Output field descriptions & Definition of calculated fields
- Control breaks and totaling
- Section definitions
- Available interactive functions
File output
- File path and names
- Format and contents
- Receiver
- Purpose
Database output
- Called transactions (or update functions, e.g. Direct Input, ALE, BAPI), including the
primary data used to create those transactions
- Batch input session names & processing requirements
- Direct tables updates
Miscellaneous
- Job log messages
- Usage of standard texts or layout sets
ABAP programmers must be familiar with, and adhere, to these program documentation standards.
Adherence to this standard is monitored at the regional level by the designated development and
transport approvers.
3.4 Programing standards
PROGRAMMING STANDARDS
This section contains a list of ABAP coding standards, as well as some efficiency standards. The
purpose of these standards is to:
Encourage consistent practices among programmers: Programs coded by
different people should follow standard coding conventions.
Provide internal documentation: Programs should be documented to the extent
that another programmer could follow the logic of the code.
Improve readability: Programs should follow a format that makes the code
easy to read.
2.0.General Rules
Standard:
2.0.1. ABAP programs that update master and transactional data MUST
ALWAYS use SAP transaction codes (where transaction codes are
available) by utilizing BDC or call transaction utilities. The only
exception to this would be the use of a BAPI or "direct input" program
provided by SAP. These methods ensure that logical units of work,
rollback, locking operations and edits are performed. SAP-supplied tables
MUST NEVER be updated directly by custom programs.
2.0.2. ABAP programs MUST NEVER be used to update configuration tables.
2.0.3. SAP-delivered ABAP programs, Dynpros, SAP transactions and Batch
programs should never be changed without the approval of the
Development Team Leader. SAP approval will also generally be required.
If it becomes necessary to modify one of these objects, then, if possible,
the object should be copied to a new name using SAP naming standards,
and modifications should be made to the copied object.
2.0.4. Before writing any code, make sure that no existing programs or function
modules, either custom or SAP-supplied, satisfy the coding requirements.
2.0.5. If custom coding is necessary, attempt to write the module so that it is re-
usable and can be stored in a central library. Function modules are an
example of this approach.
2.1. Coding Style
Standard:
2.1.1. When events (e.g. END-OF-SELECTION, TOP-OF-PAGE, etc.) are used

in the code, they should appear in the order in which they are generally
executed.
2.1.2. Skipped lines and indention should be used to promote clarity between
sections of code as well as between file definitions and declarations.
2.1.3. For ease of reading code, concatenate repetitive commands with a colon as
provided by SAP. All TYPEs, TOs, VALUEs, DEFAULTs, table names,
and comments should be aligned among themselves throughout the code,
For example.
WRITE: LFA1_LIFNR,
LFA1_NAME1,
LFA1_ORTO1.
2.1.4. Use subroutines and FORM paragraphs whenever possible to improve

readability and logic flow. If a block of code is executed more than once,
it should be placed in a subroutine at the bottom of the code.
2.1.5. FORM paragraphs should be placed after all non-subroutine code, after
the END-OF-SELECTION event. FORM paragraphs should be
positioned in the order in which they are called within the program.
2.1.6. Every logical division within the program should have descriptive
comments immediately prior to the actual code.
2.1.7. Each program should have a comment box before the REPORT
statement as shown below:
*&------------------------------------------------------------------------------------*
*& Program Name : Zxxxxxx *
*& Author : xxxxxx xxx , xxxxx xxxxx *
*& Creation Date : xx/xx/xxxx *
*& Program Type : Reports *
*& SAP Release : *
*& Requested by : *
*& Description : xxxxxxxxxx xx xxxxxx xxxxxxx xxxx xxxx xxxxx *
*& xxxx xx xxxxxxx xxxx xx xx xx xxxxxxxxx *
*& Transport No : xxxxxxxxxx *
*&-----------------------------------------------------------------------------------*
2.1.8. Every modification, no matter how insignificant, should be documented

with an additional comment box added to the program. This provides an
easy audit trail of the programs history, and also allows for comparison of
versions in different environments at a glance rather than via remote
comparisons. The modification comment box should look as follows:
*&---------------------------------------------------------------------*
*& REVISION LOG *
*& *
*& DATE : 5/06/98 *
*& AUTHOR : xxxxxx xxx *
*& DESCRIPTION : xxxxx xxxxx xxxxxxx xxxxxxxx xx xxxx *
*& xxxxxxxxx xxx xxx xxxxxxxx *
*&---------------------------------------------------------------------*
2.1.9. Comment all subroutines with their purpose. Comments should explain
the business reasons for the code in a particular section and what the code
in that section is accomplishing. Comments should not explain individual
ABAP commands. Allow the ABAP editor to generate the comment box,
by coding the "PERFORM <form>" statement and double-clicking on the
<form>. Be sure to document the input and output parameters for the
specific form in the comment box.
2.1.10. Dead Code should be removed from the program, i.e., the fields which are
never referenced and code which can never logically executed.
Guideline :
2.1.11. Keep programs to a reasonable length. Programs should be long enough so

that there is not an excessive amount of data being passed between two
related programs, but should be short enough so that the same program
does not perform many discrete functions.
2.1.12. Consider the use of INCLUDE programs for Data Declarations, PBO
Dynpro modules, PAI Dynpro modules, Subroutines, and Individual Event
Processing.
2.1.13. Do not use complicated arithmetic expression, avoid COMPUTE, ADD,
and other keyword whenever possible, e.g. using DATA = DATA + 1
instead of ADD 1 to DATA.
Tip :
2.1.14. The ABAP editor has a PP (Pretty Printer) command to indent specific
lines of code by 2 positions and add subroutine comments. Menu path:
program/pretty printer in ABAP Editor. However, since this command is
CPU intensive, its use should be kept to a minimum. Use it only after
making a series of changes for a new version of the program, rather than
after each individual change.
2.2. Report Standard
Standard :
2.2.1. The reports should be coded with "NO STANDARD PAGE-HEADING"

specified in the "REPORT" statement. Then, in the "TOP-OF-PAGE"
event, a function module should be CALLed for writing project standard
header.
2.2.2. Specify blank lines (for output) by using SKIP TO LINE <nn> or "SKIP
<n>, rather than multiple WRITE / lines.
2.2.3. For program parameters, use Selection Texts to specify literals that will
appear on the screen via editing Text Elements of the program. This will
enable the literal to be implemented in multiple languages.
2.2.4. Do not use hard-coded literals. Use Text Elements to handle literal text
that is printed on a report, the advantage is easier maintainability.
WRITE: / TEXT-001. writes error message
WRITE: / Error(001).
2.2.5. There should be no hard-coding of date formats in the programs, The date
format of the users default information (SU50) should be used to output
any date.
2.2.6. There will be no hard-coding of currency output formats in our programs.
The decimal notation of the users default information (SU50) should be
used to output any currency value.
2.2.7. The European standard paper size is A4 (210 x 297 mm) whereas the US
standard is Letter size (8.5 x 11 inches). A4 is a little bit longer and a little
bit narrower than Letter size paper. The reports should be designed so that
they will work on either paper size, so we dont end up creating two
versions of a report simply to accommodate the different dimensions.
This means we should design our reports to fit on the minimum dimension
of each, in Landscape orientation the report should be designed to fit
Letter length (11 inches) and A4 width (210 mm).
Tip :
2.2.8. Dates in ASCII interface files (flat files) should be of the form
CCYYMMDD. This is reasonably unambiguous, makes sure we have no
year 2000 issue, and allows the file to be sorted on the date. When creating
a BDC session the ABAP should use the user default date format when
formatting the record for the screen. We cant make assumptions about the
date format of the user executing the program.
2.2.9. SAP currently does not support multiple time zones, so the time used in
the system is the time that the database server is set to. The system field
SY-TZONE indicates the time difference in seconds to GMT time.
2.3. Data Definition
Standard :
2.3.1. Use CONSTANTS for variables whose values do not change (Static
Data).
2.3.2. Define CONSTANTS rather than Text Elements for these non-output hard
code literals in the program. For example:
CONSTANTS : C_ONE_THOUSAND TYPE I VALUE 1000,
C_TRUE TYPE C VALUE TRUE,
C_FALSE TYPE C VALUE FALSE.
2.3.3. For each field, include a comment (after the field) describing the use or
purpose of the field.
2.3.4. LIKE verb is used while declaring the fields whenever feasible, e.g. when
assigning internal fields that are to hold values from databases, use the
LIKE option to ensure that the variables have identical characteristics.
2.3.5. Data length and data type are not left as default.
2.3.6. Only one table shall be listed on any one line of the program, and the table
description should be added as the end of line comment.
Example:
TABLES: T001, Company codes
T100, Messages
TAPLT. Program applications
TDCT, Dialog Modules
2.3.7. INCLUDES are created for data declarations and any data structures that
will be used in more than one ABAP program.
Guideline :
2.3.8. Variable names should be descriptive, meaningful and understandable.

2.3.9. Do not use "field symbols" unless there is no simpler method available. If
"field symbols" are used, their use must be fully explained in program
comments at the place were the symbol is defined and used.
2.3.10. Global variables are minimized by declaring local variables or by passing
parameters while creating internal subroutines.
2.3.11. Specify the type of field-symbols and formal parameters in source code,
the ABAP compiler can better optimize the code.
Field-Symbol without type Typed Field-Symbol
FIELD-SYMBOLS: <F>. FIELD-SYMBOLS: <I> TYPE I.
ASSIGN I1 TO <F>. ASSIGN I1 TO <I>.
I2 = <F>. I2 = <I>.
I3 = <F>. I3 = <I>.
I4 = <F>. I4 = <I>.
2.4. Online Standard
Standard :
2.4.1. Always define the field with a Format = OK as OK_CODE. This field is
used to validate the OK Event.
2.4.2. Define all global data in the main program (TOP) module instead of the
PBO/PAI.
2.4.3. To handle a lock entry failure, invoke an error message (type E) to prevent
any further progress but leaving the user on the current screen. The user
can then take an alternative action or continue to try to lock the object. To
minimize the impact on users, limit retries.
2.4.4. When activating buttons or boxes, activate the associated text as well. This
enables the user to click on either the button/box or the text.
2.4.5. Do not use AT PFnn in programs. Instead use the function name so that
any method of invoking the function will have the same effect as the use
of the PF-Key.
Guideline :
2.4.6. Use Data Dictionary names (short, medium, long) for field text on screens
where applicable.
2.5. Batch Program / Interface Standards
Standard :
2.5.1. Document program variant(s) if a program needs to run with special

parameters.
2.5.2. An ABAP program that reads from or writes to a sequential dataset should
always OPEN the dataset before the read/write operation, and after file
processing it should CLOSE the file. Although these statements are not
mandatory, it is good practice to include them. Also, without an OPEN
DATASET statement, a file will always be opened in BINARY mode.
This may not be the mode required!
Guideline :
2.5.3. Message statements executed in batch programs are output to the txn
SM37 "Job Log". "Success" messages (type 'S') should be used
generously to provide an audit trail of the program's execution.
2.5.4. Define Logic filename as parameters
See the following example:
DATA: G_PDSNME LIKE FILENAME-FILEEXTERN. "Physical Dataset
Name.
DATA: BEGIN OF T_TAB OCCURS ...

END OF T_TAB.
PARAMETERS: P_LDSNME LIKE FILENAME-FILEINTERN "Logical Dataset Name
DEFAULT 'CUSTOMER_FILE'.
AT SELECTION-SCREEN.
CALL FUNCTION 'FILE_GET_NAME'
EXPORTING
LOGICAL_FILENAME = P_LDSNME
IMPORTING
FILE_NAME = G_PDSNAME
EXCEPTIONS
FILE_NOT_FOUND = 01.
IF SY-SUBRC <> 0.
*-------No physical filename can be determined for &
MESSAGE E016(MG)WITH P_LDSNME.
ENDIF.
START-OF-SELECTION.
OPEN DATASET G_PDSNME FOR OUTPUT IN TEXT MODE.
IF SY-SUBRC <> 0.
* Insert error processing here.
ENDIF.
TRANSFER T_TAB TO G_PDSNME.

CLOSE DATASET G_PDSNAME.
2.6. Message
Standard :
2.6.1. Do not use SAP-supplied default message IDs, as these IDs can change
from release to release. Instead, copy these messages to customer
message IDs.
Guideline :
2.6.2. Messages are included at appropriate places to indicate illegal operation,

no authorization, no data found, etc.
2.7. Program Logic
Standard :
2.7.1. A program should test the system return code field (SY-SUBRC) after any
statements that could potentially change its value unless the outcome of
the statement is not important for subsequent processing. The return code
should always be checked after any database table read/update statements.
Guideline :
2.7.2. CHECK is used instead of IF/ENDIF whenever possible

2.7.3. When Coding IF, nest true testing conditions, so that the outer conditions
are most frequently true.
2.7.4. CASE statements are clearer for legibility and a little faster than IF-
constructions. When testing fields equal to something one can use either
the nested IF or the CASE statement. CASE statements are clearer and
after about five nested Ifs the performance of the CASE is more efficient.
2.7.5. WHILE is used instead of a DO+EXIT-construction, because WHILE is
easier to understand and faster to execute.
Do While
I1 = 0. I1 = 0.
DO. WHILE C1A = SPACE.
IF C1A NE SPACE. EXIT. ENDIF. ADD 1 TO I1.
ADD 1 TO I1. IF I1 GT 10. C1A = 'X'. ENDIF.
IF I1 GT 10. C1A = 'X'. ENDIF. ENDWHILE.
ENDDO.
Runtime Measure(in microsec): 5 Runtime Measure(in microsec): 3
Notes: The runtimes depicted in this manual are just sample measurement, they are measured
on multi-processor environment, they are, however, not runtime measurement
benchmarks.
2.7.6. LOOP . WHERE is faster than LOOP/CHECK because LOOP .

WHERE evaluates the specific condition internally.
Loop/Check Loop/Where
LOOP AT ITAB. LOOP AT ITAB WHERE NAME1 = KVAL.
CHECK ITAB-NAME1 = KVAL. .
ENDLOOP. ENDLOOP.
Tip :
2.7.7. CHECK, EXIT, REJECT, STOP is used to suspend processing or skip

unnecessary processing.
2.7.8. Use PERFORM i OF statement when calling a certain routine based on a
given index, instead of using CASEWHEN/PERFORM, since the first
statement is fast to execute.
Case Perform i Of
* (I1 = 5 in this test) * (I1 = 5 in this test)
CASE I1. PERFORM I1 OF
WHEN 1. PERFORM PV1. PV1
WHEN 8. PERFORM PV8. PV8.
2.8. Data Access
Standard :
2.8.1. In a SELECT statement, only the fields that are needed are selected in the
order that they reside on the database, thus network load is considerably
less. The number of fields can be restricted in two ways using a field list in
the SELECT clause of the statement or by using a view defined in ABAP
Dictionary. The usage of view has the advantage of better reusability.
Select * Select with select list
SELECT * FROM DD01L SELECT DOMNAME FROM DD01L
WHERE DOMNAME LIKE 'CHAR%' INTO DD01L-DOMNAME
AND AS4LOCAL = 'A'. WHERE DOMNAME LIKE 'CHAR%'
ENDSELECT. AND AS4LOCAL = 'A'.
ENDSELECT.
Runtime Measure(in microsec): 42,880 Runtime Measure(in microsec): 11,402
2.8.2. SELECT SINGLE is used instead of SELECT-ENDSELECT loop if full

primary key is known. Otherwise, use Up to 1 Rows. SELECT SINGLE
requires one communication with the database system.
Select Endselect Select Single
SELECT * FROM SCARR SELECT SINGLE * FROM SCARR
WHERE CARRID = 'LH'. WHERE CARRID = 'LH'.
ENDSELECT.
2.8.3. Always specify the conditions in the WHERE-clause instead of checking

them with check-statements, The database system can then use an index (if
possible) and the network load is considerably less. You should not check
the conditions with the CHECK statement because the contents of the
whole table must be read from the database files into DBMS cache and
transferred over the network. If the conditions are specified in the where
clause DBMS reads exactly the needed data.
Select + Check statement Select with Where condition
SELECT * FROM SBOOK. SELECT * FROM SBOOK
CHECK: SBOOK-CARRID = 'LH' AND WHERE CARRID = 'LH' AND
SBOOK-CONNID = '0400'. CONNID = '0400'.
ENDSELECT. ENDSELECT.
2.8.4. Use a select list with aggregate functions instead of checking and
computing, when try to find the maximum, minimum, sum and average
value or the count of a database column, thus network load is considerably
less.
Select Where + Check Select using an aggregate function
C4A = '000'. SELECT MAX( MSGNR ) FROM T100 INTO C4A
SELECT * FROM T100 WHERE SPRSL = 'D' AND
WHERE SPRSL = 'D' AND ARBGB = '00'.
ARBGB = '00'.
CHECK: T100-MSGNR > C4A.
C4A = T100-MSGNR.
ENDSELECT.
Guideline :
2.8.5. Always select into an internal table, except when the table will be very
large (i.e., when the internal tables will be greater than 500,000 records).
Use Up to N Rows when the number of records needed is known
Select + Append statement Select Into Table
REFRESH X006. SELECT * FROM T006 INTO TABLE

X006.
SELECT * FROM T006 INTO

X006.
APPEND X006.
ENDSELECT.
Runtime Measure(in Runtime Measure(in microsec):

microsec): 2,888 920
2.8.6. Whenever possible, use array operations instead of single-row operations

to modify your database tables. The frequent communication between the
application program and database system produces considerable overhead.
Single-line Insert Array Insert
LOOP AT TAB. INSERT CUSTOMERS FROM TABLE
TAB.
INSERT INTO CUSTOMERS

VALUES TAB.
ENDLOOP.
Runtime Measure(in Runtime Measure(in microsec): 12

microsec): 12
2.8.7. ORDER BY statement is used in SELECT only if it can use an index else
sorting is effective by reading into an internal table and use the SORT
statement in the program.
Order by with index Order by without index
SELECT * FROM SPFLI ORDER BY SELECT * FROM SPFLI ORDER BY
PRIMARY KEY. AIRPFROM AIRPTO.
ENDSELECT.
Runtime Measure(in microsec): Runtime Measure(in microsec):

3,138 3,959
2.8.8. Use logical database as appropriate. Logical database implicitly executes

authorization checking for data access, but even if you just access one
table, you will still need to access all the tables above the current hierarchy
level in logical database, which creates data access inefficiency.
2.8.9. Do not use Nested Select. Use 'Inner Join' and/or 'For all Entries' instead.
'For all Entries' is used over 'Loop at itab / Select / Endloop
2.8.10. Inner Joins: In a 1:N relationship between two tables, the table with the 1
relationship is the preferred driving table. The 1 relationship is the
smallest data set as defined by the header/item relationship and/or the
smallest data set as defined by the where clause restrictions.
Tip :
2.8.11. No complex WHERE clauses, since complex where clauses are poison for
the statement optimizer in any database system.
2.8.12. For all frequently used SELECT statements, try to use an index. You
always use an index if you specify (a generic part of) the index fields
concatenated with logical ANDs in the Select statement's WHERE clause..
Select without index Select with primary index support
support
SELECT * FROM T100 SELECT * FROM T002.
WHERE ARBGB = '00' SELECT * FROM T100
AND MSGNR = '999'. WHERE SPRSL = T002-SPRAS
ENDSELECT. AND ARBGB = '00'
AND MSGNR = '999'.
ENDSELECT.
ENDSELECT.

microsec): 1,959,019 28,434
2.8.13. Use SAP buffering for accessing frequently used, read-only tables,
network load can be considerably less. However, in case of retrieving
latest data in multi-user environment, you may need to bypass the buffer.
Select without buffer Select with buffer support
support
SELECT SINGLE * FROM T100 SELECT SINGLE * FROM T100
BYPASSING BUFFER WHERE SPRSL = 'D'
WHERE SPRSL = 'D' AND ARBGB = '00'
AND ARBGB = '00' AND MSGNR = '999'.
AND MSGNR = '999'.
Runtime Measure(in Runtime Measure(in microsec): 87

microsec): 775
2.8.14. Whenever possible, use column updates instead of single-row updates to

update your database tables. Network load can then be considerably less.
Single-line updates Column update
SELECT * FROM SFLIGHT. UPDATE SFLIGHT
SFLIGHT-SEATSOCC = SET SEATSOCC = SEATSOCC - 1.
SFLIGHT-SEATSOCC - 1.
UPDATE SFLIGHT.
ENDSELECT.

microsec): 6,054 1,517
2.9. Internal Table
Standard :
2.9.1. MOVE used instead of MOVE-CORRESPONDING for efficiency

purpose, MOVE-CORRESPONDING is used only when two tables have
same field structure.
2.9.2. Specify the sort fields on the sort statement, not leave the fields as default,
the more restrictively you specify the sort key, the faster the program will
run.
Sort internal table with default Sort with sort key specified
sort key explicitly
* Table TAB is filled with 100 * Table TAB is filled with 100
entries of 500 bytes each entries of 500 bytes each
SORT TAB. SORT TAB BY K.

503 357
Guideline :
2.9.3. Header line of internal table is cleared before moving data into it.
2.9.4. Internal table is defined with OCCURS 0 if the maximum size of the
table is potentially >=8K. If the data to be read is estimated to be under
8K, then specifying the number of lines in the OCCURS statement (e.g.
itab1 occurs 10) is effective.
2.9.5. LOOP ... WHERE is faster than LOOP/CHECK because LOOP ...
WHERE evaluates the specified condition internally. The performance
can be further enhanced if LOOP ... WHERE is combined with FROM i1
and/or TO i2, if possible.
Key access with LOOP/CHECK Key access with LOOP
WHERE
entries of 500 bytes each, entries of 500 bytes each,
* 5 entries of which match the * 5 entries of which match the

key condition key condition
LOOP AT TAB. LOOP AT TAB WHERE K = KVAL.
CHECK TAB-K = KVAL. " ...
" ... ENDLOOP.
ENDLOOP.

610 182
Tip :
2.9.6. Use explicit work area operations rather than header line where
appropriate, since header line will have unnecessary MOVEs involved.
Table operation via header Table operation via explicit
line work area
* The line width of table TAB is * The line width of table TAB
500 bytes is 500 bytes
TAB = TAB_WA. APPEND TAB_WA TO TAB.
APPEND TAB.
Runtime Measure(in microsec): 4 Runtime Measure(in microsec):

3
2.9.7. Use one-step approach READ/INSERT. If the amount of data is small (<
20 entries), or if users need read-access to the internal table while it is
being filled, however, if the data amount is larger and you need read-
access only to the completely-filled table, the two-step algorithm
APPEND/SORT or three-step approach APPEND/SORT/DELETE
DUPLICATE(for tables without duplicates) is preferable.
One-step approach: Two-step approach: APPEND,
READ/INSERT then SORT
* TAB_DEST is filled with 1000 * TAB_DEST is filled with 1000

entries entries
REFRESH TAB_DEST. REFRESH TAB_DEST.
LOOP AT TAB_SRC. LOOP AT TAB_SRC.
READ TABLE TAB_DEST WITH APPEND TAB_SRC TO

TAB_DEST.
KEY K = TAB_SRC-K BINARY ENDLOOP.

SEARCH.
INSERT TAB_SRC INTO SORT TAB_DEST BY K.

TAB_DEST INDEX SY-TABIX.
ENDLOOP.

41,760 11,557
One-step approach Three-steps: copy, sort, delete

duplicates
* TAB_SRC contains 1000 * TAB_SRC contains 1000

entries, of which 500 are entries, 500 are different
different
REFRESH TAB_DEST. REFRESH TAB_DEST.
READ TABLE TAB_DEST WITH APPEND TAB_SRC TO

TAB_DEST.

SEARCH.
IF SY-SUBRC <> 0. SORT TAB_DEST BY K.
INSERT TAB_SRC INTO DELETE ADJACENT DUPLICATES

TAB_DEST FROM
INDEX SY-TABIX. TAB_DEST COMPARING K.
ENDIF.
ENDLOOP.
22,663 14,888
2.9.8. COLLECT is used instead of READ BINARY/INSERT If number of

entries greater than 1000. READ BINARY runs in O( log2( n ) ) time, and
the internal table's index must be adjusted with each INSERT , however,
COLLECT uses a hash algorithm and is therefore independent of the
number of entries and does not need to maintain a table index. If the
amount of data is small, the READ/INSERT approach isn't bad, but for
large amounts of data (> 1000), COLLECT is much faster.
COLLECT semantics using READ Collect via COLLECT statement
BINARY
* Table TAB_SRC is filled with * Table TAB_SRC is filled with

10,000 entries, 10,000 entries,
* 5,000 of which have different * 5,000 of which have different

keys keys
READ TABLE TAB_DEST WITH COLLECT TAB_SRC INTO

TAB_DEST.

SEARCH.
IF SY-SUBRC = 0. SORT TAB_DEST BY K.
ADD: TAB_SRC-VAL1 TO
TAB_DEST-VAL1,
TAB_SRC-VAL2 TO
TAB_DEST-VAL2.
MODIFY TAB_DEST INDEX SY-

TABIX.
ELSE.
INSERT TAB_SRC INTO

TAB_DEST INDEX SY-TABIX.
ENDIF.
ENDLOOP.

709,306 116,422
2.9.9. COLLECT is not used with the combination of APPEND, INSERT and/or
MODIFY when filling in the internal table. If COLLECT is mixed with
the other statements, it cannot use its hash algorithm. In this case,
COLLECT resorts to a normal linear search, which is dramatically slower.
2.9.10. Using BINARY SEARCH instead of linear search when internal table has
more than 20 entries. If TAB has n entries, linear search runs in O( n )
time, whereas binary search takes only O( log2( n ) ). And also when
reading a single record in an internal table, the READ TABLE WITH
KEY is not a direct READ. Therefore, SORT the table and use READ
TABLE WITH KEY BINARY SEARCH.
Linear search of an internal Binary search of an internal
table table
entries entries of 100 bytes each
* The READ ends with SY- * The READ ends with SY-
SUBRC=4 SUBRC=4
READ TABLE TAB WITH KEY K = READ TABLE TAB WITH KEY K =
'X'. 'X' BINARY SEARCH.

875 11
2.9.11. Specify the key fields for read access explicitly, use READ TABLE
WITH KEY k = X instead of READ TABLE WITH KEY. Otherwise,
the key fields have to be computed dynamically by the run time system.
Access via implicit default key Access via key specified
explicitly

* The READ ends with SY- * The READ ends with SY-
SUBRC=4 SUBRC=4
MOVE SPACE TO TAB. READ TABLE TAB WITH KEY K =

'X' BINARY SEARCH.
TAB-K = 'X'.
READ TABLE TAB BINARY SEARCH.

15 7
2.9.12. Internal tables can be compared, copied in logical expressions just like
other data objects. Two internal tables are equal if
- they have the same number of lines and
- each pair of corresponding lines is equal.
If an internal table itab has a header line, the table itself is accessed by
itab[].
Pedestrian way to compare Let the kernel to do the work
internal tables
* Tables TAB1 & TAB2 are each * Tables TAB1 & TAB2 are each
filled with 100 entries filled with 100 entries
* of 100 Bytes each. * of 100 Bytes each.
DESCRIBE TABLE: TAB1 LINES L1, IF TAB1[] = TAB2[].
TAB2 LINES L2. " ...
ENDIF.
IF L1 <> L2.
TAB_DIFFERENT = 'X'.
ELSE.
TAB_DIFFERENT = SPACE.
LOOP AT TAB1.
READ TABLE TAB2 INDEX SY-

TABIX.
IF TAB1 <> TAB2.
TAB_DIFFERENT = 'X'. EXIT.
ENDIF.
ENDLOOP.
ENDIF.
IF TAB_DIFFERENT = SPACE.
" ...
ENDIF.

741 152
2.9.13. Use parallel cursor instead of join two tables or nested loop. If TAB1 has
n1 entries and TAB2 has n2 entries, the time needed for joining TAB1 and
TAB2 with the straightforward algorithm is O( n1 * log2( n2 ) ), nested
loop is O( n1 * n2 ), whereas the parallel cursor approach takes only O( n1
+ n2 ) time. Binary search is used when parallel cursor is not feasible and
the number of entries in the internal table is greater than 20.
Nave join: loop tab1, read tab2 More sophisticated: use
with key parallel cursor
* Table TAB1 is filled with 1000 * Table TAB1 is filled with 1000
* Table TAB2 is filled with 300 * Table TAB2 is filled with 300
* Table TAB2 is assumed to be * Tables TAB1 & TAB2 to be

sorted by K in ascending sorted by K ascending
* order
I2 = 1.
LOOP AT TAB1. LOOP AT TAB1.
READ TABLE TAB2 WITH KEY READ TABLE TAB2 INDEX I2.
K = TAB1-K BINARY SEARCH. IF SY-SUBRC <> 0. EXIT. ENDIF.
IF SY-SUBRC = 0. IF TAB2-K = TAB1-K.
" ... " ...
ENDIF. ADD 1 TO I2.
ENDLOOP. ENDIF.
ENDLOOP.

16,723 6,228
Straight forward nested loop More sophisticated loop:

parallel cursor
* Table TAB1 is filled with 100 * TAB1 is filled with 100 entries
entries of 100 bytes each of 100 bytes each
* Table TAB2 is filled with 10 * * TAB2 is filled with 10 * 100 =
100 = 1000 entries of 1000 entries of 100 bytes each
* 100 bytes each * TAB1 & TAB2 assumed to be

sorted by K in ascending order
LOOP AT TAB1. I2 = 1.
LOOP AT TAB2 WHERE K = TAB1- LOOP AT TAB1.

K.
LOOP AT TAB2 FROM I2.
ENDLOOP. IF TAB2-K <> TAB1-K.
ENDLOOP. I2 = SY-TABIX.
EXIT.
ENDIF.
ENDLOOP.
ENDLOOP.

180,472 8,839
2.9.14. Use the MODIFY variant MODIFY itab ... TRANSPORTING f1 f2 ...
for single line, and MODIFY itab ... TRANSPORTING f1 f2 ... WHERE
condition for a set of line, to accelerate the updating of internal table. The
longer the table line is, the larger the speed-up is. The effect increases for
tables with complex structured line types.
Modifying all components of Modifying selected
single line components only
entries of 500 bytes each. entries of 500 bytes each.
* Only the 8 bytes of the * Only the 8 bytes of the

component DATE are modified. component DATE are modified.
LOOP AT TAB. WA-DATE = SY-DATUM.
TAB-DATE = SY-DATUM. LOOP AT TAB.

MODIFY TAB. MODIFY TAB FROM WA
TRANSPORTING DATE.
ENDLOOP. ENDLOOP.
Runtime Measure(in microsec): Runtime Measure(in

56,642 microsec): 53,849
Modifying all components of Modifying selected

lines components only
entries. A line has two entries. A line has two
* components, a FLAG of typ C * components, a FLAG of typ C

and an integer table and an integer table
* INTTAB with 20 entries each. * INTTAB with 20 entries each.
* The Flag is switched on for all * The Flag is switched on for all
100 lines. 100 lines.
LOOP AT TAB. TAB-FLAG = 'X'.
IF TAB-FLAG IS INITIAL. MODIFY TAB TRANSPORTING

FLAG
TAB-FLAG = 'X'. WHERE FLAG IS INITIAL.
ENDIF.
MODIFY TAB.
ENDLOOP.
Runtime Measure(in microsec): Runtime Measure(in

6,190 microsec): 235
2.9.15. Use APPEND LINES OF itab1 TO itab2 and INSERT LINES OF itab1
INTO itab2 INDEX idx instead of APPEND and INSERT. And thus the
task of appending and insert a table to another table can be transferred to
the kernel.
Pedestrian way to append a Let the kernel to do the work
table
* Table TAB_SRC and TAB_DEST * Table TAB_SRC and TAB_DEST

are both filled with 500 are both filled with 500
* entries of 100 bytes each. * entries of 100 bytes each.

TAB_SRC is appended line by TAB_SRC is appended in a
* line to TAB_DEST. * single step to TAB_DEST.
LOOP AT TAB_SRC. APPEND LINES OF TAB_SRC TO

TAB_DEST.
APPEND TAB_SRC TO TAB_DEST.
ENDLOOP.

3,716 791
Pedestrian way to insert a table Let the kernel to do the work

* Table TAB_SRC and TAB_DEST * Table TAB_SRC and TAB_DEST

are both filled with 500 are both filled with 500
* entries of 100 bytes each. * entries of 100 bytes each.

TAB_SRC is inserted line by TAB_SRC is inserted in a
* line to TAB_DEST at index IDX. * single step to TAB_DEST at

index IDX.
IDX = 250. IDX = 250.
LOOP AT TAB_SRC. INSERT LINES OF TAB_SRC INTO
INSERT TAB_SRC INTO TAB_DEST TAB_DEST INDEX IDX.

INDEX IDX.
ADD 1 TO IDX.
ENDLOOP.

16,121 845
2.9.16. Use DELETE ADJACENT DUPLICATES / DELETE itab FROM ... TO

... / DELETE itab [FROM ...] [TO ...] WHERE ... instead of DELETE, to
transfer the task of deleting entries to the kernel.
Pedestrian way to delete Let the kernel to do the work
duplicates
* Table TAB_DEST is filled with * Table TAB_DEST is filled with

1000 entries of 100 bytes 1000 entries of 100 bytes
* each and contains 500 pairs of * each and contains 500 pairs of
duplicates duplicates
READ TABLE TAB_DEST INDEX 1 DELETE ADJACENT DUPLICATES
INTO FROM
PREV_LINE. TAB_DEST COMPARING K.
LOOP AT TAB_DEST FROM 2.
IF TAB_DEST = PREV_LINE.
DELETE TAB_DEST.
ELSE.
PREV_LINE = TAB_DEST.
ENDIF.
ENDLOOP.
Pedestrian way to delete a Let the kernel to do the work

sequence of lines

* each, and lines 450 to 550 are * each, and lines 450 to 550 are
to be deleted to be deleted
DO 101 TIMES. DELETE TAB_DEST FROM 450 TO

550.
DELETE TAB_DEST INDEX 450.
ENDDO.
Pedestrian way to delete a set Let the kernel to do the work

of lines

* each, 250 of which match the * each, 250 of which match the
WHERE condition WHERE condition
LOOP AT TAB_DEST WHERE K = DELETE TAB_DEST WHERE K =

KVAL. KVAL.
DELETE TAB_DEST.
ENDLOOP.
4,813 3,771
2.9.17. The performance gain when using DELETE itab WHERE ... instead of
LOOP AT itab WHERE ... DELETE itab. ENDLOOP. increases with the
number of entries the internal table contains and the number of lines to be
deleted.
2.9.18. If the data is processed only once, use a SELECT-ENDSELECT loop
instead of collecting data in an internal table with SELECT .INTO
TABLE because the Internal table handling takes up much more space.
SELECT * FROM <TABLE> SELECT * FROM <TABLE>
INTO TABLE <INT-TAB> ENDSELECT
LOOP AT <INT-TAB>.
..
ENDLOOP.
2.9.19. Internal tables can be copied by move just like any other data object. If the
table has a header line then the tables need to be referenced by square
brackets.
ITAB[] = ITAB1[]. LOOP AT ITAB INTO ITAB1.
APPEND ITAB1.
ENDLOOP.
2.9.20. Internal tables are freed when no longer needed (either by the free
command or a subroutine exit), especially when the tables are large or the
program is a batch program.
2.10. String Operation
Guideline :
2.10.1. Use the special operators CO, CA, CS, instead of programming the
operations yourself. If ABAP statements are executed per character on
long strings, CPU consumption can rise substantially.
DO-Loop with Field-Symbols Using the CA operator
ASSIGN CHA(1) TO <C>. IF CHA(200) CA '()'.
"...any actions
DO 200 TIMES. ENDIF.
IF <C> = '(' OR <C> = ')'.
"...any actions
EXIT.
ENDIF.
ASSIGN <C>+1 TO <C>.
ENDDO.

563 20
2.10.2. Use the CONCATENATE / SPLIT statement instead of programming a

string concatenation of your own.
Moving with offset Use of the CONCATERNATE
statement
" MOVE 'Jane' TO CMA. " MOVE 'Jane' TO CMA.
" MOVE 'Miller' TO CMB. " MOVE 'Miller' TO CMB.
" MOVE 'New York City' TO CMC. " MOVE 'New York City' TO
CMC.
I1 = STRLEN( CMA ). I2 = STRLEN( CONCATENATE

CMB ).
MOVE 'Mrs. ' TO CHA. 'Mrs.' CMA CMB 'from' CMC

INTO CHA
MOVE CMA TO CHA+5. I1 = I1 SEPARATED BY SPACE.

+ 6.
MOVE CMB TO CHA+I1. I1 = I1

+ I2 +
MOVE 'from ' TO CHA+I1. I1 = I1

+ 5.
MOVE CMC TO CHA+I1.

"Mrs. Jane Miller from New York "Mrs. Jane Miller from New
City" I York City" i
Use of SEARCH and MOVE with Use of the SPLIT statement

Offset
"CMA contains '(410)-45174- "CMA contains '(410)-45174-

66354312' and shall 66354312' and shall
"be split into AREA_CODE, "be splitted into AREA_CODE,
" TEL_NO1, " TEL_NO1,
" TEL_NO2. " TEL_NO2.
SEARCH CMA FOR '-'.
MOVE CMA(SY-FDPOS) TO
AREA_CODE.
I1 = SY-FDPOS + 2. SPLIT CMA AT '-' INTO

AREA_CODE
SEARCH CMA FOR '-' STARTING TEL_NO1

AT I1.
I1 = I1 - 1. TEL_NO2.
MOVE CMA+I1(SY-FDPOS) TO
TEL_NO1.
I1 = I1 + SY-FDPOS + 1.
MOVE CMA+I1 TO TEL_NO2.

27 4
2.10.3. If you want to delete the leading spaces in a string, use the ABAP
statement SHIFT...LEFT DELETING LEADING... . Other constructions
(with CN and SHIFT...BY SY-FDPOS PLACES, with CONDENSE if
possible, with CN and ASSIGN CLA+SY-FDPOS(LEN) ...) are not as
fast. In any case, avoid using SHIFT inside a WHILE-loop!
Shifting by SY-FDPOS places. Using SHIFT LEFT DELETING
LEADING
" CLA contains the string " CLA contains the string
"' "Editor line n'. "' "Editor line n'.
IF CLA CN SPACE. ENDIF.

SHIFT CLA BY SY-FDPOS PLACES SHIFT CLA LEFT DELETING
LEFT. LEADING SPACE.
Runtime Measure(in microsec): 5 Runtime Measure(in microsec):

3
Tip :
2.10.4. Some function modules for string manipulation have become obsolete and
should be replaced by ABAP statements or functions:
STRING_CONCATENATE... -> CONCATENATE,
STRING_SPLIT... -> SPLIT,
STRING_LENGTH -> strlen(),
STRING_CENTER -> WRITE...TO...CENTERED,
STRING_MOVE_RIGHT -> WRITE...TO...RIGHT-JUSTIFIED,
Use of a CONCATERNATE Use of the CONCATERNATE
function module statement
CALL FUNCTION CONCATENATE T100-ARBGB

'STRING_CONCATENATE_3'
EXPORTING T100-MSGNR
STRING1 = T100-ARBGB T100-TEXT INTO CLA.
STRING2 = T100-MSGNR
STRING3 = T100-TEXT
IMPORTING
STRING = CLA
EXCEPTIONS
TOO_SMALL = 01.

67 3
2.10.5. Use the strlen( ) function to restrict the DO loop to the relevant part of the
field, e.g. when determining a check-sum.
Get a check-sum with field Get a check-sum with strlen()
length
"DATA: BEGIN OF STR, LINE TYPE "DATA: BEGIN OF STR, LINE TYPE
X, END X, END
"OF STR, CHECK_SUM TYPE I. "OF STR, CHECK_SUM TYPE I.
"MOVE 'KALEBVPQDSCFG' TO "MOVE 'KALEBVPQDSCFG' TO

CLA. CLA.
I1 = STRLEN( CLA ).
DO 64 TIMES VARYING STR FROM DO I1 TIMES VARYING STR

CLA NEXT CLA+1. FROM CLA NEXT CLA+1.
CHECK STR NE SPACE. CHECK STR NE SPACE.
ADD STR-LINE TO CHECK_SUM. ADD STR-LINE TO CHECK_SUM.
ENDDO. ENDDO.
2.10.6. Use "CLEAR f WITH val" whenever you want to initialize a field with a
value different from the field's type-specific initial value.
Initializing with Initializing with CLEAR WITH
CLEAR/TRANSLATE val
* STRING is a 255 byte character * STRING is a 255 byte character

field field
CLEAR STRING. CLEAR STRING WITH '*'.
TRANSLATE STRING USING ' *'.

11 1
2.10. ALE Standards

2.10.1 Development Standard :
A separate ALE Technical Specification template has been designed to cover ALE
related interfaces template is contained within the ABAP Development
Standards
Interfaces may support more than one record type each record type will have
a corresponding IDOC
Each IDOC will map to one Message Type and there will be one Technical
Specification per message type per direction of interface.
There will be one test plan per Technical Specification i.e. by message type
There will be one Development Check-list per interface message type which will
be used to validate that interface is set-up correctly in each Instance/Client
interface will be operational (this will include Unit/String/Integration/volume
test clients as well as training and production)
All ALE Configuration set-ups for Client Dependent or Independent elements will
be documented in a configuration script, refer to SAP Template Design
standards for details.
All ALE non- configuration set-ups, for example ALE batch jobs, field level
change pointers will be registered in Non Transportable Objects document
2.10.2 Generic Principles :
The general principle is to utilise the main ALE standard scenarios i.e.
Message types and IDOC structures in order to reduce long term maintenance
and upgrade risks. In addition,
The preferred design is to minimise Routing and/or ALE Data Controls and allow
these requirements to be controlled by the Middleware HUB
The initiating source will not be identified at technical level within the ALE
layer/Idoc structure any source identification will be part of application data e.g.
plant. (However, if this is required for inter-system audit - i.e. the ability to map
the message sent from one system to the message received at the other, then a
standard procedure will be introduced for adding the required data to an IDOC).
Workflow will be used as primary method for error handling and reprocessing.
No batch file controls will be applied to ALE/Idoc interfaces within the ALE layer,
alternative business/compensating controls will need to be available or written.
2.10.3 ALE Scenarios :
There are three generic scenarios that apply to ALE interfaces, the
development effort associated to these scenarios is provided in Middleware
Services Agreement.
Standard Scenario:
Standard IDOC exists that matches required data elements
Standard Triggering technique will be used i.e. change pointer, output
determination
Standard Message Type available for IDOC
No modifications to the ABAP Repository objects will be required
Extended Scenario:
An extended scenario has the following characteristics
Additional data elements/segments need to be added to standard IDOC

structure
Additional controls need to be added to triggering method in order to meet
business requirements i.e. Real Time Master Data through Workflow
A copy of a standard message type has to be made available
ABAP repository objects i.e. function module or user exits need to be
modified in order to provide additional processing or populate new
data elements
Custom Scenario:
A custom scenario has the following characteristics
New basic IDOC and/or IDOC segments have to be created
A specific triggering mechanism has to be created i.e. selection screen built
ABAP repository objects have to be created in order to meet business
requirements.
2.10.4 ALE Technical Setups :

One Distribution model will be set-up for all ALE interfaces
One RFC destination will be set-up per instance of R/3 SAPLink connection
established to the Middleware
One ALE interface id will be created for each RFC destination for Middleware
connection. A User ID (ALEADMIN) is required for inbound communication
with the Link for R/3.
Each ALE interface id that is assigned to an RFC destination will be set
as Background id only with open profile to support all interfaces. The
profile will be determined from the definition of functional requirements.
2.10.5 ALE Testing :

ALE testing will incorporate all testing for configuration and ABAP
repository changes. Some limitations to testing will be applied.
Testing of interface triggers will only include the individual tests for that
interface, no related testing of triggering technique i.e. Interfaces triggering
Interfaces will be carried out.
Unit testing will be performed using the standard ALE test process, transaction
WE19 and ALE layer components this will not include connection to HUB. The
data transmission is asynchronous, and so the ALE unit starts at the point that
the IDOC reaches the ALE layer, and ends at the point at which the IDOC is
passed to the port for distribution.
String (often referred to as End to End tests) will include the connection to
HUB but will not include detailed functional testing of the sender/receiver
application
2.10.6 ALE Triggering :

ALE interfaces will cover Master and Transaction related data that require several
alternative triggering mechanisms. How to set-up and trigger these items are
defined in individual design documents.
Master Data:
Master data interfaces requiring Real Time data transfer will use Workflow and
change pointer methods to initiate transfer
Master data interfaces that require periodic processing will use the standard
SAP supplied Change Pointer program, RBDMIDOC, to initiate transfer
Adhoc requests for Individual, Mass or complete refresh of master data will be
performed manually using the standard SAP programs within the BALM
transaction
The decision on which technique to apply will be based upon the business
requirements or the need to spread volume over course of working day
Only fields identified as change fields will have active change pointers
set for transfer
Transaction Data:
If Output determination functionality is available within that business
transaction then this will be the preferred method for transfer
Where no output determination is available for real time or batch then a user
exit will be used to hard code entry into NAST table
Real time interfaces will use output determination with trigger immediately
profile to transfer the data
Output determination will also be used for batch transfer of transaction data
by running NAST transfer program (RSNASTED) in periodic batch on manually
on-line.
For custom Message types requiring specific application triggering then
a selection screen will be made available for initiating the interface
2.10.7 IDOC Structure :

The Generic principle is to minimise changes to standard IDOCS as this presents
maximum information extracted to the HUB.
No reductions will be performed for Master data IDOCS unless there is
significant redundancy or volume impacts.
Where business data requirements cannot be satisfied by the standard IDOC
then the IDOC will be extended to accommodate these additional fields see
extended scenario.
Where the business data requirements are only met by 60% of the standard
IDOC then a custom IDOC will be created custom scenario
Where possible any extension or customization of IDOC will use standard SAP
IDOC segments
Where an interface sends multiple record formats, Each message type and
subsequent IDOC will correspond to one individual Business data entity e.g.
Goods Movement
All change data being sent into SAP will need to have control flag on the
unchanged IDOC fields to ensure existing data is not overwritten control
flag is \. Further investigation will be carried out to ensure that this is fit
for purpose when IDOCs call BAPI methods.
2.10.8 ALE Processing :
Outbound Processing:
All errors in ALE will be sent to Workflow for investigation or reprocessing
ALE reprocessing program will be run periodically to re-send application data
in error
For real-time interfaces the Message types will be set to Process Immediately
within the partner profile
Packet sizes will be determined based upon performance and optimisation
analysis during testing, default will be set to 50
Periodic Processing will be assigned to a Server group to ensure that SAP work
processes are not degraded during interface execution
For custom IDOCS that require event triggering from within the standard
SAP transactions, a function module will be created otherwise, a separate
standalone program will be written
Inbound Processing:
All errors in ALE inbound processing will be sent to Workflow
ALE reprocessing program will run periodically to re-send application data in
error
For real time interfaces message types will be set to trigger immediately within
the partner profile
For batch processing of IDOCS the message type will be set to trigger by
background program, a separate batch job will be required for this interface
type
Server Groups will be utilised for batch inbound processing. In near-real time
processing the Link for R/3 can utilise logon groups which can be set up with
the same application servers as the application group. A separate document:
ALE Server Group Usage.doc details this process.
All relevant Parameter IDs must be cleared before a Call Transaction
command is issued. This ensures that redundant ABAP memory
(maintained from a previous interface run) is cleared. This is required
due to the logon characteristics of the Link for R/3.
For custom IDOCS there are alternative approaches for processing the data
into SAP, in order of preference the following techniques will be used
Standard ALE enabled call transaction

Single method BAPI function module
Custom develop a SAP call transaction with specific controls to handle
ALE integrity
Error Handling:
Workflow will be used as the mechanism to handle all ALE related errors
All messages will be sent to user inbox for re-processing
ALE reprocessing program will run periodically to process application
errors and IDOCS that have been edited
2.10.9 ALE Data Controls :

SAP provides a selection of Data Controls within the ALE Layer. The
Middleware will provide the majority of data controls therefore the ALE
processing will not perform any:
Segment Filtering of IDOCS
Mapping of values within IDOC
Conversion of data within IDOC
2.10.10 ALE Number Ranges :

Number ranges will be established for the following parameters with the ALE
layer:
Maintain Number Range for Ports
Maintain Number Range for IDOCS
Maintain Number Range for IDOC Types
Maintain Number Range for Change Pointers
2.10.11 Optimization and Performance :

The following design principles are taken from known best practices and industry
standard settings. These will be updated after full performance testing analysis is
performed.
A server group will be established for optimizing the outbound performance for
ALE interfaces
Only Interfaces that require immediate processing to ensure overall business
integrity will be set to process immediately.
OSS notes that relate to performance of ABAP code for ALE/IDOC programs will
be verified, any modifications will be reviewed with Basis team before making
the change
Periodic clean-up of change pointer table will be run to improve processing
Periodic archiving of IDOCS will be undertaken to improve processing
Periodic archiving of work items will be undertaken to improve ALE processing
A separate ALE application server will be required to ensure that parallel
processing will not degrade the SAP work processes
If access times on specific database fields are sub-optimal, separate
indexes will be created to improve processing speed
2.10.12 Archiving IDOCs / Work Items:

Archiving requirements are dependent upon the volume of IDOCS that will be
produced. Total volume of IDOC production will only be known after the
detailed interface design has taken completed. These design principles are based
upon the assumption that archiving will be required prior to any generic
Archiving policy.
IDOC:
IDOC Archiving will be performed on IDOC object
IDOC archiving will be undertaken monthly for those IDOCS which are more
than X weeks old
Separate archiving jobs will be maintained for Master and Transaction data
Only IDOCS with the following status codes will be archived
53 Application Document Posted
57 Test IDOC, error during application check
70 Original of an IDOC which was posted
Once archiving has been completed the IDOCS will be deleted
Work Items:
Work Items archiving will be performed on WORKITEM object
Work Item archiving will be undertaken at X monthly intervals for work items
that are more than XX weeks old
The standard ABAP programs supplied for ALE reporting will be preferred solution to
providing interface processing reports. Separate variants will be set-up for Master and
Transaction data for these standard reports. Active Consistency check will be performed
once weekly to ensure Distribution model and Partner profiles are aligned. Active
monitoring will be performed for each message type or group of message types values
for active monitoring will be not be defined until integration testing. Regular reporting
of all message types in error can be performed. See ALE Error Handling Approaches for
IDOC reporting (success or failure IDOCs).
APPENDIX A. - Skeleton Programs

The ABAP skeleton programs listed in this section show how various ABAP
programs should be structured. As far as possible and appropriate, their structure
should be followed.
ZSKELREP-- Basic ABAP List Report
ZSKELINT -- Interactive ABAP List Report
ZSKELOUT -- Create a Sequential Dataset
ZSKELBDC -- Read a Sequential Dataset and Create a Batch Input Session
ZSKELCLT -- CALL TRANSACTION USING Technique
Appendix A-1. Basic ABAP List Report
*&---------------------------------------------------------------------*
*& SAP Release : 4.6D *
*& Transport No : xxxxxxxxxx
*&---------------------------------------------------------------------*
*& Revision Log *
*& Date : x/xx/xx *
*& Author : xxxxxx xxx *
*& Description: xxxxx xxxxx xxxxxxx xxxxxxxx xx xxxx *
*&---------------------------------------------------------------------*
REPORT ZSKELREP.
no standard page heading
message-id xxxx
line-count xxxx
line-size xxxx.
*&---------------------------------------------------------------------*
*& TABLES:
*&---------------------------------------------------------------------*
tables:
*&---------------------------------------------------------------------*
*& CONSTANTS:
*&---------------------------------------------------------------------*
constants:
*&---------------------------------------------------------------------*
*& VARIABLES
*&---------------------------------------------------------------------*
data:
*&---------------------------------------------------------------------*
*& STRUCTURES
*&---------------------------------------------------------------------*
*&---------------------------------------------------------------------*
*& INTERNAL TABLES
*&---------------------------------------------------------------------*
*&---------------------------------------------------------------------*
*& SELECT-OPTIONS
*&---------------------------------------------------------------------*
select-options:
*&---------------------------------------------------------------------*
*& PAPAMETERS
*&---------------------------------------------------------------------*
parameters:
************************************************************************
* INITIALIZATION
************************************************************************
* Event which occurs before the selection screen is
* shown to the user. It happens only once and is
* ignored in background processing.
INITIALIZATION.
************************************************************************
* AT SELECTION-SCREEN
************************************************************************
* Event which occurs each time the user hits enter on * the selection screen. This event is ignored
in
* background processing.
************************************************************************
* TOP-OF-PAGE
************************************************************************
TOP-OF-PAGE.
************************************************************************
* END-OF-PAGE
************************************************************************
END-OF-PAGE.
************************************************************************
* START-OF-SELECTION
************************************************************************
START-OF-SELECTION.
* Definition of fields for FIELD-GROUP extract

INSERT: ... INTO HEADER.
GET ...
************************************************************************
* END-OF-SELECTION
************************************************************************
END-OF-SELECTION.
SORT ...
LOOP ...
AT FIRST
...
ENDAT.
AT NEW
...
ENDAT.
AT END OF
...
ENDAT.
AT LAST.
...
ENDAT.
ENDLOOP.
*&---------------------------------------------------------------------*
*& Form SUB_ INSERT_ENTRIES
*&---------------------------------------------------------------------*
* xxxxxxxxx xxxx xxxx xxx xxxxx xxxx xxxxx xxxx xx xxxxxx xxxx
*----------------------------------------------------------------------*
FORM SUB_INSERT_ENTRIES
...
ENDFORM.
APPENDIX A-2. Interactive ABAP List Report
*&---------------------------------------------------------------------*
*&---------------------------------------------------------------------*
*& Revision Log *
*& Date : x/xx/xx *
*&---------------------------------------------------------------------*
REPORT ZSKELINT
message-id xxxx
line-count xxxx
line-size xxxx.
*&---------------------------------------------------------------------*
*& TABLES:
*&---------------------------------------------------------------------*
TABLES: ...
*&---------------------------------------------------------------------*
*& VARIABLES:
*&---------------------------------------------------------------------*
DATA: ...
*&---------------------------------------------------------------------*
*& SELECT OPTIONS:
*&---------------------------------------------------------------------*
SELECT-OPTIONS: ...
*&---------------------------------------------------------------------*
*& PARAMETERS:
*&---------------------------------------------------------------------*
PARAMETERS: ...
*&---------------------------------------------------------------------*
*& FIELD SYMBOLS:
*&---------------------------------------------------------------------*
FIELD-SYMBOLS: ...
*&---------------------------------------------------------------------*
*& FIELD GROUPS:
*&---------------------------------------------------------------------*
FIELD-GROUPS: ...
*&---------------------------------------------------------------------*
*& INITIALIZATION:
*&---------------------------------------------------------------------*
* Event which occurs before the selection screen is
* shown to the user. It happens only once and is
* ignored in background processing.
INITIALIZATION.
*&---------------------------------------------------------------------*
*& AT SELECTION SCREEN:
*&---------------------------------------------------------------------*
* Event which occurs each time the user hits enter on
* the selection screen. This event is ignored in
* background processing.
*&---------------------------------------------------------------------*
*& TOP OF PAGE:
*&---------------------------------------------------------------------*
TOP-OF-PAGE.
*&---------------------------------------------------------------------*
*& TOP OF PAGE AT LINE SELECTION:
*&---------------------------------------------------------------------*
* Top of page for sublists
TOP-OF-PAGE DURING LINE-SELECTION.
*&---------------------------------------------------------------------*
*& END OF PAGE:
*&---------------------------------------------------------------------*
END-OF-PAGE.
*&---------------------------------------------------------------------*
*& START OF SELECTION:
*&---------------------------------------------------------------------*
START-OF-SELECTION.
GET ...
*&---------------------------------------------------------------------*
*& END OF SLECTION:
*&---------------------------------------------------------------------*
END-OF-SELECTION.
* Produce main list report SY-LSIND = 0.

SORT ...
LOOP...
WRITE:/ ...
* Hide specific fields which are of importance to the * line.

HIDE: ...
ENDLOOP.
*&---------------------------------------------------------------------*
*& AT PF STATUS:
*&---------------------------------------------------------------------*
* Event which occurs when user hits a particular PF
* key, e.g. PF6. The hide area and SY-LISEL are
* automatically available. It produces a sublist SY-
* LSIND = 1-9. PF3 is automatic and will always
* take the user back one list level, (SY-LSIND - 1).
AT PF...
*&---------------------------------------------------------------------*
*& AT USER COMMAND:
*&---------------------------------------------------------------------*
* Event which occurs when a user types =LIST in the OK
* code. The hide area and SY-LISEL are automatically
* available. It produces a sublist SY-LSIND = 1-9.
* PF3 is automatic and will always take the user back
* one list level, (SY-LSIND - 1).
AT USER-COMMAND.
CASE SY-UCOMM.
WHEN 'LIST'. .....
ENDCASE.
*&---------------------------------------------------------------------*
*& AT LINE SELECTION:
*&---------------------------------------------------------------------*
* Event which occurs when the user places the cursor
* to a specific line on the report and hits enter.
* The hide area and SY-LISEL are automatically
* available. It produces a sublist SY-LSIND = 1-9.
* PF3 is automatic and will always take the user back
* one list level, (SY-LSIND - 1).
AT LINE-SELECTION.
Subroutines
*-----------------------------------------------------
* SUB_INSERT_ENTRIES
*-----------------------------------------------------
...
ENDFORM.
APPENDIX A-3. Create a Sequential Dataset
*&---------------------------------------------------------------------*
*&---------------------------------------------------------------------*
*& Revision Log *
*& Date : x/xx/xx *
*&---------------------------------------------------------------------*
REPORT ZSKELOUT
message-id xxxx
line-count xxxx
line-size xxxx.
*&---------------------------------------------------------------------*
*& TABLES:
*&---------------------------------------------------------------------*
TABLES: ...
*&---------------------------------------------------------------------*
*& VARIABLES:
*&---------------------------------------------------------------------*
DATA: G_PDSNME LIKE FILENAME-FILEEXTERN. "Physical Dataset Name.
*&---------------------------------------------------------------------*
*& INTERNAL TABLES:
*&---------------------------------------------------------------------*
END OF T_TAB.
*&---------------------------------------------------------------------*
*& PARAMETERS:
*&---------------------------------------------------------------------*
*&---------------------------------------------------------------------*
*& FIELD SYMBOLS:
*&---------------------------------------------------------------------*
FIELD-SYMBOLS: ...
*&---------------------------------------------------------------------*
*&---------------------------------------------------------------------*

EXPORTING
IMPORTING
EXCEPTIONS
IF SY-SUBRC <> 0.
ENDIF.
*&---------------------------------------------------------------------*
*&---------------------------------------------------------------------*
START-OF-SELECTION.
OPEN DATASET G_PDSNME FOR OUTPUT IN TEXT MODE.

IF SY-SUBRC <> 0.
.
TRANSFER T_REC TO G_PDSNME.

CLOSE DATASET G_PDSNAME.
GET ...
MOVE ... TO ...

WRITE ... TO ...
UNPACK ... TO ...
TRANSFER ... TO ...
*&---------------------------------------------------------------------*
*& END OF SELECTION:
*&---------------------------------------------------------------------*
END-OF-SELECTION.
Subroutines
*-----------------------------------------------------
* SUB_INSERT_ENTRIES
*-----------------------------------------------------
...
ENDFORM.
APPENDIX A-4. Read Sequential Dataset and Create a BDC Session
*&---------------------------------------------------------------------*
*&---------------------------------------------------------------------*
*& Revision Log *
*& Date : x/xx/xx *
*&---------------------------------------------------------------------*
REPORT ZSKELBDC
message-id xxxx
line-count xxxx
line-size xxxx.
*&---------------------------------------------------------------------*
*& TABLES:
*&---------------------------------------------------------------------*
TABLES: ...
*&---------------------------------------------------------------------*
*& VARIABLES:
*&---------------------------------------------------------------------*
DATA: G_PDSNME LIKE FILENAME-FILEEXTERN. "Physical Dataset Name.
*&---------------------------------------------------------------------*
*& INTERNAL TABLES:
*&---------------------------------------------------------------------*
END OF T_TAB.
DATA: BEGIN OF T_BDCDATA OCCURS ...

INCLUDE STRUCTURE BDCDATA.
DATA: END OF T_BDCDATA.

END OF T_TAB.
*&---------------------------------------------------------------------*
*& SELECT OPTIONS:
*&---------------------------------------------------------------------*
SELECT-OPTIONS: ...
*&---------------------------------------------------------------------*
*& PARAMETERS:
*&---------------------------------------------------------------------*
*&---------------------------------------------------------------------*
*& FIELD SYMBOLS:
*&---------------------------------------------------------------------*
FIELD-SYMBOLS: ...
*&---------------------------------------------------------------------*
*&---------------------------------------------------------------------*

EXPORTING
IMPORTING
EXCEPTIONS
IF SY-SUBRC <> 0.
ENDIF.
*&---------------------------------------------------------------------*
*&---------------------------------------------------------------------*
START-OF-SELECTION.
OPEN DATASET G_PDSNME FOR INPUT IN TEXT MODE.
READ DATASET G_PDSNME INTO T_TAB.
IF SY-SUBRC <> 0.
.
ENDIF.
CLOSE DATASET G_PDSNME.
*-- Upload a file from a PC into an Internal table --*

CALL FUNCTION 'UPLOAD' TABLES DATA_TAB = T_TAB.
*--------------- Open the BDC Session ---------------*

CALL FUNCTION 'BDC_OPEN_GROUP'
EXPORTING CLIENT = SY-MANDT
GROUP = 'SESSION_NAME' "session name
USER = SY-UNAME
KEEP = 'X'. "keep session
"after processing
LOOP AT T_TAB.
*------------------- DYNPRO nnn ---------------------*
PERFORM BDCDYNPRO USING 'X' 'SAPMxxxx' 'nnn' '' ''.
PERFORM BDCDYNPRO USING '' '' '' 'TABL-FIELD'
'LITERAL'
*------------------- DYNPRO nnn ---------------------*
PERFORM BDCDYNPRO USING 'X' 'SAPMxxxx' 'nnn' '' ''.
PERFORM BDCDYNPRO USING '' '' '' 'TABL-FIELD' TAB-
VAR.
*----------------------------------------------------*
PERFORM INSERT_BDC.
ENDLOOP.
*&---------------------------------------------------------------------*
*&---------------------------------------------------------------------*
END-OF-SELECTION.
*--------------- Close the BDC Session -------------*

CALL FUNCTION 'BDC_CLOSE_GROUP'.
*----------------------------------------------------*
* Subroutines
*----------------------------------------------------*
*--------- Add a line to the DYNPRO Table ----------*
FORM BDCDYNPRO USING BEG PRG DYN FLD VAL.
CLEAR T_BDCDATA.
T_BDCDATA-DYNBEGIN = BEG.
T_BDCDATA-PROGRAM = PRG.
T_BDCDATA-DYNPRO = DYN.
T_BDCDATA-FNAM = FLD.
T_BDCDATA-FVAL = VAL.
APPEND T_BDCDATA.
ENDFORM.
*----------------------------------------------------*
* Add a transaction to the BDC session with the *
* entries in BDCDATA. *
*----------------------------------------------------*
FORM INSERT_BDC.
CALL FUNCTION 'BDC_INSERT'
EXPORTING TCODE = 'TCOD'
TABLES DYNPROTAB = T_BDCDATA.
REFRESH T_BDCDATA.
ENDFORM.
*----------------------------------------------------*
APPENDIX A-5. CALL TRANSACTION USING Technique
*&---------------------------------------------------------------------*
*&---------------------------------------------------------------------*
*& Revision Log *
*& Date : x/xx/xx *
*&---------------------------------------------------------------------*
REPORT ZSKELCLT
message-id xxxx
line-count xxxx
line-size xxxx.
*&---------------------------------------------------------------------*
*& TABLES:
*&---------------------------------------------------------------------*
TABLES: INDX,
...
*&---------------------------------------------------------------------*
*& VARIABLES:
*&---------------------------------------------------------------------*
DATA: V_RETURN_CODE LIKE SY-SUBRC,
V_MESSAGE_TEXT(120).
*&---------------------------------------------------------------------*
*& INTERNAL TABLES:
*&---------------------------------------------------------------------*
DATA: BEGIN OF T_TRANTAB OCCURS ...
INCLUDE STRUCTURE BDCDATA.
DATA: END OF T_TRANTAB.
DATA: BEGIN OF T_MESGTAB OCCURS ...

INCLUDE STRUCTURE BDCMSGCOL.
DATA: END OF T_TRANTAB.
*&---------------------------------------------------------------------*
*& SELECT OPTIONS:
*&---------------------------------------------------------------------*
SELECT-OPTIONS: ...
*&---------------------------------------------------------------------*
*& PARAMETERS:
*&---------------------------------------------------------------------*
PARAMETERS: ...
*&---------------------------------------------------------------------*
*& FIELD SYMBOLS:
*&---------------------------------------------------------------------*
FIELD-SYMBOLS: ...
*&---------------------------------------------------------------------*
*&---------------------------------------------------------------------*
START-OF-SELECTION.
*--------------------- DYNPRO nnn -------------------*

PERFORM TRANS_FIELD USING '' '' '' 'TABL-FIELD'
'LITERAL'.
*--------------------- DYNPRO nnn -------------------*
PERFORM TRANS_FIELD USING 'X' 'SAPMxxxx' 'nnn' '' ''.
PERFORM TRANS_FIELD USING '' '' '' 'TABL-FIELD' TAB-VAR.
*----------------------------------------------------*
CALL TRANSACTION ' ' USING T_TRANTAB

MODE 'N'
UPDATE 'S'
MESSAGES T_MESGTAB.
* Message handling
V_RETURN_CODE = SY-SUBRC.
* The following function module is a custom routine

* and can be obtained from SAP America.
CALL FUNCTION 'ZZ_FORMAT_MESSAGE'
EXPORTING MESSAGE_ID = SY-MSGID
MESSAGE_NUMBER = SY-MSGNO
VAR1 = SY-MSGV1
VAR2 = SY-MSGV2
VAR3 = SY-MSGV3
VAR4 = SY-MSGV4
IMPORTING MESSAGE_TEXT = V_MESSAGE_TEXT
EXCEPTIONS NOT_FOUND = 4.
IF SY-SUBRC = 4.
V_MESSAGE_TEXT = 'No message text found in T100'.
ENDIF.
IF V_RETURN_CODE = 0.
* At this point, various things can be done to make
* the process slicker. Send the confirmation or error
* to the other program via RFC. Store key values and
* confirmation document number or error message in an
* ATAB table for future processing.
MOVE 'Transaction posted' TO ...
MOVE V_MESSAGE_TEXT TO ...
MODIFY ...
ELSE.
MOVE 'Transaction failed' TO ...
MOVE V_MESSAGE_TEXT TO ...
MODIFY ...
* In the event of erred transactions:
* Store the internal table in the INDX database for
* future online processing of the SAP transaction.
EXPORT T_TRANTAB TO INDX(..) ID ...
ENDIF.
* or create a batch input session for future
* processing.
REFRESH: T_TRANTAB,
T_MESGTAB.
*&---------------------------------------------------------------------*
*&---------------------------------------------------------------------*
END-OF-SELECTION.
* Subroutines
*-----------------------------------------------------
* Add an entry to the TRANTAB
*-----------------------------------------------------
FORM TRANS_FIELD USING BEG PRG DYN FLD VAL.
CLEAR T_TRANTAB.
T_TRANTAB-DYNBEGIN = BEG.
T_TRANTAB-PROGRAM = PRG.
T_TRANTAB-DYNPRO = DYN.
T_TRANTAB-FNAM = FLD.
T_TRANTAB-FVAL = VAL.
APPEND T_TRANTAB.
ENDFORM.
*----------------------------------------------------*
FORM ...
...
ENDFORM.
*------------------------------------------------------
Custom Program Cloning Procedures
Cloning a program is never the preferred solution. Occasionally, we simply

cannot change the original program to meet new requirements. But, the last
thing we want to do is clone a program that is a known performance
problem. Before cloning any program, determine if the original has ever been
identified as a performance issue. If the program has been modified for
performance reasons, determine if the current program runs efficiently. Checking
the current program's database utilization will confirm how well or poorly the
clone will perform.
Creating Test Program Versions
Please follow these procedures to minimize versioning issues when creating test
versions of programs. Test versions should only be created for programs that
need to be tested in Production, or benchmarked against the Production version
the Testing environment. We should not create test versions to test in the
Testing environment. In those cases just modify the Production version. If we
need to revert back to the old code we can use version management.
1. Save the Production version to put it on a transport. This will lock it from
further changes. If the program is already locked you cannot proceed!
The lock should be held on the Production version until step 4.
2. Copy the Production version to the Test version. The Test program name
should be the
Production program ended with _TEST. Put the Test version on a new
transport - not
the transport created in step 1. If the Test version already exists, first
determine if it is an
old test version. If it is, overwrite it. If it is not, you need to determine
how the Test
version is being used. You may need to add a numeric counter for the
copied version in
order to not disturb the Test version. Add the following comment line to
the Test version
revision history: "This is a copy of program Zxxxxx from dd/mm/yy for
testing/benchmarking".
3. Make changes to the Test version and transport them for testing. This
may be an iterative
process.
4. Once the changes have been signed off, copy the Test version back to
the Production version and delete the Test version. Use the transport
created in step 1 for the delete. Update the revision history in the
Production version.
Guidelines
Here are some guidelines to follow:

Modify the custom program if the modifications are simple, and
apply globally or can
be parameterized.
Copy the program if significant functional changes are being

implemented.
Do not modify or copy the program if only a fraction of the

functionality is needed. In this
case, start from scratch and create a custom program that is

performance efficient.
3.5 Custom ABAP Security

This Guideline describes HPs accepted practice for incorporating security requirements
into custom development work, e.g., ABAP/4 development.
In order to monitor access to any custom SAP program or report in the production
environment, it is necessary to integrate security in the program development stage.
This document also provides the ability to incorporate security checks within any custom
SAP program. This in turn, allows Security Administration the right to limit access
according to the confidentiality of the information, to certain groups as defined by owner
of the information.
General
Early Planning For Security
Authorization Check Objects
Programming Authority-Checks
Securing Transaction Codes
Development Steps
Administration
Early Planning For Security

It is necessary to plan early for security and to incorporate security needs at the start of
development work. The concepts of who the users are, what data groups of users are
allowed access (or not allowed access), and the field values that should be checked in
the ABAPs must all be considered.
Custom code should indicate the functionality provided and allow clear management at
object code level. It should be managed through transaction codes and authorization
objects. The object S_TCODE should be used to control the access to the custom
object.
As the business owner of the business process, they are responsible to define this
business groups and users.
Authorization Check Objects
Custom development work should not reference any SAP delivered authorization objects.
SAP Authorization objects are linked to SAP interpretation of the business processes.
Thus, using an SAP delivered authorization object may inadvertently result in allowing
access when SAP changes the interpretation of the object. In addition, custom programs
which use SAP delivered authorization objects may also be affected if the authorization
object is changed or deleted in future releases. However, there may be exceptions. For
example, calling an SAP delivered transaction or function module which includes SAP
delivered authorization objects.
The general rule to follow is that if you are hard coding the SAP delivered authorization
object check into your custom code, you must review this with SAP Security
Administration.
In order to centralize the administration of authorization objects the Security
Administrators will create these objects. The developers however, will need to define the
fields that are checked in the program and communicate those fields to Security
Administration. (See: Development Steps) (See: Development Steps)
All custom authorization objects will be evaluated and approved at the design phase by
both technical development manager and the security manager, or their appropriate
designees. The functionality of the objects must be fully documented, and kept in the
system library any changes to the functionality must be approved by the managers and
properly updated. All questions regarding usage of custom authorisation objects must be
answered including how and why they might be used.
The Functional Development teams are responsible for creating custom authorization
objects, but they are developed to meet the requirements specified by a functional
organization, project team or security manager. The Development manager and Security
manager will both approve these requests prior to their creation. The security team can
create the objects but they will adhere to the standard project approval process
Programming Authority-Checks
All custom ABAP programs and reports must address the need for security. Some
reports may not need to have an authority check if they do not display sensitive data.
Corporate guideline for Handling and Managing HPs Information Assets,
http://legalweb.corp.hp.com/legal/files/chart.pdf, should be followed. Document required
special handling should have an authorization check. This check allows Security
Administration to control access to the program and also allows field level checks, if
necessary.
Further information about authority-check statements can be found by typing HELP
AUTHORITY-CHECK at the editor command line in the ABAP program editor.
Securing Transaction Codes
Security authorization group includes t-code for all programs. T-code can be a custom t-
code or generated when program is added to the report tree. Therefore, all programs
should be secured by t-code. This is the preferred way to protect custom report.
Security can also be involved at the transaction system level. When a user enters a
transaction at the command line, a check is executed to test user access. This check
object is usually one of the same objects referenced in the program. Whereas
programming authority-checks allows for checks during run-time, securing access at the
transaction code level prevents a user from even starting the program. The user will not
even be able to display the first screen.
However, security access at this level does not check access if a CALL TRANSACTION
in another program is done to this one.
Development Steps
For creating a new authorization check, this is an iterative (not repetitive) process. Many
of these steps must be worked again as testing is done to ensure that appropriate
authorization checks are in place.
Identify the field and values that are to be checked in the ABAP program. Fields
and values check are defined by the business processes as defined by business
owner. Past
practices of linking the program attributes authorization group to user security is
not
used.
Document the field and values required for this object to Security Administration.
Security Administration then creates the object with the fields defined by the
developer and notifies the developer of the authorization object name. Security
Administration will create a user to test the object with.
Validate the authorization checks with the test user for that object. This must be a
joint effort between Security Administration and the developer. Different values in
the authorization need to be checked in order to determine if all possible values
are controlled by the program.
Once the testing and the object is ready for implementation, it will be transport to
production.
Inform the appropriate application module team of the authorization objects so
that it can be incorporated into programs and reports.
For adding an existing authorization check to a new program,

Review existing authorization object.
Add AUTHORITY-CHECK to program
Developers who require this object will have to request the appropriate activity
group from Security Administration. Once an object is coded into the program,
the developer needs the authorization to even run the program during
development.
Verify AUTHORITY-CHECK works correctly.
NOTE: Because this is an integrated process between the developer and Security
Administration, Security Administration will be available for consultation on the definition
of fields and values and also on the implementation of security requirements.
Administration
Security administration is defined by the regional infrastructure team.
SAP Security Administration
They are responsible for communicating this Guideline and keeping the developer
community informed of changes and updates. In addition, they will implement new
authorization object and assign to users.
Developer Community
The developers have the responsibility for adhering to this standard and to maintain a
vigilant effort to review for occasional updates. The community is also responsible for
documenting the security requirement based on business needs.
Business Community
The business community owns/defines the requirement for business object and approves
user requests for activity group.
Definitions/Terms/Acronyms
Authorization
Specifies the value for the fields in an authorization object. Authorizations allow control
and flexibility in assigning access to certain data values.
Authority-check
A statement in ABAP that allows checks to be carried out at run-time. At this statement,
the system searches the master record of the user executing the program for the
necessary authorization values.
Authorization object
An element of the authorization system. An authorization object groups up to 10

authorization fields for combined authorization testing. Authorization tests in the system
are carried out against objects. The user is permitted to perform an action only if he or
she passes the test for each field in an authorization object. (See illustration below).
Activity Group
Assigns a system access privilege to users in user master records
Section 1 Enhancements Technologies
With the SAP upgrade to ABAP 7.0 a new way to change SAP application execution is
provided. These are called Enhancements. There are four technologies available within
Enhancement Framework:
Source Code Enhancement
Function Group Enhancement
Class Enhancement
Kernel-BADI Enhancement
Two types of Enhancements
There are two kinds of source code enhancements, Explicit and Implicit. These are
based on technology which dynamically executes an instance of customer code when
reaching a certain point in the standard SAP object. Therefore, there is no change to the
SAP object and no repair key is needed.
Explicit Enhancements
Explicit enhancements are added to SAP code at predefined anchor points. These are
called enhancement points. These enhancement points are assigned to an
enhancement spot. The enhancement spot is the compilation and transport unit, similar
to a function group. An enhancement point can have multiple enhancement
implementation assignments. A given enhancement implementation can be assigned to
multiple enhancement points. But the assignment of a given enhancement point to a
given enhancement implementation, creates a specific change at run-time. They can be
a BADI or a source code plug-in.
Implicit Enhancements
An Implicit enhancement has no pre-existing definition nor has it been planned for by
SAP developers. An Implicit enhancement can be implemented when an SAP object
starts or ends execution. You can insert implicit source code plug-ins before the first and
the after the last line of includes, methods, reports, and function modules. Dictionary and
defined structures also allow for implicit enhancements. The following are implicit
enhancement options at which enhancements can always be inserted:
You can implement implied enhancements before the first and the after the last
line of form routines, includes, methods, reports, and function modules.
You can add further optional parameters to function modules.
For global classes, there are different permanent, implicit options for
enhancements: You can insert additional attributes or methods, and you can add
optional parameters to existing methods.
Source code plug-ins
A source code plug-in is custom code dynamically loaded at that point. But it has no
defined interface. There are 2 flavors of these, enhancement-point and enhancement-
section. Enhancement-point only occurs at a specific line in the SAP code, but can
trigger multiple enhancement implementations. Enhancement section is a replacement
for a section of code and can have only one implementation.
An Explicit enhancement-point source code plug-in is planned for by SAP developers.

But, it does not have a pre-defined interface. All data available to the SAP code is
available to the enhancement. This is similar to classic empty includes and forms
provided by SAP.
Although source code plug-ins are displayed in the same source code as the respective
enhancement options, they are actually stored in other Include programs managed by the
Enhancement Builder.
Function Group enhancement
Function Group enhancements allow SAP customers to add new optional parameters to
SAP function provided function modules. It is important to note that these types of
enhancements ARE upgradeable. As stated above these are considered implicit
enhancements and could prove to provide HP significant benefit. Instead of copying an
SAP function or performing a core mod you should investigate to see if a function group
enhancement along with an implicit source code plug-in can meet your requirements.
BADIs
A BADI enhancement is an objects method that includes import and export parameters.
It follows the rules of ABAP Objects, including filters and inheritance. Data in the SAP
code is passed through the parameters of the method interface.
**** These are considered explicit enhancements when an existing BADI is called in the
system. If you choose to enhance the BADI and add new methods or parameters this is
considered an implicit enhancement!
Detailed documentation on Enhancement Framework can be found on the SAP website:
http://help.sap.com/saphelp_nw70/helpdata/EN/94/9cdc40132a8531e10000000a1550b0/
frameset.htm
Enhancement Builder
The following SAP documentation links will provide you an overview of how you can
browse the different available enhancements, spots, implementations, etc.
Enhancement Builder:
frameset.htm
Enhancement Information System:
frameset.htm
Creating, Editing and Deleting Enhancement Spots:
frameset.htm
Creating, Editing and Deleting Enhancement Implementations:
frameset.htm
Key Considerations
Required Analysis
Before an SAP enhancement is proposed to be implemented all other options must be

reviewed before implementation. Do your homework:
Is there an existing SAP solution, program or switchable SAP enhancement that can be
utilized instead?
Are you absolutely sure standard SAP configuration changes will not meet the
requirement?
Is there an existing custom HP solution that can be utilized instead?
Discuss the proposed enhancement with architects and key stakeholders, someone will
most likely be able to provide you feedback on the best approach.
Make sure to review the enhancement type preferences below to ensure you are
implementing the most desired technology/enhancement type.
Make sure to analyze the interaction with existing SAP implementation and switch
frameworks to ensure your enhancement will work.
Will an existing enhancement implementation meet your needs? Reuse of existing
enhancement implementations at new enhancement points is better then duplicating.
Enhancement vs. Core mod: The usage of the SAP provided Enhancements are always
preferable to core modifications. Before implementing an Enhancement, it is essent ial
that you are well acquainted with an applications construction and flow logic. Such
knowledge is necessary if you want to evaluate enhancement possibilities and decide on
a sensible implementation. Developers implementing enhancements are required to be
familiar with the enhancement framework and the development tools used.
Switches
Switch framework is used primarily for controlling the implementation of one or many
industry specific solutions. While switches may also be used to control/turn on HP
enhancements to SAP the benefits for SCIT at this time are not there. At this point
SCIT will not be employing switches for enhancements. It is important to note that as
SAP rolls out new functionality that will be leveraged by HP, switch framework may be
used to turn it on.
Enhancement Type Preferences
Explicit BADI enhancement is preferred over Business Transaction Events.

Classic BADI should be migrated to new BADI for performance reasons.
BTE is preferred over Explicit source code plug-in enhancements because a BTE
has a defined interface.
Explicit enhancement is preferred over implicit enhancement because implicit
has not been planned for by SAP developers.
Explicit or Implicit enhancement code plug-in is preferred over Classic CMOD
user exits for performance reasons. (Need to discuss this)
Explicit or Implicit enhancement code plug-in is preferred over Classic include
user exits because implementation of the include requires modification and repair
key and may be wiped out by upgrades. . (Need to discuss this)
Implicit enhancement code plug-in of output requirements is preferred over

creating a new requirement because custom output requirements need a repair
key and custom output requirements may not work after an upgrade. (Need to
discuss this)
Like CMOD user exits, it is recommend to place specific code in separate
includes that are triggered by dynamic values. For example, if country = US,
include Zxyz_us. This only applies to source code plug-in. It does not apply to
BADI, since BADI has filter options.
Naming Convention
Tech Designer / developers implementing enhancements are required to adhere to

naming standards for the enhancement implementation.
The development class used must be of the enhancement type, eg. Z3ELOPDM_IDOC
where the E represents Enhancement. As per the development class/package naming
conventions the description portion of the package should be descriptive of the solution
type, eg. TOOLS, IDOC, ORDER, BOM.
The implementation naming convention is as such:
Development Class(Package) / EI / SAP Object / Number
Examples:
ZG3ELOPDM_TOOLS_EI_SAPMV45A_01
Z1ESDCM_IDOC_EI_SAPRQ33A_03
Z3ESD_EZPRS_EI_MV45AFZC_01
Activating Enhancements
Enhancements can be active or inactive. They should be left inactive, until coding is
complete and all syntax errors are resolved. They should be activated when developer is
ready to unit test.
If transported to production with the active flag turned off, the enhancement will not
execute.
Section 2 Usage of the Explicit Enhancement
The Explicit enhancement is defined by SAP. SAP program expects that customers may
implement this. Therefore, we will treat these in the same manner as classic CMOD user
exits or include user exits. They should not be considered risky development and no
PAR approval is needed. TD will decide on the correct implementation.
The preferred kind of explicit enhancement is the BADI enhancement. This has a defined
interface and is safe to use because of the object technology used.
There are 2 kinds of Explicit source code plug-ins. There are Enhancement-Points and
Enhancement-Sections.
An Enhancement-Point that is triggered when the SAP object gets to that point in the
code. These are pre-named and can be static or dynamic.
An Enhancement-Section contains a default implementation. Everything between the

Enhancement-Section and End- Enhancement-Section is the default implementation. A
custom implementation replaces this section of code.
Examples:
Found in Include LV69AF16
ENHANCEMENT-POINT KONDITION_PRUEFEN_10 SPOTS ES_SAPLV69A STATIC.
ENHANCEMENT-POINT KONDITION_PRUEFEN_11 SPOTS ES_SAPLV69A.
ENHANCEMENT-SECTION KONDITION_PRUEFEN_06 SPOTS ES_SAPLV69A.
call function 'PRICING_CHECK'
exporting
comm_head_i = komk
comm_item_i = komp
komv_i = komv
preliminary = 'X'
importing
comm_head_e = komk
comm_item_e = komp
komv_e = komv
konp_e = konp.
END-ENHANCEMENT-SECTION.
Section 3 Usage of the Implicit Enhancement
The Implicit enhancement is not pre-defined by SAP. These enhancements are implied
by the start and end of a SAP objects execution. SAP allows customers to implement
these and they will be retained in upgrades. Regardless, the approval approach for
implicit enhancements will be to gain a PAR approval in order to implement one. Please
follow the High Risk Development PAR approval guidelines. Keep in mind these are still
preferred over SAP source code modifications.
You will need to use the ABAP Editor Edit->Enhancement Operations->Show Implicit
Enhancement Options to actually see these enhancement points.
Examples:
Found in Include LV69AF16

*&--------------------------------------------------------------------- *
*& Form CHECK_WAERS
*&--------------------------------------------------------------------- *
*---------------------------------------------------------------------- *
* --> CHECK_DATE date for expiration check
* --> NO_MESSAGE parameter to suppress messages
* <--> CHECK_CURRENCY manually entered condition currency
*---------------------------------------------------------------------- *
form check_waers using check_date type datum
no_message type xfeld
changing check_currency type waers.
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""$"$ \S
E:(2 ) Form CHECK_WAERS, Start
A
statics: begin of currs occurs 0,
waers type waers,
okflg(1) type c,
"""""""""""*"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""$"$ \S
E:(1 ) Form CHECK_WAERS, Struct. CURRS, End
S
end of currs.
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""$"$ \S
E:(3 ) Form CHECK_WAERS, End
A
endform.
Section 4 Source Code Comment Requirements
Source code comments are required for enhancements just as they are for any other
custom code. The one difference here is that you are required to call out your change in
the program header with a description that starts with Enhancement, see below.
Implementation must include a comment at the very top of the source. Insert lines as
necessary. The comment should include the following data at a minimum; the date of the
change, the programmers name, the change request (transport) number, and the S-ticket
number. Additional comment lines within the comment block, or within the source code,
may be added as necessary, but should be succinct and kept to a minimum. For
readability, indent the comment lines as necessary. See ABAP documentation standard
for detailed requirements.
*----------------------------------------------------------------
-----*
* Revision History
*
* Date Programmer Name Reference Number

*
* User-ID Description
*
* ---------- ---------------------- ------------------------

*
* xx/xx/xx xxxxxxxxxxxxxxxxx xxxxxxxxxx

*
* xxxxxxxxxxxxxxxxx Enhancement-
xxxxxxxxxxxxxxxxxxx*
*****************************************************************
******
You must also use the enhancement implementation Long Text to document the reason
and function of the enhancement.
3.6 Unit Test cases & Documents

Detailed description of each test case
Please describe as detailed as possible:
- which test cases you want to test
- which input data you use and
- what the expected results are.
Examples: Which Order Number, Material number, Quantity, etc.
Document the status of the test result, if the test result does not match with the
expected result.
The following items have to be covered:

- Test Case ID
- Test Steps including Input Data
- Expected Result
- Actual Result + Status
Actual Result only if different from Expected Result)
- Status (e.g. OK, Open, Problems/Issues detected, it a good idea to use color-
coding)
Can be used to document test output data e.g. documents no. created
Regarding the format you are free to use either free floating text, a table or whatever
you like. However, the items listed above need to be explicitly mentioned in the
document.
Hint:
The description of the test process should be in a way that a third person can find the
test cases in the test system. The person should be able to understand the key
purpose of the test case and the test process.
The following table is an example for describing test cases
Case 1 : Testing for the service item of the sales document
Test ID Test Steps incl. test input data Expected Result Actual Result +
Status +
Test output data
1 Execute the Function Module: Z_CREATE_DISPAY_TO
Fill the following IMPORT parameters:

The Export Parameter PASS.
E_TANUM will have the
Warehouse Number ( I_LGNUM) : 1 New Transfer Order Refer Figure 1
Transfer requirement number ( I_TBNUM) : 802088 500235 Created :
COMMIT WORK (I_COMMIT_WORK) : X
User Name (I_BNAME) : GR
Figure 1 :
Now Execute the Function Module L_TO_CONFIRM with the following value:
Test Issue log
= Test Incident Report
Use the issue log to describe each error that occurred.
The column Test case is to have a reference to the corresponding test case.
The column Date comm., that means date communicated indicates, if the
error was communicated to the responsible person in order to have a
continuous tracking.
If an issue is processed you can mark that line in green.
No. Test Issue description Kind of Date Date Respo. Solution

case error found comm. person
3.7 Implementing Solution Guidelines

Identify Global Solution
The Global Architect Design and Solution team maintains ownership of Global solutions.
The first step in implementing a Global solution is to identify whether it is a Global
solution or a Regional solution that can be Globalized.
Isolate Global Objects

Globalized objects should be isolated from Regional specific solutions. The technical
specification will include a Global area to describe the specifications for the Global
portion of the solution.
Implement Global Solution

In order to isolate the Global solution from Regional solution the following guidelines
should be used to implement the Global solution.
Global objects should follow the naming standard for Global objects and
assigned to a Global Development Class and Global Function Group assigned to
the Global Transport Package.
Ex. Z_GX_* (Function Modules)
ZGX* (All other Objects)
Z Denotes Custom Object
G Denotes Global Object
X Denotes Regional site code (1 = EMEAetc)
Regional Exits should also follow the naming conventions for Global objects and
assigned to the Global Development Class, a Global Exit Function Group, and a
Regional Top Include within the Global Exit Function Group.
Existing regional objects identified as Global process will change their name to a
Global Object name and assigned to the Global Development class and the
Global Exit Function Group.
Regional Exit routines name will include the following suffix _EXIT0n. (n =
numeric counter)
Regional objects belonging to a global solution will be deployed by the global
solution as an empty object. The regional developer will create a Regional
Include Member using the regional naming convention, a regional TOP include
and assigned to a regional development class.
Subsequent deployment of the regional call must be managed and coordinated
with Basis and Developers as the call will overlay the include member and have
to be re-applied.
The comment box at the top of the Object will now include as the first comment:
* GLOBAL OBJECT *
The Global objects or imbedded Global code should be well documented both
identifying it as a Global solution and the functionality of the solution.
One of the Regional platforms will be the host of the Global solution and
transported to the other Regional platforms.
For existing Regional solutions, the Global code should be in an INCLUDE
member or Function Module depending on the solution.
When a Global solution cannot be isolated into a separate object, the Global
code should be incased within a comment block or in a separate FORM
identifying it as Global code.
For a portion of a Global Solution that differs at the Regional level, then a Global
Function Module OR Program would call a Regional Function Module OR a
FORM within a Regional program with Regional specific functionality which could
encompass any Data Dictionary or regional code.
Ex. Function Module regional exit call(s)
Development Class: ZG1ILOPDM
Function Group: ZG1ILOPDM01
FUNCTION Z_G1_EXTEND_MATERIALS.
* 1st FM calling specific regional logic
Function Group: ZG1ILOPDM01_EXIT
CALL FUNCTION Z_G1_RETRIEVE_PLANTS_EXIT01.
import
ENDFUNCTION.
Function Group: ZG1ILOPDM02_EXIT
* 2nd FM calling specific regional logic
CALL FUNCTION Z_G1_RETRIEVE_STORLOC_EXIT02.
import

ENDFUNCTION.
ENDFUNCTION.
FUNCTION Z_G1_RETRIEVE_PLANTS_EXIT01.
include z3ilopdm_retrieve_plants .
ENDFUNCTION.
Ex. Program regional exit call
REPORT ZG1ISDOM_SHIP_EXTRACT.
PERFORM FILTER_SHIPMENT_REGION
IN PROGRAM
ZG1ISDOM_SHIP_EXTRACT_EXIT01
CHANGING T_XLIKP[]
T_XLIPS[]
IF FOUND.
Support for a Global Solution

The Core Technical Development Team will maintain the Global objects, therefore, the
objects cannot be modified by the Regional Teams other than regional Includes within
global exits. If objects are shared, then the regional team should coordinate any changes
with the Core Technical Development when the changes impact Global functionality .
3.8 PCR process code review
Introduction.
As the S-Ticket tool is used to track assignments and workloads, it is also used to request
the corresponding code review (PCR) once you are done with your development and did
all necessary test.
If your changes are more than 10 lines of code (LOC), you have to create a PCR document
a before you can request the code review itself. PCR document helps the reviewers to
know which areas they will be focus on the code so it is very important you know how to
fill it right.
Also this document helps as a check list for developers to verify if all her/his code is
compliant with ABAP development standards followed in HP.
Only if your change is 10 lines or less, you can skip the creation of the PCR document and
go direct to the Code Review.
PCR Document Creation.

PCR Document has to be created inside the ticket with the Workflows Button from the
VIEW tab at header level.
From there, you

have to select the Create PCR Document option. This will create the corresponding
document and you will be notified via mail.
Mandatory fields to successfully create the PCR document are Assigned To, Transport
Request and PCR Reviewer.
If one or more of those fields are missing, the document will not be created but you will
also be notified.
PCR Document Fields.

Please remember that PCR document is a check list that each developer MUST use to
validate her/his code adheres to HPs development standards BEFORE request a PCR.
<LINK-TO>PCR Document Example</LINK-TO>
Ticket Number * Automatic
Transport Number * Automatic from S-ticket

PCR Reviewer * [{"ResolveText":"
Automatic from S-ticket

Developer * [{"ResolveText":"
Automatic from S-ticket
Notes for Reviewer <DIV></DIV>
<DIV></DIV>
Include important information to share with the reviewer.
New Development - Program N/A
Attributes
Is the title a concise description, the ABAP application is set to the appropriate
value for the functional area involved and the Development Class is
appropriated?
New Development - Security N/A
Has an appropriate strategy been discussed with request owner and agreed for
authorization objects inclusion in the development?
Are program attributes correctly Setup?
New Development - Program N/A
Documentation
The Online Program Documentation provides functional leads and end users
with necessary information to determine report functionality. It also contains
information on file inputs and outputs
Version Management N/A
Has version been checked in the different systems including production, if an
existing object is being changed / enhanced?
Error Handling N/A
Are Errors handled within the program, including:
-FM exceptions
-SY-SUBRC checks on Database Act
-Division by Zero
Import-Export N/A
Avoid EXPORT/IMPORT to memory whenever possible. If used at all, is this
the only possible way to exchange the information?
Transport Request Documentation N/A
Is the Transport Request/Task Correctly Documented? (Following Template)
Code Comments N/A
Internal commenting has been done sufficiently enough to ease program
maintenance and reliability of the ABAP
Change History N/A
A chronological history of modification notes; with the latest change being the
last entry in the modification log including transport number and Request
number (S-ticket, HPSM, etc.)
Naming Standards N/A
The ABAP Naming Standards and Programming Standards have been followed
in ALL NEW OBJECTS and components inside the programs
Risky Development N/A

Does Risky development have PAR approval?
-Unreleased FM
-SAP Repairs
-Direct Updates to SAP tables
Pretty printer N/A
Is Pretty Print Function used?
-Use only for new developments.
Code Inspector - Extended syntax N/A
check
Extended syntax check and Code Inspector (if Available) were performed and
Errors have been fixed
Performance Analysis N/A
Performance Impact has been considered and analyzed (You can use SE30 or
ST05 transactions)
Selection Texts N/A
Selection Texts have been created (For Parameters and Select Options)
Text Elements N/A
Text Elements are used instead of Hard-Coded text
SELECT - Into Table N/A
Whenever Possible Use SELECT INTO TABLE instead of SELECT
APPEND ENDSELECT
SELECT - fields sequence N/A
SELECT fields and the WHERE conditions should be in SAP table field
sequence and with similar types
SELECT - For All entries N/A
Whenever is possible use SELECT FOR ALL ENTRIES used outside of loops,
with a READ inside the loop.
If used verify the internal TABLE used the WHERE is not empty
SELECT - Order by N/A
Avoid SELECT ORDER BY. Preferred put records into an internal table and
SORT it
SELECT - Cluster tables N/A
For Cluster tables, only the consecutive fields that are part of the key are
qualified in the WHERE option. The CHECK command is used to eliminate
other records
SELECT - Negative Logic N/A
The use of negative logic in SELECTs is avoided whenever possible
SELECT - Indexes N/A
Whenever possible use the Primary Key or a secondary Index
Internal Tables - Nested Loops N/A
Nested loops are avoided. If unavoidable, take advantage of parallel cursor
technique
Internal Tables - Loop Where N/A
LOOPWHERE is used instead of LOOP/CHECK
Internal Tables - Read binary Search N/A
Before using READ BINARY SEARCH, sort table by the Fields used on the
READ
Internal Tables - FREE N/A
The FREE command is used to release the memory allocated to internal tables
when the program is finished processing the data in the table.
Modularization N/A
Break code into subroutines whenever possible to make the code clearer and
reusable
Logical comparison N/A
When using the AND or OR operator the most likely elimination criterion is
specified first.
Initialization N/A
Ensure fields and work areas are CLEARed and table REFRESHed
properly. (On loops, before selects, etc.)
Move Corresponding N/A
MOVE CORRESPONDING is only used for small tables and when Tables or
work areas are not identical. If they are identical use MOVE statement only.
Layout and Smartforms - Comments <DIV></DIV>
<DIV></DIV>
For SMARTFORMS and LAYOUTS, specify the elements
that were modified or created
Layout and Smartforms - Tabs N/A
The tab symbol (,,) is used instead of spaces
Layout and Smartforms - Underlines N/A
Underlines are written using uline(xx) instead of typed out
User Exits - Exit Statement N/A
Do not use EXIT statement on user exits, or use it inside DO 1 TIME ... ENDO
User Exits - COMMIT work N/A
Don't do COMMIT or ROLLBACK WORK on user exists. (SAP will do this when
ready, we dont need to do this)
Reviewer Signoff <DIV></DIV>
<DIV></DIV>
I certify that the above items have been checked
(Enter Name and Date for each time this PCR Document is reviewed)
Once you are done filling the PCR Document, then you can request the corresponding
Code Review.
3.9 Transport management
Transport Request (TR) Process

Background:
Development Phase covers almost 70 % of a Project Life Cycle. The
HPME Methodology has the following process under Development
phase
1. Design ADD
2. Construction- Config /Coding/ Unit Testing/ Test Plan /Training Matl
3. Testing- UAT /SIT/ BIT / Regression
4. Implementation- Request & Approvals/Staging / RTP / Go Live
Support
Steps:
The Developments done and moved to production has the following
steps
1) Construction of the changes and unit testing in Development
Environment
2) PCR to be completed by the developer.
3) Replicating these changes in Test Environment by moving the
changed objects through a Transport Request (TR) for UAT /SIT
4) Finally moving the changes from Development to QA/ Regression
/Staging before finally moving to Production once the UAT signoff is
received.
Types of Transports: There are basically 2 types of Trans
1. CUSTOMISING REQUEST - FRONT END / CONFIG CHANGES

2. WORKBENCH REQUEST - ABAP /CODE CHANGES
All Changes are to be made in the Development Box First and then
transported to the Testing Box for Testing, because these changes are
referred to as master changes and the same is also moved to production
STEPS IN CREATING & TRANSPORTING REQUESTS

Step I : Saving Development Changes
1. Create the Development Changes and Save them as TRs in
Development Box
Critical Fields : Request No ; Owner ; Target System; Project ID; User
Step II- Release Transport Request (TR) from Development Box
1. Go To T Code SE09
2. Click on the Selection Options and verify the USER ID
(If the developer is different from the person import into U26, the
owner ship needs to be changed in D47 and that person needs to
release TR)
3. Select the necessary options and press enter to get the list of TR
First Release all the sub tasks and then the main task .This is done by
clicking on the request no and then the release button
It is critical to check the dependencies of the Transports before importing.
This can be done by double clicking on the Pr column icon
Step III- Import Transport Request (TR) into Test System

1. Go to T Code STMS_IMPORT
2. Search the TR no
3. Click on the Request No and then the Import Icon for importing it
into U26
4. Verify the St Column has
Exception: * In SAIL System, manual importing is not required as this
is taken care by a batch job and all released TR gets automatically
imported to P2T
RTP PROCESS
Once the changes are transported to Testing Environment and all Test
scenarios are completed, a UAT signoff is received to move the changes to
production. To move these changes a RTP Request needs to be raised and
approved
A. Types of RTP Request:
1. Planned : These are meant for enhancements or non-critical changes
2. Exception: These are changes which dont have major impact but
needs to be addressed before the planned RTP date. e.g. less critical
bugs /fixes. While submitting the Exception, please provide L3
approval too with UAT signoff
3. Emergency: These have high impact on the applications, business

process or financially and needs to be moved asap/ urgently. eg
Critical Bugs / Fixes
B. RTP Request Creation:
The following steps are followed to have these changes approved for
the MTP
1. Create a RTP request as per the requirement by going to the link

below
http://vhou4intproa.houston.hp.com/RTPTool/
2. The fields are self explanatory. The contacts are given on the last
page of the presentation.
3. RTP Type and Date and the sequence of the TRs are critical
4. If Direct Changes are required, user access should be requested for

the RTP period with justification and approvals
5. After submission of the RTP, there may be a meeting held to clarify

the queries for approval of the same
6. RTP requests needs to be planned so that it is submitted well in

advance before the release date, except for emergency requests
7. Release Manager will facilitate the MTP process
C. Critical Fields / Comments to be updated in a RTP Form:

All * fields are mandatory
Submitter Information:- Self Info/ Management Email/ L3 Name/

Project Detail / Ticket or POR details /Emergency nos
Transport Info:- Rtp & Change Type, Priority, Target System,

Requested Date, Business Requestor, Change Description, Root
cause/background, Justification, Technical description, Transport list
(sequence of TR and dependencies check is critical). Please verify the
Release date from the Release Calendar
(http://teams4.sharepoint.hp.com/teams/stp.release.management.c
alendar/default.aspx)
The signoff mail needs to be sent to the Release Manager earlier.
Cross Domain Impact; In case of the changes impacting downstream

or being impacted by upstream apps of different domains, the same
needs to be highlighted to have proper co-ordination
Direct Changes: If direct changes are required into the production

system
Testing Evidence: All * fields are critical .In testing ,please mention
few Test Cases
Questionnaire: All the fields are explanatory. Please type all the
Function modules/user exits in respective field
Control Period: Only in case the RTP is being made during Control
period the fields needs to be entered
Additional Comments: As required

PLEASE DO NOT SUBMIT THE RTP UNLESS ALL REQUIREMENTS
/DETAILS ARE FUFILLED. SAVE IT AND KEEP UPDATING TILL FINAL
SUBMISSION
D. MTP Verification:
1. On the day and time of MTP, an email will be sent across by Joyce
mentioning that the changes have been moved to the Staging
Environment. At this time, the development team has to re-verify
these changes and confirm if these Transports are correctly moved
and everything is working fine. Else contact Joyce and stop the
further move to Production and have the rectifications done asap
2. Once confirmed the staging environment is working fine ( no reply is

considered as affirmative and only negative confirmation is
considered ) the Transports are moved to Production
3. Once into Production, another email is sent across to have

everything verified and some time given to make direct changes to
the Production system, wherever applicable
4. After confirmation from all requestors that the transports /Changes

are fine, the Production system will be shut down for Maintainance
and will not be available for few hours thereafter.
5. No other changes will be entertained hereafter and needs to follow

the complete RTP request process once again
HPME Methodology, Life Cycle, Deliverables.
What is a Methodology?
A good project management methodology provides a framework

with repeatable processes, guidelines and techniques to greatly
increase the odds of being successful, and therefore provides value
to the project and the project manager.
Benefits of a Project Management Methodology
Make decisions with confidence, achieve better visibility and control

of a project
Meet deadlines, stay within a budget and achieve high quality by
meeting or exceeding customer expectations
Lower the cost of a project by accomplishing more work in less time
and with fewer resources without any sacrifice in quality
Provide guidelines and flexibility
Unify teams
Minimize conflict and confusion
Be proactive, not reactive
Confidently baseline scope and schedule
Document agreements for future references
Using HPME methodology enables users to leverage from best
practices based on prior learnings, experience, and tools used
HPME Project Life Cycle

HP Project Methodology Enhanced provides a life cycle framework
that will facilitate efficient partnerships between the business & IT
groups. The lifecycle makes it easier to identify, review, update and
communicate data assigned to each project phase. Reporting and
interdependencies between projects can be better tracked through
the lifecycle phases.
The HPME Framework is a minimum framework with

8 Phases set in 3 Summary Phases.
HP ME Methodology Framework

Abap Cook Book1

Caricato da

Informazioni sul documento

Descrizione originale:

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Abap Cook Book1

Caricato da

Copyright:

Formati disponibili

ABAP COOK BOOK

ASSET BOX CLIENT TYPE

FUSION EMEA D47/R42 010 Development

SAIL PDN 001 R & D Project

ASSET BOX CLIENT TYPE

PD1 016 Development

TS6 016 Integration Test

FT5 016 Staging/Regression

APL 016 Production

RSAP DAP 003 Development

QAP 003 Integration Test

TAP 003 QA /Regression

PAP 003 Production

ASSET BOX CLIENT TYPE

FUSION AMS C30 007 Development

VELOCITY D7A 300 Development

Construction Development Implementation

R & D Project Box Integration Testing Box Staging Box

PD1 TS6 FT5 APL

DAP QAP TAP PAP

C30 C50 C10 R00

D7A D7B D7D D7E

Requesting a New User Account

User Maintenance Request

2.9 Standard templates

SECTION I - Naming Conventions

Ga = Global + originating site code

Definition A table definition in the ABAP Dictionary has the following

Z = Fixed text for custom object designation

y = Site code (1 or 2 characters. site code OR Global + site code)

x = Free form alpha characters describing table function. Project

Examples Z1ORDER_HISTORY Formatted: Strikethrough

Z = Fixed text for custom object designation

y = Site code (1 or 2 characters. site code OR Global + site code)

S_ = Fixed text for structure designation

n = Optional numeric counter if necessary to make the object name

Z1S_BWRFMD BW Reference Models

Z7S_CUFLFI Customer Flat File

Z = Fixed text for custom object designation

y = Site code (1 or 2 characters. site code OR Global + site code)

x = Free form alpha characters describing table type function.

Z = Fixed text for custom object designation

y = Site code (1 or 2 characters. site code OR Global + site code)

x = Free form alpha characters describing Type function.

Examples ZG1EX User Exit type group

Z = Fixed text for custom object designation

V_ =Fixed text for view designation

x = Name of the view based on primary key of table

n = Optional numeric counter if necessary to make the object name

ZG1V_KNA101 for standard SAP table KNA1

Z1V_TFGFCST for custom table Z1TFGFCST

Z3V_FCSTQT for multi-table custom view for forecast quantities

SAP does not require field names in a custom table to be

ZZ = Fixed text for custom object designation

x = Alphanumeric Characters from data element

Custom Table Field

x = Alphanumeric Characters from data element

Examples Table type Field name Data element Domain

SAP ZZWERKS WERKS WERKS

SAP ZZDELFLAG ZG3DELFL ZG3FLAG

Custom DELFLAG Z1DELFL Z1FLAG

Z = Fixed text for custom object designation

y = Site code (1 or 2 characters. site code OR Global + site code)