Get Example source ABAP code based on a different SAP table
Names of Repository Objects
ABAP_BACKGROUND Repository objects are development objects that you edit using the tools of the ABAP Workbench. Each repository object is assigned to a package. Packages encapsulate the repository objects contained and use package interfaces to make objects available that should be usable outside the package. This complies with the SoC principle. From a semantic point of view, packages represent a context for declarations, which is one level above the contexts of an ABAP program. Unlike the contexts of an ABAP program (programs, classes, procedures), a package does not generate a separate namespace. The namespace for repository objects is defined as follows:
Prefix namespace Development organizations (SAP departments, SAP partners, and SAP customers) can request a prefix namespace for their own development systems. A prefix namespace has a name with at least 5 and a maximum of 10 digits, and the first digit and last digit must be slashes (/.../). After the namespace has been assigned, repository objects only can be created in systems, where the namespace is enabled by prefixing the namespace name /.../. If a package is created in this type of prefix namespace, it can only contain repository objects belonging to the same namespace. However, you can create multiple packages within a prefix namespace. The available length for the actual name is reduced by the length of the namespace prefix, including the slashes.
Customer namespace If no prefix namespace is available, the names of repository objects created in customer systems or non-SAP development systems must have Y or Z as the first character. This means they are located in the customer namespace. Repository objects whose names start with Z can also be located within packages whose names start with Y and the other way round.
SAP namespace If no prefix namespace is available, there are no real restrictions for the names of repository objects that are created in SAP#s own development systems. The SAP namespace comprises the entire AS ABAP . Irrespective of the namespace where a repository object resides, the name of the repository object is unique in the current AS ABAP . Therefore, when you address the object, you do not have to make any further specifications. The namespaces (particularly the prefix namespace) were implemented to avoid namespace conflicts during transports between systems and upgrades. For SAP#s own development systems, there is a cross-system table that ensures the uniqueness of names within the SAP namespace.
ABAP_RULE Clarify the type and affiliation of repository objects in names Use common naming conventions for repository objects. The predefined name prefixes, CL_, IF_, and CX_, apply to objects of the class library. If possible, create all repository objects in the prefix namespaces only. In addition, use a naming convention to clearly indicate which package or component the objects belong to.
ABAP_DETAILS Classes and interfaces are the most important entities for programming with ABAP Objects. To type an object reference, you can use either a class type or an interface type. It is useful to uniquely flag these two types in the class library by means of a prefix. Global exception classes should also be uniquely identified by a prefix. The following naming conventions apply. These conventions are sometimes enforced by the Class Builder but are sometimes only evaluated:
CL_ for global classes
IF_ for global interfaces
CX_ for global exception classes
CL_BADI_, IF_BADI_, CX_BADI_ for classes, interfaces, and exception classes of Business Add-Ins (BAdI) In addition, the names of all repository objects should clearly identify the package or component they belong to. Technically speaking, a package does not generate its own namespace and therefore naming requires strict discipline. Using prefix namespaces is very helpful in itself. However, they are not intended for the package level but for bigger development projects, which usually comprise numerous packages. Therefore, the names of the repository objects contained in a package should be labeled with a shared name component, which indicates the affiliation to a package or at least to an application component. The length of names is restricted to 30 characters or less, and the namespace prefix is included. Therefore, you should use an abbreviation for this name component and not the complete package name. You should never assign a universal name for a package-specific or component- specific repository object. This would render the name useless for further general use. For example, general names of the SAP namespace (such as CHAR60 for a data element or CL_ABAP_MATH for a class) should only be declared in absolutely fundamental basis packages delivered by SAP and exposed by these packages in a generally available interface. If developers find a repository object with a universal name, they naturally assume that they can freely use the object in the way i ndicated by the name. Before the introduction of the operational package concept, there were no strict checks for package limits. As a result, repository objects with overly universal names (particularly in the SAP namespace and also in the customer namespace) are now used throughout all AS ABAP packages. This can lead to considerable difficulties if you want to implement real package encapsulation.
Note The above rule supplements the universal rule regarding descriptive names. With regard to technical information in repository object names, the same information stated in section on descriptive names also applies here (also refer to the discussion on prefixes and suffixes in program-internal names). All development organizations are free to create own naming conventions on the basis of the above rule regarding descriptive names. However, note that the use of a namespace prefix only leaves limited space for the remaining name components. For example, the names of database tables are restricted to 16 characters. Therefore, the namespace prefix should not be too long. It should simply describe a product line using an abbreviation
Exception Not all repository objects can be created in prefix namespaces. Authorization objects and type groups are typical examples. In these cases, you should create an additional package that includes all of these objects. The object names and package names should, if possible, contain a relevant, normal prefix instead of the real namespace prefix /.../. A similar guideline applies if further development is performed in areas that are traditionally located in the SAP namespace or the customer namespace. Instead of using a real namespace prefix, you can simulate this by using uniform prefixes when you create new packages and development objects. If the ABAP Workbench itself allocates names, for instance, for Include programs, which are assigned to specific main programs (such as function groups or class pools), this na me allocation always has priority over all other rules. This ensures that the Workbench and the Compiler run correctly.
Example Refer to the repository objects of the sample application in the package SABAP_DEMOS_CAR_RENTAL. The subpackages of the SABAP_DEMOS_CAR_RENTAL package start with the same name as the superpackage (as recommended in these guidelines). A suffix indicates their specialization. The same applies to the package interfaces. Instead of a real namespace prefix, the repository objects of the packages have the DEMO_ prefix. This indicates that the objects are part of a demo package . The affiliation to the car rental application is indicated by the abbreviation CR (car rental).