abap standards and conventions

Shell Information Services ABAP/4 Standard

ABAP/4 Programming

Standards

2.3

Authors : Fienke HuitemaRoy Faber

Revised by : Eoin Cronan

Jan 2001

18-04-23 of 44

Status : First version : Internal Use Only

Open for Discussion

Distributed to : Employees of Argus Integrated Solutions

Discussed with :

Approved by :


Version log

Version Date Name Changes

0.1 04-1997 Fienke Start

0.2 04-1997 Roy Additions

0.3 23-04-1997 Tony Few comments Sent to several Belgian collegues

0.4 26-04-1997 Fienke Additions and merging several versions

0.5 27-05-1997 Roy version additions

0.61 11-05-1997 Argus Comments, IT

1.0 13-06-1997 Fortis/Argus - First publishing

1.1 13-06-1997 Roy Comments Argus/Fortis - internal documentation- versioning

2.0 27-10-00 Shell Information Services

Updating document to 4.6C

2.1 06-09-01 Eoin Cronan Additional Naming Conventions for ALE and LSMW

2.4 29-01-2002 Suhaiman Mohamad-Nawir

Naming Conventions for Infotype enhancements

2.5 11/07/02 Jalal Ettaoussi Convention for ABAP objects modifications

2.6 22/07/02 Jalal Ettaoussi Naming Conventions for Report Category

18-04-23 of 44


Table of Contents

Version log.......................................................................................................................................... 1Version log.......................................................................................................................................... 2

INTRODUCTION.......................................................................................................4Document feedback............................................................................................................................. 4

PART I. THE HR NAMING CONVENTION...................................................................5Name ranges for Customer Developments............................................................................................5Program names................................................................................................................................... 5Development Class.............................................................................................................................. 9Legacy System Migration Workbench (LSMW) Projects.....................................................................11ALE Message Types and Segments.....................................................................................................12Within your ABAP/4 source…............................................................................................................ 14Variable Names and Internal Tables..................................................................................................14

PART II. HR GENERAL PROGRAMMING GUIDELINES...................................15Declarative elements......................................................................................................................... 15Event Elements.................................................................................................................................. 15Hard-coding...................................................................................................................................... 15Text elements..................................................................................................................................... 16Access to SAP Application Data:.......................................................................................................17Modularization.................................................................................................................................. 17Security............................................................................................................................................. 18Template............................................................................................................................................ 18Object Orientation............................................................................................................................. 19BAPI Programming........................................................................................................................... 21Creating a new BAPI......................................................................................................................... 21Controls............................................................................................................................................ 22Directives Lay-out of reports(print-out) and screens..........................................................................23

SECTION III DOCUMENTATION............................................................................26Program Readability......................................................................................................................... 26Support Documentation..................................................................................................................... 28Online Documentation....................................................................................................................... 28

APPENDIX I SAP DEFINITION OF CUSTOMER NAMING RANGE...............................29Index customer naming range............................................................................................................ 29

APPENDIX II TRANSPORT NAMING CONVENTION..................................................32Transport Request Naming Standard..................................................................................................32

APPENDIX III ABAP/4 PROGRAM CHECKLIST.......................................................36APPENDIX IV ABAP/4 PERFORMANCE..................................................................37

SAP Performance Examples.............................................................................................................. 37Internal Table.................................................................................................................................... 37Database........................................................................................................................................... 37The amount of processes in the query needs to be kept to a minimum.................................................41Unburden the SAP/3 database as much as possible............................................................................41

APPENDIX V EXAMPLE LAY-OUT OF AN ABAP/4 PROGRAM.................................43APPENDIX VI – ASAP DOCUMENTATION TEMPLATE............ERROR! BOOKMARK NOT DEFINED.Appendix VII Useful Reports/Functions/Tables.................................................47

18-04-23 of 44


Introduction

Based on the documents and knowledge shared between Shell and ARINSO, this document was intended to set out a global ABAP/4 Standard. This means that programs in the SAP/3 systems developed by ABAP/4 programmers should follow the conventions as described here.

The document is divided in three parts:

The HR Naming convention, giving strict rules for naming objects in the data dictionary and the ABAP/4 programs, and

The HR General Programming Guidelines, delivering sensible guidelines, which are strongly recommended but are not mandatory.

Documentation Standards, templates to aid in the functional and technical descriptions of developments.

This document is not meant to be a learning course for programming in ABAP/4. However, it can be of help to make more structured programs.

Document feedback

This document is always open for discussion. This means that the reader is encouraged to evaluate the contents of this document and if changes are necessary, please feel free to contact the author(s).

Eoin Cronan : [email protected]

18-04-23 of 44


Part I. The HR Naming Convention

Name ranges for Customer Developments

Customers may only create objects in the SAP environment with names that are not within the SAP name range. This ensures that customer objects are not overwritten during an upgrade. In general, SAP has reserved the letters Y and Z as the first letters for names of customer objects. We propose the prefix Y for Globally developed objects and programs. The prefix Z can be used for local or country specific developments

Note : in ‘Appendix I’ a more detailed list of allowed customer name ranges is provided.

Program names

All program names for applications in HR should follow the naming convention as shown below. The program names take the form:

YGLHMMTTnnn

where :

Y__________ Customer prefix Y : Globally developed productsZ : Local modifications (e.g. Reports)

_GL________ SAP Country ISO Code GL : GlobalDE : GermanyNL: NetherlandsUS: USA

___P______ SAP Module identification H : Human resources PlanningP : Human resources Master DataS : Basis(F : Finance, etc…)

____MM____ Submodule PA : Personnel administrationPT: Time managementPY: PayrollPE: Training & Events ManagementRC: RecruitmentBN: BenefitsPF: Pension FundCM: Compensation ManagementPD: Personal DevelopmentOS: Organisational PlanBC: BasisES: ESSMA: Managers DesktopSP: Shift PlanningEV: Time Evaluation

______TT___ Program type DM : Data MigrationPU : PU12 InterfaceII : Interface inIN : IncludeIO : Interface outIT : Internal interfaceMP : Module poolRD : Report for downloadRR : ReportRU : Report for uploadAL: ALE user exits

________nnn Sequential program number

18-04-23 of 44


Report category

In program attributes, the pushbutton 'HR Report Category' is set up when a logical database is used.

To create the report category:

Go to IMG, Personnel Mgmt-->HRIS-->reporting-->Adjusting Standard Selection Screen-->Create Report Categories.

Please note a new naming convention for report category: 9________XX_____ is the specific number of country grouping (Field Molga ---> T500L-molga )___XXXXX Sequential report category number start at 00001 to 99999

Different ABAP-source

Note: When copies of other (Standard SAP) sources form the basis of your source, the program name of the original ABAP-source should be mentioned at the top of your ABAP-source.This means that the naming convention as stated above will be used for the new program name.

Changing production code

When changing code that is further along the transport route, e.g. in Integration Testing in Acceptance, then that code may have to be backed out to be fixed on development and re-transported to acceptance. To minimise the work lost in this case, a slightly different naming convention should be adopted. When editing an object that has already been transported, the object should be copied and the developers initials should be appended at the end. Then when the program is ready to be released it is renamed back to the original development name.

E.g. Report YGLPPA001 is in QA but needs updating in Development. Developer John Smith makes a copy of YGLPPA001 to YGLPPA001_JS, makes the necessary changes and when ready to release to acceptance, moved YGLPPA001_JS to YGLPPA001.

Infotypes

Enhancements to Infotypes.

