Project Name Cairn Energy

Document Code Review Checklist

SOLMAN Id
Development Title VIM changes
Process Workstream MM
Programmer Name Gautam Kumar
Reviewed By
Review Date

SNo TABLE OF CONTENTS

1 Development Details
2 Code Review Checklist
3 Performance Review Checklist
4 Transport Request Checks
Action

1
2
3
4
5
6
7

3
4

5
6

1
2

5
6

3
4
5
6
7

8
9
10
11

12
13
14
15
16
17
18

1
2
3
4

5
6
7

1
2
3

4
5
6
7
8

9
10

11

12

13

14

15

16
17
18
19
20

21
22

1
2

4
5
6
7
8

10

11
12

13
13.1
13.2
13.3

1
2

3
4

1
2
3

1
2

3
4

1
2
Code Review Checklist
Naming Conventions
Program Naming conventions adhere to Cairn Energy Naming Convention Standards
DDIC Object Names adhere to Cairn Energy Naming Convention Standards
Transaction code name adheres to Cairn Energy Naming Convention Standards
All objects assigned to the correct packages, no local objects
All program Variable names adhere to the Cairn Energy Naming Convention Standards
All TS's are named in solman by following the naming rule : Release_GAP Type_Development Title
All completed TS have a valid TS id assigned and updated in the TS document in solman
Coding Style
All program should have a module header before the "REPORT" statement as indicated in the Cairn Energy
development standards
Use Pretty Printer to align ABAP statements properly. Skipped lines and indention should be used to promote clarity
and code readability
Use subroutines and FORM paragraphs whenever possible to improve readability and logic flow
Every logical division within the program should have descriptive comments - to indicate the business reason or
purpose of subroutines, events, section of code, etc.
Every modification, no matter how insignificant, should be documented
Dead Code should be removed from the program
Data Definition
Use CONSTANTS for variables whose values do not change (Static Data)
Global variables are minimized by declaring local variables or by passing variables through parameters and arguments
while creating internal subroutine.
TYPE (data element) command is used while declaring data variables instead of the LIKE statement.

Internal table declarations as per the Cairn Energy development standards and compatible with ABAP object context

Variable names are descriptive, meaningful and consistent within a development

The category and scope of objects must be clearly identifiable from the name
Programming Standards
Code Reusability option looked at and used in the program - includes Cairn Energy developments and SAP delivered
content (example SAP defined function modules/methods)
Selection Texts and text elements are used, no hard coding of literal text
SAP-delivered objects are not changed/updated including SAP database table contents
Reports should have the basic organizational structures as input selection screen inputs
Program design includes error handling features

No hard-coding of date formats and currency formats in the programs, currency amount is coupled with a currency key
All reports should consider use of the ABAP List Viewer (ALV)
No RFC calls allowed to and from non SAP systems
Transaction codes attached to executable programs
Use "Read Table" …. With "Binary search" option while looking for specific set of values in Internal Table.
1. Before the "Read", Check whether Internal table is Sorted based on the columns used in the "Key" clause.
2. If the Internal table type is "HASH TABLE" then this check is not applicable
Using Select …. For all Entries, check should be made to ensure that the Internal Table is not Empty
Function module exceptions must be checked by the calling program
System status (SY-SUBRC) must be checked after every event in the program that changes it
SY-TABIX should not be used directly in a program, copy it into a local variable and then use the local variable
MOVE-CORRESPONDING is only used when two structured variables/internal tables have identical fields
Levl 0 test cases check program background processing
Run Code Inspector/check for Performance/Code Optimization/Extended Syntax check warnings and errors
Dialog/Module Pool Specific Checks
Modularization of an Module Pool as per Cairn Energy development standards
Data Dictionary references of custom dictionary structure for all screen fields
No recursive call screen statements
Selection screen validations applied and Input validation checks applied to all input screen fields that update database
tables
Access to database objects mandates use of SAP locking mechanism.
Database updates performed in an update task function module as bundled updates
Custom RF screens adhere to RF program guidelines and restrictions
Interface Specific Checks
SAP Standard IDOC's evaluated and used in the interface
Custom proxies created over creating pure custom IDOC types

