Skip to Content
Technical Articles

Technical / Service user Cloud Platform Integration for Inbound Communication

Introduction

With the opportunity to use the Cloud Platform Integration (CPI) as subscription on the Cloud Foundry (CF) environment, we’ve the ability to connect the CPI to Enterprise Messaging Service (EMS) and connect events with iFlows. Because the Strategy of SCP is moving to the CF, I do recommend to think about a migration in the next years ๐Ÿ˜‰
In this small post I want to show the way to go to get a inbound-user for calling iFlows from external service providers (in our case, it’s PostMan ๐Ÿ™‚).

Preperation

  • Be sure to be have already subscribed to the CPI service on a CF subaccount and be a member of the subaccount to be able to create spaces and service-instances inside spaces
  • Create or use an existing space, to be ready to bind service-instances of CPI
  • Be able to connect to other resources (like S/4 HANA tenants) by using tile “Security Material” @ CPI. There I did deploy credentials for our S/4 HANA tenant (e.g. S4HANA_SANDBOX)
  • Create a simple iFlow (in this post I read costcenters with simple oData stuff) and deploy this iFlow

 

Let’s go

We have to understand first that we need an oAuth client to receive messages from external resources with CPI on CF. In the NEO environment we had to create S-Users or use the Identity Authentication Service (IAS) as identity provider (find Hoangs post for details).
This oAuth client will be deployed to an instance of a CF-Space. For every new service user we do have create a new instance of this service.
A)
Open the CPI in Cloud Foundry and go to the new tile “User Roles”:
There you find one default delivered role by SAP, known from the NEO environment: “ESBMessaging.send”
Note:
You can create own user roles – I did to restrict access just for iFlows for germany.
You’re able to restrict access to iFlows by providing them inside the “adapter specific” tab of your oData call:
B)
Go to a already deployed space (I named this one “INTEGRATION_TOOLS”) of your subaccount (in my case: “STAGE_CF”) and open “Service Marketplace”:
C)
Find and click on “Process Integration Runtime”
Note: If you do not find this tile for the Process Integration Runtime, check the subscription in the subaccount and the connection to an service plan / entitlement.
D)
Click “Instances”
-> Create “New Instance”
-> Choose a service plan
-> At “Specific Parameters” we need to provide the access method and the roles for this oAuth client as a json string:
{"roles": ["ESBMessaging.send"]}
Note: In my use case I did create a second role, called ESBMessaging_DE. Change the value of your json here, if you provided your own role in the CPI.
Grant-types refer to different options, provided by SAP for this oAuth Client:
If you enter grant-typeย client_x509, make sure that you exclusively use this option.
The list of supported grant-types is: refresh_token, urn:ietf:params:oauth:grant-type:saml2bearer, client_credentials, password, authorization_code, user_token, client_x509.
Find more details about this here
Example for certificate based oAuth client:
{"roles": ["ESBMessaging.send"],"grant-type": ["client_x509"]}
-> Do not bind your instance to an application
-> Provide a name of your instance, like “cpi-user-secret” or “cpi-instance” and press “finish”
E)
-> Wait till the instance is “Created” and go inside the instance by clicking on the name of the instance
-> “Create Service Key” to create a new pair of credentials (provide a name of the service key and finish it)
-> Your “Service Key” will appear and show you the credentials of your oAuth client:
Use the clientID as user and the clientSecret as password for accessing the API from external.
Note: You can create as many “Service Keys” as you want. But unfortunately, they have all the same user and secret ๐Ÿ˜‰
For every new oAuth client you need to create a new service-instance. So do not create multiple “Service Keys”, create instances!

Final testing:

Open postman and provide the Endpoint of your iFlow.
Use the clientId and the clientsecret for “BasicAuth”:
That’s it – you’re ready to go and you’re ready to test your iFlows with postman!
10 Comments
You must be Logged on to comment or reply to a post.
  • Hi,

    Thank you for this very good explained blog.

    I tried it myself on our CF tenant, but unfortunately I’m receiving following error during finishing the service instance.

    Thank you in advance,

    Tim

    /
    • Hi Tim Van Den Berghe ,

      I’m happy to hear that ๐Ÿ™‚

       

      Maybe SAP changed the default role? Is your CPI running on NEO?

      Have a look at your CPI -> “Monitor” -> “Manage User Roles” and check the available roles.

       

      Check your json again, if you did make a mistake … otherwise I recommend to open a new OSS incident :/

       

      Good luck with that!

  • Hello- can you help understand on how to implement OAuth bearer authentication for client. With the above stated process client can access simply by using Basic authentication while using client and secret. Thank you.

    • Hi Arijit,

      it’s easy. Just pass “client_credentials” as grant-type to the cpi instance (instance – not service key!!!)

      If you want to understand how oAuth works and which opportunities you have, check this wonderful post.

       

      Good luck!

  • /
    • Hi Tim,

      you can change this with quota-plans. There you can assign another plan or set the space to “Unassigned”, then you’ll get “unlimited” services (limit of your organization will be used).