Workflow API error 422- Unprocessable entity

[StarDev]

Hi All,

I am using workflows API to start and complete workflows from ABAP code given in the link below through restful abap.

I am able to successfully Start and Close workflows via abap code to call workflow API. The problem comes up when one user claims the workflow from My inbox and tries to complete it, Same abap code gets called trying to complete the workflow. But the API call gives an error 422 saying the entity is unprocessable. If the user unclaims it, we are able to successfully complete the workflows. Any help would be really appreciated.

https://blogs.sap.com/2019/07/09/leveraging-scp-neo-workflow-from-the-scp-abap-environment/comment-p...

[tobias_breyer]

Please check the response body of the call. It should contain more details. If assume, you use the PATCH task-instances API, so see the documentation:

https://api.sap.com/api/SAP_CP_Workflow_CF/resource -> User Task Instances -> PATCH /v1/task-instances/{taskInstanceId} -> 422:

The task cannot be updated for one of the following reasons:
The values submitted for updating the property cannot be resolved or became
invalid after resolution. The context provided in the request body contains
prohibited fields or the status in the request body is invalid.

Also check the example value.

[StarDev]

Thanks Tobias for your comment.

.The Wf task has been claimed by user using the CLAIM button which calls the std service via this URI odata/tcm/Claim?SAP__Origin='NA'&InstanceID='0f385027-06e8-11eb-bd0f-eeee0a91f755'. I think this is setting the status to unprocessable.

When we try to Complete it after claiming this error comes up. The complete button has a PUT call to a custom odata entity. Inside the method we are calling the API PATCH to complete it .

If the task is not claimed, We are successfully able to complete the task without any problems. Even if we unclaim it and complete it, It goes fine and gives status as success.

[tobias_breyer]

"Claiming" means reserving a task for processing by oneself so that no other recipient can see it and work on it. This avoids duplicated work. So receiving the 422 seems correct system behavior to me, if you cannot complete a task that has been claimed by another user.

It is not becoming clear whether the two calls are done by the same user. In fact, if you receive a 422 with an "already claimed", then maybe the call is not done with the user that has claimed the task. If you want to basically take away the task from that user, you have to unclaim it (could also be done with administrative APIs below task-instancees) and then complete the task by API.

[StarDev · Accepted solution]

This got solved by two api calls. First call is done to change the approver name in the context. Second call to complete the workflow instance by passing status as COMPLETED.

[tobias_breyer]

Hi Ravi,

it depends on how you integrate CP Workflow with the ABAP environment and what you want to achieve. Client-credentials is usually a "coded" way of calling the API. If the ABAP code itself was triggered from a web UI, I suppose it should be possible to use a token or session from there.

But I cannot help on how to use e. g. OAuth2SAMLBearer Assertion flow in the ABAP environment instead.

Regards,

Tobias

[StarDev]

Hi Tobias.

I think you are spot on !

Its getting created by technical user.

and as a matter of fact its Oauth.

What should be done to fix this ? 🙂

[StarDev]

HI Tobias. Thanks for your commments.

Yeah its the same user

For example if i click on complete without claiming as shown below.

https://api.workflow-sap.cfapps.eu10.hana.ondemand.com/workflow-service/rest/v1/task-instances/b44a7...

Output from response is

Error case. Same user claims it and tries to complete it

https://api.workflow-sap.cfapps.eu10.hana.ondemand.com/workflow-service/rest/v1/task-instances/10623...

I get error 422.

Also i noticed when i claim it( on click of claim button) there is a std api call which changes the status to RESERVED.

Something similiar happens when i unclaim ( Release ) it

[tobias_breyer]

Hi Ravi,

it is difficult to judge from looking at the screenshots. I still think it is quite likely that it is not the same user for both calls. Are you sure that the call that goes goes from the ABAP to workflow service isn't OAuth2 client-credentials based (i.e. using the service keys, not going via e. g. an approuter or Portal)? Technical users will usually never have real tasks or if they try to complete a task already reserved by a real user, they will "always" be different from the real user and get that error message.

If you can confirm it is the same user, I'd recommend opening a support ticket at LOD-BPM-WFS so that we can look at the data.

Regards,

Tobias