Skip to Content

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.

To report this post you need to login first.

2 Comments

You must be Logged on to comment or reply to a post.

  1. Sudarshan Survepalli

    Hi Yuri,

    Thank you for the detailed explanation.

    In our case, we have multiple DUs owned by multiple teams sharing the same HANA instance. The count is just under 20.

    All of these DUs are assigned to CTS+.

    My team has two of the largest DUs.

    – DU1: Has about 50 Packages

    – DU2: has about 25 Packages

    – Each package has about 20 objects.

    The rest of the DUs are owned by teams such as security and interfaces. There are very very minimal changes for these DUs as of now. There are no changes on the packages associated with these DUs.

    Problem Statement: On a day to day basis for DU1 and DU2, we have about 10 changes released and ready to transport to Quality. There are also a couple of released change IDs that are “never  to be transported” to quality. The pop-up that brings up the changes to transport will take 5 to 10 minutes.

    Possible Resolution?: going by what you have suggested, should I ‘UN-ASSIGN’ all other DUs apart from (DU1 & DU2) from CTS+. Migrate my changes and then assign the DUs back to CTS+ after I am done transporting my changes for the day?

    Regards,

    Sudarshan

    (0) 
    1. Yury Pazhyvilka Post author

      Hello Sudarshan,

      the main problem in your case is the statement “…there are also a couple of released change IDs that are never to be transported” to quality,” This is a scenario where the HALM was not really designed for (I know, in contrast to ABAP world). The idea is that if you have the objects in your DEV systems and the objects are released, they can be (or I would say, even should be) transported to the QA. Mostly the time is spent by analyzing of content of each released change. So, if there is at least one package assigned to a DU (in source system) which was never transported to the target -> all the released (since the CR is ON) changes are to be read and analyzed! And because of number of released changes is increasing, the processing time also increases.  By doing of transport of a complete “DU” (let’s say, once per month or so), HALM would need to read and analyze only changes released for the DU for timeframe of max. 1 month.

      For other DUs which are not actively used for transport, it probably makes sense to “unassign them from CTS+” and “assign back” only when something is to be transported.

      But again, if all (or most) of them were transported (exported) as “complete” DU, it should not take time.

      Best regards,

      Yury Pazhyvilka

      (0) 

Leave a Reply