code management implementation in sync with sap custom...

Generated by Jive on 2014-07-13+02:001

Development Guidelines for GreenfieldImplementation in sync with SAP CustomCode Management

Instructions for Managers, Architects and Developers

• 1. Introduction on page 2

• 1.1 Validity on page 3• 1.2 Scope Document on page 3• 1.3 Related Documents on page 4

• 2 Custom Code Lifecycle on page 4• 2.1 Plan on page 4

• 2.1.1 Requirement on page 4• 2.1.2 Business value on page 6• 2.1.3 Make or Buy on page 6• 2.1.4 Custom Code Usage Forecast on page 7• 2.1.5 Development Process on page 8

• 2.1.5.1 Waterfall methodology on page 9• 2.1.5.2 Agile Custom Code Development Process on page 9

• 2.1.6 Minimal Documentation on page 11• 2.1.6.1 Recommendation ABAP Doc on page 12

• Editing ABAP Doc Comments on page 12• 2.2 Build on page 12

• 2.2.1 Basic Development Environment on page 12• 2.2.1.1 Development Workbench / ABAP in Eclipse on page 13• 2.2.1.2 Development Landscape on page 13• 2.2.1.3 Releases & Maintenance on page 14

• 2.2.2 ABAP Development on page 15• 2.2.2.1 Basic ABAP Development Rules on page 15• 2.2.2.2 Custom Code Management – Rules on page 15

• • ABAP OO vs. function oriented programming on page 15• 2.2.3 UI Implementation on page 19• 2.2.4 Package Concept on page 19

• • • Naming concept of packages shall on page 20• 2.2.5 Enhancements on page 20

• 2.2.5.1 Enhancement of SAP on page 21• BADI’s: BADI - Business Add Ins on page 21• User exit: on page 22• Customer exit: on page 22• ABAP Enhancements on page 22• Implicit Enhancement Option on page 22• Explicit Enhancement Option on page 23

• 2.2.5.2 Modification of SAP on page 26• 2.2.5.3 Custom Code Implementation Types on page 29

• Custom code without SAP relations on page 29• Custom code with SAP relations on page 29• Enhancing existing custom code branches on page 29

• 2.2.5.4 Optional tools to support developers work on page 30• Easy access to the guidelines on page 30

Development Guidelines for Greenfield Implementation in sync with SAP Custom Code Management


• ABAP Code Templates with ABAP in Eclipse on page 30• 2.2.6 Quality on page 31• 2.2.7 Test on page 32

• 2.2.7.1 Building a Test Case on page 33• 2.2.7.2 Test Coverage on page 34• 2.2.7.3 SAP Code Inspector / ABAP Test Cockpit on page 34• 2.2.7.4 Runtime Check Monitor on page 35

• 2.3 Run & Monitoring on page 36• 2.3.1 Operation Handbook on page 36• 2.3.2 Usage Tracking on page 38• 2.3.3 Monitor modification growth on page 38• 2.3.4 Monitor Objects Cloning on page 39• 2.3.5 Custom Code Lifecycle Management (CCLM) on page 40• 2.3.6 Enhancement Packs and Support Package Upgrade on page 40

• 2.3.6.1 Custom Development Management Cockpit (CDMC) on page 41• 2.3.6.2 Scope and Effort Analyzer on page 41

• Hassle-Free Analysis on page 41• 2.3.7 Optimize on page 42

• 2.3.7.1 Performance on page 42• 2.3.7.2 Automated and manual tests on page 43

• 2.3.8 Security on page 43• 2.4 Early Retirement of Custom Code on page 44

• 2.4.1 The Process of Decommissioning on page 45• 3 Additional Information on page 47

• 3.1 Details and examples on page 47• 3.1.1 Detail Agile Development on page 47• 3.1.2 Example: ABAP Doc in ABAP in Eclipse on page 48• 3.1.3 Example: Template for LOOP AT statement on page 49• 3.1.4 Example: First Steps with ABAP Unit on page 50

• • Implementation on page 50• 3.2 Information Sources on page 50

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, isnot of concern. Currently we use the term “technical liability” or “technical debt” to describethese internal qualities. The idea behind this term is to illustrate that not focusing on the internalqualities 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

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



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.

http://scn.sap.com/servlet/JiveServlet/showImage/102-56285-8-487305/innovate.png



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

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

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

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

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



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.

Helpful

