Process:

Development guidelines for ABAP development

Document History

Table of content:

Name space              3

Object transport between systems              4

Development life-cycle              5

Naming convention              6

Program Internal Objects              6

Method/module/form names              7

Data dictionary names              8

Function Groups and Function Modules              8

Includes              8

Classes              9

ABAP OO              10

Model-View-Controller model              11

Identifying Entities              12

Dynpro programming              13

Event blocks              14

Program structure              15

Code layout              17

Internal tables              18

Performance optimization              19

Internationalization              20

Documentation support              21

Messages              22

Customizing              23

Condition statement result check              24

Transports management              25

Other rules              26

Object transport between systems

The development will be divided into more or less separate areas. Each area creates and uses its own package(s). Objects from one package should normally be transported via separate transports.

To decrease the probability of cross-dependencies between transports – there will be also global package introduced. It will contain global objects relevant for the whole development (so mostly technical “tools”). This will be transported separately as well.

The decision regarding the transport of the development will be done by responsible area developer.

The transport requests will be coordinated by the development coordinator (or another dedicated person indicated by him).

The transport request description should start with area code (MM,SD, ZVD etc.) followed by colon “:”. The rest of the text describes the content of the transport in more detail (could be the specification number for instance).

Development life-cycle

·         The development starts with the official request (from the project team)

·         This one most come together with the request specification

·         The specification is checked by development coordinator

·         In case of any questions the specification is being reworked

·         The specification with the right quality can be a base for further steps

·         A Specification should also contain the test cases – requesting party is responsible to prepare the test data. Otherwise the result of the development cannot be checked. The quality of the first version of application send to final tests is strongly connected with the quality of the test data provided.

·         The authorization concept should be known as well, before starting the development

·         Based on the request specification development coordinator (maybe with help of the developer) prepares the technical specification.

·         Technical specification is forwarded to the developer

·         Developer creates the application and tests it (on DEV or Q system – depending where test data are prepared).

·         Developer informs about development end.

·         The Application is tested by the requesting party (semi test by development coordinator possible as well).

·         Developer receives the test protocol – and corrects found errors.

·         Developer informs about development end… and so on…

·         Development is confirmed as ready by the requesting party.

Naming convention

·         English is the only official language in naming development objects.

·         Use a singular word form (without ending s) - for instance ZZORDER instead of ZZORDERS.

·         Some of the names described later must keep to SAP rule that own names must start with Z or namespace. If you use namespace you don't need to start object names with Z any more. To make this document more condensed and easier to understand: in our rules we would always use only Z form, but it should be replaced by namespace if you create objects within namespace.

·         In some object names, we would use also placeholder <id>, which stands for application area (like MM,FI etc.) or any area defined within the project - for instance ZVCD. The decision which areas are defined in the project belongs to the development leader. It would be the best to limit the number of characters in <id> to maximum 4.

Program Internal Objects