How does Tasklist instance id relate to Operate flow node key and how one be inferred from the other?

Camunda 8 Topics
1

Hi,

when I query the Tasklist REST API for tasks I get something like this

curl -X 'POST' \
  'http://localhost:8082/v1/tasks/search' \
  -H 'accept: application/json' \
  -H 'Content-Type: application/json' \
  -d '{}'

[
  {
    "id": "2251799813701788",
    "name": "A User Task",
    "taskDefinitionId": "Activity_0vykwtw",
    "processName": "Process_A",
...
  }
]

When I want to add a task instance variable to the task instance with id 2251799813701788 I would expect to be able to use zbctl.

zbctl --insecure set variables 2251799813701788 --variables '{"aVariable": "1234-1234-4567-7890"}' --local -o json

But I get this error message.

Error: rpc error: code = NotFound desc = Command 'UPDATE' rejected with code 'NOT_FOUND': Expected to update variables for element with key '2251799813701788', but no such element was found

It turns out zbctl expects the flow node instance key as a parameter. That only seems to be present in the operate rest api, but that does not seem to have any entrypoint using the task instance id give by the Tasklist REST API.

So, how do these two id/key generation concepts relate to each other and how can I infere the flow node instance key from the task instance id from the Tasklist REST API programmatically, to be able to add task instance variables using zbctl?

Also, I assume SetVariablesCommand from the Java API also requires the flow instance key as I see it in Operate and not the task instance id as reported by the Tasklist REST API, correct?

Best regards,
Andre

2

Hi @PKAndre, welcome to the forums! The id in the Tasklist search query is the ID of the task itself. The same response should also include a processInstanceKey, which is a reference to the process instance ID associated with that task. I believe you should be able to use the process instance ID with zbctl

3

Hi Nathan,

thank you for looking into this. You are probably right with your suggestion, that it would create a variable in the process instance. But I do not want to create a process instance variable, instead I want to create a variable that is explicitly one local to the task. And for this, as of my understanding, I need the flow node instance key of the task, which I currently cannot infer from the task instance id I get from the tasklist REST api.

4

@PKAndre - I admit that I haven’t tested this at all, but perhaps something like this?

  1. Query your task, get the processInstanceKey
  2. Using the Operate API, search for the flow node instance with the processInstanceKey found above
  3. Use the ID to set a variable

Really curious if that works - if you have a chance to test it before I do, I look forward to hearing the results!

5

Operate and tasklist API work in combination, but the problem is, that the operate api does not contain the actual task instance id.

I found that looking into the elasticsearch index works best, using camunda-elasticsearch:9200/zeebe-record_job_*/_search

This query returns the document in question:

GET localhost:9200/zeebe-record_job_*/_search
Content-Type: application/json

curl -X GET --location "http://localhost:9200/zeebe-record_job_*/_search" \
    -H "Content-Type: application/json" \
    -d "{
          \"query\": {
            \"bool\": {
              \"must\": [
                {
                  \"term\": {
                    \"value.type\": \"io.camunda.zeebe:userTask\"
                  }
                },
                {
                  \"term\": {
                    \"key\": THE_TASK_INSTANCE_ID
                  }
                }
              ]
            }
          }
        }"

The query should return at least one document and the flow_node_element_instance_key is to be found in _source.value.elementInstanceKey

The query might return more documents, as this index is from my understanding on intent granularity, capturing the task lifecycle.

Accessing the elasticsearch index is less than beautiful, but it does the trick here.