Introducing APACK – A Package and Dependency Manager for ABAP

Do you all remember the Special Snowflake Award which was granted to ABAP last year – and that the following discussion even caught Hasso Plattner’s attention? Well, many things have happened in the meantime, releasing the SAP Cloud Platform ABAP Environment may just be the most prominent one. And you know it: Together with that release, SAP also embraced the import of ABAP sources using abapGit. Seems like a small and logical step for a development environment, but it was actually a giant leap for the ABAP community. But – of course – it’s not the end of the (hi)story.

Challenges in the Cloud

When it comes to the actual development of ABAP-based solutions in the Cloud, developers still need to tackle certain challenges:

• They need to get familiar with a new, restricted ABAP language version
• They are only allowed to use/call development objects which are part of a whitelist
• There is no package and dependency management solution which makes it easy to re-use existing libraries or solutions for own developments. Dependencies need to be declared manually via README files or related documentation – no automated re-use possible

The new language version is certainly the lowest entry barrier – overall, it comprises all concepts which have anyway already been widely accepted as state-of-the-art ABAP coding. However, while the situation improved from release to release with respect to the whitelist and its supported objects, it may still lack crucial components which are desperately needed in a modern development environment.

The good news is: If you compare the situation to other widely used programming languages, ABAP has become a much less special snowflake because of that. The core functionality of the built-in features and APIs are usually limited in any environment. High-level functionality is usually shipped in dedicated re-use packages or libraries. Dependencies to such third-party components are usually orchestrated using special tools like Maven or npm. And that’s the bad news about it: Such a tool has been missing for the SAP Cloud Platform ABAP Environment so far. People were forced to reference dependencies in READMEs of their abapGit projects and forced people to manually import all packages manually one-by-one.

Let’s welcome APACK!

With release 1905 of the SAP Cloud Platform ABAP Environment we are introducing APACK – a package and dependency manager to solve exactly this problem. With APACK, you can specify a unique identifier for your abapGit package – so that it becomes eligible for re-use and componentization. The declaration follows the Project Object Model (POM) which is widely known from Apache Maven. An APACK package is therefore identified by

• group ID (e.g. sap.com)
• artifact ID (e.g. apack)
• version (e.g. 0.1)

Consequently, it’s completely independent of any ABAP backend-specific package and package interface definitions. But why is this? Well, especially with abapGit, you are free to choose the local package name(s) for the imported development objects. So, any direct declarations of package (interface) names may be completely meaningless on other systems. Moreover, you need a globally unique identifier including a version to be able to orchestrate dependencies between components from different vendors correctly. So far, everything was pretty much system-focused. We have had namespaces, but – of course – they may also be different from system to system.

But the APACK descriptor does – of course – not stop at the sole declaration of the package itself. You can declare dependencies to other packages which are automatically taken into account at import time. So far, dependencies are version-independent. In other words, the most recent version of all dependencies are imported, but this will probably change in the future. Therefore, please be sure to declare your packages according to the Semantic Versioning standard already now (we come to that later in this text again).

How does it work?

You might now say: All theory is grey, dear SAP, but how does it really work? And you are right! In order to illustrate the capabilities of APACK, we prepared two sample projects which are already using the new infrastructure and can be used right away in your ABAP instance in the Cloud. Please have a look at the JSON ABAP Konverter (JAK) GitHub page. This tiny little library provides a convenient JSON to ABAP (and back) conversion API and is dependent on another library called the YY Data Service. If you now link the JAK repository with your ABAP instance (and have an up-to-date abapGit ADT plugin), you’ll notice a new page in the link repository wizard which asks you to provide local packages for all dependencies:

After finishing the wizard, you will see that both packages (JAK and YY) have been added to the list in the abapGit repositories view. If you checked the “Pull after Link” option in the wizard, the import of both project has already been triggered as in this example here:

If you haven’t checked the “Pull after Link” option, you need to pull the code for the sample projects manually after linking. In this case, open the context menu of the package associated to the JAK repository and select “Pull”. Simply go though the wizard and ensure that the “Pull all dependent repositories” option remains checked (it’s the default setting). After the completion of the wizard, both JAK and YY will be imported.

As usual, abapGit imports are done inactively. So please ensure to activate all imported objects after the imports have completed successfully.

About APACK Manifests and their Declaration

So much about the practical implications of the new APACK infrastructure, but how does it work behind the curtain? Well, it’s pretty easy. Each project needs to include a class which implements the marker interface IF_APACK_MANIFEST and declare the respective metadata by populating the attribute DESCRIPTOR during class instantiation. Below you find the implementation for the JSON ABAP Konverter (JAK).

When a project is exported using abapGit, this implementation class is called and the APACK descriptor file .apack-manifest.xml automatically serialized. The final result looks like that and is – of course – also available in the public GitHub repository.

Use APACK in own projects

If you want to use APACK in own projects for the SAP Cloud Platform ABAP Environment, simply follow the tutorial “Use abapGit to Transform ABAP Source Code to the Cloud“. Exporting projects from an ABAP instance in the Cloud is unfortunately not yet supported.

The newest version of abapGit already includes APACK serialization support. Please note that you need to implement the interface ZIF_APACK_MANIFEST if you export using the official abapGit version. Additional details – including how to use versions – are available in the abapGit documentation.

tl;dr – ABAP Package Management made easy and convenient

To make a long story short: SAP embraces Cloud and open-source development – also for ABAP! With APACK, ABAP gets an automated package and dependency management for re-use libraries and applications tailored for the needs in the Cloud. It is directly integrated in the existing abapGit components, is easy-to-use and creates almost no overhead to the developer!

With our sample libraries JSON ABAP Konverter (JAK) and YY Data Service you can already start playing with the infrastructure and learn the basic concepts. If you want to use APACK in your own projects, you can also get started right now.

Of course, the functionality in release 1905 is just the beginning. As always the usual disclaimer: No promises made about future developments, but the framework could for example easily be extended to support central and local (company-specific) repositories other than Git – similar to Maven for example. In addition, versioned dependencies or the deserialization/import support for APACK projects for on-premise systems are also possible.

Finally, everything depends on you! If you are a developer of one of the many public ABAP projects and want to make it APACK-ready, just get started! If you are just interested in the topic and in fostering the ABAP ecosystem, please give feedback, suggestions, comments etc. either directly below this blog post or via e-mail to sebastian.wolf@sap.com. Looking forward to discussing things with you!