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 “bbb.bb.b”. 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 “ccc.cc.c” 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 “bbb.bb.b” 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 “ccc.cc.c” package to the DUA, the entire changes have to be re-transported. Unfortunately, it is not possible to transport only objects of the “ccc.cc.c” 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.