Workbench Tools - Package Builder

The Package Builder and the ABAP Package Concept
PDF download from SAP Help Portal:

http://help.sap.com/saphelp_nw73ehp1/helpdata/en/af/40bd38652c8c42e10000009b38f8cf/content.htm
Created on April 03, 2014
The documentation may have changed since you downloaded the PDF. You can always find the latest information on SAP Help Portal.
Note
This PDF document contains the selected topic and its subtopics (max. 150) in the selected structure. Subtopics from other structures are not included.
2014 SAP AG or an SAP affiliate company. All rights reserved. No part of this publication may be reproduced or transmitted in any form or for any purpose
without the express permission of SAP AG. The information contained herein may be changed without prior notice. Some software products marketed by SAP AG
and its distributors contain proprietary software components of other software vendors. National product specifications may vary. These materials are provided by
SAP AG and its affiliated companies ("SAP Group") for informational purposes only, without representation or warranty of any kind, and SAP Group shall not be
liable for errors or omissions with respect to the materials. The only warranties for SAP Group products and services are those that are set forth in the express
warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty. SAP and other
SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and other
countries. Please see www.sap.com/corporate-en/legal/copyright/index.epx#trademark for additional trademark information and notices.
Table of content
PUBLIC
2014 SAP AG or an SAP affiliate company. All rights reserved.
Page 1 of 28
Table of content
1 The Package Builder and the ABAP Package Concept
1.1 Use Case 1: Defining Package Hierarchy
1.1.1 Creating Structure Packages
1.1.1.1 Structure Packages
1.1.1.2 Types of Package Interfaces for Structure Packages
1.1.2 Creating Main Packages
1.1.3 Adding Development Packages
1.2 Use Case 2: Making Services Available
1.2.1 Creating Package Interfaces
1.2.2 Adding Elements to a Package Interface
1.2.3 Restricting the Use of the Interface
1.2.4 Extending Visibility over Several Levels
1.2.4.1 Graphic: Extending Visibility
1.3 Use Case 3: Using Services from Other Packages
1.3.1 Creating Use Accesses
1.3.2 Permissible Use Accesses
1.3.3 Visibility Rules in Subpackages
1.3.4 Accessing Content from Another Package Hierarchy
1.3.4.1 Case 1: Using Filter and Virtual Standard Package Interfaces
1.3.4.2 Case 2: Using Standard Package Interface
1.3.4.3 Case 3: Using All Structure Package Interfaces
1.3.4.4 Case 4: Using Interfaces From First Non-Structure Package Level
1.3.4.5 Case 5: Server Package Hierarchy with Nested Structure Packages
1.4 Package Architecture in SAP ERP
1.4.1 From Software Components to Structure Packages
1.4.1.1 Software Components in SAP ERP
1.4.2 From Packages to Structure Packages
1.4.3 Using Objects from Other Structure Packages
1.4.4 Applying Filters in Structure Packages
1.5 Package Checks and System Settings
1.5.1 Performing a Package Check
1.5.2 Analyzing Use of Foreign Package Objects
1.5.3 System Settings
1.5.4 Package Check Scenario
1.6 Appendix
1.6.1 Short Overview of the Package Concept
1.6.2 Naming Conventions for Packages
1.6.3 Transfer Packages from SAP NetWeaver 7.30 to SAP NetWeaver 7.31
PUBLIC
Page 2 of 28
1 The Package Builder and the ABAP Package Concept
Purpose
The Package Builder tool allows you to implement the concept of the packages in the ABAP Workbench. Packages are designed to help developers to
modularize, encapsulate, and decouple units in the SAP System.
Features
Create packages and their subpackages
Build up a package hierarchy
Define package interfaces for potential users
Expose repository objects to package interfaces
Define use access for client packages
Restrict the use of interfaces to selected users
Use of Packages
Packages can be either server (provider) or client (user) packages. Server packages offer services to other packages by exposing elements (function modules,
BAPIs, classes, ABAP programs, types, and so on) into one or more package interfaces. A server can also take on the role as a client, availing itself of the
services of other packages.

In the documentation that follows, we have assigned a variety of activities to each of these two roles (server and client). Each scenario explains how you use the
Package Builder and which activities are relevant.
Tasks for Server Packages
I. Creating packages and defining the package hierarchy
For more information, see Use Case 1: Defining the Package Hierarchy
II. Making Services Available
For more information, see Use Case 2: Making Services Available
Tasks for Client Packages
I. Creating packages and defining the package hierarchy
For more information, see Use Case 1: Defining the Package Hierarchy
II. Using services
For more information, see Use Case 3: Using Services from Other Packages
Package Checks
Package Checks and System Settings
Package-based Architecture
Package Architecture in SAP ERP

1.1 Use Case 1: Defining Package Hierarchy
The main focus of this scenario is simply to provide a structure for packages. This concerns all packages equally, whether they are servers (providers) or clients
(users).
The top level in the package hierarchy is formed by structure packages, generally consisting of several main packages. You then create the associated
development packages as subpackages from within each main package. This process allows you to specify the number and granularity of subpackages, along
with the depth to which they are nested.
Relevant Activities:
Creating Structure Packages
Creating Main Package
Adding Development Packages

PUBLIC
Page 3 of 28
Use
Structure packages have been introduced in the context of the SAP ERP applications. They form the top level in the package hierarchy and are used to define the
conditions under which system components are decoupled.
In particular, you always have to create a structure package to define the root of a new package hierarchy.
Prerequisites
To create or change a structure package you need authorization for the activity 02 (Change) in the authorization object S_PACKSTRU.
To specify the transport layer of the package to be created, you also need corresponding CTS authorization (authorization object S_CTS_ADMI or
S_CTS_SADM).

Procedure
To create a structure package as a root for a new package hierarchy, proceed as follows:
Open the Object Navigator (SE80), choose the Repository Browser and Package as the repository type.
In the input field, enter a name for the new package that complies with the Naming Conventions.
Within SAP itself, the name must begin with a letter from A to S, or from U to X.
Choose Create.
The system displays the Create Package dialog box.
Enter the following package properties:
Short Description
Enter a meaningful short text.
Application Component
From the component hierarchy of the SAP system, choose the abbreviation for the application component to which you want to assign the structure package.
Software component
The software component describes a set of development objects that can only be delivered in a single unit. Later, you will assign all the main packages of the
structure package to this software component. Exception: Packages that will not be delivered to customers must be assigned to the HOME software component.
Choose the appropriate entry.
Transport Layer
This property defines the transport behaviour of the package - that is, whether the package and all its elements are transported.
This property is only available if you have the corresponding CTS authorization for the system (see prerequisites above).
Package Type
Choose Structure Package.
Choose (Continue).
In the dialog box that appears, assign a transport request.
Result
The Package Builder displays the Properties of the new package.
You have created an empty structure package that serves as the root for a new package hierarchy. Now, you can continue to build up the package hierarchy and
add further subpackages.
Each structure package can contain either further structure packages or main packages or development packages as subpackages.

