The Package Concept

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 modularizeencapsulate, and decouple units in the SAP System.


A package is a container for objects that logically belong together; for example, all of the objects in an application. A package is also a type of development object.An example of a package might be ZSD,ZMM etc
When you create a new object or change an existing object, the system asks you to assign the object to a package.

Storing Development Objects

The SAP system stores development objects in the Repository, which is a part of the database.
When you complete work on a development object like a program, screen, or menu, you generate a runtime version of the object. This runtime version is stored, along with the object, in the Repository. An application consists of several runtime objects that are processed by the work processes in the SAP System.
In a standard SAP installation, development and live operation take place in separate systems. New applications are created in the development system and transported to the production system. Daily work takes place in the production system which uses run-time versions created in the development system.
The division between production and development systems is recommended because changes to an existing ABAP application take immediate effect. To prevent disturbances in daily work flow in the production system, all developments are carried out in development systems designed especially for this purpose.
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).
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.
(Source From

No comments:



All about contents or data or information taken from or other sap related web sites which are available on the Internet for this BLOG.
If you find any doubts or mistakes please refer the other SAP/ABAP related sites .