In the first part of this weblog series I introduced the ABAP package concept (ABAP Package Concept Part 1 – The Basics ) and package interfaces (ABAP Package Concept Part 2 – Package Interfaces of Development Packages). Now I introduce packages hierarchies and discuss how they can be used to structure applications: what packages build an application and how to define functional cohesion in an application. Please be aware that I describe package concept in Releases 6.10 up to 7.02 and things will change slightly in 7.30 but this is topic for another blog.

In the last instalment of this series I discussed package interface which reflects the concept of coupling: what are the dependencies between software packages within in application and between applications? We will discuss another way the package concept supports this concept and the related concept of cohesion which means how “focused” a software module like a package is.

Hierarchies of Packages

Why are package hierarchies useful? When you have a look at legacy development classes there was no concept of package hierarchies. As a consequence there was no concept which set of development classes form an application. Using package hierarchies you can make this explicit. Why is this necessary?

  • Packages of an application are usually tightly coupled and have to be shipped in the same transport layer.
  • All packages of an application are deployed in the same software component. You can assign a package to a component but there is no explicit concept of software components in AS ABAP because they are created in final assembly systems with tools like AAK.

With package hierarchies SAP bundled legacy development classes using structuring packages and defined the software structure explicitly.

Naming Conventions will fail

Without structure packages software architects tried to tackle above mentioned challenges with naming conventions but those conventions have drawbacks:

  • No naming convention can foresee all above mentioned aspects.
  • They make software hard to change. What happens if the architecture of a system changes? Think of the case that you want to deploy same parts of a solution as a reuse tool in a deeper software layer for example. What happens if you have to split a huge application into to smaller ones?

I can give you lots of more examples but the consequence is clear: at a certain time you will have to violate naming conventions. And even if you manage to avoid violations there is the danger that those naming conventions will be forgotten in the long run or they are getting too complex.

“From Software Components to Structure Packages”

Since Release 6.10 SAP explained this new software structuring paradigm in SAP Help Portal:

  • They introduced one or more so called structure packages that contain all packages of a software component. A structure package can represent a software component (like ABA represents SAP_ABA software component) or can represent a big application within a software component.
  • A structure package consists of so called main packages (I omit the case of included structure packages) which usually correspond to encapsulated parts of application like tool suites.
  • In the bottom of the package hierarchy are so called development packages which correspond to legacy development classes and contain development objects.

Let me summarize: With structure packages you can define the overall structure of a huge development. Using them you can define dependencies to structure packages from SAP standard. But you have to use this option because those dependencies are only checked in a special package check mode (called “R3ENTERPRISE”). There are also weaker package check modes (“RESTRICTED”) that don’t require structure packages.

Hierarchies and Visibility

This most import thing you have to know is that the package hierarchy defines visibility and controls access of development objects. The reason is simple: In a package hierarchy each parent package can restrict the use access: if it has package check “as server” only you can access development elements within its hierarchy using package interface. In fact package interface from deeper packages can be propagated to parent packages. If we don’t propagate certain interfaces we declare that a certain function is not accessible from outside the hierarchy.

As a consequence the packages concept makes it easy to access services from sibling packages but you can restrict usages at the level of the common parent packages. So a subtree within a package hierarchy defines a set of packages that can use each other’s functions. This corresponds to the principle of cohesion:  in software engineering we usually try to group development objects that belong together. This may sound to abstract but I will discuss an example below.

There is another aspect of package hierarchies: if a certain package declares a use access the same use access has to be declared in the higher packages of the hierarchy. As a consequence you can see at the top level all used interfaces of packages in the hierarchy. There is an exception to this rule: structure package need only to define use access to other structure packages.

How to access a package within an hierarchy

Every ABAP programmer frequently uses function modules from financial mathematics. SAP created to packages: one for financial mathematics (FIMA) and another one for financial conditions (FICO). In fact those packages don’t come alone – we other packages (FIMA_TEST) for example. Those packages have a strong cohesion: the test functions use the functions from financial mathematics but they don’t expose services because they are only test applications that are useful for quality insurance and serve a documentation how to use FIMA API.

So SAP grouped those packages in a package hierarchy in a package FS_FIM (see picture below).

This has many advantages: there is an explicit main package for financial toolset. Every contained package can propagate its interface to the main package so you can reduce the number of use accesses at the side of the client because interfaces are bundled:


Let me mention three things:

  • SAP decided to expose the interface of package FIMA_TEST in the main package. This is possible but you don’t need to do it. There is also the possibility to exclude this interface and to “hide” test functions.
  • The package concept made it possible to group legacy development classes. The criteria how to group them is coupling: is there a strong connection between those packages? Usually the there is a tight connection between packages of an application where applications should be more loosely coupled.
  • We can use packages to introduce cohesion: Is a package focused on a certain way? FIMA package is “focused” because it contains reuse functions for financial mathematics.

Now I will discuss how to declare a use access for function modules in FIMA package. Only if you want to express the dependencies between structure packages (package check mode R3ENTERPRISE) you have to declare a use access to the structure package at the top of the package hierarchy containing the FIMA package which is structure package ABA. ABA exposes many interfaces: a default interface, a virtual default interface and a filter interface:


In fact you have the choice: You can declare a use access to the default interface or to the virtual default interface (and on the level of structure package the access to the filter interface). A virtual default interface is a kind of carte blanche that grants access to all elements but can be restricted to a certain namespace using the filter interface.

As I showed above the services from financial mathematics are exposes in interface FS_FIM_INTERFACE_MAIN and you have to declare a use access to this interface in any case: package check mode R3ENTERPRISE as well as RESTRICTED. Here is an example that shows how the Accounting Engine declares a use access:


I explained the connection between package checks and package hierarchy. This may sound very complicated and so I will come back to this example in the next installment of this series where I show how to perform package checks.

Cohesion as Quality Criteria of an ABAP Application

So what is package concept all about? It’s all about cohesion: are the parts of a package grouped arbitrarily or is there an underlying design principle? Are the packages of an ABAP application grouped arbitrarily or is there a structure? With an underlying design principle which is understood by developers maintenance it’s easier because a certain aspect or function is located in a defined place you can easily identify parts of the software that implements a certain process.

We will discuss grouping of modules in two scales:

  • development objects can be grouped in packages
  • packages can be group to define applications

There can be many different grouping criteria – let me first give some examples for development objects:

  • Sometimes it makes sense to separate development objects from other development objects – think of generated ABAP proxies for examples which should be generated in own packages to prevent wild reuse.
  • As applications grow it makes sense to separate UI (especially new UIs like WDA) in own packages.
  • Development for special purposes (like migration and test) should be done in special packages.
  • You can create packages for different processes in an application.

Using package hierarchies you can group packages according special criteria – let me mention a few:

  • functional cohesion on package level: which packages are tightly connected?
  • business process: which process that is realized in the application?
  • bundling: which packages build an application?
  • transport layer: packages that belong to the same transport layer and should be transported together
  • dependency to SAP components: packages that have the same dependencies to structure packages / components of SAP standard
  • dependency to applications of SAP standard: which application is extended?

Those aspects are aspects of cohesion which is explained very well in Wikipedia: cohesion means how “focused” a piece of software is:


A software architect has a clear vision of the application that has to be created and knows about cohesion aspect within the application, he know interfaces to SAP standard and to SAP applications that are extended. Let’s look at an example in SAP Standard (a SOA tool called Error & Conflict Handler – ECH) where in most cases the structure has been chosen with regards to functional aspects like archiving:


I made the experience that many SAP customers don’t care about cohesion and the reason is very simple: the package concept is new and many SAP customers only know the concept of naming convention. As a consequence they create packages like ZFI for FI development, ZCO for CO development and so on. Software engineering finds the correct words for it: “coincidental cohesion” which Wikipedia calls the worst cohesion type because it has the semantics like: “develop here something with FI”. Of course this is the worst thing you can do: Is the development an extension of an existing FI process or a new process? Or is it used for migration? What about cross-cutting concerns used both for FI and CO – is it automatically BC? Sometimes those design criteria for packages are mixed with organizational aspects: FI guys develop in ZFI and are responsible for that package – but what happens if Basis developers develop parts of an FI process – is it part of package ZFI or ZBC? What happens if the organizational structure changes?

The answer is simple: If the development consists only of one or two reports resp. BAdIs, packages like ZFI and ZCO are useful. If the development gets more and more complex then packages with coincidental cohesion which have no clear focus tend to grow exuberantly. The consequence is that such maintenance will be difficult and expensive.


In this blog I discussed how packages can be structured and nested hierarchically. I explained how this affects to package checks: In a package hierarchy you can control access to contained packages: the packages may be coupled by using each other’s interfaces but not every interface has to be propagated by the surrounding packages.

Using packages you can group development objects as well as other packages. This can be done in different ways and I used the concept of cohesion as quality criteria. Usually cohesion used as property of smaller software modules but I think we can it apply general software pieces that are parts of applications.

