Application Development Blog Posts
Learn and share on deeper, cross technology development topics such as integration and connectivity, automation, cloud extensibility, developing at scale, and security.
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 

Interfaces of Structure Packages and Decoupling AddOns from the Core

ttrapp
Active Contributor
‎2016 Jul 29 9:32 AM
6,628

This blog entry is about architecture of ABAP applications. You can see it as part of my series about the ABAP package concept. The topic of this blog series is the following: How can we add new features like UIs to existing ABAP applications? How can we establish interfaces and make them explicit? From an abstract point of view it is about software structure. In my last blog I showed that SAP introduced new features that we can use to obtain a better software structure and refactor the package structure of old code. Now I discuss aspects of decoupling and an apropriate interface stategy for structure packages and the types of interfaces of structure packages: virtual default packages, filter packages and default interfaces (now called standard interfaces) with focus on the latter ones. The blog may be interesting for software architects of ABAP architectures who are familiar with ABAP package concept and want to take it to a new level: how can we develop little applications (think of Fiori-like apps) on top of an existing ABAP application (called “core”) considering following restrictions:

  • We don’t want to touch the core. This is reasonable if we have a core API consisting of classes and functions modules but also ABAP Core Data Services.
  • The extension (also called AddOn component) may have a faster release cycle than the core. It can consist of application logic, OData services but sometimes even have its own data model.
  • The AddOn module uses only this dedicated API of the core exposed as package interfaces. Therefore we have to encapsulate the core without introducing a strong encapsulating of all development packages of the core.

A typical example of those AddOns are Fiori Apps that SAP delivers as additional software components. Those software components are installable on top of the SAP software components like SAP_APPL for example. But you can also use those techniques for larger development task like Enterprise Extensions SAP developed in the past. I stole this picture from the SAP AAK documentation since it shows the principle of layered architectures very well. Please be aware that architectures with too many layers are very problematic in terms of software development, deployment and test. If I understand the slides from SAP, shown at DSAG events, describing the new digital core correctly, But I think the best solution is a low number of layers: take as much as necessary but not too much. If it is possible then you should try to get rid of not necessary layers because it is positive in terms of TCO.

Before I want to go into details I have to define the scope of this blog entry. Here I only want to discuss one aspect: How you define packages interfaces to define a proper API for the core development.

I am well aware of the fact the overall problem is far from being trivial. Just let me mention additional aspects that are crucial for AddOn development for the sake of completion:

  • You have to create software components for the AddOns using the AAK tool. Assumed that the core is shipped as a software component, too, you can define dependencies between the software component versions of the core the extensions. This is described in detail in the AAK documentation.
  • Please be aware that AAK 5.0 has many new and exciting features – f.e. you can create software components that can be deinstalled. Of course this may problematic in terms of compliance if transparent tables containing application or customizing data will be deleted.
  • Sometimes it can be the case that you need BAdIs to extend the functionality of the core and exactly here the Switch Framework can help you. Please be aware that even reversible Switches are meant by SAP only for being switched on. Switching them off is possible bit this is another story.
  • An API should be stable and should be only changed in a compatible way. As far as I know there is no toll in AS ABAP that will help you to ensure it.

Defining an API seems Easy…

Let’s get now back to the original topic of this blog entry. One major challenge is to define an API for the core. Those API should have following properties:

Encapsulating the Core

When I tried out encapsulation I encountered some challenges. The first one is easy: usually the core doesn’t have an explicit API consisting of packages interfaces, so you have to create one. But you also have to lock up the core against violations of the package interfaces and exactly therefore “default” package interface of structure packages can help you.

But at first I have to explain the challenge. Large ABAP development will consist of many ABAP packages in a hierarchy with a structure package at the top. The existence of structure packages is necessary for check mode R3ENTERPRISE (look at transparent table PAKPARAM). With this mode you can properly control dependencies to other structure packages and structure packages of SAP like SAP_ABA or SAP_BASIS f.e.

When introducing the package concept most people will start it in an evolutionary way. Therefore the development classes will be grouped into package hierarchies with structure packages at the top. Because usually there are many dependencies between packages of different structure packages most ABAP architects define so called virtual default and filter interfaces of structure packages. Those interfaces define a “carte blanche” for access unless there are restrictions defined by encapsulated packages. The following diagram makes this point hopefully easier to understand.

Virtual default interfaces are very useful if you start with the package concept. You don’t need to define interfaces in a “bing bang”-style and encapsulate everything and have the choice to encapsulate more and more development packages. The result of this is usually the following: especially older parts of your code will consist of not encapsulated packages. Newly created packages will be usually encapsulated and have proper interfaces.

The challenge is that you need to be able to encapsulate the core without introducing a proper encapsulation of all packages. The latter is often a very costly and an obstacle when building extensions. This is possible in above mentioned scenario. Just create a “standard package interface” of each structure package of the core like it is shown here:

The cool thing is that you can define a package interface of the structure package containing package interfaces, development objects from packages that are not encapsulated, but objects also from encapsulated that are not yet contained in package interface. The latter sounds weird, but it comes very handy if you start encapsulating ABAP core applications to establish a digital core with extensions built on top of it. You can just define a proper standard interfaces and reuse already existing interfaces, but you can also add single elements to them if you should need them. This is shown in the following picture.

So the mechanism of standard interfaces (in former times called default interfaces) allows you to establish quickly interfaces if you want to develop small AddOns like Fiori-apps (especially their OData services) and restrict the access to defined interfaces.

Please be aware of the following. Quickly providing and extending standard interfaces of structure packages for AddOns may leads to confusing and not to well-designed interfaces. So I recommend a governance process and to restructure those interfaces when it comes to a next major release. In my opinion you should not forget that the most important aspects:

  • Existing ABAP applications are a valuable asset and today it has to exposed to new UI and to new channels.
  • Therefore you have to define a proper API. The package concept offers different ways and even the possibility to define ad-hoc interfaces. This is good for software evolution and also ensure that private elements of an existing applications can’t be used.
  • Those ad-hoc interfaces can be established quickly but should be restructured from time to time because a proper “core” needs a proper interface.

Summary

In this blog you learned about the different types of interfaces of structure packages. As one application I mentioned the challenge of modern ABAP development:

  • Sometimes we have existing ABAP code which is often created before using the package concept. New ABAP development should of course be encapsulated and have a proper interface.
  • ABAP package concept offers methods for strong encapsulation but also for dealing with "legacy" code. Especially I explained the different types of interfaces of structure packages.
  • You can use different techniques to define new interfaces if you want to build small AddOns to existing applications. You can even provide fast and pragmatic solutions which are not invasive but keep in mind that in times of multi- and omnichannel you also have to implement a governance process for consolidation of interface definition if it should be necessary.
  • Of course you can avoid all mentioned problems if there are only properly developed ABAP applications consisting of strongly encapsulated packages having a proper interfaces. So my last recommendation is, that you should try to establish high software development standard whenever it is possible. Do not restrict your ATC checks and development guidelines just to modern development and establish guidlines for new interfaces and package interfaces. Keep an eye an standard interfaces of structure packages and if they get confusing spend some time to restructure them according to your interface guidelines.
Labels in this area
Popular Blog Posts