Consume CDS CAP oData Service by Workzone UI Integration Card

[ckuczera]

Dear Community

I am facing an issue while accessing Information from an oData v4 Service based on CAP CDS by an UI integration card in Workzone.

The service is setup and running as a service instance in BTP. I have created a destination pointing to the CAP service manually to ensure SSO access to the service:

Till now everything works like a charm. I can access the service via Workzone dynamic destination from the ui integration card:

But: each time I am deploying the service and the bound uaa instance, the client secret is regenerated and the SSO breaks:

I need to update the client secret in the destination manually. After updating the client-secret in the destination, SSO is enabled again, and the access is possible.

Is there a way to create / update the destination automatically after deployment of the service or fix the client secret as it is fixed for client id and the certificate?

Is there another way to consume the service I missed?

Addressing the approuter of the service directly leads to a cors exception in the browser and will not be an option.

BR and thanks for your feedback

[ahmet_pelit]

Hi ckuczera,

what are the exact authentacaion parameters on destination? (sap.cloud.service)
I am developing application with saas architecture. I need consume a cds service for each tenant but I did not figure out how do do it. Have you any idea what is the key point? 

[ahmet_pelit]

Hi ckuczera

[MioYasutake · Accepted solution]

@ckuczera 

I assume that your XSUAA instance is using binding secret, and you configure the destination referring to a secret bound to the CAP service.

"oauth2-configuration": {
    "credential-types": ["binding-secret"]
}

With the above setting, a new secret is generated every time the app is deployed. I suggest creating a new service key for the XSUAA instance and configuring the destination to refer to the secret of the service key. This way, the secret bound to the CAP service and the secret for the destination can be separated.

[ckuczera · Accepted solution]

@MioYasutakeThank you for the hint

after adding the following lines to the xs-security.json and chaning. to "instance-secret" the client secret is not getting regenerated after each deployment

"oauth2-configuration": {
    "credential-types": ["instance-secret"]
}

[Yogananda · Accepted solution]

https://community.sap.com/t5/technology-blogs-by-sap/how-you-can-prepare-your-own-template-using-sap...

[ckuczera]

@ahmet_pelit in the meantime I am creating the destination objects via mta on subaccount / instance level automatically using destination content option as described below:

The name given in "sap.cloud.service" is the same as defined in srv module definition section

The parameter set in package.json are obsolete in that case because the destination is recreated after each deployment automatically!

Hope this helps. In case of question, please send me a private message

BR