ABAP Package Concept Part 3 - Package Hierarchy, Coupling and Cohesion - SAP Blogs

10/3/2018 ABAP Package Concept Part 3 Package Hierarchy, Coupling and Cohesion | 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 3 Package

Hierarchy, Coupling and Cohesion
March 1, 2012 | 1,150 Views |
Tobias Trapp
more by this author
ABAP Development
abap | package | sapmentor
share
0 share tweet share
Follow
https://blogs.sap.com/2012/03/01/abap-package-concept-part-3-package-hierarchy-coupling-and-cohesion/ 1/18
In the first part of this weblog series I introduced the ABAP package concept
(ABAP Package Concept Part 1 – The Basics ) and package interfaces (ABAP
Package Concept Part 2 – Package Interfaces of Development Packages).
Now I introduce packages hierarchies and discuss how they can be used to
structure applications: what packages build an application and how to define
functional cohesion in an application. Please be aware that I describe package
concept in Releases 6.10 up to 7.02 and things will change slightly in 7.30 but
this is topic for another blog.
In the last instalment of this series I discussed package interface which

reflects the concept of coupling: what are the dependencies between software
packages within in application and between applications? We will discuss
another way the package concept supports this concept and the related
concept of cohesion which means how “focused” a software module like a
package is.
Hierarchies of Packages
Why are package hierarchies useful? When you have a look at legacy
development classes there was no concept of package hierarchies. As a
consequence there was no concept which set of development classes form an
application. Using package hierarchies you can make this explicit. Why is this
necessary?
Packages of an application are usually tightly coupled and have to be

shipped in the same transport layer.
All packages of an application are deployed in the same software
component. You can assign a package to a component but there is no
explicit concept of software components in AS ABAP because they are
created in final assembly systems with tools like AAK.
With package hierarchies SAP bundled legacy development classes using

structuring packages and defined the software structure explicitly.
Naming Conventions will fail

Without structure packages software architects tried to tackle above
mentioned challenges with naming conventions but those conventions have
drawbacks:
No naming convention can foresee all above mentioned aspects.

They make software hard to change. What happens if the architecture
of a system changes? Think of the case that you want to deploy same
parts of a solution as a reuse tool in a deeper software layer for

example. What happens if you have to split a huge application into to
smaller ones?
I can give you lots of more examples but the consequence is clear: at a certain
time you will have to violate naming conventions. And even if you manage to
avoid violations there is the danger that those naming conventions will be
forgotten in the long run or they are getting too complex.
“From Software Components to Structure Packages”

Since Release 6.10 SAP explained this new software structuring paradigm in
SAP Help Portal:
They introduced one or more so called structure packages that contain

all packages of a software component. A structure package can
represent a software component (like ABA represents SAP_ABA
software component) or can represent a big application within a
software component.
A structure package consists of so called main packages (I omit the
case of included structure packages) which usually correspond to
encapsulated parts of application like tool suites.
In the bottom of the package hierarchy are so called development
packages which correspond to legacy development classes and contain
development objects.
Let me summarize: With structure packages you can define the overall
structure of a huge development. Using them you can define dependencies to
structure packages from SAP standard. But you have to use this option
because those dependencies are only checked in a special package check
mode (called “R3ENTERPRISE”). There are also weaker package check
modes (“RESTRICTED”) that don’t require structure packages.
Hierarchies and Visibility

This most import thing you have to know is that the package hierarchy defines
visibility and controls access of development objects. The reason is simple: In
a package hierarchy each parent package can restrict the use access: if it has
package check “as server” only you can access development elements within
its hierarchy using package interface. In fact package interface from deeper
packages can be propagated to parent packages. If we don’t propagate
certain interfaces we declare that a certain function is not accessible from
outside the hierarchy.
As a consequence the packages concept makes it easy to access services

from sibling packages but you can restrict usages at the level of the common
parent packages. So a subtree within a package hierarchy defines a set of
packages that can use each other’s functions. This corresponds to the
principle of cohesion: in software engineering we usually try to group
development objects that belong together. This may sound to abstract but I will
discuss an example below.
There is another aspect of package hierarchies: if a certain package declares

a use access the same use access has to be declared in the higher packages
of the hierarchy. As a consequence you can see at the top level all used
interfaces of packages in the hierarchy. There is an exception to this rule:
structure package need only to define use access to other structure packages.
How to access a package within an hierarchy

Every ABAP programmer frequently uses function modules from financial
mathematics. SAP created to packages: one for financial mathematics (FIMA)
and another one for financial conditions (FICO). In fact those packages don’t
come alone – we other packages (FIMA_TEST) for example. Those packages
have a strong cohesion: the test functions use the functions from financial
mathematics but they don’t expose services because they are only test
applications that are useful for quality insurance and serve a documentation
how to use FIMA API.
So SAP grouped those packages in a package hierarchy in a package

FS_FIM (see picture below).
This has many advantages: there is an explicit main package for financial
toolset. Every contained package can propagate its interface to the main
package so you can reduce the number of use accesses at the side of the
client because interfaces are bundled:
Let me mention three things:
SAP decided to expose the interface of package FIMA_TEST in the

main package. This is possible but you don’t need to do it. There is also
the possibility to exclude this interface and to “hide” test functions.
The package concept made it possible to group legacy development
classes. The criteria how to group them is coupling: is there a strong
connection between those packages? Usually the there is a tight
connection between packages of an application where applications
should be more loosely coupled.
We can use packages to introduce cohesion: Is a package focused on

a certain way? FIMA package is “focused” because it contains reuse
functions for financial mathematics.
Now I will discuss how to declare a use access for function modules in FIMA
package. Only if you want to express the dependencies between structure
packages (package check mode R3ENTERPRISE) you have to declare a use
access to the structure package at the top of the package hierarchy containing
the FIMA package which is structure package ABA. ABA exposes many
interfaces: a default interface, a virtual default interface and a filter interface:
In fact you have the choice: You can declare a use access to the default
interface or to the virtual default interface (and on the level of structure
package the access to the filter interface). A virtual default interface is a kind
of carte blanche that grants access to all elements but can be restricted to a
certain namespace using the filter interface.
As I showed above the services from financial mathematics are exposes in

interface FS_FIM_INTERFACE_MAIN and you have to declare a use access
to this interface in any case: package check mode R3ENTERPRISE as well as
RESTRICTED. Here is an example that shows how the Accounting Engine
declares a use access:
I explained the connection between package checks and package hierarchy.

This may sound very complicated and so I will come back to this example in
the next installment of this series where I show how to perform package
checks.
Cohesion as Quality Criteria of an ABAP Application

So what is package concept all about? It’s all about cohesion: are the parts of
a package grouped arbitrarily or is there an underlying design principle? Are
the packages of an ABAP application grouped arbitrarily or is there a
structure? With an underlying design principle which is understood by
developers maintenance it’s easier because a certain aspect or function is
located in a defined place you can easily identify parts of the software that
implements a certain process.
We will discuss grouping of modules in two scales:
development objects can be grouped in packages

packages can be group to define applications
There can be many different grouping criteria – let me first give some
examples for development objects:
Sometimes it makes sense to separate development objects from other

development objects – think of generated ABAP proxies for examples
which should be generated in own packages to prevent wild reuse.
As applications grow it makes sense to separate UI (especially new UIs
like WDA) in own packages.
Development for special purposes (like migration and test) should be
done in special packages.
You can create packages for different processes in an application.
Using package hierarchies you can group packages according special criteria
– let me mention a few:
functional cohesion on package level: which packages are tightly

connected?
business process: which process that is realized in the application?
bundling: which packages build an application?
transport layer: packages that belong to the same transport layer and
should be transported together
dependency to SAP components: packages that have the same
dependencies to structure packages / components of SAP standard
dependency to applications of SAP standard: which application is
extended?
Those aspects are aspects of cohesion which is explained very well in

