1. ABAP Package Concept
Use Cases & Best Practices
Tobias Trapp, AOK Systems GmbH
Enterprise Architect, SAP Mentor

2. ABAP Developers and Reuse
 „In SAP Business Suite there‘s so much useful stuff.“
 „I can save 40 seconds of my life time by using data elements
from SAP standard: CHAR04, CHAR130, BEZEI30…“
 „And for something more complicated I‘m looking for an
function module.“

3. Is this how we should do reuse?
 Do you use a certain data element (BEZEI30) because it is
part of SAP data model you want use?
 If not: don‘t you want to be able to define your own short
and help texts?
 How do you know that this certain function module is
appropriate? How do you know that it belongs to a
public API?

4. An Architect‘s Answer
 Think in terms of applications and APIs - not in terms of data
elements and function modules.
 If you work with a certain SAP data model use the
corresponding data elements and domains. In your own
applications don‘t be afraid to create your own DDIC elements
and local data types.
 Use DDIC elements, classes… that are exposed in package
interfaces. Within SAP Business Suite this is a development
guideline. So you can be sure that you use appropriate
functions that are stable according to release changes. The
local integration engine infrastructure (package SAI) is a good
example.

5. Development Classes vs. Packages
 Legacy R/3 consists of 800.000 development
objects in 3000 development classes:
 Dependecies are not explicit visible
 Which set of packages build an application?
Naming conventions will fail in the long run
 What is the API of a package? What is public and what
is private?
 There are no „borders“ of applications. The system
becomes a monolith - that makes evolution of the
system and its applications difficult.

6. How can the Package Concept help?
 Packages can be ordered hierarchically. An application consists
of a package hierarchy with a main or structure package on
top.
 With package interfaces you can define (and document)
dependencies between applications in an explicit way.
 Using package checks you can check violations of
dependencies.

7. How can the Package Concept help
you in Custom Development Projects?
 Reduce dependencies: control impact of Ehps /
switched Business Functions
 Use stable APIs
 Guarantee installability of software components at
development time
 Structure your applications
 Maintain and evolve applications independently
 Define stable APIs using interfaces
 Need for privacy - don‘t expose everything to everyone!

8. Do you want to use elements of IS-U?


9. Explain Functionality


10. Software Components &
Structure Packages
Software Components are artefacts from software logistics and no
development objects.
FS-CD FS-CM
Structure packages are development object having dependencies to
other structure packages: BASIS, ABA, BS_REUSE, APPL, APPL_TOOLS,
FI-CA, …
Dependencies between software components are expressed by
dependencies of the structure packages inside.

11. Properties of Structure Packages
There are special types of interfaces:
 Default-Interfaces
 Virtual Default Interfaces – a kind of carte blanche
 Filter Interfaces that restrict Virtual Default Interfaces
to namespaces.
The use access to Filter Interfaces has to be declared only on the
level of structure packages.

12. How to implement
ABAP Package Concept
 Fight for your rights: BASIS admins have to grant new
authorizations:
 Developers/Architects have to change package properties
to assign use accesses, packages interfaces
 To avoid activation errors you need a special authorization
S_DEVELOP 94 („Overwrite“) for packages
 You have to find software architects who define /
control dependencies
 Last but not least: explain the package concept to developers

13. Package Types & Properties
 Define Package Properties:
 structure, main and development packages
 package checks: client & server
Package Check neither as Server nor as Client will be sufficient at the
beginning. Get Experience with Package Check as Server with your own
packages.

14. Declare Use Accesses

15. Define Package Hierarchies


16. RESTRICTED vs. R3ENTERPRISE
 Modify an entry in table PAKPARAM (OSS 648898 / 792058) as
system-wide switch
 Use RESTRICTED if you want to check against package interfaces
 Use R3ENTERPRISE if you want to control dependencies on the
level of structure packages and on package interfaces

17. Define Interfaces
 Package interfaces can contain package interfaces from
packages deeper in the hierarchy.

18. Fill Package Interfaces

19. Execution of Package Checks
Packages can be executed
 as part of SLIN
 using Code Inspector (SCI)
 using SE80 for all elements in a package (hierarchy)
 are part of SCI variant for transport
A violation will not prevent you from CTS transportation. This
may change but today you have to include the checks as CTS
BAdI implementation.

20. API for package checks as part of
ABAP Classification Toolset
DATA lr_obj_badi TYPE REF TO pak_object_properties.
DATA ls_pak_object_key TYPE pak_object_key.
GET BADI lr_obj_badi
FILTERS object_type = ls_tpobject-object.
CALL BADI lr_obj_badi->get_object_from_e071_entry
EXPORTING
im_e071 = ls_tpobject
IMPORTING
ex_object = ls_pak_object_key.
CALL BADI lr_obj_badi->package_check
EXPORTING
im_object = ls_pak_object_key
IMPORTING
ex_package_errors = lt_errors
ex_severity = lv_severity.

21. SAP NetWeaver 7.30
 ABAP package concept gets more complex: access control list…
 Some interface types will vanish
 Migration reports (have a look at OSS):
 RS_MIGRATE_PACKAGES
 RS_MIGRATE_PACKAGEINTERFACES
 SPAK_CREATE_HYBRID_PACK_DATA
 Packages checks not (yet) part of ABAP runtime

22. Questions? Criticism? Comments?
I would like to get into discussion!
I‘ll blog on SCN about this topic.