SAP BTP CF: workflow - configure service task

[former_member729305]

Dear all,

I am currently configuring a service task within my workflow which has the function to write back the status of my workflow to my (CAP) app which lies within the Cloud. So there is no backend connected. Once a new Item (Book) has been confirmed/rejected the decision should be written/patched into my app for that book record into the field "status_workflow" --> see Path below in Service Task.

The issue is that if I try a PATCH request I receive the response: "failed with status code 401 (Unauthorized) and response body 'Unauthorized'". The GET request goes through but responds "The 'Content-Type' header of the HTTP response contained the value 'text/html' not a 'application/json' or a JSON-compatible mime-type as expected."

My destination is OAuth which is why I assume XSRF Token is not needed. It provides the entry link to my application and points to my Workflow Service Instance in client credentials(Id and Secret).

Does anyone of you have an idea how to approach that issue?

I would be very grateful for receiving answers

Best Regards

Max

Service Task:

Header Information - not sure if these are really necessary

destination:

[former_member729305 · Accepted solution]

only ${context} has to be used in field request variable of service task.

destination is the url from your app within your service entity.

[former_member681427]

Hi snarkway

You can try to modify your destination Authentication method to "OAuth2Password". It works fine in my project. My scenario is similar with yours.

[haraldschubert]

Hi Max,

your CAP app is protected through an XSUAA instance. You need to maintain a destination with the URL set to point to your app. The security related attributes of the destination need to match the values of the XSUAA instance. Then, I would assume you would want to propagate the principal from Workflow to CAP. Service tasks support principal propagation. Finally, you need to make sure the user that is propagated has the necessary roles assigned defined in the xs-security.json for your XSUAA.

Cheers,

Harald

[frederic-pascal_ahring]

Dear Max,

You mention both GET and PATCH requests, with your screenshots showing the PATCH one. I will assume that GET - which you stated "goes through" - is also a Service Task, similar to the above.

Please verify that the technical user you're using in the destination has the required permissions to call PATCH on your CAP application. The GET request going through indicates that the call and credentials in itself are correct, but the permissions might be lacking.
You could e.g. try making the same call manually with a tool like Postman.

Please note that this technical user needs to be accepted by the server this destination is pointing to, i.e. your CAP service. Using the binding key of a workflow service instance would usually not be what you want. Please check the CAP documentation on how to define technical users and permissions.

While you are in Postman, please confirm that the GET request to your CAP service returns a "Content-Type: application/json" header, and if not, configure the CAP service to do so.
The Header tab in the Service Task is about the request (outgoing) headers (the one Workflow service sets), while the error message indicates that the response (incoming) headers (the one your CAP service sets) are different.

You are correct that for OAuth2 tokens, no XSRF tokens are needed usually. Whether they are actually needed is a configuration on the server side, i.e. your CAP application in this case.

[former_member729305]

Hi frederic-pascal.ahring

Thanks for the feedback!

could you help out with a link to CAP documentation on how to define technical users and permissions? I can barely find this.

BR
Max

[frederic-pascal_ahring]

Hi snarkway,

I hope this will help you: https://cap.cloud.sap/docs/guides/authorization

You probably have a @restrict configuration in your CAP definition, refering some roles from the xs-security.json file. The roles specified there then needs to be given to your user in BTP cloud cockpit.

[former_member729305]

Hi frederic-pascal.ahring

that is a good hint. I checked and my user already has all the relevant roles and is able to execute all the CRUD Methods inside the apps. I think the "unauthorized" error is caused by sth different.

[frederic-pascal_ahring]

Please note that the client credentials flow is different from a password grant flow - in the latter, an actual user account and password is used (not recommended to put those into the destination configuration, though), while the former uses a technical user. Thus this technical user (or "service binding") is checked for the permissions.
I don't have the documentation for CAP at hand, though I guess it's similar to how it's done if you want to call the Workflow service as destination, which is explained here: https://help.sap.com/viewer/e157c391253b4ecd93647bf232d18a83/Cloud/en-US/c74f5ff9065b4baeb700d033602...

