Skip to Content

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

To report this post you need to login first.

21 Comments

You must be Logged on to comment or reply to a post.

  1. Peter Langner
    Hi Tobias,

    thank you for that great blog. I also have the experience, that many ABAP developers still think in development classes and only have a poor knowledge of the packadge concept. There is still a lot of work to tell the story…

    Peter

    (0) 
  2. Julius von dem Bussche
    There are some very cool security advantages as well.
    It would be nice to see this aspect mentioned in the blogs as well.
    I have been ranting about it for a long time in the forums and am patiently waiting for several runtime syntax checks to say “Hello World”…  🙂
    Cheers, Julius
    (0) 
    1. Tobias Trapp Post author
      Hi Julius,

      you are absolutely right: when you use package checks SAP developers are forced to use proper APIs containing autority checks – I think I already mentioned it. But I will get in detail when I will discuss best practices for the content of package interface: put classes and functions modules into an interface but not the table structure. Is that what you have in mind?

      This is an important point but using dynamic statements (code generation, dynamic SELECTS, method calls within XSLT oder ST programs) you can access any transparant table. The only possibility to guarantee security would be put package checks in the level of the ABAP kernel. For this concept IMHO a system wide switch is not enough – we need the concept of “dangerous” code fragments like in C#. This would allow to introduce the ultimate security step be step.

      Cheers,
      Tobias

      (0) 
    2. Tobias Trapp Post author
      Hi Julius,

      you are absolutely right: when you use package checks SAP developers are forced to use proper APIs containing autority checks – I think I already mentioned it. But I will get in detail when I will discuss best practices for the content of package interface: put classes and functions modules into an interface but not the table structure. Is that what you have in mind?

      This is an important point but using dynamic statements (code generation, dynamic SELECTS, method calls within XSLT oder ST programs) you can access any transparant table. The only possibility to guarantee security would be put package checks in the level of the ABAP kernel. For this concept IMHO a system wide switch is not enough – we need the concept of “dangerous” code fragments like in C#. This would allow to introduce the ultimate security step be step.

      Cheers,
      Tobias

      (0) 
      1. Julius von dem Bussche
        Hi Tobias,
        AFAIK the package check is not only limited to SE80.

        It is also extended to the runtime environment but is currently only a warning in the developer trace.

        Step by step this will be switched to runtime error messages when the package actually has complete APIs which must be used.

        BC-SEC is a nice example of this, but I am not sure whether I will still live to see the day of this switch..  🙂

        Cheers,
        Julius

        (0) 
  3. Peter Inotai
    Hi Tobias,
    Nice topic. I’m looking forward for the next one 🙂
    We use package check with R3ENTERPRISE on SAP R/3 4.70/Basis 6.20. Unfortunately it’s really time-consuming to set up and maintain, but it works 🙂
    I already had a chance to look at the NW 7.10 version, which looks much more convenient.
    Keep blogging,
    Peter
    (0) 
    1. Tobias Trapp Post author
      Hi Peter,

      great to find other people working with check mode R3ENTERPRISE. It would be very interesting to know what’s most time consuming. Perhaps we can share experience and find best practices.

      Best Regards,
      Tobias

      (0) 
    2. Tobias Trapp Post author
      Hi Peter,

      great to find other people working with check mode R3ENTERPRISE. It would be very interesting to know what’s most time consuming. Perhaps we can share experience and find best practices.

      Best Regards,
      Tobias

      (0) 
      1. Peter Inotai
        >It would be very interesting to know what’s most time consuming.
        For us is to add the “Use access”-es. We use own program to generate them, otherwise it would take forever.
        Other problem, that we would allow access within a structure package any component to any component. However in SAP’s logic it has to be in the same level, lower level cannot access higher level because of encapsulation. So, sometimes we have to reorganize our subpackages because of SAP’s logic.
        Our main motivation was to control the access between in our packages. However we realized, that we have to allow access also for SAP components. This has the nice “side effect” that we can control, which SAP components we allow to our packages. For example before we didn’t have a tool to avoid usage objects from the PI package.

        I believe there is only very little number of customers using this tool.

        Peter

        (0) 
        1. Tobias Trapp Post author
          In NW 7.0 there is a wizard which analyses a violation of interfaces and makes suggestion which use access can solve the problem and even create this use access. Is this what you did?

          An automated generation seems a little bit too dangerous because IMHO a sofwtare architect needs to decide which use access is correct.

          An automatic tool support when refactoring the package hierarchy would be very cool indeed. Perhaps we should collect those requests and go to idea place?

          Best Regards,
          Tobias

          (0) 
        2. Tobias Trapp Post author
          In NW 7.0 there is a wizard which analyses a violation of interfaces and makes suggestion which use access can solve the problem and even create this use access. Is this what you did?

          An automated generation seems a little bit too dangerous because IMHO a sofwtare architect needs to decide which use access is correct.

          An automatic tool support when refactoring the package hierarchy would be very cool indeed. Perhaps we should collect those requests and go to idea place?

          Best Regards,
          Tobias

          (0) 
          1. Peter Inotai
            >In NW 7.0 there is a wizard which analyses a violation of interfaces and makes suggestion which use access can solve the problem and even create this use access. Is this what you did?

            We’re in 4.70/6.20, so we cannot use the Explain tool, which is available as of 7.00 via a certain support package level.
            We created our own program for access usage generation, which is already considers certain company specific rules for our packages/package hierarchy.

            >An automatic tool support when refactoring the package hierarchy would be very cool indeed.
            I cannot agree more 🙂

            Peter

            (0) 
      2. Peter Inotai
        Do you have any info about Package hierarchy tab in NW 7.30?
        It seems this nice feature was introduced in NW 7.00, but it seems it’s no longer available in NW 7.30 🙁

        BTW do you have also any info about CheckAspct/CheckConfiguratn/Check config. Rule? They are available in the Development Coordination tab in the object selection in SE80, but I couldn’t find any info about them yet.

        Thanks,
        Peter

        (0) 
        1. Tobias Trapp Post author
          I’ll blog about the differences between NW 7.0 und 7.30. IMHO the package concept got more complicated: You have access control lists, enhancement extension packages and so on…

          Best Regards,
          Tobias

          (0) 
  4. Kumud Singh
    Hello,
    I read twice to get into the feeling of it.Thanks for writing it this ways. When you move into practical, can I please request you to show an example wherein we can combine standard SAP into our customized application development.
    Just my thought,at your wish certainly.
    I am yet to read the book though which yourself and thorsten suggested. (Development from Scratch)

    Regards,
    Kumud

    (0) 
  5. James Wood
    This is an important and timely topic for many projects. As the ABAP development landscape continues to evolve, best practices for software logistics need to evolve as well. Hopefully more and more projects will embrace this concept as a result of your blog series.
    (0) 
  6. Paul Hardy

    I have been thinking about this ever since I heard you give a talk on this subject in SAP Inside Track in Bonn in 2010.

     

    I have to confess I still don;t understand 100%, but have a gut feeling this is really important, even for programmers who do not develop third party add-ons for SAP systems.

     

    Say I have a special class to handle the really complex logic regarding monster special properties (do they have seven heads, are they a hundred foot tall, do they breathe fire etc).

     

    Many applications use this class, and I gather the idea is to have the calling classes only know a bout the interface the special class implements, and not the real class itself.

     

    In Java, as I understand it, you do this to reduce compilation time, as when you change a class all the concrete classes the changed class reference have to recompile as well, but not if you use references to interfaces as opposed to references to concrete classes.

     

    Naturally we do not have the problem in ABAP of programs taking a very long time to compile, but we still use interfaces in order to favour composition over inheritance.

     

    Anyway, is the desired architecture that the calling applications are all in their own packages, the special class is in it’s own package, and the interface is in yet another package? That seems to be the design Martin Fowler uses in his book on refactoring, when he introduces interfaces to reduce the compilation time of classes.

     

    What about custom DDIC elements? Do they live in their own package? Or do you have more than one identical DDIC object with different names in different packages?

     

    Cheersy Cheers

     

    Paul

    (0) 
    1. Tobias Trapp Post author

      Hi Paul,

      my recommendation is that you try to copy the Java programming model. This means that you think in terms of APIs. Those APIs contain classes and the dictionary elements that are used (f.e. as parameter of the classes). Those APIs are provided using package Interfaces. Feel free to provide many of those Interfaces describing different APIs. The client package which uses this API just has to declare the usage of this package interface.

      Does it answer your question?

      Cheers,
      Tobias

      P.S.: Let’s talk about monsters. If I remember right NW 7.30 had a slightly different package concept but luckily (at least I think this way) this was discontinued in SAP NetWeaver 7.40, 7.5 and will hopefully vanish forever

      But there is another monster: At least in NW 7.40 it was possible to create your own package interfaces containing even unvisible elements f.e. from forbidden packages. I didn’t try it out whether this is still possible – but this mechanism allows to client to define APIs. I can’t recommend it since only the “server” package should be able to define ist API.

      So again my conclusion is that you should try to adapt Java-like best practices for creating package interfaces. If I remember right Java forbids cyclic dependencies which are possible in ABAP. But even in ABAP I consider cyclic dependencies as poor architecture style.

      (0) 

Leave a Reply