Enhancements to PD Master Data are rare but when they happen the system requires that you follow a naming convention in building up the maintenance and list screens.

Maintenance screen : MPXXXX00-0200 List screen : MPXXXX00-3000 Module Pool : ZPXXXX00 Include Modules: Data Definition : ZPXXXX10

PBO Module : ZPXXXX20PAI Module : ZPXXXX30Subroutines : ZPXXXX40

List Structure : ZPLISXXXX

For other type of Infotypes the standard naming convention applies.

Creating new Infotyes.

18-04-23 of 44


When building tables and structures of infotypes the following naming conventions should be used. There are differences in between several infotypes and it should be taken into account when designing your infotype. The following most commonly used infotypes are used:-

When designing an infotype PA Master Data, the following elements are needed: Table : PA9999 Structure : PS9999 Structure used in the ABAP/4 programs : P9999

When designing an infotype Recruitment Master Data, the following elements are needed: Table : PB9999 Structure : PS9999 Structure used in the ABAP/4 programs : P9999

When designing an infotype PD Master Data, the following elements are needed: Table : HRP9999 Structure : HRI9999 Structure used in the ABAP/4 programs : P9999 Sub-structure : HRPAD99 Sub-structure used in the ABAP/4 programs : PAD99

Example : Infotype Recruitment Master DataTable : PB9131Structure : PS9131Program structure : P9131

An infotype consists of several parts where for example the specific tables and structures are called from. These parts are saved in separate modules and the convention used for these parts are:-

18-04-23 of 44


(Module Pool) : MPXXXXYY

MP______ Module Pool Infotype MP : Module Pool

__X_____ Infotype number 9 : for Customization___XXX__ Infotype number Number of the infotype______YY Infotype part 00 : Main Module Pool

10 : all data-declarations in the PBO- and PAI-modules20 : all PBO-modules30 : all PAI-modules40 : all Forms of the PBO-/PAI-modules

Interfaces (PU12) : YGLPIOXXXXE0

YGL---------

ZDE---------

Interface Global InterfaceLocal Interface, (with ISO code)

---X-------- SAP Module P for Human Resources Master Data----IO------ Interface Out------XXXX-- Interface 4 Alphanumeric digit Interface Name-----------E0-----------L0

Program Type E0 = Extraction ProgramL0 = File Layout Program

Note: The associated include’s names should end E1-9, and L1-9.

Convention for common Data Dictionary Objects

Object name Layout Meaning: Bytes Description / Remarks

Domain YGL------- Prefix 3 Domain name (up to 30 bytes)

---+++++++ Freely definable <= 30 SAP standard domains should be used wherever possible

Data Element YGL------- Prefix 3 Data Element name (up to 30 bytes)

---+------ Application identification 1

----++++++ Freely definable <= 30

Matchcode object Y--- Prefix 1 Matchcode object (must be 4 bytes)

-+-- Application identification 1

--++ Freely definable 2

Table YGL------- Prefix 1 Table (up to 16 bytes)


----++++++ Freely definable <= 16

View YGL------- Prefix 1 View (up to 16 bytes)


----V----- Always 'V' for View 1

-----+++++ Freely definable <=

Transaction Y------- Globally Transaction 1

Z-------_DE Local Transaction, ISO code at end

4 e.g. _DE for Germany

-+------ SAP Module 1 e.g. P for Human Resources, F finance

--++---- Submodule 2 e.g. PY for Payroll

----+--- Type 1 e.g. R for Report, I for Interface, D for Dialog, S for ESS screens

-----+++ Sequence 2 Alphanumeric’s

18-04-23 of 44


Application identification for SAP-HR: H : Human resources Planning

P : Human resources Master DataS : Basis

Examples:

YUSPPAYDATA For a table used for a payroll application in USA

YGLHORGAN01 For a globally used data element for a PD application

Note : These conventions for the Data Dictionary form an applied supplement to the Index customer naming range (see appendix I, page 15).

Development Class

Several development classes have been defined for the Galaxy Project to hold developments. All ABAP development and Workbench objects should be assigned to these classes depending on the nature/use of the developments.

The following convention should be adopted

Development

Class

Global/Local

Development

Developments in:

YDEVPA Global Personnel Administration

YDEVPT Global Time management

YDEVPY Global Payroll

YDEVPE Global Training & Events Management

YDEVRC Global Recruitment

YDEVBN Global Benefits

YDEVPF Global Pension Fund

YDEVCM Global Compensation Management

YDEVPD Global Personal Development

YDEVOS Global Organisational Plan

YDEVBC Global Basis

YDEVES Global Employee Self Service

YDEVMA Global Managers Desktop

YDEVSP Global Shift Planning

YDEVEV Global Time Evaluation

YDEVALE Global ALE

YDEVPU12 Global PU12 Interfacing

YDEVWF Global Workflow

ZDEVPA_DE Local PA Developments for Germany

.…

Note: Where developments are Stepping Stone specific, a local development class is created with same name as the global development class, but with a Z replacing the Y and the ISO country

18-04-23 of 44


code at the end. E.g. PA developments for Germany, Global development class is YDEVPA, so local development class is ZDEVPA_DE.

18-04-23 of 44


Legacy System Migration Workbench (LSMW) Projects

There will be a master LSMW project which will be imported at each Stepping Stone Project. As you import the LSMW project, you must rename it to the following1

Project: Stepping Stone Project Name:(Country Code)

Subproject: As Imported

Object: As Imported

Note: Where a project Covers several different Countries the ISO country code should be included in the Project Title.

Code Project Country

Galaxy Galaxy Global Project

ANDROM Andromeda ASEAN

BOOTES Bootes UK

CARINA Carina Brunei and Bangladesh

DELPH Delphinus USA

ERIDAN Eridanus Oceania

FORNAX Fornax Benelux

GRUS Grus Brazil

HYDRA Hydra DACH

INDUS Indus France

LACERT Lacerta Nigeria

MENSA Mensa Scandinavia

OCTANS Octans South America

PAVO Pavo Caribbean

RETIC Reticulum Southern Africa

SAGITTA Sagitta Canada

TUCANU Tucana NWE Africa

URSA Ursa East Mediteranan

VELA Vela Northern Asia

APUS Apus Condor

CASSIO Cassiopeia East Africa

EQUUL Equuleus Iberia

GEMINI Gemini PDO

HERCUL Hercules East Europe

LIBRA Libra M.E.S.A.

E.g.

1 Otherwise it will overwrite the existing LSMW project.

18-04-23 of 44


Project: ANDROM:MY

Subproject: HIRE

Object: DATA

Initial Personnel hire data for Malaysia

E.g.

Project: Bootes

Subproject: HIRE

Object: DATA

Initial Personnel hire data for UK.

ALE Message Types and Segments

The Customer ALE name range allows you to utilise both Y* and Z* ranges. Although the system will still allow you to create Message types and IDOCS in the Y range, if you wish to use change pointers for your IDOCs you will have to create your segment types in the Z range, as this is explicitly checked for in the Change Pointer processing logic.

Object name Layout Meaning: Bytes Description / Remarks

Message Type YGL------- Prefix 3 Globally used Message Type

ZXX------- Prefix 3 Locally used Message Type, where

XX is the ISO country code

e.g. ZMY_Finance – Malaysia specific finance message type

---+++++++ Freely definable <= 30 Provide Info as to the use of the Message Type

IDOC Type YGL------- Prefix 3 Globally used IDOC Type

ZXX------- Prefix 3 Locally used IDOC, where

XX is the ISO country code

e.g. ZMY_Finance – Malaysia specific finance IDOC type

