Part 6: Transport approaches in SAP CP

[JakobMoellers]

This is part 6 of my blog series about cloud architecture on SAP Cloud Platform. You can find the overview page here.

In this blog, we will look at different transport scenarios in SAP CP. You will learn about the different approaches and hopefully, after reading this blog, be able to decide which approach fits your needs. I will mention different approaches and order them by degree of automation, as automation and speed, in my opinion, are the key figures for state-of-the-art transport and release tools.

The following overview will serve as an indicator for the different methods and their feasibility for the various application stacks we have in SAP CP. I will then discuss each option for the different stacks. As you know, SAP CP (NEO) features Java, HTML5, and XS Engine as application stacks. You can create Multi Target Applications (MTAs) combining and organizing those stacks. In addition, I will cover the Portal Service as the need for transporting the configurations of this service are pretty common. For the colors, green indicates that I would recommend the approach. Yellow indicates feasible approaches with some restrictions and red means that something is not possible or does not make sense. The approaches are also ordered by degree of automation, the arrow indicates the increasing degree of the approaches (manual being the lowest, CI/CD the highest).



Options for Java

• Manual Import/Export or Console Client: The developer (or team-lead) can manually deploy the app from the IDE (Eclipse) to different subaccounts. One could also use maven and/or the console client for the release-build and the deployment process. This way, the task of "transporting" (better: deploying the app to another stage) could also be structured more. For example, only the project lead or an administrator could have the permission to start a console client deployment script to deploy an application to the production account. Such scripts could conduct the repository sync with git, the build-phase with maven, and the deployment with the console client. As you have already guessed, this approach cannot really be considered "proper transporting", as it is almost completely missing the auditing and permission capabilities and functions of a real transport management system.


• SolMan/CTS+: This is one of two proper ways to transport Java applications with SAP CP. As a prerequisite, you will need SolMan 7.2 SP 03. You will have to create a "Solution" (MTA) from your Java application (check the official documentation) and can then add the exported Solution to your SolMan CTS+ Transport Request. Attention: SolMan cannot export the application from the source, it can only transport & deploy it to the target. So attaching the exported Solution to the transport request still has to be conducted manually. There is a nice blog and also a part in the official documentation explaining the details. With SolMan, you then also have the possibility of using ChaRM to manage your change requests, for example, defining approvals for transports to production.


• CI/CD: For those of you who are familiar with DevOps and Continuous Integration and Delivery processes, this approach will suit your needs. The idea is that you use CI/CD tools, for example, Jenkins, Gerrit, and Nexus, to conduct automated build and deployment processes. There is a great blog series by my colleagues explaining the various options in detail. You could, for example, use Jenkins to build a new version of your software once the developers merge on the master branch of your git repository. Then, this build could automatically be deployed to the next stage by using the deploy-commands from the console client in a script that is triggered by your CI/CD tools. With this approach, you can achieve complete automation of your build and transport processes. However, it is up to you to decide whether you also want to transport changes to production stages automatically or whether you still want a manual interaction by not linking the delivery script with the build process (so only have a continuous integration process for the production but not a continuous delivery).

For transporting and deploying Java applications, there are several methods available for hot deployment and rolling-updates to, for example, support zero-downtime scenarios. Check the documentation for details.

Options for HANA XS

• Manual Import/Export: You can use HANA Studio or Eclipse to push changes (e.g. encapsulated in Delivery Units (DUs)) from one stage to another. Same as for Java applications, I would not consider this "proper transporting"…


• HALM: The "HANA Application Lifecycle Management" is also available on the HANA instances within SAP CP. HALM can be used to create transport routes between two HANA systems and then transport DUs between those systems. Access rights can be given to only selected users whereas permission concepts will not be as fine grained as in, for example, ChaRM. For the technical connection between the two HANA systems, a xshttpdestination is used.


