The Package Concept 

Current situation

At present, the SAP System contains more than 300 000 development objects (programs, tables, screens, BAPIs, function modules, types, and so on). These objects are grouped in over 1700 development classes stored in a flat structure.
Any developer can use any object. A developer can hardly set up a protection for his own development objects. He can also only with difficulty mark the development objects that he would like to make available to others. The technical modularization options open to developers on a small scale – for example, using module pools, function groups, or classes – are very limited. Whether on a large or small scale however, there are no mechanisms for technical modularization.
The package concept was developed to address these issues. Packages are a further development of the current development classes with new additional semantics. They are designed to help developers modularize, encapsulate, and decouple units in the SAP System.

Packages

Existing development classes are simply containers for development objects with a transport layer that determines how the objects will be transported. Packages extend the concept of development classes with the addition of new attributes: nesting, interfaces, visibility, and use accesses.

·         Nesting allows you to embed packages in other packages.

·         Visibility is a property of package elements. Elements may be visible outside their package. However, they are always visible to other elements in the same package and always invisible to embedded (sub-)packages within their package. For an element to be visible outside the package, it must be contained in at least one package interface.

·         Use access is the right of one package to use the visible elements in the interface of a second package (but not the other way round).

The following graphic illustrates these properties:

 

Packages use interfaces and visibility to make their services known to other packages. All the visible elements in a package can, potentially, be sued by other packages. In contrast, invisible elements cannot be used by other packages as well. This allows the package to encapsulate its contents and protect its elements from being used by unspecified external packages.

Use accesses restrict the use of the visible elements of other packages’ interfaces. Not all visible elements can be used. A package can only use the visible elements of the provider package after the use access to the latter’s interface has been created.

Nesting allows you to split up larger units of the SAP System and structure them in a hierarchy. The interplay between interfaces and use accesses allows the elements of a package to be hidden simply, and thus protect them from unintentional use.

The package concept also offers the option of splitting and encapsulating the SAP System into technical units (the packages), reducing high levels of dependency and thus decoupling the system on a large and small scale.

For either the user package, provider package, or both, there may be consistent exceptions to the package check. This is, for example, makes sense in system programs or generated programs.

There is also a transitional phase for migration projects in general, during which package checks will be less strict.