ABAP Package Concept Part 4 – How to perform package checks

[ttrapp]

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:

• We can structure ABAP applications.
• We can define packages interfaces.
• We can define hierarchies of packages with main and structure packages at the top.

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.

Summary

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.