DSAG RECOMMENDATIONS BEST PRACTICE GUIDELINES FOR ... · that much has changed in SAP development...

DSAG RECOMMENDATIONS

BEST PRACTICE GUIDELINES FOR DEVELOPMENT –USEFUL TIPS FOR ABAP DEVELOPMENT

Authors: Dr. Christian Drumm, Head of Application Development & Consulting, FACTUR Billing Solutions GmbH

Martin Fischer, Portfolio Unit Manager SAP Database & Technology, BridgingIT GmbH

Judith Forner, Senior Consultant Finance & Controlling, Mundipharma Deutschland GmbH & Co. KG

Edo von Glan, SAP Developer, Drägerwerk AG & Co. KGaA

Florian Henninger, Senior Consultant SAP Development, FIS GmbH

Martin Hoffmann, Head of Software Engineering, Miele & Cie. KG

Valentin Huber, Senior IT Consultant, msg systems ag

Jens Knappik, SAP System Architect, thyssenkrupp Materials Services GmbH

Dr. Christian Lechner, Principal IT Consultant, msg systems ag

Steffen Pietsch, Head of Backoffice, Haufe-Lexware GmbH & Co.KG

Daniel Rothmund, IT Business Analyst SAP, Geberit Verwaltungs GmbH

Holger Schäfer, Business Unit Manager, UNIORG Solutions GmbH

Denny Schreber, Senior Solution Architect, cbs Corporate Business Solutions Unternehmensberatung GmbH

Andreas Wiegenstein, CEO, SERPENTEQ GmbH

Bärbel Winkler, System Analyst SAP Basis/Programming, Alfred Kärcher GmbH & Co. KG

Further information on the authors can be found in Section 11 ‘The Authors’.

BEST PRACTICE GUIDELINES FOR DEVELOPMENT

USEFUL TIPS FOR ABAP DEVELOPMENTVersion: 2.0

Updated: September 2016, translated February 2018

DSAG RECOMMENDATIONS – BEST PRACTICE GUIDELINES FOR DEVELOPMENT -2-

THANK YOU TO ALL THE PARTICIPANTS

Special thanks go to those SAP employees who actively supported compilation of the 2nd edition of the guide with their reviews, discussions and constructive ideas. In particular we would like to thank Jürgen Adolf, Carine Tchoutouo Djomo, Olga Dolinskaja, Thomas Fiedler, André Fischer, Dr. Thomas Gauweiler, Oliver Graeff, Michael Gutfleisch, Martin Huvar, Karl Kessler, Michael Schneider, Harald Stevens, Christoph Stöck, Dr. Wolfgang Weiss, Wolfgang Wöhrle and Margot Wollny.


CONTENTS

1 INTRODUCTION 8

1.1 MOTIVATION & YOUR COOPERATION 8

1.2 POSITIONING 8

1.3 AMENDMENTS IN THE 2ND EDITION 8

2 PROGRAMMING GUIDELINES 9

2.1 NAMING CONVENTIONS 10

2.2 NAMESPACE 11

2.3 READABILITY AND MODULARISATION 11

2.4 SEPARATION OF PRESENTATION AND APPLICATION LOGIC 17

2.5 INTERNATIONALISATION 18

2.6 DYNAMIC PROGRAMMING AND AUDITABILITY 19

2.7 NEW LANGUAGE ELEMENTS 20

2.8 OBSOLETE STATEMENTS 22

2.9 AUTOMATIC CHECKING OF DEVELOPMENT OBJECTS 22

2.10 HARD CODING, MAGIC NUMBERS 23

2.11 AUTHORISATION CHECKS IN SOURCE CODE 24

2.12 PROGRAMMING MODEL: OBJECT-ORIENTED VS. PROCEDURAL 24

2.13 DEVELOPMENT LANGUAGE 25

3 PERFORMANCE 25

3.1 THE PRINCIPLE OF AVOIDANCE 25

3.2 PERFORMANCE OPTIMISATION ONLY IN THE APPROPRIATE AREAS 25

3.3 USE EXISTING TOOLS 263.4.1 Data model 273.4.2 Database access 273.4.3 ABAP Core Data Service (CDS) Views 29

3.5 INTERNAL TABLES AND REFERENCES 303.5.1 Field symbols 313.5.2 Passing parameters 31

3.6 CODE PUSH DOWN 32

4 ROBUSTNESS AND ACCURACY 33

4.1 ERROR HANDLING 334.1.1 SY(ST)-SUBRC checks 334.1.2 MESSAGE statement 344.1.3 Class-based exceptions 344.1.4 Exceptions that cannot be handled 36

4.2 CORRECT IMPLEMENTATION OF DATABASE CHANGES 364.2.1 Lock objects 364.2.2 Database access frameworks 374.2.3 Update concept 37

4.3 LOGGING 37

5 ABAP SECURITY AND COMPLIANCE 38

5.1 SECURITY ISSUES RELEVANT TO TESTING IN SAP STANDARD 385.1.1 Authorisation checks 395.1.2 Auditability 395.1.3 Data privacy 395.1.4 Injection vulnerabilities 405.1.5 Standard protection 40

5.2 SECURITY RECOMMENDATIONS 405.2.1 Seven universal rules for secure ABAP programming 415.2.2 The most critical and frequent risks in ABAP 42

5.3 ABAP COMPLIANCE PROBLEMS 42

5.4 TESTING TOOLS 43


6 DOCUMENTATION 44

6.1 DOCUMENTATION INDEPENDENT OF DEVELOPMENT OBJECTS 44

6.2 DOCUMENTATION OF DEVELOPMENT OBJECTS 45

6.3 DOCUMENTATION IN THE SOURCE CODE 466.3.1 Documentation language 466.3.2 Change documentation 466.3.3 Program header 466.3.4 Source code comments 47

7 FEASIBILITY AND ENFORCEABILITY 47

7.1 FEASIBILITY 477.1.1 Motivation for a process 477.1.2 Process design and maintenance 48

7.2 ENFORCEABILITY 497.2.1 Manual testing 497.2.2 Automatic testing 50

7.3 PRACTICAL EXPERIENCE AND TIPS 517.3.1 Source code quality assurance 517.3.2 Time and budget quality assurance (QA) 517.3.3 Problems 527.3.4 Decision making regarding modifications 527.3.5 Practical field report: Comgroup GmbH 53

8 INFRASTRUCTURE AND LIFECYCLE MANAGEMENT 54

8.1 INFRASTRUCTURE 548.1.1 Classic three-system landscape 54

8.1.1.1 Development 548.1.1.2 Quality assurance 548.1.1.3 Production 54

8.1.2 Five- and six-system landscape 548.1.2.1 Development 548.1.2.2 Test 558.1.2.3 Quality assurance 558.1.2.4 Maintenance 558.1.2.5 Consolidation 558.1.2.6 Production 558.1.2.7 Schematic illustration of six-system landscape 55

8.1.3 Sandbox 56

8.1.4 Transport system 568.1.5 Safeguarding consistency of new developments and extensions 578.1.6 Roll back of new developments 57

8.2 CHANGE MANAGEMENT 58

8.3 SOFTWARE MAINTAINABILITY 60

8.4 ADAPTATION OF SAP FUNCTIONALITY 60

8.5 AUDITABILITY OF APPLICATIONS 638.5.1 Test process basics for the creation of software products 638.5.2 Test automation 65

9 ECLIPSE DEVELOPMENT ENVIRONMENT 67

9.1 REQUIREMENTS AND INSTALLATION 67

9.2 NECESSITY 67

9.3 ADVANTAGES 67

9.4 CONSIDERATIONS 68

9.5 PROBLEMS AND SUPPORT WITH CHANGEOVER 68

9.6 CONCLUSION 69

9.7 ADDITIONAL SOURCES 69

10 USER INTERFACE (UI) 70

10.1 UI TECHNOLOGIES IN PRACTICE 70

10.2 SAPUI5 7110.2.1 Requirements 7110.2.2 Development 72

10.2.2.1 Discover 7310.2.2.2 Design 7310.2.2.3 Deliver 74

