ABAP Package Concept Part 3 – Package Hierarchy, C...

ttrapp · ‎2012 Mar 01

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.