10/3/2018 ABAP Package Concept Part 1 The Basics | SAP Blogs

Products
Products Industries
Industries Support
Support Training
Training Community
Community Developer
Developer Partner
Partner

About
About

 
Ask a Question Write a Blog Post Login

ABAP Package Concept Part 1 The Basics

December 4, 2011 | 9,232 Views |

Tobias Trapp
more by this author

Retagging required
tobias trapp s views on sap technology

share
0 share tweet share

Follow

At SAP communities ROCK! I offered a session about ABAP package

concept. There are slides and a video of the session available but I decided to
write a series of blogs about the topic. In my opinion the ABAP package

https://blogs.sap.com/2011/12/04/abap-package-concept-part-1-the-basics/ 1/17
10/3/2018 ABAP Package Concept Part 1 The Basics | SAP Blogs

concept was – besides object orientation and ICF – the most important
innovation of the ABAP application server. The reason is simple: the package
concept allows to develop software so that is “soft” which is necessary for
evolution of any software system.

In my opinion too many custom development projects don’t care about this
and most developers don’t know about the ABAP package concept. I can only
guess the reason: At the beginning of a development project the aspects of
software logistics and naming conventions (Z or a customer namespace) are
first challenges. Usually packages and namespace prefixes for development
objects are defined to group some objects according some obvious properties:
there is one package for FI development, another one for HCM and so on.

This may be appropriate for small development projects consisting of some

report and BAdI implementations but will lead to serious trouble in larger
projects. But even in small development projects the ABAP package can help
you. I can give you an example from my own experience. One of my tasks as
developer was to implement A2A and B2B processes and therefore I used the
web service infrastructure of the ABAP application server – the package SAI. I
think it was first shipped in 6.20 and there have been incompatible changes in
release 6.40, 7.0 and I think in NW 7.0 SP 15 because of changes of SAP
Web Service frameworks. Luckily I only used functions of the package
interface of package SAI and so I had only a few things to change in the
releases.

But the same applies to custom development of applications: if you create

your own application with database persistence, application layer, UI that is
used by another custom developed application you have to define proper API
to guarantee authorization concept for example. Without package interfaces
following problems will occur:

Developers don’t know what ABAP classes or function modules belong

to the public API. Naming conventions won’t help you because you
can’t assume that they are widely known.
It’s likely that developers start do use ABAP classes which you consider
as “private” and you will get into trouble when you want to change them
(think of refactoring or optimization) in an incompatible manner. When
this happens your application uses its most important property: it is not
“soft” any more as software should be. There are too much unwanted
dependencies and you have to consider side effects when doing
changes.

https://blogs.sap.com/2011/12/04/abap-package-concept-part-1-the-basics/ 2/17
10/3/2018 ABAP Package Concept Part 1 The Basics | SAP Blogs

As a consequence I changed my programming style: when I’m coding an

application I will write define a proper interface that helps developers to use
my tools. When I want to reuse parts of SAP standard I first look at the
package interfaces. This helps me to learn how to use SAP standard much
faster and the chance is much higher that I don’t have much after a release
upgrade.

I give you some example: When I wrote my last blog about a Operations
Research & ABAP within SAP standard I learned how to use it by studying unit
tests and package interface:

Use Cases of the Package Concept

The ABAP package allows nesting packages hierarchically. The package at
the top level corresponds to an application.

The ABAP package concept allows you to create stable APIs of a package.
This means that you can distinguish between public and private parts
(implementation details) that can be changed.

But package concept has many other use cases – we can define
dependencies to other packages of SAP standard as well to your own

https://blogs.sap.com/2011/12/04/abap-package-concept-part-1-the-basics/ 3/17
10/3/2018 ABAP Package Concept Part 1 The Basics | SAP Blogs

packages:

You can define dependencies to SAP standard. This can help you in
SAP software updates because you use stable API and control the
dependencies which is very help in impact analysis of SAP Switches &
Business Functions of EhPs.
In a larger development project you can structure your application. You
can define your own stable APIs to tell the developers who to use APIs
and to protect some parts you would like to change in the future. This is
most important if you want to decouple applications for an independent
release cycle.
If you are delivering software components using the Add On Assembly
Kit the control of dependencies to guarantee the installability of custom
made SCs.

To come to the conclusion: ABAP package concept is the most important tool
for software architecture. You can use package checks as part of extended
syntax checks and Code Inspector to check violations of package interfaces.

I’ll discuss these and even more aspects of the ABAP package concepts here
and will even go deeper into pesky details. If you like at SE80 you will find
different options for package checks – “as client” and “as server”.

And last but not least there are two different package check modes:
RESTRICTED and R3ENTERPRISE. You may ask why the concept is so
difficult. In my opinion SAP had no other chance: the software structure of R/3
was too complex and there have been too much unwanted dependencies. On
the way to ECC 6.0 SAP had to solve many problems – the most urgent
comes from the introduction of EhPs that allows to define packages which are
activated after switching in a business function on the customer system.
Therefore you have to control dependencies because no object of a non-
switchable package is allowed to use an object that is switchable. In my
opinion the package concept is a necessary step for development of
switchable units. But therefore SAP had to deal with R/3 code with many
unwanted dependencies – so the definition of a strict and Java-like package
concept was not possible – SAP had to define check modes that allow
violations of package interfaces.

But first we I want to discuss some basic aspects of software development in

ABAP.

Packages and Software Components

https://blogs.sap.com/2011/12/04/abap-package-concept-part-1-the-basics/ 4/17
10/3/2018 ABAP Package Concept Part 1 The Basics | SAP Blogs

SAP and ISVs delivers the software as software components. You can find the
list of installed software components in transparent table CVERS. You can
think of Software components (in short SCs) as special transports containing
metadata. Those transports are installed using transaction SAINT. Let me ask
some simple questions:

1. What’s the difference between software components in ABAP and in

Java (SAP NetWeaver CE)?
2. What’s the difference between ABAP packages and ABAP software
components?
3. What’s the difference between ABAP and Java packages?

There are some differences between SCs (or SWCVs – software component
versions) in both worlds – but one is very important: An SC in Java defines a
persistence unit in terms of JEE. In fact there is no such concept in ABAP –
we have concepts like internal modus and LUW. In Java SCs contain DCs and
so called top level DCs define the “visible” objects of an SC.

What about packages and SCs? These are completely different concepts. An
SC is an artifact from software logistics and can contain complete packages
(in an installation package – AOI). Packages can be assigned to software
components but in contrast to packages they have no representation in ABAP
Workbench.

In Java there is a concept of visibility – you can protect develop objects from
being accessed. In Sap NetWeaver CE there is an additional concept of
accessability. In ABAP there is none of such concepts. Event circular
dependencies are possible which will lead to compilation errors in Java.

Reuse of Development Objects

The most important aspect of package concept is to keep control on reuse. So
let my first think about to do reuse in a proper way. From the view of concept
this very simple: SAP defined package interfaces of their packages and so an
API consisting of ABAP classes, function modules, data elements and so on. If
you want use the ABAP package concepts you should only development
objects that are exposed that way.

So what do you think about reuse of data elements of SAP standard? In my

experience there are many developers who just think of SAP standard as
huge set of data elements they can reuse in their programs. But how to do it
right? I think there is a simple advice:

https://blogs.sap.com/2011/12/04/abap-package-concept-part-1-the-basics/ 5/17
10/3/2018 ABAP Package Concept Part 1 The Basics | SAP Blogs

If you use the data model of an SAP standard application, you should
exactly the data elements of the application.
But misusing them will bring you into trouble. In most cases short texts
and documentation is not correct. The definition of own data elements
will allow you to define proper texts and documentation. Another
consequence of misuse of data elements is that your software is not
merger ready with SAP standard tools like Landscape Transformation:
Basic Operations.

I think I have to clarify the last aspect. When you want to merge and split
systems or change the SAP data (think of organizational management) or
customizing in a disruptive way with tools like SAP LT you have to ensure that
your custom developed application is merger ready. Landscape
Transformation: Basic Operations works on the level of ABAP domains and
will change the value if domains whether they are in transparent tables or in
intransparent data containers. So merger readiness means exactly that that
you develop the way it is described above.

Everything I mentioned above applies to DDIC domains, too. My advice is

simple:

Use SAP domains only if you have a good reason. Merger readiness of
an ABAP application is such a reason. Consider the case that you want
to define a role of the SAP Business Partner application. Therefore you
should create a new data element to have be able to define short texts,
F1-help and search-helps. In this case you should reuse the
BU_PARTNER domain of SAP Standard so that landscape
transformation tools can analyze that this is an proper extension.
If you are using domains like CHARxyz please check whether they are
exposed in package interfaces. And please check to which application it
belongs to avoid unwanted dependencies to SAP applications you don’t
use. Otherwise package checks against package interface are not
useful because they’ll produce too much error messages.

What about reuse of ABAP message classes? In fact I don’t recommend it in

most cases. Message classes are used to define error messages in BAPIRET-
messages, in the Business Application Log (BAL) and sometimes in controlled
dumps. If such an error message occurs with the use access you can find the
correspond line in the ABAP code – but if you reuse error messages from SAP
standard and is not easy to find the right line of code where an error message
was created. And there is another reason not to reuse error messages from
SAP standard: in most cases the long text is not appropriate in the context of
the custom application.

https://blogs.sap.com/2011/12/04/abap-package-concept-part-1-the-basics/ 6/17
10/3/2018 ABAP Package Concept Part 1 The Basics | SAP Blogs

Summary and Outline of the Blog Series

In this weblog I explained some use cases of the ABAP Package Concept
from the point of view of an ABAP developers as well of an software architect.
In the next part of this weblog series I’ll discuss

ABAP Package Concept Part 2 – Package Interfaces of Development

Packages
types of packages: structure packages, main packages and
development packages (NW 7.0)
types of packages checks (NW 7.0)
best practices how to implement the package concept (NW 7.0)
package concept in NW 7.30

Alert Moderator

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

Peter Langner

December 4, 2011 at 10:36 am

Hi Tobias,

thank you for that great blog. I also have the experience, that many ABAP developers
still think in development classes and only have a poor knowledge of the packadge
concept. There is still a lot of work to tell the story…

Peter

https://blogs.sap.com/2011/12/04/abap-package-concept-part-1-the-basics/ 7/17
10/3/2018 ABAP Package Concept Part 1 The Basics | SAP Blogs

Tobias Trapp Post author

December 4, 2011 at 1:41 pm

Hi Peter,

glad you liked the blog. I think in the next part I’ll explain how to look for
package interface and how to create them.

Cheers,
Tobias

BTW: At the moment I’m using some of the semantic techniques I

described in Semantic Web Technologies Part 3 – Looking Into AS ABAP to
analyse code. Perhaps I’ll write a follow up-blog about this, too.

Krishnendu Laha

December 4, 2011 at 12:00 pm

Brilliant idea, looking forward for future blogs..

Former Member

December 4, 2011 at 1:24 pm

There are some very cool security advantages as well.

It would be nice to see this aspect mentioned in the blogs as well.
I have been ranting about it for a long time in the forums and am patiently waiting for several
runtime syntax checks to say “Hello World”…
Cheers, Julius

Tobias Trapp Post author

December 4, 2011 at 1:37 pm

Hi Julius,

https://blogs.sap.com/2011/12/04/abap-package-concept-part-1-the-basics/ 8/17
10/3/2018 ABAP Package Concept Part 1 The Basics | SAP Blogs

you are absolutely right: when you use package checks SAP developers
are forced to use proper APIs containing autority checks – I think I already
mentioned it. But I will get in detail when I will discuss best practices for the
content of package interface: put classes and functions modules into an
interface but not the table structure. Is that what you have in mind?

This is an important point but using dynamic statements (code generation,

dynamic SELECTS, method calls within XSLT oder ST programs) you can
access any transparant table. The only possibility to guarantee security
would be put package checks in the level of the ABAP kernel. For this
concept IMHO a system wide switch is not enough – we need the concept
of “dangerous” code fragments like in C#. This would allow to introduce the
ultimate security step be step.

Cheers,
Tobias

Tobias Trapp Post author

December 4, 2011 at 1:38 pm

Hi Julius,

you are absolutely right: when you use package checks SAP developers
are forced to use proper APIs containing autority checks – I think I already
mentioned it. But I will get in detail when I will discuss best practices for the
content of package interface: put classes and functions modules into an
interface but not the table structure. Is that what you have in mind?

This is an important point but using dynamic statements (code generation,

dynamic SELECTS, method calls within XSLT oder ST programs) you can
access any transparant table. The only possibility to guarantee security
would be put package checks in the level of the ABAP kernel. For this
concept IMHO a system wide switch is not enough – we need the concept
of “dangerous” code fragments like in C#. This would allow to introduce the
ultimate security step be step.

Cheers,
Tobias

Former Member

https://blogs.sap.com/2011/12/04/abap-package-concept-part-1-the-basics/ 9/17
10/3/2018 ABAP Package Concept Part 1 The Basics | SAP Blogs

December 4, 2011 at 1:47 pm

Hi Tobias,
AFAIK the package check is not only limited to SE80.

It is also extended to the runtime environment but is currently

only a warning in the developer trace.

Step by step this will be switched to runtime error messages