10.2.3 General recommendations 7610.2.4 Additional sources 77

10.3 SAP GATEWAY 7710.3.1 Using SAP Gateway 7710.3.2 Developing with SAP Gateway 7810.3.3 General recommendations 8010.3.4 Additional sources 80


11 THE AUTHORS 81

APPENDIX A: NAMING CONVENTIONS 83

A.1 REPOSITORY OBJECT NAMING CONVENTIONS 84A.1.1 Package hierarchy 85A.1.2 Dictionary objects 85A.1.3 Containers for source code objects 86

A.2 NAMING CONVENTIONS FOR ABAP SOURCE CODE 88A.2.1 Classic user dialogues (selection screens/dynpros) 88A.2.2 Visibility 88A.2.3 Signatures 88

A.3 FURTHER INFORMATION ON NAMING CONVENTIONS 89

A.4 MISCELLANEOUS/LESSONS LEARNED 89A.4.1 Customer namespaces 89A.4.2 Avoid superfluous identifier information 89

A.5 FORMS 90

A.6 PROTECTION OF NAMING CONVENTIONS IN ABAP WORKBENCH 90

APPENDIX B: FURTHER EXAMPLES 91

B.1 ADDITIONAL ABAP KEYWORD DOCUMENTATION 91

LEGAL NOTICE 92


LIST OF FIGURES

Figure 1: ICS risks resulting from insecure ABAP source code 42Figure 2: Schematic illustration of six-system landscape 55Figure 3: Change control form (CC) 58Figure4: W-model with test levels 64Figure 5: SAP NetWeaver 7.5 PAM browser support 71Figure 6: Phases of design thinking 72Figure 7: Supported test phases in SAPUI5 75Figure 8: SAP Gateway deployment options 78


1 INTRODUCTION

As standard software SAP is highly flexible and extensible. Almost every company that uses SAP software customizes the software, adds custom code or different kind of extensions. SAP software is consequently subject to a continuous process of modifica-tion and upgrading by both the manufacturer and the customer as a result of varying customer requirements.

This high level of flexibility and extensibility of SAP software has advantages and disadvantages. The software can be optimally adapted to meet customer-specific requirements and significantly increase value added as a result. At the same time extensibility exposes the risk of custom developments, which can be complex, difficult to maintain and prone to failure.

2012 saw the first edition of the DSAG Best Practice Guidelines published with the aim of providing practical tips for and impulses on the maintainable and efficient design of custom developments. The following years saw the guidelines translated into English. We received major readership feedback from the first version; not to mention the fact that much has changed in SAP development in recent years and a lot of innovations have been introduced. As a consequence, we now present you with the second, totally reworked and updated edition of the DSAG Best Practice Guidelines. The German version 2.0 was originally published at the DSAG Annual Conference in 2016. The English translation we present in February 2018. Hereby, we did not consider any updates but translated the content as of 2016.

1.1 MOTIVATION & YOUR COOPERATION

The work of the German-Speaking SAP User Group (DSAG) is based on three pillars – broadening the knowledge base, exerting influence and networking. The following document was drawn up by the DSAG working group SAP NetWeaver Development and addresses the first pillar, broadening the knowledge base for users and partners.

As the authors, our aim is to provide the implicit knowledge of development that is evident throughout companies to other DSAG members in the form of a compact document. Our goal is to see the document actively applied and the wealth of experi-ence it encompasses continuously improved upon.

For this very reason we have established a community website that provides further information on the guide, author and other DSAG member contact information and also enables you to share your outlook with others:

www.dsag.de/leitfaden-abap

We look forward to your feedback!

1.2 POSITIONING

SAP and a whole range of specialist journals have produced excellent publications on application development, enhancing and upgrading the SAP platform. Throughout this guide we will be referring to what we regard as literature worth reading.

The added value of this document lies in the consolidation of established procedures, practical tips and well-proven rules applied in user companies. These guidelines provide users, developers and project, IT and development managers with recommen-dations and support so they can avoid ‘re-inventing the wheel’ and instead build on the experiences of others. In the same breath, recommendations in this guide should not be interpreted as a set of hard and fast rules, but more as a selection of practical tips.

In our capacity as the authors, we have endeavoured to find the right balance between general knowledge and in-depth detail. As a consequence, we provide references to additional sources at relevant points to avoid unnecessarily reiterating topics that have already been thoroughly debated.

1.3 AMENDMENTS IN THE 2ND EDITION

The second edition of this document is structurally based on the first edition from 2012. Each section has been fundamentally checked for content and revised. As a result of DSAG member feedback, some recommendations from the first edition were updated, while others were comprehensively expanded on by the authors. The sections ‘Develop-ment Environment’ and ‘User Interface’ have also been newly added.

Even if you are well-acquainted with the first edition, we thoroughly recommend that you read and apply the recommendations in this comprehensively revised second edition.


1. IN

TRO

DU

CTI

ON

http://www.dsag.de/leitfaden-abap

2 PROGRAMMING GUIDELINES

This section defines firmly established and recommended programming guidelines for applications created using ABAP. It tells you how to achieve readable, maintainable, high-quality ABAP source code using standard SAP tools and discipline. This makes source code maintenance more straightforward and enables different internal and external individuals to work together efficiently on the (further) development and maintenance of programs.

Using official ABAP programming guidelines

Since the release of NetWeaver 7.31 SP5, official SAP ABAP programming guidelines have become a fixed component of ABAP keyword documentation. Developers can access these via the local system installation (transaction ABAPDOCU/F1 Help in ABAP Editor/ADT) or via the SAP Help Portal1. In addition to its comprehensive, high-quality content, the document has a further advantage over other development guidelines: instead of gathering dust in someone’s desk drawer, it can be directly integrated into the development environment. Instructions for carrying out SAP Easy Access menu integration are available under SAP Note 13870862 or for SE80 integra-tion in the linked SAP Community Network (SCN) blog.3

SAP ABAP programming guidelines offer

• Extremely well-founded, practical recommendations

• Detailed information on each rule, including examples

• Availability in German and English

• Ongoing further development by SAP

• Interactive navigation to keyword documentation, release-dependent changes, performance and security themes, sample programs and transactions

• Use of all available ABAPDOCU functions (export as HTML or PDF, search, etc.)

• Well-known guidelines which have more or less established as a standard

• Can be extended by customer

1 Cf. SAP Help Portal 'ABAP keyword documentation – NW7.50'2 Cf. SAP Note 1387086 – HTML Viewer Control in SAP Easy Access screen3 Cf. SCN Article ‘Enhancing the ABAP Workbench with a website containing dev guidelines!’

Extension of ABAP programming guidelines

Extension the ABAP programming guidelines makes sense primarily if you are looking to incorporate areas not currently covered by the standard rules. These include object composition design principles (SOLID4/GRASP5) and architectural concepts such as SAP package concepts or the use of frameworks. Also conceivable is an additional listing of rules that are regarded as pivotal to your company. Refer to the appendix (Section B.1) for further details on how to expand ABAP keyword documentation.

BEST PRACTICE• Make your development guidelines available within

the the development environment to facilitate quick access.

• Use numerous transparent and verifiable examples within the development guidelines that can be re-used as code snippets.

• Use the official SAP ABAP programming guidelines as a benchmark. This extremely comprehensive docu-ment offers detailed recommendations for a broad range of activities.

4 Cf. https://en.wikipedia.org/wiki/SOLID_(object-oriented_design)5 Cf. https://en.wikipedia.org/wiki/GRASP_(object-oriented_design)


2. P

RO

GR

AM

MIN

G G

UID

ELI

NE

S

http://help.sap.com/abapdocu_750/de/index.htmhttps://launchpad.support.sap.com/#/notes/1387086http://scn.sap.com/community/abap/custom-code-management/blog/2014/05/15/enhancing-the-abap-workbench-with-a-website-containing-dev-guidelineshttps://en.wikipedia.org/wiki/SOLID_(object-oriented_design)https://en.wikipedia.org/wiki/GRASP_(object-oriented_design)

