Skip to Content

I hope you already heard about HALM XS application. The HALM stands for HANA Application Lifecycle Management and the application comes with any HANA installation starting since SP6 (auto-content HANA_XS_LM DU). In short, the tool helps you to develop and transport HANA applications. You can manage products, delivery units and packages, but in this blog I would like to describe only transport capabilities and details provided by HALM. Main key transport features were already available in the first version of HALM released with HANA SP6. The HALM SP7 was already able to transport also released objects and with the HALP SP8 you can transport your changes not only between two systems, but also integrate the Change and Transport System (CTS) to transport to multiple systems. Main focus in this blog is transport of HANA repository objects with native HALM. The HALM can be accessible as http(s)://<host:port>/sap/hana/xs/lm


Transport of active objects


Let’s say, you develop your simple XS application. You create a package and in the package you create your repository objects and activate them. For example:

Pic1.jpg

After you checked that your application works, you would like to transport it to another system. To do so, you need to be sure that all the packages where your objects are located are assigned to a Delivery Unit (DU). You create a Delivery Unit and assign the packages you would like to transport to it. Something like: DEMO_DU (demo/aaa).

To transport this application via HALM is pretty easy. I just would like to shortly remind that HALM transports are supposed to be PULL transports. In the target HANA system you create transport routes from one or many source HANA systems. For each transport route you can assign one or many delivery units existing in the source system. They (DUs) don’t have to exist prior in a target. The list of delivery units available for transport is defined by a source system.

Pic2.jpg

So, the first thing to be done for organizing HALM transports is to register in a target system a source system where the delivery units should be transported from. The details how to do that can be found in the official documentation. (Developer Guide, Chapter 12.6). Having a transport route defined, it can be (re-)used for subsequent transports of the assigned Delivery Unit(s). A transport executes 3 main steps: export of the assigned delivery units in the source system, transfer of DU archives to the target system and finally import of the archive objects and activating them. The activation process can fail (for whatever reasons), but in many cases it nevertheless means that the objects are already in the target system. For such cases the transport result code gets a special value (8 – activation errors) and once the problems are fixed (either via another transport or manually), the failed objects can be reactivated.

