Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
Showing results for 
Search instead for 
Did you mean: 

Best Practice: Usage of the ABAP Packages Concept?

Former Member
0 Kudos

Hi SDN folks,

I've just started on a new project - I have significant ABAP development experience (15 years+) - but one thing that I have never seen used correctly is the Package concept in ABAP - for any of the projects that I have worked on.

I would like to define some best practices - about when we should create packages - and about how they should be structured.

My understanding of the package concept is that they allow you to bundle all of the related objects of a piece of development work together. In previous projects - and almost every project I have ever worked on - we just have packages ZBASIS, ZMM, ZSD, ZFI and so on. But this to me is a very crude usage of packages, and really it seems that we have not moved on passed the 4.6 usage of the old development class concept - and it means that packages do not really add much value.

I read in the SAP PRESS Next Generation ABAP book (Thomas Ljung, Rich Hellman) (I only have the 1st edition) - that we should use packages for defining separation of concern for an application. So it seems there they are recommending that for each and every application we write - we define at the least 3 packages - one for Model, one for Controller and one for view based objects. It occurs to me that following this approach will lead to a tremendous number of packages over the life cycle of an implementation, which could potentially lead to confusion - and so also add little value. Is this really the best practice approach? Has anyone tried this approach across a full blown implementation?

As we are starting a new implementation - we will be running with 7 EHP2 and I would really like to get the most out of the functionality that is provided. I wonder what others have for experience in the definition of packages.

One possible usage occurs to me that you could define the packages as a mirror image of the application business object class hierarchy (see below). But perhaps this is overcomplicating their usage - and would lead to issues later in terms of transportation conflicts etc.:



ZSOrder ZDelivery ZBillingDoc

Does anyone have any good recommendations for the usage of the ABAP Package concept - from real life project experience?

All contributions are most welcome - although please refrain from sending links on how to create packages in SE80

Kind Regards,



Former Member
0 Kudos

Hi Julian,

I have struggled with the same questions you are addressing. On a previous project we tried to model based on packages, but during the course of the project we encountered some problems that grew overtime. The main problems were:

1. It is hard to enforce rules on package assignments

2. With multiple developers on the project and limited time we didn't have time to review package assignment

3. Devopelers would click away warnings that an object was already part of another project and just continue

4. After go-live the maintenance partner didn't care.

So, my experience is is that it is a nice feature, but only from a high level design point of view. In real life it will get messy and above all, it doesn't add much value to the development. On my neew assignment we are just working with packages based on functional area and that works just fine.


0 Kudos


it doesn't add much value to the development.

: this is the truth

I think it should be a central commision to decide which the packages will needs in a projects, who writes an analisys for a new development has to assign the right package to be used: the developer shouldn't choose the package.


Active Contributor
0 Kudos

Unless you're developing a large application, involving many objects, then the package concept is largely irrelevant for most sites. For SAP and developers of add-ons and other third party solutions, then it is very useful - and will become more so when it's fully in place, with all the access rights etc.

One use I do encounter at client sites is for landscapes more complex than the usual dev-qa-prod. Where there are multiple destinations from dev, the package allows control over where things go. And that's pretty useful too.


Former Member
0 Kudos


we use a approach similar to your suggestion (like: ZSD1- sales order, ZSD2 - delivery, ). This makes sense if different people are responsible for e.g. requirements, design or realization. It makes sense to bundle this (package ZSD includes packages ZSD1 to ZSDn).

Naming conventions for objects may force developers to assign the right package (e.g. name of a new DDIC table must begin with package name/underscore). This should be checked by a tool (could be implemented using BADI CTS_REQUEST_CHECK check at release of task/transport).

Execpt the possibility to reflect the object hierarchy I see not much difference to the old development classes.

Kind regards,


Edited by: Holger Pakirnus on Sep 7, 2011 12:10 PM

Former Member
0 Kudos

Hi all,

At our current customer we are going through this same process: Starting a greenfield implementation, allowing us to start doing things different from the past, getting to a higher level of development standards and practices.

We are now also figuring out what to do with the package concept. Questions like these come up: "What's our package hierarchy gonna be like?". At first we thought of replicating the SAP hierarchy, but that's big and we'll probably only use 1% of that. And where should our regular developments (non-enhancements) end up then?

Julian, what did you decide on in the end?

Kind regards,


Active Participant
0 Kudos

you might be interested in the following:

basic recommendations for using packages - [state-of-the-art ABAP programs part 3|]

recent blog post explaing the basics of ABAP package and the best practices - [ABAP Package Concept Part 1 u2013 The Basics|] [original link is broken] [original link is broken];