• If necessary consolidate the SAP document into a summarised version. Due to its scope and depth of detail, a comprehensive look at the official ABAP programming guidelines would be relatively time- consuming and partially encompass topics that are irrelevant for day-to-day development activity. If this document is to be used in your organisation, we recommend the assignment of a team to summarise the document and provide training on use of the document within your organisation. Especially in large organisations, it may be prudent to bring stakeholders from quality assurance and development into the team and possibly adapt certain points to meet the specific requirements of the organisation.

• If the document becomes an element of external service contracts, the external developer acceptance process should be incorporated into developer key activation and reference made to the document in the course of acceptance dialogue.

ADDITIONAL SOURCES:

1. Development Guidelines for Greenfield Implementation in sync with SAP Custom Code Management6

6 Cf. SCN article http://scn.sap.com/docs/DOC-56285

2.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.

The explicitly formulated naming conventions should be a component of internal training to familiarise new employees with the basic rules and the specifics of the company. In addition, making the naming convention the subject of contracts with external developers and partner companies is also an established procedure. Auto-mated checks ensure subsequent compliance with the convention (cf. Section 2.9 and Appendix A).

BEST PRACTICEAppendix A contains an example of a naming convention.


2. P

RO

GR

AM

MIN

G G

UID

ELI

NE

S

http://scn.sap.com/docs/DOC-56285

2.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…

//…

An existing SAP customer can register a customer-specific namespace with SAP free of charge. Following confirmation, that namespace is exclusively registered worldwide for use by the respective company. This procedure reinforces conflict-free assignment of names for software objects.

The advantage of a customer-specific namespace is that there are no conflicts when importing external objects into the company SAP system (e.g. when using external applications that are imported by a transport request) and when combining SAP systems within the scope of a post-merger integration. With the reservation of the namespace, a software object with the same prefix cannot be created on any external system, i.e. a system that is not registered to the namespace in question.

One disadvantage of using the customer-specific namespace is that through consistent use of the prefix, object naming will inevitably ‘use up’ numerous characters. This can make assigning a name difficult, especially for objects that only have a few characters available for naming. Moreover, not all object types support the use of namespaces, e.g. authorisation objects. The same applies to some SAP tools und frameworks: although their use makes sense and is advisable, such utilisation can be problematic as the use of namespaces in partner and customer development can be inconsistent and even non-existent. We therefore recommend checking this situation prior to any utilisation of new tools or frameworks.

BEST PRACTICEWe recommend using a customer-specific namespace.

ADDITIONAL SOURCES

1. http://help.sap.com (Creating namespaces)

2. Note 105132 – Reserving namespaces

3. Note 84282 – Developing namespaces for customers and partners

4. SAP Support Portal: http://support.sap.com/namespaces

2.3 READABILITY AND MODULARISATION

Creating a clearly readable source code that is easy to understand is not simple and requires discipline and professionalism. Yet the effort invested is certainly worth it in the long-term, above all in the case of durable applications involving continuous maintenance and upgrading tasks. But what defines readable, easily comprehensible source code? If we look beyond ABAP7, then it is all about the simplicity of the source code. In order to achieve this, we suggest the following approach:

• 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

7 Pertinent authors/books on this topic:• Robert C. Martin: Clean Code: A Handbook of Agile Software Craftmanship. Prentice Hall, 2008• Steve McConnell: Code Complete, 2nd Edition. Microsoft Press 2004• Martin Fowler: Refactoring – Improving the Design of existing Code. Addison-Wesley, 1999


2. P

RO

GR

AM

MIN

G G

UID

ELI

NE

S

http://help.sap.com/https://launchpad.support.sap.com/%23/notes/105132https://launchpad.support.sap.com/%23/notes/84282http://support.sap.com/namespaces

• 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

What are the specific characteristics of the ABAP environment?

• Avoiding abstract terminology is sometimes difficult. Older developments (classic SAP modules) in particular contain numerous German abbreviations and identifiers that make it harder to come up to speed for international project teams or junior developers with little SAP background knowledge.