Enhancement to standard IDOC by creating custom IDOC extension enhancement segments considered and used
Error handling done for custom inbound proxies with the use of FAULT message type
Error handling done for custom IDOC extensions created
Workflow used as the mechanism to handle all ALE errors, BAPI errors handled via Bapireturn parameters
As applicable Standard BAPI' functionality used and wrapped around a custom proxy
Master data interfaces that require periodic processing use the standard SAP supplied Change Pointer program,
RBDMIDOC, to initiate transfer
Only fields identified as change fields will have active change pointers set for transfer
Requests for Individual, Mass or complete refresh of master data performed manually using the standard SAP
programs within the BALM transaction
For transactional data if output determination functionality is available within that business transaction then this will be
the preferred method for transfer
Only for real-time interfaces as dictated by the FS and business requirements the message types will be set to process
Immediately within the partner profile
Packet sizes will be determined based upon IDOC size, performance and optimization analysis during testing, default
will be set to 50 
For batch processing of inbound IDOCS the message type et to trigger by background program, a separate batch job
will be required for execution of this interface type
Parallel processing with the use of RFC server groups after discussion and approval from BASIS will be considered
based on the nature and volume of data transfer
Wherever applicable serialization requirements handled and programmed
No or exception use with justification for use of BDC Recoding or Call transaction for any interfaces
For front-end file handing use of methods and attributes in CL_GUI_FRONTEND_SERVICES class
UNICODE compliance of OPEN DATASET command
Program to check if the user has authorization to open files on the application server - use fn module
AUTHORITY_CHECK_DATASET
Use of logical file names as applicable
Where applicable, statistical report , exception report and program execution detailed log output as per the program
design
Form Specific Checks
Standard forms used a baseline - driver towards smartforms and adobe forms.
Custom driver programs should not be created - use of custom perform statements and smartform initialization blocks
considered
In smartforms/adobe forms any custom extraction to be performed in the initialization section and not in the individual
nodes and program lines
Unwanted text element ID's copied from the SAP original form should not deleted
Separate styles for each and every development
Standards texts be used to print configurable texts
Paragraph tab used for spacing, use of correct fonts in the form as per the program design document
Physical form output unit tests executed on correct printers v.important for Preprinted stationery forms and label
printers
Form Translations, the non English text should be of a length smaller than the English text
Adobe Forms specifc checks (In addition to above checks)
Function module 'FP_FUNCTION_MODULE_NAME' used to get auto generated smart form function module, in
program
Minimum (only unavoidable) coding done in Interface
Only required variables mapped in Context

If Form Scripting is performed in code then check following

Appropriate scripting type ( server side or client side ) is used.
Appropriate scripting language (Java Script / Form Calc) used through out the form.
Proper Documentation maintained for code, Refer Documentation section mentioned above.

Workflow Checks
Before a new workflow or task is defined, the SAP library must be searched for any templates in the system.

No changes to standard SAP workflow, task groups, tasks, and roles. These elements are client independent in the
system
Collect the tasks and workflows that belong together in a task group.
Deadline monitoring changed as per requirements of unit testing
Enhancement Checks
While creating new user exit includes ensure the editor lock in not set, SAP defaults this
Explicit Enhancement spots evaluated as an option
For local market RICEF, user exit enhancement strategy implemented
Message Checks
Use existing messages where possible and appropriate instead of creating multiple duplicates.
Use message type ‘I’ with LEAVE LIST-PROCESSING rather than messages of type ‘E’ in the START-OF-
SELECTION and END-OF-SELECTION events
Make sure all messages using 'WITH' clause have ‘&’ parameters in the actual message definition
Ensure no hardcoded break-points or checks based on specific user name (sy-uname) exist in the code
Security/Authorization Checks
Custom tables and maintenance views have correct authorization group assigned
Authorization checks are used whenever appropriate
Review Action Comments
Yes/No/NA
NA
NA
NA
Yes
NA
Yes
Yes

Yes

Yes
Yes

Yes
Yes
NA

Yes

Yes

Yes

Yes
Yes
Yes

Yes
Yes
NA
Yes
Yes

Yes
Yes
NA
Yes

Yes
Yes
Yes
Yes
Yes
Yes
NA
Yes

Yes
Yes
Yes

Yes
NA
NA
NA

NA
NA

NA
NA
NA
NA
NA

NA
NA

NA

NA

NA

NA

NA

NA
NA
NA
NA
NA

NA
NA
NA

Yes

NA

Yes
NA
Yes
Yes
Yes

Yes
NA

NA
NA
NA

NA
NA
NA
NA

NA

NA
NA
NA

NA
Yes
NA

Yes

Yes
Yes
NA

Yes
Yes
Action

1
2
3
4
5

6
7

8
9
10
11
12
13
14
15

16

3
4

5
6
7
8

1
2

1
2
3
4
1

