Skip to Content
Technical Articles

Setting up SAP Cloud Platform Transport Management for SAP Cloud Platform Integration


In this blog I will describe how to setup SAP Cloud Platform Transport Management (TMS) for SAP Cloud Platform Integration (CPI) running in the Neo environment. I will concentrate on the points which seem to be a little more challenging and refer to the documentation for the rest.


  • (At least) two SAP Cloud Platform Integration tenants (development/source and production/target) running in two SAP Cloud Platform Neo subaccounts.
  • The service ‘Solutions Lifecycle Management’ is enabled in all Neo subaccounts being part of the transport landscape.
  • Setup SAP Cloud Platform Transport Management as described in the SAP documentation. This includes:
    – Buy TMS
    – Entitle a Cloud Foundry Subaccount for TMS
    – Subscribe to TMS
    – Create role collections and assign them to users
    – Create a TMS service instance and a service key


There are three different types of destinations needed to setup the CPI / TMS scenario. Please see the picture below:

  1. Destination pointing from the Solutions Lifecycle Management Service in the Neo subaccount hosting the CPI source tenant to the service instance of TMS. The name of the source node is provided as a parameter in this destination.
    Please follow the instructions in SAP help to configure this destination.
    Take note that the name of this destination has to be ‘TransportManagementService‘ (case senitive!)
  2. Destinations pointing to the target Neo subaccounts hosting the CPI tenants: these are configured in the destination service of the Cloud Foundry subaccount hosting TMS as described in the SAP documentation.
    The names of these destinations can be freely chosen.
    You have to create one destination for every Neo subaccount respectively CPI tenant you would like to deploy to.
    These destination are then used to configure the transport nodes in TMS.
  3. Destination pointing from the Solutions Lifecycle Management Service to the CPI tenant running in the same Neo subaccount.
    The configuration of this destination is described here in the SAP documentation.
    It has to have the fixed name ‘CloudIntegration‘ (case-sensitive).
    A more generic format of the destination’s URL is
    ‘https://<CPI tenant name>-tmn.hci.<data center>’
    The destination shown in the documentation would refer to an SAP internal account in Canada (‘int/cn1’).
    This destination has to be created in all subaccounts which are part of the TMS landscape (source and targets).The easiest way to retrieve the URL containing the CPI tenant name is to go to the SAP Cloud Platform cockpit of the Neo subaccount hosting the CPI tenant. Open the ‘Applications’ tab and the ‘Subscriptions’ subtab. In the list of ‘Subscribed Java Applications’ click on the one which name contains ‘tmn’. This opens a list of ‘Application URLs’ where you can copy the one which ends with ‘itspaces’.

Users, Roles and Identity Providers

Destination to Neo subaccount

The technical user(s) used in the destinations pointing to the target Neo subaccounts (type 2 above) has to be a member of the subaccount and needs to have the role Developer (or Administrator) in the corresponding subaccount. This role can be assigned when adding the user as a member to the subaccount. Alternatively you can assign a custom platform role with the scopes Manage Multi-Target Applications and Read Multi-Target Applications.

If you are using SAP Cloud Identity Authentication Service (IAS) as your platform identity provider the user should be a local user in the IAS tenant and cannot be a user integrated from another Identity Provider. The reason for this is the lack of industry standards for propagating basic authentication requests.

Destination to SAP Cloud Platform Integration tenant

The technical user for the destination pointing to the CPI tenants (type 3 above) needs to have the roles AuthGroup.IntegrationDeveloper and IntegrationContent.Transport. How to assign these roles is described here in the SAP documentation.

If you are using SAP Cloud Identity Authentication Service (IAS) as your application identity provider please take note that ‘Basic Authentication’ for this destination by default points to the SAP Identity Service and does not use SAP IAS. However, this is technically possible and can be changed via a ticket to the security operations team (BC-NEO-SEC-IAM). After the configuration is done also the basic authentication will be done against the SAP IAS tenant used as application identity provider.

As above the user should be a local user in the IAS tenant and cannot be a user integrated from another Identity Provider.

Administrator role for enabling TMS as transport tool in CPI

The administrators who should be able to change the transport mode used for CPI additionally need the role AuthGroup.Administrator. 

