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:
Use Case 1: One Codeline in a 3-System Landscape | SAP Help PortalUse Case 2: One Development and Correction Codeline in a 5-System Landscape | 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 Cor1Cor1 (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:
Manage System Hibernation | SAP Help PortalSAP BTP ABAP Environment – Manage System Hibernati… – SAP CommunityOptimize Your SAP BTP ABAP Environment Budget: A D… – SAP Community
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 connectionCheck 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:
Creating Destinations for Deployment of References of SAP BTP, ABAP Environment | SAP Help PortalSetting Up and Working with Your Landscape | SAP Help PortalSetting Up and Working with Your Landscape: Important Notes | SAP Help Portal
Previously in Cloud Transport Management – 2302Just 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 EnvironmentHowever, we’ve updated the service, so I thought I would run through the changes here.Now in Cloud Transport Management – 2405One 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 HelpTo 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:Use Case 1: One Codeline in a 3-System Landscape | SAP Help PortalUse Case 2: One Development and Correction Codeline in a 5-System Landscape | 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 landscapeThis graphic shows the systems involved:DEV = develop features on main branchTST = Quality Assurance / acceptance testing on main branchCOR = develop corrections on release branch; QAS = Quality Assurance / acceptance testing on release branch; PRD = Productive end useIt 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 Cor1Cor1 (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 CommunityWorried 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:Manage System Hibernation | SAP Help PortalSAP BTP ABAP Environment – Manage System Hibernati… – SAP CommunityOptimize Your SAP BTP ABAP Environment Budget: A D… – SAP CommunityHow to set this up Landscape overview in SAP BTP, ABAP Environment and in the Cloud Transport Management serviceMost of the setup has been covered already in Harald’s blog post, so I’m just going to focus on the new parts.Prerequisites – sameService Instance for cTMS – samecTMS versus CI pipelineDespite 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 CORCreate 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_0948SAP 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 arrangementRepeat 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 arrangementDestinations for cTMS import into QAS and PRDYou now need to create destinations pointing to your target ABAP instances, using the information from the inbound communication arrangements.Check connectionCheck 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:Creating Destinations for Deployment of References of SAP BTP, ABAP Environment | SAP Help PortalSetting Up and Working with Your Landscape | SAP Help PortalSetting Up and Working with Your Landscape: Important Notes | SAP Help Portal Read More Technology Blogs by SAP articles
#SAP
#SAPTechnologyblog