---+++++++ Freely definable <= 30 Provide Info as to the use of the IDOC Type

Segment Z--------- Prefix 1 Customer Name Range

-+++++++++ Freely definable <= 24 Should indicate from which table, view or data source the segment is populated

Customer Model YGL-------- Prefix 3 Global Distribution Model

ZXX-------- Prefix 3 Local Distribution Model

XX is the ISO country code e.g. DE

---+------ Direction 1 (I)Inbound, (O) Outbound, (X) Bi-directional

18-04-23 of 44


----++++++ Freely definable 6

ALE Objects YGL-------- Prefix 3 Global ALE Object

ZXX-------- Prefix 3 Local ALE Object

---_------ Underscore 1

---_++++++ Freely definable 26 Descriptive Text

18-04-23 of 44


Within your ABAP/4 source….

Variable Names and Internal Tables

Variable names may be up to 30 character long. Apart from the special character ( ) + . , : , SAP allows any characters including numbers. However, a name should not consist of numbers alone.

The first(two) character(s) of the variable name should be its type followed by an underscore. The underscore will help to distinguish the variables from SAP data dictionary names. Do not use hyphens (-) in variable names since they indicate field strings. Make the rest of the name as self-explanatory as possible. The way the prefixes should be placed in this order:-

Prefix notation:

<Prefix> _ <Fieldname>

Use the following prefixes:

<Prefix> Description Example

W Global data fields, W_NUMBER

C Constants C_TAXVALUE

SW Switch, boolean. Define as "X" = true and " " = false. SW_SECONDFIGURE

R Ranges. R_DAYS

S Fields on the selection screen of a report. For SELECT-OPTIONS and PARAMETERS.

S_PERNR

L Local fields in a Form. L_SIRNAME

X Parameters of a Form (FORM A USING X_REPLY). X_AMOUNT

O ABAP Objects O_USER

T Defined Data Types T_DATATYPE

I Internal tables I_T512W

<F_xxx> Field Symbols <F_symbol>

P Parameters in a function-definition. P_COUNTER_NUMBER

Modularization

Forms Form name should be separated by underscore only (_). Discourage to use Hyphen (-).

Includes see Program naming conventionModules When a module pool program contains more than one screen (dynpro), the

name of the modules should contain the related screennumber. For example S1000_CHECK_INPUT. If a module is used in more than one screen use NNNN in place of the screen number. E.g. SNNNN_CHECK_INPUT

18-04-23 of 44


Part II. HR GENERAL PROGRAMMING GUIDELINES

Declarative elements

The following lists the declarative elements in the order they should appear in ABAP/4 reports, immediately after the REPORT statement. At least one empty line should occur between each of these elements. An element should only be coded if it is used in the ABAP/4 report. Every element should have a new line. A description of the element must be added as comment. For long programs the data declarations should be in an include.

The order is:

TYPES (preferably in an INCLUDE)TABLESINFOTYPESCONSTANTSDATA (internal tables) DATA (variables and flags)SELECTION-SCREEN, SELECT-OPTIONS, PARAMETERSRANGESFIELD-SYMBOLS

Event Elements

The following are common event elements coded in an ABAP/4 program. These should be coded in the order below, in order to ease the location of the relevant event within the programming code. Only those events that are used in the program should be present.

INITIALIZATIONAT SELECTION-SCREENLOAD-OF-PROGRAMSTART-OF-SELECTIONGETGET LATEEND-OF-SELECTIONAT LINE-SELECTIONAT PFnAT USER-COMMANDTOP-OF-PAGETOP-OF-PAGE DURING LINE-SELECTIONEND-OF-PAGE

Hard-coding

Do not hardcode fixed texts, conditions etc. in the program. Use any of the following methods where possible:

1. pass values from SELECT-OPTIONS or PARAMETERS2. pass values from text elements3. read values from own defined tables

18-04-23 of 44


Text elements

The text-elements should be used so the program can display the texts in the reports in the language the user specifies when logging on, if maintained in that language. Instead of using:

WRITE: / ‘Company’,‘Name’.

or:

WRITE: / TEXT-001,TEXT-002.

you should use:

WRITE: / ‘Company’(001),‘Name’(002).

The last method is preferred because if the text-element is not maintained in the logon language, the original text will be displayed. Moreover, it is also more convenient reading the source code this way.

Convention for ABAP source modifications

The idea is to put in bloc all modifications (Modif/Delet/Add) done by developers who not create the object between to sentences to specify the start and the end of change.

UsercID, Sy-datum, START OF modif/Delet/Add N*, number of (1,2,3...), useful description to start, and

UsercID, Sy-datum, END OF modif/Delet/Add N*, number of modif (1,2,3...) to terminate.

So for example:

NLJET0, 11/07/02 Start of MODIFICATION N*1: Delete the popup when skillpoolcatalog transaction is triggered

* Old Code...* Old Code...* Old Code...* Old Code... New Code... New Code... New Code...

.... NLJET0, 11/07/02 End of MODIFICATION N*1.

18-04-23 of 44


Access to SAP Application Data:

For On-line Reports:

Use Logical Database PNP to access application data wherever possible. You need to activate this database driver by maintaining the report attributes logical database PN and application P. Benefits are:

Select statements are coded by the Logical Database program.

Authorization checks are performed.

Selection screen is provided.

The Logical Database is primarily used with on-line reports. They should not be used when a selection screen is not desired. When you run your report, the logical database loads the personnel data for each employee into the main memory and makes it available for processing. The entire history of each infotype is loaded into the main memory, i.e. all infotype records between the lowest and highest system date. When the next personnel number is selected, the data of the previous personnel number is deleted.

When you specify 'infotypes' in your report, you must know the following:

These infotypes are read during creation of 'logical database'. If you specify infotypes with subtypes and the user hasn't access to all subtypes of this infotype, the persons having these non-authorised subtypes will not be taken into the report for authorization reasons.

E.g. infotype 0014: if a user with only limited access on some wage types in infotype 0014 executes a program specifying 'infotype : 0014', authorization problems will occur. You best use in these cases read_infotype.

The selection screen allows the user, who runs the report to specify the data selection, matchcode selection and sorting condition. The sort function key can be used to sort employees according to name or criteria of organization assignment. You could change the standard selection screen by changing the reporting class.

Modularization

Forms

Forms should be used to make your program more readable and structured. Use always forms if this means that you can use the same form several times.

Each FORM must contain one program function.

All FORMs should be physically located at the bottom of the program (outside of the main processing logic).

Group all Subroutines (SAP Forms) together preferably in an own include. Use a frame, ”Start of Forms”, to indicate the start of the subroutines.

Likewise for Modules.

18-04-23 of 44


Security

It is important that security be build into reports modeled around data as much HR data can be of a sensitive nature and its viewing should be restricted to authorised people. Therefore, we need to include the proper authority checks into the developments.

As mention above, for reporting associating a logical database with a report, will ensure that the correct authority checks are performed when selecting the data. For dialog programming, where you are selecting records, always perform authority checks

Template

As an example, a report template has been created in the system, which can be copied and used as a starting point for new developments. It contains the correct header layout and sections for tables, infotypes, constants, data and selection-screens. It is stored in the report Y_ABAP_TEMPLATE.

Input Screens

As a rule, we should always look to have F4 selection helps for the input fields (excluding text input fields). We should also look to have F1 help provided for the input fields. Where SAP help is available, we should use that but we should program in F1 help if none is available. We should ensure that online documentation is available for the screens.

