1.

NAMING CONVENTIONS

Naming conventions specify uniform, binding guidelines for naming software objects
(e.g. classes, function modules) and naming objects in the source code (e.g.
variables).

We strongly recommend stipulating a naming convention as a guideline for any

developments within the SAP system. The aim of using a standardised naming conven-
tion is to significantly enhance the maintainability of customer-specific
modifications and upgrades. This consequently means lower maintenance requirements
and costs as well as faster troubleshooting in the event of an error.

2. NAMESPACE
The separation of customer objects and SAP objects can be facilitated using the
prefixes Y and Z and also via a customer-specific namespace. The syntax is as
follows:

Z� Y�

/<customer-specific namespace>/�

3 READABILITY AND MODULARISATION

� Use natural language (�meaningful� naming of variables, procedures etc. to

reveal your intention)�

� Consistent use of Domain-specific vocabulary

� Avoidance of abstract, unclear terms and abbreviations uniform source code

structure (indentation, writing style)

� Foregoing individual programming styles in favour of a common standard

� Modularisation

� No overly-long/complex procedures

� Avoidance of global variables

4.Code formatting

We recommend using Pretty Printer / Formatter and defining the settings as a

uniform standard. In addition to the settings in Pretty Printer, we also recommend
using functional syntax for method calls and not to use the CALL methode statement.

5.Software structuring with the SAP package concept

Package structures can be formed on the basis of functional, technical and
organisational criteria, whereby the following lists the most common criteria:

� Dependency on software components

� Assignment to SAP standard application hierarchy

� Reusability of development objects

� Grouping of individual applications

� Stability of development objects

� Layer-specific/technical affiliation

� Organisational assignment of incorporated objects

� Translation relevance of development objects

6.INTERNATIONALISATION
Language-dependent texts in programs should not be �hard coded�, but stored in text
elements (program text, class text, online text repository [OTR]), standard text or
message classes. As all independent developments should be of a standard that can
be applied worldwide, all the texts should be translated into the commensurately
principal languages.

7. THE PRINCIPLE OF AVOIDANCE

The components of a computer system that are the most secure, fastest, most
accurate, cheapest, reliable and easiest to maintain and document are those that
are not there.� (Gorden Bell)

8 HARD CODING, MAGIC NUMBERS

Problematic hard coding should be avoided. Magic numbers should be replaced by

distinctly named constants or fur- nished with a suitable comment.

9 OBSOLETE STATEMENTS
SAP has a strict backwards compatibility policy. Nevertheless, be aware that using
obsolete statements such as headers in internal tables will cause problems if the
code is transferred to classes. More up-to-date alternatives are always available
for obsolete language elements. Habit aside, there is little reason to use these
elements and the use of such should consequently be avoided

10 AUTOMATIC CHECKING OF DEVELOPMENT OBJECTS

SAP provides various tools for automatically checking development objects during
design time:

� Simple syntax checking is carried out automatically upon activation and

prevents the activation of faulty development objects.

� Extended Program Check can be executed for specific, already activated source
code (programs, global classes �) and will report potential problems using three
priority levels.

� Code Inspector provides a comprehensive catalogue of checks, some configu-

rable, from which a check variant can be assembled. This includes Extended Program
Check. Numerous performance and stability tests are also encom- passed. In
addition, internal company checks can also be programmed and incorporated.

11 USE EXISTING TOOLS

The tools already available in the SAP system provide excellent support for
creating performant applications and analysing performance issues.

Key transactions are

� ATC/SCI � ABAP Test Cockpit/Code Inspector

Static analysis of performance aspects (amongst other things). Integrated within
Workbench and ADT, administration through transactions ATC and SCI

� SAT � runtime analysis Full analysis at runtime

� ST05 � Performance Trace

Analysis of SQL commands executed within a program (and other events)

In addition, a number of standard tools are available that can also be used for
perfor- mance analysis

� SM50/SM66 � Work Process Overview

� Debugger � step-by-step execution of source code

� ST03 � Workload monitor

� ST22 � Analysis of runtime errors (lack of storage)

� STAD � Workload analysis (post-runtime)

The following tools are suitable for specific performance-related areas

� ST04 � DB Performance Monitor

� DB05 � Analysis of Table with respect to Index Fields

12.DATABASE ACCESS

When accessing the database, five golden rules (source: SAP, see reference in
Section 3.7) are to be complied with to ensure a performant execution of programs
with database access. These five rules are:

1. Keep the result sets small � if the volume of selected data is kept small,
loads are avoided both on the database system and on the network during transfer of
the data to the application server.

2. Minimise the amount of transferred data � as the transfer of data between the
database and application server is in blocks, it is best to keep the volume of data
small to minimise the load on the network.

3. Minimise the number of database access operations � reducing the number of

access operations to the database system minimises the load on both the system and
the network as each access constitutes more work for the database system
administration.

4. Minimise number of queries � using WHERE and HAVING clauses as recommend- ed

further optimises performance if the volume of searching the database system is
reduced by applying the appropriate indices.

5. Minimise (unnecessary) database loads � unnecessary database loads should

