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:
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.
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. (SAP HANA Application Lifecycle Management). 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, transfhttp://help.sap.com/hana/SAP_HANA_Developer_Guide_en.pdfer 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.
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)
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. 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.
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.
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:
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: http://help.sap.com/hana/SAP_HANA_Developer_Guide_en.pdf
[2] Change and Transport System: http://scn.sap.com/docs/DOC-7643
- SAP Managed Tags:
17 Comments
