Additional Blogs by Members
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 

ABAP Package Concept Part 1 – The Basics

ttrapp
Active Contributor
‎2011 Dec 04 12:51 AM
51,193

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:

  • Developers don’t know what ABAP classes or function modules belong to the public API. Naming conventions won’t help you because you can’t assume that they are widely known.
  • It’s likely that developers start do use ABAP classes which you consider as “private” and you will get into trouble when you want to change them (think of refactoring or optimization) in an incompatible manner. When this happens your application uses its most important property: it is not “soft” any more as software should be. There are too much unwanted dependencies and you have to consider side effects when doing changes.

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:

 

Use Cases of the Package Concept

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:

  • You can define dependencies to SAP standard. This can help you in SAP software updates because you use stable API and control the dependencies which is very help in impact analysis of SAP Switches & Business Functions of EhPs.
  • In a larger development project you can structure your application. You can define your own stable APIs to tell the developers who to use APIs and to protect some parts you would like to change in the future. This is most important if you want to decouple applications for an independent release cycle.
  • If you are delivering software components using the Add On Assembly Kit the control of dependencies to guarantee the installability of custom made SCs.

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.

Packages and Software Components

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:

  1. What’s the difference between software components in ABAP and in Java (SAP NetWeaver CE)?
  2. What’s the difference between ABAP packages and ABAP software components?
  3. What’s the difference between ABAP and Java packages?

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.

Reuse of Development Objects

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:

  • If you use the data model of an SAP standard application, you should exactly the data elements of the application.
  • But misusing them will bring you into trouble. In most cases short texts and documentation is not correct. The definition of own data elements will allow you to define proper texts and documentation. Another consequence of misuse of data elements is that your software is not merger ready with SAP standard tools like Landscape Transformation: Basic Operations.

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:

  • Use SAP domains only if you have a good reason. Merger readiness of an ABAP application is such a reason. Consider the case that you want to define a role of the SAP Business Partner application. Therefore you should create a new data element to have be able to define short texts, F1-help and search-helps. In this case you should reuse the BU_PARTNER domain of SAP Standard so that landscape transformation tools can analyze that this is an proper extension.
  • If you are using domains like CHARxyz please check whether they are exposed in package interfaces. And please check to which application it belongs to avoid unwanted dependencies to SAP applications you don’t use. Otherwise package checks against package interface are not useful because they’ll produce too much error messages.

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.

Summary and Outline of the Blog Series

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

21 Comments
Popular Blog Posts
Top kudoed authors
View all