• The development environment can sometimes significantly limit the use of natural language for naming repository objects and other identifiers. Further-more, in contrast to other programming languages, ABAP uses a global as opposed to a package-based namespace. In combination with prefix namespaces (/*/), such conditions promote the use of abbreviations that are difficult to read and may be detrimental to developer productivity.

These specific characteristics aside, the above principles can be positively implemented. Refactoring tools from the ABAP Development Tools (ADT) for Eclipse (cf. Section 9) can be extremely helpful in this respect. For example, utilisation of ADT enables the renaming of individual variables or entire classes for all occurrences in one go. This minimises the effort required for correcting an unsuitably selected identifier and also reduces the risk of error.

BEST PRACTICE• Consider the aforestated procedures during developer

selection and training, project scheduling (time pressure during initial development can result in source code that is difficult to maintain with conse-quently higher follow-up costs) and the planning of quality measures (automatic and manual inspections).

• Use uniform, natural language with consistent termi-nology for source code, within documents and during discourse with colleagues and customers. Use the SAP terminology database as a guide (transaction SAPTERM or http://www.sapterm.com/).

• Define standards for the consistent handling of identifiers, taking into account the extent of integra-tion with SAP standard software (customer/product supplier), quantity of customer source code and the structural and procedural organisation of your SAP development department (generalists/specialists in national/international teams). Depending on the constellation of the aforestated aspects, the naming conventions (e.g. variable identifier sales_organisa-tion instead of vkorg8 or index instead of i) can facili-tate a lot maintenance and further development activities. The following table serves to support any necessary decision making.

8 The five-character field identifier in the classic modules is a special case. When used in structures, conversion to descriptive identifiers can mean a greater workload (and error risk) for mapping in both directions. As such it may be prudent to retain them (despite the poor legibility).


2. P

RO

GR

AM

MIN

G G

UID

ELI

NE

S

Small/ cen-tralised team

Large/ decen-tralised team

Identical native language

Multi- lingual team

Module special-ists

Genera- lists

Lots of custom code

Little custom code

Add-on devel-opment

∙ ∙ ∙ ∙ ∙ ∙ ∙ ∙ ∙ ∙ ∙ ∙ ∙ ∙ ∙ ∙

∙ ∙ ∙ Strong impairment of maintenance/further development through problematic readability/ identifier selection

∙ Little impairment of maintenance/further development through problematic readability/ identifier selection

Code formatting

Clear and readable source code helps any developer to (re-)familiarise with the code. The easiest and fastest way to make and retain readable source code is to use the Pretty Printer / Formatter in the ABAP development environment or ABAP Development Tools. At the push/click of a button/shortcut, the selected source code is formatted in a standard form and the tool offers various configuration options. These can be found in the workbench settings within the classic SAP GUI workbench, while in ABAP Develop-ment Tools, the settings need to be made in the project-specific formatting properties. We recommend to use source code indentation, with keywords in higher case and identifiers in lower case. This enables the source code to be easily understood even in printed form and without syntax colouring. Pretty Printer / Formatter is a straightfor-ward way to create a standardised source code layout. We recommend deactivating the option ‘Insert standard comments’, as the generated comments are not automatically updated following later changes and include redundant information.

BEST PRACTICEWe 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.

Software structuring with the SAP package concept

With the roll out of SAP NetWeaver Application Server 6.20, the development class concept was completely replaced by the SAP package concept and also expanded by numerous features to improve software structuring. In addition to high-level structur-ing of the software, the primary tasks of the package concept are to embed related objects in a common framework, regulate access to objects and control dependencies to other packages. Explaining the details of the package concept goes beyond the scope of these guidelines, which is why we provide reference to existing SAP Help documentation9 and the extremely comprehensive SCN article series.10 Generally speaking, 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

9 Cf. https://help.sap.com/viewer/search?q=package%20builder&language=en-US&state=PRODUCTION&format= standard,html,pdf,others

10 Cf. SCN article Tobias Trapp ‘ABAP Package Concept – Part 1 – 4“


2. P

RO

GR

AM

MIN

G G

UID

ELI

NE

S

https://help.sap.com/viewer/search?q=package%20builder&language=en-US&state=PRODUCTION&format=standard,html,pdf,othershttps://help.sap.com/viewer/search?q=package%20builder&language=en-US&state=PRODUCTION&format=standard,html,pdf,othershttps://blogs.sap.com/2011/12/04/abap-package-concept-part-1-the-basics/

BEST PRACTICE• Use structure packages to highlight the dependency

of various software components, meaningfully group your own comprehensive developments or when planning to use the package check.

• Within the scope of development, check if a main package for the commensurate top-level application components (SE81) already exists in the customer namespace and create one if not.

• Allocate packages to application components that are semantically most suitable.

• Use package hierarchies to organise your software system. Each software system should have at least one main package that consolidates its sub-systems and essentially defines its purpose.

• Use development packages to centrally bundle seman-tically and technically coherent repository objects.

• Avoid reciprocal dependencies between two or more packages. Transfer dependent components to separate packages so that only unilateral dependency exists.

• Arrange packages with unilateral dependency as far up the software system package hierarchy as possible. If functions are needed by multiple software systems, create a general foundation or basis package.

• Group repository objects using a package-specific namespace prefix. Use the application hierarchy or a product abbreviation in this respect (example: all objects in the package hierarchy for the main package Z_SALES_SUPPORT are given the prefix SAS: class ZCL_SAS_FIELD_WORKER, master data table ZSASFIELDWORKERS, etc.).

Package interface and package use access

Package access on all package levels is defined via the package interface and use access. Whereas the package interface serves to disclose reusable package compo-nents, use access helps to control access to components. If a developer does not pay attention to the package interface, and uses standard SAP components that are not released through the package interface, this can impact considerably on the customer as a result of necessary subsequent upgrading. The possible results of using unautho-rised components are described by way of example in the SCN blog.11

Access to components of other packages can be optionally controlled via the package check concept. Further details on activating the package check are covered by SAP Note 64889812. SPAK_API package tools can be used and package access controlled following activation.

11 Cf. http://scn.sap.com/community/abap/blog/2013/01/28/is-sap-nw-ehp-3-really-non-disruptive12 Cf. https://launchpad.support.sap.com/#/notes/648898


2. P

RO

GR

AM

MIN

G G

UID

ELI

NE

S

http://scn.sap.com/community/abap/blog/2013/01/28/is-sap-nw-ehp-3-really-non-disruptivehttps://launchpad.support.sap.com/%23/notes/648898

BEST PRACTICE• Prior to reusing a repository object from a different

package, first check if the object has been released in a package interface. Only objects released via a package interface can guarantee long-term stability. In SAP standard, using such objects reduces the risk of changes caused by a release change.

• Provide access to package objects through the defini-tion of package interfaces. Only stringent package interface compliance can ensure that the defined package structure is maintained and no disruptive access to package objects occurs.

• If necessary provide more package interfaces and group the interfaces on the basis of semantic infor-mation, for instance data manipulation or reporting tools, or according to utilisation criteria.

• If required, move your package interfaces further up the package hierarchy where you have the possibility of further limiting access or enabling access to released elements from outside the system.

• Limit the use of critical functions by providing sepa-rate package interfaces for these objects. Interface usage rights can be determined through defining restriction on user packages.

Package namespaces

In addition to the generally known customer namespaces Y*, Z* and /namespace/, via the package concept SAP also offers the namespaces $* and T*. Every developer is no doubt familiar with $TMP; but did you know that you can also use those two namespaces for packages with local objects in your own package hierarchies? The difference between the namespaces is that $* cannot be transported and the developer has to carry out versioning manually. By contrast, T* package contents can be manually transported to all systems that are not designated production systems by way of a transport of copies. From a software structuring perspective this gives rise to the following benefits:

• It is easier to distinguish unfinished or prototypical components from productively used components.

• Production systems are not overloaded with unnecessary and potentially security- critical functions.

• Maintenance and further development costs can be reduced because necessary changes only have to be carried out on productively used packages.

BEST PRACTICE• Use a suitable namespace for structuring your packages.

Take into consideration the relevance of transporting and the purpose of the development (local test devel-opment/test development with deviating transport destination).

• Ensure that local developments do not enter the production system.


2. P

RO

GR

AM

MIN

G G

UID

ELI

NE

S

Using the package concept

Comprehensive utilisation of all the features of the package concept will not equally suit every company and if designed incorrectly can lead to unwarranted additional costs. We have created the following table to help you in the decision making process. The valuation criteria are based on the value range (+) = less important to (+++) = very important.

Small cen-tralised team

Large/ decen-tralised teams

Regional special develop-ment

Transla-tion activities

A lot of custom code

Little custom code

Add-on- develop-ment

General package concept

++ +++ ++ +++ +++ ++ ++

Package interfaces ++ +++ +++ + +++ + +++

Structure packages + ++ + ++ ++ + +++

Package testing + ++ ++ + +++ + +++

Modularisation

Programs in which the logic units of work are overly long and not separated are consequently harder to read and therefore difficult to maintain and extend.

A modularisation unit (form routine, method or function module) consolidates logically cohesive statements that perform a clearly defined task. However, ensure that you do not end up with a lot of very small individual units that perform only trivial functions. Avoid modularisation units with only a few statements unless these improve readability of the source code and as such are part of the source code documentation.

Modularisation serves to clearly arrange the source code, despite the complexity of the task in hand. See also Section 2.12 ‘Programming model: object-oriented vs. procedural’.

ABAP Development Tools (see Section 9) provide comprehensive refactoring options, for example automatic method extraction, which facilitates subsequent modularisation of the source code (naturally there are limits, which means some manual editing may be required).

Avoiding global variables

In addition to structuring the program text, modularisation also involves restricting the visibility of variables.

Global variables destroy program modularisation. They make readability and maintain-ability considerably more difficult. Debugging and extension of code that uses mainly global variables is often only possible on a ‘trial and error’ basis.

BEST PRACTICEAvoid all global variables.

Limitations of the rule

In smaller programs with only a few simple modularisation units, global variables are usually harmless (due to its small size, the program is normally fairly transparent and ‘hidden’ or less obvious side effects due to changes in global variables are unlikely). Unfortunately, global variables cannot always be avoided. In particular, they are still required for the elements of classic screens and selection parameters.

Further exceptions are the printing programs using the SAPscript technology, which explicitly works using global variables. For readability reasons, always work with returning parameters in this case, which are then correspondingly made available in global variables.

Avoiding code copies

Duplicate or multiple source code (clones) makes debugging and function modification or extension more difficult because all the copies have to be found and adapted accordingly. Moreover, because the copies are usually no longer totally identical, ascertaining whether differences exist and where these differences are takes a great deal of time and effort.


2. P

RO

GR

AM

MIN

G G

UID

ELI

NE

S

Copying SAP standard code is a special case. See Section 8.4 ‘Adaptation of SAP functionality’.

BEST PRACTICEAdhere to the DRY principle: ‘Don’t repeat yourself‘13 and split off the repeated source code section and transfer it to a separate method.

Remarks

A more generous formulation of the DRY principle is the Rule of Three14, which allows for a second copy.

When searching for copies of code15, generated source code should be excluded as this constitutes a deliberate copy.

Multiple statements in one line, method chaining

To increase source code readability, we recommend avoiding multiple statements on one line.

One exception to this is so-called method chaining. Chaining method calls avoids variables introduced merely to hold intermediate results, thus creating a more readable source code. However, extensive method chaining, particularly in combination with less descriptive method names, can reduce readability. As such there is no all-encompassing guideline.

13 Cf. https://en.wikipedia.org/wiki/Don%27t_repeat_yourself14 Cf. http://en.wikipedia.org/wiki/Rule_of_three_(programming)15 For example with SAP Clone Finder, CCAPPS transaction code

2.4 SEPARATION OF PRESENTATION AND APPLICATION LOGIC

A separation of presentation and application logic should be carried out in all programs. This enables application logic results and functions to be displayed to the user via a variety of user interfaces (UIs) and also to provide these to other systems via a stan-dardised interface. This rule applies to all standard UI technologies, but the degree of support to such logic separation can vary. Implementation in Floorplan Manager/Web Dynpro for ABAP already allows for separation of the model and UI logic within the framework. Separation is not facilitated in the same way in the case of classic Dynpros and BSPs, but separation can and must also be carried out within these environments. However, no technical checks are available in this case, unlike with Floorplan-Manager/Web Screens, where commensurate checks are undertaken in Code Inspector. The same principles naturally also apply for UI5 development (see Section 10), in which user interface technologies already support the model-view-controller pattern and the application logic is provided by the respective backend.16

Plausibility rules are a typical example of explicit separation of the application logic and UI. When a plausibility check of input is developed in a specific UI technology (in the presentation layer), if the UI technology is changed, these checks have to be re-developed. In order to avoid this, the functions for checking input or parameters should be created and maintained independently of the applied UI.

Most of the time it also makes sense to keep the source code for the data model and/or database access separate, be it via a separate local class (for small developments not targeted for reuse) or a framework such as BOPF (Business Object Processing Framework17). This complies with the classic model-view-controller pattern.

16 SAP roadmap for user interface strategies17 http://scn.sap.com/community/abap/bopf


2. P

RO

GR

AM

MIN

G G

UID

ELI

NE

S

https://en.wikipedia.org/wiki/Don%27t_repeat_yourselfhttp://en.wikipedia.org/wiki/Rule_of_three_(programming)https://support.sap.com/content/dam/website/roadmaps/en_us/cross-topics/SAP User Interface Technologies Road Map.pdfhttp://scn.sap.com/community/abap/bopf

2.5 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.

Configurable language-dependent texts are stored in individual text tables. A text table possesses the same key attribute as the associated customising table and is referenced to this via a foreign key relationship. In addition, the first key attribute after the client field must be the language attribute (data element SPRSL or SPRAS).

BEST PRACTICE• We recommend using Code Inspector or ATC to

search for texts that cannot be translated.

• To create subsequent translations more easily, the length of the descriptions and text elements should be as long as possible. As a rule of thumb, the length of text elements should be 1.5 times the length of the native description.

To reduce the outlay for translations, the following aspects should be considered when establishing a translation strategy:

• Use English as the core source language

• Define the depth of translation work (e.g. only surface text, surface text and F1 Help functions, complete translation) using the translation levels defined by SAP18

• Assign packages to the SAP application hierarchy to enable use of domain- specific text recommendations for the distribution of top texts

• Label technical text tables that are not relevant to translation

• Use long text objects (e.g. via SO10) instead of dividing text into a number of lines

• Use uniform terminology and spelling supported by the terminology database

• Avoid wildcard characters (&) in message texts (instead use &1 &2 &3 &4, because the position of such within a message text may differ in the various languages)

• Work with supplementation language in systems different from the development system for filling translation gaps in the target language. Use pseudo language 2Q for technical user interface tests.19

• Use the SAP package concept for separating elements that are relevant and non-relevant to translation

ADDITIONAL SOURCES

1. Presentation ‘Best Translation Practices in SAP Custom Development Projects’ by Lindsay Russel (SAP SE)

18 Cf. https://websmp102.sap-ag.de/~form/handler?_APP=00200682500000002672&_EVENT=DISPLAY&_SCENAR-IO=01100035870000000122&_HIER_KEY=501100035870000008578&_HIER_KEY=601100035870000248115&

19 http://www.se63.info/pseudo-localization-sap-applications/


2. P

RO

GR

AM

MIN

G G

UID

ELI

NE

S

https://www.dsag.de/system/files/node/document/field_doc_file/20141120_development_sap_russel.pdfhttps://websmp102.sap-ag.de/~form/handler?_APP=00200682500000002672&_EVENT=DISPLAY&_SCENARIO=01100035870000000122&_HIER_KEY=501100035870000008578&_HIER_KEY=601100035870000248115https://websmp102.sap-ag.de/~form/handler?_APP=00200682500000002672&_EVENT=DISPLAY&_SCENARIO=01100035870000000122&_HIER_KEY=501100035870000008578&_HIER_KEY=601100035870000248115http://www.se63.info/pseudo-localization-sap-applications/

2.6 DYNAMIC PROGRAMMING AND AUDITABILITY

Dynamic programming

In ‘traditional’ static development, the development objects and source code are defined at design time and statically stored in the SAP system. The specified source code is then executed during runtime. In contrast, dynamic programming allows greater source code flexibility. Dynamic programming is illustrated by the following example:

The name of an ABAP class to be invoked is not stored statically in the source code; instead, an instance of a class whose name is provided during runtime (with the name stored in a variable, possibly coming from customizing), is created. The name and consequently the specifically executed implementation may well vary, for example, as a result of user input.

An advantage of this methodology is increased flexibility, while the disadvantage is greater complexity. Depending on the type of dynamic programming, security risks may also be an issue. Tools for automatically recognising security risks do not function as well with dynamic source code.

Advantages:

• Increased flexibility

• Better reusability

• Avoidance of copies and consequent minimisation of the amount of source code requiring maintenance

Examples of advantages:

Example 1 – Own user exit setup

The static definition of an abstract class incl. method signature forms the basis for a ‘user exit’. Numerous specific implementations of the abstract class can then be subsequently created. At runtime, for example, the name of a specific class implemen-tation is read from a customising table and invoked. Customising can consequently be used to activate/deactivate a variety of different implementation variants.

Example 2 – Dynamic WHERE clause

At runtime, the WHERE clause for a database operation, e.g. SELECT, is created within a string variable. This avoids complicated CASE queries, which execute various open SQL commands depending on the input.

Example 3 – Replacement of so-called boilerplate code20

Dynamic programming can also be used to avoid re-implementing similar logic in almost identical variants. One example is a database access layer: the tables maybe different, but the algorithm is always the same. In this case the problem can be solved using dynamic programming or generating the source code. This takes more work, but depending on the scenario pays off with less maintenance effort.

Disadvantages:

• When using dynamic calls, the where-used list within the ABAP development environment is not available. Changing the called code is then a problem.

• When using dynamic programming no syntactic checking is possible during design time. This can cause an abort in program execution where variable content is erroneously configured (e.g. erroneous compounding within a dynamic WHERE clause, wrong class name).

• Dynamic programming brings with it increased security risks if the dynamic content can be influenced due to unprotected access (e.g. where a WHERE clause can be influenced by user input; keyword: SQL injection).

• Increased source code complexity.

20 https://en.wikipedia.org/wiki/Boilerplate_code


2. P

RO

GR

AM

MIN

G G

UID

ELI

NE

S

https://en.wikipedia.org/wiki/Boilerplate_code

BEST PRACTICE• Dynamic programming should be used very conserva-

tively and be well-controlled. Source code with dynamic content should be checked according to the dual control principle and documented as it poses a potential security risk. 21

• When generating source code, a syntax check should be carried out after generation using the SYNTAX- CHECK command.

• For dynamic or generated source code, class CL_ABAP_DYN_PRG test mechanisms should be used, enabling whitelists for dynamic table access to be applied, for example.

Section 5.2 also addresses dynamic programming from a security perspective.

Auditability of ABAP source code

At all times it must be possible to check customer developed or generated ABAP source code for errors through manual inspection or by using static code analysis tools. All methods for concealing ABAP source code are impermissible as they impede such checking and can even be specifically exploited to place backdoors into a system. Hidden source code (e.g. macros) can no longer be inspected by the debugger, which makes auditability and error analysis all the more difficult. The techniques for hiding source code are explicitly not described within this document.

21 Code Inspector/ATC security checks can be used to find dynamic source code (pre-selection for dual control).

BEST PRACTICE• Never apply methods for concealing source code and

contractually agree this with any external developers.

• To avoid problems during maintenance activities carried out by different developers, we do not recom-mend to use the editor lock flag to prevent changes to source code. Instead, source code can be protected by assigning it to a separate package, for which access can be restricted using authorisation object S_DEVELOP with explicit values for field DEVCLASS.

2.7 NEW LANGUAGE ELEMENTS

ABAP syntax has been considerably expanded with NetWeaver 7.40 and 7.50.22 New elements can be roughly divided into two areas:

1. Enablement of the expression orientation that is standard in many other program-ming languages

This replaces the former statement orientation arising from the ABAP origins as a macro language. ABAP developers should to be in a position to concentrate on the ‘what’ in terms of programming rather than the ‘how’ (see the many auxiliary structures in the legacy source code in the following example).

2. Support of the ‘Code2Data’ paradigm

In other words the transfer of data-intensive operations from the application server to the database, also called ‘code pushdown’. The associated new language elements are partly available for all databases (extensions, Open SQL, Core

22 http://scn.sap.com/community/abap/blog/2013/07/22/abap-news-for-release-740 http://scn.sap.com/community/abap/blog/2015/11/27/abap-language-news-for-release-750


2. P

RO

GR

AM

MIN

G G

UID

ELI

NE

S

http://scn.sap.com/community/abap/blog/2013/07/22/abap-news-for-release-740http://scn.sap.com/community/abap/blog/2015/11/27/abap-language-news-for-release-750

Data Service CDS views23) and partially only available for SAP HANA (AMDP – ABAP Managed Database Procedures). When considering the use of HANA-specific language elements, a balance has to be made between universal operability on all databases and performance optimisation for SAP HANA.

To illustrate the new potential offered by expression orientation in (1), here is an example featured in Horst Keller’s blog (see below):

Source code in NetWeaver 7.0

DATA itab TYPE TABLE OF scarr.

SELECT * FROM scarr INTO TABLE itab.

DATA wa LIKE LINE OF itab.

READ TABLE itab WITH KEY carrid = ’LH‘ INTO wa.

DATA output TYPE string.

CONCATENATE ’Carrier:‘ wa-carrname INTO output SEPARATED BY space.

cl_demo_output=>display( output ).

Corresponding source code in 7.40 (SP08)

SELECT * FROM scarr INTO TABLE @DATA(itab).

cl_demo_output=>display( |Carrier: { itab[ carrid = ’LH‘]-carrname }| ).

23 Still some restrictions in NetWeaver 7.40 (parameterised views only with SAP HANA), from NetWeaver 7.50 onwards, the CDS view functions are database-agnostic

The following language expansions in particular are fundamental:

Introduced in SAP NetWeaver 7.02:

• Inline calculations and inline method calls

• String templates (NW 7.40 example line 2: Parameter of the display method)

• String functions and regular expressions

In SAP NetWeaver 7.40:

• Inline declarations (in line 1: DATA(itab))

• Constructor operators VALUE and NEW

• Table expressions (in line 2: itab[ ... ])

• New parser for Open SQL (in line 1: @ as a character for host variables)

• SQL expressions

BEST PRACTICEWe recommend learning and using the new language elements as they can be used to increase the development efficiency and improve source code readability. The above list is a good place to start.


2. P

RO

GR

AM

MIN

G G

UID

ELI

NE

S

Also to be considered in this connection are team skills and the SAP NetWeaver release used within the system landscape. Older SAP versions do not always support the new language constructs or the Code2Data paradigm. If developers are frequently working on different systems with different SAP NetWeaver releases, then as much common ground as possible should be found to subsequently avoid even greater complications during the transfer to legacy systems.

Further information on the new language elements is available in the ABAP Keyword Documentation and Horst Keller’s SCN blogs.22

2.8 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.

BEST PRACTICEWe recommend the regular application of a static code analysis tool to discover obsolete statements. Suitable SAP built-in solutions include Code Inspector/ATC and using the extended program check. To minimise the amount of work required, obsolete statements should al-ways be replaced when development objects are changed anyway in the course of other change requests. Usually, this requires only little additional test effort. In addition, excellent third-party analysis tools are available.

2.9 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.

• The latest tool is the ABAP Test Cockpit (ATC)24, which uses Code Inspector check variants and also has a number of its own additional functions.

These tools can be used by developers during the development process and are all well integrated in the ABAP Workbench and ADT (exception: Extended Program Check is not directly accessible from ADT).

Code Inspector or the ATC can also be globally executed using transaction SE03 to enable the early recognition and rectification of problems and vulnerabilities during the release of transport requests. This saves spending unnecessary time and effort on transports, testing and error handling and improves program performance, stability, security and maintainability.

In SAP standard, Code Inspector or the ATC are only activated on the release of a transport request. The recommended process (and the only meaningful option for transport management with transports of copies – see Section 8.1.4) is to carry out checking upon release of the respective transport task or after completion of the development objects by the developer. This requires implementation of BAdI CTS_RE-QUEST_CHECK.25

24 Available as of NetWeaver 7.4 or specific SPs in 7.0 and 7.3.25 How this is implemented for the ATC is specified http://scn.sap.com/community/abap/blog/2016/04/20/how-to-

perform-an-atc-check-automatically-during-transport-task-release


2. P

RO

GR

AM

MIN

G G

UID

ELI

NE

S

http://scn.sap.com/community/abap/blog/2016/04/20/how-to-perform-an-atc-check-automatically-during-transport-task-releasehttp://scn.sap.com/community/abap/blog/2016/04/20/how-to-perform-an-atc-check-automatically-during-transport-task-release

BEST PRACTICEMany of the rules and recommendations for development objects in these guidelines can be checked automatically with the tools. Developers should therefore be familiar with the tools and they should be applied early on in the development process. General testing with Code Inspector or ATC on the release of transports should be configured. Selection or configuration of a check variant is a prerequisite in this respect. Who may grant exemptions in the case of failed checks should also be established (e.g. quality assurance officer or development manager).

Various third party tools are also available to check source code for infringements of development guidelines even at design time and provide developers with direct feedback on certain code quality characteristics. In addition to design time checking, some of the tools also offer the option of automatic correction.

Section 7 and particularly subsection 7.2.2 ‘Automatic testing’ contain comprehensive recommendations for this area.

ADDITIONAL SOURCES:

The procedure for implementing BAdI CTS_REQUEST_CHECK for Code Inspector is specified in the ‘SAP Code Inspector User Manual’ (SAP Press), as well as in this blog.

The book also describes the integration of a number of customer checks in Code Inspector/ATC. A blog is also available on this topic.

2.10 HARD CODING, MAGIC NUMBERS

Problematic hard coding is regarded as the coding of data such as texts, numbers, user names etc. directly into a program, which may then change; for example, because they actually comprise configuration information (interface paths…). Hard coding initially saves development time, but inevitably leads to higher costs over the entire lifecycle of the application because, for example, configuration changes would necessi-tate modification of the program. If the same value is hard coded in numerous programs or subroutines, then an additional problem arises when a change is required all the positions have to be modified (see also ‘Avoiding code copies’ in Section 2.3).

A related theme involves Magic Numbers, in other words numbers that are used in a program without explanation. The problem here is one of program readability and maintainability. Again, costs may also be saved initially in this case, but nevertheless are likely to be incurred on later modifications, perhaps at an even higher rate if the meaning of the magic number first needs to be determined.

A further aspect when using hard coding and magic numbers is that this may be a sign of implementation without any consideration for object-oriented concepts. One example being CASE statements on constants, which can be avoided either using the refactoring method ‘Replace Code with Subclasses’26 or via filter BAdIs27.

BEST PRACTICEProblematic hard coding should be avoided. Magic numbers should be replaced by distinctly named constants or fur-nished with a suitable comment.

The use of constant names that are identical to the value is to be expressly avoided as this will give rise to faulty information if the value is changed. (Paradoxically, change-ability is the main reason for using constants.)

26 https://sourcemaking.com/refactoring/replace-type-code-with-subclasses27 See also http://scn.sap.com/docs/DOC-10286


2. P

RO

GR

AM

MIN

G G

UID

ELI

NE

S

http://scn.sap.com/community/abap/testing-and-troubleshooting/blog/2013/09/19/how-to-trigger-atc-or-code-inspector-checks-during-the-release-of-a-transport-taskhttp://scn.sap.com/community/abap/blog/2006/11/02/code-inspector--how-to-create-a-new-checkhttps://sourcemaking.com/refactoring/replace-type-code-with-subclasseshttp://scn.sap.com/docs/DOC-10286

The definition of constants should be in the form of an attribute in a specifically dedicated interface or an abstract, final class. We do not recommend the use of constant includes. Within the scope of large scale developments, it may be a good idea not to store all the constants in one interface, but to distribute the constants to different interfaces according to business topic. Additionally, interfaces can be furnished with a tag interface (the same as BAdI Interface IF_BADI_INTERFACE). This ensures the discovery of interfaces that contain constants.

When introducing constants ensure that these can be found by other developers, otherwise identical constants may be potentially duplicated on the system. Unfortunately, there is no dedicated SAP tool that assists with this task. An alternative is to access the SAP ecosystem and use the openly available tool ConSea.28 One option is to document the constants within an interface outside the system, but it is likely that maintenance of the external documents will be neglected. As of NetWeaver 7.50, ABAP Doc documen-tation can be exported like with JavaDoc. If the TREX search is installed and configured, this can be used to carry out a performant search.

2.11 AUTHORISATION CHECKS IN SOURCE CODE

The required authorisation objects have to be checked to access and present data. When standard objects are used, the check should utilise the corresponding SAP standard authorisation objects (simplifies maintenance of the required roles). SAP standard authorisation objects cannot generally be used to check customer data objects. Customer authorisation objects can be implemented and checked for this purpose. For further information see Section 5.1.1.

2.12 PROGRAMMING MODEL: OBJECT-ORIENTED VS. PROCEDURAL

It is advisable to move from a procedural programming model to object-oriented programming to promote future-proof development and encapsulate objects. Object-oriented development should be used exclusively in the case of new projects.

28 Cf. GitHub

Object-oriented development was designed so that logically coherent operations can be uniformly encapsulated within objects. Amongst other things, this increases the reusability of source code. In particular, such objects can be easily extended or changed by other developers to meet their needs without compromising the basic functions (open-closed principle). Additionally, core functionalities or individual variables can be specifically protected against undesired read and write accesses by invoking programs. An initial overview of the basic principles of object-oriented design can be found, for example, on Wikipedia.29

The introduction of object orientation into ABAP with ABAP Objects went hand-in-hand with a revision of the language and the unification of constructs. Utilisation of ABAP Objects therefore results in enhanced maintainability. For smaller programs30, this enhanced maintainability can be achieved by replacing FORM routines with the class methods of local class lcl_main without the need to undertake a strictly object-orient-ed (re-)design.

SAP has now categorised procedural development in ABAP, for example using FORM routines, as obsolete. In recent years, procedural development has also proved to be extremely opaque, complex and error-prone due to global variables and includes. This is a further reason for switching to object-oriented programming.

BEST PRACTICEWe recommend that wherever possible new development projects are to be implemented using the principles of object orientation with ABAP Objects. Obsolete procedural ABAP language constructs such as FORM routines should be avoided and replaced with constructs from ABAP Objects. This recommendation is congruent with the specific rules ‘ABAP Objects as a programming model’ under the program-ming guidelines in the ABAP keyword documentation.

29 https://en.wikipedia.org/wiki/Object-oriented_design30 The upper limit of a ‘small program’ in this case is deemed as being between 200 and 500 lines, depending on

the coding style and the complexity of the implemented functions.


2. P

RO

GR

AM

MIN

G G

UID

ELI

NE

S

https://github.com/TheRealTier/ConSeahttps://en.wikipedia.org/wiki/Object-oriented_design

Possible counter-arguments:

• Available ABAP Objects team expertise and the planned and realistically expecteddevelopment of expertise

• Systems with older Basis/NetWeaver release that include ABAP Objects that areless mature (prior to SAP Web Application Server 6.20) or in systems/modules inwhich procedural components also dominate in SAP standard.

ADDITIONAL SOURCES

1. Horst Keller and Gerd Kluger, Not Yet Using ABAP Objects? Eight Reasons WhyEvery ABAP Developer Should Give It a Second Look, Sap Professional Journal

2. Horst Keller and Gerd Kluger, NetWeaver Development Tools ABAP, SAP AG

3. Bertrand Meyer, Objektorientierte Softwareentwicklung, Hanser 1990,ISBN 3-446-15773-5

4. Bertrand Meyer, Object-Oriented Software Construction, Prentice-Hall 1994

2.13 DEVELOPMENT LANGUAGE

All developers should log on with the same language and maintain language-depen-dent texts in that language. Language-dependent texts should always be created in translatable form.

3 PERFORMANCE

In the following subsections we recommend a number of best practices that should be observed during day-to-day ABAP development work to ensure appropriate perfor-mance of the developed application. Any specifics of the SAP HANA as compared to other databases will be highlighted in the respective subsection.

3.1 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)

BEST PRACTICEAvoid all unnecessary source code, including unnecessarily executed source code.

3.2 PERFORMANCE OPTIMISATION ONLY IN THE APPROPRIATE AREAS

Performance optimisation (insofar as it increases overheads and complexity) should only be carried out in the appropriate areas. Performance must first be measured to ascertain where these ‘hot spots’ are.


3. P

ER

FOR

MA

NC

E

BEST PRACTICE • Focus first on clear and simple implementation of the

essential logic. Then run performance tests on a system with sufficient data volume (usually a test system) in order to subsequently optimise perfor-mance at the relevant hot spots if the program is indeed slower than desired by the user. Exceptions to this involve programs where it is known in advance that they are performance critical. For these pro-grams any decisions should be made at design time, e.g. use of parallelisation.

• We recommend starting the search for performance bottlenecks with a runtime analysis (transaction SE30/SAT) with full aggregation. This should clarify whether the runtime results from interaction with the database or from processing the data loaded into the main memory.31 Important is that representative and realistic data is processed so as not to be led down the wrong track by unusual processing patterns. If more than half of the runtime is taken up with data-base processing, a closer analysis of the SQL com-mands should be carried out using transaction ST05. If more runtime is taken up by ABAP processing, a more in-depth analysis is undertaken using transac-tions SE30/SAT; whereby the aggregation levels are reduced in stages to obtain more precise feedback about critical points in the program. Results are compared and documented after each optimisation stage.

3.3 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

31 An initial overview of runtime distribution between the database and application server is also available via the transaction STAD.


3. P

ER

FOR

MA

NC

E

• ST10 – Table call statistics to check table buffering

• ST12 – Single Transaction Analysis (end-to-end trace)

• S_MEMORY_INSPECTOR – Memory Inspector (also integrated within SAP GUI Debugger)

• SQLM/SQLMD – SQL Monitor Recording and analysis of all SQL requests within the production system. New from NetWeaver 7.0/7.4 onwards (For details see Note 1885926).

• SWLT – Performance Tuning Worklist Work list based on ATC and SQL Monitor results. New from NetWeaver 7.0/7.4 onwards (specific SPs, see SAP Documentation).

Within the context of the SAP HANA rollout, SAP provided further tools or extensions to existing tools to identify performance problems early on and establish a procedure to enable iterative optimisation of the performance of applications on SAP HANA.

Performance analysis in this context encompasses static source code analysis through ATC with the three testing variants FUNCTIONAL_DB, FUNCTIONAL_DB_ADDITIONAL and PERFORMANCE_DB. These variants carry out static code analysis within the scope of using SAP HANA as the DB. Further information is available in Note 1912445 – ABAP Custom Code Migration for SAP HANA – recommendations and Code Inspector variants for SAP HANA migration.

The ABAP SQL Monitor was also introduced. This tool enables system-wide tracing of all SQL requests over a long period with additional recording of the entry points (transactions, reports, etc. within the scope of which an SQL command was executed). More detailed information on SQL Monitor can be found on the SAP Community Network in the document ‘Optimising Custom ABAP Code for SAP HANA – The New ABAP SQL Monitor’.

Consolidation of the SQL Monitor runtime screen and static analysis through ATC occurs via the SQL Performance Tuning Worklist. This enables setup of a work list for performance optimisation that can be processed following analysis and prioritisation. Further information on this procedure can be found on the SAP Community Network in the document ‘Best Practice Guide – Considerations for Custom ABAP Code during a Migration to SAP HANA’.

3.4 DATA MODEL AND DATA ACCESS

3.4.1 DATA MODEL

The data model structure forms the basis for performant applications. A pragmatically normalised data model can work more efficiently with data and indices.32 Independent of the programming language ABAP, normalisation rules are adhered to in this respect. Moreover, during the data modelling process, data elements in the data dictionary should be respectively assigned to domains. This results in greater transparency and improved maintenance.

3.4.2 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.

32 The S/4HANA model goes a step further and denormalises the data model. This is possible due to the type of data storage in the HANA in-memory database and provides a simpler data model and greater performance for data queries.


3. P

ER

FOR

MA

NC

E

https://launchpad.support.sap.com/%23/notes/1885926https://help.sap.com/saphelp_nw74/helpdata/de/cf/b2a58ff7834bebaad6dda30febdd82/content.htm?frameset=/de/71/3ff185b9b347aaacbe3ada28d4fa72/frameset.htm&current_toc=/de/e4/e3e6e3a8514af2be58552a3ba40b1b/plain.htm&node_id=34https://launchpad.support.sap.com/%23/notes/1912445http://scn.sap.com/docs/DOC-47444http://scn.sap.com/docs/DOC-47444http://scn.sap.com/docs/DOC-46714http://scn.sap.com/docs/DOC-46714

These five rules apply to all database systems. Within the context of code push downs and code-to-data paradigms in SAP HANA, in contrast to non-HANA databases a modi-fied weighting of the rules is to be observed. This is explained in Section 3.6.

Regardless of code push down, when using SAP HANA as a database, Rule 4 on the incorporation of indices has greater relevance. In SAP HANA, as few indices as possible should be applied. In principle, column-based storage enables each column to be used as an index, so theoretically no more indices are required: however, scenarios can arise, particularly in OLTP, where it makes sense to incorporate indices in SAP HANA, to avoid potential poor performance and/or high CPU consumption by SAP HANA. The relevant details can be found in SAP Note 1794297 – Secondary Indices for the Business Suite on HANA.33

BEST PRACTICESReduction 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

34

33 SAP Note 1794297 – Secondary Indexes for the Business Suite on HANA34 Cf. SCN blog ‘Why ‘INTO CORRESPONDING’ is much better than its reputation’

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.


3. P

ER

FOR

MA

NC

E

https://launchpad.support.sap.com/%23/notes/1794297http://scn.sap.com/docs/DOC-33976

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 . 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.

3.4.3 ABAP CORE DATA SERVICE (CDS) VIEWS

ABAP CDS Views is a DDIC artefact introduced with NetWeaver 7.40 SP05 that offers more extensive options for defining views than the classic SE11 Views. In addition to classic SQL functionalities such as outer joins and the Case statement, it also encom-passes SQL functions such as currency conversion. Furthermore, CDS Views also offers the option of defining associations between tables and consequently defining business objects in a reusable manner in the form of views.

35 SAP provides a Runtime Check Monitor with NetWeaver 7.40 that carries out a runtime check to address this problem. See also Note 1931870 – Downport of transaction SRTCM to SP02 / 03 / 04


3. P

ER

FOR

MA

NC

E

https://launchpad.support.sap.com/%23/notes/1931870

Further benefits include options to parameterise views (not supported for all databases in NetWeaver 7.40) and store annotations in a view or to view fields. From NetWeaver 7.50 onwards, the latter enables the straightforward exposure of views with OData Service and use of views and annotations to automatically develop UI5 interfaces (e.g. via Smart Templates). CDS table functions that enable access to SQL script are also available on SAP HANA. As such, all SAP HANA features (e.g. calculation views) are available via CDS Views. Further information on ABAP CDS Views can be found in ABAP keyword documentation for NetWeaver 7.4036 and NetWeaver 7.5037 as well as on the commensurate SCN landing page.38 Please note that ABAP CDS Views can only be created using ABAP Development Tools in Eclipse.

3.5 INTERNAL TABLES AND REFERENCES

Internal tables are a core construct for developing applications with ABAP. In addition to enabling database access, they are also the secondary source of performance problems. Things like the selection of the right type of table and a suitable key are not really a problem with smaller data volumes; however, where larger data volumes are processed, areas previously deemed non-critical from a performance perspective can be the cause of considerably prolonged runtime.

36 http://help.sap.com/abapdocu_740/de/index.htm?file=abencds.htm37 http://help.sap.com/abapdocu_750/de/index.htm?file=abencds.htm38 http://scn.sap.com/docs/DOC-70385

BEST PRACTICEWe 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’.39

• If a Sorted or Hashed table type is accessed, this should always occur using the appropriate (partial) key.

39

As of AS ABAP 7.02 in addition to the primary key, additional secondary keys can be defined for internal tables that are rarely changed, but are read using more than one access pattern. The primary key is defined and used as previously. Secondary keys can be of a different type than the primary key (sorted, hashed).

For example, an additional sorted type key can be defined for a hashed table that has an unambiguous primary key. This additional key makes it possible to effectively access data in the table from another perspective (ambiguous or partial key possible) without the need to load the data a second time into the main memory and in the case of changes manually ensure consistency between the two tables.

39 Access as described in Section 2 above. Path: ABAP – Reference → Processing internal data → Internal tables→ Internal table overview


3. P

ER

FOR

MA

NC

E

http://help.sap.com/abapdocu_740/de/index.htm?file=abencds.htmhttp://help.sap.com/abapdocu_750/de/index.htm?file=abencds.htmhttp://scn.sap.com/docs/DOC-70385

BEST PRACTICE• 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.40

40

3.5.1 FIELD SYMBOLS

Field symbols offer the option of referencing existing data, e.g. internal table lines. Working with references is significantly more efficient than copying data. As such, field symbols should be used wherever possible. Notwithstanding, be aware of the fact that when using field symbols, any change to the value of a field symbol will also overwrite the value of the referenced data element.

40 From NetWeaver Release 7.40 SP02 onwards the function LINE_EXISTS( ) is available and should be used for this type of check for reasons of enhanced readability.

BEST PRACTICEUse standard field symbols for accessing internal tables.

3.5.2 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. This applies particularly for parameters with deep data types such as internal tables or strings. Moreover, as few parameters as possible should be defined as this increases source code readabili-ty. The Extended Program Check identifies superfluous variables and parameters, thereby supporting clean up.

BEST PRACTICEUse as few parameters as possible. Generally use passing by reference and only use passing by value in exceptional cases deemed technically necessary.


3. P

ER

FOR

MA

NC

E

3.6 CODE PUSH DOWN

Using SAP HANA as a database system can greatly enhance performance, particularly of data-intensive applications, if data-intensive operations are delegated to the database layer. Delegation of application server logic in SAP HANA is called Code Push Down. The objective of this procedure is to no longer transport data to the application layer to process it there (data-to-code), but rather to execute the logic where the data resides (code-to-data).

In combination with the SAP HANA architecture, this objective consequently results in a different weighting of the rules defined in Section 3.4.1 in comparison to a non-HANA database. The first three rules (keep the result sets small, minimise the amount of transferred data and minimise the number of database transfers) become more significant in the wake of a Code Push Down, while the fourth rule (optimise the search overhead) becomes less important due to the column-based storage of data.

The fifth rule involves keeping unnecessary load away from the database, as the proce-dure consciously delegates data-intensive operations to the database and thus burdens it.

The extended language scope of ABAP and Open SQL in SAP NetWeaver 7.40 and 7.50 essentially enables Code Push Down in two ways:

• Using Open SQL expansions and ABAP CDS Views

• Using ABAP Managed Database Procedures (AMDP) and as a last optionNative SQL

Which and to what extent the two options are used is highly dependent on the objective. In both cases existing code has to be modified. The complexity of such modification is lower using Open SQL and ABAP CDS Views than

DSAG RECOMMENDATIONS BEST PRACTICE GUIDELINES FOR ... · that much has changed in SAP development...

Documents

Transcript of DSAG RECOMMENDATIONS BEST PRACTICE GUIDELINES FOR ... · that much has changed in SAP development...