News about ABAP Package Concept: Naming Conventions for Package Hierarchies

[ttrapp]

In this blog entry I’ll describe impact of OSS note 2297645 for ABAP development: https://launchpad.support.sap.com/#/notes/2297645/ . For me this is a very important ABAP innovation. SAP Partners and software architects now can optimize existing ABAP packages according state-of-the-art development:

• We need smaller and sometimes encapsulated packages to develop small and innovative applications like Fiori and UI5 apps.
• We can start to split up huge development classes into smaller ones to improve the software structure. This is a chance: software is getting more transparent and can be maintained with lesser costs.
• We encapsulate existing objects like CDS objects to prevent dangers of reuse (think of CDS for BI vs. CDS for BI for example).

This is now possible by keeping existing naming conventions. This allows customers and partners to create modern package hierarchies like SAP does in the following picture:

The BRFplus framework is developed as subpackages of the package SFDT where all development object have a same namespace prefix FDT_. Modern SAP solution have this property (BRFplus is just an example):

• It has a welldefined structure which helps to understand the solution and makes maintenance easier.
• The development process becomes easier since one can define responsibilities for development object on the level of packages.
• There is a common namespace prefix which is necessary in a complex development landscape.

The package concept is really cool since it allows you split up huge packages into smaller one according different concerns. The benefit is a better software modularization which is necessary for modern ABAP developemt containing of smaller applications and new interface technology (Fiori & OData), operational reporting (CDS and BW on ERP) and so on. I already blogged about it in a series of blogs, f.e. ABAP Package Concept Part 4 – How to perform package checks. Please remark that this blog is not about package concept - I will show how to use it together with existing ("legacy") naming conventions.

Development Classes and Naming Conventions – A look back into the Past

At the beginning of every ABAP development project development packages and naming conventions are defined. The central note https://launchpad.support.sap.com/#/notes/84282/EN described how it goes:

I give you a small example: For FI development often development packages like /ACME/FI have been introduced and the object names started with a namespace prefix /ACMR/FI_. This is necessary to avoid duplicate objects especially in complex system landscapes. According OSS note 84282 you can define the name range a transparent table TRESN which is displayed in the following picture.

With this entry in maintenance view V_TRESN following is guaranteed:

• There is a check which prevents that an object starting with a different name prefix can be assigned to this package.
• And if an object is created there is a proposal for the correct package according to the namespace prefix.

This is extremely useful especially in larger development projects where software is transported between different development systems and we have to avoid clashes in naming conventions. Those naming conventions also make it possible to redesigning systems by moving software into a deeper software component.

Please be also aware that such checks are also possible (perhaps somewhat limitated) with check programs like Code Inspector (transaction SCI). But usually those checks come much too late: Once an ABAP application is developed, object renamings are difficult and expensive.

But above TRESN definition has one disadvantage: a namespace can be assigned to a package but not a package hierarchy. So we can’t apply state of the art software structure like in the following example with SFDT: the SAP application BRFplus is contained in subpackages of the package SFDT and all objects have the same namespace prefix FDT_.

Unfortunately this is not possible with package SFDT_BRFPLUS because the name space prefix FDT_ can be assigned only to a single package (so far). This was changed with OSS note 2297645. No we can define a namespace prefix for a package hierarchy by choosing the value „H“ like it is done on the following picture:

The letter “H” in the picture means “hierarchical” since it allows one namespace prefix for a package hierarchy. Now we create subpackages of package /ACME/FI like /ACME/FI_ODATA, /ACME/FI_CDS… to introduce a proper software modularization and keep existing naming conventions.

Summary

One of the drawbacks of ABAP language is that development classes (now called packages) don’t define namespaces by themselves. Therefore we have to use namespace prefixes for development objects and checks at development time to prevent renamings.

Since the ABAP package concept moved on, the naming conventions for package hierarchies had to follow. And now it is here and ready to use!