Skip to Content
Technical Articles

SAP CPI – Transport Individual IFLOW Using Custom IFLOW

In this Blog let’s discuss how we can transport individual iflow from source to target tenants using custom iflow by name “SAP_CPI_Transports”

Use Case:-

 

If you do not have CTS+ configured or TMS service is not enabled or manual upload and download of iflow is not allowed due to audit restrictions, in this cases you can use this custom iflow which fulfill most of the transport requirements

We will be using Standard API’s in custom iflow to transport .You can find the standard API’s from below URL

https://api.sap.com/api/IntegrationContent/resource

 

 

My requirement:-

As we did not have CTS+ or TMS service and no manual upload/download due to audit. I have to Use custom iflow to transport any individual iflow and deploy the iflow only if manager approved deployment else only upload the iflow to target tenant and configure as needed and keep it ready and deploy when manager approved and have emails saved for audit purpose

 

Prerequisites:-

 

  1. If you are transporting a new iflow for the first time using a new package, as there is no standard API to transport package, we need to ask CPI Admin to manually create the new package in target tenant with the same name as source tenant package name, if package already exists in target tenant, you are good to go
  2. Configure all the external parameters as shown and discussed below
  3. Configure email credential name in mail adapter with your choice of new or existing name

 

Points To Know:-

 

  1. You have to deploy this iflow “SAP_CPI_Transports” each time you want to transport an individual iflow as timer set to “Run Once”
  2. You will receive an email about the transport status for most of the below shown scenarios, you can stop by setting external parameter “enable_Send_Emails” to false
  3. You enable and disable logging through attachment by setting parameter “enable_Payload_Logging” to true or false
  4. You have started developing a custom iflow from version 1.0.0 and finished the development at version 1.0.5, in this case you don’t have to transport all versions to targets tenant, only the active version 1.0.5 which you want to transport will be transported to target tenant and I don’t as see any point in transporting all versions as you will never revert to old version directly in target system, you will have to revert the version in source tenant and then transport again to maintain all systems in sync and as best practice
  5. Very Important – If you are deleting any external parameter which is no longer needed as part of update to an actual main iflow example “Order_Create” make sure after updating iflow you must use the option “Remove Unused” to remove all unwanted external parameters

 

 

You can download the custom iflow from below link and upload to your CPI tenant and once you configure all external parameters you can deploy, I recommend to do a POC with test iflow with and with out external parameters

 

https://drive.google.com/open?id=1FTWa4YCX3QW1Zgc_0Q-t2mPMS0fw3B2Q

 

 

 

Lets discuss about external parameters you need to configure mandatorily in iflow

you have to update values in all the parameters with the relevant data however 3 important parameters are high lightened below in red

 

External Parameters:-

 

 

  1. Iflow_ID_To_Transport —> Actual Iflow ID which you want to transport to target tenant, make sure you always select iflow ID and not Iflow Name. Only the selected ID will be transported to target tenant

 

2. Manager_Approved_Deployment —> This parameter is needed to make sure we have manager approval to deploy the iflow automatically in target tenant, if manager did not approve and you set the parameter to false, still it will transport the iflow when you run it but it will only upload and not deploy the iflow, you can configure the external parameters in target tenant iflow and keep the it ready and deploy manually once you have the manager approval or as needed

 

3. Update_External_Parameters_Before_Deploy_In_Target_System —>This parameter is needed to make sure if external parameters needs to be updated in target system with new values. If you set to “true” that means you need to update the parameter values manually in target system using standard web gui portal, if set to “false” iflow is deployed directly as you have already set manager approved to true

 

4) For Parameters “Source_TenantID” and “Target_TenantID

You can use Source tenant as DEV and target tenant as QA

You can use Source tenant as QA and target tenant as PRD

You can use Source tenant as DEV and target tenant as PRD

Note: If you want to take a back up of PRD existing Iflow, you can also set source tenant as PRD and target as either DEV or QA, in this case make sure you set manager approved as “false” as you do not want to deploy and just take a back up of iflow to a package

 

Lets test and talk about scenarios

Scenario 1

 

You developed a new iflow by name example “Order_Create” in source tenant and this new iflow does not have any external parameters, count of source tenant external parameters = 0 then set the below values in iflow “SAP_CPI_Transports”

  1. Iflow_ID_To_Transport —> “Order_Create”
  2. Manager_Approved_Deployment —> “true”
  3. Update_External_Parameters_Before_Deploy_In_Target_System —> “false”

 

Scenario 2

 

You developed a new iflow by name example “Order_Create” in source tenant and this new iflow have few external parameters, count of source tenant external parameters > 0. For now you do not want to change the external parameters values in target tenant and maintain same values as of source tenant and may be you want to change values in target tenant later in future using standard web gui, set the below values in iflow “SAP_CPI_Transports”

  1. Iflow_ID_To_Transport —> “Order_Create”
  2. Manager_Approved_Deployment —> “true”
  3. Update_External_Parameters_Before_Deploy_In_Target_System —> “false”

Scenario 3

 

You have an existing iflow by name example “Order_Create” in both source tenant and target tenant and you want to update some mapping or some iflow process steps and transport the iflow from source tenant, however you want to retain same existing values of external parameters in target system as this is only a map change or process step change, set the below values in iflow “SAP_CPI_Transports”

  1. Iflow_ID_To_Transport —> “Order_Create”
  2. Manager_Approved_Deployment —> “true”
  3. Update_External_Parameters_Before_Deploy_In_Target_System —> “false”

this transport iflow will take back up of target system external values, delete iflow only from design time not runtime, upload the iflow, restore the external parameter values which are backedup and then deploy

 

Scenario 4

 

You have an existing iflow by name example “Order_Create” in both source tenant and target tenant and you want to update some mapping or some iflow process steps and transport the iflow from source tenant, however you want to maintain a new values of external parameters in target system, set the below values in iflow “SAP_CPI_Transports”

  1. Iflow_ID_To_Transport —> “Order_Create”
  2. Manager_Approved_Deployment —> “true”
  3. Update_External_Parameters_Before_Deploy_In_Target_System —> “true”

this transport iflow will take back up of target system existing external parameter values, delete iflow only from design time, upload the iflow, restore the external parameter values which are backedup

When you set No 3 parameter to true, iflow is uploaded to target tenant but not deployed, you can update the external parameter as needed and deploy using standard web gui

 

you can try multiple scenarios change the external parameters values

 

Note:- in any case manager approved deployment is set to false it will just upload the iflow and will not deply the iflow, so that you keep it ready with all configuration in target system , you can deploy it as needed or when approved

I used more process calls to explain the different processes better, its not recommended to use unwanted process call at least in synchronous real time iflows

I Used lengthy names for parameters for your better understanding

If you get any error which is not expected, you can fix the issue and redeploy the iflow

I recommend create a new test iflow and do a poc for all scenarios to understand the overall process and then use actual iflows to transports

 

 

 

 

Be the first to leave a comment
You must be Logged on to comment or reply to a post.