Activating Package Checks in a Running System

[gabmarian]

Does anyone have experience with the activation of package checks in an ABAP customer system already in operation for years and with a large code base?

I’ve been playing around with RESTRICTED mode and I like the features provided by the encapsulation, mainly the aspect revealed via package checks that standard SAP objects should not be just reused mindlessly.

Do I have to fear that once activated it will cause problems in existing custom objects, as nobody payed attention to package interfaces before? I’ve seen an error popup during DDIC activation on violation, but it seemingly can be bypassed. I tried to search on parameter DEFAULT_SEVERITY in table PAKPARAM and how to use it, but without any success.

PS: I’m also interested in any experience with package checks in customer systems. Does it worth it in the long run?

[tudor_teoteoi]

It's a long time since this question was asked, but here is the input I can provide...

1) With regard to parameter DEFAULT_SEVERITY in table PAKPARAM, it uses values of domain ERRSEVRTY: NONE/INFO/WARN/ERRO/OBSO.
This can be derived from usage in method S_SET_DEFAULT_SEVERITY of class CL_PACKAGE_PARAMETERS.

2) For standard SAP objects extensive maintenance will be required on a large code base installed, where no one payed attention to package encapsulation rules:

a) You will need to provide the respective SAP package interfaces; this is not that hard, as running a package check in SE21 will accompany each message with a suggestion for correction, IF there is a possible solution...

b) ... but some standard SAP objects are not exposed in package interfaces, and you will have to search for alternatives or copy the objects in your Z-namespace (e.g. I did this for one standard class, which I inherited and slightly adjusted for my use case).

c) You will have to define standard packages on the top-most level.

3) Your custom packages will probably start as non-encapsulated.( There is a check mark in SE21 (or when creating a new package) on the properties screen for that.)
You can gradually start to mark packages as encapsulated, and correct errors due to cross-package usages.
A clear concept must be defined in this phase about what should be exposed from each of your custom packages.

There is a series of blogs from SAP on the topic, which may help to some extend on understanding the concept, though I can't say I was fully able to grasp all concepts after reading these:

https://blogs.sap.com/2011/12/04/abap-package-concept-part-1-the-basics/

https://blogs.sap.com/2011/12/10/abap-package-concept-part-2-package-interfaces-of-development-packa...

https://blogs.sap.com/2012/03/01/abap-package-concept-part-3-package-hierarchy-coupling-and-cohesion...

https://blogs.sap.com/2012/07/22/abap-package-concept-part-4-how-to-perform-package-checks/

[christianpunz]

hi Tudor, hi Gabor,
A decade ago I tried this stuff and was totally lost.
Now one customer wants to know details about his legacy code base: "we have /NAMESPACE/code which uses Z-DTELs. crashes upon import in receiving system (nobody took care creating the transport request). how to find out these bad codings?".

Well, I read (more or less) the 4 blog posts by tobias.trapp and tried in our sanbox with S/4HANA 2022. And I'm lost, again.
There seems to be no easy way for the answer "/NAMESPACE/code contains these Z-Objects from Z-Packages" except maintaining structure packages for all the involved things, which is rather annoying for a bunch of legacy packages.

Like the checkbox "Package encapsulated" (outsiders are not allowed to use objects of this package, if they are not exposed explicitly) there should be a checkbox "this package must not use objects from outside".
BR
Christian
ps. maybe I'm too dumb for this package interface feature 😞

[tudor_teoteoi]

Hi Christian,

Maybe transaction /SDF/TRCHECK helps? It can check if a transport will cause import problems in an external system. You only need an RFC destination (to your target system or to any system which ideally does not yet have any of the objects).

This will list a table with all the missing objects, as well the calling objects, which are the "bad codings" you're looking for:

In the above, function group ending in *CRM is using non-existing class endig in *CONV. (There are 3 matches for the private/public/protected part of the class, plus one additional match for a direct reference to a method inside the class.)


The packaging feature is indeed quite complex and took me some time to create a working concept. And I do not know all secrets.

Once the feature is active, you do have to explicitly specify (on tab "Use Accesses") what type of accesses you are allowed to do outside your own package. However, packages which do not have the encapsulation active will be available for everyone from the outside; in care of undesired access outside the package you do have to set the encapsulation flag accordingly (start be setting it for all packages and gradually remove it for the few exceptions that are allowed OR create the package interfaces containing the sub-set of objects that are exposed to the outside).

I guess /SDF/TRCHECK method is easier if don't plan to edit that code in the future.

Best Regards,
Tudor