At SAP communities ROCK! I offered a session about ABAP package concept. There are slides and a video of the session available but I decided to write a series of blogs about the topic. In my opinion the ABAP package concept was – besides object orientation and ICF – the most important innovation of the ABAP application server. The reason is simple: the package concept allows to develop software so that is “soft” which is necessary for evolution of any software system.
In my opinion too many custom development projects don’t care about this and most developers don’t know about the ABAP package concept. I can only guess the reason: At the beginning of a development project the aspects of software logistics and naming conventions (Z or a customer namespace) are first challenges. Usually packages and namespace prefixes for development objects are defined to group some objects according some obvious properties: there is one package for FI development, another one for HCM and so on.
This may be appropriate for small development projects consisting of some report and BAdI implementations but will lead to serious trouble in larger projects. But even in small development projects the ABAP package can help you. I can give you an example from my own experience. One of my tasks as developer was to implement A2A and B2B processes and therefore I used the web service infrastructure of the ABAP application server – the package SAI. I think it was first shipped in 6.20 and there have been incompatible changes in release 6.40, 7.0 and I think in NW 7.0 SP 15 because of changes of SAP Web Service frameworks. Luckily I only used functions of the package interface of package SAI and so I had only a few things to change in the releases.
But the same applies to custom development of applications: if you create your own application with database persistence, application layer, UI that is used by another custom developed application you have to define proper API to guarantee authorization concept for example. Without package interfaces following problems will occur:
As a consequence I changed my programming style: when I’m coding an application I will write define a proper interface that helps developers to use my tools. When I want to reuse parts of SAP standard I first look at the package interfaces. This helps me to learn how to use SAP standard much faster and the chance is much higher that I don’t have much after a release upgrade.
I give you some example: When I wrote my last blog about a Operations Research & ABAP within SAP standard I learned how to use it by studying unit tests and package interface:
The ABAP package allows nesting packages hierarchically. The package at the top level corresponds to an application.
The ABAP package concept allows you to create stable APIs of a package. This means that you can distinguish between public and private parts (implementation details) that can be changed.
But package concept has many other use cases – we can define dependencies to other packages of SAP standard as well to your own packages:
To come to the conclusion: ABAP package concept is the most important tool for software architecture. You can use package checks as part of extended syntax checks and Code Inspector to check violations of package interfaces.
I’ll discuss these and even more aspects of the ABAP package concepts here and will even go deeper into pesky details. If you like at SE80 you will find different options for package checks – “as client” and “as server”.
And last but not least there are two different package check modes: RESTRICTED and R3ENTERPRISE. You may ask why the concept is so difficult. In my opinion SAP had no other chance: the software structure of R/3 was too complex and there have been too much unwanted dependencies. On the way to ECC 6.0 SAP had to solve many problems – the most urgent comes from the introduction of EhPs that allows to define packages which are activated after switching in a business function on the customer system. Therefore you have to control dependencies because no object of a non-switchable package is allowed to use an object that is switchable. In my opinion the package concept is a necessary step for development of switchable units. But therefore SAP had to deal with R/3 code with many unwanted dependencies – so the definition of a strict and Java-like package concept was not possible – SAP had to define check modes that allow violations of package interfaces.
But first we I want to discuss some basic aspects of software development in ABAP.
SAP and ISVs delivers the software as software components. You can find the list of installed software components in transparent table CVERS. You can think of Software components (in short SCs) as special transports containing metadata. Those transports are installed using transaction SAINT. Let me ask some simple questions:
There are some differences between SCs (or SWCVs – software component versions) in both worlds – but one is very important: An SC in Java defines a persistence unit in terms of JEE. In fact there is no such concept in ABAP – we have concepts like internal modus and LUW. In Java SCs contain DCs and so called top level DCs define the “visible” objects of an SC.
What about packages and SCs? These are completely different concepts. An SC is an artifact from software logistics and can contain complete packages (in an installation package – AOI). Packages can be assigned to software components but in contrast to packages they have no representation in ABAP Workbench.
In Java there is a concept of visibility – you can protect develop objects from being accessed. In Sap NetWeaver CE there is an additional concept of accessability. In ABAP there is none of such concepts. Event circular dependencies are possible which will lead to compilation errors in Java.
The most important aspect of package concept is to keep control on reuse. So let my first think about to do reuse in a proper way. From the view of concept this very simple: SAP defined package interfaces of their packages and so an API consisting of ABAP classes, function modules, data elements and so on. If you want use the ABAP package concepts you should only development objects that are exposed that way.
So what do you think about reuse of data elements of SAP standard? In my experience there are many developers who just think of SAP standard as huge set of data elements they can reuse in their programs. But how to do it right? I think there is a simple advice:
I think I have to clarify the last aspect. When you want to merge and split systems or change the SAP data (think of organizational management) or customizing in a disruptive way with tools like SAP LT you have to ensure that your custom developed application is merger ready. Landscape Transformation: Basic Operations works on the level of ABAP domains and will change the value if domains whether they are in transparent tables or in intransparent data containers. So merger readiness means exactly that that you develop the way it is described above.
Everything I mentioned above applies to DDIC domains, too. My advice is simple:
What about reuse of ABAP message classes? In fact I don’t recommend it in most cases. Message classes are used to define error messages in BAPIRET-messages, in the Business Application Log (BAL) and sometimes in controlled dumps. If such an error message occurs with the use access you can find the correspond line in the ABAP code – but if you reuse error messages from SAP standard and is not easy to find the right line of code where an error message was created. And there is another reason not to reuse error messages from SAP standard: in most cases the long text is not appropriate in the context of the custom application.
In this weblog I explained some use cases of the ABAP Package Concept from the point of view of an ABAP developers as well of an software architect. In the next part of this weblog series I’ll discuss