Technology Blogs by SAP
Learn how to extend and personalize SAP applications. Follow the SAP technology blog for insights into SAP BTP, ABAP, SAP Analytics Cloud, SAP HANA, and more.
cancel
Showing results for 
Search instead for 
Did you mean: 

The basics of HALM changes transport is pretty good described in the Understanding of native transport of changes in HALM blog. After the Change Recording is enabled in a HANA source system, users can transport Hana change objects (from a source system to a target system) either with native HALM tool or via CTS+. As mentioned in the other blog, HALM always tries to keep consistence in the source and target systems in its transport logic. When the number of Delivery Units and released changes to be transported is small enough, it works fine. But with increasing number of Delivery Units assigned to a transport route (or to CTS+) and increasing number of released changes, the performance of calculation of changes available for transport can slow down significantly. Here I would like to show what exactly influence HALM performance, so that you could optimize your transports.

As you know, HANA objects are located in packages and packages are normally assigned to Delivery Units. When HANA objects are modified (in the CR-enabled system), the modified objects are recorded in a change. As soon as the modified objects are ready for transport, the change contributors approve their modifications and the change is released. The HALM considers such released change as a candidate for transport and after the transport is successfully done, the HALM stores information about DU packages transported with the change. So, if the DU_A consists of 3 packages: "aaa", "bbb" and "ccc" and the released (and transported) change contains objects of all packages (let's say, object A, object B and object C), the HALM stores the information about transported DU packages in the form: { source_system, DU, package, transported_change } In this case:

SRC   DU_A   aaa   change1(released 01.01.2016 at 00:00:00)

SRC   DU_A   bbb   change1(released 01.01.2016 at 00:00:00)

SRC   DU_A   ccc   change1(released 01.01.2016 at 00:00:00)

To find out the released changes available for transport (and analyze them), next time the HALM will ask repository in the source system about changes released only after 01.01.2016 00.00.00. It's an ideal case. You can imagine that the change1 could contain only objects of packages “aaa” and “bbb”. In this case, the information about the transported “ccc” package would be missing in the target system and the HALM would have to ask about the released DU changes starting since the very beginning (when the CR was switched ON). That is for sure not a problem if the CR was enabled not too long time ago. But if meantime hundreds (or even thousands) of DU changes was released, the HALM would need to analyze all of them. And that is a time consuming operation. That is why it could be a good reason to transport from time to time a complete DU (released objects). In this case, HALM would store for all DU packages the timestamp of last successful transport.

Unfortunately, a change transported with HALM doesn’t really mean that it will never be transported again. As you know, a DU can be restructured pretty easy in the source system: packages can be assigned and/or unassigned, which is a bad practice. But the changes are transported based on Delivery Units assigned to a transport route (or to CTS+). So, when a change is transported, in reality only objects belonging to the Delivery Units defined in a transport route/CTS+ are transported. And if some time later new packages are assigned to a Delivery Unit in the source system, the change and many (and it could be really a lot of) already transported changes have to be re-transported again.

All the described information is also related to the CTS+ transport scenario. Here unfortunately there is no such flexibility to group Delivery Units as in the native HANA scenario where you could assign one or many Delivery Units for a transport route. In the CTS+ case you simply define Delivery Units to be transported via CTS+ and it could be a really long list. From the performance point of view, you can imagine that one thing is to analyze changes for a couple of Delivery Units and completely another thing to do the same for 20, 50 or more. Here the HALM still could be improved by providing a way to initiate transport only for selected subset of all assigned to CTS+ control Delivery Units. Please, keep it in mind, that the same strategy of transporting from time to time of the “complete DUs” could be applied here to improve performance.

2 Comments