Enabling TMS transports for CPI

Once you have configured all the destinations above and the corresponding transport landscape in TMS, you have to switch the transport mode of CPI to actually use TMS. That switch is somewhat hidden…

In the CPI web client you have to select the ‘Settings’ tab, then the ‘Transport’ tab and then press the ‘Edit’ button in the lower right corner (which can be far away on a large screen).

This enables the drop down list where you can select ‘Transport Management Service’. Don’t forget to save…

Using TMS from within CPI

Once you have configured and activated TMS for CPI as described above you can use it to create transport from within the CPI development environment.

For that, switch to the ‘Design’ tab in the CPI development tenant and select the CPI package you would like to transport:

You can now perform your changes to the package and save them. You initiate the TMS transport by pressing the ‘Transport’ button:

Provide some information of the transport and press the ‘Transport’ button:

Now a new transport request is created in TMS, the CPI package is put into a Multitarget Application (MTA) archive file and attached to the transport request. The transport request is then released and put into the queue of the transport node which follows the development node (in this example the test node). The confirmation message tells you into the queue of which node the transport has been placed.

In the Transport Management service UI, you will find the new transport in the queue of the node specified in the success message above. From this queue you can trigger the import into the target CPI tenant.

This concludes this blog about the configuration and usage of SAP Cloud Platform Transport Management for SAP Cloud Platform Integration. Have fun using this scenario!


You must be Logged on to comment or reply to a post.
  • Hello Harald

    Another great blog for SCP TMS.

    We have SCP TMS working in a technical capacity to transport CPI content between Neo subtenants.

    We are hitting an issue in "So.lution Lifecycle Management" that reports an error "Integration Content Missing" after package deployment to CPI, however in SCP TMS and  the CPI system no error is reported and the CPI package is working as expected ( though it did need to be deployed manually )

    Is there any advice in how this can be troubleshooted / where logs may exist please?


    Many thanks


  • HI Harald Stevens

    We have recently subscribed to SAP CPIS ( cloud foundry ) integration service and need to setup the TMS on top of it to transport the content between various CPIS tenants( on cloud foundry).


    Can you suggest, similar to above blog if you can guide us on below

    Setting up SAP Cloud Platform Transport Management for SAP Cloud Platform Integration"Suite" on Cloud Foundry


    Shobhit Taggar

  • HI Harald,


    Thanks for sharing the blog. I have one more question on the Subaccount for TMS Service.


    Scenario: We have 2 CF Subaccounts(QA and PRD) in Singapore Azure region and as per SAP TMS service is available in this region

    Q1: Can we use existing CF subaccounts to activate the TMS service

    Q2. If Above is yes, then which subaccount to use to activate this service,  (QA or Prd)

    Q3:  Service will be activated in 1 tenant or all tenants in the landscape

    Q4: If We wish to apply new Subaccount for this service, Will it be in Singapore OR US(E) / Frankfurt. I find in SAP documentation somewhere that TMS subaccounts need to be created in only US(e) and Frankfurt region. Kindly suggest on this.



    • Hi Shobhit,


      let me try to answer your questions:

      Q1: as TMS is available on the Azure data center in Singapore you can use the existing CF subaccounts

      Q2: in the subaccount you use for TMS you have to configure the role collections for TMS and assign them to the users who should be operating TMS. You also configure the destinations to all target subaccounts in this subaccounts. Besides that you will need for full TMS functionality a space inside the subaccount in which you create one service instance of TMS (you can reuse an existing space for that if it has free service instance quota).
      Based on this information it might be easier for you to decide which subaccount will be better suited. Technically for TMS there is no difference.
      My gut feeling would prefer the QA subaccount to clearly separate the productive applications from operative tasks like TMS:

      Q3: You need to activate (subscribe to) TMS in only one subaccount.

      Q4: If I understand your question correctly you are thinking about creating a new subaccount for TMS. You can use any data center (region) in which TMS is available. That would include Singapore. If (most of) your target subaccounts would be in Singapore as well it could create some (slight) performance benefits to have TMS in the same data center due to reduced network latency.
      Could you please point me to the place in the documentation which calls for US or Frankfurt only, so that we can correct this outdated information.

      Thanks a lot.

      Kind regards


      • Hi Harald,


        Thanks for your response.

        1. I read your blog Where you mentioned about "Boundary condition" it is mentioned US & Frankfurt.
        2. In tenant Setup "Step 1 video" The Trainer mentioned about US and Frankfurt only.

        Aside I raised the same questions to SAP Support BC-CP-LCM-TMS support group and I just got a response from the team. All replies are same as you said above except Q3.

        As per your response above you mentioned we need to Activate ( subscribe) TMS in only 1 sub account. Where as SAP support in ticket no 759320/2020 responded it should be activated in all Subaccounts, those part of TMS landscape

        NOW kindly guide further on this.


        • Hi Shobhit,

          thanks a lot for pointing me to the blog post. I have corrected it accordingly.

          As for the video in the SAP Help Portal, we are planning to rerecord them because some of the UIs have changed. However, this will take a few more weeks.

          Concerning the question of how many subaccounts need a subscription to TMS my information is correct. The complete transport landscape is managed from one subaccount which is the only one with the TMS subscription.

          However, there might be a confusion with the Solutions Lifecycle Management service in the Neo environment. This has to be enabled in all subaccounts involved in TMS transports. It is available by default and free of (extra) cost but has to be enabled once.


          Solutions Lifecycle Management service in the Neo environment

          Kind regards

  • Hi Harald,


    With reference to SHobhit's Query (above), I have one more question on the Subaccount for TMS Service.

    As above,I have created a new subaccount for TMS. Now, I am trying to create destinations by using client service key from TMS account to QA.

    1) Am I doing the right approach? How should I create destinations from (new TMS subaccount or CPI DEV)  to CPI QA?

    2) I tried with “CPI QA service instance and service key” and “Basic authentication which I have admin access in QA” ,   Both authentications are failing (connection established but 401 authorization error) please help.

  • Thanks, Harald Stevens.


    Now, I can able to create Nodes. Quick question, Initially, i have done Transport path from DEV to QA. All was working well.


    But now, I am trying to add PROD node. Please advise me what other configurations have to do from QA to PROD?

    1. Do we need to create TargetDestination in QA?
    2. Do i need to activate settings " TransportManagement" service in QA?
    3. any other?
    • Hi Vasudeva,

      great to hear that the authorizations issue has been solved.

      The complete configuration for TMS happens in TMS itself or in the subaccount from which you have subscribed to TMS. For adding a PROD node you would have to:

      • Create a destination pointing to the PROD target in the subaccount from which you have subscribed to TMS. It should be the same place where you defined the destination pointing to QA.
      • In TMS create a new node for PROD using this new destination
      • Create a new transport route connecting QA and PROD node

      Please also have a look at the chapter on landscape setup here:

      Kind regards


  • HI Harald,

    Thank you for your quick reply.

    I have done the following steps. ( as shown above).


    Quick help needed,

      1. Do I need to activate TransportManagementService in QA?a
        • .Getting error when check Configuration as "Destination lookup failed"
      2. There is no TRANSPORT link at iflows to export. 


  • Harald Stevens

    Thank you for the introduction! We have everything in place and working fine. I was wondering if there's a setting that transported artifacts get deployed automatically? It's a little annoying to deploy each iFlow individual after transporting it.

    Thank you


    • Hi Christopher,

      I am glad to hear that you liked the blog post and could use it successfully.

      Currently there is no configuration setting to directly start an import/deployment after a new transport request has been added to the queue of a node.

      One option would be to use the scheduling function of TMS (upper right corner of the screen when you are looking on the queue). This would automatically trigger an import of the complete queue. The minimum interval that can be currently configured is one hour, so that in worst case you would have to wait one hour until the CPI package is imported. This could be a valid option for your test environment, but I would rather not recommend it for a productive tenant.

      Another option would be the usage of our APIs for TMS (see ). One of them can trigger an import of a single transport and another the import of a complete queue. Some customers use that approach in their development scenarios in conjunction with a CI/CD pipeline to trigger the import after the transport request has been created by the CI server. However, this approach does not fit so well to the CPI use case because triggering the import would still be a separate (manual) step.

      Kind regards