Skip to Content

ABAP Package Concept Part 4 – How to perform package checks

In the first parts of this weblog series I discussed basics of the ABAP package concept: package interfaces and package hierarchies and explained the benefits:

I can give the following résumé: If you want to create maintainable and evolvable software you need the ABAP package concept. I consider the package concept as the most important “new” feature of ABAP besides the web enabling (ICM and ICF) and object orientation! Unfortunately some aspects of the package concept are more complex than they should be – but don’t be afraid: There are very powerful tools that will help you too overcome problems. Now I explain how to switch on package checks and how to perform package checks as well as some pesky details.

Package checks can be performed in extended syntax check and within code inspector. There is also the possibility to check all elements of a package (and the elements of contained packages if you want) in transaction SE80. As a result you get list of package errors that you can resolve step by step guided by an explain tool and a wizard. When you resolve an error the former erroneous element changes its status so that you don’t have to refresh the whole list which might take a little bit. But before you can use the package concept you have to switch it on which is described in the following paragraph.

Transparent table PAKPARAM and “check as client” vs. “check as server”

In AS ABAP 7.0 to 7.02 package checks are switched off by default and you have to switch it on in transparent table PAKPARAM (see OSS note 792058). There are two package check modes:

  • “NONE” is the default value.
  • With check mode “RESTRICTED” you can perform checks against package interfaces.
  • Using check mode “R3ENTERPRISE” you can check dependencies between structure packages, too. This means that every package in a development system has to be in a package hierarchy of a structure package.

  When you switch to “RESTRICTED” or “R3ENTERPRISE” the maintenance dialog for ABAP packages has two check boxes:  “package check as client” and “package check as server”. The first option means that the package check will produce an error if when the package uses an object that is exposed in a package interface but declares no use access. This concept is a little bit redundant and will vanish from the UI with NW 7.31 (= AS ABAP 7.03). The mode “check as sever” is far more severe because packages have to declare use accesses and can only use elements exposed in package interfaces otherwise you will get an activation error. The activation error is very severe for usage of DDIC elements and you need a special authorization to prevent an activation error. But don’t be afraid, the transport system is not affected so they won’t be trouble if you import erroneous elements into an ABAP system. If you are interested in the details you can read it in the book ABAP Development from Scratch.  

“Enterprise” or “Restricted”

Use the check mode „R3ENTERPRISE“ only if you want to control the dependencies on the level of structure packages:

  • Which structure packages from SAP standard do you use?
  • What are the dependencies between custom developed structure package?

These features make sense in a larger development project: structure packages represent software components or huge applications within a huge software component – think of SAP_APPL for example that contains R/3 modules. Especially ISVs can benefit from this package concept:  

  • If you develop custom software components using the Add-On Assembly Kit from SAP or you have a complex development landscape it will help you increase software quality as well as installability.
  • You can reduce unwanted side effects from wrong dependencies: Let’s consider the case you are developing an add-on to FI or HR module and you are using development objects from IS-U solution then you will get into trouble when those show a different behavior after an IS-U business function is activated. Using the package concept you can control that you are building a “proper” add-on.

  Switching on package check mode “R3ENTERPRISE” has following consequences:  

  • All development packages in a system have to be in the package hierarchy of a custom structure package – otherwise you will get a large number of package errors.
  • All packages have to declare additional use accesses: structure packages have to declare a use access of a virtual default interface together with a filter interface or a default interface. Main packages or development packages have to declare use access of a virtual default interface or a default interface.
  • Your own structure packages should define interfaces: a virtual default interface together with a filter interface together with a default interface.

A personal opinion

In my opinion the ABAP package concept is more complicated than it should be:  

  • We have four different types of packages interfaces and three different types of packages.
  • With virtual default interfaces we can perform a “weak package check” that exposes all elements of a structure package (restricted to namespace which can be declared in a filter interface).
  • You can create defined lists of exposed elements in a so called default interface – unfortunately there are no usable tools to create such lists.

Luckily SAP created an explain tool that analyzes package errors and even contains a wizard that can solve package check errors.  

If you want to introduce the package concept do the following:

  • Start with package checks in a sandbox with package mode “RESTRICTED” and get familiar with the package concept. Check the results of the package concept and you’ll get a deep result in dependencies to SAP standard, soon.
  • Think of defining “strongly encapsulated” packages (package mode “as server”) for certain packages f.e. new developed applications, packages that will be transported in a complex landscape or the ones you want to redesign.
  • The design of structure packages is more complicated and you have to consider transport layers, dependencies within your overall development, dependencies to SAP standard, hierarchy of software components and so on. I recommend to start with “weak encapsulated” structure packages i.e. working with virtual default interfaces.
  • Don’t try to use all features of the package concept – choose a feasible subset.

NW 7.30 – the complexity raises

In NW 7.10 SAP introduced a change to the package concept of NW 7.0 – I learned about it when I developed in the ABAP stack of SAP PI. This package concept is the as in NW 7.30 and you can learn about in SAP Library, you can find a lot of additional OSS note 1148288 describing migration reports RS_MIGRATE_PACKAGE_INTERFACES and SPAK_CREATE_HYBRID_PACK_DATA. If you are confused: NW 7.30 is shipped in BW and pure AS ABAP systems– don’t mix it up with NW 7.03 (= AS ABAP 7.31).  

I won’t describe details of this package concept but I will give you my personal opinion:

  • From my point of view the NW 7.10 / 7.30 ABAP package concept is much too complicated for a pragmatic use. Instead to simplify it be reducing the number of package types SAP introduced new ones. The concept  of “weak” and “strong” encapsulation is well thought but SAP introduced more and more  features.
  • So I want to warn you: don’t use this package concept! You will have to migrate your “legacy” (= NW 7.0)  development and find a solution for the next EhP because NW 7.31 has the package concept from NW 7.02 that is incompatible with 7.30.
  • Switch the package checks off using ABAP profile parameter abap/package_check.

AS ABAP 7.31 – reason prevails

I already mentioned that the package concept of 7.31/7.03 is the same as 7.02 and there are some small improvements from which I mention the most important: “Package Check as Client” was removed from the UI and “package check as server” is called “Package Encapsulated”. Furthermore you can customize the extended syntax check is performed during activation.

In my opinion with AS ABAP 7.31 SAP has a pragmatic package concept that is still a little bit too complicated but the explain tool makes it easy to use.


In this blog I explained how to switch on the package checks, differences between AS ABAP releases and the explain tool will guide you in case of trouble. I explained to different check modes: “restricted” and “r3enterprise”. In this next instalment of this web log series I will explain best practices, f.e. how to start with the ABAP package concept.

You must be Logged on to comment or reply to a post.
  • Hello Tobias,

    thank you for your very detailed blog-series about the package concept. Especially for the parameter settings to turn them off/on;-)

    I also think, that SAP has bring us a good tool for handling the complexity and bring us more stability into our development process - but: The price is very high and it is much easier, to turn it off instead of using the tool the right way.

    In my projects I oftern alternate between using the package concept or ignore it. One thing, I am afraid, is the fact, that the way of using SAP standard modules/classes/interfaces will be very small if you use the package checks right. And this kind of limitation is one of the biggest arguments against using it.

    But if you develop your own software component/solution, it will bring a lot more clarification about a well designed application model and it helps to avoid violations against this.

    Kind regards,


    • Hi Hendrik,

      I think I'll continue the series with best practices.

      But there is something I would be very interesting to know: Can you image an ABAP package concept or features of it so that every ABAP programmer would love to use it?

      Best Regards,


      • Hi Tobias,

        well, your question is so nice, that i like it 😉 ( "ABAP" and "love" in one sentence ...)

        Of course, I can imagine: If it should possible, I would like to have a "wizard" - better a housekeeper - which assigns my objects correctly and takes more than 80% of the work for maintaining, package interfaces, ACLs and so on. Short: Every ABAP developer would love it, if it is calm but still integrated and used.

        For example: After activation of a development object, a huge list of violations occurs. The developer will get a dialog in which all actions to correct them appear and he will have the choice of perform them or not. Ok, the developer still have the responsibility and he should take all of them as "default", so we will not gain a lot more than today, but: a second audit can ensure, that these options are taken correctly (for example in a architectural review). As you may see, sometimes I even dream of a ideal world 😉

        The big advantage of ABAP is the high integration and high automation in some software engineering principles. So I think, I should not only adapt some concepts of other platforms in place of adapt them into the ABAP development concepts.

        Kind regards,


  • Hi Tobias,

    Thank you for this blog, it really clarifies many complex concepts of package design.

    We are currently starting to understand the real benefits of package design and are willing to make our first attempt but, we are still stuck in package check activation and possible impacts in existing developments.

    From OSS note 648898 - "Switching on the package check" we acknowledge the necessity of switching parameter GLOBAL_SWITCH to "RESTRICTED" in order to enable package checks but we are concerned with the possible impacts of this change.

    Wont this reveal all erroneous dependencies and possibly block current developments activation?

    If you could dwell on section "Transparent table PAKPARAM and check as client vs check as server" a little more we would be most appreciated.


    • If switch on package checks there can be activation of DDIC elements if they use "forbidden" objects. If developers have S_DEVELOP mit activity 94 (overwrite) for DEVC for the development package they can confirm the error message and activate the element.

      There are no other problems especially not with the transport system.

      So tell your developers that they will get some more error messages (but this exactly what you want) but they can nevertheless activate their objects and transport them.

      Best Regards,


      • Thank you Tobias,

        We have now successfully implemented our first package dependency-aware solution. We are now making an effort to repack our previous developments properly and accordingly to the package paradigm.

        Thank you for your help, very powerful concept.


  • Hi Tobias,

    Thank you for so much precious information.

    I have a main package ZA.

    I have a message class ZCX in an encapsulated package ZB. Another package ZC has an exception class which is referencing this message class in one of its texts.


    \--- ZB

          \- ZMSG

    \--- ZC

          \- ZCX

    I was expecting this to yield a package violation since the package ZB doesn't have any package interface nor package ZC has any use access for it.

    Afterwards, I tried to create a simple method TEST() in class ZCX with the statement MESSAGE S001(ZMSG). And now I get a package violation.

    So it seems like the checks are not taking into account the message classes used in exception classes. Do you think this is a bug in the package check? Or am I doing something wrong? I am using RESTRICTED mode.

    Thanks in advance,

    Nuno Godinho

    • How does ZCX work? Does it implement IF_T100_MESSAGE? And are you working with character literals moved to T100KEY? In this case the package violation can't be detected. But S001(ZMGS) in command MESSAGE S001(ZMSG) is no string literal and refers to ABAP dictionary objects that are under control of package checks.

      Could that explain the behaviour?

      Best Regards,


      • Hello Tobias,

        Indeed the ZCX has IF_T100_MESSAGE but I'm not doing any manual manipulation of the T100KEY. I simply associate TEXTIDs with specific messages using the standard SE24 interface and when I raise an exception with a specific text... the standard takes care of filling the fields with the correct message data.

        I think it would make sense for it to be detected since a message from that message class is being explicitly declared in the exception class.

        I'd say this can be seen as a bug, no?

        Thanks for your answer.