Entering content frame

Background documentation Creating Packages in the Enterprise Core Locate the document in its SAP Library structure

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.

This graphic is explained in the accompanying text

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.

This graphic is explained in the accompanying text

Using Objects from Other Structure Packages

Structure packages were introduced to apply rules, within the development and correction process, for using objects from different packages
One of the fundamental goals of this concept is to ensure that the two
software components SAP_HR and SAP_APPL remain technically independent. This means that objects contained in the structure package HR cannot use any objects that belong to the structure package APPL.

Initially, 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.
The table below summarizes examples of how object visibility is implemented in different structure packages and of the dependencies between them, within the R/3 Enterprise Core. Thus, it shows exactly how the structure package concept has been implemented in the R/3 Enterprise Core.

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.

Example

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

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.

 

 

Leaving content frame