Whats to know about ABAP Package concepts (SE21) today?
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:
Edit: and there is also that:
Tobias Trapp seems to know and publish a lot about packages, a recent (2016) blog being
Then there are the older (2011/2012) Blogs, seeming to explain everything there is to know:
(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?
[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!
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.
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.
@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.
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.
Hey Jens Knappik , seems I never thanks you for your Input,so: thanks!
Also it seems now both links (mine and yours) are broken..
Here are new ones:
As of now (2022)
This is the overview of all(?) DSAG papers:
And this are the direkt PDF-links to dev guidelines:
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:
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.
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.....
Thanks all for your input!
[Yes I do realize I’m coming back to a blog from very early this year]
I haven't utilized all of it yet, I'm sure, but today I came back to packages with the question about how to turn on "Package Check" in a System.
I found that very part of help.sap.com but I have the feeling that it's no help at all:
That’s very fine, part of what I wanted to knwo, but where exactly do I go in customizing? Shouldn't that page tell me? (The "old" help gave me the path how I should navigate, if I recall correctly).
I'm pretty sure I'll find it somehow, but my current question is about help.sap.com:
- Do I have the wrong expectations? (Maybe there's another (more technical?) resource, not only telling me "there’s customizing" but also how to actually get there? If so, which is that?
- Don't I just see it? Is there a hint/link/something I just don't see? Glad if you could point that out to me.
Here's the link in case you want to go searching:
Yep... I looked for the same, and got to the same result...
SAP "Help" is no help at all...
So in the end it leads to table PAKPARAM (not maintainable)
but there is a view: PAKPARAM_V which can be maintained via SM30
thanks for sharing my pain! 😉
To link some ends: I also asked about switching on package checks here: https://answers.sap.com/comments/326685/view.html
and, well, apparently, there isn't a better way...
It's all documented in SAP note 648898 - Switching on the package check. I know, anyway difficult to find.
Oh - save this one too! I think we - the community could help on what NOT to remove. This one is great on it's own - but the comments are really good too!
Package concept is very very very very ..... complicated. I didn't understand it.
Good blog about package (se21) concepts, the links to further resources and the comments are nice!