when the package actually has complete APIs which must be
used.

BC-SEC is a nice example of this, but I am not sure whether I

will still live to see the day of this switch..

Cheers,
Julius

Peter Inotai

December 4, 2011 at 10:56 pm

Hi Tobias,
Nice topic. I’m looking forward for the next one
We use package check with R3ENTERPRISE on SAP R/3 4.70/Basis 6.20. Unfortunately it’s
really time-consuming to set up and maintain, but it works
I already had a chance to look at the NW 7.10 version, which looks much more convenient.
Keep blogging,
Peter

Tobias Trapp Post author

December 4, 2011 at 11:11 pm

Hi Peter,

great to find other people working with check mode R3ENTERPRISE. It

would be very interesting to know what’s most time consuming. Perhaps we
can share experience and find best practices.

Best Regards,
Tobias

https://blogs.sap.com/2011/12/04/abap-package-concept-part-1-the-basics/ 10/17
10/3/2018 ABAP Package Concept Part 1 The Basics | SAP Blogs

Tobias Trapp Post author

December 4, 2011 at 11:12 pm

Hi Peter,

great to find other people working with check mode R3ENTERPRISE. It

would be very interesting to know what’s most time consuming. Perhaps we
can share experience and find best practices.

Best Regards,
Tobias

Peter Inotai

December 4, 2011 at 11:21 pm

>It would be very interesting to know what’s most time

consuming.
For us is to add the “Use access”-es. We use own program to
generate them, otherwise it would take forever.
Other problem, that we would allow access within a structure
package any component to any component. However in SAP’s
logic it has to be in the same level, lower level cannot access
higher level because of encapsulation. So, sometimes we have to
reorganize our subpackages because of SAP’s logic.
Our main motivation was to control the access between in our
packages. However we realized, that we have to allow access
also for SAP components. This has the nice “side effect” that we
can control, which SAP components we allow to our packages.
For example before we didn’t have a tool to avoid usage objects
from the PI package.

I believe there is only very little number of customers using this

tool.

Peter

Tobias Trapp Post author

December 5, 2011 at 3:08 am

In NW 7.0 there is a wizard which analyses a

violation of interfaces and makes suggestion which

https://blogs.sap.com/2011/12/04/abap-package-concept-part-1-the-basics/ 11/17
10/3/2018 ABAP Package Concept Part 1 The Basics | SAP Blogs

use access can solve the problem and even create

this use access. Is this what you did?

An automated generation seems a little bit too

dangerous because IMHO a sofwtare architect
needs to decide which use access is correct.

An automatic tool support when refactoring the

package hierarchy would be very cool indeed.
Perhaps we should collect those requests and go
to idea place?

Best Regards,
Tobias

Tobias Trapp Post author

December 5, 2011 at 3:10 am

In NW 7.0 there is a wizard which analyses a

violation of interfaces and makes suggestion which
use access can solve the problem and even create
this use access. Is this what you did?

An automated generation seems a little bit too

dangerous because IMHO a sofwtare architect
needs to decide which use access is correct.

An automatic tool support when refactoring the

package hierarchy would be very cool indeed.
Perhaps we should collect those requests and go
to idea place?

Best Regards,
Tobias

Peter Inotai

December 5, 2011 at 3:26 am

>In NW 7.0 there is a wizard which

analyses a violation of interfaces and
makes suggestion which use access

https://blogs.sap.com/2011/12/04/abap-package-concept-part-1-the-basics/ 12/17
10/3/2018 ABAP Package Concept Part 1 The Basics | SAP Blogs

can solve the problem and even create

this use access. Is this what you did?

We’re in 4.70/6.20, so we cannot use

the Explain tool, which is available
as of 7.00 via a certain support
package level.
We created our own program for
access usage generation, which is
already considers certain company
specific rules for our
packages/package hierarchy.

>An automatic tool support when

refactoring the package hierarchy
would be very cool indeed.
I cannot agree more

Peter

Peter Inotai

December 5, 2011 at 1:46 am

Do you have any info about Package hierarchy tab in NW 7.30?

It seems this nice feature was introduced in NW 7.00, but it seems
it’s no longer available in NW 7.30

BTW do you have also any info about

CheckAspct/CheckConfiguratn/Check config. Rule? They are
available in the Development Coordination tab in the object
selection in SE80, but I couldn’t find any info about them yet.

Thanks,
Peter

Tobias Trapp Post author

December 5, 2011 at 3:13 am

I’ll blog about the differences between NW 7.0 und

