Configuring a Multi-Node Landscape with the Cloud Transport Management Service

Explanation

Once the rationale for transport management is understood, the next step is configuring an actual landscape. The Cloud Transport Management service is provisioned as a subscription in a BTP subaccount, typically in a dedicated subaccount used for operations rather than in each development subaccount, so it can serve as a shared transport backbone across your landscape. After subscribing, you define a transport landscape consisting of nodes. Each node typically maps to a target environment - for example a DEV node, a TEST node, and a PROD node - and each node is configured with an import queue that holds content awaiting import. Nodes are connected by transport routes, which express the promotion path (DEV to TEST, TEST to PROD). A route can be a direct route, moving content straight from source to target, or in some configurations content is uploaded once and then forwarded along the chain. Configuration of nodes and routes is typically done through the Cloud Transport Management service's own web UI or via its REST API, and each node is associated with credentials and content type restrictions so that, for example, a node dedicated to MTA archives will reject an unsupported file type. The typical workflow for promoting an MTA-based application (for example a Cloud Foundry app with a Node.js or Java module) is: the developer builds and packages the application locally or in a CI/CD pipeline using the MTA build tool, producing an .mtar file. This archive is then uploaded to the import queue of the first node (often representing the entry point into the managed landscape, sometimes still called DEV or the transport node closest to the build) using the Cloud Transport Management UI, the transport management client library integrated into a CI/CD pipeline, or direct API calls with an authenticated service key. Once uploaded, the artifact appears in that node's import queue with a status of open. An authorized transport administrator (or an automated pipeline step, depending on the organization's automation maturity) triggers the import. Cloud Transport Management then forwards the archive along the configured route or directly deploys it to the target environment via its integration with Cloud Foundry, based on how the node is configured. For Integration Suite content (integration flows, value mappings, message mapping artifacts), a similar principle applies but the content is packaged as an integration content archive rather than an MTA archive, and importing typically triggers deployment of the flows into the target tenant's Integration Suite runtime, subject to the target tenant's design and deploy permissions. A critical configuration decision is how to handle environment-specific values during this flow. Rather than hardcoding backend URLs or credentials inside the artifact, well-designed content externalizes these as parameters - for Integration Suite this often means using externalized parameters on adapters, and for Cloud Foundry apps this often means environment variables or bound service instances that differ per space. Cloud Transport Management itself moves the artifact, but it does not automatically rewrite embedded literal values, so parameterization must be designed into the content before it enters the transport process, not fixed afterward. Troubleshooting at this stage typically revolves around import failures: a node rejecting an artifact due to unsupported content type, missing target-space bindings for Cloud Foundry deployment, insufficient authorizations on the service key used for the API call, or a locked import queue due to a prior failed import that needs manual resolution before new imports proceed. Reviewing the import log for the specific node, checking the target environment's own deployment logs (Cloud Foundry app logs, or the Integration Suite deployment status), and verifying that the destination and identity provider configuration in the target subaccount match what the content expects are the standard diagnostic steps. Because Cloud Transport Management transports the packaged content but does not manage the target subaccount's underlying entitlements or service instances, many failures actually originate in the target environment not being fully provisioned to receive the content, rather than in the transport mechanism itself.

Code example

# Example CI/CD pipeline steps for MTA-based transport via Cloud Transport Management # 1. Build the MTA archive from the source projectmbt build -t ./mta_archives # 2. Authenticate and obtain an access token for the Transport Management service#    using a previously created service key (client id/secret)export TMS_TOKEN=$(curl -s -X POST "$TMS_UAA_URL/oauth/token" \  -u "$TMS_CLIENT_ID:$TMS_CLIENT_SECRET" \  -d "grant_type=client_credentials" | jq -r .access_token) # 3. Upload the MTA archive to the entry node's import queuecurl -X POST "$TMS_API_URL/v2/nodes/$ENTRY_NODE_ID/transportRequests" \  -H "Authorization: Bearer $TMS_TOKEN" \  -F "file=@./mta_archives/my-app_1.0.0.mtar" # 4. Trigger import of the uploaded transport request into the target nodecurl -X POST "$TMS_API_URL/v2/nodes/$TARGET_NODE_ID/transportRequests/$TRANSPORT_REQUEST_ID/import" \  -H "Authorization: Bearer $TMS_TOKEN" # 5. Poll import status until it reports SUCCESS or FAILED, then fail the pipeline on FAILEDcurl -s "$TMS_API_URL/v2/nodes/$TARGET_NODE_ID/transportRequests/$TRANSPORT_REQUEST_ID" \  -H "Authorization: Bearer $TMS_TOKEN" | jq .status

Real project scenario

An integration team automates promotion of both Cloud Foundry microservices and Integration Suite flows using a Jenkins pipeline. The pipeline builds the MTA archive, uploads it to the Cloud Transport Management entry node, and waits for approval from a change manager recorded in the import queue before triggering the import into PROD. During one release, the import fails because the PROD subaccount's destination for the SAP S/4HANA backend was never created, revealing that the target environment provisioning checklist had been skipped for that release, not a defect in the transport service itself.

Common mistakes

• Hardcoding backend URLs or credentials inside integration flows or app configuration instead of externalizing them as parameters before transport. • Assuming Cloud Transport Management provisions target subaccount entitlements, destinations, or service instances automatically; it only transports the packaged artifact. • Not monitoring the import queue, leading to a backlog of open transport requests and confusion about what is actually running in each environment. • Granting broad transport administrator rights to all developers instead of restricting import-to-PROD rights to a controlled group. • Ignoring failed import logs and retrying blindly instead of diagnosing whether the failure is in the transport step or in the target environment's readiness.

Best practices

• Externalize all environment-specific values (URLs, credentials, IDs) as parameters or bound service instances rather than embedding them literally in transported content. • Restrict import rights into PROD nodes to a small, auditable group, separate from those who can upload into entry nodes. • Integrate transport uploads and imports into CI/CD pipelines with automated status polling rather than relying on manual UI clicks for routine promotions. • Maintain a target-environment readiness checklist (entitlements, destinations, service instances) that is verified before the first import into a new node. • Regularly review and clear the import queue, keeping historical transport request logs for audit purposes rather than deleting them prematurely.

Interview angle

Candidates are often asked to describe the end-to-end flow of promoting an MTA archive or integration package through a BTP landscape, and to explain how environment-specific configuration is handled without hardcoding values. Interviewers also probe understanding of the separation of concerns between the transport mechanism moving artifacts and the target subaccount needing to be independently provisioned with the right entitlements and destinations.