[ABAP Part One] Program Development Phase 1 ---- Basic Sturcture & Obj Overview

This section dicusses issues, concerns, and practices to be aware of during the program development cycle.

As programmers, it's our nature to learn by looking at testing programs and copy code as necessary.

This article is design for give you a freshlook about the ABAP programing architecture, and how does it works in R/3 enviornments.Also we will introduct the object naming rule for you. It's very strange, isn't that. Because in the VS.NET platform, you can name the object for any string, VS.NET provide namespace to separte them into different platform.

Customer Objects

SAP objects are kept separate from customer objects by using different letters for the first character of the object’s name. Customer objects begin with Y or Z. Oddly enough, SAP may use 'Z' in rare cases for their objects even though this is reserved for customers. The letter ‘Z’ is suggested throughout this document as a standard practice for customer objects but the letter 'Y' may also be used.

Third party vendors can apply for a reserved prefix to identify their development objects within a customer's SAP system. These conventions ensure that custom developed objects will not conflict with SAP objects in current or future releases.

Adhering to object naming conventions adds consistency to named objects while also helping to identify and categorize your development objects. The following table suggests naming conventions for ABAP Dictionary and WorkBench Objects.

Dictionary Objects

DDIC Object	Naming Standard	Repository Entry	Meta Data Table
Domain	Z*
Data Element	Z*
Lock Object	EZ*
Search Help	ZSH*
Structure	ZS*
Table	Z* or ZT*
Table Type	Z* or ZTY*
Table Indeces	Z## 3 character unique name
Type Group	ZTG*
View	ZV*

Workbench Repository Objects

After the Z prefix, it is common practice to further identify the object by including the application ID as part of the prefix. This naming convention is entirely up to the corporate standards and is only presented here as an additional identifying technique.

Sample Application ID's

AM - Asset Management
BW - Business Warehouse
FI - Finance (GL, AR, PS)
MM - Material Management
PP - Production Planning
SD - Sales and Distribution

For Example: if the object belongs to the SD application, a program could be named ZSDLOADORDERS. In addition, some shops choose to use the process or GAP ID as part of the name so for example if the gap is GAP123 you could essentially see a program named something like ZSD123LOADORDERS or ZSDLOADORDERS123 or simply ZSD123.

Another common practice is to provide a qualifier as part of the name that identifies the program TYPE i.e. for the above Data Load program, the name could be ZSDDORDERS which would literally translate to a "Data Load program that loads Orders and belongs to the SD application area"

Sample Program Types

R - Report
D - Data Load
I - Include
X - Interface
etc.

SAP Object	Naming Standard	Repository Entry	Meta Data Table
Application Log	Z*
Area Menu	Z*
Batch Input Session	Z*
Change Document	Z*
Package	Z*
Dialog Module	Z*
CMOD Enhancement Project	Z*
Form Pool	SAPFZ* Generated Include modules should follow SAP suggested recommendations For Example FZ*TOP - Data declarations FZ*F## - Subroutines
Function Groups	Z*
Function Modules	Z_*
Gui Status	Z*
Include	ZI*
Memory ID	ZM*
Message Class	Z*
Messages Number	numeric 3 digits 1-999
Module Pool	SAPMZ* Generated Include modules should follow SAP suggested recommendations For Example MZ*TOP - Data declarations MZ*O## - PBO modules MZ*I## - PAI modules MZ*F## - Subroutines
Number Range	ZNR*
Program	Ztype* where type identifies the program function
Screen	4 characters
GUI Title	Z*
Transaction Code	Z*

Modifications

Whenever an SAP object is modified, a special kind of modification referred to as a ‘repair’ is performed. Repairs are a special type of Correction in SAP where the system recognizes that a change is being made to a ‘copy’ of the original source. The term 'repair' also applies when a customer object is modified in the non original source system that it was developed i.e. created in a development system and changed in a QA or production system.

Modifications to SAP programs should be done only when all other alternatives have been exhausted and management has given approval to proceed. There are circumstances such as when an advance correction is made available from SAP that are considered normal practice. These are usually made available in the form of an OSS note from SAP.

If a modification must be performed that is outside the scope of an OSS note, try to encapsulate the modification in a single programming unit such as a function, method, Form, or Include. When a new release is installed, and if the object has been upgraded to a new version as a reult of the new release, the customer must manually compare the modifications with the new standard and re-apply any modifications that may still be desired.

Obsolete ABAP

Avoid Obsolete Statements – Obsolete does not necessarily mean that it is physically dropped from the language or will not pass a program generation. If the statement is deemed obsolete by SAP, it can mean that it will not be compatible with ABAP OO syntax or could cause extended program check warnings. There are generally better/newer ways to use the command. The old conventions are usually preserved for backwards compatibility. For a complete and currect list of obsolete statements check the SAP help as well as the Release Notes found in the Object WorkBench.