Instructions for Managers, Architects and Developers

1. Introduction

The following development guideline describes the different aspects of Custom Code Lifecycle and the tools provided by SAP. The document contains the elementary and most important concepts for the development of new custom code in SAP environments. The basics are necessary to implement a global, distributed and secure customer add-on solution. It will not focus on single ABAP programming templates but more on the impact of these on a custom built solution. The main difference is the level of complexity. Customers using SAP are not software producers and the goal of customers IT departments is to fulfill the business requirements in a fast and efficient way and not to create and sell software. A main goal is to ensure the operation of the added software pieces. Consequently the objectives become more focused on the following business scenarios.

• Improve the available standard functionality provided by SAP
• Create new functionality integrated into the SAP products

These scenarios bring the topic of quality to the fore. The availability of new features in the business process is the first juncture when customers become aware of quality. This can be considered as the external quality and for those customers the internal quality, such as costs for maintenance and improvement, is not of concern. Currently we use the term “technical liability” or “technical debt” to describe these internal qualities. The idea behind this term is to illustrate that not focusing on the internal qualities during the implementation leads to costs in the future.

What can we see as technical liability?

• High complexity in methods and classes. Such an artifact is difficult to understand and difficult to change.
• Minimal test coverage. Every change in the coding leads to high risk in the productive environment.
• High complexity of architecture concepts e.g. Flexibility of coding only where it is necessary.
• Low cohesion in components. Implementations in a component fulfill requirements from different areas. In this case a change not only affects one area.
• No decoupling of components. The change in one component leads to changes in further components. 

These guidelines and conventions mainly serve to reduce the technical liability and to help to improve the Custom Code Lifecycle.

1.1        Validity

The guideline shall be valid for all internal development projects and all external service providers developing custom code. All new developments or redesign of existing custom code objects must follow this guideline. Exceptions have to be approved by the quality management.

1.2        Scope Document

This guideline considers the different phases of a complete Custom Code Lifecycle. Normally development guidelines are concentrated only on the Build phase of Custom Code Lifecycle.

Improved Custom Code Development Guidelines are in sync with the planning phase. Only these elements will be developed if there is a kind of business case available. But it might be clear that every predefined business case will have trouble in the Run phase as soon as the real usage of implementation will be taken into account. Each part of the Custom Code Lifecycle influences the other parts. It is important to optimize all parts of the Custom Code Lifecycle so that all parts fit together perfectly.

1.3        Related Documents

SAP has published a Best Practice Document Best-Build Applications. This document forms the basis for ABAP Development integrated to SAP standard
software.

2    Custom Code Lifecycle

2.1        Plan

2.1.1        Requirement

 
 
A clear requirement definition is very important and helps to avoid rash developments.

Use a Software Requirements Specification template to:

• Assist users in determining if the software meets their requirements.
• Reduce development effort. It forces stakeholders to consider all requirements before design begins, reducing redesign, recoding, and retesting.
• Provide a basis for costing’s and schedule. The product description as captured in the Software Requirement Specficiation (SRS) can serve as a basis for estimating project costs.
• Serve as a basis for enhancement as it provides a foundation for continued production evaluation.

Creation of custom code must be driven by the requirement to create something really new. Something not available in a standard software product with the goal to create a competitive advantage compared to your biggest competitor.

• Avoid implementing legacy system product features.
• Avoid implementing convenient features.
• Avoid re-implementing legacy process flows

Custom code put on top of a standard software product must create value with every execution. Seen as an asset the return on investment must be realized in a short period of time. Every unused custom code is a waste of time, money and resources. Standard software offers an incredible number of features, not needed for all businesses sceanrios, but which, in the right environment, create added-value.

2.1.2          Business value

In addition to the classical development processes a new concept will be introduced. The new concept is Design Thinking. This concept puts the business value and the integration of end users into the development process. Design thinking is a methodology for practical, creative resolution of requirements and gaps that looks for an improved future result. In this regard it is a form of solution-based, or solution-focused thinking that starts with the goal or what is meant to be achieved instead of starting with a certain problem. Then, by focusing on the present and the future, the parameters of the problem and the resolutions are explored, simultaneously. This type of thinking most often happens in the built environment also referred to as the artificial environment.

This differs from the scientific method, which starts with defining all the parameters of the problem in order to define the solution. Instead, the design
way of problem solving starts with a solution in order to start to define enough of the parameters to optimize the path to the goal. The solution, then, is actually the starting point.

The six basic steps of design thinking are:

2.1.3          Make or Buy

The decision to make or buy new software should be taken with great care. Identifying available functionality from SAP is not so easy. SAP provides several tools to find Products & Innovations and the Innovation Discovery tool to simplify your search for new functions. For those cases where SAP or other Software Companies do not provide a product it is very helpful to use a SWOT analysis to make a decision. This would allow achievable goals or objectives to be set for the organization.

• Strengths: characteristics of the business or project that give it an advantage over others.
• Weaknesses: characteristics that place the business or project at a disadvantage relative to others
• Opportunities: elements that the project could exploit to its advantage
• Threats: elements in the environment that could cause trouble for the business or project
  

Identification of SWOTs is important because they can inform later steps in planning to achieve the objective.

2.1.4          Custom Code Usage Forecast

Custom Code starts always with a requirement to close a gap in a business process with help of a piece of software. In the best case this gap can be closed with configuration of the standard software. Often the easiest way is starting a custom development requirement based on a solid business case including efforts and benefits. Most often neglected is benefit case in terms of future usage and KPIs to validate the investments. Forecast represents the expected usage in a productive phase of this custom code and will have a positive impact on aspects like quality and business criticality. Typically a usage analysis delivers the high level execution of the software. But it is critical to know if the implemented custom code fits the specified requirement.

Usage forecast will help you to

• Define a gap rating to support the decision process
• Set the right focus on the required test scope
• Validates the business benefit in relation to the real usage
• Validates the business case of the gap and implementation project success

Of course it is very difficult to forecast an expected usage. But this rough estimation will be the counterpart of the usage logging available in the custom code management methodology. Move forward from a classic Boolean usage towards the direction of knowing when and how often. If the measured usage shows a high discrepancy compared to the estimated usage you then has valid decision criteria to rate the benefit of this custom code investment.

Find an answer to the questions

• Was it worth developing at all?
• Was it tested enough?
• Was it over-engineered?

Experiences from past custom code development implementations demonstrate a trend towards over-engineering. Instead of building simple and easy to understand pieces of code, often huge frameworks with thousands of functions are implemented for customers on top of the standard software. Often the justification is articulated as follows: We are preparing maximum flexibility to complete potential gaps in the initial business requirement.

2.1.5          Development Process

Development processes are long established. Over the past years of software development a clear shift of mindset can be realized. There exists no clear statement which kind of development process will be more efficient. Elements like project management, resources, tasks and of course the goal influence the success of realization. The waterfall method compared to an agile development process will have the benefit to be very structured and will fit into a project plan. Agile methods sound like coming from a foreign asteroid, but at the end only the result and the success measure.

2.1.5.1          Waterfall methodology

Waterfall methods represent the most structured implementation method, stepping through different phases like requirements, analysis, design, coding/configuration, and testing in a strict, pre-planned sequence. Each phase has predefined quality gates and checkpoint to be controlled. Each phase can be huge from content and long from time perspective. It is a hand-in-hand process. Triple constraints (Time, scope, costs) and dependencies are managed across phases. Progress and success is generally measured in terms of clearly defined phase deliverables. There is always a risk to miss the
goal also in case all phases were completed successfully. The explanation is simple and easy to understand. In a very detailed precompiled project setup any
side effects can influence the main goal. In some bad exampled only at the end in the final assembly phase you will see what you will get.

2.1.5.2          Agile Custom Code Development Process

A new trend for development processes is agile development. Compared with traditional software engineering (waterfall) , agile development is mainly targeted at complex systems and projects with dynamic, non-deterministic and non-linear characteristics, where accurate estimates, stable plans and predictions are often hard to get in early stages, and big up-front designs and arrangements will probably cause a lot of waste, i.e. not economically sound.

These basic arguments and precious industry experiences learned from years of successes and failures have helped to shape Agile’s flavor of adaptive, iterative and evolutionary development.

The Agile Manifesto is based on twelve principles:

• Customer satisfaction by rapid delivery of useful software
• Welcome changing requirements, even late in development
• Working software is delivered frequently (weeks rather than months)
• Working software is the principal measure of progress
• Sustainable development, able to maintain a constant pace
• Close, daily cooperation between business people and developers
• Face-to-face conversation is the best form of communication (co-location)
• Projects are built around motivated individuals, who should be trusted
• Continuous attention to technical excellence and good design
• Simplicity—the art of maximizing the amount of work not done - is essential
• Self-organizing teams
• Regular adaptation to changing circumstances

These principles lead to new concepts like user story modeling, planning poker, scrum teams or kanban board.

It is not possible to describe all these concepts in this document. The experiences with agile development inside SAP allow us to recommend agile development.

For the development process it is important to define a clear ownership for the different rolls in the development process.

Summarized:

• Representations of agile approaches are SCRUM and eXtreme programming
• Tasks are broken into small increments and iterations are short time frames ('time-boxed‘)
• Multiple iterations may be required to release a product or new features as changing requirements are welcome
• Teams are generally co-located, and empowered to make decisions
• Documentation is kept to a minimum Progress is measured in terms of working
  functions or products

More information can be found here http://ase-education.de

2.1.6  Minimal Documentation

Documentation is an unpopular part of the development process. In this guide we will concentrate on maintenance and user documentation.

Everything starts with the well-described business requirements and a description of the business value of the planned code implementation. The business requirements will have the biggest impact on the final solution. The better and more detailed these requirements are described the better the code will be implemented, as less change requests will be started after code release.

For every development process it is important to have specifications and design documents. These documents will be created during the development process and will describe details which are not important for the maintenance or the user. Small changes will not be integrated in these documents and after a while they become outdated.

The technical documentation focuses mainly on the interfaces and how the code was implemented in the corresponding development language. Depending on the history of creation the document will be outdated as soon as the first change request is implemented.

User documentations will be created typically for training reasons. Inside the documentation the screens and the tasks working with the application will be described.

A new aspect is the documentation for the maintenance. This documentation should be done in the coding itself. Together with ABAP in Eclipse a new kind of documentation will be introduced.

Maintenance documentation in combination with an operational handbook will be the smallest, easiest to create and most sustainable form of a documentation. In the best case this documentation is integrated in the code.

2.1.6.1          Recommendation ABAP Doc

ABAP Doc allows you to document declarations in ABAP programs, based on ABAP Doc comments. This is the way the important information about the application should be documented. After an incident the first look is always into the application.

Editing ABAP Doc Comments

ABAP Doc comments consist of a single comment line or a coherent block of several comment lines. In the source code editor, they can be placed in an empty line directly in front of a declarative statement like data declarations, method definition, class definitions, and so on.

This is an example of how ABAP Doc can be used.

ABAP Doc comments can be added in ABAP classes, ABAP interfaces, ABAP programs, or ABAP function groups to describe functionality in the code element. In addition, you can generate ABAP Doc by importing the existing descriptions of global classes and interfaces including their attributes, methods, parameters, and so on.

2.2        Build

2.2.1 Basic Development Environment

In this chapter some of the basic development environment questions will be described. What is a good structure of the development teams, which development environment should be used and how does the system landscape look like?

2.2.1.1          Development Workbench / ABAP in Eclipse

SAP offers two development workbenches (IDE) . This is the well known in SAP NetWeaver integrated development workbench and the new ABAP in Eclipse Workbench. ABAP in eclipse is available for SAP Systems NW 7.31/7.03 and NW 7.40.

The integrated development workbench (Transaction SE80) provides all necessary features for a classical ABAP development project. For new product enhancement like HANA the switch to the ABAP in Eclipse development workbench is necessary. Eclipse is a development workbench used for several development languages like Java, C#. These development languages are part of the standard education in universities and new employees know how to work with eclipse.

It is recommended to switch to the ABAP in Eclipse development workbench as soon as technically possible

ABAP in Eclipse offers you the following benefits compared to the classic ABAP Workbench

• Modern UI
• Modern look and feel
• Integrated interface documentation with mouse-over
• Plugins available to support for code quality, code patterns, external re-use library
• Plugins for Code inspections, Code Vault, Clone Detections,….
• Lower training costs to empower new hires for code development
• Only workbench supporting new Netweaver tools like Core Data Service, SQL Monitor, Dynamic Log-Points, ABAP Doc, Runtime Check Monitor etc…
• With the latest release a full integration into the ABAP Test Cockpit inclusive excemption handling

2.2.1.2          Development Landscape

The classical SAP System landscape “Development -> Quality -> Productive” is not flexible enough for the modern requirements. Typically a second landscape for a new project will be installed and merged later-on back to the standard development landscape. Today, not only one project is ongoing and one project landscape is not enough and the maintenance for the productive system must be guaranteed as well. A new landscape will be introduced. This new landscape allows a flexible “Release” development and installation. Even concepts like Parallel Releases/Projects and Release Validation can be achieved with the proposed development landscape.

The dual landscape with a pre-production system:

2.2.1.3          Releases & Maintenance

Talking with many of our customers globally, there is enormous pressure on being able to implement new business models. Innovation and speed are required to compete with cloud providers like Amazon.com, for example, but up-front investments are hard to obtain and justify. Outcomes have to be predictable.

Very often IT, and even the existing software solutions (SAP and non-SAP), are perceived as inhibitors of required business innovations. This is often due to the extent of modifications, but may also be caused by a lack of the skills and resources required to adapt and change existing solutions. Changing
this perception requires a solid strategy and a new way of working together. It requires a platform that enables, not prohibits, business transformation. With the SAP Business Suite on HANA and the SAP Mobile Platform, SAP provides the building blocks of such a platform. Moreover, the SAP building blocks fit
together and are managed and supported as one end-to-end business solution by SAP orchestration. SAP solutions are efficient to run, and they are built to
scale. Last but not least, with the SAP mobile platform, every consumer and partner is always connected. In this way, SAP provides the capabilities to run
SAP solutions without interruption. Many SAP MaxAttention customers run their SAP solutions as a single global instance, supporting their business  operations all over the world.

Within the white paper Two Value Releases per Year a concept of parallel development landscape will be introduced.

2.2.2          ABAP Development

2.2.2.1          Basic ABAP Development Rules

Creating good custom code shall follow the officialABAP Guidelines. This guideline is the basis for all developments. These guidelines are valid for
every development in ABAP but in a customer environment with a restricted scope, some rules shall be adapted to support the best practices for SAP Custom Code.

2.2.2.2          Custom Code Management – Rules

Develop custom code on the basis of available knowledge – Keep it simple

ABAP OO vs. function oriented programming

ABAP OO is strongly preferred for new development. The service-oriented paradigm does not fit to the former function oriented programming style. As a consequence, most of the functionality should reside in global ABAP classes and their methods. Care should be taken during class modeling and interface design to avoid objects that are too granular & that lead to the instantiation of hundreds of small instances at run time, without providing any real benefit. You don’t always need an object; pure data is sufficient in many cases. In short: whenever object orientation collides considerably with performance, performance has the higher priority. Also by implementing UI interfaces like e.g. Webdynpro you should use the benefits of ABAP OO.

Never implement function oriented programming models with the help of ABAP classes and methods.Function modules are not class methods, etc.

• Never develop in ABAP OO if you don’t understand the concept behind.
• Maintaining existing custom code: continue developing in the given style of the existing source code.

If you are more familiar with the classic ABAP concept, use them until you reach the technical limits.

• Avoid over engineering – Keep it simple
• Don’t implement flexibility where it is not required

Implementing in ABAP OO will help to make software more structured, but.

• Avoid class events if not really needed
• Avoid class multi-level inheritance
• Avoid class redefinitions
• Keep the Lines of Code of the units small. Don’t use more than 100-200 ABAP statements.
• Avoid sophisticated ABAP capabilities
• Avoid more than 3 nested code levels

ABAP offers a bunch of capabilities to make the developers life easier. From a security, support and maintenance point of view do not use such techniques.

• Avoid dynamic call of subroutines (perform xy in <program> if exists)
• Avoid dynamic selection of variables, tables,…
• Avoid dynamic call of methods, classes, function modules
• Avoid dynamic assign of variables outside the visibility of the unit
• Avoid Import/Export of memory -> static methods and attributes of global classes
• Avoid usage of SET/GET parameters
• Avoid Field exits
• Avoid definition and use of macros
• Avoid creation of clones
• Avoid generic exception catching

A simple way of modification avoidance is doing cloning of SAP original units. With the introduction of ECC 6.0 it is strictly recommended to avoid clones. The
original program might have implemented enhancements spots. In the cloning process all these implementations will be deactivated and lead to functionality
loss. Furthermore patches on the original will not be inherited to the clone. Stay as close as possible to SAP standard and use the available enhancement or
modification possiblities.

• Avoid using multi-reused includes

We do not recommend to reuse existing includes neither from custom code nor from SAP in your own new programs. It might be an easy way to save effort by including foreign includes in your code. As long as it is limited to declaration parts it can be accepted, but reusing subroutine pools in another environment will lead to uncontrollable behaviors of program logic. Also unused subroutines/methods will be accessible and ABAP Code Inspector will validate the correctness of code by unpacking these Includes and assign them to the main program. Further details in chapter See “Reuse of Functionality”

• Use embedded ABAP Checkpoint statements

ABAP offers statements like Assertions, Log-points, dynamic breakpoint and dynamic trace-points to enrich the custom code with monitoring and support capabilities.

• Use ASSERTION to detect implementation errors
• Do not use ASSERT ID to check business logic
• Only use ASSERT (without ID) with an easy to check condition to catch a critical system state. It will always be active, it will always affect performance, it will create a short dump if the condition evaluates to false.

Details in chapter Checkpoints

• Use SAP frameworks if possible
• Use ABAP List Viewer for all table outputs
• Use SAP Decision Service Management (DSM) / BRFplus for complex or simple but
  highly flexiblebusiness rules.
• If a custom code object contains huge structures of IF-ELSE or CASE/WHEN statements combined with a high number of change requests to adapt business logic, we recommend to use SAP Decision Service Management, which is an add-on to BRFplus, for business rules instead of coding.
• Develop multi language – multi currency – multi unit and Unicode

One key benefit of the ABAP language is the integrated multi language, multi-currency, multi-unit capability.

• Never use hard coded texts – use translatable text pools
• Never develop on fixed currency – use predefined DDIC structures
• Currency and Units should be only used with ISO codes. No internal mapping to SAP proprietary codes is allowed.
• Usage of country code always in ISO format
• Ensure for all custom code the Unicode flag is set.
• Naming & Documentation & Templates & Patterns
  • Variables shall have names or common programming language naming
  • Inline documentation and common documentation must be done in English only
  • Place comments directly in front of the code to be commented
  • Do not use method documentation to comment methods
  • Always provide understandable descriptions where a description field is available
    • e.g. description of parameters
    • or description of methods
    • Use templates
      • Unit headers shall be used including elements like business responsible, project,…
      • Changes shall be documented in the header – Change history
      • Use code templates if available
      • Templates can be maintained in table TSE05
      • Use common OO patterns
        • Factory
          pattern
      • Don’t use comments like INSERT START INSERT END,… to make changes visible
      • Don’t uncomment code to be deleted
• Avoid modifications

It is strictly recommended to avoid any type of modification of the SAP standard. But instead of cloning follow the checklist. Details on how to make a customer specific enhancement is described in another chapter.

• Check if the requirement can be implemented by activation of an existing SAP business function
• Check with SAP Support ticket if the modification can be avoided (ICC, MJC)
• Check if there are any predefined enhancements available (e.g. appends, User exit,..)
• Check if the change can be implemented with an implicit enhancement
• Modify the original SAP program by introducing an explicit enhancement spot and implement the spot.
• Describe and modify the original unit including all dependencies.

More details in chapter Modifications

Re-use capabilities of SAP elements

In most cases custom code contains several re-use elements of the SAP environment. Direct usage always will lead to additional efforts in upgrade or support package update. To minimize these efforts we recommend

• Use only released APIs like BAPIs
• Don’t access SAP database tables with SQL statements
• Re-use existing SAP authorizations depending on the business requirement
• Work always with the original DDIC structure and take care of any potential SAP appends
• Never update database entries directly
• Re-use custom development element

After some years of custom development it might happen that other projects need similar functionality from other or older projects. Using such elements will
automatically lead to dependencies that must be able to be separated without pain.

• Define global or local usage at specification time
• Never clone and enrich a global defined functionality
• Never change a global released functionality
• Don’t redefine local functions as global functions after release.
• Re-use capabilities or re-use 3rd party frameworks.

Implementation of projects often reuse elements of others customers implementations or preinstalled frameworks. This might be a benefit to speed up the time to build a new custom code but will lead to massive impacts in maintenance and incident cases.

• Never import transports from external sources
• Check the legal IP rights of the foreign code
• Check the usage capabilities and ownership of 3rd party packages after expired license agreements
• Check if the imported code is SAP NW certified
• Avoid developers importing code from local files from other projects without validation
• Avoid the existence of tools like SAPlink in productive environments
• Make code quality checks mandatory during the development phase
  • Ensure that you check your ongoing developments using ABAP Test cockpit or Code Inspector
  • Ensure that priority 1 or priority 2 errors are fixed before releasing the transport request
  • Pay special attention to reported performance and security statements
  • Ensure that the code will be HANA ready by fixing HANA issues reported by the Code Inspector or ATC

2.2.2.3 Database oriented programming

With the introduction of HANA a bunch of new programming techniques are available.

• Do as much as you can in the database to get the best performance -> Use Core Data Services (CDS)

Also if you have a HANA database available follow the following rules

• Use OpenSQL as often as possible instead of native database programming.
• Use the CDS (Core Data Services) instead of old DDIC Views
• Use AMDP (ABAP Managed Database Procedure) only if there is a real need and with needed experience

All three points are full supported in CTS and transport management.

• Avoid using native HANA coding. Same rule as years before for all other databases with EXEC SQL.

In case you need a switch between legacy database and HANA optimized code we recommend to define at given position in main code a new Badi definition with a BAdi call with filter value DBSYS_TYPE. The current valid value can be read with static class attribute CL_DB_SYS=>DBSYS_TYPE

Implement one or multiple filter dependent implementations.

Further details in the SAP HANA End to End Development Guide

2.2.3          UI Implementation

SAP offers several state of the art UI technologies to support customers demand for best end user experience. An excerpt of available UI techniques and guide how to implement it can be found under https://experience.sap.com/post/show/111

Renewal of existing SAP Suite Applications like ERP can be realized without any custom code programming with SAP Screen Personas.

2.2.4          Package Concept

Structured packaging of custom code with a Package Concept can be used to structure the custom code instead of using a kind of naming convention for the objects. The package structure is used in tools to organize and analyze software.

Use a package hierarchy concept

• For every business functionality use a dedicated enclosed package
• Interfaces to external systems shall be managed in a dedicated interface package separated by interface partners (e.g. by systems)
• Global functionality in global re-use packages

Separate business behaviors in packages with the main goal to replace or delete each package.

Naming concept of packages shall

• Never represent project structures
• Never represent organizational company structures like locations
• Never represent HR structures
• Never represent ABAP code objects collectors like “reports, function
  modules,…”

2.2.5          Enhancements

At the beginning, we repeat the basic reasons why enhancements are so much better than modifications and why they save you a lot of work in an upgrade. The Enhancement- and Switch Framework is almost as flexible as implementing modifications when it is necessary to change or add something to SAP standard objects. This means, you achieve the same aim, but use a different technology.

With enhancements you avoid most of the work that modifications cause in the software lifecycle. Enhancements are never overwritten in an upgrade, because they are objects in your namespace, while modifications are part of the object they modify. So with enhancements, you have most of the advantages of modifications, while enjoying freedom from most of the work that modifications require in an upgrade.

Customer Enhancements of an SAP object are objects in their own right and live in the customer namespace in your packages.

Together with the Switch Framework the enhancements are a strong feature for advanced Custom Code development. The idea behind using enhancements in custom code objects is to implement custom code similar to SAP Enhancement Packs. The documentation with examples can be found in the appendix.

2.2.5.1          Enhancement of SAP

SAP provides different concepts to enhance the provided standard software. In this chapter some of these concepts will be mentioned.

BADI’s: BADI - Business Add Ins

are enhancements to the standard version of the SAP code. They can be inserted into the SAP system to accommodate user requirements that are too specific to be included in the standard delivery. Customers can find the possible enhancements (BADIs) in their SAP system in the Implementation Guide (IMG) and in the component hierarchy. BADI definitions are included in the IMG so that customers can create suitable, company-specific implementations. SAP guarantees the upward compatibility of all Business Add-In interfaces. Release upgrades do not affect enhancement calls from within the standard software nor do they affect the validity of call interfaces.

Two different views are available:

• In the definition view, an application programmer defines exit points in a source that allow specific industry sectors, partners, and customers to
  attach additional coding to standard SAP source code without having to modify the original object.
• In the implementation view, the users of Business Add-Ins can customize the logic they need or use a standard solution if one is available.

User exit:

A user exit is a three-character code that instructs the system to access a program during system processing.

SXX: S is for standard exits that are delivered by SAP.  XX represents the 2-digit exit number.

UXX: U is for user exits that are defined by the user.  XX represents the 2-digit exit number

Customer exit:

The R/3 enhancement concept allows you to add your own functionality to SAP’s standard business applications without having to modify the original applications. SAP creates customer exits for specific programs, screens, and menus within standard R/3 applications. These exits do not contain any functionality. Instead, the customer exits act as hooks. You can hang your own add-on functionality onto these hooks.

ABAP Enhancements

As part of the enhancement concept, it is possible to enhance ABAP source code, without modifications, using source code plug-ins.

You can execute enhancements to implicit and explicit enhancement options. The Enhancement Builder tool for defining explicit enhancement options and for implementing enhancements is integrated in the ABAP Editor.

Implicit Enhancement Option

At common enhancement places, implicit Enhancement options are available.

Examples:

• End of Executable Program, Include, Function group,
• Dialog module
• Begin/End of Form routine / Function module / Method
• End of a structure
• End of Private/Protected/Public Section of a local class

Explicit Enhancement Option

Predefined enhancement options can be defined in source code.

• They are additionally stored inside Enhancement Spots.

The enhancement spots are used to manage explicit enhancement options. Enhancement spots carry information about the positions at which enhancement options were created. One enhancement spot can manage several enhancement options of a Repository object. Conversely, several enhancement spots can be assigned to one enhancement option.

Switch Framework

The Switch Framework (available as of ABAP 7.0) is made to control the visibility of development objects at runtime. If a switchable development object is not
switched on it is not part of the ABAP load and therefore behaves as if it does not exist at all though as a transport object it still exists. The Enhancement
and the Switch Framework are closely integrated which means: All enhancements of the Enhancement Framework (but also many other objects) can be switched by the Switch Framework.

The three major use cases or scenarios of the Enhancement Framework are

• The adaptation of SAP standard programs by customers
• The re-integration of the SAP Industry Solutions in the ERP core
• The Enhancement Package Strategy of SAP ERP 6.0 and the Business Suite 7.0.

Enhancement of Tables and Table Index

Append structures are used for enhancements that are not included in the SAP standard code. This includes special developments, country versions and adding customer fields to any tables or structures.

An append structure is a structure that is assigned to exactly one table or structure. There can be more than one append structure for a table or structure.

The following enhancements can be made to a table or structure TAB with an append structure:

• Insert new fields in TAB,
• Define foreign keys for fields of TAB that already exist,
• Attach search helps to fields of TAB that already exist,

These enhancements are part of the append structure, i.e. they must always be changed and transported with the append structure.

When a table or structure is activated, all the append structures of the table are searched and the fields of these append structures are added to the table or structure. Foreign keys and search help attachments added using the append structure are also added to the table. If an append structure is created or changed, the table or structure assigned to it is also adjusted to these changes when the append structure is activated.

Since the order of the fields in the ABAP Dictionary can differ from the order of the fields on the database, adding append structures or inserting fields in such append structures does not result in a table conversion.

The customer creates append structures in the customer namespace. The append structure is thus protected against overwriting during an upgrade. The fields in the append structure should also reside in the customer namespace, that is the field names should begin with ZZ or YY. This prevents name conflicts with fields inserted in the table by SAP.

If you create an append structure for a table or structure, only those enhancements are allowed that are consistent with the enhancement category of the enhanced table or structure.

The new versions of the standard tables are imported after an upgrade, and the fields, foreign key definitions and search help attachments contained in the append structures are added to the new standard tables at activation.

Creating an index is not so critical. Nevertheless with an extension index you can create an additional index for a table in a system other than the original system of the table. Indexes are used to speed up searches in tables.

When an extension index is created, the relevant table remains unchanged. An extension index is an enhancement of the standard. Extension indexes are automatically copied over during upgrades and no modification adjustment takes place. See the following discussion http://scn.sap.com/thread/3355684.

2.2.5.2          Modification of SAP

A modification is a change of existing code objects or foreign code objects (3rd party solutions) that are no part of the current SAP software stack. Normally a modification can be seen as a change of an SAP object. Exceptions are manual activities of notes or implementations of former user exits and also cross transports of coding from external systems. Having modifications within an SAP system is not a big issue as long as the complexity and dependency is low and the business requirement is well defined. Unfortunately, many modifications are made because the hurdle to do it is extremely low. Strict governance processes to avoid modifications will fail in most cases because developers will try to solve the requirements with other ideas. Prominent here is the idea of cloning SAP code, which is more critical from a maintenance perspective. This leads to the following rules and guidance

• Do not modify SAP code if it is not really necessary
• Never clone an SAP original object

In case a modification is expected to be necessary, there are several optional possibilities to validate or reject this need e.g. in an early phase of the
custom code requirement lifecycle. To follow a zero modification strategy use the offering of the “SAP Innovation Control Center” to determine a
detailed gap analysis. This organizational project setup at customer site will establish direct access to the SAP experts. http://www.sap.com/services-support/support/plans/info/innovation-control-center/index.html

Consuming SAPs latest innovations shipped via Enhancement packages can also avoid the need for modifications. Browse through SAP capabilities with the self-service “SAP Innovation Discovery”  (https://apps.support.sap.com/innovation-discovery). Discover the potential of the SAP standard software at an early stage including sneak previews of upcoming releases.

SAP Find Innovation (https://service.sap.com/findinnovation). This information center provides customers with details about SAP Business Suite
innovations. It includes a collection of the entire portfolio of innovation for SAP Business Suite applications, including innovation delivered via SAP Notes,
SAP support packages, SAP enhancement packages, and future SAP roadmaps.

SAP Business Function Predictor (https://service.sap.com/bfp). This service identifies relevant functionality included in SAP enhancement packages for SAP ERP 6.0. SAP Business Function Predictor uses customer productive system usage analysis to prepare a report that includes a tailored list of new business functions that enhance transactions, identifying the relevance of each business function for the customer and how often that function is used by other SAP customers. The service also offers direct access to all relevant information for each predicted business function, including overview presentations, release notes and documentation, and technical usage mappings.

Proactive and also reactive validation is possible through the “SAP Accelerated innovation Enablement” service (https://service.sap.com/aie). This service is an essential element of SAP Enterprise Support. SAP provides up to five person days per calendar year of remote assistance and enablement for each customer to help evaluate the innovation capabilities of the latest SAP enhancement packages delivered with SAP Business Suite 7.

SAP Modification Justification Check. The objective of this offering is to provide expert advice on how to avoid SAP source code modifications whenever possible by using SAP standard functionality, or by taking advantage of the SAP Enhancement Framework.

All the mentioned services have a slightly different focus depending on the progress of the implementation status of the modification. But all follow the goal to avoid a modification at an early stage.

Finally if the decision was made to modify it is important to make the modification with the goal of minimal impact. Use the SAP Enhancement Framework to implement the modification.

Guide: The Many Ways to Enhance a SAP Application With the New Framework

Implement implicit enhancement spots instead of modifications.

For more details read the guide Overview of the Use Cases and the Advantages of Enhancements
Over Modifications.

For all information using the SAP Enhancement framework follow the blog “SAP Switch and Enhancement Framework”. The How-to guide “Modification free adaptions of SAP” will give you a step- by-step description on how to replace modifications with enhancement technology.

In combination with the given package concept including package hierarchies the implementation of planned modifications should be done in separated packages. If you adhere to the following guide you will have some real benefits in the future with custom code lifecycle management.

• Modify only the SAP original program with the position of the enhancement spot in the SAP original package
• Define the technical behavior of the enhancement spot in a global re-use package and describe well the purpose of this enhancement definition
• Implement one or several spots in one single package and ensure this package identifies encapsulated business functionality.
• Always implement using delegating ABAP procedures like methods, subroutines or function modules

These 4 steps are the biggest mindset switch because position, definition and implementations are strictly separated. The delegation of the code to an dedicated ABAP object will ensure the continuous usage of Code Inspector for your customer implementations. It may sound like too much effort compared to the classic ways of modifications, but the benefits will be seen later on. Implementing Enhancement spots can be seen as code-plugins, similar to includes at a given position with direct relation to surrounding SAP variables and logic. As soon as you have the business requirement to support different organizational units, countries, locations you should refrain from spending too much time implementing IF-ELSE or CASE statements. Instead it is better to define a customer specific Business Add In (BAdI) and use the filter features of implementations.

• Define customer Filter BAdIs

Details about BadI’s and how to define them can be found at SAP Help Portal. Important key features are multi- use BAdI and filter conditions. With
these features you are able to transfer the business logic down to an implementation and the business decision flow can be controlled by filter
conditions. Of course BAdI implementations can be integrated into the switch concept to ensure business logic is active or inactive.

One benefit is the capability of switching implementations on and off if the spot was defined as reversible.

• Assign a switch to the implementation package

Details on how switching works and how to define customer specific business functions and business functions sets can be found at “The basics about switching”.

Switching of implementation packages leads to the possibilities to activate business logic at a given time; replacing logic A with logic B and also implementing development projects completely independent from the maintenance stream in the same development landscape without influencing the business. And finally

• Build your own customer business functions including dependencies

In cases the SAP enhancement framework does not cover all required capabilities and there is still the wish to modify there is one important rule

• Never deactivate the SAP modification assistant

The modification assistant is a tool to improve adjustment time in a support package or Upgrade case. Some customers deactivated the SAP Modification Assistant globally. The system configuration for modifications can be verified with report RSPFPAR. The parameter entry for

eu/controlled_modification

must have a value different to 0.

Allowed modifications of SAP

A modification is a technical based change of the original system. This happens under the following circumstances

• Manual implementation of SAP corrections via notes
• Cross transport of transport of copies of objects from other systems
• Implementation of classic user exits (subroutine with name user exit)
• Application specific enhancement models with modification techniques

All these modifications can be seen as allowed modifications, as long as the origin and the modification handling is clear defined.

In most cases such modification do not play an important role. In a modification adaption process SAP corrections will be removed automatically as soon as you implement a newer support package. user exit implementations remain untouched. Cross transports are located in customer namespace or are under responsibility of the ISV/partner. Application specific changes can be regenerated or there exists special tools to adapt them.

To make it easier in the custom code management to distinct between allowed modifications and customer specific modifications simple but efficient governance rule can be introduced in the overall quality management process

• Never mix note implementations with custom code bug fixes - Create a unique transport for notes
• Never implement customer modifications with system users like SAP, DDIC or Upgrade
• Use different users to make the SPAU adaptions of modifications related to the task

For the manual activities of SAP note implementations including SNOTE activities try to create a unique user like SAPNOTE who is implementing all SAP corrections. In the corresponding transport documentation document the real end-user name who is doing the implementation of the note.

With this simple approach you are able to distinct between real business related modifications and corrections of SAP code.

For real business modifications please follow these rules

• Implement the modification with a real user name
• Do never mix modifications with different purposes in one single mass transport - Ensure grouping regarding purpose
• Give the modification transport a valid meaningful description - Do not use texts like "all modifications in system ...'
• Ensure to maintain the SOLAR01 business process in Solution Manager system to document the modified business process
• Assign a business owner in the Custom Code Lifecycle management tool (CCLM) on the Solution Manager

With these steps you will be able to monitor the growth and change behavior of modifications. CCLM will also helps you to track usage of modifications and the single point of entry for documentation and the business relation.

2.2.5.3          Custom Code Implementation Types

Custom code without SAP relations

100% SAP independent custom code is really rare. On top of the ABAP platform such solutions will be built to complete very special business requirements never be part of a SAP standard solution. These solutions will automatically lead to a high maintenance and support behavior because none of the follow up tasks can be outsourced either to SAP or to any other maintenance contractor. Often the relation to main standard business processes is not given and documentation is not available

• Try to avoid 100% home grown custom code solutions if you are not a software vendor

Custom code with SAP relations

Custom Code development has often integration points to SAP standard software. Some of these integration points could be changed in the next software upgrade. SAP provides different tools to identify the integration points and to identify which custom code objects must be adjusted after the software upgrade. Active Global Support provides with the new EHP Scope and Effort Analyzer detailed information about the efforts for the upgrade.

• Reserve up to 10% of your initial development efforts for maintenance tasks in the future
• Use SAP Custom Code Management Tools to monitor impact

Enhancing existing custom code branches

The versioning of code objects should be activated. It is recommended to document at the header of the code object which enhancement has been done. Documentation inside the coding like “change starts here” or make coding as a own comment line is not necessary, because versioning provides the features to identify the changes between different versions.

• Do not create copies of existing custom code to implement new functionality
• Use enhancement concepts to separate the business requirements
• Decommission unused custom code

2.2.5.4         Optional tools to support developer's work

Easy access to the guidelines

Enforcing standards such as those outlined in the Development Guidelines will be more easily achieved and adhered to where developers have access to these guidelines and where a high degree of visibility (daily) is placed on achieving these standards. Furthermore any updates, important notifications and changes must be distributed to all developers on an easy-to-consume communication channel. As emails will not be helpful and Wiki pages are not bound to the developer’s workbench a simple but effective method is to bundle the guidelines with the developer’s workbench in one place.

Include a HTML intranet web page or Wiki page to the main menu of SAP session start screen. Use transaction SM30 to maintain the cross-client customizing table SSM_CUST and add the entry

SES_URL= <http address>

If you have any issues follow the instructions in note 1387086.

ABAP Code Templates with ABAP in Eclipse

ABAP code templates are structured descriptions of coding patterns that can be used in the ABAP source code. Code templates help the developer to reduce the time spent on routine editing activities and improve consistency when writing code. They allow for quick generation of commonly used ABAP code, as well as easy customization. ABAP code templates go beyond the functionality of simple code snippets. They include direct integration with code completion, the ability to use predefined and custom variables, and the ability to improve style uniformity and validity of ABAP code. When using code snippets, you basically get a shell that you can insert and edit manually.

ABAP Development Tools provides a number of predefined code templates for ABAP. In addition, you can create your own templates or edit existing ones. You can view, edit, or create new ABAP code templates using the preferences page.

Templates are inserted into the ABAP source editor

• Using code assist (Ctrl + Space)
• Through Drag & Drop using the Templates view.

2.2.6          Quality

Code quality is one of the most emotional topics in a development guideline. Programming is like talking a language. English in USA is different to English in United Kingdom and it is not easy to define who talks with higher quality. Therefore it is essential to define the common basic rules for quality.

The quality level of coding is the essential and most important part of the whole document.Instead of the optimization of elements like incident management, incident processing times, hotline, etc. It is very important to ensure only best of class custom code will move into your system. A bug found in a very early phase of the development lifecycle will save a lot of money in later phases.

In addition to a contractual alignment between the developers organization and customers IT, we recommend to define a

• Quality governance process with quality gates
• Central responsible quality manager
• Approval check document

This approval check document must be valid for all participants handling code and contains the following building blocks.

This first check should be automatically analyzed. Within SAP it is possible to use SAP Code Inspector or the SAP ABAP Test Cockpit to evaluate a “minimal” set of checks against any kind of code imported to the customer system (In case the implementation will be don by 3th Party). The Q-gate for this check must ensure that NO custom code can be transported to the next system as long as there are errors with priority 1.

• Check 100% of custom code with SAP Code Inspector

It is possible to automate the analysis and to inform the developer via E-Mail about the required changes to fulfill the common basic quality rules. These static
quality checks don’t identify semantic issues and issues in design and architecture.

• Use the same Code Inspector variant in all system

We recommend using the same minimal Code Inspector variant in the development system in the transport release and in the quality system with a scheduled job. Results of the global run should be replicated to the development system to give developers the chance to fix all prio 1 and prio 2 issues.

It is also recommended to use a methodology of Code Review like FAGAN to verify that the requirement is fulfilled from design of the architecture to the implementation. These code reviews are time consuming and should be done for a minimum set of 5% - 10% of the code. Criteria for object selections can be done on the basis of the Code Inspector results or any “gut feeling” of the responsible quality manager. Each defect found via code inspections saves ~10h of downstream efforts in subsequent processes.

• always look for latest SCI/ATC improvements shipped via SP or notes

A general recommendation is to start as early as possible with quality checks so that corrections can be done directly and the identified error pattern
eliminated. The following benefits can be achieved using any kind of Code Inspection of your custom code.

• Early error detection
• Alignment with given ABAP code standards
• Knowledge exchange to onboard new developers: Feedback as a core process of development
• Share knowledge: Avoid double work. Know what others are doing.
• Transparency and flexibility of using tools

2.2.7          Test

Testing is a substantial part of the program development process. Tests verify the intended program behavior. In that sense also debugging or simple text traces are tests. Nevertheless these two methods require human judgment. This soon limits the test possibilities when coming to more complex test scenarios: debug information must be checked step by step and text output very easily becomes so voluminous that they are almost unmanageable (“scroll-blindness”). A long-term benefit from testing is only achievable by automation. A unit test tool solves the mentioned problems with developer tests. ABAP Unit is the new unit test tool for ABAP. Tests can be conveniently grouped into test tasks. Test results are condensed and become instantly evident. Test tasks can be automated.

2.2.7.1          Building a Test Case

In order to build a test case it is necessary to know what requirement or test conditions are fulfilled with the execution of the test case. The execution of the test case will need to trace at least one requirement; otherwise, it calls into question the validity or merits of the test case. In turn, a requirement for
which a test case cannot be constructed calls into question the validity of the requirement. A test case template can be used for different testing efforts
such as functional, development, performance, security, and regression testing.SAP provides documentation for Working with Test Case Templates.

2.2.7.2          Test Coverage

The ABAP Coverage Analyzer is a tool for collecting and analyzing the code coverage of test suites. You can use it to improve the quality
of ABAP Unit tests and integration tests and to help manage quality assurance testing.

The Coverage Analyzer tracks how much of your code is exercised in the course of testing or even in the course of normal production use. The Coverage Analyzer reports on code coverage at the procedure, branch, and statement levels. It also tracks the frequency with which code is executed and the occurrence of runtime errors.

Here are some typical tasks for which you can use the ABAP Coverage Analyzer:

• If you are a developer, you can use the Coverage Analyzer to Validate your ABAP Unit tests and integration tests.

You can determine how much of your code is exercised by your tests. You can efficiently find gaps in your testing that you can fill with new or modified tests. You can verify that your integration tests correspond in terms of code coverage to actual user scenarios.

• If you are a quality manager, you can use the Coverage Analyzer to do the following:
  • Monitor the code coverage achieved by testing in a QA system. You can use code coverage as a measure of the adequacy of the testing.
  • Analyze and report on trends in code coverage in a QA system
  • Aggregate code coverage results from remote systems

2.2.7.3          SAP Code Inspector / ABAP Test Cockpit

Bugs in your custom ABAP code can be quite expensive when they impact critical business processes, which is why quality assurance of custom ABAP code is receiving more and more attention in business. SAP also develops a great deal of ABAP code, and for us as well, highest quality is our primary goal. To reach this goal, SAP invested in the ABAP Test Cockpit (ATC), which has become SAP’s main internal quality assurance tool for ABAP.

SAP Netweaver offers an integrated code quality tool fully integrated in the IDEs like ABAP Development Workbench and ABAP in Eclipse. The code inspector or the successor ABAP Test Cockpit is integrated in the transport management and in the Solution Manager ChaRm process.

An overview of how to use the tool can be found at http://scn.sap.com/docs/DOC-31773

The Setup and administrative work at http://scn.sap.com/docs/DOC-32791

The definition of required RFC connection at http://help.sap.com/saphelp_snc700_ehp01/helpdata/en/9e/641866d4d74e44823c6c1a49626d9b/content.htm

It is recommended to use the static code checks with Code Inspector or ABAP Test Cockpit for the transports between development system and quality system and between the quality system and the productive system. Use the same check variant for all code checks. The identified issues with Priority 1 and 2 must be solved before the ABAP code should be transported. Projects can use more restrictive check variants e.g. performance optimizations for HANA.

Security checks are part of the product SAP Code Vulnerability Analyzer. This enhancement of ATC if offering the latest always up to date

• SQL Injections
• ABAP Code Injections
• OSCommandInjections
• Insufficientprotection
  against directory traversal attacks
• Backdoors
• Missingor incorrect authorization checks

HANA performance optimization checks are part of the standard ATC/SCI delivery. The following checks shall be added to your default check variant

• FUNCTIONAL_DB
• PERFORMANCE_DB

Some additional 3rd party SCI/ATC checks are also available in the market. Please refer to the following examples. The list is independant and not related to SAP. Entries will be added or deleted at any time.

• Dr ZedGe - Hard Coded Literal check

FAQ about ABAP Code Inspector or ABAP test Cockpit

Watch always for latest notes
2141188   – analysis of customer exits

2141202–  analysis of custom namespace

2.2.7.4          Runtime Check Monitor

The Runtime Check Monitor is a kernel based code quality check to evaluate critical ABAP code sequences not able to be detected with static checks of the SAP Code Inspector. The RTM checks support, in the release 7.40 SP5, the following two important checks. Additional checks will be shipped via support packages.

• SELECT... FOR ALL ENTRIES IN itab is empty during runtime
• SELECT_NO_ORDER: Binary access on an unsorted table

For lower releases, kernel must be at 740 PL 42, note 1931114 in combination with ABAP notes 1933710 and then SAP note 1931870. Start SRTCM Lite with report SRTCM_PRELIMINARY. When SRTCM lite is available in the intended system (production) then you can start it using report SRTCM_PRELIMINARY.

Necessary Authorizations: Same authorizations as for SQL Monitor ( S_ADMI_FCD=SQMA to activate the checks, S_ADMI_FCD=SQMD to display results)

To improve the quality of custom code it is strongly recommended to activate the check for a limited period of time in a productive environment or a test system with heavy test activities. It is not intended to keep the RTCM activated for a longer period of time. Reasons are overall performance loss and generated data volume.

2.3        Run & Monitoring

2.3.1          Operation Handbook

After release of code to a productive environment in most cases the documentation like specification and design will not fit to the existing implementation of code. And after some change requests to the custom code objects, there might exist some change request documents but these are often outdated as soon as you save the document in any version. Of course documentation is a must regarding the Custom Code Standard - a minimal documentation is necessary to get full SAP support from end-2-end.


In addition the inline code documentation we recommend to describe in the header of the code the

• Main influenced business process and  in best case, with the corresponding SAP transaction
• Add the corresponding starting entry point of this routine
• Maintain the corresponding executable programs in the Solution Manager SOLAR01 assigned to a business process structure

This is the minimum structured approach to make your custom code more transparent but will not help to improve elements like root-cause-analysis, incident handling etc.
In a 24/7 business a guaranteed IT hotline resources must be able to debug and understand the custom code without reading several hundred pages of documentation, in the worst case,
spread around several file shares with limited access. In case of emergency the time-to-reaction and
time-to-solve must be tremendously improved. This will work if you

• Build an in-code operation handbook

It is not advocated here to write several hundred lines of documentation, but every custom code needs at least a

•   One pager with best of debugging hints

This one pager must be accessible from everywhere or be part of the code itself. It should describe a raw data flow and be enriched with elements of SAP Checkpoint groups.

If changes are made to the code, then there is no guarantee that previous assumptions are satisfied. SAP ABAP checkpoints can be used to make sure that program correctness is maintained. Under checkpoints, we consider assertions, break point and log points.

• Use and implement features of SAP Checkpoint Groups

An interesting blog about the topic technical documentation can be found here.

SAP Checkpoint Groups:

SAP has introduced an alternative to application logging in transaction code SAAB. SAAB is used for creating, activating and displaying logs, breakpoints and
asserts. At the moment three new ABAP statements have been introduced to conditionally activate/write logs, breakpoints and asserts.

Assertion
With the help of assertion we can check this condition at runtime e.g. comparison of variable content following predefined business logic. It is a
statement which we can put in the program describing a specific condition.
ASSERT logexpr.

During program execution if statement is incorrect, execution can be stopped. Program execution can be stopped by raising ASSERTION_FAILED.

ASSERT ID checkpointgroup CONDITION logicalexpr.

If ID statement is used then assertion could be activated otherwise it is always active.

BREAK-POINT:Break
Point can be activated by writing following code in your program.

BREAK-POINT ID Checkpointgroup.

Activateable break point behaves same as always-active break point. In case of background processing activateable break points are simply ignored.

LOG-POINTS:Log
Point can be made activate-able by writing following code in your program.

LOG-POINT ID Checkpointgroup.

Logs can be used to identify or analyze the system behavior. Variable values can be logged so that the program developer can analyze those values.

You can add in your program statement LOG-POINT ID ZTRY.

2.3.2          Usage Tracking

Usage and Procedure Logging (UPL) is a new functionality available in any ABAP based system based on the core functionality of SAP Coverage Analyzer. It will be used to log all called and executed ABAP units (procedures) like programs, function modules down to classes, methods and subroutines. This new enhanced SAP Netweaver capability will have no performance impact on your system and will catch usage information of ABAP routines directly when they happen. UPL will give you 100% coverage of usage without estimations or evaluation of ABAP call stacks. This also includes the detection of dynamically called ABAP elements. UPL is the one and only technology to close the existing gaps in the SAP workload statistic. With the secured access to the UPL data, your usage information is protected against 3^rd party eyes. The full reporting capabilities with enriched information in BW of the Solution Manager will give you the flexibility to analyze ABAP usage for your custom code. With this usage tracking you can compare the estimated usage..

• Activate UPL via Solution Manager 7.1 in managed productive systems

Evaluation of test activities and test coverage can be done with two methods. The test usage tracking on a procedure level can be done with UPL. For a detailed test coverage analysis also the SAP Coverage Analyzer can be activated in test or Quality assurance systems. It is not recommended to activate Coverage Analyzer in a productive environment.

• Monitor test activities and test coverage in test systems in integration and acceptance tests

UPL will give you the usage of a technical custom code object. What is missing is the relation or the grouping to a development project, a business process or a comparable group of objects to rate the usage level in one or several systems. To create this relationship between a subset of custom code objects to a higher aggregation level the introduction of SAP Custom Code Lifecycle Management is recommended.

2.3.3          Monitor modification growth

In every customer implementation project there is always the need to modify existing SAP code objects. In a previous chapter there is already explained how to achieve this challenge to avoid modifications. But the most critical step in an established code governance process is the control. To improve the governance process and give developers a chance to be agile and flexible we recommend observing the growth of modifications.

• Track the creation of new modifications

Using the Custom Code Applications (tcode: CCAPPS) there will be a functionality available to display all existing modifications in an ALV list control. Sorting the result list by creation date, will give you the possibility to track new modifications and ask for reasons.

• Align new found modifications with your project documentation

Also SAP CCLM is offering you reporting capabilities in Solution Manager to track modifications at a central place.

2.3.4          Monitor Objects Cloning

As mentioned in a previous chapter one simple strategy to avoid modifications is the creation of a clone. This might look like a solution to avoid modifications, but at the same time the efforts to adapt the clones through missing SAP notes or new SAP innovations can be tremendous.

• Track the creation of new clones

Using the Custom Code Applications (tcode: CCAPPS) there will be a functionality available to display all existing and new cloned objects. Ensure in a development project the creation of clones either from SAP or from existing former custom code projects will be avoided. If it is necessary to clone a project documentation is necessary to maintain.

• Document relation of clones in the object header

SAP Custom Code Lifecycle management will offer you the possibility to track the clones automatically and will determine the relation to the original objects.

2.3.5          Custom Code Lifecycle Management (CCLM)

CCLM was developed especially for the purpose of accompanying your ABAP enhancements and new developments throughout their whole lifecycle. This cycle begins when you create an object (program, transaction, table, class, etc.), followed by it’s use in production systems and extends through to the retirement of the object in case of non-use or a reorientation of the development. This newly developed application is a part of the SAP Solution Manager 7.1. The heart of the application is a generic library model with which you can classify and manage custom code objects developed by your organization. Information about the use of these objects, their quality and version-history in the connected systems can also be collected if desired. You get an application that provides instant transparency for your custom code and records its use in a complex landscape without any additional manual effort. The generic central library is used by SAP as the central data source for all information on customer objects. You benefit particularly from the possibilities of individual assignment of responsibilities and contracts, consolidation of developments within an organization, and total control over new developments. It is possible to assign any object or list of objects to a contract or other predefined attributes.

The objective in introducing this application is to ensure that you can achieve the best possible adaptation of custom code to SAP code and therefore receive the best possible support. You can also benefit from cost savings in possible upgrades to higher SAP releases.

2.3.6          Enhancement Packs and Support Package Upgrade

Most SAP customers modify or enhance their SAP standard software in some way. Some customers only add reports that are specific to their business, while others have complete custom developed add-ons (developed internally or by a third party). These changes allow customers to tailor solutions to their individual requirements.

There are usually a large number of custom development objects in customer systems. This can lead to high operation costs for you because it can be difficult to identify any objects that your system does not use anymore. There can often be an unnecessarily high number of these obsolete objects.

What are the issues you face?

It can be challenging for you to keep track of all these changes to the standard configuration, and becomes increasingly difficult over time as the number of development objects increase. Some objects may become obsolete without anybody noticing. The person responsible for custom developments may be unavailable, for example.

If you want to upgrade to a higher SAP release, or to apply a support package, you must check and adapt every custom development object manually. You must then test each object to ensure that it does not cause any problems in the new context. This process represents a considerable amount of effort.

2.3.6.1         Custom Development Management Cockpit (CDMC)

The Custom Development Management Cockpit provides a set of features that support the handling and organization of ABAP custom development objects in SAP systems.

You can use SAP CDMC to address the following aspects:

• Analyze custom developments in your SAP system, and identify obsolete developments (Clearing Analysis)
• Identify the potential consequences an upgrade can have on custom developments (Upgrade / Change Impact Analysis)

Clearing Analysis

Clearing Analysis is the analysis of custom objects and modifications made to SAP standard objects in order to identify the used and unused custom objects and modifications.

You can delete custom objects and modifications not used in the system. This is referred to as the clearing process.

Upgrade / Change Impact Analysis

Upgrade / Change Impact Analysis identifies the impact that a support package or upgrade will have on any custom developments in the system.

2.3.6.2          Scope and Effort Analyzer

The Scope and Effort Analyzer addresses specifically the effort estimation for these issues and provides features for.

Hassle-Free Analysis

• Change impact analysis without physical EHP deployment
• Simple Guided procedure in local SAP Solution Manager
• No external transfer of customer code to protect Intellectual Property
• Tailored impact analysis for custom code and modifications
• Early estimation of project effort and required adjustment activities
• Overview on used and unused code based on reliable usage statistics
• Automatic generation of preliminary business blueprint (if required)
• Test Scope Optimization with significant reduced test scope and test effort
• Additional test plan for business processes including custom code & modifications
• Recommendations for missing test cases and process traces (BPCA TBOM)

Custom Code & Modifications

• Tailored impact analysis for custom code and modifications
• Early estimation of project effort and required adjustment activities
• Overview on used and unused code based on reliable usage statistics

Test Management

• Automatic generation of preliminary business blueprint (if required)
• Test Scope Optimization with significant reduced test scope and test effort
• Additional test plan for business processes including custom code & modifications
• Recommendations for missing test cases and process traces (BPCA TBOM)

2.3.7          Optimize

2.3.7.1          Performance

Performance can be considered from both the system and user perspective. While system administrators are interested in achieving the required system throughput and reasonable resource consumption with a given IT budget, the end users expect very good response times when interacting with software systems. Appropriate response times are, of course, related to the content of business processing.

The most important indicators for performance are response time and data throughput.

To guarantee a good performance the following areas must be investigated:

• Efficient database programming:
  Designing database accesses for optimal data retrieval; e.g. ensuring that database accesses are supported by an appropriate index.
• Linear resource consumption:
  Making optimal use of available system resources; for example, by efficientlydesigning database locks and SAP enqueues to allow scalable parallel processing.

• Efficient network communication: Streamlining communication between frontend and application layer or between two servers, as well as reducing the amount of data transferred betweenfrontend and application layer.
• Minimum response times: Keeping the average response time per user interaction step as low as possible.
• Sizing: Determining the hardware requirements of a solution by means of a sizing procedure for CPU consumption, memory consumption and disk space

SAP provides different tools for performance investigations. These tools can be used during the test phase to trace the performance behavior of the application. In addition to this proactive investigation it is possible to monitor a productive system with the SQL Monitor and the Usage and Procedure Logging to get more information about the behavior of the application during the productive usage.

For guidelines concerning performance refer to the following documents:

Global Performance Analysis:

http://help.sap.com/saphelp_nw70ehp1/helpdata/en/44/c84e0cc84b5478e10000000a422035/frameset.htm

In a world of high-performance in-memory databases a so called code push-down will transfer the application logic down to the database layer. Within SAP using the HANA technology this feature is called ABAP Managed Database Procedures. More details canbe found at http://scn.sap.com/docs/DOC-51612

2.3.7.2          Automated and manual tests

For predominantly ABAP-based programs, these checks can be automated to a large degree, using the Global Performance Analysis (transaction ST30).

The ST30works by invoking eCATTs scripts on a central test system. These eCATT scripts run the recorded scenarios, involving all the necessary components of a system
landscape. The ST30 retrieves the relevant performance figures generated from these runs by integrating the following tools:

Performance Analysis (transaction ST05, SQLM, SWLT)

Statistical Records (transactions STAD, ST03N, ST03G, etc.)

Code Inspector (transaction SCI)
ABAP Test Cockpit (ATC)

Distributed Statistical Records (DSRs)

The Global Performance Analysis thus can analyze performance in a complex SAP system landscape and collect performance figures across system boundaries. It keeps the performance data on a central system, enabling you to make repeated comparisons or statistical evaluations, e.g. regression tests.

2.3.8          Security

Minimize Custom Code Risks with SAP Code Vulnerability Analysis. Your valuable data assets are only as secure as the applications that host and access them. This integrated tool is scanning your ABAP custom code for security vulnerabilities. Details can be found in this SAP Insider article.

2.4        Early Retirement of Custom Code

Retirement of custom code objects shortly after the creation in a development project might sound strange. At this stage of a project there is an assumption all created code objects are necessary and in use. As soon as the development freeze was done the initial rating of objects shall be done. Classify the code objects in the following usage pattern

• Objects to be deleted

This group contains all objects with education purposes. Test programs. Clean up programs, etc.

These objects will not create and business value and create a high risk
if they are transported to a productive environment

• Objects to be deleted after temporarily availability

This group of objects contains migration or conversion programs to migrate legacy system data to the current data model. In most cases the use is
very limited but in most cases not restricted to special users with a security concept. It is recommended to delete these programs directly after a successful
use or ensure implement security compliance elements.

• Objects to be observed

The remaining rest of code objects have a defined business purpose. After a going live it will need some time until all elements are in productive
use. Code objects never reached the productive systems are either incomplete developed or have a wrong business value assignment. They are candidates for the decommissioning process.

Unused custom code has a big impact on your system, includes high risks and adds significantly to your costs, with:

• Maintenance and adjustment effort during change events. (E.g. System upgrade, new EhP, system merge)
• Maintenance effort and cost during operation  (E.g. bug fixing, due to dependency ofcoding -> coupling complexity of custom code with standard code)
• Security and destabilization risk of execution (no control) -> Missing authorization concepts
• Testing effort due to unknown usagebehavior -> Initial test plans may not cover business reality
• Data consistency risk when executing  unknown and old code.  (E.g. legacy migration reports, excel upload reports)
• Training effort to build and keep up to date development and support skills -> Handover of development responsibility and corresponding training activities
• Increasing the complexity and building adblocks on the way to a more simplified landscape or new technology landscape.  (e.g. Cloud, Hana).
• Creation of unnecessary documentation
• Inaccurate forecast and estimation of future development activities based on uncertainty or incorrectness
• Legal aspects to provide audit ability and certifications for processes (e.g. PCI DSS, Payment Card Industry Data Security Standard)

Reality of custom code impact: Experience from typical customer systems

Our recommendation is not to continue with a message like “Don’t touch a running system”, but instead follow the lean management of CC and
“Don’t invest into ‘Waste’”.

2.4.1          The Process of Decommissioning

The goal of decommissioning is to identify these custom code objects, which are possible and desirable to eliminate from the system as early as possible.

The four main characteristics of an object to be identified are:

1. Not used during a defined time period
2. Similar or even identical to an existing SAP object
3. Created long time ago but not active in any productive system
4. Obsolete because of existing standard functionality

For each characteristic the framework has to be defined:

For unused objects:

What does “not used” mean? – Ex.: Zero usage or used less than a certain threshold (accidental usage)

What is the right time period? – Ex.: At least 12 months to include closing activities (year-end closing)

For similar objects:

What is the degree of similarity for the objects? – Ex.: Only 100% clones will be marked for decommissioning.

For un-deployed objects:

What does a “long time ago” mean? – Ex.: Only objects which are created two or more years ago.

For obsolete objects:

Is the standard functionality already implemented?

A successful decommissioning strategy is divided into four main phases:

1. Analyze your custom code and get transparency
2. Identify custom code objects for decommissioning
3. Wait a specific timeframe, to ensure that the object is not executed
4. Decommission the objects

3   Additional Information

3.1         Details and examples

3.1.1          Detail Agile Development

Together with agile development the structure of development teams should be adjusted as well. A proven concept is Scrum.

Scrum is an iterative, incremental framework for projects and product or application development. It structures development in cycles of work called Sprints. These iterations are no more than one month each, and take place one after the other without pause. The Sprints are timeboxed – they end on a specific date whether the work has been completed or not, and are never extended.

At the beginning of each Sprint, a cross-functional team selects items (customer requirements) from a prioritized list. The team commits to complete the items by the end of the Sprint. During the Sprint, the chosen items do not change. Every day the team gathers briefly to inspect its progress, and adjust the next steps needed to complete the work remaining.

At the end of the Sprint, the team reviews the Sprint with stakeholders, and demonstrates what it has built. People obtain feedback that can be incorporated in the next Sprint. Scrum emphasizes working product at the end of the Sprint that is really “done”; in the case of software, this means code that is integrated, fully tested and potentially shippable.

More information can be found here http://ase-education.de

3.1.2          Example: ABAP Doc in ABAP in Eclipse

In the following example, the ABAP Doc comments are added one line before the corresponding declarative statements.

If you display the ABAP Element Info view in the ABAP perspective and select the method name in the source code editor, the corresponding ABAP Doc comment is displayed:

Figure: In the ABAP Element Info view, the ABAP Doc comment of the method_with_variable method is displayed

3.1.3          Example: Template for LOOP AT statement

A common coding pattern in ABAP is to iterate over the rows of an internal table using a loop that reads the internal table in a loop, where each row is assigned to a field symbol. By using a template for this pattern, you can avoid typing in the complete code for the loop. Invoking code assist after typing the word loop will present you with a list of possible loop templates. Selecting this template will insert the code into the editor and position your cursor so that
you can edit the details.

Figure: Inserted code in the ABAP Source Editor when using the loopAtAssign template

3.1.4          Example: First Steps with ABAP Unit

Implementation

Tests are defined and implemented as local classes inside a main program.

1. Define a local class with the extension “FOR TESTING” and no constructor with parameters.
2. Therein define methods with no parameters and the extension “FOR TESTING”.
3. Implement test code inside this method and verify the expected state using assert methods from the utility class “CL_AUNIT_ASSERT”.

In releases with SAP_BASIS >= 7.02 CL_ABAP_UNIT_ASSERT offers more methods.

Example:

----------------------------------
*       CLASS ltc_Wallet DEFINITION
------------------------------------
*
-----------------------------------
CLASS LTC_WALLET DEFINITION FOR TESTING. „#AU Risk_Level Harmless    PRIVATE SECTION.      METHODS CHECK_LIQUIDITY FOR TESTING.  ENDCLASS.                 „ltc_Wallet DEFINITION
----------------------------------
*       CLASS
ltc_Wallet IMPLEMENTATION
------------------------------------
*
------------------------------------  CLASS LTC_WALLET IMPLEMENTATION.    METHOD CHECK_LIQUIDITY.      DATA:        MY_WALLET TYPE REF TO CL_WALLET,        LIQUIDITY TYPE I.     CREATE OBJECT MY_WALLET.     LIQUIDITY = MY_WALLET->GET_LIQUIDITY( ).     CL_AUNIT_ASSERT=>ASSERT_EQUALS(          ACT = LIQUIDITY          EXP = 0          MSG = ‘New wallet assumed empty’ ).      MY_WALLET->PUT_IN( EUROS = 12 ).      CL_AUNIT_ASSERT=>ASSERT_EQUALS(         ACT = MY_WALLET->LIQUIDITY         EXP = 12         MSG = ‘As many euros as put in before’ ).    ENDMETHOD.                „check_Liquidity
ENDCLASS.                   „ltc_Wallet IMPLEMENTATION

3.2         Information Sources

This section provides the collection of information sources with the WWW addresses for the print version of the document.

SAP Guideline for Best-Build Application:

http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/c0f0373e-a915-2e10-6e88-d4de0c725ab3?overridelayout=true

Technical Liability / Debt:

http://en.wikipedia.org/wiki/Technical_debt

Product and Innovation finder:

http://service.sap.com/public/findinnovation

https://apps.support.sap.com/innovation-discovery/

https://service.sap.com/bfp

https://service.sap.com/aie

Agile Software Engineering:

http://ase-education.de

ABAP in Eclipse:

http://scn.sap.com/community/abap/eclipse

http://scn.sap.com/community/abap/eclipse/blog/2014/11/03/abap-test-cockpit-for-developers-in-eclipse

https://www.youtube.com/watch?feature=player_embedded&v=_SmSJ8Tkl8w

Open SQL

http://help.sap.com/abapdocu_740/en/abenopensql.htm

SAP HANA End to End Development Guide

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

ABAP Managed Database Procedures

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

ABAP for SAP HANA Reference Scenario - Video Tutorials

http://help.sap.com/abapdocu_740/en/abenamdp.htm

Code Data Services

New Data Modeling Features in SAP NW ABAP 7.4 SP5

http://help.sap.com/abapdocu_740/en/abencds.htm

Two Value Releases:

http://service.sap.com/~sapidb/012002523100009359122013E

SAP Decision Service Management:

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

SAP Enhancement Framework / SAP Switch Framework

http://scn.sap.com/people/thomas.weiss/blog/2010/04/14/what-is-new-in-abap-language-abap-workbench-and-enhancement-framework-with-sap-netweaver-70-ehp2

https://www.sdn.sap.com/irj/sdn/weblogs?blog=/pub/wlg/8021

https://www.sdn.sap.com/irj/sdn/weblogs?blog=/pub/wlg/8310

https://www.sdn.sap.com/irj/sdn/weblogs?blog=/pub/wlg/8216

UI strategy

https://experience.sap.com/post/show/111

SAP Screen Personas

http://sapscreenpersonas.com

ABAP Enhancements:

http://help.sap.com/saphelp_nw04s/helpdata/en/fb/e3d8403e37762ae10000000a155106/content.htm

http://help.sap.com/saphelp_nw04s/helpdata/en/09/9bf240a5668d38e10000000a155106/content.htm

Table Indexes:

http://help.sap.com/saphelp_sm70ehp1_sp23/helpdata/en/cf/21eb20446011d189700000e8322d00/content.htm

http://scn.sap.com/thread/3355684

Innovation Control Center:

http://www.sap.com/services-support/support/plans/info/innovation-control-center/index.html

Modification free adaptions of SAP:

http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/f02f5459-7c76-2b10-54b4-f95e5f75476b?QuickLink=index&overridelayout=true&33779917805697

ABAP Development Guideline:

http://help.sap.com/abapdocu_740/en/index.htm?file=ABENABAP_PGL.htm

Modification Assistant:

http://help.sap.com/saphelp_nw04s/helpdata/en/60/d6ba5aceda11d1953a0000e82de14a/frameset.htm

BAdIs and Filter BAdIs:

http://help.sap.com/saphelp_nw04s/helpdata/en/8f/f2e540f8648431e10000000a1550b0/frameset.htm

Code Inspections:

http://en.wikipedia.org/wiki/Fagan_inspection

Test Case Template:

http://help.sap.com/erp_hcm_ias_2012_01/helpdata/EN/10/6abff28ad84562be39e6c442a56669/frameset.htm

Code Coverage:

http://help.sap.com/saphelp_nw70ehp2/helpdata/en/4a/828b7a3a90387fe10000000a421947/content.htm

http://help.sap.com/saphelp_nw70ehp2/helpdata/en/5c/8c1f1092834315a733662c54e3b5eb/content.htm

http://help.sap.com/saphelp_nw70ehp2/helpdata/en/83/0c8c04837e46c3bab1d1d94fef0d13/content.htm

http://help.sap.com/saphelp_nw70ehp2/helpdata/en/49/175e98a2ec14d2e10000000a42189b/content.htm

http://help.sap.com/saphelp_nw70ehp2/helpdata/en/2e/48a3df3d634ed9a4e13eca40b0e359/content.htm

http://help.sap.com/saphelp_nw70ehp2/helpdata/en/08/cdf259e2734222806192d95406eaf4/content.htm

http://help.sap.com/saphelp_nw70ehp2/helpdata/en/08/adce20700c4917887829543d4d3c86/content.htm

ABAP Unit Test:

http://help.sap.com/saphelp_nw70ehp2/helpdata/en/48/b39a5d17f84455e10000000a421945/content.htm

Integration Test:

http://help.sap.com/saphelp_nw70ehp2/helpdata/en/35/28ec72e8aa5570e10000009b38f983/content.htm

SAP Checkpoint Groups:

http://help.sap.com/saphelp_erp60_sp/helpdata/en/9b/b1b64104e52f31e10000000a155106/content.htm?frameset=/en/22/a6b241a1b33131e10000000a155106/frameset.htm

http://help.sap.com/abapdocu_702/en/abaplog-point.htm

http://help.sap.com/abapdocu_702/en/abapbreak-point.htm

http://help.sap.com/abapdocu_702/en/abapassert.htm

ABAP Test Cockpit / SAP Code Inspector:

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

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

http://help.sap.com/saphelp_snc700_ehp01/helpdata/en/9e/641866d4d74e44823c6c1a49626d9b/content.htm

SCI and ATC Partner products

http://scn.sap.com/community/abap/testing-and-troubleshooting/blog/2014/09/29/business-hard-coding-finder--a-free-tool-to-improve-your-custom-abap-code-and-save-money-during-your-next-rollouts#comment-540286

Global Performance Analysis:

http://help.sap.com/saphelp_nw70ehp1/helpdata/en/44/c84e0cc84b5478e10000000a422035/frameset.htm

DSAG Best Practice Guideline for ABAP Development postulates secure programming:

http://scn.sap.com/community/security/blog/2013/04/03/dsag-best-practice-guideline-for-abap-development-postulates-secure-programming

Ongoing discussion:

http://scn.sap.com/community/abap/blog/2013/08/06/a-word-document-explaining-abap-instructions-are-you-serious

Security Analysis:

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

Other Guidelines:

Secure Configuration of SAP NetWeaver Application Server Using ABAP

Fiori Design Guidelines

DSAG Best Practice Guideline for ABAP Development now available in English

ABAP Development Standards concerning Security

SQL Guidelines for HANA and MSSQL

Performance Guidelines for ABAP Development on the SAP HANA Database

SAP Press: Enhancing the quality of ABAP Development

SAP Press: ABAP Development Guidelines