Wikipedia: cohesion means how “focused” a piece of software is:
A software architect has a clear vision of the application that has to be created
and knows about cohesion aspect within the application, he know interfaces to
SAP standard and to SAP applications that are extended. Let’s look at an
example in SAP Standard (a SOA tool called Error & Conflict Handler – ECH)
where in most cases the structure has been chosen with regards to functional
aspects like archiving:
I made the experience that many SAP customers don’t care about cohesion
and the reason is very simple: the package concept is new and many SAP
customers only know the concept of naming convention. As a consequence
they create packages like ZFI for FI development, ZCO for CO development
and so on. Software engineering finds the correct words for it: “coincidental
cohesion” which Wikipedia calls the worst cohesion type because it has the
semantics like: “develop here something with FI”. Of course this is the worst
thing you can do: Is the development an extension of an existing FI process or
a new process? Or is it used for migration? What about cross-cutting concerns
used both for FI and CO – is it automatically BC? Sometimes those design
criteria for packages are mixed with organizational aspects: FI guys develop in
ZFI and are responsible for that package – but what happens if Basis
developers develop parts of an FI process – is it part of package ZFI or ZBC?
What happens if the organizational structure changes?
The answer is simple: If the development consists only of one or two reports
resp. BAdIs, packages like ZFI and ZCO are useful. If the development gets
more and more complex then packages with coincidental cohesion which have
no clear focus tend to grow exuberantly. The consequence is that such
maintenance will be difficult and expensive.
Summary
In this blog I discussed how packages can be structured and nested
hierarchically. I explained how this affects to package checks: In a package
hierarchy you can control access to contained packages: the packages may
be coupled by using each other’s interfaces but not every interface has to be
propagated by the surrounding packages.
Using packages you can group development objects as well as other

packages. This can be done in different ways and I used the concept of
cohesion as quality criteria. Usually cohesion used as property of smaller
software modules but I think we can it apply general software pieces that are
parts of applications.
Naming conventions are useful and I recommend using defined (and if

possible unique) prefix for all elements in a package but should be aware that
those naming conventions can’t replace the package concept because of the
following reasons:
We can use the package concept to express different aspects of

cohesion which reflects the architecture of the system.
We can use the package concept to support aspects of software

logistics to group packages after transport layers and according to
dependency to SAP software components.
With use access we make dependencies visible and we can express
the aspect of coupling (which is different from cohesion): How are the
dependencies between packages? Which dependencies are allowed
and which are forbidden?
So my advice is the following:
Use naming conventions but don’t try to use them for challenges the
package concept was made for.
Try to find a meaningful set of packages and think in terms of functional
cohesion.
Don’t try to use all features of the package concept – use the ones that
help you most.
Try to avoid complex package hierarchies. Have a look at recent
developments in SAP standard to get inspiration.
Alert Moderator
12 Comments
You must be Logged on to comment or reply to a post.
Peter Inotai
March 2, 2012 at 12:50 am
Hi Tobias,
Thanks for this blog. It’s a great one… as always

The topic is really interesting, but somehow package concept is not so important for in-
house development unfortunately. The newly developed objects are just saved
somewhere … most developers are still using packages like development classes.
The whole story is different, when you have to develop components or add-ons, which
could be independently installed to different systems.
>What about cross-cutting concerns used both for FI and CO – is it automatically BC?
Maybe for FI and CO you can still group them as some kind of mixed Accounting
package.
However when you mix different components like ERP and CRM you have to go to the
direction to component ABA. I have the impression more and more SAP standard
objects are moved here. I just recently discovered ABA_GEN and all the subpackages.
I’m looking forward for the 7.30 related blogs.
I wonder what will happen in customer systems, when package check won’t be optional
anymore. It will be an interesting story
Cheers,
Peter
Tobias Trapp Post author
April 18, 2012 at 5:48 pm
Hi Peter,
in NW 7.30 you can still switch off package checks – in fact you have to
change a system parameter. In fact the docu is wrong and I gave this
feedback already to the docu writers – in some parts of SAP Help portal this
is very simple because of the feedback mechanism.
Please compare the package concept of NW 7.30