2
3

4
Performance Review
Database operations
Pick only relevant fields from SQL’s, Select * should not be used if all fields are not required
where clause specified precisely
Fields used in the WHERE clause are in proper order
Use of database indexes
where clause kept simple, avoid complex where clause - Avoid using OR conditions in WHERE clauses and using NOT
condition on an index field
Use LIKE on a non-index field and ensure that the data fetch will be drastically reduced
For all Entries used over “Loop at itab > Select > Endloop program construct. No selects should be made within loops
unless absolutely necessary
Check is place to ensure internal table IS NOT INITIAL before any FOR ALL ENTRIES statement
DELETE ADJACENT DUPLICATES from the driver table in place before any for all entries select
Avoid using inner join/outer join together with ‘FOR ALL ENTRIES’
Use “SELECT INTO TABLE” rather than “SELECT INTO CORRESPONDING FIELDS OF TABLE”.
the ORDER BY statement should be rarely used because it is database intensive
Do not use Nested Select. Use “Inner Join” and/or “For all Entries” instead.
Consider Join implemented as a view in ABAP/4 Dictionary
When creating joins over database tables there should be an index at least on the inner table for the fields in the join
condition else use for For-all-entries select.
Cluster and pool tables have read overheads. Hence every access to a cluster or pool table must be carefully evaluated.
The same caution apply to transparent tables used as a history table (e.g. VBFA).
Program Processing
Avoid LOOP AT WHERE. Instead implement Parallel Cursor technique to avoid unnecessary and extra loop processing.

HASHED TABLES should always be used when there is need for multiple reads on a big internal table (i.e. with table key
access
Do not DELETE or SORT on a hashed table since it increases memory costs.
When a hashed table cannot be declared or used or is unnecessary, use READ with BINARY SEARCH after 
SORTING
Use addition TRANSPORTING in conjunction with READ and MODIFY wherever possible
SORT and delete should not be used inside a LOOP statement
Program logics consolidating multiple loops on an internal table and one look wherever possible
COLLECT can be used for filling cumulative values into an internal table but not for modifying statements (INSERT,
DELETE)
Use Program Buffering Concept with use of internal tables and inside a Function Module that are called with recursively
with duplicate data
Forms Development
All data retrieval and logic should be placed in initialization block/section of the smart forms
Interfaces
Only Interfaces that require immediate processing to ensure overall business integrity will be set to process immediately
ABAP code written within IDOC user exit should be highly optimized to avoid performance issues in high volume execution
Memory Management
Free internal tables whenever no longer needed
Eliminate redundant internal tables
Eliminate unnecessary SORT’s/DELETE ADJACENT/
Eliminate unnecessary data transfer between internal tables
SAP Performance Tuning Transactions - USE
Use runtime analysis SE30 to display results as a series of lists, display table access summaries and the program flow

Use ST05 to perform a SQL trace to analyze the run time information, the native SQL used to access the database,
duplicate database table hits if any and test out different SQL statements
Use Transaction STAT used to check out workload statistical records - run time of the program with details of CPU time,
DB request time and overall response time
Optional - Use transaction SM50 -> Detail to view the memory usage at a given point of time during the program run

Key Points to consider

Five Rules of Efficient SQL Programming
Keep the result small
Minimize the amount of data transferred
Minimize the number of Data Transfers
Minimize the search Overhead
Reduce the Database load
Program Design and Logic
Various designs can be used to achieve the same result, sometimes changing a given approach/design addresses the
performance issues. Functional, business analysts and program developers can always work together to find the most
efficient design path
Review Action Comments
Yes/No/NA
YES
NA existing one used
NA existing one used
NA

NA
NA
NA

NA
NA
NA
NA
NA
NA
NA
NA

NA

NA

NA

NA
NA

NA
NA
NA
NA

NA

Yes

NA
NA

NA
NA
NA
NA
NA

NA

NA

NA
Action

1
2

9
Performance Review

All RICEF Objects for the FS are in 1 single appropriate Z package

Cairn Energy Transport Request naming conventions adhered to

Standards texts/logo's should be manually saved in the Transport containing the main form layout set

New function modules created in existing groups , the Transport includes the main program of the
Function Group
All messages used by the program are included in the Transport

All ALE-IDOC related configuration and setup is included in the Transport

Logical file names are included in the Transport

Custom Z tables of type config are included in the Transport with the correct table contents

User-exit projects are included in the Transport

Review
Action Comments

Yes

Yes

NA

NA

NA

NA

NA

NA

NA