Where input values have an associated text value, then we should also display that text, next to the input field.

18-04-23 of 44


Object Orientation

Object Orientation is a widely accepted paradigm in the development world, with many OO languages being utilised e.g. Java, C++. SAP is also looking to move to a completely OO environment. From release 4.0, SAP has allowed for the creation of ABAP objects. This was improved in 4.5 with the OO extension and again in 4.6 with the addition of inheritance, nested interfaces, and dynamic method invocation. In release 5.0 we can expect that ABAP will be completely object orientated.

Object Orientation allows for better encapsulation, extensibility, and reuse. It also allows for integration with external object models e.g. DCOM, CORBA. With the use of the Business Objects Repository (BOR), SAP have provided many Object Types, with their associated methods and events. If you define your programs accordingly, then you can make use of these standard Objects.

ABAP Objects is based on classes. Classes are pieces of program code that describe objects by defining their components. Typical object components are attributes (data), which describe an object’s state, and methods (functions), which describe an object’s behavior. Objects are instances of classes. Many objects can be created from one class, but each object has its own attributes.

ABAP Objects provides a set of new statements that defines classes and handles objects. These statements can be used in any kind of ABAP program.

Classes, and therefore objects, consist of at least two layers—an inner and an outer layer. The externally visible layer of an object is made up of public components. Public components can be accessed directly by all users and form an object’s external point of contact. Private components are only visible within objects of the same class. The public section usually contains few attributes. The state of an object is generally kept in private attributes and manipulated by public methods. This way an object can ensure its own consistency.

Outside ABAP Objects, the only instances in ABAP are instances of whole ABAP programs such as reports, module pools, or function groups. Each time a program is executed, a program instance is implicitly created, which then runs in a separate ABAP process. Calling an external procedure (a subroutine or a function module) also creates an ABAP program instance, which contains the procedure. However, repeated calls always use the same one instance. Such program instances live as long as the application program is running and cannot be handled explicitly.

With ABAP Objects, it is now possible to explicitly handle instances. The instances of classes, namely objects, are created explicitly with ABAP statements. They have a unique identity (independent of their attribute values) and are addressed by references. They live only as long as they are needed.

You can define classes and interfaces in ABAP Objects either globally or locally. You define global classes and interfaces using the Class Builder (Transaction SE24) in the ABAP Workbench. These are then stored centrally in the class library within the R/3 Repository. All ABAP programs in the R/3 System can access global classes and interfaces. You define local classes and interfaces within an ABAP program. They can only be used in that program. When you use a class in a program, the system first looks for a local, then for a global class with the specified name. There is no other distinction in using global and local classes or interfaces.

18-04-23 of 44


Example of an Object Orientated program

REPORT demo_class_counter .

CLASS counter DEFINITION.

PUBLIC SECTION.

METHODS: set IMPORTING value(set_value) TYPE i,

increment,

get EXPORTING value(get_value) TYPE i.

PRIVATE SECTION.

DATA count TYPE i.

ENDCLASS.

CLASS counter IMPLEMENTATION.

METHOD set.

count = set_value.

ENDMETHOD.

METHOD increment.

ADD 1 TO count.

ENDMETHOD.

METHOD get.

get_value = count.

ENDMETHOD.

ENDCLASS.

DATA number TYPE i VALUE 5.

DATA cnt TYPE REF TO counter.

START-OF-SELECTION.

CREATE OBJECT cnt.

CALL METHOD cnt->set EXPORTING set_value = number.

DO 3 TIMES.

CALL METHOD cnt->increment.

ENDDO.

CALL METHOD cnt->get IMPORTING get_value = number.

WRITE number.

18-04-23 of 44


BAPI Programming

Object-oriented technology has been implemented in SAP R/3 by making SAP R/3 processes and data available as Business Objects. Business Objects can be accessed by external applications using standardised platform-independent interfaces called Business Application Programing Interfaces or BAPIs. A BAPI is defined in the SAP Business Object Repository as a method, and is implemented as a function module. The separation of the definition and the actual implementation enables a BAPI to be accessed in two ways.

i) For Windows 95 and Windows NT platforms the BAPI is invoked using the method defined in the Business Object Repository. The BAPI ActiveX Control provided by SAP is used to invoke the BAPI methods and allows external applications to access the SAP Business Objects in the Business Object Repository by invoking BAPIs through OLE Automation.

ii) For non-Windows platforms, RFC calls are used to access the function module on which a BAPI is based.

Creating a new BAPI

The creation of a new BAPI for an existing SAP Business Object involves modifying the SAP Business Object. In order to create a new BAPI it is recommended that a new Business Object type is created and that the BAPI methods of the new type are extended. New Business Object types should be created as subtypes for the object type being extended. In this way, the relevant information, such as key fields, interfaces, attributes, methods, and events are copied to the new object (sub)type.

For more information on creating new Business Object types refer to the SAP Business Workflow documentation.

By creating new subtypes from within the ABAP/4 Development Workbench, the underlying program is automatically created with the coding necessary to support the new object. For the most part, this program should not require amending. However, if for any reason the program requires modification then standard SAP macro instructions are available.

The macro instructions are available when the INCLUDE <OBJECT> command is specified as a report section in the object type program. This instruction is added to each object type program automatically when maintaining business objects via the ABAP/4 Workbench.

Container

A container is used for storing data and making it available to individual components in the SAP Business Workflow. Containers may hold:-

field values and multiline lists of field values

object references and multiline lists of object references

A container consists of a number of container elements. A data type reference is defined for each element in a container. The container is named CONTAINER, and exists locally within the object type program. The elements of the container have the same names as the attributes or parameters to be stored within them.

Object Program Macro Instructions

The following macro instructions are available for processing a container.

SWC_SET_ELEMENT write a field value to the container

SWC_SET_TABLE write a multiline list of values to a container

SWC_GET_ELEMENT read a field value from the container

SWC_GET_TABLE read a multiline list of values from a container

18-04-23 of 44


SWC_CREATE_OBJECT assign an object reference to the container

SWC_GET_OBJECT_TYPE read an object reference type from container

SWC_GET_OBJECT_KEY read an object key from the container

The following macro instructions are available for accessing objects in the business object repository.

Variables which contain references to objects are defined with the type SWC_OBJECT.

SWC_CREATE_OBJECT create an object reference

The macro SWC_GET_OBJECT_TYPE and SWC_GET_OBJECT_KEY can be used to read the type and key of the object respectively.

SWC_CALL_METHOD call a method of an object

Example: SWC_CALL_METHOD Object Method Container

The result (container element _RESULT) and the export parameters are stored in the container.

The following macros can be used to access attributes or key fields of an object.

SWC_GET_PROPERTY returns single values

SWC_GET_TABLE_PROPERTY returns multiline values

Attributes that are references to database fields are only read the first time that they are accessed. In order to read them again the SWC_REFRESH_OBJECT macro can be used.

Implementation of BAPI Functionality

The creation of a new BAPI requires the creation of the underlying function module. The function modules that are available for use with BAPIs must have the following characteristics:

- Support the Remote Function Call (RFC) protocol,

- Must be assigned as a method for a SAP Business Object in the Business Object Repository,

- Must be processed without returning any screen dialogs to the calling application, or make use of the SAP update task. (synchronous processing).

Controls

New as of 4.6, SAP have introduced SAPGUI controls. These allow you to split up a screen using docking and splitting controls, which provides greater scope for User Interfaces. These controls can be used to incorporate web browsers, pictures, drag and drop functionality and integration with Windows applications such as Office suite into the GUI. These are Object Orientated and can be utilised by instantiating the relevant control objects.

