Development Guidelines Custom Code Management

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 BADIs: 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 toolsprovided by SAP. The document contains the elementary and most important concepts for the developmentof new custom code in SAP environments. The basics are necessary to implement a global, distributed andsecure customer add-on solution. It will not focus on single ABAP programming templates but more on theimpact of these on a custom built solution. The main difference is the level of complexity. Customers using SAPare not software producers and the goal of customers IT departments is to fulfill the business requirements in afast and efficient way and not to create and sell software. A main goal is to ensure the operation of the addedsoftware 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 processis the first juncture when customers become aware of quality. This can be considered as the external qualityand 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 tochange.

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 theCustom Code Lifecycle.

1.1 ValidityThe guideline shall be valid for all internal development projects and all external service providers developingcustom 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 DocumentThis guideline considers the different phases of a complete Custom Code Lifecycle. Normally developmentguidelines 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 willbe developed if there is a kind of business case available. But it might be clear that every predefined businesscase 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 theCustom 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 forABAP Development integrated to SAP standard

software.

2 Custom Code Lifecycle

2.1 Plan

2.1.1 Requirement



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

Use a Software Requirements Specification template to:

Assist users in determining if the software meets their requirements. Reduce development effort. It forces stakeholders to consider all requirements before design begins,

reducing redesign, recoding, and retesting. Provide a basis for costings 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 notavailable in a standard software product with the goal to create a competitive advantage compared to yourbiggest 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 anasset the return on investment must be realized in a short period of time. Every unused custom code is a wasteof time, money and resources. Standard software offers an incredible number of features, not needed for allbusinesses sceanrios, but which, in the right environment, create added-value.



2.1.2 Business value

In addition to the classical development processes a new concept will be introduced. The new concept isDesign Thinking. This concept puts the business value and the integration of end users into the developmentprocess. Design thinking is a methodology for practical, creative resolution of requirements and gaps that looksfor an improved future result. In this regard it is a form of solution-based, or solution-focused thinking that startswith the goal or what is meant to be achieved instead of starting with a certain problem. Then, by focusing onthe 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 todefine 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 thepath 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 functionalityfrom SAP is not so easy. SAP provides several tools to find Products & Innovations and the Innovation



Discovery tool to simplify your search for new functions. For those cases where SAP or other SoftwareCompanies do not provide a product it is very helpful to use a SWOT analysis to make a decision. This wouldallow 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.

Helpfulto achieving the objective

Harmfulto 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 pieceof software. In the best case this gap can be closed with configuration of the standard software. Oftenthe easiest way is starting a custom development requirement based on a solid business case includingefforts and benefits. Most often neglected is benefit case in terms of future usage and KPIs to validate theinvestments. Forecast represents the expected usage in a productive phase of this custom code and willhave a positive impact on aspects like quality and business criticality. Typically a usage analysis delivers thehigh level execution of the software. But it is critical to know if the implemented custom code fits the specifiedrequirement.

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 counterpartof the usage logging available in the custom code management methodology. Move forward from a classicBoolean 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 thiscustom 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 withthousands of functions are implemented for customers on top of the standard software. Often the justificationis articulated as follows: We are preparing maximum flexibility to complete potential gaps in the initial businessrequirement.

2.1.5 Development Process

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



2.1.5.1 Waterfall methodology

Waterfall methods represent the most structured implementation method, stepping through different phaseslike requirements, analysis, design, coding/configuration, and testing in a strict, pre-planned sequence. Eachphase has predefined quality gates and checkpoint to be controlled. Each phase can be huge from contentand long from time perspective. It is a hand-in-hand process. Triple constraints (Time, scope, costs) anddependencies are managed across phases. Progress and success is generally measured in terms of clearlydefined 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. Ina very detailed precompiled project setup anyside effects can influence the main goal. In some bad exampled only at the end in the final assembly phaseyou 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 oftenhard 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 Agiles 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 Simplicitythe 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 developmentinside SAP allow us to recommend agile development.

