SAP Cloud Platform Integration Co-Deployment in SAP Process Orchestration

This is the first blog post of a series where I want to describe in a real world scenario how to build an integration content and deploy it on SAP Process Orchestration (SAP PO) for execution. In Alexander Bundschuh’s blog post from Jan 2018 you find an overview of how it works and what options you have for a co-deployment. (see https://blogs.sap.com/2018/01/18/best-practices-cloud-integration-content-in-sap-process-orchestration-deployment-enhancements/ )

In this blog post I want to show how to co-deploy a scenario where I call a SAP backend service in SAP ECC via SOAP. Usually you would do it via a RFC connection. But the Profile SAP PO 7.50 SP10 doesn’t support a RFC channel for a SAP backend. So first question then would be, how to convert an existing RFC into a (SOAP) WebService?

Oh, you might ask: But SAP PO has since a couple of years a RFC adapter, so why can’t I use an RFC adapter in my co-deployed scenario? Yes, SAP PO has a RFC adapter, but we are not deploying to SAP PO, but in SAP PO integrated SAP CPI runtime. (SAP CPI = SAP Cloud Platform Integration). So the question is, if the included SAP CPI runtime has the capabilities you find in the cloud based SAP CPI runtime.

Even I don’t describe it in detail you would use transaction SOAMANAGER in your backend system and configure how the RFC/BAPI is wrapped in a SOAP service.

Before you do that you would go in transaction SE37 (Function Builder) to your BAPI, and under “Utilities”-> “more Utilities”-> “create WebService” you can convert any BAPI into a WebService. In my case I use a custom BAPI, ZBAPI_PO_CREATE,

Now to our co-deployment scenario: I’ve created an integration package in SAP Cloud Platform Integration (SAP CPI) with name “CPI_To_PI_Migration” with different artifacts. One artifact is the integration flow “Create Purchase Order – Deployable in SAP PO 7.5 SP10” and another is “Create Purchase Order – Deployed in CPI”

I simply created a copy of the second one, so no changes were done from an iFlow that runs in a SAP CPI (cloud) runtime. I just gave it another name. So let’s see how to deploy it to a SAP PO runtime.

Figure 1:

First let’s have a look what the iFlow does.

As you can see in the next screen we receive an HTTP request from a sender and SAP CPI sends the request to the SAP backend via SOAP message.

Figure 2:

The SOAP call calls the BAPI. The BAPI creates a response, in our case the generated purchase orderID in the backend. This we will see later once we test our co-deployed scenario.

Further we want to deploy this integration scenario designed in SAP CPI to a SAP PO 7.50 SP10 system. So first question is where can I configure to which SAP PO system version this integration flow (iFlow) should be deployed to? And a second question: Can I use all functions I have in the (always) most current SAP CPI release, also in my SAP PO backend version?
Usually there is a time gap of a half year to year at SAP customer side, where the SAP PO release is behind the SAP CPI release, as SAP CPI is updated every 4 weeks, but Service packages (SP’s) in SAP PO are released only one or two per year and customer might decide to not go as soon as possible to the latest SAP PO release, as this causes a migration project with test effort. (see for details: https://help.sap.com/viewer/368c481cd6954bdfa5d0435479fd4eaf/Cloud/en-US/5a4ff04ed13b40828a86766fff9ec639.html)

If you click on any space outside the iFlow itself and then on “Runtime Configuration” you see, you can select the so called product profile.

Figure 3:

The copy from which I stared had “SAP Cloud Platform Integration” as product profile. So I change it to the SAP PO release into which I want to deploy the iFlow. In my case: “SAP Process Orchestration 7.5 SP10”. In SAP PO 7.5 SP10 exists no RFC connection, (see next screen shot) therefore we use SOAP instead, to send the incoming Purchase Orders to the SAP ECC backend system.

Figure 4:

If you would change the product profile to the latest version (as of writing this blog post it’s SAP PO SP16) we wouldn’t also see a RFC Adapter type. That’s why we call the SAP backend not via RFC adapter, rather with a SOAP connection.

In general there is a mapping and possibly other manipulation of an incoming message, before it’s send to a receiver. But here we send the http request exactly in the format the SOAP call expects, so in this simple case we don’t have any processing steps in SAP CPI.

As our iFlow now has a product profile of “SAP Process Orchestration…” you can’t deploy it any longer to SAP CPI Cloud-runtime.

The deploy button is still there, but if you click it you’ll get an error.

Figure 5:

So next step is to deploy it to SAP PO.

For that you have to logon to your SAP PO environment and go to “Cloud Integration Content”

Figure 6:

As you can see in the Cloud Integration Content Management Cockpit, you get an overview of the Integration Content coming from the connected SAP CPI tenant.

Figure 7:

So a natural question arise: Where do I configure from which SAP CPI tenant you want to import the iFlows?

And a second question might come up: What if I have external parameters in my iFlow in SAP CPI, for example the credential name of the user who connects to the SAP backend system? These credential names must be also know in SAP PO, as now SAP PO sends the Purchase Order for processing to the SAP backend system.

Let’s start with answering the second question: The following screen shot shows that we have a parameter “credential name” in the SOAP connection from (now) SAP PO to SAP backend.

Figure 8:

So if you come back to the Cloud Integratin Content Management Cockpit you deploy the credential manually in SAP PO in the “Security Artifact” tab. Click on the “Deploy” button, select the Artifact Type “User Credentials”

Figure 9:

and in the following screen …

Figure 10:

… you define the artifact Type “User Credentials”. Enter the name, here the same name you used in the iFlow (ec3_800_ibs_rfc), which refers to an existing user in the SAP backend, here the user ibs_rfc (which is a technical user) who has the authorization to create purchase orders in the backend. Finally you enter the users password, confirm and save it.

So now everything is ready to deploy the iFlow defined in SAP CPI to SAP PO. For that come back to the “Integration Content” overview screen and click the “Deploy” button.

Figure 11:

As you can see there are 3 options. They allow you to configure from which SAP CPI tenant you want to deploy the content to SAP PO runtime.

The first option is to configure a Cloud Tenant via Destination. Like SAP Cloud Platform, SAP PO also provides a generic mechanism to connect to external systems via the concept of a destination. I used a configured destination “HCID0207”. This is eventually a HTTP based destination. The second option is to provide the Cloud Tenant via its URL, plus user and password to the tenant. And the last option is to export in SAP CPI the content and upload it via File System. Here you would go in the SAP CPI tenant to your package, and click the “download” under “Actions” function (see next screen shot).

Figure 12:

The download automatically starts and a zip-file is generated with the name of the selected iFlow.

The destination which I use for connection to my SAP CPI tenant is defined in SAP PO NetWeaver Administrator (nwa). You find the entry to nwa in the start page of your SAP PO.

Figure 13:

Click on “Configuration”

Figure 14:

and then on “Destination” and you’ll end up in the configuration of the SAP PO destinations.

Here you create your destinations. You need to provide a System ID (HCID0207), the Destinaton Type, here type HTTP, the URL to your tenants management node (tms), here https://xxx-tmn.hci.eu1.hana.ondemand.com plus the logon data for your SAP CPI tenant.

Figure 15:

The most convenient way is of course using a destination, as once you have configured the many destinations you might have, you can just use the drop down box in the Cloud Integration Content Management Cockpit and select the SAP CPI tenant for which you want to deploy the artifacts in your SAP PO system.

So once you have selected your SAP CPI tenant and click on “Next” your SAP PO system connects to the SAP CPI tenants and gives you the list of all artifacts in your tenant. You’ll see only saved iFlows from your tenant. Now search your SAP CPI package and the iFlow(s) you want to deploy and start the deployment to SAP PO through the “Deploy” button.

Figure 16:

What about versioning? What if I have several versions of my iFlow in SAP CPI and would deploy a specific one? If you create a version of your iFlow in SAP CPI, you see in the list above only the latest version in SAP CPI (more precisely the current version in SAP CPI). If you want to revert to an older version in SAP PO you would have to go back to an older version in SAP CPI and make it the “current version”.

In the next screen shot you see where you do it in SAP CPI.
If you click on the version link in the overview of your artifacts in SAP CPI

Figure 17:

you see the different versions of your iFlow. I have three versions of it.

By selecting which one becomes the current one, you would revert the version, and in the SAP CPI list this new current version would be displayed. As you can see version 1.0.2 is the current one, and therefore I see in the screenshot above this version as deployable version.

Figure 18:

This is another argument to make SAP CPI your preferred tool for design time, even you have SAP PO as your runtime. SAP CPI would be the leading system where you design your process integration scenarios. Here you configure which one is your current version and this version can be deployed to SAP PO. As you might sooner or later anyway migrate all SAP PO integration scenarios to SAP CPI, you would now do all the development already in SAP CPI, even they might still deployed to SAP PO, but if you then later want to migrate them to SAP CPI runtime, you just do a deployment to SAP CPI and no longer to SAP PO. For those scenarios where SAP CPI is your desgin time environment you won’t have to do anything but deploying them later to SAP CPI. So this gives you flexibility when you migrate with minimal effort from SAP PO runtime to SAP CPI.

Now let’s see if the deployed iFlow works.
To test your iFlow in SAP PO go to the deployed iFlow  and hover your iFlow. Click on “View Endpoints”

Figure 19:

and copy the URL of the endpoint to which my sender should send the Purchase Order request.

Figure 20:

I use for SOAP calls SOAP UI as a generic tool which you can download for free from the internet.

As you can see SOAP is (always) a POST call,  so switch the “Method” to “POST” enter the URL to SAP PO which is the same URL as you see it in the SAP PO start page, (http://<server>:50100) and copy the URL from the screen shot before into the Resource field (/igwhttp/CreatePO_SAP_PO, including the leading “/”. )

Figure 21:

Click on “Authorization” select your authorization method (I used “basic”) and provide your user/password for the SAP PO system, as we send through this request a message from SOAP UI to SAP PO.

Figure 22:

If you finally provide the format of the BAPI call, and have used the right Media type “application/xml” for the content negotiation for the call, and click the “run” button you should see the response of the SAP backend system. In between SAP CPI has taken the request, forwarded the call to SAP backend and we see the result. A purchase order with OrderID: 4500067107 is created. Now let’s see if the order is really in the backend.

For that I log on to the backed, open transaction ME23N, enter the purchase order ID and voilá the order details are displayed

Figure 23:

So a purchase order for a 21″ Flat Screen was created.

So, what have we seen:

– you can use SAP CPI as your default integration scenario design time environment, even you want to deploy the artifacts to SAP PO. This gives you flexibility to deploy later the integration scenarios to SAP CPI, but as you have already build the scenarios in SAP CPI you don’t have to migrate/rebuild them in SAP CPI.

– you can use the product profiles in SAP CPI and SAP CPI automatically displays only those features that are available in your SAP PO runtime version.

– how to get externalization parameters from SAP CPI environment into SAP PO environment

– how to do versioning of SAP CPI artifacts

– how to configure from which SAP CPI tenant the artifacts should be deployed to the SAP CPI runtime in SAP PO

– how to find the corresponding endpoint for the SAP PO runtime, to which a sender has to send the message to

– how to test the co-deployed integration scenario

In the next blog post I want to give you hints how to get the BAPI request in Figure 21/22 and one more blog post how to monitor runtime errors in the SAP CPI runtime in SAP PO and another one of how to adapt a file based integration into a SOAP and finally in a REST based integration scenario. You’ll see it’s not much to migrate old style file exchanges into more modern SOAP/REST based WS scenarios.