Example
BASIS, ABA, HR, APPL, and APPL_TOOLS are all examples of structure packages that are delivered with SAP ERP.

PUBLIC
Page 4 of 28

Use
A structure package bundles a set of packages at the top level of the package hierarchy. Structure packages do not contain any repository objects except for its
own package interfaces and subpackages. Instead, they hold several main packages and are used to structure software projects. You can also use structure
packages to specify the conditions for decoupling software components. Thus, they have a special significance as far as defining the basic architecture of SAP
ERP is concerned. Examples of structure packages include BASIS, ABA, HR, and APPL.
Characteristics
Structure packages define the top node of a package hierarchy (above the main package level)
Structure packages contain only other packages, not development objects
Their package interfaces are used to specify the relationships between structure packages, not to add development objects.
In contrast to main packages and standard development packages, you can define filter package interfaces, default package interfaces and virtual default
interfaces for structure packages.
You can bundle several structure packages in a surrounding structure package, which means that all SAP packages could be bundled together in one
structure package (SAP).
See also:
Types of Interfaces for Structure Packages
Using Objects from another Package Hierarchy

1.1.1.2 Types of Package Interfaces for Structure Packages
Structure package interfaces define the use relationships at the highest level of the package hierarchy. For example, in order to use the repository objects from
the structure package BASIS within the structure package APPL, APPL needs to declare a use access to the filter package interface _BASIS_FILTER. This
package interface allows repository objects from BASIS to be used externally.

In general, there are three types of package interfaces available in structure packages:
Virtual Standard Package Interface
The package interface (implicitly) contains the repository objects of all non-encapsulated packages belonging to the structure package.
Filter Package Interface
A filter (filter package interface) is a special package interface that can only be defined at the structure package level. It is necessary to add such a filter in the
following use cases:
A client (consumer) package hierarchy wants to use the virtual standard package interface of a server (provider) package hierarchy.
A client package hierarchy wants to use the package interfaces at the first non-structure package level.

The declaration of the use access to the filter package interface takes place at the top-level client package only. With this use access, a contract between the
provider and the client package hierarchy is established. In other words: it is the prerequisite that both, the virtual standard package interfaces and the package
interfaces of the first non-structure level become visible for the client package hierarchy.
However, a use access declaration in a regular development package on the client-side is not necessary.
See also: Case 1: Using Filter and Virtual Standard Package Interfaces
Standard Package Interface
This type of package interfaces contains a set of repository objects from the provider package hierarchy that are chosen for external usage. A structure package
can have multiple standard package interfaces. These package interfaces do not require a declaration of use access to the filter package interface on the client-
side.

See also: Case 2: Using Standard Package Interface

1.1.2 Creating Main Packages
Use
PUBLIC
Page 5 of 28
A main package is primarily a container for repository objects that belong together, in that they share the same system, transport layer, and customer delivery
status. However, a main package cannot contain any further repository objects except of its package interfaces and subpackages. Subpackages can be
additional main packages and regular development packages.
Prerequisites

You have the authorization for the activity L0 (All Functions) and the object type DEVC in authorization object S_DEVELOP.
You are already authorized to create main packages if you have authorization to create or change structure packages.
To specify the transport layer of the package to be created, you also need the corresponding CTS authorization (authorization object S_CTS_ADMI or
S_CTS_SADM).
The superpackage of the main package to be created exits already in the relevant system. This superpackage serves as the anchor for adding the new
package to the package hierarchy.
Procedure
You can add (main) packages to a superpackage in two ways. You can
create new subpackages directly from within a superpackage
Or
add existing packages to a superpackage.
To create a new subpackage to the given superpackage:
Open the Object Navigator (SE80), choose the Repository Browser and Package as repository type.
In the input field, enter a name of the direct superpackage.
Right-click on the superpackage name in the object list and choose Create Development Coordination Package.
Specify the following package properties:
Package
Enter the name for the new package that complies with the Naming Conventions for packages. Within SAP itself, the name must begin with a letter from A to S, or
from U to X.
Short Description
From the component hierarchy of the SAP system, choose the abbreviation for the application component to which you want to assign the new package.
Software Component
Select an entry. The software component describes a set of development objects that can only be delivered in a single unit. You should assign all the
subpackages of the main package to this software component.Exception: Subpackages that will not be delivered to customers must be assigned to the HOME
software component.
Transport Layer
This property determines the transport behaviour of the package - that is, whether the package and its elements are transported.
This property is only available if you have the corresponding CTS authorization for the system (see Prerequisites).
Main Package
This checkbox appears only if you have the appropriate authorization (see Prerequisites).
To indicate that the package is a main package, check this box.
Choose (Continue).
The Package Builder displays the Properties of the new package.

To add an existing package to a superpackage:
Open the Properties page of the superpackage and choose the Add button from within the
Subpackages tab and then enter the name of the package.
PUBLIC
Page 6 of 28
Result
You have created your main package and can now define a structure within it. Generally, you will continue by adding subpackages to the main package. Each
main package can contain either further main packages or development packages.

1.1.3 Adding Development Packages
Use
While structure and main packages form the higher levels of the package hierarchy, the development packages (with the exception of local packages), are
always subpackages and can, in turn, be used as superpackages for further development packages.
Development packages are regular packages that can contain any number of repository objects.
Prerequisites
To create or change a development package you need authorization for the activity 02 (Change) and object type DEVC in the authorization object
S_DEVELOP.
To specify the transport layer of the package to be created, you also need the corresponding CTSauthorization (authorization object S_CTS_ADMI or
S_CTS_SADM).
The superpackage of the package to be created exits already in the relevant system. This superpackage serves as the anchor for adding the new package
to the package hierarchy.
Procedure
You can add packages to a main package in one of two ways. If you wish, you can create new sub packages - from within a main package - and assign them to
the main package at the same time. Alternatively, you can add existing packages to a main package in a separate step.

To add a new subpackage to a given superpackage:
Open the Properties page of the direct superpackage.
Starting with Object Navigator (SE80), open the Properties page of the direct superpackage.
Alternatively, you can create a new subpackage from the superpackage's object list in the SE80 using the context menu Create Development Coordination
Package.
Make sure you are in Change mode.
Choose the Subpackages tab.
To create a new subpackage, choose the Add button.
Specify the following package properties.
Package
Enter the name for the new package that complies with the Naming Conventions for packages. Within SAP itself, the name must begin with a letter from A to S, or
from U to X.
Short Description
From the component hierarchy of the SAP system, choose the abbreviation for the application component to which you want to assign the new package.
Software Component
Select an entry. The software component describes a set of development objects that can only be delivered in a single unit. You should assign all the
subpackages of one main package to this software component. Exception: Subpackages that will not be delivered to customers must be assigned to the HOME
software component.
Transport Layer
This property determines the transport behaviour of the package - that is, whether the package and its elements are transported.
This property is only available if you have the corresponding CTS authorization for the system (see Prerequisites).
PUBLIC
Page 7 of 28
Choose (Continue).
If the package already exists, choose the Add Existing Package button.
Result
You have created one or more subpackages and added them to a superpackage. To add subpackages to an existing package (that is, to nest subpackages),
double-click a package and follow the instructions above.

See also:
Visibility Rules in Embedded Subpackages

1.2 Use Case 2: Making Services Available
A structure for the server (provider) package hierarchy is already available in this use case. The package interfaces may or may not be available.
You use the package interfaces to specify which repository objects you want to be visible to other packages. When you add elements to interfaces, you can group
them according to semantic or use criteria. You can also nest packages at different levels, and specify at each level whether you want to release the elements of
the interface. Finally you can apply constraints to the use of an interface, by naming exclusive users.
Creating Package Interfaces
Adding Elements to an Interface
Restricting the Use of the Interface
Extending Visibility over Several Levels

1.2.1 Creating Package Interfaces
From the outside, an encapsulated package looks like a "black box." To make the content of a package visible from the outside so that it can be used, you define
package interfaces. Only those package elements that have been added to an interface can be used by other packages. In other words: packages make their
services available to other packages providing package interfaces.
A package can contain multiple package interfaces, each with a different name. When you add new package interfaces to a package, the creation procedure
differs a little depending on the package type. In particular, you have to distinguish between package interfaces for
Structure packages (see also: Types of Package Interfaces for Structure Packages)
Mainand development packages.
Prerequisites
You have the authorization to change the package for which the interface needs to be created.
Example
For example, you are authorized to add a package interface to a structure package only if you have authorization to create or change structure
packages.
The package for which the package interface needs to be created must exist in the ABAP system and have an active version.
Procedure
To create a package interface (example: filter package interface) for a structure package:
1. Launch the Object Navigator (SE80) and open the relevant structure package in the package editor.
2. Make sure the editor is switched to Change mode.
3. Select the Package Interfaces tab.
4. Choose the Create button.
5. Enter the name and short description for the structure package interface.
6. To create a filter, select the option Filter Package Interface .
PUBLIC
Page 8 of 28
Figure: Defining a filter for a structure package
7. Choose Continue .
8. Choose to save your entries.
9. In the dialog box that appears, assign a transport request.
Note
With the steps above, you have created a (filter) package interface for the structure package. Up to this point, the procedure does not vary if you create
other types of interfaces for structure packages.
To add filter conditions (no longer required in SAPNetWeaver release 7.31 SP5!) for the elements exposed in a package filter interface, continue the procedure as
follows:
1. Double-click the entry for the newly created filter package interface to open the corresponding editor.
2. Select the Visible Elements tab and then choose the Add button.
3. Define the filter conditions by editing
1. PCHK as a value for Object Type and
2. EVERYTHING as a value for Development Element .
Figure: Defining a filter
condition for a filter package interface
Figure: Filter conditions that will become effective during the package check
To create a package interface for a main or development package:
1. Launch the Object Navigator (SE80) and open the relevant package in the package editor.
Note
Alternatively, you can create a package interface from the package's object list in the SE80 using the context menu Create Development
Coordination Package Interface .
2. Make sure the editor is switched to Change mode.
3. Choose the Package Interfaces tab.
4. Choose Add .
The system displays the Create Package Interface dialog box.
5. Enter a name and short description for the package interface.
7. Choose to save your entries.
8. In the dialog box that appears, assign a transport request.
Result
You have created an interface for the package. Each interface you create is an independent transport object, separate from the package.
You can now add package elements to the interface to make the elements in it visible to other packages.
Related Information
Adding Elements to a Package Interface
PUBLIC
Page 9 of 28
Use
Elements in encapsulated packages are not visible - and therefore usable - automatically. This allows package elements to be protected from access. To make
an element in another package available so that it can be used, you make it visible to other packages by assigning it to one or more package interfaces.
You can also specify the level of support for the element by defining the value of the Release status attribute. In this way, you can specify how long you want an
element to be compatible.
Prerequisites
The elements you want to add to a package interface are either in the same package as that interface or are included in an interface belonging to one of the
package's sub-packages.
Procedure
To add package elements to an interface:
Display the relevant package interface in the Package Builder.
Select Change mode.
Choose the Visible elements tab.
To add an element, choose the Add button.
The system displays the Visible element dialog box.
Enter the other attributes for the element:
Object type
Choose the appropriate object type. You can obtain a list of possible entries by choosing F4.
Development element
Enter a name for the element.
Release status:
You can assign the following values:

Choose .
Alternatively, in step 3, you can add an element from the object list tree structure using Drag&Drop.
Result
You have now added one or more elements to a package interface. These elements are now visible - and can be made available as services - to other packages.
Thus by definition, any element that does not belong to an package interface cannot be used by other packages - that is, access to it is prevented.
See also:
Not supported (assigned by default) Every element is assigned this value by default. This value reveals nothing about the
future availability or compatibility of the element, which may remain unchanged for
several releases, but which could become incompatible at any time.
Obsolete If you assign this value to an element, it will not be supported in the next-but-one
functional release. (This is similar to the way Change Management is applied to BOR
object types and their components). Until then, element is treated as if it were supported
(in terms of compatibility and availability).
Usually, the developer will provide a new element to replace the obsolete one.
Supported If you assign this value to an element, you guarantee that the element will remain
available for at least the next three functional releases, and that during this time, only
compatible changes will be made. (This is similar to the way Change Management is
applied to BOR object types and their components)
Not supported (assigned by developer) You choose this value to emphasize the fact that you cannot make any assumptions
about the availability or compatibility of the element.
PUBLIC
Page 10 of 28
Creating Use Accesses

1.2.3 Restricting the Use of the Interface
Use
By default, all the elements in a package interface are visible to - and thus can be used by - all the packages at the same hierarchy level. In some cases,
however, the provider package may want to restrict the use of an interface to one or more user packages. For example, an interface might provide critical
functions that could cause data inconsistencies and that can only be used correctly by a particular package in a specific context. In such a case, it would be
undesirable for other packages to be given use access to this special interface.
Provider packages can make their interfaces available only to certain users, preventing other packages from using them. See also: Graphic: Permissible Use
Accesses
Prerequisites
You have created a package interface.
Procedure
To name the only packages allowed to use an interface:
1. Choose the interface belonging to the provider package.
2. Make sure you are in Change mode.
3. Choose Restriction on user packages.
4. Check the Restriction on user packages.
The lines in the table are now ready for input.
1. Under Packages, enter the user packages that are permitted to use the interface.
2. Note that the packages you enter do not necessarily have to be in the current system. The Package Builder does not perform any further checks on the
package to ensure that its use access is authorized.
3. Choose Save.
Result
You have specified the only user packages entitled to use a particular interface of the provider package. Other packages do not obtain use access, which means
that they cannot use the interface elements, even if the latter are visible.
See also:

1.2.4 Extending Visibility over Several Levels
Use
The nested package concept allows you to release different elements of an interface at different levels. At each separate level of nesting from the inside outwards,
you can decide whether or not a visible element in an embedded package should remain visible to the next level outwards. In this way, you can specify, for
example, that development objects can only be used within a main package and not between two main packages.
Conversely, if you want a visible element within a main package to be available for other main packages, then you must extend visibility over several levels until
the other main packages can see it. The following graphic clarifies this concept.
Prerequisites
Only the innermost sub-package has an interface with the elements assigned to it.
Procedure
To extend the visibility of interface elements from a sub-package outwards:
Choose the package immediately surrounding this sub-package.
Create an interface for this package.
For more information, see Creating Package Interfaces.
Double-click the name of the interface you have just created.
The system displays it.
Choose the Visible elements tab.
Choose the Add package interface button.
PUBLIC
Page 11 of 28
The system displays the Choose the package interface you want to add dialog box.
Choose the interface belonging to the inner sub-package.
Choose to confirm your entries.
Choose to save.
Result
You have extended the visibility of the elements in the embedded packages one level outwards. These elements have the same attributes in interfaces at all
levels and are now available to additional users at every nested level that has an interface to them.

1.2.4.1 Graphic: Extending Visibility

The above graphic clarifies the principle of extending the visibility of package elements over several levels.
P1 and P2 are two main packages. The object IF_1 (from the sub-package P1_2) is passed up to the interface I1 (of the main package P1) using the package
interface I2_3 through I1_2. This makes it visible in P2. Conversely, the element FM_1 is only added to the package interface I2_1, so it is not passed up to the
next level. This means that its visibility is not extended any further; it is limited to subpackage P1_1. In contrast, TAB_1 cannot be seen outside P1_2, since it
has not been added to any of its package interfaces.

1.3 Use Case 3: Using Services from Other Packages
A structure for the client package hierarchy is already available in this use case. From the client package, you specify use access for the visible elements of
another package assigned to its interface.

1.3.1 Creating Use Accesses
Use
User packages cannot make use of all the visible elements of an interface of a provider package, unless there is use access available for it ("only visibility
together with use access permits use"). The package immediately surrounding the embedded package is the only package that does not require use access for
the interface, since here use access is implicit.
For migration projects, you can specify different levels of use by classifying error severity.
You have the option of creating use accesses either individually, for one package interface at a time (single maintenance), or in a mass maintenance transaction.
In the second case, you can adopt all use accesses from the direct superpackage. If any use access has already been defined for the respective package using
single maintenance, this will not cause any conflict. Then, only all the remaining use accesses for the superpackage will be added.
Prerequisites
The suitable package interfaces of the provider package already exist.
The use access you want to define follows the rules of the package concept. More information: Permissible Use Accesses.
The direct superpackage has suitable use accesses that are to be adopted by the subpackage (only for mass maintenance).
Procedure
PUBLIC
Page 12 of 28
Procedure
Create Single Use Access
1. Choose the client package.
2. Choose the Use Accesses tab.
4. Choose Create.
The system displays the Create Use Access dialog box.
5. Make the required entries:
Enter the Package Interface to which the use access should refer.
Classify the level of use permission with Error Severity only if you do not wish to adopt the generated default value. You should do this only when migrating
the generated use interfaces, and even then, only if you intend to update the use access.
All values that differ from the default value No Reaction for error severity no longer mean genuine permission, but rather refer to varying degrees of
prohibition of use.

6. Choose (Continue).
7. Save the new values.
Adopt Use Accesses from Superpackage
1. Choose the client package.
2. Choose the Use Accesses tab.
4. Choose Adopt from Superpackage.
5. The Package Builder adds all the Use Accesses from the direct superpackage. You have the option of specifying the error severity - different from the
superpackage - in the corresponding field.
6. Save the new values.
Result
You have created for a user package all the required use accesses to the required interface(s). In this way, the user package can use all visible Repository
objects of the listed provider packages.

1.3.2 Permissible Use Accesses
The following graphic indicates which use accesses to the server package interfaces comply with package concept rules.
For packages at the same level
Only packages P1 and P2 are entered in interface I3 as exclusive users. P4 cannot have use access to I3.
For packages at different hierarchy level and with the same root package.
Error Severity Meaning
No Response Default value
The system does not respond when you use interface elements (true permission).
Information If you use interface elements, the system displays an Information message when
you run an error check with transaction SLIN.
Warning If you use interface elements, the system displays a Warning message when you
run an error check with transaction SLIN.
Error If you use interface elements, the system displays an Error message when you run
an error check with transaction SLIN.
Obsolete After performing an error check, the system classifies the interface elements as
obsolete and then they should no longer be used.
PUBLIC
Page 13 of 28
a). The use access cannot break through a package - that is, access a server package without using an interface (see the graphic on the right).
Nor can the client package access a server package without a package interface. In the graphic below, the package P2 has to define a package interface I2.