[former_member729305]

Hi Frederic-Pascal Ahring

that is a good advice and I had the same thought. Never the less equipping the Workflow service with mostly all authorities/scopes doesn't help. Error stays the same. In general maybe another technical user (credentials) has to be used in the destination when patching data from the workflow service to your apps. I also tried using the credentials from my html5-app-repo-host service inside my destination. but error is still there. Unfortunately the documentation for that use case (writing information from workflow to separate app via service task) looks pretty rare. Maybe anyone else has an idea. An overview of all technical scopes/authorities per service instance would also help.

Best Regards

Max

[frederic-pascal_ahring]

snarkway
From what I got from your description, you want that your SAP Workflow service is calling (using a Service Task) a separate service, and this results into an authorization issue, which is then displayed in Monitor Workflows as a failed Service Task step.
The documentation from a purely Workflow Service Task point of view is short because that's really all there is to it: define the destination name, the method ("verb") and the path. Hostname and authentication are defined in the destination, the required permissions (scopes / roles) are defined by the service being called (in this case, the CAP servie, and there it is defined in the xs-security.json file), and the association between your user and the roles are done in your IdP / Security configuration. In case of technical users, the scopes are called "authorities" and defined when creating a service instance or binding key (which would be the instance of the service you want to call - so again, the CAP service, not the workflow service)

I'm sorry that I can't help you further without an individual session.

[former_member729305]

Hi Frederic-Pascal Ahrin

thank you for investigation:) I confirm all your points.

https://help.sap.com/viewer/e157c391253b4ecd93647bf232d18a83/Cloud/en-US/df943e71122448caaf3c49f5ffd...

within the link above it states "For all OAuth2-based workflow APIs, you do not need to specify a CSRF token. This is because the OAuth2 flows already have CSRF protection when used without intermediaries. However, when workflow API requests are routed through an application router, you must apply CSRF token mechanisms. Otherwise, the CSRF protection is lost. Therefore, do not turn off the csrfProtection setting of routes in the application router that use xsuaa as authenticationType."

I assume that could be the issue as my service requires approuter and thus I need to enter a Path in XSRF Token path. But I do not know how this would look like:

books/v1/xsrf-token?

this also returns error:

Service Task

do you have any idea on how the Path for XSRF-Token has to look like?

Best Regards

Max

[frederic-pascal_ahring]

snarkway

I'm sorry, I don't know your background knowledge level, but I think there is still a confusion about the two sides of the communication here.
Workflow - as a "server" - can be called, using any kind of client, and then the Workflow API (which you just linked) and the Workflow permissions are relevant.
Workflow can also act as a client - using the Service Task - to call another service (like CAP). In that case, the authentication type, APIs and permissions of that other service are relevant.
Finally, workflow can act as a client to call itself, which can be useful in some cases.
So your scenario would be the second one.
Could you perhaps share your CAP project?

[former_member729305]

Hi frederic-pascal.ahring

Unfortunately I am not able to share the project. I am new to service tasks and usage of destinations. Lets assume I got a bookstore app: All that happens there is the creation of an item like a book which initiates an approval workflow via MyInbox. Once the approve/reject button is executed the status should be written back to my Bookstore - List Report App which then shows "approved/rejected" for that initially created item/book. For the instantiation of the workflow Instance I have also used a destination for calling the Rest API. This one is OAuth2 authenticated and helds the credentials of my linked workflow service instance.

As far as I understood you now X-CSRF Token is not necessary for that call as I am not calling a Workflow API but another App via destination. Meaning I am calling my own Bookstore App from my workflow App via destination. The question here would be which service instance I would have to use to enter the client credentials. I have tried credentials of HTML-REPO-HOST and also XSUAA service instance already but this returns the same error messages: