Unerasable Empty Development Packages on an SAP ERP System

#abapGit#HANA Transport#SCTS_HTA#ABAP Transport Layer#HANA Development Perspective#ABAP Development Perspective

Introduction of abapGit in Project

In our customer project the abapGit tool was introduced. This open-source tool enables the transfer of SAP back-end resources with the help of an ABAP transaction (usually ZABAPGIT) into a Git repository. The associated possibility for feature-based tracking of changes created an analog to the existing procedure for front-end code.

Comparing front-end and back-end there are fundamental differences in the organization of the code. For front-end code, a repository actually consists of a directory tree with which every developer works independently. The back-end, on the other hand, is a huge pot. All objects can access each other. (For this reason, SAP dreams of providing every developer with a repository that consists of a copy of the complete system. Only then a back-end developer can work as independently from their colleagues as a front-end developer.) Since this vague future has not yet begun, smaller criteria must be used to group development objects into repositories.

abapGit regards a single package as one repository. If the package contains subpackages, these are synchronized as well. However, there is a strict package name check in the hierarchy. The name of a subpackage must begin with the name of the parent package. As a result, the names are becoming more and more specific, analogous to the ever more specific development objects within the packages. (You can avoid this strict check. But this is not recommended. Instead, you should clean up your package names.)

Strict Naming Convention becomes important

In the project's packages the naming convention was respected with a few exceptions. The introduction of abapGit forced the elimination of these exceptions. That meant creating new packages with the correct names, moving the objects from the old packages to the new ones and then deleting the old packages.

In the course of the move towards the new package names supposedly empty packages with old names were discovered.

Empty Package with Inappropriate Name detected!

If you expanded one of these packages, you could see that unlike "normal" packages it obviously didn't contain any development object.

Who needed empty packages? Nobody! So: delete them all!

But then:

Package can't be deleted. What next?

The package obviously wasn't empty. If a package can be deleted it must no longer contain any objects. But how should we delete objects that we couldn't see? And what kind of objects were they? Might we not be able to delete the package at all?

We could find the answer to this question by inspecting the contents of the TADIR system table, the directory for all transportable repository objects in the system. We looked for the package name in that database table. In previous SAP releases packages were known under the name "development class". The package name must therefore be entered in the selection screen of transaction SE16

in the DEVCLASS field. The following hits were displayed:

The entry with the "DEVC" object always stands for the package itself, which is also transportable in addition to the objects it contains.

What does Object Type HOTA mean?

Pressing the input help in the OBJECT field of the selection screen and filtering according to HOTA resulted in:

So the other objects denoted HANA objects. The object names were HANA packages which, together with the development objects they contained, were only visible in the HANA Development Perspective of the ABAP Development Tools in Eclipse. They were not visible in the ABAP Development Perspective.

Linking HANA Package to ABAP Package

In order to transport HANA objects from one system in the landscape to another system these objects have to be transferred into an ABAP package that is connected to the ABAP Transport Layer in SAP CTS (Correction and Transport System). This is done on the package level. A HANA package is synchronized with transaction SCTS_HTA into a transportable ABAP package. When we entered one of the package names from table TADIR in that transaction,

we could also see the objects contained in the package:

If you press the Execute button at the top left, you can specify an (existing) ABAP package to include the HANA objects for transport purposes. Warning: You will never see that package again in this transaction! In any case, we couldn't find a way to display it again later in the transaction itself. Only querying table TADIR did the job. We had to put in the HANA package name as the object name to get to know the ABAP package. If you know better please let us know!