b). Use access is only granted after all the relevant superpackages have also received their use accesses
In a case such as depicted below, you must first create the use access for the package superpackage package P1. The client package P1_1 can then access
the package interface I2 of the server package P2.
See also:
Visibility Rules in Embedded Sub Packages
1.3.3 Visibility Rules in Subpackages
Nested packages have a special relation between packages and their subpackages that also comes along with a restriction of visibility. As a general rule, the
visibility has a one-way effect, namely from top (surrounding package) to the bottom (subpackages).
This means that elements in sub packages are always visible and accessible within their surrounding package (see graphic on the left).
However, the elements of the surrounding package are always invisible (and therefore not accessible) in embedded packages (see graphic on the right). For
instance, it is not allowed for an ABAP program in the subpackage P2_1 to call a function module or so from the package P1.

Note
This behaviour is analogous to the layering principles of the software components. A higher-level software component can always use development objects
from a lower-level software component, but never the other way round. For instance, in SAP ERP this principle entails that development objects from the
SAP_BASIS are not allowed to access the application's layer SAP_APPL. In the reverse direction however, it is always granted for the applications
components to use the SAP_BASIS functionality.

.

PUBLIC
Page 14 of 28

.

1.3.4 Accessing Content from Another Package Hierarchy

In order for a repository object to be able to access contents from another package hierarchy, a type of linkage between the client package hierarchy and the
server package hierarchy must be created at the highest package hierarchy level. Since the root packages for a particular package hierarchy are usually
structure packages, the general requirements for a linkage between the package hierarchies at the top level of structure packages are fulfilled. The corresponding
structure package on the server side must provide suitable package interfaces for this, whereas the client side must register on the package interfaces by
declaring the respective use access.
To demonstrate more clearly the connections between the structure packages and the required use accesses, we will make a distinction between the cases
described below:
Case 1: Using Filter and Virtual Default Package Interfaces
Case 2: Using Default Package Interface
Case 3: Using All Structure Package Interfaces
Case 4: Using Interfaces From First Non-Structure Package Level
Case 5: Server Package Hierarchy with Nested Structure Packages

1.3.4.1 Case 1: Using Filter and Virtual Standard Package
Interfaces

Description
Let's assume that a server structure package provides a
Filter package interface
Virtual standard package interface.
Solution
In order for the client package hierarchy to be able to use visible repository objects from the server package hierarchy, the client structure package has to declare
a use access for the filter package interface that is defined at the server structure package level.
The declaration of the use access to the filter package interface takes place at the top-level client package only. With this use access, a contract between the
provider and the client package hierarchy is established. In other words: it is the prerequisite that both, the virtual standard package interfaces and the package
interfaces of the first non-structure level become visible for the client package hierarchy.
To access the repository objects that are contained in the virtual standard package interface, the respective client package and all its superpackages - up to the
level of the structure client package - have to declare a use access for that virtual standard package interface.

The above graphic clarifies the principle of using objects from another package hierarchy:
PUBLIC
Page 15 of 28
SP1 and SP2 are two structure packages and form the root of two different package hierarchies. SP1 acts as a client structure package and contains a main
package MP11, which itself contains a standard development package P111. SP2, on the other hand, acts as a server structure package and provides a filter
package interface FILTER_2 and the virtual standard package interface VIRT_DEF_2.
In such a case, the client structure package SP1 must declare a use access to the filter interface FILTER_2.
In addition, a virtual standard interface VIRT_DEF_2 is defined in the structure SP2. This interface, however, must be entered in the actual client package P111,
in its superpackages MP11 and SP1, to declare the use access to all non-encapsulated subpackages of SP2.

1.3.4.2 Case 2: Using Standard Package Interface

Description
Let's assume that a server structure package provides a standard package interface. There are no other package interfaces defined in this structure package.

Solution
To use the repository objects that are exposed in the standard package interface, the respective client package and all its superpackages - up to the level of the
structure client package - have to declare a use access to that standard package interface.

The above graphic clarifies how the usage of the standard package interface is linked to use access to be declared on the client-side package hierarchy:
SP1 and SP2 are two structure packages and form the root of two different package hierarchies. SP1 acts as a client structure package. It contains a main
package MP11, which itself contains a regular development package P111. The actual client package P1111 is a subpackage of the P111. SP2 acts as a
server structure package for SP1 and provides a standard package interface DEFAULT_2 only. This interface makes visible all the repository objects that are
defined in its subpackages.
In order for the client package P1111 to be able to use the content from SP2 (that is defined in one of its subpackages), the actual client package and all its
superpackages have to declare use access to the standard interface of SP2. In other words: the standard interface DEFAULT_2 has to be entered in P1111,
P111, MP11, and in SP1 to declare use access to all non-encapsulated subpackages of SP2.

1.3.4.3 Case 3: Using All Structure Package Interfaces

Description
Let's assume that a server structure package provides all possible types of structure package interfaces
Filter package interface
Virtual standard package interface
Standard package interface
Solution
This case corresponds exactly with case 1 in combination with case 2. Therefore, the rules for the declaration of the use access in the client's package hierarchy
are derived from both cases above.

PUBLIC
Page 16 of 28

1.3.4.4 Case 4: Using Interfaces From First Non-Structure
Package Level

Description
The top-level server structure package SP2 (see figures below) offers a filter package interface FILTER_2. There are no other package interfaces defined in this
structure package. SP1 however acts as a client structure package and contains a main package MP11, which itself contains a standard development package
P111 as the actual client package.

Situation A (see first figure below):
The first non-structure package within the server package hierarchy is a main package that provides a
package interface PINF_21 without any access control list (ACL)
package interface PINF_22_WITH_ACL with an ACL that only contains entries for the packages SP3, MP3, P311 (not pictured on figure below).

Situation B (see second figure below):
The first non-structure package within the server package hierarchy is an ordinary development package that provides a
package interface PINF_21 without any access control list (ACL)
package interface PINF_22_WITH_ACL with an ACL that only contains entries for the packages SP3, MP3, P311 (not pictured on figure below).

