Assign Task API is not working

Camunda 8 Topics
, , ,
21

If you have installed camunda using helm chart did you provide a context path? if yes endpoint should be like

${host}:${zeebe-gateway-rest-port}/${contextPath}/v1/tasks//assign

22

Hello @nathan.loding ,

thanks for the idea. Will try out using Postman as well.

I have narrowed the cause down to the configuration with Multi-tenancy and Identity auth. When I try the exact same code with the docker-compose-core.yaml file from Camunda Platform, the calls to the Zeebe REST API work correctly. So, when Auth via Identity is disabled (and thus also Multi-tenancy is disabled), the calls work correctly.

Kind regards,
bpmnenthusiast

23

Hello @rashidRizvi98 ,

thank you for the help. I am, however, not using the Helm Chart and have checked - the configured URL is correct.

Kind regards,
bpmnenthusiast

24

@bpmnenthusiast - that’s interesting, good info. Let me know how the Postman call turns out. I do plan on testing this after I clear a few other things from my plate. If we have a bug, I want to make sure we can replicate it and get it to engineering!

@rashidRizvi98 - FYI, the instance key in that Java error rarely includes the protocol, host, port, or context, and only shows the relative path to the endpoint that was called. This is expected behavior.

25

Hello @nathan.loding,

great, thank you for letting me know.

I tested the call also via Postman. As you suspected, this call also fails with the exact same error message as the call via the client library.

Kind regards,
bpmnenthusiast

1 Like
26

Hello @nathan.loding,

I could narrow the issue further down.

I tried the call when Identity Auth is enabled but Multi-tenancy is disabled. It worked fine. So the issue seems to be the handling of the tenant ID when Multi-tenancy is enabled.

Kind regards,
bpmnenthusiast

27

@bpmnenthusiast - I encountered some issues with Zeebe User Tasks and multi-tenancy myself, and I engaged our engineers who were able to use the feature with no problem. I’ll be doing some additional troubleshooting with them this week to identify what I’m doing incorrectly, and will hopefully have some answers for you (and perhaps some upgrades to our documentation also!) later this week!

28

Hello @nathan.loding,

great, thanks for letting me know.

I have noticed that one part of my setup as I had described it here was not how we are meant to use Camunda Applications. It still worked equivalentally to what I have currently but wasn’t the way to go.

So, my current setup (in which everything works as before - meaning my calls to the Zeebe gRPC API and to the Tasklist API also work correctly as before, but the call to the Zeebe REST API for user tasks doesn’t work) is like this:

  • I create an own Application in Identity, let’s call it B
  • I then assign tenant A to application B
  • Under Applications → B → Access to APIs I assign only the APIs that B will be using - in this case all permissions for the Tasklist and Zeebe APIs.
  • In my setup for the Zeebe and Tasklist clients I pass the client ID and client secret for application B, not for the zeebe and Tasklist Applications as I did previously

This shouldn’t make a difference, but I wanted to show that I have corrected the usage of Identity Applications on my part.

Kind regards,
bpmnenthusiast

29

@bpmnenthusiast and @Mukesh_Reddy - circling back on this, it looks like it might be an issue with the Docker configuration specifically. We have a suite of automated tests that explicitly test Zeebe User Tasks and the REST API, and they pass (example). We are able to recreate the issue with a local Docker environment, but if we build/run from source to debug, it works as expected! So rather than it being a bug in the code, it’s a bug in the container/configuration. I’m continuing to work with the engineers to further troubleshoot and figure out what is incorrect, and get it fixed!

30

Hey @nathan.loding

Thanks for letting us know .

31

@bpmnenthusiast and @Mukesh_Reddy - I believe we’ve found the missing configs! It was quite a journey, but a good one for us to take as we’ve identified important gaps in our documentation and default configurations. Thanks for the patience and the feedback!

Add these variables to the Zeebe configuration in docker-compose.yaml:

- CAMUNDA_IDENTITY_ISSUERBACKENDURL=http://keycloak:8080/auth/realms/camunda-platform
- CAMUNDA_IDENTITY_BASEURL=http://identity:8084
- CAMUNDA_IDENTITY_AUDIENCE=zeebe-api
- SPRING_PROFILES_ACTIVE=identity-auth

I think these can replace some of the variables, but I am not totally sure, so best leave the other configuration values as is for now.

Let me know if this works for you!

32

Hello @nathan.loding,

many thanks! Adding the four new variables worked great.

Thank you very much for taking the time and investigating with us.

Kind regards,
bpmnenthusiast

33

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.