Examples of these controls can be found in the ABAP Editor (SE38), under Environment Controls Examples

18-04-23 of 44


Directives Lay-out of reports(print-out) and screens

It is important that the screens of your ABAP/4-program are as user-friendly and clear to the user as much as possible. That is why the lay-out of your screen needs to be set up properly. This means that before you start designing your screens, you should start finding the right balance between the unused and active parts of your screen. The active parts can be adjusted by aligning, ranging (text) fields and columns on the screen in a proper way.

SAP Provides Ergonomic examples of reports and Dialog screens that can be used as a template for list processing and Dialog programming. This can be reached through the ABAP Editor (SE38), under Environment Ergonomic Examples (Lists, Screens).

In addition to these templates the suggestions below will help you designing your user screens: -

Information overload Do not show too much information on one screen. The user should be able to focus on the relevant information only when using the screen and not get lost in the mass of detail in a screen. The usage of SELECT-OPTIONS and Report-variants help to increase the usability of your software;

Dialog steps Try to minimize the number of dialog steps when navigating towards your target within the program (say for instance one or two screens deep). Only when the functions become more complex, the number of dialog steps may increase. By adding screens and thus splitting up the measure of functionality of the screen, less information is put away in one screen and decreases the level of complexity;

Checks Check by user input (PAI), but try to keep these checks to a minimum in between dialog steps. When designing the order in which the screens will be presented to the user, take into account that content in previous screens need to be correct for the user to be allowed to continue to the next screen. This means that when an user made an error some screens ago, he or she do not has to go back through all the previous screens to correct the problem.

Order of screen check Check by user input: within the screen check the different fields from up-left to down-right, like the fields appear in the screen. Phase (within the screen-processlogic) the checks of the fields and their relationships between the fields as following :-

1. First : Field size check

2. Second : Field contents check

3. Last : Check on the relations between several fields

Fields check Check by user input : open, when input errors made by the user are detected, with the commands CHAIN..ENDSCHAIN only those fields before INPUT, who are necessary to solve the input error.

18-04-23 of 44


Grouping fields Group all fields, text and text area's logically together. For instance you could use the BOX-option in the screenpainter to group fields.

Fields consistency Place combinations of input fields exactly the same (consistent) way in other screen instances. When you use, for example, within screen 1000, transaction ZAAA using the order : 'name1, name2, address, city', you also should use the same order for screen 1000 in transaction ZBBB.

Boolean For input in a Boolean-way, you can make use of radiobuttons. You can check your input field more easily with a "IF N_INPUTFIELD NE SPACE' for a "true"-situation.

You should leave enough unused 'space' in your screens. Some instruments for helping you designing your screens are:-

1. ULINE - line

2. SKIP - blank lines

3. FORMAT INTENSIFIED ON/OFF - colour intensified

4. FORMAT COLOR - usage of colours

5. Etc.

In reports which are (very) interactive and where action is done repeatedly, function-keys should have a consistent meaning throughout the dialog-process.

In conclusion to these guidelines, there is a short example of screen/report stated below.

Example HEADERPAGE:

<Selection fields of Log.DB> or <Your own design>

Example REPORT

DD.MM.YYYY ZM0000: Overview addresses 9999

---------------------------------------------------------------------

Personnel Name Street Cost Currency

Number

---------------------------------------------------------------------

10000000 Smith, P.A. 2300 East drive 4.540,00 FFR

10000001 Johnson, K. 100, Indylane 3.009 BFR

10000003 McGiver, Th. 4 th avenue 7.241 USD

---End List---

Example FOOTER

…

---------------------------------------------------------------------------------------------------------------------------------

<pageno.>

18-04-23 of 44


Section III Documentation

Documentation in the program

The source code should be documented (in English) so that other programmers can quickly understand the purpose of the program and its flow. Every program must begin with a documentation block. This block must contain information about the program, the programmer and the corrections. The following elements must be present at the top of every program:

Name of the program

Author and company

Date

Correction number and version

Title of program

Short description of the purpose for the program

Details

Construction

Change history (who changed what, when, why)

An example of a documentation block is shown below.

*=================================================================================== * Report : YGLXXXXXX0 * Version: 1.00 * Author : A. Programmer SHELL Date : 21.01.2001 *----------------------------------------------------------------------------------- * Title :

* Purpose: ..................................................................... * * Document: (Name of Technical and/or Functional Spec)

* * Details: (technical description of the report, how does the program work,…) * ..................................................................... * Constr.: Assumptions and constraints *=================================================================================== * Change history *----------------------------------------------------------------------------------- * Correction on version : * New version * Author : ... +(initials)* Date : ... * Reason : ... * Change : ... (description(s) of changes made in the report) *===================================================================================

Program Readability

Indentation

The ABAP programs should have proper indentation. Always use the PRETTY PRINTER after editing the programs, when you did not indentation manually.

Use for every command and component a new line. For example, when using the select statement, each selection criterion is on a new line.

18-04-23 of 44


For example:

SELECT * FROM TABLE1 WHERE FIELDNAME1 = S_PAR1 AND FIELDNAME2 = ‘400’ OR FIELDNAME3 = TABLE2-FIELDNAME4.

WRITE: TABLE1-FIELDNAME1, TABLE1-FIELDNAME2, TABLE1-FILEDNAME3.

ENDSELECT.

Comments

The ABAP programs should be well documented with clear and concise comments alongside the program codes in mixed case. Comments in the program are useful. They should explain what the code is doing, not how it is doing it. When the complexity of a piece of source is (too) high, additional comments are needed.

For example:

SET PARAMETER id 'BDC' FIELD LOG."Parameter id needed for"BDC logging."The LOG field is updated"at when releasing BDC

In addition, the following entities of a program should also be documented:

a) Table names

b) Variable names

c) Function calls

d) Modules

e) Forms

Comments when the ABAP/4 source will be changed

When a ABAP/4-source will be changed, the change history block in the documentation header block need to updated with the changes. In the change history block the functional descriptions of the changes will be notated. It will also be necessary to add comments per changed line in the source. You will add the initials and the date of the changes in the comments. In case when an OSS-note is responsible for the change in the source, make sure you place the OSS-number also in the line-comment.

For example:

SUBMIT (ZSREPORT) AND RETURN. "FHU220497 external logging

ADD 1 TO W_ALERT. "OSS NOTE 1234567

18-04-23 of 44


Support Documentation

In addition to the ABAP source code being well documented, the development should be supported by Functional & Technical specifications and a well-defined Test Procedure. The ASAP implementation assistant provides us with a standard template to create a standard look and feel to the documentation. The ASAP implementation tool helps define requirements for developments and can also be used to generate some of the functional specification document.

The Documentation template is attached in Appendix V, which should be completed and checked as part of the User Acceptance Testing.

Online Documentation

Documentation can be copied from functional and technical specifications. Links to the glossary and hypertext can be used to provide meaningful data and references.

The system provides four standard sections.

Description

This section should contain the following:

1) A description of the business case for the program and what it does from a business perspective. This portion has the purpose of guiding an end user in the proper application and operation of the program, consequently this would be written, or copied from the specification provided, by the person who identified the original functionality gap.

2) A brief functional description of the program; this has the purpose of indicating to a technical support person what the program does. This would be written by the programmer. NB. This would not contain how the program works - this should be documented with the program code.

Preconditions

A description of what this program expects upon execution. This may need to be both from a technical and a business perspective.

Output

What the program is expected to produce. Include any special formatting / media notes in this description, and also the name (if applicable) of any programs that are expected to use the output.

Examples

If possible, some simple examples of what the program will do are to be included here. This will mainly be to help an end user and so the examples should be created in conjunction with the business users.

18-04-23 of 44


Appendix I SAP definition of customer naming range

Customers may only create objects in the ABAP/4 Dictionary with certain names, which are not used by SAP. This ensures that customer objects are not overwritten in an upgrade.

The following overview gives the customer name ranges currently specified for objects of the ABAP/4 Dictionary.

Object Name length Customer name range Example

Domain 30 Y*, Z* YNAME, Z1234

Data element 30 Y*, Z* ZNAME, YNAME12

Matchcode object 4 Y*, Z* YMCO, ZMCO

Matchcode ID 1 0 to 9 YMCO1, ZMCO7

Pool/cluster name 10 Y*, Z* YPOOL, ZCLUSTER

Lock object 10 EY*, EZ* EYNAME, EZNAME

Structure 16 Y*, Z*, T9*, P9* YSTRUCT

Transparent table 16 Y*, Z*, T9*, P9* YTAB1, ZTAB2

Index ID 3 Y*, Z* Y12, ZAB

APPENDs 16 Y*, Z* ZAPPEND

Fields 30 YY*, ZZ* ZZFIELD

Pooled/cluster table 16 Y*, Z*, T9*, P9* YPOOL, ZCLUSTER

View 16 Y*, Z* YVIEW

Help view 10 H_Y*, H_Z* H_ZVIEW

Customer includes 16 Cl_* Cl_KUNDE

Index customer naming range

The following index contains all objects with their naming convention and the reference to the page in the document. It can be used as a quick reference guide or the index.

Legend:

= must equal to

<= less than or equal to

<A-ID> application id (H=Human Resource Planning, F-Finance etc.)

<T> I for Inquiry, P for Processing/Update

* freely definable

Object Length of name Customer reserve Application log

Object 4 Z*, Y*

Subobject 10 Z*, Y*

18-04-23 of 44


Object Length of name Customer reserve Authorization/Profile <=12 <A-ID>:*, <A-ID>:*

Authorization object <=10 Z_*, Y_*

Authorization group for report <=8 Z<A-ID><T>*,Y<A-ID><T>*

Authorization group for table =4 Z<A-ID>*, Y<A-ID>*

Batch input session <=12 <A-ID>-*

Batch job name <=32 <A-ID><A-ID>***_*

Change document object 10 Z*, Y*

Data element <=30 ZZ<A-ID>*, YY<A-ID>*

Dialog module <=30 Z*, Y*

Domain <=30 ZZ*, YY*

Dynpro number =4 9000 - 9999

Development class =4 Z<A-ID>, Y<A-ID>

Form <=16 Z*, Y*

Function modules <=30 Z_<A-ID>* ,Y_<A-ID>*

Function group =4 Z<A-ID>*, Y<A-ID>*

Infotype number 4 9000 - 9999

Logical database =2 Z* , Y*

Matchcode ID =1 0 - 9

Matchcode object =4 Z<A-ID>*, Y<A-ID>*

Message ID =2 Z<A-ID>, Y<A-ID>

Message number =3 900 - 999

Number range document object 10 Z*, Y*

Pool name/cluster name 10 Z*, Y*

ID of the relation 2 Z*, Y*

Report <=30 Z<A-ID>*, Y<A-ID>*

Report class =4 Z*, Y*

Report variant

globally transportable 14 X*

locally transportable 14 Y*

not transportable 14 Z*

R/3 Analyzer

Identifiable 20 Z*, Y*

SAPscript

Layout set 16 Z<A-ID>*, Y<A-ID>*

Style <=8 Z*, Y*

Text ID =4 Z<A-ID>*, Y<A-ID>*

Standard texts name <=32 Z*, Y*

SPA/GPA parameter =3 Z<A-ID>*, Y<A-ID>*

Lock object 10 Z*,Y*

Spool

Device type <=8 Z*, Y*

Font families <=8 Z*, Y*

System barcodes <=8 Z*, Y*

Page format <=8 Z*, Y*

18-04-23 of 44


Object Length of name Customer reserve Format type <=16 Z*, Y*

SYSLOG messages =2

Table

(Pool,cluster,transparent) <=16 Z<A-ID>*, Y<A-ID>*

(Internal) <=16

Table field <=30 Z*, Y*

Table index <=3 Z*, Y*

Transaction code <= 20 Z<A-ID>*, Y<A-ID>*

Types 5 Z*, Y*

View <=16 Z<A-ID>V*, Y<A-ID>V*

Help view 10 H_Z<A-ID>*, H_Y<A-ID>*

View maintenance data

View contents reserved in TRESC

Table contents reserved in TRESC

Workflow object types 10 Z*, Y*

18-04-23 of 44


Appendix III ABAP/4 program checklist

Object:__________________ Date:_______ Author:_____________ Tester:_____________

Documentation

Is the English (and/or: local language) Online documentation (in SAP/3) available?

Are the HELP pages, text-elements, etc. available (and translated) ?

Sourcecode

Are comments used in the source in English?

Are all the descriptions used in your ABAP-source easy to read and are the amount of descriptions ?

Are all declarative/events elements accompanied with the necessary comments?

Are all variables & forms in conformity with the Naming Convention (also from SAP)?

Is the program-description-block implemented and is it correctly filled in at the begin of the ABAP/4 source code?

Are all SELECT's accompanied with the necessary AUTHORITY-CHECK's?

Have you used MODE N for time infotypes (2000 - 2999)

No PROVIDE statement, join or projection to process time infotypes.

Are all DATA/TABLE/FIELDNAMES-declaratives put on a single line with the appropriate description?

Are the lines of source grouped logically?

Are the declarative elements/events set in the correct order of appearance? (see Declarative Elements/Events)?

Is the size of the forms you are using very large? If so, put it in a separate include.

Have you used line indentation in your source code (pretty printer)?

Have you freed the internal table, when no longer used in the program?

Screen/Printer Output

Is a user able to understand the way the output is presented of the screen/printer?

Is the error-messaging clear so the user knows what to do? (check SY-SUBRC-settings)

Are all relevant fields on the screen grouped logically (e.g. using BOX in screenpainter)?

Is the Header/Footer correct?

Are the field-calculations, -colours, -names correct?

Program

After using the advanced debugger, is the program free of bugs?

Have you used the Runtime-analyse and is the performance acceptable e.g. does not exceed max. on line runtime?

18-04-23 of 44


Appendix IV ABAP/4 Performance

To get the best performance of your ABAP/4 programs, the following rules are recommended when programming your program: -

SAP Performance Examples

The ABAP workbench contains programming performance examples including SQL examples, String Manipulations, Internal Tables and Conversions. It is recommended that you incorporate these examples into your developments. The examples can be accessed via the ABAP Editor (SE38) under Environment Performance Examples.

Internal Table

When defining the size of the internal table (OCCURS), use the size of the table you are importing into your internal table as an indication. This means that when the table is referenced for the first time, the system reserves memory for the internal table. If the table exceeds the reserved space in memory, usage of memory is less efficient which in turn reflects on the system's performance;

If an internal table is no longer needed, use the FREE statement to free system memory occupied by the table;

For reasons of efficiency use always (if possible) the SORT…BY statement rather than SORT, when sorting an internal table;

When importing data from a table into an internal table and only a few table fields are needed, use the MOVE-statement instead of the MOVE-CORRESPONDING-statement;