For transporting of active objects HALM offers currently only one type of transport: “Complete Delivery Unit”. In details it means that for each package assigned to the DU all the active objects are exported into the DU archive (tgz) and importing of this archive in the target system overrides there the DU objects. So for example, transport of the DEMO_DU from a source system into a target system where DEMO_DU already exists (see the picture below will delete demo.aaa.AA.xsjslib object and demo.ccc package with all its content.

Pic3.jpg

One important thing I still would like to mention about HALM transport behavior is transport of dependent delivery units. Let’s say, you defined some privileges in your DEMO_DU (demo.aaa..xsprivileges), but another application (demo.bbb.Tester.hdbrole) referring your privileges belongs to another DU (INTERNAL_DEMO_DU):

DEMO_DU (demo.aaa), INTERNAL_DEMO_DU (demo.bbb)

Pic4.jpg

If the INTERNAL_DEMO_DU is transported first, the activation would fail as the required .xsprivileges object is missing in the target system. Defining two DUs to the same transport route and executing such transport will import both delivery units in a single call, so that objects from both DUs could be successfully activated (even if there cycle object dependencies).


Transport of released objects

Not always transport of all active objects belonging to a delivery unit is a good idea. Very often developers work hard on their objects activating them multiple times until they are really ready for migration. Quite common is a situation when some DU objects are already ready for transport, but some of them still not. This is one of major scenarios where you can benefit from the enabled in the (source) system Change Recording feature. The HALM administrator can enable the Change Recording in HALM to record all the changed objects. More details you can find in the official documentation (Chapter 12.7). Once the Change Recording is enabled, all the object modifications have to be assigned to a change. The objects are locked in an open change until all change contributors approve their modifications and the change is finally released. The new “released” state of an object brings additional flexibility to your transports: – only released objects are exported and finally transported to a target system. The object versions which are still not good enough (not yet released) are not transported. The “All Changelists” type of a transport route from a system with enabled Change Recording will transport all the released DU objects.

Pic5.jpg

Transport of released changes

With transport of released changes you can reach even more flexibility in your transport logic. If the Change Recording is enabled in your source system, you can choose in HALM which released changes you would like to transport. You need to create a transport route of “Selected Changelists” type assigning one or more delivery units. When you initiate transport for such route, the HALM finds all the released for the specified delivery units, but not yet transported changes.

Pic6.jpg

In the list you can see the released changes with information about which delivery units are affected by a change and when a change was released. You can also see object details for each change.

When you select one or more changes, the HALM calculates all their predecessors. The predecessors in context of HALM are changes released earlier than the selected changes and containing objects from the same packages. For example, having 3 released changes like below:

Pic7.jpg

and choosing the Change 3 for transport, finds Change 1 as predecessor because it contains objects from the same package (demo.bbb). In HALM you have only possibility to transport the selected changes together with their predecessors. As soon as the changes are successfully transported (without activation errors), the HALM stores information about which change was transported as the last one for each package. Once transported changes will not be longer presented in the list of available for transport changes.

Here I also would like to mention one detail which is very important. When the Change Recording is activated in a system, all the active objects in the system becomes part of so called “base” change which is released automatically. The base change is initially always a predecessor of any released changes (per DU) visible in the HALM wizard, even if it’s not shown there. Other words, if your DU contains already 100 objects at the time when you enable Change Recording, all the 100 objects are “released” with the “base” change. If you after that modify an object, assign it to a change, release the change and finally transport it, all the 100 objects released with a “base” changes will be transported together (as predecessor). In the ideal case you start developing of you DU objects after Change Recording is already activated.

References

[1] SAP HANA Application Lifecycle Management in the HANA Developer Guide:http://help.sap.com/hana/SAP_HANA_Developer_Guide_en.pdf (Chapter 12);

[2] Change and Transport System: http://scn.sap.com/docs/DOC-7643

To report this post you need to login first.

15 Comments

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

    1. Yury Pazhyvilka Post author

      Hello Jonu Joy,

      as soon as a role is a design-time object, you can easily assign its package to a DU.

      For eaxample, one of our (HALM) roles looks like:

      role sap.hana.xs.lm.roles::Developer extends role sap.hana.xs.lm.roles::Display, sap.hana.uis.db::SITE_USER

      {

      system privilege: REPO.MODIFY_OWN_CONTRIBUTION;

      application privilege: “sap.hana.xs.lm::Developer”;

      application privilege: “sap.hana.xs.lm.hanaCockpit::WidgetAccess:developerCatalog”;

      }

      and is located in the sap.hana.xs.lm.roles packages.

      Best regards,

      Yury

      (0) 
  1. Vidann R

    Thanks Yury Pazhyvilka. , Very Good Info.

    Have a few Queries as I am new to ALM.

    We have a native hana development and would like to go for HALM for transport.

    1. Is DU  same as transport request in ABAP world?

    2. Suppose I create a delivery Unit DU_1 in my Dev system , assign packages and transport it via the transport route to the target QA system.

    Assume my DU_1 had demo.aaa and demo.bbb objects in it.

    Now, I have some more changes in my Dev systems only to the object demo.aaa

    Would i assign it again to the same delivery unit DU_1 via change recording and transport it to the target QA system or should i create a different delivery unit again!

    Also, I have read in blogs that transporting the same delivery unit would over write the objects in the target system!

    Thanks in advance,

    Regards,

    Vidy

    (0) 
    1. Harald Stevens

      Hi Vidy,

      a DU is more comparable to a package / development class in ABAP. It has the additional function of grouping objects which will be transported / delivered together. If you look for an analogy for an ABAP transport request it would be a change list in HANA.

      The assignment of packages to delivery units is normally quite static and would rarely be changed later on. So in your example you create the initial version of objects demo.aaa and demo.bbb in the package pack1 which in turn is assigned to DU_1. If you now perform a HANA native transport from Dev to QA all these artifacts (Objects, package, DU) are created in the target system.

      If you now change object demo.aaa in the dev system and transport DU_1 again the complete content of all packages assigned to DU_1 is imported again into the target system overwriting the existing objects. In your case package pack1 with objects demo.aaa and demo.bbb.

      If you would like to transport with finer granularity (only changed objects) you would have to use change lists (see documentation, chapter 6). However, for the transport from QA to Prod we still recommend transporting DUs (or using the CTS+ integration of HANA transports)

      Kind regards

      Harald

      (0) 
      1. Vidann R

        Thank you Harald.

        To re-iterate, in order to transport minor changes we can use changelists

        Suppose Change recording is enabled in My system then,

        Steps:

        1. I create a delivery Unit DU_1 and assign the packages demo.aaa and demo.bbb.

        2. In the transport route i select my Delivery Unit and select the changelists to be transported.

        and then transport.

        3. Now if i have changes in my Package demo.aaa, i create a new changelist.

        4. I again select the same delivery unit in the transport route and select the changelist to be transported. Now only changes in Package demo.aaa are transported.

        so My target system has updated Package demo.aaa and old demo.bbb.

        Please correct me if I am wrong.

        Best Regards,

        Vidy

        (0) 
        1. Harald Stevens

          Hi Vidy,

          in principle I would agree, however, change lists work on object level, not on package level. So if you have five calculation views inside your package demo.aaa and you change only that view leaving the other four untouched only this changed view inside the package demo.aaa is transported and deployed to the target system.

          I will try to make this hierarchy clearer with a picture

          DU            package            object        change list

          DU_1

                           demo.aaa

                                                   view1         view1

                                                   view2

                                                   role1

                           demo.bbb

                                                   view3

                                                   role2           role2

                                              

          So now you can transport either on DU level meaning everything below DU_1 irrespective if it has been changed or not.

          Or if you use change lists you would assign the objects you change to a change list (e.g. view1 and role2) and only these objects would be transported (leaving the rest untouched).

          We recommend only to put objects from one DU into the one change list.

          Kind regards

          Harald

          (0) 
        2. Yury Pazhyvilka Post author

          Hello Vidy,

          your expectations for the described scenario are completely correct.

          As Harald mentioned, we recommend to put objects of only one DU into a change list.

          But packages can be also unassigned (for the time when transport is executed).

          So if your first change contains modified objects of “demo.aaa”, “demo.bbb” and “demo.ccc” and only “demo.aaa” and “demo.bbb” are assigned to the DU, so only the modified objects of these 2 packages are transported. The complexity comes if some time later, you probably decide to assign the “demo.ccc” package also to the DU. After that the already transported change will be available for the transport again and all modified objects of all 3 packages will be transported (overwriting the same objects in the target system).

          Best regards,

          Yury

          (0) 
  2. Frank Siebert

    Hi Yury,

    we use HANA Native Transport in the HCP with activated change tracking, transporting small changes from dev to test.
    The documentation explains that in this configuration any activation error in the target system leads to a roll-back, and I was not able to find any information how to trouble shoot this situation.

    Now I’m exactly in this situation. The next transport package in the queue does raise an activation error, the rollback takes action and no option left to do anything about it, like e.g. active it without the activation of dependent objects.

    Do you have any trouble shooting information you could share?

    Thank you,
    Best regards,

    Frank

    (0) 
  3. Vinod Gujja
    Hi Yury Pazhyvilka,

    as you mentioned here “HALM you have only possibility to transport the selected changes together with their predecessors”, is it still valid with SPS12 as well ?

    If more than one change id is captured in same delivery unit, is it mandatory to move all the change id’s in that delivery unit or we can move only the required change id ? lets say developer 1 changed view1 and developer 2 changed view 2 , each view captured in a seperate change id but associated to same delivery unit. Now i just want to move only view 2 but not view 1. is that possible, can you please let me know where i would select the required change id for this ?

     

    thanks!

     

    (0) 
  4. Yury Pazhyvilka Post author

    Hi Vinod Gujja,

    the predecessors are calculated based on packages. So, if your views are in different packages (but both packages still belong to the same DU), you can anyway transport them separately.

    Best regards,

    Yury

    (0) 

Leave a Reply