For the development process it is important to define a clear ownership for the different rolls in thedevelopment 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 onmaintenance and user documentation.

Everything starts with the well-described business requirements and a description of the business value ofthe 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, asless change requests will be started after code release.

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

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

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



A new aspect is the documentation for the maintenance. This documentation should be done in the codingitself. 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 tocreate and most sustainable form of a documentation. In the best case this documentation is integrated in thecode.

2.1.6.1 Recommendation ABAP Doc

ABAP Doc allows you to document declarations in ABAP programs, based on ABAP Doc comments. This isthe way the important information about the application should be documented. After an incident the first look isalways 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 thesource code editor, they can be placed in an empty line directly in front of a declarative statement like datadeclarations, 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 functiongroups to describe functionality in the code element. In addition, you can generate ABAP Doc by importing theexisting descriptions of global classes and interfaces including their attributes, methods, parameters, and soon.

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 goodstructure of the development teams, which development environment should be used and how does thesystem 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 integrateddevelopment workbench and the new ABAP in Eclipse Workbench. ABAP in eclipse is available for SAPSystems NW 7.31/7.03.

The integrated development workbench (Transaction SE80) provides all necessary features for a classicalABAP development project. For new product enhancement like HANA the switch to the ABAP in Eclipsedevelopment workbench is necessary. Eclipse is a development workbench used for several developmentlanguages like Java, C#. These development languages are part of the standard education in universities andnew 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:



2.2.1.3 Releases & Maintenance

Talking with many of our customers globally, there is enormous pressure on being able to implement newbusiness models. Innovation and speed are required to compete with cloud providers like Amazon.com, forexample, 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 ofrequired business innovations. This is often due to the extent of modifications, but may also be caused by alack 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. SAPsolutions 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. Inthis way, SAP provides the capabilities to run

SAP solutions without interruption. Many SAP MaxAttention customers run their SAP solutions as a singleglobal 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 beintroduced.



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 alldevelopments. These guidelines are valid for

every development in ABAP but in a customer environment with a restricted scope, some rules shall beadapted 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. Youdont 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.Functionmodules are not class methods, etc.

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



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

Avoid over engineering Keep it simple Dont 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. Dont 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 andmaintenance point of view do not use such techniques.

