Creating Packages in the Enterprise Core
From Software Components to Structure Packages
How are structure packages and software components related?
In previous releases, software components were used to bundle packages that were always delivered together. For this reason, they now provide the foundation for the new package architecture of R/3 Enterprise. Each software component is directly identified with a structure package
Thus, the structure packages BASIS, ABA, HR, and APPL are derived from the software components SAP_BASIS, SAP_ABA, SAP_HR and SAP_APPL.
With the software component SAP_APPL, we also needed to split the component further, so we introduced two additional structure packages:
The two structure packages HR and APPL must be decoupled, so that they can be delivered in separate Support Packages.
The following graphic illustrates the link between software components and structure packages. It also summarizes once more how structure packages emerged from existing software components in the R/3 Enterprise Core.
From Software Components to Structure Packages
Why are the usual concepts of packages and main packages no longer enough?
Structure packages can reduce the organizational effort necessary
In large software projects, you generally have a large number of main packages. You must always define the use conditions between each main package explicitly, which can mean a lot of organizational work.
As containers for main packages, structure packages can contribute substantially to reducing this effort. "Use" accesses can then be defined at the structure package level. This reduces the number of use accesses needed between user and provider packages.
Additional possibilities offered by filter interfaces
The particular significance of filters in structure packages can be explained using an example:
Let us assume that the two packages, APPL and HR, are normal packages or main packages, not structure packages. Now let us consider the object O1 in APPL, which is contained in the package P1 and which is to be used by the object O2 from another package, P2 (see graphic). P2 is also a component of APPL.
First, you make the object O1 visible externally by adding it to the interface I1. This allows the user package P2 to create a use access to the interface I1 of P1. In this case, however, the object O1 is also visible to the package P3, so that it is not protected from accesses from P3. However, the package P3, belongs to HR. Objects from HR should not be allowed to use APPL objects, assuming that we want to ensure decoupling.
This is exactly where structure packages come into play: they allow you to filter out visible objects from other structure packages. The use of objects that belong to different structure packages needs to be explained at the structure package level first.
Using Objects from Other Structure Packages
Structure packages were introduced to apply rules, within the development and correction process, for using objects from different packagesInitially, each structure package is completely independent of each other structure package. In such cases, the use of objects from other structure packages would lead to an error if a
package check was performed.
Structure package |
Visible... |
Can use objects from ... |
BASIS |
in all other packages |
BASIS |
ABA |
in all other packages except BASIS |
BASIS or ABA |
HR |
only in HR |
BASIS, ABA, APPL_TOOLS, and HR |
APPL |
only in APPL |
BASIS, ABA, APPL_TOOLS, and APPL |
APPL_NU |
only in APPL_NU |
BASIS, ABA, APPL_TOOLS, APPL_NU, and APPL |
APPL_TOOLS |
in all other packages except BASIS |
BASIS, ABA, and APPL_TOOLS |
The reciprocal dependencies of the structure packages are a result of the use accesses of the user structure packages to the package interfaces of the provider structure packages.
Filters in Structure packages
Filters are special package interfaces that are only defined at the structure package level. Each filter can be used to limit the visible elements in a structure package to a certain number.
Thus if a client object O1 from the structure package S1 uses a server object O2 from another structure package S2, the package check checks that there is a use access from S1 to the filter package interface S2 that contains the object O2. If there is not, the package check displays an error message.
To use objects from the structure package BASIS within the structure package APPL, APPL needs a use access to the filter package interface _BASIS_FILTER (see the table below).
Note that the existence of a suitable use access to a package interface is a necessary but insufficient condition for the legal use of a server object from another structure.
Ultimately, you must also ensure that the filter also "allows the use to happen". Moreover, the used object may be visible in an interface of the provider structure package and a suitable use access may exist from the user structure package, but the filter prevents the specific object involved from being used.
Structure package |
Filter interface (technical name) |
Description |
BASIS |
_BASIS_FILTER |
Filter that allows objects from BASIS to be used externally. |
ABA |
_ABA_FILTER |
Filter that allows objects from ABA to be used externally. |
HR |
_HR_FILTER |
Filter that allows objects from HR to be used externally. |
APPL |
_APPL_FILTER |
Filter that allows objects from APPL to be used externally. |
APPL_NU |
- |
No filter interface defined. |
APPL_TOOLS |
_APPL_TOOLS_FILTER |
Filter that allows objects from APPL_TOOLS to be used externally. |