(http://help.sap.com/saphelp_nw73/helpdata/en/4a/a197adacd5007fe10000
000a42189c/frameset.htm) and NW 7.03
(http://help.sap.com/saphelp_nw70ehp3/helpdata/en/fd/f39de8ae6f11d596c
000a0c94260a5/frameset.htm). In fact both package concept are different
and some IMHO confusing features of NW 7.30 vanished.
Cheers,
Tobias
Peter Inotai
April 19, 2012 at 7:28 am
Hi Tobias,
Thanks for the info about NW 7.03/7.30.
I also noticed recently that in NW 7.03 a maintenance view

PAKPARAM_V was created for these parameters. However I
couldn’t find any IMG note for it yet, which would make sense
to me.
Cheers,
Peter
Paul Hardy
March 2, 2012 at 3:05 am
Greetings,
I was at your talk at the SAP inside track in the Netherlands and I found it fascinating. Until
such time as such a check does become compulsory you are going to have a hard time
getting this concept over to people, as you will get the good old “it works fine as it is”
argument. You need a big list of “this is what problem you are going to get eventually if you
do not do this correctly” type examples.
Also, can you really trust not only developers but SAP itself not to change the exposed
elements of the interface, or is it enforced somehow?
Cheersy Cheers
Paul
April 18, 2012 at 4:44 pm
Hi Paul,
I think the SAP package SAI is a good example. SAP introduced it very early
and there have been many changes to it in 6.40, NW 7.0 SP 15, NW 7.01 and
so on. The reason was simple: SAP optimized the web service infrastructure
several times. Do you remember the transaktions WSCONFIG and WSADMIN
– now you use SOAMANAGER. But if you used only elements that are exposed
in packages interfaces everything was fine – although SAP changed even the
data model.
You are asking a good question: is it possible that SAP removes exposed
elements? Of course it is – but it is also so possible that SAP deletes some
data elements as it happened in CRM 7.0 upgrade. It is even worse: From a
legal point of view most function modules and classes are not supported by
SAP. But is it really a problem? From my experience ABAP developers can
develop stable software if they look at SAP Business Suite:
If a framework is used in SAP Business Suite quite often then
incompatible changes are not likely.
If development elements are exposed in package interface it is not that
likely that SAP will do incompatible changes. Within SAP package
checks are used, too.
Let me summarize: Of course incompatible changes are possible and I give you
examples: function module WS_UPLOAD is of no use in unicode systems.
There have been even incompatible changes to ABAP language for unicode
systems. If you want to minimize the risk of having trouble after a release
upgrade then think of both advices from above: use frameworks hat are heavily
used within SAP Business Suite and try to use only exposed elements.
Cheers,
Tobias
Former Member
April 7, 2012 at 3:10 pm
Great blog, Tobias,
and surely it is the best strategy to start development with a clear concept of packages
and package dependencies.
But for systems that have already been visited for a decade or so by many developers,
coming from various consulting teams, each of them making not more than bringing
precisely his particular task to work, usually leaves a chaos of Z packages and
dependencies. Nobody will pay the effort for cleaning this up.
For such a situation, I found a pragmatic approach for bundling development objects
together without caring too much about their package membership: the piece lists of
CTS (SE01).
It doesn’t save me the work of decoupling, but it defines a new way of grouping
development objects together, independent of the package hierarchy/ies. The piece list
is a development object itself which can be maintained, transported and extended, like
any other development object. On the other hand, it is a kind of “non-transportable
transport”, which can be copied into a “real” transport.
Together with a report Z_DECO_TRAN which helps me find forward references by

looking at the DB tables CROSS, WBCROSSGT and WBCROSSI, I can add iteratively
objects to a piece list until it contains no more cross references than to SAP_ABA and
SAP_BASIS, which makes the object list transportable into any SAP target system. The
name is in reference to a transaction DECO declared as SAP-internal which had a
similar goal during HR decoupling.
I have described the details (only in German language, sorry… ) in my blog

