Add section: Proper use of Packages

[sap]

Add section: Proper use of Packages

[fabianlupa]

Also switchable packages for SFW5 could be mentioned.

Some things I ran into when learning the package concept, that might prevent some headaches if they were documented somehwere:

1

You cannot legally use objects of a parent package from a child package. Package interfaces are only consumable by siblings, not parents/children. Children cannot see objects of the parents. This leads to having structures like this (PROD = product, COMP = component):

• /ABC/FIN (Structure package for products with dependencies on S4FIN)
  • /ABC/PROD (Main package)
    • /ABC/PROD_PUBLIC (package interface)
    • /ABC/PROD_CORE (Development package)
      • /ABC/CL_PROD_UTILS (Class)
      • /ABC/PROD_CORE_PUBLIC (package interface)
    • /ABC/PROD_COMP1 (Development package)
      • /ABC/CL_PROD_COMP1_FACTORY (Class which uses /ABC/CL_PROD_UTILS)
    • /ABC/PROD_COMP2 (Development package)

Instead of the more intuitive:

• /ABC/FIN (Structure package for products with dependencies on S4FIN)
  • /ABC/PROD (Development package)
    • /ABC/PROD_PUBLIC (package interface)
    • /ABC/PROD_COMP1 (Development package)
      • /ABC/CL_PROD_COMP1_FACTORY (Class which uses /ABC/CL_PROD_UTILS)
    • /ABC/PROD_COMP2 (Development package)
    • /ABC/CL_PROD_UTILS (Class)

simply because /ABC/PROD_COMP1 cannot declare a use access for /ABC/PROD_PUBLIC as that is one level higher up (source).

2

As your first resource for figuring out how package interfaces work you might be inclined to look at how SAP uses it in their products. So naturally you look at how they achieved separation between the structure packages BASIS and APPL and so on. What you realize only after a few hours of trial and error is that the package BASIS and its package interfaces are hardcoded into the package check and behave differently than when you create the same structure.

3

Enabling package checks is a system wide setting (PAKPARAM), that cannot be restricted to packages or even development clients. If you cannot convince every one on the development system to either use the package concept or to ignore all error messages you need to write your own checks or use something like fake package encapsulation in AOC. The package check is implicitely called in the syntax check for DDIC objects in SE11.
(I tried a modification on the SELECT on PAKPARAM to achieve a client specific setting but that failed as the table is accessed directly by the kernel somewhere I assume.)

4

Lots of SAP objects are not externally accessible, including APIs that are mentioned in SAP documentation as free to use. If you are using ATC with CTS integration you cannot create exemptions for package check errors as the default package check implementation does not allow it. You can wrap the default check in your own check which does support exemptions and use that one in the ATC variant.

Since the package checks were changed at some point, this is the most recent public doc I think?
S4H/753: https://help.sap.com/viewer/bd833c8355f34e96a6e83096b38bf192/201809.002/en-US/af40bd38652c8c42e10000009b38f8cf.html
752 https://help.sap.com/viewer/bd833c8355f34e96a6e83096b38bf192/7.52.4/en-US/af40bd38652c8c42e10000009b38f8cf.html

Also the tooling for package interfaces in ADT is still quite lacking (/non-existent). To comfortably add new objects to a package interface (using drag and drop) you need to use SE80. I hope the tooling will be added at some point (packages got a native ADT UI even with display of their interfaces), but since PINF objects are not available in the cloud and there are some newer ways available for some object types (API state) I don't have high hopes.

[KnutStargardt]

Creating a reliable package concept is a kind of art / a kind of future guessing. It's like organizing a garage - it's always depends how many tools you expect to have in future. By this you decide how many boxes you need and how the boxes should be labeled.

I don't have a right algorithm for creation of packages, but:
A rough architecture of the development to be created should be in place
-> A common package for re-usable elements is useful
-> A package for database handling
-> A package for each API
-> A package for the core logic
-> A package for the UI layer
-> Some packages for test entities are useful ( for example database mocks, E2E tests, etc.)
-> It is quite important that objects are only placed in the packages of the lowest
layer otherwise package interfaces are quite tricky.

Kind regards,
Knut

SAP Information:
https://help.sap.com/doc/saphelp_nw70/7.0.31/en-US/6b/566a4d988611d596b900a0c94260a5/frameset.htm

[larshp]

and package naming, eg. as package names are global I typically prefix all subpackages with the name of the super package

[nununo]

and package naming, eg. as package names are global I typically prefix all subpackages with the name of the super package

I also do the same. It's so sad that SAP doesn't have a proper namespace hierarchy.

[nununo]

This proposal seems to be abandoned. But Clean ABAP really needs a section talking about this. Too many systems (and developers) still think of packages as bottomless buckets called ZMM, ZSD and ZUSEREXITS.

[pixelbaker]

Good idea. I will sum up my observations on the weekend. Maybe we can also find a position to package interfaces in that section.

…

On 19. Jun 2019, at 08:35, g-back ***@***.***> wrote: I've tried to find some information regarding the proper use of packages, but it seems packages are barely even mentioned. Would it make sense to add a section on how to properly use packages? While there are similarities to classical "package-systems" like in Java, there are a few peculiarities that could be expanded upon. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.