7.30. IMHO the package concept got more
complicated: You have access control lists,
enhancement extension packages and so on…
https://blogs.sap.com/2011/12/04/abap-package-concept-part-1-the-basics/ 13/17
10/3/2018 ABAP Package Concept Part 1 The Basics | SAP Blogs

Best Regards,
Tobias

Peter Inotai

December 5, 2011 at 3:31 am

>I’ll blog about the differences

between NW 7.0 und 7.30.
Unfortunately it’s difficult to find some
official docs about it.
In the SAP Online help there are some
info about the new concept for NW
7.1:
http://help.sap.com/saphelp_nwpi711/helpdata/en/18

I’m looking forward to your blog

about this topic.

Peter

Kumud Singh

December 5, 2011 at 6:00 am

Hello,
I read twice to get into the feeling of it.Thanks for writing it this ways. When you move into
practical, can I please request you to show an example wherein we can combine standard
SAP into our customized application development.
Just my thought,at your wish certainly.
I am yet to read the book though which yourself and thorsten suggested. (Development from
Scratch)

Regards,
Kumud

Former Member

December 15, 2011 at 9:47 am

https://blogs.sap.com/2011/12/04/abap-package-concept-part-1-the-basics/ 14/17
10/3/2018 ABAP Package Concept Part 1 The Basics | SAP Blogs

This is an important and timely topic for many projects. As the ABAP development landscape
continues to evolve, best practices for software logistics need to evolve as well. Hopefully
more and more projects will embrace this concept as a result of your blog series.

Paul Hardy

March 1, 2017 at 6:42 am

I have been thinking about this ever since I heard you give a talk on this subject in SAP
Inside Track in Bonn in 2010.

I have to confess I still don;t understand 100%, but have a gut feeling this is really
important, even for programmers who do not develop third party add-ons for SAP
systems.

Say I have a special class to handle the really complex logic regarding monster special
properties (do they have seven heads, are they a hundred foot tall, do they breathe fire
etc).

Many applications use this class, and I gather the idea is to have the calling classes only
know a bout the interface the special class implements, and not the real class itself.

In Java, as I understand it, you do this to reduce compilation time, as when you change
a class all the concrete classes the changed class reference have to recompile as well,
but not if you use references to interfaces as opposed to references to concrete classes.

Naturally we do not have the problem in ABAP of programs taking a very long time to
compile, but we still use interfaces in order to favour composition over inheritance.

Anyway, is the desired architecture that the calling applications are all in their own
packages, the special class is in it’s own package, and the interface is in yet another
package? That seems to be the design Martin Fowler uses in his book on refactoring,
when he introduces interfaces to reduce the compilation time of classes.

https://blogs.sap.com/2011/12/04/abap-package-concept-part-1-the-basics/ 15/17
10/3/2018 ABAP Package Concept Part 1 The Basics | SAP Blogs

What about custom DDIC elements? Do they live in their own package? Or do you have
more than one identical DDIC object with different names in different packages?

Cheersy Cheers

Paul

Tobias Trapp Post author

March 10, 2017 at 8:51 pm

Hi Paul,

my recommendation is that you try to copy the Java programming model.

This means that you think in terms of APIs. Those APIs contain classes and
the dictionary elements that are used (f.e. as parameter of the classes).
Those APIs are provided using package Interfaces. Feel free to provide
many of those Interfaces describing different APIs. The client package
which uses this API just has to declare the usage of this package interface.

Does it answer your question?

Cheers,
Tobias

P.S.: Let’s talk about monsters. If I remember right NW 7.30 had a slightly
different package concept but luckily (at least I think this way) this was
discontinued in SAP NetWeaver 7.40, 7.5 and will hopefully vanish forever

But there is another monster: At least in NW 7.40 it was possible to create

your own package interfaces containing even unvisible elements f.e. from
forbidden packages. I didn’t try it out whether this is still possible – but this
mechanism allows to client to define APIs. I can’t recommend it since only
the “server” package should be able to define ist API.

So again my conclusion is that you should try to adapt Java-like best

practices for creating package interfaces. If I remember right Java forbids
cyclic dependencies which are possible in ABAP. But even in ABAP I
consider cyclic dependencies as poor architecture style.

https://blogs.sap.com/2011/12/04/abap-package-concept-part-1-the-basics/ 16/17
10/3/2018 ABAP Package Concept Part 1 The Basics | SAP Blogs

Share & Follow

Privacy Terms of Use

Legal Disclosure Copyright

Trademark Sitemap

Newsletter

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