Naming conventions are useful and I recommend using defined (and if possible unique) prefix for all elements in a package but should be aware that those naming conventions can’t replace the package concept because of the following reasons:

  • We can use the package concept to express different aspects of cohesion which reflects the architecture of the system.
  • We can use the package concept to support aspects of software logistics to group packages after transport layers and according to dependency to SAP software components.
  • With use access we make dependencies visible and we can express the aspect of coupling (which is different from cohesion): How are the dependencies between packages? Which dependencies are allowed and which are forbidden?

So my advice is the following:

  • Use naming conventions but don’t try to use them for challenges the package concept was made for.
  • Try to find a meaningful set of packages and think in terms of functional cohesion.
  • Don’t try to use all features of the package concept – use the ones that help you most.
  • Try to avoid complex package hierarchies. Have a look at recent developments in SAP standard to get inspiration.
To report this post you need to login first.


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

  1. Peter Inotai
    Hi Tobias,

    Thanks for this blog. It’s a great one… as always 🙂
    The topic is really interesting, but somehow package concept is not so important for in-house development unfortunately. The newly developed objects are just saved somewhere … most developers are still using packages like development classes.
    The whole story is different, when you have to develop components or add-ons, which could be independently installed to different systems.

    >What about cross-cutting concerns used both for FI and CO – is it automatically BC?
    Maybe for FI and CO you can still group them as some kind of mixed Accounting package.
    However when you mix different components like ERP and CRM you have to go to the direction to component ABA. I have the impression more and more SAP standard objects are moved here. I just recently discovered ABA_GEN and all the subpackages.

    I’m looking forward for the 7.30 related blogs.

    I wonder what will happen in customer systems, when package check won’t be optional anymore. It will be an interesting story 🙂


    1. Tobias Trapp Post author

      Hi Peter,

      in NW 7.30 you can still switch off package checks – in fact you have to change a system parameter. In fact the docu is wrong and I gave this feedback already to the docu writers – in some parts of SAP Help portal this is very simple because of the feedback mechanism.

      Please compare the package concept of NW 7.30 ( and NW 7.03 ( In fact both package concept are different and some IMHO confusing features of NW 7.30 vanished.



      1. Peter Inotai

        Hi Tobias,

        Thanks for the info about NW 7.03/7.30.

        I also noticed recently that in NW 7.03 a maintenance view PAKPARAM_V was created for these parameters. However I couldn’t find any IMG note for it yet, which would make sense to me.



  2. Paul Hardy
    I was at your talk at the SAP inside track in the Netherlands and I found it fascinating. Until such time as such a check does become compulsory you are going to have a hard time getting this concept over to people, as you will get the good old “it works fine as it is” argument. You need a big list of “this is what problem you are going to get eventually if you do not do this correctly” type examples.
    Also, can you really trust not only developers but SAP itself not to change the exposed elements of the interface, or is it enforced somehow?

    Cheersy Cheers


    1. Tobias Trapp Post author

      Hi Paul,

      I think the SAP package SAI is a good example. SAP introduced it very early and there have been many changes to it in 6.40, NW 7.0 SP 15, NW 7.01 and so on. The reason was simple: SAP optimized the web service infrastructure several times. Do you remember the transaktions WSCONFIG and WSADMIN – now you use SOAMANAGER. But if you used only elements that are exposed in packages interfaces everything was fine – although SAP changed even the data model.

      You are asking a good question: is it possible that SAP removes exposed elements? Of course it is – but it is also so possible that SAP deletes some data elements as it happened in CRM 7.0 upgrade. It is even worse: From a legal point of view most function modules and classes are not supported by SAP. But is it really a problem? From my experience ABAP developers can develop stable software if they look at SAP Business Suite:

      • If a framework is used in SAP Business Suite quite often then incompatible changes are not likely.
      • If development elements are exposed in package interface it is not that likely that SAP will do incompatible changes. Within SAP package checks are used, too.

      Let me summarize: Of course incompatible changes are possible and I give you examples: function module WS_UPLOAD is of no use in unicode systems. There have been even incompatible changes to ABAP language for unicode systems. If you want to minimize the risk of having trouble after a release upgrade then think of both advices from above: use frameworks hat are heavily used within SAP Business Suite and try to use only exposed elements.


  3. Rüdiger Plantiko

    Great blog, Tobias,

    and surely it is the best strategy to start development with a clear concept of packages and package dependencies.

    But for systems that have already been visited for a decade or so by many developers, coming from various consulting teams, each of them making not more than bringing precisely his particular task to work, usually leaves a chaos of Z packages and dependencies. Nobody will pay the effort for cleaning this up.

    For such a situation, I found a pragmatic approach for bundling development objects together without caring too much about their package membership: the piece lists of CTS (SE01).

    It doesn’t save me the work of decoupling, but it defines a new way of grouping development objects together, independent of the package hierarchy/ies. The piece list is a development object itself which can be maintained, transported and extended, like any other development object. On the other hand, it is a kind of “non-transportable transport”, which can be copied into a “real” transport.

    Together with a report Z_DECO_TRAN which helps me find forward references by looking at the DB tables CROSS, WBCROSSGT and WBCROSSI, I can add iteratively objects to a piece list until it contains no more cross references than to SAP_ABA and SAP_BASIS, which makes the object list transportable into any SAP target system. The name is in reference to a transaction DECO declared as SAP-internal which had a similar goal during HR decoupling.

    I have described the details (only in German language, sorry… ) in my blog



    1. Tobias Trapp Post author

      Hi Rüdiger,

      I like your blog and you cover cool and interesting topics like programming JavaScript in ABAP, DSLs and so on. Great work! I think many people would love to see your blogs on SCN.

      Please, can you explain the advantage working with a piece list? Another approach would be to create a structure package with dependencies only to ABA and BASIS. The package check in mode R3ENTERPRISE would show you unwanted dependencies.



      1. Rüdiger Plantiko

        Hi Tobias,

        thanks for your feedback on my blog. Blogging in the SCN might be a future option. [As you mention JavaScript in ABAP, by the way: It’s a pity that the class CL_JAVA_SCRIPT has been marked obsolote in SAP_BASIS 7.02, and the docu explicitly mentions that there will be no substitute! And this is in times where everybody is speaking about fluid, expressive syntax, where Java has incorporated a framework for dynamic languages, &c.]

        You are surely right: In a fresh SAP system, I would model the package dependencies from the beginning, as you outlined it in this blog series. But this is not feasible in a system which is already productive since 10 years, and dozens of consulting teams contributed their stuff.  From time to time, new SAP systems with dedicated purposes are added to the system landscape. We then use a piece list, which has only dependencies to SAP_ABA and SAP_BASIS, to import some of our core reusable software parts and tools into that system.

        The advantage is that the piece list is treated like a common development object in the source system: New objects can be added in the course of time, and the package assignments are secondary. This came out useful for us.



  4. Paul Hardy

    Hello, I have a question on this, which may well show my total alck of understanding of the whole concept.

    I copied an example class from the book “Design Patterns in Object Orientated ABAP” into my PI system, as it was the only one on Netweaver 7.0 at the time.

    This class uses the method CL_GUI_DOCKING_CONTAINER->GET_HEIGHT which appears at first glance to be public. The extended program check however throws up a red light which I think is related to the package interface saying “cannot use the class from package SCET in any of the usgae types use object or type”. A typical SAP message in that it is cryptic and obscure.

    A red light in the extended program check would prevent a transport out of the development system in our head office SAP system.

    Luckily I get pointed at an analysis tool which then throws up some more cryptic messages.

    I think I am being told to add some interfaces into the pacakge of the custom ABAP class under analysis. Would that be correct?

    Again, I am sorry if I have missed the whole point of this.

    Cheersy Cheers


    P.S. I am at Heathrow waiting to fly to Australia at the moment but all flights are delayed for an hour, to allow for the arrival of the Olympic Torch!

  5. Rudy Clement

    Hi Tobias,

    Thanks a lot for sharing your knowledge with the community! I was also present at the SAP Inside Track in Eindhoven last year were I saw your presentation. I found it very interesting!

    Me and my colleagues are currently trying to use the package concept within a new project at our customer. We are on a NW 7.02 system. But there is one thing we don’t understand. Some ‘common’ SAP objects are not exposed in any package interface. For example, when using class CL_ABAP_TABLEDESCR, the package check will give errors. There is no package interface that exposes this class while several other CL_ABAB_*DESCR classes are exposed via _AKB_INITIAL.

    Same problem for persistent classes: when using persistent classes, we want to catch exceptions from package SOS_EXCEPTION like CX_OS_OBJECT_NOT_EXISTING. But this package doesn’t have any package interface. The package check even gives an error on the base agent class which is fully generated by SAP!

    Do you have any explanation for this? Maybe (hopefully) we are just missing a part of the theory and you can guide us in the right direction… Or did SAP simply forget to add objects like these to package interfaces? If that’s the case, how should we handle this?

    Once again, thanks for sharing your knowledge!

    Kind regards,

    Rudy Clement.


Leave a Reply