http://ruediger-plantiko.blogspot.com/2012/04/abap-code-pragmatisch-entkoppeln.html
Regards,
Rüdiger
April 18, 2012 at 4:08 pm
Hi Rüdiger,
I like your blog and you cover cool and interesting topics like programming
JavaScript in ABAP, DSLs and so on. Great work! I think many people
would love to see your blogs on SCN.
Please, can you explain the advantage working with a piece list? Another
approach would be to create a structure package with dependencies only to
ABA and BASIS. The package check in mode R3ENTERPRISE would
show you unwanted dependencies.
Cheers,
Tobias
Former Member
April 20, 2012 at 7:12 am
Hi Tobias,
thanks for your feedback on my blog. Blogging in the SCN

might be a future option. [As you mention JavaScript in ABAP,
by the way: It’s a pity that the class CL_JAVA_SCRIPT has
been marked obsolote in SAP_BASIS 7.02, and the docu
explicitly mentions that there will be no substitute! And this is in
times where everybody is speaking about fluid, expressive
syntax, where Java has incorporated a framework for dynamic
languages, &c.]
You are surely right: In a fresh SAP system, I would model the
package dependencies from the beginning, as you outlined it
in this blog series. But this is not feasible in a system which is
already productive since 10 years, and dozens of consulting
teams contributed their stuff. From time to time, new SAP
systems with dedicated purposes are added to the system
landscape. We then use a piece list, which has only
dependencies to SAP_ABA and SAP_BASIS, to import some
of our core reusable software parts and tools into that system.
The advantage is that the piece list is treated like a common

development object in the source system: New objects can be
added in the course of time, and the package assignments are
secondary. This came out useful for us.
Regards,
Rüdiger
Paul Hardy
May 18, 2012 at 6:32 pm
Hello, I have a question on this, which may well show my total alck of understanding of
the whole concept.
I copied an example class from the book “Design Patterns in Object Orientated ABAP”
into my PI system, as it was the only one on Netweaver 7.0 at the time.
This class uses the method CL_GUI_DOCKING_CONTAINER->GET_HEIGHT which

appears at first glance to be public. The extended program check however throws up a
red light which I think is related to the package interface saying “cannot use the class
from package SCET in any of the usgae types use object or type”. A typical SAP
message in that it is cryptic and obscure.
A red light in the extended program check would prevent a transport out of the
development system in our head office SAP system.
Luckily I get pointed at an analysis tool which then throws up some more cryptic
messages.
I think I am being told to add some interfaces into the pacakge of the custom ABAP class
under analysis. Would that be correct?
Again, I am sorry if I have missed the whole point of this.
Cheersy Cheers
Paul
P.S. I am at Heathrow waiting to fly to Australia at the moment but all flights are delayed
for an hour, to allow for the arrival of the Olympic Torch!
Rudy Clement
May 21, 2012 at 2:35 pm
Hi Tobias,
Thanks a lot for sharing your knowledge with the community! I was also present at the
SAP Inside Track in Eindhoven last year were I saw your presentation. I found it very
interesting!
Me and my colleagues are currently trying to use the package concept within a new
project at our customer. We are on a NW 7.02 system. But there is one thing we don’t
understand. Some ‘common’ SAP objects are not exposed in any package interface. For
example, when using class CL_ABAP_TABLEDESCR, the package check will give
errors. There is no package interface that exposes this class while several other
CL_ABAB_*DESCR classes are exposed via _AKB_INITIAL.
Same problem for persistent classes: when using persistent classes, we want to catch
exceptions from package SOS_EXCEPTION like CX_OS_OBJECT_NOT_EXISTING.
But this package doesn’t have any package interface. The package check even gives an
error on the base agent class which is fully generated by SAP!
Do you have any explanation for this? Maybe (hopefully) we are just missing a part of
the theory and you can guide us in the right direction… Or did SAP simply forget to add
objects like these to package interfaces? If that’s the case, how should we handle this?
Once again, thanks for sharing your knowledge!
Kind regards,
Rudy Clement.
January 13, 2017 at 1:56 pm
Hi Rudy,
I don’t have any Access to a 7.02 system. Moreover I don’t know the check
mode you are using(transparent table PAKPARAM). If you use mode
R3ENTERPRISE you package has to include _BASIS_VIRTUAL_DEFAULT
and the ABAP package must be contained in a structure package that
contains package Interfaces _BASIS_VIRTUAL_DEFAULT and
_BASIS_VIRTUAL_FILTER.
Best Regards,
Tobias
Joachim Rees
January 11, 2017 at 2:10 pm
Hey, Tobias,
you link to the first 2 Parts in the start of your blog, very nice.
How about also linking to the next part (https://blogs.sap.com/2012/07/22/abap-package-
concept-part-4-how-to-perform-package-checks/) in the end?!
-> That would make it easiert for your readers to read on (or even know that there is
another part!)
best
Joachim
PS: I stumbled about this when trying to get up to date with ABAP Packages – would you
today (5 Years later, NW7.5 being around) still recommend you series as a good read?
Or have things change drastically since then?
Share & Follow
Privacy Terms of Use
Legal Disclosure Copyright
Trademark Sitemap
Newsletter

ABAP Package Concept Part 3 - Package Hierarchy, Coupling and Cohesion - SAP Blogs

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

ABAP Package Concept Part 3 - Package Hierarchy, Coupling and Cohesion - SAP Blogs

Transféré par

Droits d'auteur :

Formats disponibles

10/3/2018 ABAP Package Concept Part 3 Package Hierarchy, Coupling and Cohesion | SAP Blogs

ABAP Package Concept Part 3 Package

In the last instalment of this series I discussed package interface which

Packages of an application are usually tightly coupled and have to be

With package hierarchies SAP bundled legacy development classes using

Naming Conventions will fail

No naming convention can foresee all above mentioned aspects.

parts of a solution as a reuse tool in a deeper software layer for

“From Software Components to Structure Packages”

They introduced one or more so called structure packages that contain

Hierarchies and Visibility

As a consequence the packages concept makes it easy to access services

There is another aspect of package hierarchies: if a certain package declares

How to access a package within an hierarchy

So SAP grouped those packages in a package hierarchy in a package

Let me mention three things:

SAP decided to expose the interface of package FIMA_TEST in the

We can use packages to introduce cohesion: Is a package focused on

As I showed above the services from financial mathematics are exposes in

I explained the connection between package checks and package hierarchy.

Cohesion as Quality Criteria of an ABAP Application

We will discuss grouping of modules in two scales:

development objects can be grouped in packages

Sometimes it makes sense to separate development objects from other

functional cohesion on package level: which packages are tightly

Those aspects are aspects of cohesion which is explained very well in

Using packages you can group development objects as well as other

Naming conventions are useful and I recommend using defined (and if

We can use the package concept to express different aspects of

We can use the package concept to support aspects of software

So my advice is the following:

March 2, 2012 at 12:50 am

Thanks for this blog. It’s a great one… as always

I’m looking forward for the 7.30 related blogs.

Tobias Trapp Post author

April 18, 2012 at 5:48 pm

Please compare the package concept of NW 7.30

April 19, 2012 at 7:28 am

Thanks for the info about NW 7.03/7.30.

I also noticed recently that in NW 7.03 a maintenance view

March 2, 2012 at 3:05 am

Tobias Trapp Post author

April 18, 2012 at 4:44 pm

April 7, 2012 at 3:10 pm

Great blog, Tobias,

Together with a report Z_DECO_TRAN which helps me find forward references by

I have described the details (only in German language, sorry… ) in my blog

Tobias Trapp Post author

April 18, 2012 at 4:08 pm

April 20, 2012 at 7:12 am

thanks for your feedback on my blog. Blogging in the SCN

The advantage is that the piece list is treated like a common

May 18, 2012 at 6:32 pm

This class uses the method CL_GUI_DOCKING_CONTAINER->GET_HEIGHT which

Again, I am sorry if I have missed the whole point of this.

May 21, 2012 at 2:35 pm

Once again, thanks for sharing your knowledge!

Tobias Trapp Post author

January 13, 2017 at 1:56 pm

January 11, 2017 at 2:10 pm

Share & Follow

Privacy Terms of Use

Legal Disclosure Copyright