to achieving the objective

Harmful

to achieving the objective

Internal origin Strengths Weaknesses

External Origin Opportunities Threats

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

http://ase-education.de/



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.

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…

2.2.1.2 Development Landscape

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

The dual landscape with a pre-production system:

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



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.

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



2.2.2 ABAP Development

2.2.2.1 Basic ABAP Development Rules

Creating good custom code shall follow the official ABAP 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 doesnot fit to the former function oriented programming style. As a consequence, most of thefunctionality should reside in global ABAP classes and their methods. Care should be taken duringclass modeling and interface design to avoid objects that are too granular & that lead to theinstantiation of hundreds of small instances at run time, without providing any real benefit. Youdon’t always need an object; pure data is sufficient in many cases. In short: whenever objectorientation collides considerably with performance, performance has the higher priority. Also byimplementing 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.

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



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 form custom code nor from SAP inyour own new programs. It might be an easy way to save effort by including foreign includes inyour 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 unusedsubroutines/methods will be accessible and ABAP Code Inspector will validate the correctnessof code by unpacking these Includes and assign them to the main program. Further details inchapter 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 conditionevaluates 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 flexible business 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 DecisionService 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.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

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


http://sapscreenpersonas.com/



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

http://scn.sap.com/servlet/JiveServlet/showImage/102-56285-8-487390/package.png



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 Custom Code development.

The documentation with examples can be found with this Link.

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.

https://portal.wdf.sap.corp/irj/portal?NavigationTarget=navext%28ROLES%3a%2f%2fportal_content%2fcp%2froles%2fcto%2forganization%2ftip_core%7CWCMS%3a%2f%2fInfocenters%2fWS+Office+of+the+CTO%2fOrganization%2fCore%2f~%2fABAP%2fSwitch+and+Enhancement+Framework%29



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 standardbusiness applications without having to modify the original applications. SAP creates customerexits for specific programs, screens, and menus within standard R/3 applications. These exits donot contain any functionality. Instead, the customer exits act as hooks. You can hang your ownadd-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

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

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



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.

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

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 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 “SAPInnovation 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

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

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

https://service.sap.com/findinnovation

https://service.sap.com/bfp



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 SAPEnterprise Support. SAP provides up to five person days per calendar year of remote assistanceand enablement for each customer to help evaluate the innovation capabilities of the latest SAPenhancement 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 andEnhancement Framework”. The How-to guide “Modification free adaptions of SAP” will give you astep- 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

https://service.sap.com/aie

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



https://portal.wdf.sap.corp/irj/portal?NavigationTarget=navurl://81b4a2fa424ac316962256b838619dfd

https://portal.wdf.sap.corp/irj/portal?NavigationTarget=navurl://81b4a2fa424ac316962256b838619dfd

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



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 keyfeatures are multi- use BAdI and filter conditions. With

these features you are able to transfer the business logic down to an implementation and thebusiness decision flow can be controlled by filter

conditions. Of course BAdI implementations can be integrated into the switch concept to ensurebusiness 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 andbusiness 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 globally. The system configuration for modifications can be verified with report

RSPFPAR. The parameter entry for

eu/controlled_modificationmust have a value different to 0.

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



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



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 theheader 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, becauseversioning 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• Decomission unused custom code

2.2.5.4 Optional tools to support developers work

Easy access to the guidelines

Enforcing standards such as those outlined in the Development Guidelines will be more easilyachieved and adhered to where developers have access to these guidelines and where a highdegree 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-consumecommunication channel. As emails will not be helpful and Wiki pages are not bound to thedeveloper’s workbench a simple but effective method is to bundle the guidelines with thedeveloper’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 CodeInspector or the SAP ABAP Test Cockpit to evaluate a “minimal” set of checks against any kind ofcode imported to the customer system (In case the implementation will be don by 3th Party). TheQ-gate for this check must ensure that NO custom code can be transported to the next system aslong 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 requiredchanges 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 therequirement is fulfilled from design of the architecture to the implementation. These code reviewsare time consuming and should be done for a minimum set of 5% - 10% of the code. Criteriafor 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 ofdownstream efforts in subsequent processes.

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

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



2.2.7 Test

Testing is a substantial part of the program development process. Tests verify the intendedprogram behavior. In that sense also debugging or simple text traces are tests. Neverthelessthese two methods require human judgment. This soon limits the test possibilities when comingto more complex test scenarios: debug information must be checked step by step and text outputvery 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 thementioned problems with developer tests. ABAP Unit is the new unit test tool for ABAP. Testscan be conveniently grouped into test tasks. Test results are condensed and become instantlyevident. 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 businessprocesses, which is why quality assurance of custom ABAP code is receiving more and moreattention in business. SAP also develops a great deal of ABAP code, and for us as well, highestquality is our primary goal. To reach this goal, SAP invested in the ABAP Test Cockpit (ATC), whichhas become SAP’s main internal quality assurance tool for ABAP.

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

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

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

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

http://help.sap.com/saphelp_nw70ehp2/helpdata/en/5c/8c1f1092834315a733662c54e3b5eb/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



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.

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.

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


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




2.3 Run & Monitoring

2.3.1 Operation Handbook

After release of code to a productive environment in most cases the documentation likespecification and design will not fit to the existing implementation of code. And after somechange requests to the custom code objects, there might exist some change request documentsbut these are often outdated as soon as you save the document in any version. Of coursedocumentation is a must regarding the Custom Code Standard - a minimal documentation isnecessary 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 willnot help to improve elements like root-cause-analysis, incident handling etc.�In a 24/7 business aguaranteed IT hotline resources must be able to debug and understand the custom code withoutreading several hundred pages of documentation, in the worst case,�spread around several fileshares 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 ofvariable 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.

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

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



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 3rd 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 enhancementsand new developments throughout their whole lifecycle. This cycle begins when you createan object (program, transaction, table, class, etc.), followed by it’s use in production systemsand extends through to the retirement of the object in case of non-use or a reorientation ofthe 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 managecustom 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. Youget an application that provides instant transparency for your custom code and records its usein a complex landscape without any additional manual effort. The generic central library is usedby SAP as the central data source for all information on customer objects. You benefit particularlyfrom the possibilities of individual assignment of responsibilities and contracts, consolidation ofdevelopments within an organization, and total control over new developments. It is possible toassign 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 aresupported by an appropriate index.

• Linear resource consumption:Making optimal use of available system resources; for example, by efficientlydesigning databaselocks and SAP enqueues to allow scalable parallel processing.



• Efficient network communication: Streamlining communication between frontend and applicationlayer or between two servers, as well as reducing the amount of data transferred betweenfrontendand application layer.

• Minimum response times: Keeping the average response time per user interaction step as low aspossible.

• Sizing: Determining the hardware requirements of a solution by means of a sizing procedure for CPUconsumption, 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

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 ST30 works 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, systemmerge)

• 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”, butinstead 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 period2. Similar or even identical to an existing SAP object3. Created long time ago but not active in any productive system4. 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 (accidentalusage)What is the right time period? – Ex.: At least 12 months to include closing activities (year-endclosing)

For similar objects:

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

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 transparency2. Identify custom code objects for decommissioning3. Wait a specific timeframe, to ensure that the object is not executed4. 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 applicationdevelopment. It structures development in cycles of work called Sprints. These iterations are nomore than one month each, and take place one after the other without pause. The Sprints aretimeboxed – they end on a specific date whether the work has been completed or not, and arenever 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 ithas built. People obtain feedback that can be incorporated in the next Sprint. Scrum emphasizesworking product at the end of the Sprint that is really “done”; in the case of software, this meanscode 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:





Agile Software Engineering:

http://ase-education.de

ABAP in Eclipse:


Two Value Releases:


SAP Decision Service Management:


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




UI strategy


SAP Screen Personas

http://sapscreenpersonas.com

ABAP Enhancements:





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









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

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





http://scn.sap.com/

http://sapscreenpersonas.com/





Table Indexes:



Innovation Control Center:


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:


Modification Assistant:


BAdIs and Filter BAdIs:


Code Inspections:


Test Case Template:


Code Coverage:



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

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




ABAP Unit Test:


Integration Test:


SAP Checkpoint Groups:













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_erp60_sp/helpdata/en/9b/b1b64104e52f31e10000000a155106/content.htm?

frameset=/en/22/a6b241a1b33131e10000000a155106/frameset.htm




ABAP Test Cockpit / SAP Code Inspector:




Global Performance Analysis:


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:


SAP Press: Enhancing the quality of ABAP Development

SAP Press: ABAP Development Guidelines










http://scn.sap.com/community/security/blog/2013/04/03/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


