SAP Cloud Transport Management System Setup for Transporting SAP Build Work zone Objects

[Loganand__Sivabalan]

Overview :

The Cloud Transport Management System (cTMS) in SAP Business Technology Platform (BTP) automates software changes across different cloud environments. This tool streamlines the process of moving changes from development to testing and production environments, making it valuable for SAP customers using cloud-based development practices.

Overview of Setting Up Cloud Transport Management for SAP Build Work Zone:

SAP Build Work Zone (formerly known as SAP Launchpad service) creates personalized, role-based entry points for accessing SAP and non-SAP applications. When implementing Cloud Transport Management (cTMS) for SAP Build Work Zone, you can efficiently manage content transport—including roles, catalogs, and apps—across development, test, and production environments.

Example Transport Structure Scenario :

In this Blog, I have taken a setup of 2 tier landscape of Transport management for SAP Build Work zone Standard edition existing in Subaccounts that belong to different global accounts.

Implementation Steps for Cloud Transport Management with SAP Build Work Zone

• Set Up SAP Build Work Zone Instances:
• Subscribe to Cloud Transport Management Service (cTMS)
• Configure Destinations
• Create Transport Nodes in cTMS
• Define Transport Route:
• Prepare and Transport Content
• Import Transport Request
• Limitations and Key Considerations

1. Set Up SAP Build Work Zone Instances

   In both the Development (DEV) and Production (PRD) subaccounts, subscribe to and create instances of the SAP Build Work Zone, standard edition. For a three-tier landscape, include Quality Assurance (QA) as well.

   

   Generate service keys for the SAP Build Work Zone instances in both DEV and PRD environments.

   

   Perform the same above steps in the PRD subaccount as welll.

2. Subscribe to Cloud Transport Management Service (cTMS)

   In the source subaccount (typically DEV), subscribe to the SAP Cloud Transport Management Service.

   Create an instance and generate a service key for the cTMSThe above step is applicable only for the source subaccount as cTMS is setup in one subaccount

3. Configure Destinations

   Set up a destination for the Cloud Transport Management Service in both the DEV and PRD subaccounts.

   Copy the service key details of the cTMS instance and create a destination named ctms_destination in both the DEV and PRD subaccounts respectively with the below config.
   
   

   Name ctms_destination

   Type	HTTP
   Description	Destination to Cloud Transport Management
   URL	uri from the service key of cTMS
   Proxy Type	Internet
   Authentication	OAuth2ClientCredentials
   Client ID	Copy Client ID from the service key of the cTMS
   Client Secret	Copy Client Secret from the service key of the cTMS
   Token Service URL	copy from the service key and append /oauth/token to the URL
   Additional Property
   node-name	DEV

   For PRD, Just change the Additional Property node-name to PRD
   
   

   The check connection test will return the below message and you’re good to go!
   
   In the subaccount where cTMS is hosted (DEV in this case), create destinations for both the source (DEV) and target (PRD) SAP Build Work Zone applications.

    Navigate to the destinations page in the cTMS subaccount and create the destinations for DEV and PRD workzone with the below config.
   
   

   Name DEV

   Type	HTTP
   Description	Destination to Workzone Application DEV
   URL	Portal service URL from service key of workzone and append /cdm_import_service
   Proxy Type	Internet
   Authentication	OAuth2ClientCredentials
   Client ID	Copy Client ID from the service key of workzone
   Client Secret	Copy Client Secret from the service key of workzone
   Token Service URL	uaa-url from the service key

   Create another destination for PRD Application with the same details from the service key of PRD

   The connection check will return the following message
   
   

   

4. Create Transport Nodes in cTMS:

   In the cTMS application, create two transport nodes—one for the DEV Work Zone application and another for the PRD Work Zone application.

   Navigate to the Cloud Transport Management Application and Create two nodes for DEV and PRD.

   Under Transport Nodes, Click on + and create nodes with the below settings. The name of the nodes must be same as that of what maintained in node-name property of the cTMS_destination 
   
   

   

5. Define Transport Route

   Establish a transport route from the DEV node to the PRD node to enable the movement of content between the two environments.

   Navigate to the Cloud Transport Management Application and Create Transport route DEV — PRD

   Under Transport Routes tab, Click + to create a transport route.
   
   

   Under Landscape Visualization you can see your nodes and transport routes of them

6. Prepare and Transport Content

   In the DEV Work Zone application, create a sample site, along with associated roles and groups.

   I have created a test application in the DEV Workzone application with an Application, Group and Role each assigned to the site.

   
   
   To Transport a site along with all it’s assigned contents, you can transport the whole site using by selecting the Transport Site option under more options on the site directory.
   
   Once you click on Transport Site, the site will be pushed as transport request to the cTMS system.

   To Transport objects individually you can select the objects in the content manager and click on the Transport Icon.
   
   

   

7. Import Transport Request

   In the PRD environment, access the import queue of cTMS and import the transport request to deploy the content.

   Navigate to the Landscape visualization Tab in the cTMS application and you can see the initial/Repeatable object count changed to 1 in the PRD queue.
   
   

   
   
   Go to the import queue of PRD by selecting the node and clicking on Go to this node’s import queue.In the import queue you can see the Request waiting to be imported. Select the request and click in import selected to import it into PRD.
   
   
   
   Approve the Import Request and proceed to start import.
   
   You can see the import logs in the Transport Action Logs tab. You can see the import status there.
   
   Now you can see the site transported with all it’s contents to the PRD workzone.
   
   

8. Limitations and Key Considerations

   • Supported and Unsupported Objects:

     • Supported Objects:
       • Sites, pages, and content (e.g., widgets, apps, and catalogs).
       • Roles and groups.
       • Custom themes and layouts.
     • Unsupported Objects:
       • User-specific personalization or customizations.
       • Some dynamic content or configurations tied to specific environments.
       • Certain administrative settings or system-level configurations.

   • Environment-Specific Configurations:

     • Some configurations (e.g., URLs, API endpoints, or destination settings) may be environment-specific and need to be adjusted manually after transport.
     • Hardcoded references to environment-specific details will not work in the target system without modification.

   • Manual Adjustments in Target System:

     • After transporting objects, you may need to manually adjust certain settings in the target system (e.g., reassigning roles or updating app URLs, as some application URLs of DEV and other systems may differ).
     • This is especially true for integrations with external systems or custom configurations.

   • Data Loss Risks:

     • If the target system already has content with the same names or IDs as the transported objects, there is a risk of overwriting or losing data. Always review and resolve conflicts during the import process.

   • Transport of Large Objects:

     • Transporting large sites or complex content structures may result in performance issues or timeouts during the export or import process.
     • Break down large transports into smaller, manageable chunks if necessary.

   • Content Federation/ Content Manager

     If you’re using content federation for content from backend systems, the content provider/ package name must be identical in all the tiers.