Solution
To be able to use visible repository objects from the server package hierarchy, the client structure package SP1 has to declare a use access to the filter
package interface FILTER_2 that is defined at the server structure package level. This use access it is the prerequisite that both, the virtual standard package
interfaces and the package interfaces of the first non-structure level become visible for the client package hierarchy.

Based on the last step, all package interfaces of the main package (here: MP21) or the development package (here: P21) that have either no ACL or an ACL that
contains entries for SP1, MP11, P111, are visible for the client packages SP1, MP11, P111. Therefore, the client package hierarchy can declare the use access
to the package interface PINF_21 only. It comes because the second package interface PINF_22_WITH_ACL has an ACL that does not include the client
packages SP1, MP11 and P111.

PUBLIC
Page 17 of 28

1.3.4.5 Case 5: Server Package Hierarchy with Nested Structure
Packages

Description
The top-level server structure package SP2 (see figure below) offers a
Filter package interface FILTER_2 and
Virtual standard package interface VIRT_DEF_2.
The first-level server structure package SP21 provides the filter package interface FILTER_21 and the second-level structure package SP211 the filter package
interface FILTER_211.
The structure package SP211 contains a regular development package P2111 that exposes repository objects using the package interface PINF2111. The
development package P2111 serves as the actual server package for client package P111 from another package hierarchy.

Solution
To be able to use visible repository objects from the server package hierarchy, the client structure package has to declare a use access for the filter package
interface FILTER_2 that is defined at the server structure package level.
To declare a use access to one of the first packages that are not structure packages - below the root structure package SP2 - all the structure packages in
between (here: SP21 and SP211) do not need to be considered. In other words: The client package can ignore the nested structure packages below the root
structure package.

All package interfaces of the main or development packages (here: P2111) that are direct subpackages of the lowest-level structure package (here: SP211) are
directly visible for other package hierarchies. To use content that is exposed in the package interface PINF2111 of the server package P2111, the respective
client package and all its superpackages - up to the level of the client structure package SP1 - have to declare a use access for that package interface.

1.4 Package Architecture in SAP ERP
Goals of the Package Concept
When SAP created the package architecture in SAP ERP applications, its goals were:
To improve the structure of the software
To encapsulate software functions more strictly
To make well-defined interfaces available to all applications
To clarify responsibilities.
Topics in This Documentation
The next section in this documentation deals with the how the package concept is implemented in the architecture of ERP Core Applications.
From Software Components to Structure Packages
From Packages to Structure Packages
Using Objects from Other Structure Packages
PUBLIC
Page 18 of 28
Applying Filters in Structure Packages

1.4.1 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 SAP ERP applications.Each software component is directly identified with structure packages.
Thus, the structure packages BASIS, ABA, HR, and APPL are derived from the software components SAP_BASIS, SAP_ABA, SAP_HR and SAP_APPL.
However, the software component SAP_APPL is split into further parts, so that two additional structure packages were introduced:
The structure package APPL_TOOLS contains objects that are also used in HR.
The two structure packages HR and APPL must be decoupled, so that they can be delivered in separate Support Packages.
The structure package APPL_NU contains Unicode exceptions - that is, ABAP classes, programs, function groups, and other objects that do not support
the syntax check for Unicode compatibility.
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 Core Applications from ERP.

See also:
From Packages to Structure Packages
Accessing Content from Another Package Hierarchy

1.4.1.1 Software Components in SAP ERP
Software Components
A software component bundles a set of packages that can only be delivered to customers together. All packages are distributed disjunctively among software
components. This means that the objects in a package can only be delivered to customers with a software component. You assign objects to a software
component by assigning the package (containing these objects) to a software component. In general there are several releases for each software component.
Support Packages can be imported into each software component separately.
Package Architecture in SAP ERP
Software Component Description
SAP_BASIS SAP Web Application Server (formerly: SAP Basis)
SAP_ABA Cross-application components
SAP_HR Human resources
SAP_APPL Logistics and Accounting

HOME This software component contains packages with objects that are assigned to a transport
layer and can be transported within a system landscape. This packages are not
PUBLIC
Page 19 of 28
The software component hierarchy
The software components delivered with SAP ERP form a hierarchy.You can use this hierarchy to work out which dependencies are implied by the use of a given
software component. For example, SAP_HR uses objects from the component SAP_ABA, which in turn depends on SAP_BASIS.

Use
A structure package bundles a set of packages at the top level of the package hierarchy. Structure packages do not contain any repository objects except for its
own package interfaces and subpackages. Instead, they hold several main packages and are used to structure software projects. You can also use structure
packages to specify the conditions for decoupling software components. Thus, they have a special significance as far as defining the basic architecture of SAP
ERP is concerned. Examples of structure packages include BASIS, ABA, HR, and APPL.
Characteristics
Structure packages define the top node of a package hierarchy (above the main package level)
Structure packages contain only other packages, not development objects
Their package interfaces are used to specify the relationships between structure packages, not to add development objects.
In contrast to main packages and standard development packages, you can define filter package interfaces, default package interfaces and virtual default
interfaces for structure packages.
You can bundle several structure packages in a surrounding structure package, which means that all SAP packages could be bundled together in one
structure package (SAP).
See also:
Types of Interfaces for Structure Packages
Using Objects from another Package Hierarchy

1.4.2 From Packages to Structure Packages

- Why are the usual concepts of packages and main packages no longer enough?
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.

Structure packages can reduce the organizational effort necessary
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. Structure packages allow to reduce the number of use accesses needed between the client and server packages.
designated for external delivery.
LOCAL Contains packages with local objects only. Local packages are not assigned to a transport
layer.
PUBLIC
Page 20 of 28
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 encapsulated 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.

Additional possibilities offered by filter interfacesThis 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.

See also:
Using Objects from Other Structure Packages

1.4.3 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 Core Applications of SAP ERP. Thus, it shows exactly how the structure package concept has been
implemented in SAP ERP.

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.

See also:
Applying Filters in Structure Packages

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
PUBLIC
Page 21 of 28

1.4.4 Applying 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 elements of a structure package
visible outside 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.

See also:

1.5 Package Checks and System Settings
This section of the documentation deals with the following topics:

1.5.1 Performing a Package Check
With the package check, you have the option of ensuring that the different relationships of the Repository objects are defined correctly in accordance with the
package concept rules. The package check covers the static relationships between repository objects, in much the same way as the syntax of an ABAP
program or the activation of a repository object is checked.
Note that package checks are always performed at the design time of the development object, not at compile time or runtime. This means that dynamic uses of
the object (such as calling a function module) are not checked.
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.
Tells you...
Package Checks ...which tools are used to perform package checks, and when they are performed.
System Settings ...what system settings affect the package check.
Analyzing Use of Foreign Package Objects how you can use the package check tools to analyze, in advance, the use of a
repository object of a foreign package.
Package Check Scenario ...a typical check scenario from a client perspective.

PUBLIC
Page 22 of 28
Procedure
The ABAP Workbench provides the option of performing a package check at different times in the development phase and for different object ranges.

Performing a Package Check for All Objects in a Package
This package method includes in the package check all Repository objects of a selected package. The package check is initiated either from the Object
Navigator or from the Package Builder (SE21).
Prerequisites
Only the active version of an object is used for the check.
Call
1. Select the package to be checked in the Repository Browser of the Object Navigator.
2. In the tree display, open the context menu for the package node and choose the option Check Package Check Package Objects.

As an alternative to the last step, you can double-click the package node and start the Package Builder editor. There you can call the check function by selecting
the corresponding icon .
The package check results are output in a detailed object list. Here you can choose between a simple list view and a hierarchical view.

Performing a Package Check for Objects in a Package Hierarchy
The package check in this case affects the Repository objects within a hierarchical (sub)tree. This means that when you choose a package, not only its contents,
but also the contents of its subpackages and their sub-hierarchy trees are included in the package check sequence.
Prerequisites
Only the active version of an object is used for the check.
Call
1. Select the package to be checked in the Repository Browser of the Object Navigator.
2. In the tree display, open the context menu for the package node and choose the option Check Package Check Check Hierarchy Objects .
A hierarchical display of the objects is output on the screen.
3. In the object display, expand the subtree whose objects are to be included in the package check.
You have the option of including, in one single sequence of the package check, individual objects and sets of objects, as well as all objects that are contained in
the package hierarchy.
The results of the package check are output for each individual object node.

Performing a Package Check for Individual Objects in a Package
Call from the Object Navigator
1. In the Repository Browser, choose the object to be checked.
2. In the tree display, open the context menu for the package node and choose the option Check Package Check.
The package check results are displayed in a list.

Call from the Extended Program Check (SLIN)
Remember that the extended program check can only be performed for active sources.
1. In the Repository Browser, choose the object to be checked.
2. In the tree display, open the context menu for the package node and choose the option Check Extended Check.
As an alternative to these two steps, you can call the check through the transaction SLIN or from the ABAP editor using the path Program Check Extended
Program Check.
1. Set the Package Interface checkbox.
2. Start the program check.
The extended program check also performs package checks and displays messages of the appropriate type (error, warning, information), where necessary. You
can then navigate to the line in the source code where the problem occurred by double-clicking.

Call from the ABAP Dictionary (SE11)
Starting from the ABAP Dictionary tool, you can perform a package check on an active version of a Dictionary object (table, view, data element, domain, and so
on). Inactive version is only checked when activating a Dictionary object.
1. Select the Dictionary object to be checked either in the Repository Browser or within the Dictionary tool.
2. From the menu, choose Check Package Check.
The package check results are displayed in a list.
When activating an inactive Dictionary object, the system performs the check automatically using the inactive version.
If an error occurs during a package check of one of SAP's own Dictionary objects, this object is not activated. If the object has been created by a customer,
however, a dialog box containing a warning is displayed.

Call of Package Checks During Transport Release
Checks are performed on some Dictionary object types when the relevant transport is released. The system administrator can specify whether or not the package
check is switched on in the system.

PUBLIC
Page 23 of 28

1.5.2 Analyzing Use of Foreign Package Objects
You can use the tool to analyze, in advance, the use of a repository object of a foreign package. The package check, in this case, serves to identify activities that
are required in order to avoid package errors with the use of objects.

For example, you wish to know what you need to do in order to use a data element in a class from the current package, whereby the data element belongs to a
different structure package hierarchy. From the results of the package error analysis, you will be made aware of any possible incorrect use access to the foreign
structure package. If the data element you wish to use has not been exposed in a package interface, you would be able to detect this from the results of the
package error analysis.
Prerequisites
If the repository object to be used has not yet been activated, the inactive version is taken for the analysis.
Procedure
1. In the Repository Browser of the Object Navigator, select the package that is to adopt the role of the client.
2. In the tree display, open the context menu for the package node and choose the option Check Package Check Use of Object in Current Package.
3. In the dialog box displayed, specify the repository object to be used.
In general, a repository object is uniquely determined by the specification of the following three values:
1. Program ID:If you are dealing with a repository object (complete object), enter R3TR as the value. For a subobject of the repository object, enter
LIMU.
2. Object Type: Choose the suitable type using the F4 help.
3. Object Name:Enter the object name.
4. Choose Continue to start the package check.
Result
The result of the package check is listed in a separate display of the error analysis. First and foremost, the package error analysis gives a list of all problem
messages relevant to the package. In addition, it supplies you with detailed information on how to solve these problems.
If a long text is assigned to an error description, you can access additional information on the error diagnosis by clicking the displayed icon to call the help text.

1.5.3 System Settings
The following section outlines which system settings are connected with package checks and thus affect the flow of the package check.
There are two main setting types: Global settings, which affect all packages throughout the system, and package-specific settings.
Global Package Check Switch
This system-wide switch is activated as part of customizing. If this switch is deactivated, there is no package check at all. In general, one of the following three
values can be selected:
Package-Specific Setting
Package-specific settings are generally made when the package is created. You can change them later in the Package Builder (on the Properties tab).

OFF No package check.
RESTRICTED Structure packages are not considered in the package
check.
The package check only takes place if the appropriate
setting Package encapsulated is activated for the package.

R3ENTERPRISE The check considers structure packages on the client and
server package side.
This is similar to a RESTRICTED package check but takes
structure packages into account. That is, if the client and
the provider are stored in the same structure package, the
check is limited to the RESTRICTED package check.
Otherwise, the system needs to check whether or not a
use relationship between the two structure packages is
allowed. If it is, the system performs the restricted package
check. Otherwise, an error message occurs.

Package encapsulated When this package property is activated, the package is
PUBLIC
Page 24 of 28
See also:
Structure Packages

