DSAG RECOMMENDATIONS BEST PRACTICE GUIDELINES FOR DEVELOPMENT – USEFUL TIPS FOR ABAP DEVELOPMENT BEST PRACTICE GUIDELINES FOR DEVELOPMENT USEFUL TIPS FOR ABAP DEVELOPMENT Version: 2.0 Updated: September 2016, translated February 2018 Authors: Dr. Christian Drumm, Head of Application Development & Consulting, Dr. Christian Lechner, Principal IT Consultant, msg systems ag FACTUR Billing Solutions GmbH Steffen Pietsch, Head of Backoffice, Haufe-Lexware GmbH & Co.KG Martin Fischer, Portfolio Unit Manager SAP Database & Technology, BridgingIT GmbH Daniel Rothmund, IT Business Analyst SAP, Geberit Verwaltungs GmbH Judith Forner, Senior Consultant Finance & Controlling, Mundipharma Deutschland GmbH & Co. KG Holger Schäfer, Business Unit Manager, UNIORG Solutions GmbH Edo von Glan, SAP Developer, Drägerwerk AG & Co. KGaA Denny Schreber, Senior Solution Architect, cbs Corporate Business Solutions Unternehmensberatung GmbH Florian Henninger, Senior Consultant SAP Development, FIS GmbH Andreas Wiegenstein, CEO, SERPENTEQ GmbH Martin Hoffmann, Head of Software Engineering, Miele & Cie. KG Bärbel Winkler, System Analyst SAP Basis/Programming, Valentin Huber, Senior IT Consultant, msg systems ag Alfred Kärcher GmbH & Co. KG Jens Knappik, SAP System Architect, thyssenkrupp Materials Services GmbH Further information on the authors can be found in Section 11 ‘The Authors’. 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. DSAG RECOMMENDATIONS – BEST PRACTICE GUIDELINES FOR DEVELOPMENT -3- CONTENTS 1 INTRODUCTION 8 3.5 INTERNAL TABLES AND REFERENCES 30 3.5.1 Field symbols 31 1.1 MOTIVATION & YOUR COOPERATION 8 3.5.2 Passing parameters 31 1.2 POSITIONING 8 3.6 CODE PUSH DOWN 32 1.3 AMENDMENTS IN THE 2ND EDITION 8 4 ROBUSTNESS AND ACCURACY 33 2 PROGRAMMING GUIDELINES 9 4.1 ERROR HANDLING 33 4.1.1 SY(ST)-SUBRC checks 33 2.1 NAMING CONVENTIONS 10 4.1.2 MESSAGE statement 34 2.2 NAMESPACE 11 4.1.3 Class-based exceptions 34 4.1.4 Exceptions that cannot be handled 36 2.3 READABILITY AND MODULARISATION 11 4.2 CORRECT IMPLEMENTATION OF DATABASE CHANGES 36 2.4 SEPARATION OF PRESENTATION AND APPLICATION LOGIC 17 4.2.1 Lock objects 36 2.5 INTERNATIONALISATION 18 4.2.2 Database access frameworks 37 4.2.3 Update concept 37 2.6 DYNAMIC PROGRAMMING AND AUDITABILITY 19 4.3 LOGGING 37 2.7 NEW LANGUAGE ELEMENTS 20 2.8 OBSOLETE STATEMENTS 22 5 ABAP SECURITY AND COMPLIANCE 38 2.9 AUTOMATIC CHECKING OF DEVELOPMENT OBJECTS 22 5.1 SECURITY ISSUES RELEVANT TO TESTING IN SAP STANDARD 38 2.10 HARD CODING, MAGIC NUMBERS 23 5.1.1 Authorisation checks 39 5.1.2 Auditability 39 2.11 AUTHORISATION CHECKS IN SOURCE CODE 24 5.1.3 Data privacy 39 2.12 PROGRAMMING MODEL: OBJECT-ORIENTED VS. PROCEDURAL 24 5.1.4 Injection vulnerabilities 40 5.1.5 Standard protection 40 2.13 DEVELOPMENT LANGUAGE 25 5.2 SECURITY RECOMMENDATIONS 40 3 PERFORMANCE 25 5.2.1 Seven universal rules for secure ABAP programming 41 5.2.2 The most critical and frequent risks in ABAP 42 3.1 THE PRINCIPLE OF AVOIDANCE 25 5.3 ABAP COMPLIANCE PROBLEMS 42 3.2 PERFORMANCE OPTIMISATION ONLY IN THE APPROPRIATE AREAS 25 5.4 TESTING TOOLS 43 3.3 USE EXISTING TOOLS 26 3.4.1 Data model 27 3.4.2 Database access 27 3.4.3 ABAP Core Data Service (CDS) Views 29 DSAG RECOMMENDATIONS – BEST PRACTICE GUIDELINES FOR DEVELOPMENT -4- 6 DOCUMENTATION 44 8.1.4 Transport system 56 8.1.5 Safeguarding consistency of new developments and extensions 57 6.1 DOCUMENTATION INDEPENDENT OF DEVELOPMENT OBJECTS 44 8.1.6 Roll back of new developments 57 6.2 DOCUMENTATION OF DEVELOPMENT OBJECTS 45 8.2 CHANGE MANAGEMENT 58 6.3 DOCUMENTATION IN THE SOURCE CODE 46 8.3 SOFTWARE MAINTAINABILITY 60 6.3.1 Documentation language 46 8.4 ADAPTATION OF SAP FUNCTIONALITY 60 6.3.2 Change documentation 46 6.3.3 Program header 46 8.5 AUDITABILITY OF APPLICATIONS 63 6.3.4 Source code comments 47 8.5.1 Test process basics for the creation of software products 63 8.5.2 Test automation 65 7 FEASIBILITY AND ENFORCEABILITY 47 9 ECLIPSE DEVELOPMENT ENVIRONMENT 67 7.1 FEASIBILITY 47 7.1.1 Motivation for a process 47 9.1 REQUIREMENTS AND INSTALLATION 67 7.1.2 Process design and maintenance 48 9.2 NECESSITY 67 7.2 ENFORCEABILITY 49 9.3 ADVANTAGES 67 7.2.1 Manual testing 49 7.2.2 Automatic testing 50 9.4 CONSIDERATIONS 68 7.3 PRACTICAL EXPERIENCE AND TIPS 51 9.5 PROBLEMS AND SUPPORT WITH CHANGEOVER 68 7.3.1 Source code quality assurance 51 9.6 CONCLUSION 69 7.3.2 Time and budget quality assurance (QA) 51 7.3.3 Problems 52 9.7 ADDITIONAL SOURCES 69 7.3.4 Decision making regarding modifications 52 7.3.5 Practical field report: Comgroup GmbH 53 10 USER INTERFACE (UI) 70 8 INFRASTRUCTURE AND LIFECYCLE MANAGEMENT 54 10.1 UI TECHNOLOGIES IN PRACTICE 70 10.2 SAPUI5 71 8.1 INFRASTRUCTURE 54 10.2.1 Requirements 71 8.1.1 Classic three-system landscape 54 10.2.2 Development 72 8.1.1.1 Development 54 10.2.2.1 Discover 73 8.1.1.2 Quality assurance 54 10.2.2.2 Design 73 8.1.1.3 Production 54 10.2.2.3 Deliver 74 8.1.2 Five- and six-system landscape 54 10.2.3 General recommendations 76 8.1.2.1 Development 54 10.2.4 Additional sources 77 8.1.2.2 Test 55 8.1.2.3 Quality assurance 55 10.3 SAP GATEWAY 77 8.1.2.4 Maintenance 55 10.3.1 Using SAP Gateway 77 8.1.2.5 Consolidation 55 10.3.2 Developing with SAP Gateway 78 8.1.2.6 Production 55 10.3.3 General recommendations 80 8.1.2.7 Schematic illustration of six-system landscape 55 10.3.4 Additional sources 80 8.1.3 Sandbox 56 DSAG RECOMMENDATIONS – BEST PRACTICE GUIDELINES FOR DEVELOPMENT -5- 11 THE AUTHORS 81 APPENDIX A: NAMING CONVENTIONS 83 A.1 REPOSITORY OBJECT NAMING CONVENTIONS 84 A.1.1 Package hierarchy 85 A.1.2 Dictionary objects 85 A.1.3 Containers for source code objects 86 A.2 NAMING CONVENTIONS FOR ABAP SOURCE CODE 88 A.2.1 Classic user dialogues (selection screens/dynpros) 88 A.2.2 Visibility 88 A.2.3 Signatures 88 A.3 FURTHER INFORMATION ON NAMING CONVENTIONS 89 A.4 MISCELLANEOUS/LESSONS LEARNED 89 A.4.1 Customer namespaces 89 A.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 DSAG RECOMMENDATIONS – BEST PRACTICE GUIDELINES FOR DEVELOPMENT -6- LIST OF FIGURES Figure 1: ICS risks resulting from insecure ABAP source code 42 Figure 2: Schematic illustration of six-system landscape 55 Figure 3: Change control form (CC) 58 Figure4: W-model with test levels 64 Figure 5: SAP NetWeaver 7.5 PAM browser support 71 Figure 6: Phases of design thinking 72 Figure 7: Supported test phases in SAPUI5 75 Figure 8: SAP Gateway deployment options 78 DSAG RECOMMENDATIONS – BEST PRACTICE GUIDELINES FOR DEVELOPMENT -7- 1 INTRODUCTION As standard software SAP is highly flexible and extensible. Almost every company that www.dsag.de/leitfaden-abap 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- N O tion and upgrading by both the manufacturer and the customer as a result of varying TI C customer requirements. We look forward to your feedback! U D O R This high level of flexibility and extensibility of SAP software has advantages and T N disadvantages. The software can be optimally adapted to meet customer-specific 1. I requirements and significantly increase value added as a result. At the same time 1.2 POSITIONING extensibility exposes the risk of custom developments, which can be complex, difficult to maintain and prone to failure. SAP and a whole range of specialist journals have produced excellent publications on application development, enhancing and upgrading the SAP platform. Throughout this 2012 saw the first edition of the DSAG Best Practice Guidelines published with the aim guide we will be referring to what we regard as literature worth reading. 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. The added value of this document lies in the consolidation of established procedures, We received major readership feedback from the first version; not to mention the fact practical tips and well-proven rules applied in user companies. These guidelines that much has changed in SAP development in recent years and a lot of innovations provide users, developers and project, IT and development managers with recommen- have been introduced. As a consequence, we now present you with the second, totally dations and support so they can avoid ‘re-inventing the wheel’ and instead build on the reworked and updated edition of the DSAG Best Practice Guidelines. The German experiences of others. In the same breath, recommendations in this guide should not version 2.0 was originally published at the DSAG Annual Conference in 2016. The be interpreted as a set of hard and fast rules, but more as a selection of practical tips. English translation we present in February 2018. Hereby, we did not consider any updates but translated the content as of 2016. 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.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 1.3 AMENDMENTS IN THE 2ND EDITION 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. 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 As the authors, our aim is to provide the implicit knowledge of development that is DSAG member feedback, some recommendations from the first edition were updated, evident throughout companies to other DSAG members in the form of a compact while others were comprehensively expanded on by the authors. The sections ‘Develop- document. Our goal is to see the document actively applied and the wealth of experi- ment Environment’ and ‘User Interface’ have also been newly added. ence it encompasses continuously improved upon. Even if you are well-acquainted with the first edition, we thoroughly recommend that For this very reason we have established a community website that provides further you read and apply the recommendations in this comprehensively revised second edition. information on the guide, author and other DSAG member contact information and also enables you to share your outlook with others: DSAG RECOMMENDATIONS – BEST PRACTICE GUIDELINES FOR DEVELOPMENT -8- 2 PROGRAMMING GUIDELINES Extension of ABAP programming guidelines S This section defines firmly established and recommended programming guidelines for Extension the ABAP programming guidelines makes sense primarily if you are E N applications created using ABAP. It tells you how to achieve readable, maintainable, looking to incorporate areas not currently covered by the standard rules. These include LI high-quality ABAP source code using standard SAP tools and discipline. This makes object composition design principles (SOLID4/GRASP5) and architectural concepts such E UID source code maintenance more straightforward and enables different internal and as SAP package concepts or the use of frameworks. Also conceivable is an additional G external individuals to work together efficiently on the (further) development and listing of rules that are regarded as pivotal to your company. Refer to the appendix G N maintenance of programs. (Section B.1) for further details on how to expand ABAP keyword documentation. MI M A Using official ABAP programming guidelines R G O R Since the release of NetWeaver 7.31 SP5, official SAP ABAP programming guidelines P 2. have become a fixed component of ABAP keyword documentation. Developers can access these via the local system installation (transaction ABAPDOCU/F1 Help in BEST PRACTICE ABAP Editor/ADT) or via the SAP Help Portal1. In addition to its comprehensive, • Make your development guidelines available within 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 the the development environment to facilitate quick integrated into the development environment. Instructions for carrying out SAP Easy access. Access menu integration are available under SAP Note 13870862 or for SE80 integra- • Use numerous transparent and verifiable examples tion in the linked SAP Community Network (SCN) blog.3 within the development guidelines that can be re-used SAP ABAP programming guidelines offer as code snippets. • Use the official SAP ABAP programming guidelines as • Extremely well-founded, practical recommendations a benchmark. This extremely comprehensive docu- ment offers detailed recommendations for a broad • Detailed information on each rule, including examples range of activities. • 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 screen 4 Cf. https://en.wikipedia.org/wiki/SOLID_(object-oriented_design) 3 Cf. SCN Article ‘Enhancing the ABAP Workbench with a website containing dev guidelines!’ 5 Cf. https://en.wikipedia.org/wiki/GRASP_(object-oriented_design) DSAG RECOMMENDATIONS – BEST PRACTICE GUIDELINES FOR DEVELOPMENT -9- 2.1 NAMING CONVENTIONS S Naming conventions specify uniform, binding guidelines for naming software objects E N (e.g. classes, function modules) and naming objects in the source code (e.g. variables). LI • If necessary consolidate the SAP document into a E UID summarised version. Due to its scope and depth of We strongly recommend stipulating a naming convention as a guideline for any G detail, a comprehensive look at the official ABAP developments within the SAP system. The aim of using a standardised naming conven- G N programming guidelines would be relatively time- tion is to significantly enhance the maintainability of customer-specific modifications MI and upgrades. This consequently means lower maintenance requirements and costs as M consuming and partially encompass topics that are A well as faster troubleshooting in the event of an error. R irrelevant for day-to-day development activity. If this G O document is to be used in your organisation, we R The explicitly formulated naming conventions should be a component of internal 2. P recommend the assignment of a team to summarise training to familiarise new employees with the basic rules and the specifics of the the document and provide training on use of the company. In addition, making the naming convention the subject of contracts with document within your organisation. Especially in large external developers and partner companies is also an established procedure. Auto- organisations, it may be prudent to bring stakeholders mated checks ensure subsequent compliance with the convention (cf. Section 2.9 and Appendix A). 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 BEST PRACTICE activation and reference made to the document in the Appendix A contains an example of a naming convention. course of acceptance dialogue. ADDITIONAL SOURCES: 1. D evelopment Guidelines for Greenfield Implementation in sync with SAP Custom Code Management6 6 Cf. SCN article http://scn.sap.com/docs/DOC-56285 DSAG RECOMMENDATIONS – BEST PRACTICE GUIDELINES FOR DEVELOPMENT -10-