Application Development Blog Posts
Learn and share on deeper, cross technology development topics such as integration and connectivity, automation, cloud extensibility, developing at scale, and security.
cancel
Showing results for 
Search instead for 
Did you mean: 
CreyJ
Participant
Dear all,

we dared to switch on the package check in check mode “R3ENTERPRISE”. Doing this, we struggled with visibility of SAP objects w/o appropriate package interfaces.

Example:

Assuming you have the following package structure:

  • An own Z-Structure package, beneath a

    • Z-Main package

      • Z-development package






Could look like this

  • ZTESTPIF_STRUC

    • ZTESTPIF_STRUC_MAIN

      • ZTESTPIF_STRUC_DEV






Inside the Z-development package, you wan to use the data element /SCDL/ADF_CHK_ARCH in a program. Running a package check for your program leads to several errors:

  1.  Used object from external structure package not visible

  2. The object DTEL /SCDL/ADF_CHK_ARCH is not exposed in package interfaces.


First error, is because of a missing / useable package interface on structure package level in package /SCWM/COMMON_CORE_STRUC, second error occurs as package /SCDL/ADAPTER_DF is encapsulated.

Looking at the package interfaces /SCWM/COMMON_CORE_S4APPL_ESIF seems to be made for re-usage of the objects in other applications.


But unfortunately, /SCWM/COMMON_CORE_S4APPL_ESIF has a restriction of client packages. So we cannot reuse it.

Solution for that create an own package interface for the SAP structure package level and its sub packages to grant visibility in your Z-Packages, from structure to development package.

  • /SCWM/COMMON_CORE_STRUC:     Structure package

    • /SCWM/STRUCTURE:    Structure package

      • /SCDL/MAIN:    Main package

        • /SCDL/ADAPTER:    Development Package

          • /SCDL/ADAPTER_DF:    Development Package
















How to create a PIF for a SAP package.

  1. Go to SAP Package

  2. Right click on package and choose "Create->Package->Package Interface"

  3. Fill the Name (Your Namespace), description and Type (default Standard Package Interface). Do not change the Package here

  4. Confirm

  5. And now the magic occurs and you can assign the PIF to your own package.



 

For in the given example you have to execute the following steps

  1. Create a package interface for each SAP package; from SAP structure package down to SAP development package.



























    SAP Package Example PIF
    /SCWM/COMMON_CORE_STRUC ZSCWM_COMMON_CORE_STRUC
    /SCWM/STRUCTURE ZSCWM_STRUCTURE
    /SCDL/MAIN ZSCDL_MAIN
    /SCDL/ADAPTER ZSCDL_ADAPTER
    /SCDL/ADAPTER_DF ZSCDL_ADAPTER_DF


  2. Add development object, in this example DTEL /SCDL/ADF_CHK_ARCH, to the visible elements (TAB Visible Elements) of your PIF ( e.g. ZSCDL_ADAPTER_DF) for the SAP development package interface.

  3. Add visibility (TAB Visible Elements) to your PIFS of the superordinate SAP packages up to top SAP structure package using button "Add Package Interface".

  4. Add your PIF of the SAP structure package to your structure package for your own developments (TAB "Use Accesses", "Create").

  5. Add this PIF to your sub packages (TAB "Use Accesses", "Copy from Superpackage").


 

 

 

 

 

 

 
6 Comments
Peter_Inotai
Active Contributor
Hi Jürgen,

"we dared to switch on the package check". Welcome to the club 🙂

We also used package check in my previous company and it was really a HUGE effort to make it work for us.

I would emphasize that what you did is almost "cheating". I don't know the mentioned objects and packages, but generally speaking there is a reason why only certain objects are available in the package interfaces. Creating a new package interface just to make them accessible might potentially break something, which was not intended.

For me it's almost like accessing a private method in a class via a new wrapper method.

Best regards,

Peter
CreyJ
Participant
Dear Peter,
I have been in contact with SAP development about this, and the solution (for S/4 2020) was to create own PIFs for SAP objects, as the PIFs provided by SAP are not to be considered as an interface for customer developments, but rather for SAP internal use.

PIFs for customer developments have "never been pursued with any vigor as a goal in the application" until now. But that is expected to change in the future. We have therefore currently severely restricted the authorization for packages and PIFs in these systems and creation or modifying packages is no longer available to a "normal developer".

Since I didn't find any post about it, I wrote this blog. And so we can have a good discussion about it. 😊

Regards
Jürgen
Peter_Inotai
Active Contributor
Dear Jürgen,

Thanks for the additional info. Now the picture is more clear why it was done this way. 🙂

Best regards,

Peter
Peter_Inotai
Active Contributor
0 Kudos
Sorry, just noticed that there is a typo in the title (crate instead of create).
thalesvb
Active Contributor

And here was I, thinking for many years that PIFs were exactly for customer developments (since classes doesn't really have a true "released for customer" mechanism).

I agree that is almost cheating, but then when you have some time to debug Package Check program and flying-by a bunch of hardcoded exemptions (maybe they "fixed" by now) then you won't blame yourself much for having the upper hand by manipulating cards. Yet you can also be picking the wrong cards just to have a green check instead of refactoring to pick the right ones. We don't know for sure which are the right ones.

wridgeu
Participant
0 Kudos
Hey Jürgen,

great read, nice post! Especially the conversation between you and Peter helped clarify a few things, that I was wondering about for quite some time now. Although I'm barely ever using PIFs it is nice to know a little more about 'em. 😊

cheers 🍻

 
Labels in this area