• SolMan/CTS+: You can use the Solution Manager to transport HANA Delivery Units with CTS+. This is also possible for the Cloud Platform, you will have to make sure that your solution manager can reach the SAP CP. Detailed information can, for example, be found here. If you already use CTS+ for your on-premise HANA systems, I recommend you use similar methods in your cloud environments as well.


• CI/CD: You can include your HANA artifacts into your CI/CD processes as well. For scripts, I recommend you use a combination of hdbalm and hdbsql to transport artifacts between systems. For this, you will need a service channel in your SAP Cloud Connector to connect to the database via ODBC/JDBC. Once you have the service channel, you can use hdbalm and hdbsql within your pipeline to import DUs or execute other necessary commands within the integration or deployment processes.

Notice: Both the CTS+ or the CI/CD approach offer the combined transport of artifacts from multiple stacks in parallel. Let's assume you have an application that consists of a Java component and a XS backend. With those approaches, you can combine the transport of those artifacts despite the fact that they are technically separated. This becomes especially relevant if you have a hybrid environment: Let's assume you have some logic in an on-premise backend system and some frontend app in SAP CP: With SolMan, you can combine those artifacts in one transport request so that you do not have to care about the dependencies while transporting and always have a consistent state at all times.

Options for HTML5

• Manual Import/Export: You can manually export and import a HTML5 application in the Cloud Cockpit. As I would not regard this as "proper transporting", I will not elaborate on this any further…


• Git-Sync: A more convenient approach than the manual import/export is a synchronization of the git repositories. You can build scripts that transfer certain commits from the git repository of the source subaccount to the git repository of the target subaccount. This way, you can transport the application's code from one stage to another while have a guarantee (from git's SHA1 hashes) that the source code is identical in source and target subaccount. After the synchronization, you still have to create a new version of the application in the cockpit manually, so this form of transporting cannot be automated completely. Still, I would argue it's more elegant than the manual import/export approach.


• SolMan/CTS+: Same as for Java. You will need to create a solution (recommended anyways) and then you can transport your HTML5 application the same way as your Java application.


• CI/CD: Similar to Java applications. You can use CI/CD tools to automatically build (if necessary at all) and deploy your application.

Options for MTA

• Console Client: You can deploy Solutions (MTA) via the Console Client. So as soon as you have your .mtar-file containing the Solution, you can deploy this file to the target system via the Console Client ("deploy-mta" command). Similar as for the Java applications, this cannot really be called transporting but by assigning proper member roles and encapsulating the console client in a usable script, you can achieve at least some level of controlled release mechanism.


• SolMan/CTS+: As mentioned before, having MTAs is a prerequisite for using SolMan and CTS+ for transporting applications (excluding HANA XS).


• CI/CD: Having MTAs is also a good use case for CI/CD processes because the MTA build process (packing the .mtar-file) can be part of the CI/CD build process. You could use Maven to automatically build new MTAs once a commit to the master-branch of your repository is conducted by a developer. Then, the software could be tested by your test frameworks and automatically be deployed to a QA subaccount for user acceptance tests. Check the referenced best practices blogs for process and pipeline suggestions.

Options for Portal Service

• Manual: At this point in time, the only way to transport portal settings and configurations is via a manual import/export. You can however select which components and settings you want to transport, so you will not have to change all the configurations on the target tenant each time you transport. But still, it is still a manual process. Check the configuration for details.


• Git-Sync/Console Client: This is not really applicable, however, if you have certain UI5/HTML5 components in your portal sites (e.g. shell plugins), those can be transported the same way as also HTML5 applications. This is why I indicated that there is some automation possible for those components, but this does not affect the overall portal site configuration of course.

I hope this overview helps you in evaluating which kinds of transport approaches are feasible for your SAP Cloud Platform scenarios. Let me know if you have questions or need additional clarifications! Which scenarios do you think are most useful?

For further reading, I can also highly recommend my colleague Harald's blog about setting up CTS+ transport landscapes with SAP CP.

See you in the next blog! Cheers,

Jakob