If the entire key of an internal table is known, use the READ TABLE-statement to fetch the desired table entry. If this key is incomplete, make use of the binary search-statement. E.g. READ TABLE itab WITH KEY key = key_entry BINARY SEARCH;

Use the COLLECT-statement only if the internal table consists less than 50 entries.

Database

To achieve the best performance of an ABAP/4-program it is necessary to keep the amount of data handling between the database and the program as low as possible. With other words: try to limit the amount of data traffic on the network to the client. Stated below there is a list with some guidelines.

The amount of data traffic between the SAP/3 Database and the application needs to be kept to a minimum.

When using certain options in the SELECT-line, network traffic between the DBMS and the application further reduced.

Use your data selectively

When a small number of datafields is necessary, only the datafields, which are needed should be read.

18-04-23 of 44


Example: instead of..

SELECT * FROM table WHERE condition.

..processes..

ENDSELECT.

Do..

SELECT field1 field2 field3 INTO ( f1, f2 )

FROM table WHERE condition.

..processes..

ENDSELECT.

Use of aggregate functions

Program functions can be used in your SELECT-statement so the DBMS can perform certain computations when reading the database instead of moving large amounts of data to the application.

The following program functions are available for this purpose: -

MAX Finds the largest value

MIN Finds the smallest value

AVG Calculates the average value

SUM The sum of a column

COUNT ( DISTINCT <f> ) Gives the number of different values of a column (<f>)

COUNT ( * ) Gives the number of lines per (sub)total. When using the GROUP-BY option in the SELECT-line, the number of lines per group will be given.


Sum = 0.

SELECT * FROM table WHERE year = ‘1995’.

Sum = sum + tab-amount.

ENDSELECT.

Do..

SELECT SUM( amount ) INTO sum FROM table

WHERE company = ‘0001’

GROUP BY year.

..processes..

18-04-23 of 44


ENDSELECT.

Note : this kind of functions can not be used in pooled- and cluster-tables.

In general it is more efficient to import all data into the memory of the application, instead of browsing the table several times.

Use Internal Table operations - INSERT

When inserting a set of records into a table, the insert functionality is much faster than the LOOP AT / INSERT solution


LOOP AT itab.

INSERT INTO dbtab VALUES itab.

ENDLOOP.

Do..

INSERT dbtab FROM TABLE itab

ACCEPTING DUPLICATE KEYS.

IF sy-subrc = 4.

..error handling..

ENDIF.

Note: In the above example, duplicate records will be ignored.

Do not update work area's

When performing simple calculations (like incrementing values in a field), it is advisable to write the directly to the table in the database, instead of performing the calculation in your program. In the first example (stated below) all records are transported from the DBMS to the application and back. The second example only a single task is sent to the table (hence it appears that no data is transported to the application).


SELECT * FROM table WHERE condition.

Tab-field = Tab-field + var1.

UPDATE tab.

..processes..

ENDSELECT.

Do..

18-04-23 of 44


UPDATE tab SET field = field + var1

WHERE condition.

Avoid nested SELECT's

Using nested selects is a technique with a low performance. The inner select statements are executed several times which might be an overhead. In addition more data is transferred in comparison to other techniques.

To avoid nested loops Implement a join as a view in the ABAP/4 dictionary


SELECT * FROM pers WHERE condition.

SELECT * FROM persproj WHERE person = pers-persnr.

..processes..

ENDSELECT.

ENDSELECT.

Do..

* VIEW persjproj_view in ABAP/4 DDIC

SELECT * FROM persjproj_view WHERE condition. ?????check!

..processes..

ENDSELECT.

Narrow down your selection as much as possible

Use as many Constraints in the SELECT-statement as possible, especially on key-fields, the statement can be executed very fast.

Example:

SELECT * FROM BKPF

WHERE mandt = '001'

AND bukrs = '0002'

AND belnr = '000000005'.

..processes..

ENDSELECT.

18-04-23 of 44


The amount of processes in the query needs to be kept to a minimum

Always try to pecify all known conditions in the WHERE-line to minimize the amount of data requested. In case there is no WHERE-line in the query specified, the DBMS can not perform any optimizations.


SELECT * FROM table.

CHECK field1 = ‘NAME’.

CHECK field2 = ‘STREET’.

..processes..

ENDSELECT.

Do..

SELECT * FROM table

WHERE field1 = ‘NAME’ AND field2 = ‘STREET’.

..processes..

ENDSELECT.

Note : In some cases when all data has to be read from a table (for example when reporting on all companies, Client Copies, Utility function, etc) the WHERE-line can be left out of the query.

Unburden the SAP/3 database as much as possible

The DBMS is a central resource in the R/3 system. It is shared by all users. Everything should therefor be done to take the load of it.

Tables can be buffered in R/3. Buffering is only recommended for read-only or read-mostly tables.

Check whether an application reads the same data repeatedly. This is not only a question of performance. R/3 usually reads the database in uncommitted mode and thus reading a record twice can lead to a different result;

Performing a SELECT before an UPDATE or DELETE of a record just to check whether the record exists is superfluous. Check the SY-SUBRC after updating or deleting.

For large batch jobs, the new language element OPEN CURSOR…WITH HOLD should be used. Please refer to the documentation

There are two ways to get ordered data. The data can be selected using the addition ORDER BY in your SELECT-statement from the database. This is advisable for large amounts of data because the database system us the only component in R/3 with really huge resources. Ensure that the ORDER BY can use an index. When rather small data is to be done with ABAP use the SORT statement on your internal table.

SAP Open SQL statements should be minimized to reduce I/O processing. SQL statements should normally be issued once and stored in work areas for further processing.


SELECT * FROM T9XXX WHERE <KEY1> = …

18-04-23 of 44


MOVE-CORRESPONDING T9XXX TO <internal database>.

APPEND.

ENDSELECT.

Do..

SELECT * FROM T9XXX INTRO TABLE <internal database>

WHERE <KEY1> = ..

18-04-23 of 44


Appendix V Example Lay-Out of an ABAP/4 Program

<Heading-part, see example mentioned in HR General programming guidelines>

Report ... USING DATABASE PNP

MESSAGE-ID ZZ

NO STANDARD PAGE HEADING

LINE-SIZE 130 “Landscape, default

* LINE-SIZE 80 “Portrait

LINE-COUNT 62(2).*-----------------------------------------------------------------------------------

* TABLES

*-----------------------------------------------------------------------------------

Tables ... “<description per table>

*-----------------------------------------------------------------------------------

* INFOTYPES

*-----------------------------------------------------------------------------------

Infotypes ... “<description per Infotype>

*-----------------------------------------------------------------------------------

* DATA: INTERNTAL TABLES

*-----------------------------------------------------------------------------------

DATA: BEGIN OF … OCCURS 0, “<description of table>

END OF … “<descriptions per field if necessary>

*-----------------------------------------------------------------------------------

* DATA: CONTSTANTS

*-----------------------------------------------------------------------------------

RP-DEF-BOOLEAN. “Define ‘BOOLEAN’, ‘TRUE’,

“ ‘FALSE’

CONSTANTS: B_TEST LIKE BOOLEAN VALUE ‘X’, “Switch for test-mode

… “<description per constant>

*-----------------------------------------------------------------------------------

* DATA: VARIABLES

*-----------------------------------------------------------------------------------

DATA: WU_POS_PAGE_NO LIKE SY-PAGNO,“Position of page-no

WI_TEST_REC_COUNT TYPE I, “Record counter for test

… “<description per constant>*-----------------------------------------------------------------------------------

