getText intrinsic function not executed for Filepicker document in REST connector (SaaS Web Modeler)

Camunda 8 Topics
,
1

Hi all,

I’m using Camunda 8 SaaS with Web Modeler and trying to extract the full text content of a document uploaded via a Filepicker form field into a process variable (e.g. documentContent).

According to the docs, the getText intrinsic function:

“accepts a document and an optional encoding parameter. It extracts the text content from the document and returns it as a string,” and “inserts it into the request body as a string.” [Intrinsic functions]

Goal

  • User uploads a single file (PDF/DOCX) via Filepicker.

  • Filepicker variable key: documents.

  • I want to use getText(documents[1], "UTF-8") in a REST outbound connector (HttpJson.v2) to get the text and map it into a process variable documentContent, all within SaaS + Web Modeler (no custom workers).

What I modeled

Service task using REST connector (io.camunda.connectors.HttpJson.v2):

<bpmn:serviceTask id=“Activity_1ft1rzg” name=“Get Document”
zeebe:modelerTemplate=“io.camunda.connectors.HttpJson.v2”
zeebe:modelerTemplateVersion=“12”>
<bpmn:extensionElements>
<zeebe:taskDefinition type=“io.camunda:http-json:1” retries=“3” />
<zeebe:ioMapping>
<zeebe:input source=“noAuth” target=“authentication.type” />
<zeebe:input source=“POST” target=“method” />
<zeebe:input source=“``https://dummyjson.com/test”`` target=“url” />
<zeebe:input source=“=true” target=“storeResponse” />
<zeebe:input source=“=20” target=“connectionTimeoutInSeconds” />
<zeebe:input source=“=20” target=“readTimeoutInSeconds” />
<zeebe:input
source=“={
"documentContent": {
"camunda.function.type": "getText",
"params": [ documents[1], "UTF-8" ]
}
}”
target=“body” />
<zeebe:input source=“=false” target=“ignoreNullValues” />
</zeebe:ioMapping>
<zeebe:taskHeaders>
<zeebe:header key=“elementTemplateVersion” value=“12” />
<zeebe:header key=“elementTemplateId” value=“io.camunda.connectors.HttpJson.v2” />
<zeebe:header key=“resultVariable” value=“restResult” />
<zeebe:header key=“resultExpression”
value=“={
documentContent: response.body.documentContent
}” />
<zeebe:header key=“retryBackoff” value=“PT0S” />
</zeebe:taskHeaders>
</bpmn:extensionElements>
</bpmn:serviceTask>

This follows the docs for:

What actually happens

  1. The process runs, the Filepicker uploads the file, and documents contains a proper Camunda document reference (with documentId, storeId, metadata, etc.).

  2. The REST connector executes and does not throw a “null argument” error when using documents[1] in params, which suggests getText is being invoked with a non-null document.

The connector response is stored in restResult looks like this (example):

{
“status”: 200,
“headers”: { … },
“body”: null,
“reason”: “OK”,
“document”: {
“storeId”: “gcp”,
“documentId”: “4f232462-b05d-4ca1-a4bb-419641fa4f9e”,
“contentHash”: “…”,
“metadata”: {
“contentType”: “application/json; charset=utf-8”,
“size”: 31,
“fileName”: “4f232462-b05d-4ca1-a4bb-419641fa4f9e”
},
“camunda.document.type”: “camunda”
}
}

This matches the REST connector docs: with “Store response” enabled, the response is exposed as status, body, headers, and document.

However, the mapped process variable documentContent is always null, because response.body is null, so response.body.documentContent is null.

To debug further, I looked at an incident where I also put the intrinsic function into headers. The incident variables show that the intrinsic JSON is being sent as-is, not resolved:

“body”: {
“documentContent”: {
“camunda.function.type”: “getText”,
“params”: [
{
“camunda.document.type”: “camunda”,
“documentId”: “ab0cd06e-174a-41cf-85ef-18da89bac7d4”,
“storeId”: “gcp”,
“contentHash”: “…”,
“metadata”: {
“contentType”: “application/vnd.openxmlformats-officedocument.wordprocessingml.document”,
“size”: 13333,
“fileName”: “Test File.docx”,
“customProperties”: {
“pickerKey”: “files::2sxesa6pkeu6jodsu9wu3t255”
}
}
},
“UTF-8”
]
}
}

So instead of seeing "documentContent": "<extracted text>" in the outgoing request, the connector is sending the intrinsic function structure unchanged.

When I intentionally used a non-existing variable (e.g. document[1] instead of documents[1]), I got:

Failed to execute intrinsic function: getText with arguments: [null, UTF-8]

which confirms that:

  • Intrinsic functions are being invoked.

  • The argument is null when the variable is wrong.

  • With documents[1], this error does not occur, so the document argument is non-null in that case.

Summary of the issue

  • Filepicker upload works; I get a valid document reference in documents.

  • REST connector with storeResponse = true works; I get restResult.document with documentId, etc. [REST response]

  • Intrinsic function getText is configured as per docs and is clearly being invoked.

  • But:

    • The intrinsic JSON is not being resolved in the request body/headers (it is sent as-is).

    • The HTTP response has body: null, so response.body.documentContent is always null.

    • I never see the extracted text anywhere in the connector response or process variables.

Questions:

  1. Is getText currently supported for:

    • SaaS,

    • REST connector (io.camunda.connectors.HttpJson.v2),

    • documents coming from a Filepicker (stored in GCP document store)?

  2. If yes, is there a working example of:

    • Filepicker → documents[1] → getText in REST connector input → mapping the extracted text into a process variable (e.g. documentContent)?

  3. From the incident payload, it looks like the intrinsic function JSON is not being evaluated at all (it’s just serialized). Is this a known limitation or bug?

  4. If this is not yet supported, is the recommended approach still to:

    • Use the document reference (documentId) and call the Orchestration Cluster REST API (GET /documents/{documentId}) from an external service, then

    • Extract the text there and send it back to Camunda as a variable? [Download document]

Any clarification or confirmation (supported / not supported / known issue) would be very helpful. If needed, I can provide the full BPMN and exact incident payloads.

Thanks!

Jignesh Pithava