1.5.4 Package Check Scenario
In the following scenario, we will check whether or not a client (C) can use an object (S) of a provider package (server). The client and provider packages are
stored in different structure packages. For example, the provider could be part of the ERP Core Application, in the structure package ABA, while the client could
be part of the Core extension.

1.6 Appendix
For more information on the package concept, see:
Package Concept
Naming Conventions
Transfer Packages from SAP NetWeaver 7.30 to SAP NetWeaver 7.31

1.6.1 Short Overview of the Package Concept
From Development Classes to Packages
In former releases (before SAP Web Application Server 6.20) development objects (programs, tables, screens, BAPIs, function modules, types, and so on) were
grouped in over 1700 development classes stored in a flat structure. Any developer was allowed to use any object. A developer could hardly set up a protection
referred to as encapsulated. This setting is especially
relevant for a package in the role of a server package since
it protects the package contents from unwanted use. Using
this encapsulation property, you determine the sanctions
imposed during package checks if the contents of the
respective package are accessed. Development objects
(contents of the package) must first be made available
through server package interfaces before they can be
accessed by a user through a use access.

PUBLIC
Page 25 of 28
for his own development objects. He could 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 - were very limited. Whether on a large
or small scale however, there were no mechanisms for technical modularization.
With the SAP Web Application Server 6.20 release, the package concept was introduced 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 properties: nesting, encapsulation, visibility, and use accesses.
Nesting allows you to embed packages in other packages.
Encapsulation level determines the scope of package encapsulation.
Visibilityis 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 used 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.

1.6.2 Naming Conventions for Packages
Naming Conventions for Packages
General recommendations
Do not use technical concepts like original system, release, and so on
Identifiers in names should be carefully chosen so that they do not become obsolete quickly. Do not include attributes that could change in the near future
Names should be made up of English identifiers.
Packages
The following namespaces are available for packages:
Package names beginning with a letter from A to S, or from U to X.
Package names beginning with these letters are reserved for objects of the SAP standard
system from the SAP namespace. You cannot create customer objects or objects from
prefix namespaces in these packages.
Note that the package name must be no more than 30 characters long. The name of the
main package should reflect the content of the package Adjacent packages should have
similar names.
The Transport Organizer records changes to objects in these packages, so that they can
be transported. These packages belong to the "SAP" transport layer and are assigned to
an SAP software component (such as SAP_BASIS, SAP_APPL).
Package names beginning with Y or Z
You can create customer-specific objects from the customer namespace in these
packages. The Transport Organizer records changes to objects in these packages, so that
they can be transported, provided the SAP System has been set up appropriately. (For
more information, see Setting the System Change Option).
These packages are assigned to the software component HOME.
PUBLIC
Page 26 of 28
Packages Interfaces
Each interface name must be unique. This means that, if you want to use several interfaces to extend visibility over several levels, you must use a different
name at each level.
The interface name should clarify whether the interface is functional or descriptive.
See also:
Creating Package Interfaces
1.6.3 Transfer Packages from SAP NetWeaver 7.30 to SAP
NetWeaver 7.31
Concept
The metadata concept for packages and package interfaces was changed significantly in SAP NetWeaver releases higher than 7.10. To transport packages or
package interfaces from SAP NetWeaver 7.30 to SAP NetWeaver 7.31, you need to follow a specific procedure that creates metadata in the old format before
attempting a downport.
Features
If you have a modifiable transport request of the type Transport of Copies containing any R3TR DEVC (package data) or R3TR PINF (package interface data)
entries, and you want to import this transport request into a 7.31 system, you first need to start the SPAK_CREATE_HYBRID_PACK_DATA program on your 7.30
system. This program creates hybrid package and package interface data for the modifiable transport request, starts the release of the transport request, and then
immediately deletes the hybrid package and package interface data from the database tables.
Caution
The released transport request can only be imported into SAP NetWeaver systems of release lower than 7.10. If the transport request is imported into a
system of release 7.10 or higher, the relevant packages and package interfaces can no longer be displayed or maintained by the Package Builder
(transaction SE21) or the Object Navigator (transaction SE80).
Process
You can find information on how to start and execute the migration process in the documentation of the SPAK_CREATE_HYBRID_PACK_DATA program. In
transaction SA38, call the program and use the Report Documentation pushbutton to display the documentation.
Note
If you have a Transport of Copies containing many objects, you need to place the packages and package interfaces in a separate Transport of Copies
request and delete those from the previous request. Use the program to process only the transport request containing the package data and the Transport
Organizer (transaction SE09) to directly release the other request which no longer contains packages and package interfaces.
More Information
Package names beginning with T (private test packages)
These packages allow you to create objects for customers, from the customer
namespace, or object from the prefix namespace (which is installed in your SAP System
with the role "producer"). See also Releasing Namespaces.
When you create a private test package, specify whether or not you want to link it to the
Transport Organizer. If you do, the objects that the Transport Organizer processes are
recorded in local requests that are not transported. This package does not belong to a
transport layer.
Objects in these packages can only be transported to other SAP Systems using a special
transport request (transports of copies, or relocation transports).
Newly installed SAP Systems contain a private test package, TEST, which is not
connected to the Transport Organizer.
These packages are assigned to the software component LOCAL.
Package names beginning with $ (local packages)
These packages allow you to create objects for customers, from the customer
namespace, or object from the prefix namespace (which is installed in your SAP System
with the role "producer"). See also Releasing Namespaces.
The Transport Organizer does not record changes to objects in these packages. These
packages do not belong to a transport layer, so the object cannot be transported.
Newly installed SAP Systems contain a local package, $TMP.
Packages belong to a prefix namespace.
Like other Repository Objects, packages can belong to a prefix namespace, provided the
appropriate namespace is installed in your SAP System.
The prefix namespace affects packages as follows:
The package name begins with a namespace prefix, enclosed in slashes (/).
You can create customer-specific objects from the customer namespace in these
packages. The Transport Organizer records changes to objects in these packages,
so that they can be transported, provided the SAP System has been set up
appropriately.
PUBLIC
Page 27 of 28
More Information
For more information, see SAP Note 1295439 .
PUBLIC
Page 28 of 28

Workbench Tools - Package Builder

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Workbench Tools - Package Builder

Enviado por

Direitos autorais:

Formatos disponíveis

The Package Builder and the ABAP Package Concept

PDF download from SAP Help Portal:

Você também pode gostar