* SELECTION-SCREEN

*-----------------------------------------------------------------------------------

SELECTION-SCREEN BEGIN OF BLOCK FRAME_1 WITH FRAME

18-04-23 of 44


TITLE ‘Overview’(001).

SELECTION-SCREEN END OF BLOCK FRAME_1.

*-----------------------------------------------------------------------------------

* INITIALIZATION

* Note: initialization of variables and any other action you want to run

* before the actual program starts, for example authority-check.

* For complilation-reasons AFTER selection-screen.

*-----------------------------------------------------------------------------------

INITIALIZATION.

* AUTHORITY-CHECK object …

* Initialization of variables

CLEAR: WU_POS_PAGE_NO,

WU_TEST_REC_COUNT,

…

*-----------------------------------------------------------------------------------

* AT SELECTION-SCREEN ON <field>

* note: field specific checks can be performed here, for example check whether an

entered country exists, if an entered number is valid, etc.

*-----------------------------------------------------------------------------------

…

*-----------------------------------------------------------------------------------

* AT SELECTION-SCREEN

* note: relations between fields can be checked at this event.

*-----------------------------------------------------------------------------------

…

*-----------------------------------------------------------------------------------

START-OF-SELECTION. *-----------------------------------------------------------------------------------

* <describe initial actions before first record of LDB is read.>

*-----------------------------------------------------------------------------------

PERFORM FIRST_PAGE. “Print first page with parameters and

“ select-options.

…

*-----------------------------------------------------------------------------------

GET PERNR.

* <describe processing of record>

*-----------------------------------------------------------------------------------

* If in test-mode: quit after 100 records and goto end-of-selection.

18-04-23 of 44


…

* Check whether the selected person is valid.

RP-PROVIDE-FROM-LAST p0002 SPACE PN/BEGDA PN/ENDDA.

…

*-----------------------------------------------------------------------------------

GET PERNR.


*-----------------------------------------------------------------------------------

* If in test-mode: quit after 100 records and goto end-of-selection.

IF B_TEST = TRUE.

…

* Check whether the selected person is valid.

RP-PROVIDE-FROM-LAST p0002 SPACE PN/BEGDA PN/ENDDA.

…

*-----------------------------------------------------------------------------------

END-OF-SELECTION.


* Example: read internal table and process it.

*-----------------------------------------------------------------------------------

LOOP AT …

AT NEW …

* Go to end-of-page section (command NEW-PAGE skips this section)

ENDAT.

* Write data to report.

WRITE: /(…) …,

…

*--------

AT END OF …

…

ENDAT.

*--------

AT FIRST …

…

ATEND.

*--------

AT LAST …

…

ATEND.

*--------

ENDLOOP.

18-04-23 of 44


…

* Marking of “End of list”

SKIP 2.

FORMAT COLOR COL BACKGROUND INTENSIFIED OFF.

WRITE AT 10 ‘--- End of List ---‘(r01).

* Go to end-of-page section (command NEW-PAGE skips this section)

*-----------------------------------------------------------------------------------

TOP-OF-PAGE.

*-----------------------------------------------------------------------------------

…

*-----------------------------------------------------------------------------------END-OF-PAGE.

*-----------------------------------------------------------------------------------

…

18-04-23 of 44


Appendix VI Useful Reports/Functions/Tables

Included below are some useful reports.

Report Program Name Description

SAPMSABAPDEMOS_TREE Displays ABAP documentation & examples (Transaction ABAPDOCU)

RSHOWTIM Displays tips and tricks for ABAP Programming

RSANAL00 Program analysis

RSABAPIV Lists all ABAP commands

RSTXTRAN Transfer text between clients with transport number

RSBDCSUB Initiates Batch input sessions to run automatically when scheduled

RSDYNL10 List all DYNPROs which belong to a specific ABAP

RSTXSCRP Transports SAPscript without transport number

RSTXR3TR Transports SAPscript with transport number

RSTXFINF List information about a SAPscript form

RSTXFCON Conversion of paper format for SAPscript forms

RSTXFCOM Compares two SAPscript forms

Useful FunctionsBelow is a list of useful functions you may use in your own programs. SAP provides several which you should use as much as possible to avoid redundant code. The functions themselves can be accessed via the Object Repository or the function builder (transaction SE37).

Batch Input Sessions (BDCs)

BDC_OPEN_GROUP

Creates a new batch input session

BDC_INSERT

Creates a record in a batch input session

BDC_CLOSE_GROUP

Closes the batch input session

BDC_DELETE_SESSION

Deletes the batch input session

Text Processing

READ_TEXT

18-04-23 of 44


Reads text from the specified object into an internal table

READ_STDTEXT

Reads standard text into an internal table

Date Processing

DATE_COMPUTE_DAY

Determines the weekday as a numeric value (1-7) from a date specified

DATE_CONVERT_TO_FACTORYDATE

Determines the factory calender date from a date specified

DATE_GET_WEEK

Determines the week of the year given a specified date

EASTER_GET_DATE

Determines the Eastern date given a specified date

FACTORY_CONVERT_TO_DATE

Determines date given a factory calender date

HOLIDAY_CHECK_AND_GET_INFO

Determines if a given date is a holiday and if so, gives information

WEEK_GET_FIRST_DAY

Determines the first day of the week for the week a specified date falls upon

Popup Windows

POPUP_TO_CONFIRM_LOSS_OF_DATA

Displays a pop-up window asking the user for a decision on loss of data

POPUP_TO_DECIDE

Displays a pop-up window asking the user for a decision on customizable information

POPUP_TO_CONFIRM_STEP

Displays a pop-ip window to confirm further processing

POPUP_TO_FILL_COMMAND_LINE

Displays a pop-ip window for user command input

Useful Dictionary Tables and StructuresThe following are tables that are useful in custom developed programs for reference and/or validation purposes.

18-04-23 of 44


Table Name Table Type Use

DD03L Trans. Table All tables in the data dictionary and their fields

NRIV Trans. Table Number Ranges

BDCDATA Structure Structure of table for batch input processing

BDCMSGCOLL

Structurestructure of table to hold all system messages during a CALL TRANSACTION command

T000 Trans. Table Client Codes

T100 Trans. Table System Messages

TADIR Trans. Table Directory of transportable developments

TDCT Trans. Table Directory of dialog modules

TDEVC Trans. Table Development classes

TFDIR Trans. Table Directory of function modules

TLIBG Trans. Table Function groups

TFLIBT Trans. Table Fuction groups short text

TRCL Trans. Table ABAP report classes

TRCLT Trans. Table ABAP report classes texts

TRDIR Trans. Table Directory of reports

TRESE Trans. Table Reserved words

TSTC Trans. Table Transaction codes

TSTCT Trans. Table Transaction code texts

TVARV Trans. Table Select variables for ABAP variants

TVDIR Trans. Table Directory of table views

SYST Structure

Internal table filled by SAP during runtime. A developer can reference the runtime environment for their program through the fields of this structure using the "SY-" prefix before the structure field name. There are several useful fields, but the most commonly used is "subrc" in "sy-subrc" statements which gives the return value of processes.

SCREEN Structure

Internal table filled by SAP during runtime. Attributes of the current screen-fields may then be accessed. Screen-field contents, however, can only be accessed and changed within a "LOOP AT SCREEN....ENDLOOP" statement.

18-04-23 of 44

abap standards and conventions

Documents

abap4 programs

abap4 source

abap4 program43appendix

abap4 programmers

naming objects

global abap4 standard

eoin cronanjan

documentation standards