generally be avoided; for example, making calculations via database query, the
results of which are not required in the application. In addition, the application
Server ABAP provides numerous options for minimising database loads through
buffering.
Reduction of columns
� Avoid transfer from the database of unnecessary columns, in particular large
objects (for example strings), to prospective performance-critical areas (see
Section 3.2).
� Note: contrary to general opinion, SELECT * and INTO CORRESPONDING FIELDS
themselves often do not pose a problem in these cases as the system intelli- gently
analyses the source and target fields at compi- lation time.34
Optimised query
� When selecting data, try to use one of the existing indices in its entirety.
If this is not possible, at least try and use the first elements of an index so the
database can apply the index to a search.
Line reduction
� Use the WHERE clause to minimise the data to be transferred to the ABAP
system. Use SELECT SINGLE/ UP TO n ROWS if only single lines are required.
Aggregates
� Aggregates (MIN, MAX�) are often (in the case of HANA always) practical as
they have been previously analysed on the database server, so less data has to be
transferred. However, be aware that any existing table buffering cannot be used by
the system in this case, which could have a converse effect.
Updates
� Similar to column reduction when reading, the number of columns to be written
can be reduced using the statement UPDATE SET. This statement should be used
wherever possible.

Large volume operations

� Each execution of an Open SQL statement is associated with a certain overhead
(parsing, check against the DBMS statement buffer etc.). Each statement should
therefore transfer as much required data as possible at once. If the data for 50
orders is required, for example, the data should not be retrieved through 50
individual SELECTs, but rather just one single SELECT query. This is implemented
using the additions INTO TABLE for reading or FROM TABLE for writing access (array
operations).
Avoiding MODIFY
� Do not use MODIFY <DB table>. The statement is extremely critical from a
performance perspective: even using array operations an UPDATE has to be executed
initially per array line, and in case of an error a subsequent INSERT, all of which
can unneces- sarily hamper performance.
VIEWS/JOINS
� Nested and looping SELECT statements should be avoided. Use instead JOINS,
views or the addition FOR ALL ENTRIES.
� Overly extensive JOINS (more than 5 tables) should be avoided as they could
hamper the DB Optimiser.

Observe the following when using FOR ALL ENTRIES:

� If the internal table in the FOR ALL ENTRIES state- ment is empty, the WHERE
clause is ignored and all DB table entries selected. Normally this is not desired
and may result in performance problems. The prob- lem can be solved by checking the
size of the table prior to executing the query.35
� If the internal table in the FOR ALL ENTRIES state- ment contains duplicated
entries, this may result in data sets loading twice from the database or unnec-
essarily bloating the SELECT statement in the DB interface. We recommend executing
DELETE ADJA- CENT DUPLICATES for the internal tables prior to executing the query.
� As using FOR ALL ENTRIES activates an implicit DISTINCT select operation, all
key fields should be selected as otherwise there is a possibility that not all
relevant data sets will be read.

13 INTERNAL TABLES AND REFERENCES

We recommend adhering to the following guidelines for increasing application

performance:
� Choose a suitable table type for subsequent applica- tion. Details on this
are available in the keyword documentation under �Selection of table type�.
� If a Sorted or Hashed table type is accessed, this should always occur using
the appropriate (partial) key.
� Similar to DB access, there are single line and mass access operations for
internal tables. Mass access operations should be used whenever possible be- cause
they perform better than multiple single access operations.
� When using the SORT statement avoid implicit sorting and for reasons of
better verification always specify the desired sort fields.
� Before applying the DELETE ADJACENT DUPLICATES statement, ensure the table is
sorted according to the same fields so that duplicate entries are actually deleted.
� Pure existence checks on internal tables should always be carried out using
READ TABLE TRANS- PORTING NO FIELDS.
� Use standard field symbols for accessing internal tables

14 PASSING PARAMETERS

Passing parameters by value should only be carried out where stipulated on

technical grounds (e.g. RFC function modules, returning parameters in functional
methods). This saves the unnecessary copying costs of passing parameters

15 ROBUSTNESS AND ACCURACY

Robustness is the ability of a program to deliver correct results and not to abort
even in unfavourable circumstances. This principally means programs recognise
errors and respond to them in a way that does not impair the desired functionality.

Conversely, sometimes errors cannot be meaningfully handled and in many cases

imple- mentation of genuine error handling with at least one exception or error
message can prove uneconomical as the probability of occurrence is deemed
exceptionally minimal.

16 ERROR HANDLING
The ABAP runtime environment offers a variety of options for indicating an error to
an application. These options are listed below together with best practices.

i) SY(ST)-SUBRC CHECKS
ii) MESSAGE STATEMENT
iii) CLASS-BASED EXCEPTIONS
iv) EXCEPTIONS THAT CANNOT BE HANDLED

17 CORRECT IMPLEMENTATION OF DATABASE CHANGES

SAP locks are valid across multiple database LUWs (Logical Unit of Work), enabling
consistent database changes to be performed across the entire business object being
changed

18 5 ABAP SECURITY AND COMPLIANCE

This section describes how a programming error in ABAP can negatively impact on
security within a company and what countermeasures exist. The subject of
application security is principally relevant to all programming languages, but in
the case of ABAP has not been given sufficient attention to date. Within this
context, potential risks that may arise within a company as a result of corrupt
ABAP programs are:

� Statutory violations (e.g. infringement of German federal data protection

laws if the programming error leads to the theft of personal data)

� Non-compliance with compliance requirements (e.g. SOX or PCI/DSS)

� Cyber attacks aimed at carrying out industrial espionage, sabotage or
extortion

� Backdoors, which enable extensive insider access to data

� Press reports if vulnerabilities or data theft become known

Custom developed ABAP code in particular, must not pose a risk to the
confidentiality, integrity and availability of business data.
az