Feel expression

Camunda 8 Topics
1

Hi,

I am getting the connector response in string format of third party API so, how can I convert that string response to json object in feel expression?

I can’t force the client to change the requirement/ update the API based on our need right?

TIA

1 Like
2

Hi @yadav1990 - I don’t think there’s a direct way to convert a string to a context (which is what JSON-like objects are called in FEEL). You might be able to use the substring function to build a context, but that feels fragile to me.

I’m not sure the answer to your second question. If the API is programmed to respond with a string value rather than JSON, then the API itself needs to be changed in order to change the response. Another option would be to create your own Connector that converts the API response to an object before sending the response to the process engine. Java (and Node and Python) have much more powerful methods for converting data than FEEL!

1 Like
3

Hi @yadav1990,

I’ve created a JSON value for a local variable from other existing variables with an input mapping like this:

grafik

Hope this helps, Ingo

4

thanks for trying but it’s what I am looking.

5

exactly to the second point @nathan.loding the API itself returning in string with escape character and getting consumed by 100’s of customer so I can’t force them to change for me.

Also, I don’t want to write the code and introduce multiple connector just for parsing the different responses.

6

Are you able to share the string and an example of the object shape you’d like to see it in?

7

I just wanted to share my experience. I’m using the SQL Connector (with MySQL) to retrieve a JSON column. (The Connector encodes the contents of the column as base64 - which is a separate problem). If I cast the column as CHAR then I get back the JSON as a string but then there seems to be no way to parse that string back into JSON!

I strongly agree with @yadav1990 that I don’t really want to add a worker/connector to parse this data.

8

I’m facing the same problem.
I need to pass some parameters of the userTask to a thirdParty task manager .
First I make a REST-call with the REST-connector to the Camunda8API REST endPoint /v2/user-tasks/search to get the active userTasks by processInstanceKey. I tried putting the parameters (JSON) into customHeaders, but in the response to the query I get them back with escape characters for every " and I couldn’t parse this escaped JSON in FEEL.
Example:
header1 in Modeler is {"TaskResult":4}
But the output is
"customHeaders": {"header1": "{\"TaskResult\":4}"}
so I can’t access it like message.body.items[1].customHeaders.TaskResult

{
  "items": [
    {
      "key": "2251799863357118",
      "elementInstanceKey": "2251799863357117",
      "processDefinitionKey": "2251799863354847",
      "processInstanceKey": "2251799862909211",
      "state": "CREATED",
      "elementId": "Activity_09e7dov",
      "processDefinitionId": "BidFactoring",
      "creationDate": "2025-07-22T17:46:16.900+0000",
      "tenantIds": "<default>",
      "externalFormReference": "4422922",
      "processDefinitionVersion": 14,
      "customHeaders": {
        "header1": "{\"TaskResult\":4}"
      },
      "priority": 50
    }
  ],
  "page": {
    "totalItems": 1,
    "firstSortValues": [],
    "lastSortValues": [
      2251799863357118
    ]
  }
}

I have also tried to put the parameters into a local variable, but sometimes I don’t get the values of variables from tasklist REST /v1/tasks/:taskId/variables/search when querying because the variables have not jet been processed in ElasticSearch indices by the time the taskId itself is already available through /v1/tasks/search. So this method of passing task parameters is unreliable - the task is already available but its local variables are sometimes not available jet and there is no way to know when the are finally available for querying.

So it would be nice if ether FEEL could parse an escaped JSON (string) into a context or if the Camunda8API REST endPoint /v2/user-tasks/search would output JSON values of customHeaders as JSON and not as a sting (escaped JSON)

9

@igormsk - I agree. Could you please comment on and upvote this GitHub issue, and I will this feedback with our product management team as well!

10

done - thank you

1 Like