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 hereExample 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!
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.
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!
Hi Cedric,
Issue is resolved. I was using the wrong entitlement plan (api instead of integration-flow).
Thank you !!
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 Cedric,
Is there a limitation on the creation of service keys?
There seems to be a limit of 10 keys in our tenant?
Kr,
Tim
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).
Hi,
Thank you for this quick response. Do I miss something?
Kr,
Tim
Hi,
it looks like your subaccount isn't that big at all, right? Unfortunatley you can change the quota of the subaccount only via OSS support and service request. Sry :/
Resolved by creating an OSS ticket 🙂
Maybe one more question: the technical user is able to call interface flows, but is unable to open WSDL definitions via the browser. Did you find a solution on that?