Cloud Transport Management for Steampunk – The Fiv...

julieplummer20

Previously in Cloud Transport Management - 2302

Just over a year ago, it became possible to manage transports in SAP BTP, ABAP Environment (i.e. “Steampunk”) systems using the BTP service, Cloud Transport Management (cTMS).

Harald Stevens wrote an exhaustive, step-by-step blog post, which I found indispensable:

Setting up SAP Cloud Transport Management for SAP BTP ABAP Environment

However, we’ve updated the service, so I thought I would run through the changes here.

Now in Cloud Transport Management - 2405

One limitation was that you could only import one released transport at a time. Now, we’ve developed some improvements:

Import All – to import all transport requests (TRs) in the sequence in which they’re placed in the import queue.
Import Upto – i.e., you select a transport request; this and all previous requests are imported, in sequence, from the import queue.

If you want to know more, check out the SAP Help Portal:

Import Transport Requests | SAP Help

To use these improvements, you need to use a new Communication Scenario, SAP_COM_0948 (instead of the deprecated SAP_COM_0510.) I’ll talk about this below.

How many systems should you set up?

Both the use cases I will discuss here are covered in detail in SAP Help Portal:

We strongly recommend that you set up five systems for any project requiring more than occasional development. In fact, we really don’t recommend a three-system landscape for projects where you need to fix bugs in parallel to ongoing feature development.

In a 3-system landscape, you can of course use git branches to save your work on new features. You could then temporarily use your development (DEV) system as a correction (COR) system – for fixing urgent bugs on the release branch that is currently active in production (PRD).

However, if you had already extended your data model for a new feature, any test data based on the extended model would be lost when switching DEV to the previously released state. The only way to avoid such inconsistencies caused by switching branches would be to deliver fixes directly with the next regular release. If this is not feasible for your project, you need a 5-system landscape.

With five systems, you can set up two codelines:

An “infinity” codeline for developing new features in DEV, where released transports end up as commits on the main branch. Depending on your test strategy, you can either set up a CI pipeline to import new commits in TST for automatic testing with ATC and AUnit; or you could set up a cTMS route transporting exported commits to TST for manual acceptance testing.
A delivery codeline for releasing features and hot fixes, based on release branches R1..n, created whenever new features from infinity should be prepared for production. The cTMS route starts in COR where corrections are developed. Manual acceptance tests are performed in QAS before final release to production (PRD).

Cloud Transport Management (cTMS): Five-system landscape

This graphic shows the systems involved:

DEV = develop features on main branch

TST = Quality Assurance / acceptance testing on main branch

COR = develop corrections on release branch;

QAS = Quality Assurance / acceptance testing on release branch;

PRD = Productive end use

It works like this:

Developers release several transports in DEV, resulting in commits C1, C2, and C3 on branch main.
CI pipeline imports the latest commit C3 (implicitly including all previous commits C1, C2) to TST for automated testing.
CI Pipeline tags C3 after successful testing
(Iterate as required until the Release decision is made.)
When the Release decision is made:
The Release Manager pulls the qualified commit (here: tagged C3) into COR, creates release branch R1 , exports C3 to the cTMS transport route for delivery to PRD.
If required, the developer creates corrections in COR (here: C4)- in parallel to new features being developed in DEV for the next release.
Here: The developer releases transport from COR, resulting in commit C4 on branch R1.
The Release Manager exports commit C4 to cTMS transport Cor1
Cor1 (containing C4) is automatically forwarded to QAS for manual acceptance testing.
After successful testing, Cor1 is manually forwarded to PRD.
Developer performs double maintenance of C4 in DEV, resulting in new commit C5 on branch main from DEV.

The advantage of the five-system landscape is that you keep your feature development route separate from your hot fix route – i.e., you develop to your heart’s content in the infinity codeline. If you need to implement a correction, you can directly do so in COR on the release branch and transport the fix, knowing that there are no new features in the way that may not be ready.

