ABAP Development and Review Best Practices V2.3

© 2009 IBM Corporation

GBS Globally Integrated Delivery

ibm

1© Copyright IBM Corporation 2010

IBM Confidential

ABAP Development and Review Best Practices

2012

© Copyright IBM Corporation 2010

GBS Globally Integrated Delivery ibm

2 IBM Confidential

Purpose of the document

The purpose of this document is to be a refresher guide on ABAP Best Practices and also to highlight some of the common issues that are currently being observed in multiple projects.

Target Audience:

All ABAP Practitioners including Teams Leads and Reviewers.

Expectation from Reader:

The strategies, templates and approaches mentioned here are based on general IBM delivery methodology as well as from TAC.

However all practitioners are expected to follow their existing project methodologies and not adopt anything without discussing and agreeing with the project management.

The variances should be highlighted and discussed with the Team Lead or PM. Unless there is a project specific direction, the reasons for not following the best practices should be documented and remain available for audits.

There will be a follow-up mandatory online quiz covering all elements of ABAP delivery which all practitioners will have to take and pass.



3 IBM Confidential

The following section covers the ABAP Delivery process flow, the associated tools and checklists.



4 IBM Confidential

Meth

od

P

hase

Communication & Coordination (all teams)

1. Document Functional

SpecificationDocument (FSD)

8.Create Technical Design and Unit Test

Plan

13. Execute Unit Test

16. Review Test Results

Clie

nt

18.Test ( Functional,Integration and User

Acceptance )

14. Internal Code Walkthrough

9. Internal Design Walkthrough

17 SCR

10.DesignReview

Legend

Task with Deliverable

Task withoutDeliverable

Process checkpoint

Sign off andKnowledge Transfer Handoff

AB

AP

TA

C/O

ffsh

ore

GD

19. Support development

during cutover and testing

20. Complete Knowledge management with Lessons Learnt and update

methods .

2. Decide Delivery Cell *

3. Compute FSI

4. Interactive Design Session

5. Determine Complexity and

Effort

6. Perform TAC capacity planning and

decide on schedule and resource *

7. Identify Reusable Components that

can be used

11. Create Program Structure using RIC

Generator and plug in reusable components

12. Complete code

Ongoing Issue Resolution (all teams)

SAP ABAP Development– Process Flow

15. Delivery Review

RealizationBusiness Blueprint

Final Preparation

Go Live

* Steps # 2 and 6 are applicable for TAC only



5 IBM Confidential

Some Examples:

Document Template Example

FSI http://romgsa.ibm.com/gsa/romgsa/home/a/n/anirdg/SAP%20Wiki/3005/SAP_WRICEF_FSI_V2.1.xls

CDF http://romgsa.ibm.com/projects/s/sap_methods_india/saptac_methods/TAC_ABAP%20Estimator_V1.7.xls

TS Review Checklist https://w3.tap.ibm.com/w3ki2/download/attachments/796033/TS_Review_Checklist.doc?version=1

Code Review Checklist

https://w3.tap.ibm.com/w3ki2/download/attachments/796033/AAO+ABAP+TAC+-+Code+Bundle+Review+Checklist+v2.0.xls

It is always suggested to work with the current copy from the wiki, as these documents are frequently updated.

Code_Review_Checklist_Sample

FSI_Sample

CDF_Sample

TS_Review_Checklist_Sample



6 IBM Confidential

Gaps identified in the process adherence across projects

IssuePrimary

ResponsibilityExpected Action

FSI not done consistently across projects

Developer/TLFSI usage should be mandatory, unless the development is very small < 16 hrs

Issue log not maintained – issues and resolutions are in individual mailboxes

TL/DL

Issue Log provides an official means to highlight and escalate problems. This is a mandatory process and should not be bypassed.

Review records not maintained – review not done diligently or review points are in mails and not tracked to closure

TL/Reviewer

No delivery should happen without a proper review. Evidence of review for all developments should be centrally available for audit purposes.

Review bypassed for Changes (TPRs/SCRs)

TL/DLAll changes should undergo review before delivery.

Code Optimizer or SCI are not used consistently across projects

Developer

Usage of Source Code Inspectors like Code Optimizer or SCI should be made mandatory. Developer has to ensure that all issues reported from the tool is addressed before handing over a code for review.

Defect Prevention activities ( analysis of defects and taking action based on analysis ) not performed consistently

TL/DLThis is a mandatory DE process, discuss with the PQA for more details.



7 IBM Confidential

Gaps identified in the process adherence across projects

IssuePrimary

ResponsibilityExpected Action

Incomplete metric data submission:All objects are not reported in the Metric ToolIncorrect data submitted( incorrect DDD , DRE etc)

TL/DLAs per IBM DE process, complete and correct data for all developments should be submitted in Metrics tool.

Quality of delivered code is not meeting expectation ( please refer next slide)Hard coding , issue with Date format , not following Coding standards etc are commonly occurring issues

Developer/Reviewer Refer to subsequent slides



8 IBM Confidential

This section covers the best practices in ABAP development, common Hard Coding scenarios, their possible remediation and some examples.



9 IBM Confidential

Process, Methods and Tools

Any ABAP development has to be compliant with the following:

The ABAP Development Standard *

The Development Review Checklist *

Checks of code inspectors like Code Optimizer and SCI

* It is strongly recommended to go through these documents at this stage before proceeding farther. Links to these are available in the later slides.



10 IBM Confidential

10

Hard Coding – A common issue

Hard Coding refers to the software development practice of embedding input or configuration data or even transactional directly into the source code of a program, instead of determining that data programmatically using a logic or retrieving the data from configuration/tables in single or multiple steps.

Hard coding means the coding practice to specify a data value within a code, which restricts the program execution for that specific data only.

As per IBM development standards, NO such hard coding should be done in any development.

If there is any specific business need it should be clearly called out in both FS and TS.

The strategy for handling constants can vary between projects, but it is always recommended to follow a practice which provides maximum scalability and flexibility. For example:

Using TVARVC table for maintaining constant values Make it a part of selection screen Develop a dynamic logic in program

An example of Hard Coding: SELECT kunnr parvw expnr inpnr

INTO TABLE i_edpar

FROM edpar

FOR ALL ENTRIES IN i_expnr

WHERE kunnr = 'EDI820'

AND parvw = 'RG’ AND expnr = i_expnr-expnr.

Hardcoding on customer number and partner function



11 IBM Confidential

Different Categories of Hard Coding and guidance to Remediation

Hard Coding can be broadly categorized into:

High Impact/Severity: Literals or Constants used for 1) Business variables like Organization Structure/Element, G/L account, Sales org, Chart of Accounts, Company Code ,Customer number, Vendor number, Create/Change/Display T-Codes (especially for enhancements) 2) System Parameters like system id, current date, current time etc., 3) File path/File directory 4) Hard coded User Id Checks, Hard Coding in forms/reading texts, Hard coded form name in driver program in the code. etc.

Medium Impact/Severity: Literals or Constants used for specific values of fields (e.g. Document Type, Movement Type, Order Type, Item Category etc.) and these constants are used at different places in the code.

Drawback: If Business variables are hard coded using literals or constants, then limits the extendibility of the program to newer scenarios. Hard coding of System variables and File path/File directory makes the program rigid and increases the maintenance overhead of the program.

The developer and designer (Designer is the primary responsible in this case) should incorporate flexibility of the solution in the design itself (e.g. Collecting some values from the user in the selection screen, pointing to some configuration, suggesting a single or multi-step logic to retrieve it from standard or custom tables.)



12 IBM Confidential

Different Categories of Hard Coding and guidance to Remediation The Developer should discuss and confirm with the designer for any design

considerations/changes to get the values dynamically.

1) Business variables should be defined as parameters with default values in the selection screen, so that their values can be changed. No hard coding should be done in the program.

2) Only System Variables (e.g. sy-uname, sy-datum) should be used to get system parameters .

3) File path/File directory: No hard coding should be done in the program for the same. Logical file names should be used instead and should be declared as parameters with default value.

Developer can maintain these values is table TVARVC and extract from there within the ABAP code. This will help the power user to maintain it, without changing the code, but it is still Hard coding, as the Hard coded values just move from the Code to a table. This use of TVARVC or any Custom table to store the values can logically be categorized as another type of Hard coding, so using this option should be discussed and agreed with the functional consultant

To really keep off Hard Coding the designer should provide the logic or give reference to some other standard transaction to the developer to determine the values dynamically.

Note: It is okay to use constants in Enhancement Spots/BAdi/User Exits/Idocs, if there is no way to determine the required value of business variables, using the information available inside the Badi/user exit/Idoc. However it needs to documented in TS/FS.



13 IBM Confidential

Different Categories of Hard Coding and guidance to Remediation Low Impact/Severity: Hard Coded Literals used in code, which can be maintained as

Constants (e.g. Flags, Return codes, Gui status, Type of message, Transaction Codes etc.)

Impact is Low, as this will cause inconvenience in maintaining the program, but this will have no improvement in functionality, if hard coded literals are replaced by constants.

Drawback: If Hard Coded Literals are used in code, without maintaining them as Constants then when the value needs to be changed, it needs to be done at all places the literal is used inside the program. However, defining constants and using them inside the program will make it easier to change values, as the value needs to be changed only at a single place, where the constant is declared.

Remediation:

Developer is fully responsible, as he/she is NOT compliant as per coding standards.

Define appropriate constants and set it with the required value. Use the constant at all places in the program, where the literal was used.



14 IBM Confidential

Hardcoding is common in the these areas..

Date format: A common mistake is to hardcode the output

format of the date based on the current geography of implementation.

Best practice:

· Identify the country of use; print as per the date format of that country

· if country specific date format not available then print as per the user profile date format

A date 10/02/2012 will be read as 10th Feb in Europe

and 2nd Oct in US. An example of hard-coding:

IF g_rem_date IS NOT INITIAL.

WRITE g_rem_date TO lv_rdate MM/DD/YYYY.

ENDIF.

SPLIT p_idate AT '/' INTO lv_year lv_month lv_date.

Developer should always validate with the process team on whether a development will be used globally or local to a specific country.

Logical System or RFC Destinations:

Logical Systems and RFC destinations should never to hardcoded.

Based on project strategy it can be dynamically generated in code , or using the values from system tables like RFCDES, or by maintaining them in custom tables/TVARVC

Output Currency:Similar like date format.

Should be driven by the country or user profile.

The format cannot be generalized as well as countries like Japan does have a decimal system.



15 IBM Confidential

15

Commonly observed Hard Coding practices

Type Commonly Observed Practices

3(High) Hard coding GL Account/Movement Type/Document Type in Program (e.g. Interface structure or org unit, master /transaction/config data)

Wrong "IF <ls_table>-lgnum EQ 203."

Warehouse Number / Warehouse Complex hardcoded to 203.

Correct Use TVARVC/Sel-Screen/dynamic logic etc in consultation with Functional Consultant and must be mentioned in both FS and TS

3(High) RFC Destination/Logical system hardcoded

Wrong lv_logsys = ‘D03CLNT100’.

Correct Use TVARVC/Sel-Screen/dynamic logic etc in consultation with Functional Consultant and must be mentioned in both FS and TS. For logical System name, retrieve from T000 or use FM OWN_LOGICAL_SYSTEM_GET.

3(High) Condition type hard coded in VOFM routine, Forms.

Wrong IF KSCHL = ‘ZABC’


3(High) Partner Functions hard coded

Wrong IF PARVW = ‘SP’.




16 IBM Confidential

What are the commonly observed Hard Coding practicesType Commonly Observed Practices

3(High) Currency Format hard coded

Wrong Write lv_curr to lv_curr_out currency ‘JPY’.

Correct Write lv_curr to lv_curr_out currency lv_currency where lv_currency is the currency key for lv_curr.

3(High) Selection from text tables with language hard coded (e.g. Where SPRAS = ‘E’, TDSPRAS in FM READ_TEXT = ‘EN’ etc. )

