SAP BTP integration suite giving 403 error while triggers data from SAP

[S0025445531]

While doing integration from Happay to SAP ERP through Happay application. We are integrating using Rest API using HTTPS protocol.While triggering data from Postman we can able to get data into CPI and the same data successfully posted to the ERP system and getting the response back from ERP to postman. Please find the below screenshot:

But once we are trigger the data from the Happay application the data is not coming to CPI and those Happay team getting the 403 forbidden error.

We are doing this integration using oauth 2.0 token based.

[satishgunda]

The issue is resolved now.

https://blogs.sap.com/2019/02/14/cloud-integration-inbound-http-connections-using-oauth-client-crede...

The below step(in the above mentioned blog) is missing which was the root cause.

Go to Security > Authorizations and assign the user with name oauth_client_<client ID> to the role ESBMessaging.send. Alternatively, you can assign a custom role to this user in case you like to make sure that permissions to process messages on the runtime node should be defined per integration flow endpoint.

[sunny_kapoor · Accepted solution]

Hi ajay.rimkar,

This could be related to role assignment in case you are getting a 403 Forbidden error.

If that is the case, then for client credentials authorization in the Neo environment, you need to assign the role to oauth_client_<clientID> in SAP BTP Cockpit as explained here.

Regards,

Sunny

[CarlosRoggan]

Hello,
difficult to say what's going wrong.
Just a few questions to consider:
Postman: what credentials are you using to call the iFlow?
basic auth with clientid/clientsecret
Or are you fetching JWT token then sending token to iFlow?
Or basic auth with real user name
Or client certificate?
When the Happy-Application calls the iFlow, how are they doing?
Maybe they have different oauth-flow?
Do they have user-centric application that fetches JWT token with authorizcation-code?
Or they do token exchange, then send that token to the iFlow?

So, if flow is different, then this grant-type needs to be added to the list of grant-types when creating a service-instance of ProcessIntegration

Are they using the same service-instance and service-key like you?
What about user roles?
Is the endpoint protected with roles and do they have the roles in the service instance params?

These are some hints to consider

Kind Regards,
Carlos