Avoid dynamic call of subroutines (perform xy in 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.0it is strictly recommended to avoid clones. The

original program might have implemented enhancements spots. In the cloning process all theseimplementations 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 SAPstandard 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 thecustom 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

Factorypattern

Dont use comments like INSERT START INSERT END, to make changes visible Dont 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 followthe 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 willlead to additional efforts in upgrade or support package update. To minimize these efforts we recommend

Use only released APIs like BAPIs Dont 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 fromother or older projects. Using such elements willautomatically 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 Dont 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 preinstalledframeworks. This might be a benefit to speed up the time to build a new custom code but will lead to massiveimpacts 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 userexperience. 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 programmingwith SAP Screen Personas.

2.2.4 Package Concept



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

Use a package hierarchy concept For every business functionality use a dedicated enclosed package Interfaces to external systems shall be managed in a dedicated interface package separated by

interface partners (e.g. by systems) Global functionality in global re-use packages

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

Naming concept of packages shall

Never represent project structures Never represent organizational company structures like locations Never represent HR structures Never represent ABAP code objects collectors like reports, function

modules,

2.2.5 Enhancements



At the beginning, we repeat the basic reasons why enhancements are so much better than modifications andwhy they save you a lot of work in an upgrade. The Enhancement- and Switch Framework is almost as flexibleas implementing modifications when it is necessary to change or add something to SAP standard objects. Thismeans, 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, whilemodifications are part of the object they modify. So with enhancements, you have most of the advantages ofmodifications, 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 inyour 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 theseconcepts will be mentioned.

BADIs: BADI - Business Add Ins

are enhancements to the standard version of the SAP code. They can be inserted into the SAP system toaccommodate user requirements that are too specific to be included in the standard delivery. Customerscan find the possible enhancements (BADIs) in their SAP system in the Implementation Guide (IMG) and inthe 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 thevalidity of call interfaces.

Two different views are available:

In the definition view, an application programmer defines exit points in a source that allow specificindustry sectors, partners, and customers toattach 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 astandard solution if one is available.



User exit:

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

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

Customer exit:

The R/3 enhancement concept allows you to add your own functionality to SAPs 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, usingsource code plug-ins.

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

Implicit Enhancement Option

At common enhancement places, implicit Enhancement options are available.

Examples:

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



Explicit Enhancement Option

Predefined enhancement options can be defined in source code. They are additionally stored inside Enhancement Spots.

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

Switch Framework



The Switch Framework (available as of ABAP 7.0) is made to control the visibility of development objects atruntime. If a switchable development object is notswitched on it is not part of the ABAP load and therefore behaves as if it does not exist at all though as atransport object it still exists. The Enhancementand the Switch Framework are closely integrated which means: All enhancements of the EnhancementFramework (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 includesspecial 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 thanone 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 withthe append structure.

When a table or structure is activated, all the append structures of the table are searched and the fields ofthese append structures are added to the table or structure. Foreign keys and search help attachments addedusing the append structure are also added to the table. If an append structure is created or changed, the tableor 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 protectedagainst overwriting during an upgrade. The fields in the append structure should also reside in the customernamespace, that is the field names should begin with ZZ or YY. This prevents name conflicts with fieldsinserted in the table by SAP.

If you create an append structure for a table or structure, only those enhancements are allowed that areconsistent 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 definitionsand search help attachments contained in the append structures are added to the new standard tables atactivation.

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

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



2.2.5.2 Modification of SAP

A modification is a change of existing code objects or foreign code objects that are no part of the currentSAP software stack. Normally a modification can be seen as a change of an SAP object. Exceptions aremanual activities of notes or implementations of former user exits and also cross transports of coding fromexternal systems. Having modifications within an SAP system is not a big issue as long as the complexity anddependency is low and the business requirement is well defined. Unfortunately, many modifications are madebecause the hurdle to do it is extremely low. Strict governance processes to avoid modifications will fail in mostcases because developers will try to solve the requirements with other ideas. Prominent here is the idea ofcloning SAP code, which is more critical from a maintenance perspective. This leads to the following rules andguidance

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 rejectthis 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 SAPexperts. 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 formodifications. 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 anearly stage including sneak previews of upcoming releases.

SAP Find Innovation (https://service.sap.com/findinnovation). This information center provides customers withdetails 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 functionalityincluded in SAP enhancement packages for SAP ERP 6.0. SAP Business Function Predictor uses customerproductive system usage analysis to prepare a report that includes a tailored list of new business functions thatenhance transactions, identifying the relevance of each business function for the customer and how often that



function is used by other SAP customers. The service also offers direct access to all relevant information foreach predicted business function, including overview presentations, release notes and documentation, andtechnical usage mappings.

Proactive and also reactive validation is possible through the SAP Accelerated innovationEnablement 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 toavoid SAP source code modifications whenever possible by using SAP standard functionality, or by takingadvantage of the SAP Enhancement Framework.

All the mentioned services have a slightly different focus depending on the progress of the implementationstatus 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 minimalimpact. 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 EnhancementsOver 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 plannedmodifications should be done in separated packages. If you adhere to the following guide you will have somereal 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 originalpackage

Define the technical behavior of the enhancement spot in a global re-use package and describe wellthe purpose of this enhancement definition

Implement one or several spots in one single package and ensure this package identifiesencapsulated 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 strictlyseparated. The delegation of the code to an dedicated ABAP object will ensure the continuous usage of CodeInspector for your customer implementations. It may sound like too much effort compared to the classic ways



of modifications, but the benefits will be seen later on. Implementing Enhancement spots can be seen as code-plugins, similar to includes at a given position with direct relation to surrounding SAP variables and logic. Assoon as you have the business requirement to support different organizational units, countries, locations youshould refrain from spending too much time implementing IF-ELSE or CASE statements. Instead it is better todefine a customer specific Business Add In (BAdI) and use the filter features of implementations.

Define customer Filter BAdIs

Details about BadIs 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 themaintenance 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 tomodify 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. Somecustomers deactivated the globally. The system configuration for modifications can be verified with reportRSPFPAR. The parameter entry for

eu/controlled_modificationmust have a value different to 0.



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 tocomplete very special business requirements never be part of a SAP standard solution. These solutions willautomatically lead to a high maintenance and support behavior because none of the follow up tasks can beoutsourced either to SAP or to any other maintenance contractor. Often the relation to main standard businessprocesses 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 integrationpoints could be changed in the next software upgrade. SAP provides different tools to identify the integrationpoints and to identify which custom code objects must be adjusted after the software upgrade. Active GlobalSupport provides with the new EHP Scope and Effort Analyzer detailed information about the efforts for theupgrade.

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 thedevelopers workbench a simple but effective method is to bundle the guidelines with thedevelopers workbench in one place.

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

SES_URL=

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 sourcecode. Code templates help the developer to reduce the time spent on routine editing activities and improveconsistency when writing code. They allow for quick generation of commonly used ABAP code, as well as easycustomization. ABAP code templates go beyond the functionality of simple code snippets. They include directintegration with code completion, the ability to use predefined and custom variables, and the ability to improvestyle uniformity and validity of ABAP code. When using code snippets, you basically get a shell that you caninsert and edit manually.



ABAP Development Tools provides a number of predefined code templates for ABAP. In addition, you cancreate your own templates or edit existing ones. You can view, edit, or create new ABAP code templates usingthe 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 alanguage. English in USA is different to English in United Kingdom and it is not easy to define who talks withhigher 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 theoptimization of elements like incident management, incident processing times, hotline, etc. It is very importantto ensure only best of class custom code will move into your system. A bug found in a very early phase of thedevelopment lifecycle will save a lot of money in later phases.

In addition to a contractual alignment between the developers organization and customers IT, we recommendto 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 followingbuilding 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 dont 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 transportrelease and in the quality system with a scheduled job. Results of the global run should be replicated to thedevelopment 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 feelingof 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 donedirectly and the identified error pattern

eliminated. The following benefits can be achieved using any kind of Code Inspection of your custom code.

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



2.2.7 Test

Testing is a substantial part of the program development process. Tests verify the 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 theexecution 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 templatecan be used for different testing efforts

such as functional, development, performance, security, and regression testing.SAP provides documentationfor 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 canuse 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 thecourse 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 runtimeerrors.

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

You can determine how much of your code is exercised by your tests. You can efficiently find gaps in yourtesting that you can fill with new or modified tests. You can verify that your integration tests correspond in termsof 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 SAPs main internal quality assurance tool for ABAP.



SAP Netweaver offers an integrated code quality tool fully integrated in the IDEs like ABAP DevelopmentWorkbench and ABAP in Eclipse. The code inspector or the successor ABAP Test Cockpit is integrated in thetransport 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-31773The Setup and administrative work at http://scn.sap.com/docs/DOC-32791The 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 transportsbetween development system and quality system and between the quality system and the productivesystem. Use the same check variant for all code checks. The identified issues with Priority 1 and 2 must besolved 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 sequencesnot able to be detected with static checks of the SAP Code Inspector. The RTM checks support, in the release7.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 andthen SAP note 1931870. Start SRTCM Lite with report SRTCM_PRELIMINARY. When SRTCM lite is availablein 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 thechecks, 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 oftime in a productive environment or a test system with heavy test activities. It is not intended to keep the RTCMactivated for a longer period of time. Reasons are overall performance loss and generated data volume.



2.3 Run & Monitoring

2.3.1 Operation Handbook

After release of code to a productive environment in most cases the documentation 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 leasta

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 dataflow 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. SAPABAP checkpoints can be used to make sure that program correctness is maintained. Under checkpoints, weconsider 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.

AssertionWith 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 bestopped 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 processingactivateable break points are simply ignored.

LOG-POINTS: Log

Point can be made activate-able by writing following code in your program.

LOG-POINT ID Checkpointgroup.



Logs can be used to identify or analyze the system behavior. Variable values can be logged so that theprogram 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 onthe 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 enhancedSAP Netweaver capability will have no performance impact on your system and will catch usage information ofABAP routines directly when they happen. UPL will give you 100% coverage of usage without estimations orevaluation of ABAP call stacks. This also includes the detection of dynamically called ABAP elements. UPL isthe one and only technology to close the existing gaps in the SAP workload statistic. With the secured accessto the UPL data, your usage information is protected against 3rd party eyes. The full reporting capabilities withenriched information in BW of the Solution Manager will give you the flexibility to analyze ABAP usage for yourcustom 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 aprocedure level can be done with UPL. For a detailed test coverage analysis also the SAP Coverage Analyzercan be activated in test or Quality assurance systems. It is not recommended to activate Coverage Analyzer ina 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 groupingto a development project, a business process or a comparable group of objects to rate the usage level inone or several systems. To create this relationship between a subset of custom code objects to a higheraggregation 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 aprevious chapter there is already explained how to achieve this challenge to avoid modifications. But the mostcritical step in an established code governance process is the control. To improve the governance process andgive 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 allexisting modifications in an ALV list control. Sorting the result list by creation date, will give you the possibilityto 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 centralplace.

2.3.4 Monitor Objects Cloning

As mentioned in a previous chapter one simple strategy to avoid modifications is the creation of a clone. Thismight look like a solution to avoid modifications, but at the same time the efforts to adapt the clones throughmissing 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 allexisting and new cloned objects. Ensure in a development project the creation of clones either from SAP orfrom existing former custom code projects will be avoided. If it is necessary to clone a project documentation isnecessary 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 willdetermine 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 its 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 adaptationof custom code to SAP code and therefore receive the best possible support. You can also benefit from costsavings 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 addreports that are specific to their business, while others have complete custom developed add-ons (developedinternally 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 tohigh operation costs for you because it can be difficult to identify any objects that your system does not useanymore. 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 becomesincreasingly difficult over time as the number of development objects increase. Some objects may becomeobsolete without anybody noticing. The person responsible for custom developments may be unavailable, forexample.



If you want to upgrade to a higher SAP release, or to apply a support package, you must check and adaptevery custom development object manually. You must then test each object to ensure that it does not causeany 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 andorganization 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 (ClearingAnalysis)

Identify the potential consequences an upgrade can have on custom developments (Upgrade /Change Impact Analysis)

Clearing AnalysisClearing Analysis is the analysis of custom objects and modifications made to SAP standard objects in order toidentify 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 clearingprocess.

Upgrade / Change Impact Analysis

Upgrade / Change Impact Analysis identifies the impact that a support package or upgrade will have on anycustom 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 providesfeatures 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 areinterested in achieving the required system throughput and reasonable resource consumption with a given ITbudget, the end users expect very good response times when interacting with software systems. Appropriateresponse 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 phaseto trace the performance behavior of the application. In addition to this proactive investigation it is possibleto monitor a productive system with the SQL Monitor and the Usage and Procedure Logging to get moreinformation 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 GlobalPerformance Analysis (transaction ST30).The ST30 works by invoking eCATTs scripts on a central test system. These eCATT scripts run the recordedscenarios, involving all the necessary components of a system

landscape. The ST30 retrieves the relevant performance figures generated from these runs by integrating thefollowing 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 andcollect 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 assecure as the applications that host and access them. This integrated tool is scanning your ABAP custom codefor 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 soonas the development freeze was done the initial rating of objects shall be done. Classify the code objects in thefollowing 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 riskif 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 currentdata 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 todelete 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 timeuntil all elements are in productive

use. Code objects never reached the productive systems are either incomplete developed or have a wrongbusiness 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