Correct Retrieve language using business logic or from logon language unless stated explicitly in the FS. If so use a retrieval logic using TVARVC/Sel-Screen etc in consultation with Functional Consultant and must be mentioned in both FS and TS.

3(High) For all form calls printer name is hard coded (TDDEST = ‘LOCL’ etc. Wrong)

Correct Printer name should ideally be never hardcoded. Even if there is any specific business need, then apply a dynamic method like Sel-sceen/ TVARVC etc.

3(High) In enhancements Hard TCode checks (e.g. ME22N) to trap transaction modes (create/Change etc).

Wrong If sy-tcode = ‘ME21N’

Correct If trtyp = lc_trmode_a , lc_trmode_h, lc_trmode_v.

3(High) Date format hard coded. Wrong Using a predetermined value as date format.

Correct As explained earlier.




17 IBM Confidential

17

What are the commonly observed Hard Coding practicesType Commonly Observed Practices

2(Medium)

Item position using hard coding (e.g. ‘900001’)

Wrong In case of retrieving batch split data we often use the batch split item number to get the batch split details.

Correct Use fields provided in tables to indicate higher level item to indicate batch split and other such scenarios. Incase it is absolutely necessary and explicitly stated in the FS, use TVARVC/constant in this case.

2(Medium)

In enhancements Hard TCode checks (e.g. ME22N to restrict multiple tcodes with same functionality

Wrong If sy-tcode = ‘ME21N’.

Correct In case functionality needs to be restricted as stated explicitly in the FS use a retrieval logic leveraging a flexible approach like TVARVC/local constant in consultation with Functional Consultant and must be mentioned in both FS and TS.

1(Low) Using hard coded literals in FM/Class Methods

Wrong Call Function ‘ABC’

Exporting

Program = ‘ZABCDEFGH’

Correct Call Function ‘ABC’

Exporting

Program = lc_prog




18 IBM Confidential

18

What are the commonly observed Hard Coding practices

Note: If any project's development standard has a different approach for any of the guidelines shared here, then the developer should follow the approach defined in the project's development standard and discuss with the Cell Leads/Delivery Leads for any confusion.

Type Commonly Observed Practices

1(Low) Reading messages in BAPI (Message Type = ‘E’/’A’)

Wrong Read table lt_bapiret with key msgty = ‘A’

Correct Read table lt_bapiret with key ksgty = lc_msgty_a

These are only some of the common examples. It is recommended for the project to do an analysis of their own defect data, and take corrective measures as appropriate.




19 IBM Confidential

General Guidelines: Static Methods / Attributes should not be used, unless

there is a specific need.

Visibility of Methods / Attributes should be properly chosen:

-[1] The Methods / Attributes used for internal logic / calculations should not be declared as ‘Public’; those should ‘Private’ / ‘Protected’ depending on the requirement.

-[2] Only the Methods / Attributes used globally should be declared as ‘Public’.

Exceptions should be properly handled inside the Methods; a proper custom message should be used along with those Exceptions.

While creating custom classes, proper care should be taken before declaring that as ‘Final’ –

-[1] A ‘Final’ class can not have subclass– in another word, the ‘Final’ class can not be inherited.

-[2] A ‘Final’ method can not be redefined in subclasses.

The ‘Local’ classes can be used, if the scope is limited within a single program / global class only. If it has to be used in several places, then it must be declared as ‘Global’.

While using ‘Local’ classes in a custom program, there should be a separate ‘INCLUDE’ program for ‘IMPLEMENTATION’; the ‘DEFINITION’ can still be declared in the ‘TOP INCLUDE’.

Explicitly use the self-reference ‘ME’ while accessing any Method / Attribute of the same class, in stead of just using those individually.

Bypass Obsoletes:

There are several statements those are syntactically forbidden in ABAP Objects or in Unicode programs. Here we have tried to collect some of those as a ready-reference:

The left-hand side of the following table shows obsolete relational operations.

The statement ‘RANGES’ is an obsolete declaration of a range tables. The statement is now replaced by the addition ‘TYPE’ or ‘LIKE RANGE OF’ of the statements ‘TYPES’ and ‘DATA’.

Obsolete Statements:

1. ON CHANGE OF and ENDON

2. ASSIGN LOCAL COPY

3. ADD - THEN, UNTIL

4. Many more…… Read Project / IBM Development standards for details.

‘Extended Syntax Checker’ must be used after developing any custom object, to identify all these obsolete statements.

Best Practices in OOPs ABAP

Obsolete operator

Valid operator

>< <>, NE

=< <=, LE

=> >=, GE



20 IBM Confidential

20

Best Practices that should be followed…

Form names should always be picked up from config tables (e.g. TNAPR for SD forms)

For condition types/document types use TVARVC or client specific variant table heavily.

All checks identified by IBM Code Optimizer and other SAP tools for syntax checks should be removed before the internal review.

Literal with translation requirements and being displayed to user on screen or in print, should me maintained as text elements and NOT CONSTANTS

For webdynpro/forms use OTR Texts and text modules/standard texts.

For hardcoded subroutine for external programs calls always use IF Found.

Never hardcode basic transaction data like customer/vendor within program.

Constant names should always be meaningful and well documented.

Instead of Flag use ABAP_TRUE.



21 IBM Confidential

Best Practices that should be followed…

For alv calls use sy-repid and not hardcode the program name and same for subscreen.

Use Activity Type (TRTYP) instead of hard coded TCODE values.

End Date in HR Programs (ENDDA) should never be hardcoded as ‘99991231’

Fact – Generally 80% of issues are caused by 20% of problems. Common examples:

Not using Binary search, or not sorting the internal table correctly before the binary-search read.

Check the driver internal table is not empty before “all entries” select

No parallel cursor, loop within loop

Not using proper indexes in selects. Not checking SQL Traces for performance impacts

Mandatory Read

ABAP Development Standard

https://w3.tap.ibm.com/w3ki2/download/attachments/796033/Development+Standards.zip



22 IBM Confidential

Important links

ABAP Wiki link :

https://w3.tap.ibm.com/w3ki2/display/ABAPTAC/0+-+ABAP+Service+Area

Wiki of ABAP TAC Service Area: Contains information on Governance, PMT, Training, Solutioning etc.

ABAP Development Standards : https://w3.tap.ibm.com/w3ki2/download/attachments/796033/Development+Standards.zip

Contains the ABAP development guidelines and naming conventions.

SAP PM&T Snapshot :

http://ams1.sby.ibm.com/igsdf/pmt_snapshot.nsf/Content/SAP_Intro

Covers the overview, common guidance and details of SAP Assets.

SAP Tools Snapshot : http://ams1.sby.ibm.com/igsdf/pmt_snapshot.nsf/Content/SAP_Tool_Guidance_GlobalDelivery

Contains details of the IBM Tools and Accelerators



23 IBM Confidential

Question?

If you have any question on the content please discuss with your team lead. Also you can reach out to any the following.

Ranadeep Banerjee

http://w3.ibm.com/jct03019wt/bluepages/simpleSearch.wss?searchBy=Name&location=All+locations&searchFor=ranadeep+banerjee

Subhanjan Mitra

http://w3.ibm.com/jct03019wt/bluepages/simpleSearch.wss?searchBy=Name&location=All+locations&searchFor=Subhanjan+Mitra+

Sangram Chowdhury

http://w3.ibm.com/jct03019wt/bluepages/simpleSearch.wss?searchBy=Name&location=All+locations&searchFor=Sangram+Chowdhury+

Sachin Tadse

http://w3.ibm.com/jct03019wt/bluepages/simpleSearch.wss?searchBy=Name&location=All+locations&searchFor=Sachin+Tadse+



24 IBM Confidential

Measurements Selected for SAP ABAP Delivery

Quality Defect Injection Rate Cost of Quality Cost of Poor Quality Delivered Defect Density Defect Removal Efficiency FSI Average

Cycle Time Schedule Delay % On Time Delivery % On Time FS FS Schedule Delay

Speed Effort Variation % On Budget Delivery

Reuse Effort Savings due to Reuse



25 IBM Confidential

ABAP Development and Review Best Practices V2.3

Documents

Transcript of ABAP Development and Review Best Practices V2.3