For the COR-QAS-PRD route, we recommend Cloud Transport Management, for controlled delivery and orchestration with other tools, such as Change Request Management (ChaRM) on SAP Solution Manager (SolMan) or Cloud Application Lifecycle Management (CALM). While you could also set up a 2nd cTMS route for DEV-TST, we recommend using the ABAP Environment Pipeline from Project Piper to enable faster automated roundtrips. With a second cTMS route, you would have to manually export commits from DEV for import to TST.

If you want to find out more about CI pipelines for ABAP Environment at SAP, I can recommend this detailed blog post by Daniel Mieg:

SAP BTP, ABAP Environment Pipeline: Introducing AB... - SAP Community

Worried about costs?

Since SAP BTP 2308, you can temporarily “hibernate” / suspend any systems that are not permanently needed – here, TST, COR, QAS, and possibly even DEV, -- thus reducing the operating costs and making a 5-system landscape much more affordable.

That is, you pay for the disk space but not for memory or processing time. You also need to plan for a few minutes spin-up time.

For more details about hibernation, see:

How to set this up

Landscape overview in SAP BTP, ABAP Environment and in the Cloud Transport Management service

Most of the setup has been covered already in Harald’s blog post, so I’m just going to focus on the new parts.

Prerequisites - same

Service Instance for cTMS - same

cTMS versus CI pipeline

Despite the fact that this is a five-system landscape, I’ll focus only on the cTMS route COR-QAS-PRD. As suggested above, I’m going to assume that you are using cTMS for your correction development but a CI pipeline for your “infinity development.” This means I’ll be setting up a transport route for: COR > QAS > PRD. I will not include DEV or TST.

Outbound Communication Arrangement SAP_COM_0599 in ABAP COR

Create the communication arrangement:

Choose New.
Select the scenario SAP_COM_0599, choose an Arrangement Name. Then paste the Service Key from your Cloud Transport Management (cTMS) service instance. This is less error-prone than pasting individual entries. Choose Create.
A communication system is created automatically, with the correct OAuth settings, along with an outbound communication user. Choose Save.
Finally, back in your Communication Arrangement, in Additional Properties > CTMS Node Name, enter a name for the entry node (i.e. development node) in you transport landscape. You will reuse this name when creating transport nodes in cTMS. Also, note that the name will be converted to upper case letters after you’ve entered it.

The new inbound Communication Arrangement, SAP_COM_0948

SAP BTP, ABAP Environment: Inbound Communication Arrangements in QAS and PRD

The process is very similar to the process in Harald’s blog post, but I’ll run through it anyway.

In (one of) your target systems, create a new Communication Arrangement, by choosing New. Here, I am setting up the QAS system.
Select the Communication Scenario SAP_COM_0948:
Then create the communication system: In Common Data, choose New.
Choose a System ID for the communication system (only upper-case letters and underscores are possible). The System Name can be identical. Choose Create.
Now create a communication user:
Scroll down to Users for Inbound Communication, then choose the + icon:
- Choose New User.
- Enter User Name, Description and Password. Store this information in a safe place, because you will need it later to set up the destinations for cTMS. The password must have at least 20 characters, so I used Propose Password.
- Confirm the user by choosing OK.
Save the Communication System.
The data from the Communication System is automatically transferred to the Communication Arrangement.
The Communication Arrangement should look roughly like this. You will use the Manage Software Components API later when creating a destination.
Save inbound communication arrangement
Repeat these steps for your other target systems – in our example, PRD.

The Communication Arrangement should look roughly like this. You will use the Manage Software Components API later when creating a destination.
Save inbound communication arrangement

Destinations for cTMS import into QAS and PRD

You now need to create destinations pointing to your target ABAP instances, using the information from the inbound communication arrangements.

Check connection
Check the Connection. It should return '200: OK'.
Connection check successful

And that’s it. You should now be ready to transport your development objects as Harald describes. And as he said, please feel free to leave your feedback.

For more information, please see SAP Help: