Building software on S/4HANA, I have the feeling I have to re-think / update my knowledge about packages (you know, SE21).

There is  a lot I (think I) know, but I’m very sure there also are many aspects I don’t know yet.

One of them is this one:
https://answers.sap.com/questions/101591/se21-flag-for-package-encapsulation-how-to-change.html
Edit: and there is also that:
https://answers.sap.com/questions/101748/se21-what-happend-to-packtype.html

Tobias Trapp seems to know and publish a lot about packages, a recent (2016) blog being
https://blogs.sap.com/2016/05/03/news-about-abap-package-concept-naming-conventions-for-package-hierarchies/. 

Then there are the older (2011/2012) Blogs, seeming to explain everything there is to know:

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-packages/
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/

(I have not read them yet, this blog kind of serves as a “to-read”-list for me (I’m gladly sharing with the community as well) – also I’m not sure if they are still a good/true/up-to-date read after all, they are about 6 years old, things might have changed since then…(“ things will change slightly in 7.30 “).

Paul Hardys book “ABAP to the Future” (you know, the one that helps if you phone is to low) doesn’t say anything about “packages” (at least there is no such entry in the Index under “P”, also nothing on “SE21”, also not on “ABAP Packages”).

Maybe the help.sap.com “The Package Builder and the ABAP Package Concept” might be a good read as well?
http://help.sap.com/saphelp_nw75/helpdata/en/af/40bd38652c8c42e10000009b38f8cf/content.htm

[Edit: 2017-02-07: Yes it is! I actually started digging into it today, and it seems really detailed.

Also, because it’s the help on an up-to-date release I don’t have to fear about reading “to-old-to-still-matter” stuff there!

]

 

Do you care about Packages? How do you use them? Where would you start reading about packages if focusing on the “new” / S/4HANA-World?

Your input is most welcome!

best
Joachim

 

To report this post you need to login first.

6 Comments

You must be Logged on to comment or reply to a post.

  1. David Henn

    Hi,
    thank you for this great link collection.
    We use packages a lot to structure our development. At the moment we are starting to think about package interfaces to really slice single components out of our software and to ensure, one product has no dependencies to another so they can be installed separately.

    (0) 
    1. Joachim Rees Post author

      Hey David,

      great that it is of help to you!
      The use case you describe is very relevant to me, too. If a concept would ensure separation/encapsulation of dev-objects, that would be really helpful.

      best
      Joachim

      (0) 
  2. Joachim Rees Post author

    Short update:

    @Florian Henninger recomended the current DSAG development guidelines to me in regards to package concepts.

    Of course, they are a good and up-to-date read on all the other topics as well! They’re publically available (no need to be a DSAG-member) but currently in German only.

    They actually don’t say too much on packages, but they do refer to Tobias’ blog series as well, so I think that is still very relevant.

    best
    Joachim

    (1) 
    1. Jens Knappik

      Hi Joachim,

      please have a detailed look at the DSAG document. At the beginning of page 13 there are a lot of information and recommendation how to deal with the package concept, when to use what and where you can find more information. Additional you will find an example how to build a package structure in the Appendix at page 85.
      Please give us some information what you are currently missing and the authors may be add it in the next release.

      By the way: Your document link is addressed to the internal DSAG Member section. To all who are interested in the public german PDF document, please have a look here.

      Cheers

      Jens

      (0) 
  3. Peter Inotai

    Hi Joachim,

    In my previous company we heavily used packages and package interfaces for the package concept. We used it for ABAP Add-on development. I don’t think it makes too much sense for „normal“ custom development.

    Our main motivation was to be able to deliver part of our development (packages) and able to control dependencies between them.

    We found package check, but it’s really badly documented. I remember I found table PAKPARAM via debugging the standard SAP code 🙁

    We still used the old approach (system with 6.20) and structure packages. It was quite a lot of effort to maintain it, so in the end we wrote a generation program (and yes, with direct update on table PERMISSION :)). Also some cases we had to open SAP message, because it was not clear if there is a bug in our system or simple it’s not set up correctly. The SAP logic quite strange and some of the part I never really understood why it’s like that, but simple accepted it and it worked 🙂

     

    The big advantages were:

    • It was integrated in extended syntax check, code inspector and ATC
    • We were able to control dependencies between our packages
    • We were able to control dependencies between our package and SAP packages (we used IDES system, which was full of Add-ons, but it was not necessarily the case in customer systems)

    The big disadvantages was the high effort.

     

    I heard that it was heavily redesigned with release 7.10, but I never had the opportunity to try it out.

    Best regards

    Peter

     

    (2) 
  4. Paul Hardy

    Funnily enough, when I drew up the list of topics to include in my book two areas I originally included were based on Tobias’s blogs about the package concept and the business suite foundation.

    In the end I had so many potential topics I had to let lots of them fall by the wayside.

    As mentioned above Tobias was talking from the perspective of an independent software company creating ABAP add-ons to be installed in various different SAP systems. In such a case it is naturally vital that you are 100% sure there are not any sneaky dependencies hanging around.

    This is not that important if you are an ABAP developer creating code that will only ever be used in one SAP system.

    When my company first installed SAP the consultants created one package per module e.g. SD, MM, HR and so on, and a GENERIC one. As even at that point(1999) the module based approach to SAP did not make a lot of sense, many developments did not fit neatly into one box and so went into the GENERIC bucket.

    As can be imagined, this was bog all use.

    My company had mapped all its business processes into a diagram that looked a bit like a Rocket. I created an application hierarchy to mirror this, so the package structure reflects the business as opposed to the internal structure of the software we use to run the business.

    As the helpdesk / new projects system has an identical hierarchy, by the time it gets to the developer it is obvious where in the package structure the new objects should live.

    Now, it was mentioned above – can the package structure, with all the restrictions on package interfaces and the like, enforce a separation of concerns in some way?

    That would be lovely, but at the moment I cannot see how.

    In the day to day programming you tend to get DDIC objects which are used in multiple places (business processes). Do you create many duplicates of a data element, one for each package, despite the data element referring to one unique concept?

    What about structures which objects in different packages use to communicate? What package should they be in?

    In summary, I have many more questions than answers on this topic…..

    Cheersy Cheers

    Paul

    (4) 

Leave a Reply