Coding Standards of
abap:
ACCESS CONDITION WITHOUT ALL KEYS:This rule covers both, SELECTs from database
tables and READs from internal tables. Single rows in internal tables are
accessed with a READ TABLE statement. All READs access the internal table by
numeric index or with an internal table key. For READs with an incomplete or
incorrect key there may be multiple rows that satisfy the partial criteria. In
this case the READ statement returns the first matching row. This may not match
the expected result.
Select Single should provide all fields of the Primary Key. The purpose of a select single is to retrieve a single unique row based on the unique primary key fields(s). Without all key fields specified, there may be multiple rows that satisfy the partial key criteria resulting in any one of the rows being returned. Therefore, the specific record expected may not be the one returned.
DATABASE ACCESS INSIDE A LOOP:Avoid database accesses inside a loop to minimize performance issues
The
file pointer will be set immediately after the 3 byte BOM.
LENGTH:VALUE specifications must not exceed the length
of the defined field or type.
NAMING STANDARDS
Select Single should provide all fields of the Primary Key. The purpose of a select single is to retrieve a single unique row based on the unique primary key fields(s). Without all key fields specified, there may be multiple rows that satisfy the partial key criteria resulting in any one of the rows being returned. Therefore, the specific record expected may not be the one returned.
ACCESSING ABAP MEMORY WITHOUT ID:Programs should always reference ABAP Memory by a
unique ID. Referencing Memory generically can have impact on other applications
using ABAP memory i.e. FREE MEMORY without an ID would wipe out all ABAP memory
which could affect other programs that are counting on data in memory.
ALV LIST VIEWER:
• Classic List reporting using Write statements
• The first introduction of ALV with the REUSE*
functions
• This was then replaced with the Class based
ALV using CL_GUI_ALV_GRID
• And now a complete delivery of the ALV object
model called SALV.
All new report
programming should use SALV* classes
AMBIGUOUS FIELD NAME:
ARITHMETIC OPERATORS INSTEADOF WORDS:Use operators (+, -, *, /, =) rather than the obsolete
words ADD, SUBTRACT, MULTIPLY, DIVIDE, MOVE.
ASSIGNMENT HAS NO EFFECT:
BREAK-POINT STATEMENTDETECTED:All break-point statements must be removed prior to
production. This could potentially stop production and provide back door access
(I.e. debugger) into the code and confidential data.
BUFFER INVALIDATED:
• UPDATE/DELETE with a WHERE on
single-record-buffered table.
•
UPDATE/DELETE
dbtab, UPDATE/DELETE dbtab FROM WA and UPDATE/DELETE dbtab FROM ITAB each
invalidate only the specified records
• UPDATE/DELETE with a WHERE invalidates the
entire table in the buffer.
•
UPDATE/DELETE
with a WHERE on generically buffered table and generic key not fully specified.
•
UPDATE/DELETE
with a WHERE, and the generic key in the WHERE condition is not fully
specified, all the generic areas of the buffer are invalidated.
• INSERT/UPDATE/MODIFY/DELETE on completely
buffered table.
Each change of a
completely buffered table invalidates the table in the buffers of the other
application servers of the system. If the parameter "Only 'buffering
switched on' " is set in the check, accesses to tables that allow the
option 'buffering' in their technical properties, but have 'switched off' set,
are not checked.
BUFFERED TABLE IN A JOIN:
BUFFERED TABLE IN SELECT WITH SUB QUERY:Avoid the use of buffered tables in a sub query to
avoid bypassing the buffer.
BYTE & CHARACTER STRINGS:
CALL TO EDITOR:
CASE VERSUS IF:
CASE WHEN FIRST STATEMENT:
CASE WITHOUT WHEN OTHERS:
CATCH - PROCESSING MISSING:
CLIENT SPECIFIED LIMITED TOSYSTEM TOOLS:In Multi-Client production systems, regular ABAP
application programs should never select data across clients with the CLIENT
SPECIFIED option since there’s a risk with mixing data across clients /
companies. Standard SAP always stays within a client for regular application
data and therefore custom code should follow the same rule. The use of CLIENT
SPECIFIED should be limited to system tools.
CLIENT SPECIFIED TABLE FIRST FIELD:This is a Data Dictionary Requirement that Client
Specified Tables MUST have the first field of the table defined as CLIENT
(MANDT).
CODING BLOCK EMPTY:
COMMON PART STRUCTURE DEFINITION INCONSISTENT :Identically Named Common Parts must have the same
structure definition.
COMPONENT NOT ASSIGNED TO AN ENHANCEMENT:Function Module must be assigned as a component of a
CMOD enhancement.
CURRENCY CLAUSE:When outputting numbers that are tied to currency,
always use the CURRENCY formatting option. This will set the number of decimals
according to the currency of the country.
CUSTOMER DEFINED MACROS NOT RECOMMENDED:Operational issues in Macros that cause Program Dumps
are difficult to trace. Wrap the reusable code in a method instead.
DANGEROUS HIDE ON A FIELD SYMBOL:Avoid using field symbol with a HIDE statement. If
field symbol is not assigned, unpredictable results can occur
DATA VARIABLES - USE OF DEFAULTS:Do not use implied defaults on data declarations. Be
explicit when TYPING your data variable. Always Specify the TYPE and Length.
DATA VARIABLES - USE OF TYPE VS LIKE:Use
keyword TYPE when declaring data objects rather than LIKE (which is an old
convention). LIKE should only be used when a data declaration refers to an
existing data object defined in your program. LIKE is also commonly used for
declaring the line type of an internal table i.e. LIKE LINE OF.
TYPE is a common
convention found in most other modern programming languages.
Note: In OO
porgramming, any reference to a dictionary type MUST use the keyword TYPE. LIKE
will fail syntax check.DATABASE ACCESS INSIDE A LOOP:Avoid database accesses inside a loop to minimize performance issues
DATABASE UPDATE
WITHOUT UPDATE MODULE:Updates to the database should be encapsulated
in V1 or V2 Update function modules. This provides full recovery and logging of
activity when performing INSERT, UPDATE, MODIFY and DELETE of Database tables.
DATABASE UPDATES INSIDE A LOOP:Replace Updates inside a loop with a single set
level process update to the Database outside of the loop. This will reduce the
trips to the Database and improve performance.
DATE FORMAT UNSUPPORTED: Do not reference unsupported date formats. The
only valid supported date formats are found in USR01-DATFM
DEAD CODE:Remove unused code unless it is required for
documentation.
DIRECT UPDATE TO SAP
TABLE:Under no circumstances should any program
directly update SAP delivered tables. Updating of SAP tables should be
performed using pre-delivered API's that perform the update.
DUPLICATE DEFINITION:Avoid Duplicate Definitions for all objects and
declarations. It is redundant, causes Maintenance issues, and possible
extraneous processing with unpredictable results.
DUPLICATE WHEN CONDITIONS:Never duplicate a WHEN condition. Unexpected program behavior could result with duplicated WHEN conditions.
DYNAMIC CALLS TO PROGRAMS:Dynamic Calls to programs can lead to production failures if program or object does not exist. Without proper exception handling, this is a dangerous practice.
DYNAMIC TABLE ACCESS:Always Include Exception Handling when accessing Tables Dynamically. Dynamic Calls can lead to production failures if the call cannot be resolved or object does not exist. Dynamic Table access can be a very a dangerous programming practice if proper exception handling is not in place.
EXCEPTION HANDLING
GENERIC
MESSAGE AFTER FUNCTION CALL:and could be caused by incorrect
implementations internal to the program or external interactions such as input
errors or unexpected resource limitations (E.g. files, memory).
All runtime errors (E.g. zero divide, conversion errors, …) raise class-based exceptions and should becaptured and handled in program code with the CATCH statement in a TRY/ENDTRY control block.
EXCEPTION HANDLING - USE CLASS BASED:Use Class Based Exception Handling Techniques. CATCH … ENDCATCH is obsolete.
Errors should be anticipated and handled in all program code. The nature of errors varies The generic message should only be used in the case where the function and all nested functions that are called use the Message ...Raising format consistently throughout the function chain. The Message...Raising format sets the sy-message and other sy variables. Only then, can you be assured that a generic message statement can be used to present a proper error message. However, since this situation is most likely not the case, a good developer will handle the message themselves and not count on the generic format to provide a meaningful message relevant to the situation.
EXCEPTION NOT PROCESSED:there may be cases where SAP delivered functions do not have defined exceptions. It is
EXTERNAL CALLS:External calls to subroutines are forbidden. In the case of short dumps, the ability to debug external calls is restricted and Production support therefore becomes more difficult.
EXTRACT FILES:
EXTRACT files are a convenient way of dealing with
internal tables of different structures that have same or similar keys. The
same can be achieved with internal tables. Only one EXTRACT file can be used
per program.
FIELD IS UNKNOWN:Only fields that are defined or in a specified table can be referenced. Any reference to fields that do not exist will cause syntax issues.
SELECT OPTION:The parameter / select-option in the SUBMIT
statement does not exist on the selection srceen of the called program. Verify
that the parameters and select options match between the SUBMIT statement and
the called program selection screen.
Exception: Excluded from this rule are system functions that don't return any exceptions, i.e. function module DEQUEUE. For these system functions that do not have defined exceptions, it does not make sense to check for SY-SUBRC after the function call.
HYPHEN DETECTED:Avoid the use of the hyphen in a declared variable name. It is normally used as a dereferencing operator.
IGNORED EXCEPTIONS CLAUSE:The EXCEPTIONS clause is ignored for asynchronous update function modules. Clean up the function by removing the superfluous Exceptions.
ILLEGAL NUMBER CONVERSION:Non numeric fields should not be converted into numbers. This could result in a run time error with a program dump.
ILLEGAL USE OF OFFSET:A length declaration is required when using offsets.
INCOMPATIBLE USING/CHANGING:The actual parameter category must match the formal parameter category. This means that if a parameter is passed as a USING, it should be received as a USING.
LIST PROCESSING
EVENTS:List Processing Event Blocks are obsolete. All
report programming should be performed using the ALV object model. Therefore,
any list processing events that are traditionally used for controlling lists in
classic programming are considered obsolete. This would include Top-of-Page,
End-of-Page, New-Page, at pf . Selection screen events are still used to
support selection screens.
DUPLICATE WHEN CONDITIONS:Never duplicate a WHEN condition. Unexpected program behavior could result with duplicated WHEN conditions.
DYNAMIC CALLS TO PROGRAMS:Dynamic Calls to programs can lead to production failures if program or object does not exist. Without proper exception handling, this is a dangerous practice.
DYNAMIC TABLE ACCESS:Always Include Exception Handling when accessing Tables Dynamically. Dynamic Calls can lead to production failures if the call cannot be resolved or object does not exist. Dynamic Table access can be a very a dangerous programming practice if proper exception handling is not in place.
EXCEPTION HANDLING
GENERIC
MESSAGE AFTER FUNCTION CALL:and could be caused by incorrect
implementations internal to the program or external interactions such as input
errors or unexpected resource limitations (E.g. files, memory).All runtime errors (E.g. zero divide, conversion errors, …) raise class-based exceptions and should becaptured and handled in program code with the CATCH statement in a TRY/ENDTRY control block.
EXCEPTION HANDLING - USE CLASS BASED:Use Class Based Exception Handling Techniques. CATCH … ENDCATCH is obsolete.
Errors should be anticipated and handled in all program code. The nature of errors varies The generic message should only be used in the case where the function and all nested functions that are called use the Message ...Raising format consistently throughout the function chain. The Message...Raising format sets the sy-message and other sy variables. Only then, can you be assured that a generic message statement can be used to present a proper error message. However, since this situation is most likely not the case, a good developer will handle the message themselves and not count on the generic format to provide a meaningful message relevant to the situation.
EXCEPTION NOT PROCESSED:there may be cases where SAP delivered functions do not have defined exceptions. It is
Still
recommended to provide exception handling when calling the function. This
enables that the code still works without a run-time error in the event that
SAP adds an exception to the Function Module interface. For example the
application of an OSS Note is able to introduce a new execption for the
function module. Setting all exceptions to 0 in the CALL FUNCTION statement is
not a good practice because it basically ignores the exceptions.
The programmer should always check the exception
returned from a function. DO NOT not count on an importing parameter being
returned to the calling program as a sign of successful execution. An
assumption holds true that a field is not set if an exception is returned, but
that could change during a future enhancement of the function. EXTERNAL CALLS:External calls to subroutines are forbidden. In the case of short dumps, the ability to debug external calls is restricted and Production support therefore becomes more difficult.
EXTRACT FILES:
Extract Files are considered
Obsolete. There is no need to use this old style array processing technique
|
FIELD IS UNKNOWN:Only fields that are defined or in a specified table can be referenced. Any reference to fields that do not exist will cause syntax issues.
FIELD NOT A PARAMETER Or
|
|
Exception: Excluded from this rule are system functions that don't return any exceptions, i.e. function module DEQUEUE. For these system functions that do not have defined exceptions, it does not make sense to check for SY-SUBRC after the function call.
Note: Customer defined functions should always have Exceptions defined.
Recommendation:
==> If a
function module has exceptions defined, you have to handle them. An empty IF
statement is not enough
==> If a
function module has no exception defined, CodeExcellends recommends using
EXCEPTION OTHERS = 1 and handle the exception
==> If a
function module has no exception defined, and the programmer is not using
EXCEPTION OTHERS = 1 you can't check sy-subrc after the function module call
since the sy-subrc will not be set by the function call
CUSTOMER DEFINED MACROS NOT RECOMMENDED:Operational issues in Macros that cause Program Dumps are difficult to trace. Wrap the reusable code in a method instead.
FIELD SYMBOL NOT
ASSIGNED:A field symbol was defined but not assigned. If
the field symbol is not used, then it should be removed.
FILE OPERATIONS - LOGICAL FILE NAMES:Use the logical file concept instead of hard coded physical file names.
The function FILE_ GET_NAME must be used to translate the logical file name to
the physical path and file name.
FUNCTION GROUP
INCONSISTENT:All components of a Function Group must pass
internal consistency check. If the consistency check error occurs, it is
possible that some internal objects have been corrupted. This can result in the
function module not being stored in the database table TFDIR or possibly stored
under a different name.
FUNCTION MODULE OBSOLETE:Using Obsolete Function Modules should be
avoided. It will cause upgrade issues as they are not forward compatible or
supported by SAP™.
FUNCTIONS WITHOUT EXCEPTIONS:When Calling a function, always include the
exceptions clause. There is no value in checking sy-subrc if the exceptions
clause is not part of the CALL Function statement. Don't add an empty IF
SY-SUBRC = 0 ... ENDIF block or a CHECK SY-SUBRC = 0 after a function call
without exceptions. A function should be defined with exceptions unless it is a
special purpose function such as update task, asynchronous, RFC, etc.
HARD CODING:When
the same text literal is used repeatedly in an arithmetic or logical
expression, define the value as a Constant instead of a text literal and name
the constant descriptively. This check determines if their is hard coding
contained in the following statements: SELECT, DELETE, SORT, LOOP, WHEN, IF,
READ.
Corporate
processes change. So do the business values used in daily operations. For
example, it is very common to experience changes to business config items such
as document types, org level definitions, cost centers, company codes, plants,
etc. Therefore it is highly recommended to avoid ‘Hard Coding’ of any business
values required in your program.
Where
possible, use existing SAP tables to provide business values to the program and
use a SELECT statement to retrieve those values into an internal table. If an
SAP table is not available with the required values, then it is advised to
build a custom Z* table to contain the required business values. There are
significant benefits to this approach when it comes to maintenance. When a
business value changes, then maintenance is performed on the custom table
(once) rather than all instances of programs that use the business values.
Customer defined business type tables should try to use data elements that are
already used in like fields in other SAP tables.
If the above approach is not followed and it is
decided to hard code business values in the program then at minimum, the hard
coded value should be defined as a constant and named descriptively.HYPHEN DETECTED:Avoid the use of the hyphen in a declared variable name. It is normally used as a dereferencing operator.
IGNORED EXCEPTIONS CLAUSE:The EXCEPTIONS clause is ignored for asynchronous update function modules. Clean up the function by removing the superfluous Exceptions.
ILLEGAL NUMBER CONVERSION:Non numeric fields should not be converted into numbers. This could result in a run time error with a program dump.
ILLEGAL USE OF OFFSET:A length declaration is required when using offsets.
INCOMPATIBLE USING/CHANGING:The actual parameter category must match the formal parameter category. This means that if a parameter is passed as a USING, it should be received as a USING.
INCOMPLETE ACCESS TO
INTERNAL TABLE:Avoid Indirect Index Access to an Internal
Table. All INSERT statements need to be either placed within a LOOP or use a
specific row INDEX. Duplicate records for an unique internal table index will
cause a program dump. For all internal table operations make sure the system is
clearly able to identify the internal table row where the change, delete or
insert needs to occur.
INCOMPLETE Or MISSING WHERE
CONDITION:Use a WHERE condition with appropriate indexes
where possible.
INCORRECT MESSAGE PARAMETERS:WITH fields must match placeholders defined for
the MESSAGE statement.
INCORRECT USE OF FOR ALL ENTRIES:When using the addition FOR ALL ENTRIES in ITAB,
the driver table ITAB and table fields must have the same type and length.
INEFFICIENT COPY (LARGE DATA OBJECT):Avoid poor performing assignment of large
amounts of data. This is especially critical in the case of deep structures or
large data elements.
INTERNAL TABLES - DELETE ADJACENT COMPARING:DELETE ADJACENT DUPLICATES should always be
explicit by using the COMPARING clause, even if there is only one field in the
ITAB.
INTERNAL TABLES - LOOP AND ASSIGN:Use LOOP AT ITAB and assign to a field symbol.
This technique improves performance on medium and large ITABs.
INTERNAL TABLES - MODIFY IN LOOP ASSIGN:When using LOOP AT … ASSIGNING, MODIFY and
UPDATE statements are redundant. The Assigning is a pointer. Any changes to the
row become explicit on the row being processed so there is no need to issue the
update or Modify commands.
INTERNAL TABLES - NESTED LOOPS:Nested Loops can cause inefficient processing
when programmed incorrectly. Use parallel cursor technique for nested loops
with standard tables. It is the most efficient means of processing Nested Loops.
The performance gains are significant.
INTERNAL TABLES -
SINGLE READ:DO NOT LOOP an itab to retrieve a specific
record when a single READ will do the job.
INTERNAL TABLES- TRANSPORTING:Use the TRANSPORTING clause with READ and MODIFY
wherever possible to transport only the fields necessary.
INTERNAL TABLES SORT BY BREAK LEVEL FIELDS:FOR BREAK LEVEL processing with the AT command
inside a LOOP at ITAB, sort by the break level fields before entering the LOOP.
INTERNAL TABLES SORTING:When sorting internal tables, always be explicit
by using "SORT BY key1 … keyn", never just "SORT" on its
own.
INTERNAL TABLES WITH
HEADER:Avoid any syntax that results in obsolete tables
with headers such as OCCURS 0 or With Header Line or Perform Tables.
INTERNAL TABLES WITH HEADER IN FORM:Do not use TABLES statement when passing internal tables to FORMS. This
will result in an internal table with Header being created local to the form.
ITABS with header are obsolete.
INTERRUPT COMMANDS:RETURN
Statement should be used to exit a procedure (FORM, FMOD, and METHOD).
EXIT should
not be used.
If a conditional statement (i.e LOOP, IF, etc. ) is in the procedure,
the programmer can code either EXIT or RETURN depending on the desired exit
scenario i.e. is the intent to leave the conditional block or to exit the
procedure
INVALID PROGRAM TYPE FOR INCLUDE:Include program type attribute must be correctly
set to indicate it is an Include.
INVALID SLIN PSEUDOCOMMENT:Use valid PSEUDOCOMMENTS as defined by SAP when
marking code for inspection bypass.
INVALID VALUE
SPECIFICATION:Use valid VALUE specifications for a FIELD.
IS ASSIGNED:IS ASSIGNED check should be issued prior to a
field symbol assignment in the Read TABLE statement. If the field symbol is
referenced and has not yet been assigned, a short dump will occur.
ITAB MODIFY INDEX IN
LOOP:Avoid
LOOP at ITAB and then modifying by index in the loop. This can lead to
unpredictable results and performance costs.
Avoid inserting new lines while looping over an
internal table. Instead, add new lines inside the LOOP using the APPEND
statement to add the new line at the end of the internal table.
ITAB OVERWRITE IN
LOOP:During LOOP Processing of an internal table, do
not delete or overwrite the table that is being Looped.
KEY NOT SPECIFIED IN A BUFFERED TABLE :Use keys in tables to avoid bypassing the
buffered table. In the case of Generically Buffered Key Area, specify all keys
that are part of the generic buffered area as defined in the technical setting
of the table.
LOGICAL OPERATORS INSTEAD OF WORDS:Use operators
( >=, <=, =, <>, >, <) rather than the obsolete words GE, LE,
EQ, NE, GT,LT.
LOOP IN
SELECT/ENDSELECT:Avoid LOOP/ENDLOOP blocks within
SELECT...ENDSELECT statements. They are very performance expensive.
MAINTAIN TEXT
ELEMENTS:TEXT Element is not defined in text pool in the
original language.
MESSAGE TRUNCATED:Message parameter should not exceed field length
specification. SAP only provides a maximum length of 50 characters for any
message parameter (SYST-MSGV1-MSGV4). Please make sure that all fields and
texts that are passed into a message variable are no longer than 50 characters.
METHODS FOR MODULARIZATION:For Modularization and re-usability, always use methods as your first choice over FORMS (subroutines) and function Modules. In OO context, FORM...ENDFORM is considered obsolete.
METHODS FOR MODULARIZATION:For Modularization and re-usability, always use methods as your first choice over FORMS (subroutines) and function Modules. In OO context, FORM...ENDFORM is considered obsolete.
MISSING CRITICAL PROGRAM ELEMENT:Critical Program Elements are missing and
therefore the program cannot compile. (This includes sub objects such as
screens, tables, Includes, forms, parameters, etc.). All referenced components
must exist.
MISSING MANDATORY PARAMETER IN FUNCTION CALL:All mandatory parameters must be specified when
calling a function.
MOVE TO INSTEAD OF WRITE
TO:Use MOVE TO instead of WRITE TO when possible.
NATIVE SQL:Avoid using native SQL to ensure database
independence and avoid incompatibilities between different database tables.
NESTED LOOP:Nested loops can cause performance issues. This
applies to any form of Nested Loop i.e. WHILE or DO inside of a Loop or a LOOP
inside of WHILE or DO. In the case of a Loop within a Loop, explore the
possibility of using a Parallel cursor technique where checks are in place to
ensure that the inner loop record exists using READ and uses EXIT to exit inner
loop when keys are different. With large tables, the performance gains are
significant.
NO READ ACCESS TO
FIELD:Validate that the FIELDS are used in the
program. It is posible that it is referenced indirectly such as parameter
passing to a procdure. If the field is not used anywhere, remove unreferenced
fields from the program.
NO WHERE CONDITION IN A LARGE TABLE:Where statements should always include index
fields for performance reasons, especially for LARGE tables.
OBJECT UNREFERENCED
Or UNUSED:Remove all program elements that are unused or
unreferenced.
OBSOLETE ABAP:Avoid the use of obsolete ABAP statements.
OFFSETS AND SUBSCRIPTING:Avoid code that uses specific offsets for the
purpose of subscripting into parts of a structure. Offset coding is problematic
when coding in a UNICODE environment since characters are not represented by a
single byte and can therefore lead to incorrect data sub stringing. Offset
coding is also very problematic when dealing with dates where users are able to
change their date format.
ON CHANGE OF IN LOOPS:Avoid using ON CHANGE OF statement for Break level processing.
Unpredictable results can occur with ON CHANGE OF because it is specific to a
single field whereas the AT... ENDAT triggers a break when any change occurs in
the field specified or fields left of the specified field.
OPEN DATASET with
ENCODING:
The
ENCODING option determines the character representation of the content of the
file. At minimum, you must specify the encoding option DEFAULT or UTF-8.
When Opening a Dataset for Output in Text Mode, the file should be
Opened with the
Encoding Option UTF-8 and With Byte Order Mark(BOM). This will
create a proper Unicode non platform dependant file with a BOM, consisting of
3 bytes at the beginning of the file that identifes the file as UTF-8
When opening a Unicode File (UTF-8) for
Input, specify the addition SKIPPING BYTEORDER MARK so that the BOM is
skipped and NOT considered part of the file content.
|
OPEN DATASET with
MESSAGE:Authorization and permission access at the OS level is one of the most
frequent causes of an OPEN statement failing. Always Use the Message clause on the OPEN
statement to trap operating system errors. This approach traps the Operating
System error and therefore goes beyond the standard subrc checking. Subrc only
tells if the operation was successful but does not give the speicfic reason why
the operation failed. The Message Clause reports specific application server
errors such as permissions, file existence, etc.
OUTPUT POSITION 0 NOT ALLOWED:Avoid using output position 0.
OVER RIDE VIOLATIONS:Used to bypass detected rule violations due to
technical reasons.
PARAMETER PASSING BY
REFERENCE:As
a general rule, PASS BY REFERENCE should be used where possible for performance
reasons. This test examines whether it is possible to improve the performance
of a parameter transfer for a method, form, function module, or event. However,
there are programmatic reasons for using by VALUE. i.e. in the case of a
RETURNING parameters, it is always by VALUE. Specifically, the test checks for
the following situations:
•
The
type of the VALUE parameter contains tables whose row type in turn contains
internal tables.
• The type of the VALUE parameter
contains tables with different row types.
• The type of the VALUE parameter
contains strings, but no tables.
• The parameter type is a flat field
with a length > 100 bytes/characters.
The type of the VALUE input parameter is a flat field
with a length <= the parameter.
PARAMETER PASSING IN
FORMS:Define USING parameters by VALUE. Define
CHANGING and Internal Tables by REFERENCE.
PARAMETER Untyped:All parameters must be typed to enable static
type checks. If a type cannot be declared, use the type ANY.
PARAMETERS - USING DOES NOT MATCH CHANGING:USING parameters must match CHANGING parameters.
POSSIBLE LOSS OF DB
CURSOR:The database cursor may be lost as a result of
certain call sequences that contain COMMIT. For example, a Commit work or
PERFORM inside a SELECT…ENDSELECT is problematic.
POSSIBLE SEQUENTIAL ACCESS ON AN INTERNAL TABLE:Avoid
sequential access on internal tables. On large tables, this can be costly. A
sequential access will happen if internal tables have incomplete keys or in the
case of standard tables, Binary Search clause is missing. For internal tables
avoid using the obsolete version of READ TABLE ... WITH KEY. Instead specify an
appropriate UNIQUE or NONUNIQUE INDEX as part of the internal type definition
and use READ TABLE ... WITH TABLE KEY. Note: The addition BINARY SEARCH is
still required to avoid sequential reads when using STANDARD tables.
PRIMARY KEY FIELDS NOT FULLY SPECIFIED:Always specify the fields of a primary key in a
single record buffered table.
PROBLEM WITH INDEX ACCESS TO INTERNAL TABLE:When using Non-Numeric Index Value to delete
rows from an internal table, use the format 'DELETE ITAB FROM work areas'.
RAISE FOR EXCEPTION
MISSING:An EXCEPTION that is part of the exception group
never gets raised. This exception should be removed from the exception group if
it is never used.
RAISE ONLY IN FUNCTION
GROUPS:RAISE statements should only be used in FUNCTION
groups.
SECONDARY INDEX IN A CLIENT SPECIFIC TABLE WITHOUT CLIENT FIELD:Secondary indexes for CLIENT SPECIFIC tables
should have client as the first field of the secondary index.
SELECT FOR ALL ENTRIES:
Any further filtering can be done using ABAP Memory.
SELECT FOR ALL ENTRIES:
When using "Select... For all Entries" the
following rules MUST be followed:
• Check to make sure driver ITAB is
not empty • Always SORT the ITAB (driver table) by keys.
•
Specify
all keys used in the WHERE clause.
•
DELETE
Adjacent Duplicates Comparing the keys that were sorted.
•
All
Primary Key Fields must be in the Select List.
•
The
WHERE clause must include INDEX fields to make use of index scan.
•
If
index fields are not available as part of the WHERE clause, then it is better
not to use FOR ALL ENTRIES. The better option would be a SELECT…WHERE into an
ITAB.
|
SELECT INTO CORRESPONDING:Avoid the use of SELECT ... INTO CORRESPONDING
especially for tables with a large Number
of fields. The CORRESPONDING clause results in DB overhead. The corresponding
target fields are not know until runtime and therefore need to be rebuilt at
execution. The has a negative effect on performance.
SELECT SINGLE EXPECTED FOR SINGLE RECORD BUFFERED TABLE:Use SELECT SINGLE with full key when accessing
Single Record Buffered Table or buffer will be bypassed.
SELECT WITH A SUBSEQUENT CHECK:Avoid the use of CHECK statements after a
SELECT. Instead use a WHERE statement to filter the data.
SELECT WITH AGGREGATE FUNCTION ON BUFFERED TABLE:Use aggregate functions with caution in a
buffered table. Aggregate functions will cause the buffer to be bypassed which
leads to increased processing to retrieve data from DB instead of buffer.
SELECTION SCREEN
FIELDS:The purpose of a selection screen is to provide
the user with flexible options to enter values that will influence the outcome
of the program execution. Create variants, where possible, and have the user
community use the variant to set screen default values. Exceptions to this rule
are non-business technical related parameters i.e. Logical File Names, etc.
SELECTION TEXT NOT
MAINTAINED:Be sure to maintain the Selection text
for all selection fields and parameters. In multilingual systems the DDIC
reference flag should be set wherever possible to leverage existing
SELECTION TEXT WITHOUT SELECTION FIELD:Selection Texts that are defined but not used or
referenced on a selection screen should be removed from the text element list.
SINGLE PERIOD LINE:Eliminate lines of code that contain a single
period.
STANDARD INTERNAL TABLE PROCESSING:When
Processing a Standard Internal Table:
• Always use the Binary Search option
i.e. READ ITAB with KEY Binary Search.
• READ the Internal Table by Keys
Be sure that table is sorted by same key that is used
in the READ WITH KEY statement (or data will be missed).
STATEMENT UNREACHABLE:Unreachable
statements have been detected. i.e. after Jump statement such as RAISE:
STRUCTURES OBSOLETE:Use type statement to build local structures.
Structure statement is obsolete.
SUPPRESSED RULE:SUPPRESSED RULE
SUSPICIOUS ERROR:NEEDS FURTHER INVESTIGATION
SYSTEM CALL:Never make calls directly to System Functions
for production programs. System Calls and functions are reserved exclusively
for SAP™ use.
SYSTEM FIELDS FLAGGED
OBSOLETE:Never Use obsolete system fields. Check
Dictionary structure SYST. The data element description indicates which fields
are flagged as obsolete.
SYSTEM FIELDS PASSING
& UPDATING:Never update
system fields or pass system fields to Procedures (FORMS, METHODS,
SY-SUBRC NOT HANDLED:Always Check Return Code SY-SUBRC after critical
operations – SQL, ITAB Operations, Function Calls, etc.
TEXT ELEMENT IN POOL
NOT USED:TEXT ELEMENT from text pool in program is not
used.
TEXT ELEMENT
INCONSISTENT:Text Element is defined differently in the
program and the text pool.
TEXT ELEMENT MISSING:Char. strings without text elements cannot be translated in a multi-lingual environment.
TEXT ELEMENT MISSING:Char. strings without text elements cannot be translated in a multi-lingual environment.
TEXT LITERAL SHOULD BE NUMERIC:It is more efficient to use numeric literals
directly. Text literal must be converted to a numeric literal.
TRANSPORTING NO
FIELDS:It does not make sense to use TRANSPORTING NO
FIELDS if the fields need to be referenced.
UNCOMPILABLE CODE:Use the Code Inspector to eliminate all SYNTAX
errors, including syntax warnings.
UNDEFINED INTO FIELD:Into LISTS must be of the form (f1...fn) with
all fields defined.
UNDEFINED TITLE:TITLEBARS should have a title defined.
UNDESIRABLE LANGUAGE ELEMENTS:A
number of ABAP statements are no longer compatible with the latest SAP
technologies. These statements still work in a SAP GUI transaction environment
but have been replaced by newer much more efficient and flexible solutions.
Programming syntax that is considered problematic are as follows:
• ABAP list processing statements like
WRITE, FORMAT, SKIP, NEW-LINE etc. in programs should instead using ABAP List
Viewer classes for list display functions.
• The use of CALL TRANSACTION USING to
submit a BDC. This technology relies on screen layouts. If a screen layout
changes, the code stops working. This makes the code highly unreliable during
the application of Support Packs, Enhancement Packs and Upgrades. Therefore
programs need to use BAPIs to submit business functions.
• Submitting database operations
directly from ABAP by calling database functions directly (e.g.
'DB_COMMIT"). Any use of these functions introduces a high risk of
transaction inconsistencies and needs to be avoided. Similarly, programs need
to avoid direct access to data dictionary function modules changing the databse
tables, e.g. DD_CREATE_TABLE.
• Programs need to avoid using position
operations in sequential files. If necessary files should be processed
sequentially instead of controlling the read position (SET DATASET, GET
DATASET, TRUNCATE DATASET).
• Database SELECTs need to avoid
retrieving a single line for Update. This operation includes an implicit
database lock quickly leading to bottenecks and deadlocks. Instead use ENQUEUE
functions to lock an object in SAP, read it and subsequently update it.
• Avoid using SELECT.. BYPASSING
BUFFER.. Since this access avoids using the database cache causing performance
issues and inconsistencies.
Avoid using native SQL to ensure database independence
and avoid incompatibilities between different database tables.
UNICODE FLAG NOT SET:All programs in a Unicode system must have the
UNICODE flag set ON. If the flag is not set in a Unicode system the program
dumps with a syntax error. The Unicode flag can only be set once the program
passes the Unicode syntax check (transaction UCCHECK). In a non-Unicode system
the flag does not have to be set, but as of ERP 6.0 SAP only supports single
code page non-Unicode ERP system. Any multi code page system has to be Unicode.
Therefore it's generally better to always turn this flag on.
UNIT CLAUSE:When outputting numbers that are tied to units
of measure, always use the UNIT formatting option. This will set the number of
decimals according to the unit of measure being output.
UPDATING and PASSING GLOBAL
FIELDS:Avoid
the declaration of global variables as much as possible. Avoid passsing Globals
to Subroutines and Methods.
USER SPECIFIC CONTROL:Avoid using references to specific USERS or
USERIDs for any reason.
VALUE ASSIGNMENT EXCEEDS
|
VARIABLE NAME INCORRECT:Variable names should not begin with %_*. Prefix
%_* is reserved for internal names.
NAMING STANDARDS
1. Program names may be between 5 and
40 characters in length. Program names
will be composed of the following subfields:
a. Z —
all programs must begin with the letter “Z”.
b. XX — where XX is the SAP module. Current SAP modules include:
1. AM Asset
Management
2. BC Basis
Component
3. BG UM
Budget Preparation System
4. BI Business
Intelligence
5. CO Controlling
6. CM Student
Lifecycle Management
7. EP Enterprise
Portal
8. FA Financial
Aid
9. FI Financials
10. FM Funds
Management
11. HR Human
Resources
12. MB Mobius
13. MM Materials
Management
14. PM Plant
Maintenance
15. SE Staff
Evaluations
16. TR Travel
Management
17. UM global
to all modules
18. other
modules as designated or added to the system
c. “_” —
separate the prefix from the remaining program name by an underscore “_”.
d. If
the program is for use by UMMC only, characters 5-10 must include “UMMC_”.
e. The
remaining 31-36 characters may be as descriptive as you wish.
PROGRAM
STANDARDS
TRANSACTION STANDARDS
1.
Reports
2.
Dialog Programs
CODING
STANDARDS
1.
Formatting
2.
One command per line
3.
Indented source code
4.
Variable naming
5.
Reusable code
6.
Parameter passing in subroutine
7.
Text handling
8.
Usage of UserIDs in programs
9.
Messages
10.
Development Class
11.
Source Code Documentation
12.
Function Modules
PERFORMANCE STANDARDS
1.
General Performance Standards
append .
= .
[] = []. (if is empty) Instead of this:
2.
Performance Checking
DICTIONARY:
TABLE STANDARDS
1.
User-developed table naming convention
2.
User-developed table definition convention
3.
Maintenance settings
Updates: Direct database updates of SAP standard
tables
RULES
STANDARDS
3. Validations
and Substitutions
4. Rule Modules
5. Rule Containter
TRANSPORTING
STANDARDS
1.
Communication
2.
Transports
3.
Re-imports
4.
Critical Imports
TESTING
STANDARDS
1.
Internal testing
2.
Return Codes
3.
Performance analysis
4.
Requestor Review
AUTHORIZATIONS
STANDARDS
REFERENCES
f. When
writing a temporary or training program, please use the prefix “ZTST_XX_” for
the beginning of your program name. This
will indicate that this program should not be used on a regular basis in the
production environment.
PROGRAM
STANDARDS
1. A
template program ZTEMPLATE in client
110 has been provided for your convenience.
Please be careful not to update this program directly. Copy it to your new program name, and then
modify your program. Be sure to change
the “Title” field on the attribute page of your program to reflect a
description of what your program does.
2. All
programs should include a comment box at the beginning of the program listing
the following information (see ZTEMPLATE):
a. Program
name
b. Author
c. Date
written
d. Description
of the program. Be sure to list any
special considerations and/or situations.
List any tables being used, with a brief description of the table.
e. All
modifications to the program should also be documented in this area. (See
Coding Standards: Source Code Document for more information.
3. Use
descriptive data and paragraph names. Do
NOT use a hyphen “-“ in variable
names or in paragraph (“form”) names.
Use the underscore “_” instead.
SAP uses the hyphen “-“ to separate a table name from the field name in
the table. Using an underscore will
increase readability of your program.
4. Group
parameters and select-options together.
Group table names together. All
data items should be at the beginning of the program before any event logic.
a. Names
of parameters and select-options are limited to 8 characters.
b. Table
names are limited to 16 characters.
5. Event
paragraphs should be listed in a logical order inside of a START-OF-SELECTION
…END-OF-SELECTION section.
6. Use
indentation to make the reading of your program easier. This is automatically
set when you use Pretty Printer (see Code Standard: Formatting).
7. Screen
frame titles should be constructed using standard Title Case.
8. All
emails generated from SAP programs should use proper grammar and punctuation
and appropriate line-wrapping.
DIALOG
PROGRAM STANDARDS
1.
Module Pool
2.
Screens
3.
GUI Status
4.
Miscellaneous
DIALOG
PROGRAM STANDARDS
1.
Module Pool
a. Transactions
are maintained using SAP transaction SE38 (ABAP Editor).
b. Naming
convention – SAPMZXX_
c. Naming
convention for includes
i.
MZXX_...TOP – Global data
ii.
MZXX_...O01 – PBO modules
iii. MZXX_...I01
– PAI modules
iv. MZXX_...F01
– Form routines
2.
Screens
a. Transactions are maintained using
SAP transaction SE51 (Screen Painter).
3.
GUI Status
a. Standard menu bar, application
toolbar and standard toolbar are maintained using SAP transaction SE41 (Menu
Painter).
4.
Miscellaneous
a. Initialize
all screen fields and global variables in the PBO (Process before Output)
module.
b. PAI
(Process after Input) should contain the logic to be executed after the user
has selected a function key, menu item, etc.
c. POV
(Process on Value-Request) should contain logic to display list of possible
values on F4 request.
d. POH
(Process on Help-Request) should contain logic to display help information on
F1 request.
TRANSACTION STANDARDS
Transactions are maintained using SAP transaction SE93 (Maintain
Transactions).
User must select the appropriate “Start object“ on the
first “Transaction Creation Screen”. Depending on the underlying associated
object (e.g.: Reports or Dialog Programs) user selects the appropriate Start
object type.
The following two sections describe the Transaction
standards for Start object: Reports and Dialog Programs respectively:
1.
Reports
a. Transaction
Code name can be up to 20 characters.
The standard naming convention (ZXX_) should be used (see Naming
Standards).
b. The
standard package is always ZDEV for UM clients only.
c. GUI
Support – select all (HTML, Java, and Windows).
2.
Dialog Programs
a. Transaction
Code name can be up to 20 characters.
The standard naming convention (ZXX_) should be used (see Naming
Standards).
b. The
standard package is always ZDEV for UM clients only.
c. GUI
Support – select all (HTML, Java, and Windows).
CODING
STANDARDS
1.
Formatting
a. Standardize formatting should be
used to format all programs, function modules, etc.
To setup, select ‘Setting’ under the ‘Utilities’ option on
the SAP toolbar. Select ‘ABAP Editor’ option.
Within this option, select ‘Pretty Printer’. Check the following options:
i.
Indent
ii.
Convert Uppercase/lowercase
iii. Keyword
Uppercase
2.
One command per line
a. Each ABAP/4 command consists of a
sentence ending with a period. As a
standard, start each new command on a new line. This will allow for easier
deleting, commenting, and debugging.
3.
Indented source code
a. For command statements that have a
corresponding “END” (such as IF…ENDIF, SELECT…ENDSELECT, LOOP…ENDLOOP), the
“END” part of the statement
should be placed in the same
column as the beginning part of the statement.
It is helpful to also comment the “END” statement by using the “
parameter on the same line. For
example, LOOP at ITAB.
…….. statements here
ENDLOOP
“ ITAB table
4.
Variable naming
a. ABAP/4
variable names can be up to 30 characters for DATA fields and subroutines and
up to 8 characters for SELECT-OPTIONS
and PARAMETERS, therefore, as a standard, make the names descriptive. Do NOT
use a hyphen “-“ in variable names or in paragraph (“form”) names. Use the underscore “_” instead. SAP uses the hyphen “-“ to separate a table
name from the name of a field in that table.
Using an underscore will increase readability of your program.
b. Some
variable types should be prefixed with a specified letter or letters:
Variable Type
|
Prefix
|
Selection
screen parameter
|
p_ or a_
|
Form
routing parameter
|
p_
|
Select-options
|
s_
|
Ranges
|
r_
|
Internal
tables (global)
|
t_ or gt_
|
Internal
tables (local)
|
lt_
|
Local
structures
|
ls_
|
Global
structures
|
gs_
|
Constants
|
c_
or lc
|
Global
constants
|
gc_
|
Local
variables
|
lv_
|
Global
variables
|
gv_
|
c. Whenever
possible, the LIKE parameter should be used to define the type of a variable.
d. Whenever
possible, global constants should be used instead of creating local constants
or hard-coded values. For function
modules and dialog programs, global constants should be stored in the
“MZXX_...TOP” section of the function module group.
5.
Reusable code
a. If a block of code is executed more
than once, it should be placed in a subroutine at the bottom of the code or in
a function module. This makes the code more readable, requires less
indentation, and is easier to debug.
6.
Parameter passing in subroutine
a. Whenever possible use a TYPE or LIKE
statement when specifying the formal parameters of a subroutine. This is a good programming style, plus it
allows the ABAP compiler to generate more efficient code (which can increase
performance up to a factor of 2x).
7.
Text handling
a. Variable
names should not be used on the parameter selection screen for any program
placed in production. Use the “Text
Element” function found in the ABAP editor to describe the selection criteria
and relate it to the variable name.
b. INCLUDE
files can't define their own Text Elements - any Text Elements to which they
refer must be defined in the main program which invokes the INCLUDE file. TIP:
You can use the INITIALIZATION event of the “include” program to set the
values of these text elements.
8.
Usage of UserIDs in programs
a. In no case should a production
program or function contain a UserID as either literal or constant data. In the
development system it may be necessary to code temporary breakpoints for
specific UserIDs, however, these debugging techniques must be removed before
the program is transported.
9.
Messages
a. Declare
the message class in the report statement. While it is possible to specify the
message class each time a message is output, it is easier to specify once it in
the report statement. You can still use a message from another class than the
one defined in the report by adding the class in parentheses after the
message. Messages can be defined using
SAP transaction SE91 (Message Maintenance: Initial Screen).
b. Messages
should use proper grammar and punctuation.
10.
Development Class
a. The development class of any program,
table, function, etc., should be ZDEV for
UM clients only. If a special
development class is required, authorization must be request from BASIS (see
Authorization Standards for more information).
11.
Source Code Documentation
a. It
is wise to provide future programmers with documentation inside your source
code. Explain the purpose, design, structure and any testing hints at the top
of the program.
b. All
programs should also have a modification log displayed at the top of the
program. This log should the initials of
the developer making the change, the date of the change, and a description of
the change. The log should be dated
with the most recent change first. For
example:
a. Comment
work fields, and fields in work records especially those used for interfacing.
Comments should explain what the code is doing.
b. Comments
should be included before each “form” subroutine to briefly describe what the
subroutine is to accomplish. Comments
should also be placed before SAP events.
These comments help to pinpoint the beginning of events and subroutines,
and help direct the flow of logic.
a. It
is also helpful to include comments for each block of code designed to
accomplish a task. For example:
12.
Function Modules
a. The
standard naming convention (ZXX_) should be used for naming Function Modules
and Function Groups (see Naming Standards).
b. The
import and export parameters of function modules should be documented at the
top of the source code section of the function module with brief descriptions
of the fields and their typical contents. Also, any special requirements or
usage should be noted.
c. The
first letter of the parameter’s name should indicate the direction in which the
parameter was passed:
Input or importing = I
Output or exporting = E
Bi-directional or changing = C
d. The
second letter of the parameter’s name should indicate the nature of the formal
parameter:
Single value or variable = V
Single structure or record (however complicated) = S
Internal table (however complicated the line structure) =
T
e. Function
modules that contain database reads should also contain at least one EXCEPTION
parameter.
f. All
RFCs (Remote Function Call) must contain at
least one EXCEPTION parameter.
PERFORMANCE STANDARDS
1.
General Performance Standards
a. "Dead"
code - (Avoid leaving "dead" code in the program. Comment out (or
delete) variables that are not referenced and code that is not executed. Use
program --> check --> extended program to check to see a list of
variables which are not referenced statically.
a. Logical
databases - Most SAP modules have logical databases that are available for your
use. However, it has been found that
unless you are using a lot of the data from the logical databases, the runtime
of the program using a logical database is greatly increased from one directly
accessing a database table using a “SELECT” statement.
b. Subroutine
usage - For good modularization, the decision of whether or not to execute a
subroutine should be made before the subroutine is called. For example:
This is better:
IF
f1 NE 0.
PERFORM sub1.
ENDIF.
FORM
sub1.
... ENDFORM.
Than this:
PERFORM
sub1.
FORM
sub1.
IF f1 NE 0.
...
ENDIF.
ENDFORM.
d. IF
statements - When coding IF tests, nest the testing conditions so that the
outer conditions are those which are most likely to fail. For logical
expressions with AND, place the mostly likely false first and for the OR, place
the mostly likely true first.
e. CASE
vs. nested Ifs - When testing fields "equal to" something, one can
use either the nested IF or the CASE statement. The CASE is generally better
because it is easier to read.
f. MOVE-ing
structures - When records a and b have the exact same structure, it is more
efficient to MOVE a TO b than to MOVE-CORRESPONDING a TO b.
g. SELECT
– Direct SELECT statements should only be used if the data can not be accessed
using a function module or an evaluation path.
When possible the SELECT statements should be stored in a function
module.
h. SELECT
and SELECT SINGLE - When using the SELECT statement, study the key and always
provide as much of the left-most part of the key as possible. If the entire key
can be qualified, code a SELECT SINGLE not just a SELECT. If you are only interested in the first row
or there is only one row to be returned, using SELECT SINGLE can increase
performance by up to 3x.
i.
Check each SELECT statement for the use of index. This can be most easily
determined using the Code Inspector, transaction SCI, which will report on any SELECT statement against large tables
not using an index.
j.
Check that there is no assumed sort order
after the SELECT statement. Do not
assume that the data will be returned in primary key order.
k. SELECT * versus SELECTing individual fields -
In general, use a SELECT statement specifying a list of fields instead of a
SELECT * to reduce network traffic and improve performance. For tables with only a few fields the
improvements may be minor, but many SAP tables contain more than 50 fields when
the program needs only a few. In the
latter case, the performance gains can be substantial.
l.
SELECT
– Direct SELECT statements should only be used if the data can not be accessed
using a function module or an evaluation path.
When possible the SELECT statements should be stored in a function
module.
m. Small internal tables vs. complete internal
tables - In general it is better to minimize the number of fields declared
in an internal table. While it may be
convenient to
declare an internal table using the LIKE command, in most
cases, programs will not use all fields in the SAP standard table.
n. Refreshing internal tables – When you
are done working with an internal table REFRESH the table to release it from
memory.
o. Row-level processing of a table -
Selecting data into an internal table using an array fetch versus a
SELECT-ENDELECT loop will give at least a 2x performance improvement. After the data has been put into the internal
data, then row-level
processing
can be done. For example, use:
select ... from table <..> into
(corresponding fields of itab) where ...
loop at
endloop.
instead of using:
select
... from table <..> where ...
endselect.
p. READing single records of internal tables
– When reading a single record in an internal table, the READ TABLE WITH KEY is
not a direct READ. This means that if
the data is not sorted according to the key, the system must sequentially read
the table. Therefore, you should SORT
the table and use READ TABLE WITH KEY BINARY SEARCH for better performance.
q. SORTing internal tables - When SORTing
internal tables, specify the fields to be SORTed.
r. Deleting duplicates – After sorting
internal tables, remember to use the command “DELETE ADJACENT DUPLICATES FROM” to
remove duplicate records.
s. Number of entries in an internal table -
To find out how many entries are in an internal table use DESCRIBE.
t.
Length
of a field - To find out the length
of a field use the string length function.
LV_FLDLEN = STRLEN (FLD).
u. Nested SELECTs versus table views - Since OPEN SQL does not allow table joins,
often a nested SELECT loop will be used to accomplish the same concept. However, the performance of nested SELECT
loops is very poor in comparison to a join.
Hence, to improve performance by a factor of 25x and reduce network
load, you should create a view in the data dictionary, then use this view to
select data.
v. If nested SELECTs must be used - As
mentioned previously, performance can be dramatically improved by using views
instead of nested SELECTs, however, if this is not possible, then the following
example of using an internal table in a nested SELECT can also improve
performance by a factor of 5x:
Use this:
form select_good.
data: t_vbak like vbak occurs 0 with header
line.
data: t_vbap like vbap occurs 0 with
header line.
select * from vbak into table t_vbak
up to 200 rows.
select * from vbap for all entries in
t_vbak
where vbeln =
t_vbak-vbeln.
... endselect.
endform. Instead of this:
form select_bad.
select * from vbak up to 200 rows.
select * from vbap where vbeln =
vbak-vbeln.
...
endselect.
endselect. endform.
w. Avoid unnecessary statements - There are
a few cases where one command is better than two. For example:
Use: append to .
Instead of:
append (modify ).
And also, use:
if not [] is initial.
Instead of:
describe table lines . if
> 0.
x. Copying or appending internal tables ⎯ Use this:
loop at .
append to .
endloop.
y. Clear vs Refresh – Use the CLEAR
statement to initialize local variables and local structures. Use the REFRESH
statement to initialize local tables. If
the table has a header row, use “REFRESH lt_table[]” to clear both the table
and the header row. Don’t forget to
re-initialize local variable and table before each re-use.
z. Report display – Make sure the case matches
throughout the report. Do not mix all
upper-case displays with all lower-case displays. Ex:
Do not display:
SHIELA
LONG, academic administrator, school of education
Instead use:
Sheila
Long, Academic Administrator, School of Education
System fields – ABAP automatically stores
information necessary to control the program’s internal flow of logic in some
system fields and tables. These fields
and tables are accessible by the programmer.
It is better to use a system field than to create logic to generate the
same data (i.e. current time, current date, table index, etc.). A list of system fields and system tables can
be found in The Official ABAP Reference
2.
Performance Checking
a. Performance diagnosis ⎯ SAP transaction SE30 (ABAP/4 Runtime
Analysis) must be ran on all new programs before they are put into
production. This utility allows
statistical analysis of transactions and programs.
b. Error checking – Use the SAP transaction
SCI (Code Inspector) to spot meaningful error; however, the developer will
still need to use judgment to filter out meaningless errors.
DICTIONARY:
TABLE STANDARDS
1.
User-developed table naming convention
a. Table names are limited to 16
characters. Follow the naming convention
for programs as far as the first 3 to 4 characters are concerned (ex. ZFPM, ZAM, ZFI).
2.
User-developed table definition convention
a. The
first field defined for any customer table should be: MANDT. This is the
'client' field, and makes the table specific to the client that it is
used/modified in.
b. Field
names do not have to begin with ‘Z’; however, the field name should be
descriptive.
3.
Maintenance settings
a. "Tab. Maint. Allowed" 'X' or (blank)
i. An 'X' indicates that this table is to
be maintained directly using the "Standard Table Maintenance"
functions (SM31 / SM30). This means that the table can be maintained
independently of any other table or application. This should only be used for
tables that have a relatively low number of updates, done on an infrequent
basis. Tables that are maintained this way are typically used to set control
information, or similar table values that change infrequently, but will change.
Examples are tax rates, overhead rates, program control tables, message tables,
program or error status tables, etc. ii. Tables maintained this way should NOT
have any dependency on other tables or other entries in the same table for the
validity of a new entry or new value, unless that dependency can be validated
through the use of a check table for the field.
iii. X should be selected ONLY if the table
is to be maintained by the "Standard Table Maintenance" functions.
(SM30 or SM31) Any table for which entries are maintained / changed / inserted
/ deleted by an application should in most
cases not have this field checked.
Updates: Direct database updates of SAP standard
tables
Under no circumstances should any
program directly update SAP-delivered tables using the
INSERT, UPDATE, or DELETE
commands. SAP-delivered tables begin with all letters other than Y and Z, and
they should only be updated using an SAP transaction. To automate updates to
SAP tables via a program, you can use an SAP supplied function module.
RULES
STANDARDS
1. Each
University should have their own instance of programs ZGBBR000 and ZGBBS000,
and VSR.
2. Exit names (in ZGBBR000 or ZGBBS000)
a. Limited
to 5 characters.
b. They
should all begin with “U”.
3. Validations
and Substitutions
a. Limited
to 7 characters.
b. Uses
exit: same name as Exit
i.
Info-only (footnote): IMSG001-IMSG999
a. Program-type
related: Begin with 1st character of program-type
i.
Uxxxxxx (UMAXHRS for Undergraduate Maximum
Hours)
ii.
Lxxxxxx (LMAXHRS for Law Maximum Hours)
iii.
Gxxxxxx (GMINHRS for Graduate Minimum Hours)
a. School
related: Begin with 1st three
characters associated with school
i.
LAxxxxx ( Liberal Arts) ii. BUSxxxx
(School of Business) iii. ENGxxxx (School of Engineering)
a. Department
related: Begin with Department/Course
prefix
i.
MLANGxx (Modern Languages)
ENGL (English)
a. Classification
related: Begin with classification
prefix
i.
FRxxxxx (Freshman)
ii.
SOxxxxx (Sophomore)
iii.
JRxxxxx (Junior)
iv.
SRxxxxx
(Senior)
a. Campus
related: Begin with campus prefix
i.
OXFxxxx (Oxford)
a. Status
related: Begin with status prefix
b. HONxxxx
(Honors)
i. Specialization related: Begin with X, then
i. XMATHxx for Math Majors
4. Rule Modules
a. Limited
to 4 numbers with desc.
b. All
descriptions same as Validation or Substitution as referenced.
Figure 19
5. Rule Containter
a. Limited
to 12 characters.
b. In
general, similar text as used in validation, but enhanced for Web display
purposes.
i. PRxxxxxxxx for Pre-requisite ii. COxxxxxxxx
for Co-requisite
iii. SPECxxxxxx
for Specialization
iv. IMSGxxxxx
for Informational Message
TRANSPORTING
STANDARDS
1.
Communication
a. If
you are going to working on a program, function module, table, structure, etc.
for a length of time, it is crucial that you communicate with the other
developers before transporting these items to production.
b. It
is the developer’s responsibility to determine if a more recent copy of any
item in his/her transport group has already been moved to production.
2.
Transports
a. Transports
are requested using transaction ZTRANSPORT_FORM.
b. When
transporting more than one transport group, be sure to transport the groups in
the order they were created.
c. When
completing a project, transport ALL transport groups for that project into
production.
3.
Re-imports
a. Re-import
requests are submitted using the Transports transaction
ZTRANSPORT_FORM.
b. Requests
for transports to be re-imported into QAS and PROD must be submitted in
PROD. Be sure to select the correct
Target System.
c. If
transports were not originally submitted in the correct order, they can be
resubmitted using the Reimport Request option.
d. When
completing a project, transport ALL transport groups for that project into
production.
4.
Critical Imports
a. Critical
Import requests are submitted using the Transports transaction
ZTRANSPORT_FORM.
b. Requests
for transports are generally done at set times during normal workdays. Any requests for transports that need to be
completed outside of these normally scheduled times must be coded as Critical.
c. Only
transports that are truly crucial to the operating of the system should be
marked as Critical.
d. Developers
must enter an explanation for the critical transport in the “Requester’s
Comments for BASIS / Reason for Critical Transport”.
TESTING
STANDARDS
1.
Internal testing
a. All
projects (including enhancements) should be tested internally within IT before
being reviewed by the requestor.
Appropriate support teams in IT are available to assist with this
task.
b. All
developers are responsible for developing their own test plans. Test plans should include an appropriate
sampling of data before and after project has ran. They should also include measure to ensure
the appropriate outcome.
c. A
program review will be conducted by the appropriate manager.
2.
Return Codes
a. Test all return codes (sy-subrc) for
success and failure after any I/O and calls to function modules (database
selects, internal table reads, call transaction, etc.)
3.
Performance analysis
a. Program performance analysis should
be conducted using SE30 (ABAP Runtime Analysis) .
4.
Requestor Review
a. All projects should be tested/reviewed
and signed-off on by the requestor before they are moved to production.
AUTHORIZATIONS
STANDARDS
The
SAP authorization concept protects transactions, programs, and services in SAP
systems from unauthorized access. On the basis of the authorization concept,
the administrator assigns authorizations to the users that determine which
actions a user can execute in the SAP System after he or she has logged on to
the system and authenticated himself or herself. Follow standards to restrict
access for any table, program, transaction or service.
a. The
development class of any restricted program, table, function, etc., should not
be ZDEV. Consult with BASIS and
create a new package specific to application having name starting with Z, and use this package as development
class.
a. For
Dictionary objects: select Utilities-> Assign Authorization Group and enter
table/view name associated with newly created package name as Authorization
Group.
a. Submit
a request with BASIS to link authorization object related to this new package
and restrict the access.
PROJECT LIFE CYCLE
1. Project
request arrives via IT Work Request.
2. CIO
approves/disapproves project
3. Approved
projects
a. Written Requirements
i.
IT and requestors develops and agree on written
requirements.
ii. Requestor
must sign-off on requirements before development on the project can begin.
b. Design Document and Project Schedule
i.
The Developer/Project Team will be responsible
for creating a design document and project schedule.
ii. The
Director or Associate Director of Enterprise Applications must sign-off on the
design document.
iii. More
complex projects will require a sign-off by the CIO/Deputy CIO also. c. Project
Development
i.
Developer/Project Team will be responsible for
developing code, configuring the system, creating interfaces, etc. as needed
for the project.
ii. Weekly/Bi-weekly
checkpoints should be setup to monitor the progress of the project.
iii. All
development should take place in the development/test system. d. Internally
Testing
i. Project should be tested within IT
first. ii. Appropriate support teams within IT will be available to assist
with testing, such as, SAP Support Team, FTDC, Helpdesk, and Academic Computing
Coordinator. The developer is responsible for ensuring an appropriate test plan has
been developed.
iii. Problems during internal testing should
be fixed before the project moves to the next step.
e. Requestor
Testing
i.
Once project has been tested internally, the
project should be tested/reviewed by the requestor.
ii. The
developer should assist the requestor in developing an adequate test plan.
f. Finalization
i.
Support teams will be responsible for finalizing
documentation and for developing a roll-out plan.
ii.
Support teams will be responsible for conducting
necessary user training to support the project.
iii. The
developer will be responsible for coordinating efforts with BASIS to ensure
appropriate user authorizations have been granted.
g. Deployment
i.
Projects are not to be deployed to the
production system(s) until the requestor has signed-off.
ii. The
developer will be responsible for making sure all transports related to the
project are properly deployed.
h. Notification
i.
The developer will be responsible for
notifying the requestor when the new functionality will be available.
ii. The developer will be responsible for
determining if others on campus need to be aware of the new function (i.e.
appearance of a new tab on Student File).
4. Disapproved
projects
a. CIO/Director of Enterprise
Application notifies requestor.
REFERENCES
1. The
SAP Style Guide is available in the help documentation using the following
path:
a. Help -> R/3 Library -> BC-Basis
Components -> ABAP Workbench (BC-DWB) -> BC-> SAP Style Guide.
2. The
task code ABAPDOCU or ABAPHELP can be accessed through the
command window.
3. Inside
the ABAP editor, you can click on the “Information” or “I” icon.
Naming Standards
The proposed nomenclature for the values not mentioned in the Naming standards Document are high-lighted in yellow in the below table.
Position
|
Description
|
Values
|
Meaning
|
1-2
|
Variable Description
|
CA_
CN_
|
for Constants
|
P_
|
for Parameters
|
||
S_
|
for Select-Options
|
||
R_
|
For Range
|
||
RB_
|
for Radio buttons
|
||
CB_
|
for Checkbox
|
||
PB_
|
for pushbuttons
|
||
VA_
VN_
|
for Global Variables
|
||
O_
|
ABAP Object
|
||
I_
|
for Internal Tables
|
||
L_
|
for Local Variable
|
||
LT_
|
for Local Internal Table
|
||
LO_
|
for Local ABAP Object
|
||
LW_
|
for Local Work Area
|
||
LR_
|
For
|
||
ST_
|
for Statics used in Subroutines
(FORM and FUNCTION)
|
||
WA_
|
for Work Areas for Internal Tables
|
||
LB_
|
For List-Boxes
|
||
I_VA_
I_VN_
|
For Formal parameters which are Alphanumeric/Numeric Variables
in Input of Sub-routines
|
||
O_VA_
O_VN_
|
For Formal parameters which are Alphanumeric/Numeric
Variables in Output of Sub-routines
|
||
I_TB_
O_TB_
|
For Formal parameters which is Internal table in input,
only used for the reading of the data in sub-routines.
|
||
For Global Field-symbol
|
|||
For Local Field-symbol
|
|||
TY_
|
For Types Declaration
|
||
TTY_
|
For Table Type
|
||
LO_
|
For Local Objects referenced to Class
|
||
I_
|
Import Parameters of Function Module
|
||
O_
|
Export Parameters of Function Module
|
||
C_
|
Changing Parameters of Function Module
|
||
TB_
|
TABLES Parameters of Function Module
|
||
Class Methods
|
|||
C_
|
Class Attributes
|
||
Class Interfaces
|
|||
Class Types
|
|||
Class Events
|
|||
3-30
|
Freely Definable
|
use abbreviations for clear and
Concise names.
|
No comments:
Post a Comment