Skip to Content
Author's profile photo Juri Pazhyvilka

Understanding of native transport of changes in HALM

The basic introduction into the transport of HANA objects I did already: Transport of HANA objects with HALM

Based on my experience with handling of customer messages, I decided to summarize key misunderstandings of using HALM changes-based transport and to provide some technical details which are (still) missing in the official documentation. Hopefully it can help the HALM users to avoid some critical situations in the future.

1. HALM cares about all released objects.

The statement sounds very clear, but in HALM it has a special meaning. Let’s say, you installed a HANA system, created a DU, assigned some created packages to the DU and work on some objects. After some time, you decide to switch the Change Recording in your system on and after that all the object modifications are recorded in a change. The key point here is that all the existing active objects at the moment of Change Recording enabling are released in the so called “base” change. As a result, when the first change of a DU is transported, all the DU objects released in the “base” change are also transported, even if it’s not shown in the list of the transporting changes.


For many users this is not really expected, since the believe that only “manually” recorded and released changes should be transported. But for the consistency reasons it probably would be incorrect just to transport the first manually released change without the objects existed before enabling of the Change Recording.

2. HALM can re-transport already transported changes.

I have seen already many users complaining that HALM re-transports sometimes already transported changes. And it really does, when consistency of DU objects cannot be guaranteed in the target system. Let’s take the example illustrated above:  DUA has 2 assigned packages “aaa.aa.a” and “”. You transport from time to time your released changes and everything looks great because only “not-yet-transported” changes are available for the transport. But one day you notice that many of already transported changes are waiting to be transported again. This can happen for different reasons, but most usual one is reassignment of DU packages. As you know, the transport routes in HALM are defined for specified DUs. But a change can contain objects from packages of different DUs (or even not yet assigned to any DU).


If you assign now the package “” to DUA in the source system, the changes 1, 2 and 3 have to be re-transported again. This is done because the transport archives are DU tgz files including all DU objects for the given time. If only “aaa.aa.a” and “” packages were assigned to the DUA when the changes were transported, it means that only objects of these 2 packages were transported. But after you assigned the “” package to the DUA, the entire changes have to be re-transported. Unfortunately, it is not possible to transport only objects of the “” package with HALM in this case.

Another case when already transported changes are to be re-transported with HALM is when you import a DU archive from a file system into your target system (for whatever reasons).

3. HALM always cares about predecessors.

It is not possible to transport a released change without transporting of existing predecessors. The predecessors are calculated in HALM based on a package level (starting since SP8) or based on a DU level (in SP7). What that means? Very simple:- if an earlier released change contains objects of the same package (package level), the change is considered to be a predecessor. So in the example above, the change 2 is a predecessor of the change 3 and the change 1 is a predecessor of the change 2 (and of change 3). So. it’s not possible to transport change 3 without transporting of change 1 and change 2 (even if the changes contain different objects!).

4. HALM brings objects to the target system.

… even if a transport failed because of activation errors. Yes, it’s true. The HALM executes transports (as well as pure imports) with the special activation mode (=4) resulting that even broken objects are committed. So, you should always be able to find your objects in the target system (either successfully activated or broken).

5. In the Change Recording enabled system HALM always creates a change as a result of a transport (or import).

And automatically releases it (since SP8), even if activation errors happened. That is why probably it makes no sense to enable the Change Recording in a target system.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Former Member
      Former Member

      Thanks Yury .

      Your posts are wonderful.

      I would appreciate if you could also guide me, like you rightly said that using HALM selective changes are not possible however what if it is somehow required to migrate changes without a need to migrate the predecessor.

      Let me explain this way , in our project we have dev,test and prod environment.

      all a up and running , now on day 1 we have migrated few changes from DEV to TEST on which UAT is on and there still no indication to move it to prod. Now after few days, say day 2  some other object from the same packages was required to moved to TEST and to Prod because of some bug fix (different object but due to same package it is reflected in same DU) . This was ok to move to prod , but situation here is without moving the change of day 1 we are not able to proceed with the change of Day 2 . Day 1 objects are not required in Prod but Day 2 to object is required.

      Now with the current behaviour of HALM it is supposedly not possible . What do you suggest we can do , I am looking for an better option or alternative.

      Any suggestion would highly be appreciated.

      Many Thanks in advance

      Author's profile photo Yury Pazhyvilka
      Yury Pazhyvilka
      Blog Post Author

      Hello Ashwini,

      I understand your point, and frankly speaking, you are not the only one with similar requirements. The idea behind was that HALM should avoid any "risky" transports which could potentially lead to inconsistency in a target system. In your case, you transported objects of day 1 into your test system and after some time you would like to transport objects of day 2 (to both systems). But, normally before transporting in PROD the changes have to be tested in a test system. What could happen is that your fix (day 2) somehow depends on changes of day 1; in your TEST system everything works fine, but transport of only objects of day 2 could break the PROD.

      As a (some kind) workaround, you could probably use CTS-managed transports in HALM. In this case you export your changes from a source HANA system and attach them to a transport request (ABAP). As soon as the transport request is released, it's available for import (in the Import Queue) according to your configured TMS landscape. In this case you could import a specified transport request without taking predecessors (as usually in ABAP). But this logic would require more discipline, especially regarding transport request creation/release policy.

      Best regards,