How the Package Check Works
Prerequisites
The package check performed on SAP objects in a customer system does not usually return an error.
How the package check is performed depends on whether or not structure packages are to be included. See also
Example of a Check Scenario.In general, the package check takes place at two different levels:
|
At the structure package level |
This check takes place whenever the user package and the provider package are stored in different structure packages and ascertains whether or not the use relationship between the structure packages is allowed. |
|
|
At the level of the package check as a server or as a client |
The package attribute Package Check As Server causes a "strong" check to be performed. This means that all users must comply with the pure package check. If the Package Check As Client is assigned to a package, the package concept need only be complied with locally, not in every use case. This type of check is known as a "weak" check. |
Process flow (simplified)
If the system is to perform a restricted package check, it omits steps 1-5. See also:
In step (1) of the package check, the system queries whether or not the provider and user are in the same structure package. If they are, the subsequent check process is restricted to a package check as a server and a package check as a client. The check continues from step (6). If conversely the provider package and user package are in different structure packages, the system performs the complete check at the structure package level.
Firstly, it queries whether or not the user package has a use access for any of the interfaces to the package (2). If not, it displays an error message.
If the use access does exist, it ascertains the kind of package interface (3). If the interface is a virtual default package interface, the system then ascertains whether or not a filter has been defined between the two structure packages (a filter package interface (4)). If so, the system checks the filter. If not, it displays an error message.
Conversely, if the interface is a generated default package interface (with a set of exceptions), the system only checks whether or not the development used can be found in this interface (5).
Only if the check is successful at the structure package level does the system continue with the second level check (as a server or as a client). If the provider package (that is, the server package) has the Package Check as a Server flag checked (6), the system performs a "strong" check. Every user then needs a use access to at least one package interface containing the required development element.
If the system reaches the use access check, it takes the
If the provider packager does not have the Package Check as a Server flag checked, the system checks whether or not it has the Package Check as Client attribute (7). If it has, the system only returns an error message if there is no use access available for the user package, even though the provider package has made the object to be used visible in a package interface. If, however, the Package Check as Server flag is not set for the provider package, and if there are no package interfaces defined, the system displays only an information message.
If neither the Package Check as Server nor the Package Check as Client flag is set, the check is completed successfully.
See also:
Structure Packages