Processes: allow actions to return data

[ebruchez]

Internally, actions return Try[Any]. But send, in particular, could return data, including:

• response XML
• response text
• response headers
• etc.

We could see this as an immutable bag of parameters going through the process. send would be one of the few actions returning or updating the current bag. The parameters could be accessed from XPath expressions as variables or via functions (e.g. in conditions), or via parameters.

send then setvalue(ref = "/a/b/c", value = "$response-xml/*/foo")

See also discussion about calling a CMIS service and returning an id. This has also been discussed with a customer's RFE.

[ebruchez]

Use case: return value from a service and call a JS function:

send(…) then script(xvt"alert('{$response-text}')")

Or something along those lines (the alert text would need to be escaped, in particular).

[ebruchez]

We also need this for #2132 if we have a dialog asking for an email address which we want to pass to the email action.

• we could have a set-var(name = "foo", value = ...) action which updates in-scope (immutable) variables
• to take the result of an action, do `set-var(name = "foo") and the value will come from the preceding action
• hopefully this is compatible with a future update to the process language using say let foo = ... (see also New syntax for simple processes #1255)

[avernet]

+1 from customer, to be able retrieve an error message returned by a send() and use that message in an error-message().

[avernet]

+1 from user for the same use case mentioned in the previous comment.

[avernet]

+1 from user

[ebruchez]

Also related to #224 and #3803: we'd like to clarify the source of a "set control value" action instead of implicitly considering that it comes from the service response.

Now if data is conceptually stored in vals accessible later in the process, what is the structure of that val? Is it a single XML document? This would be limiting. A service, for example, returns a status code, body, etc. So we need to know what datatypes are supported by a val. Probably that the following would make sense:

• XPath item or sequence of items
• hashmap (could be an XPath map)

If they are accessible with a $foo syntax, would you have to write map:get($foo, 'body') to deal with a response body?

[avernet]

+1 from customer to access the result from send() and set the value of a field in the form with that message

[avernet]

+1 from user

[ykowalewski]

+1 from me to have such feature

[ebruchez]

+1 from customer for accessing a send's HTTP status code.

[ebruchez]

Also related to the new "action syntax", which needs something similar.

[avernet]

+1 from user

[avernet]

+1 from customer who would like to see the save action, which in their case is calling their own implementation of the persistence API, to be able to return an error message, which could then be made to be shown to end-users

[avernet]

+1 from user

For send(), if one needs to access the document returned by the service, and XML or JSON is returned, as a workaround, it can be accessed with xxf:instance('fr-send-submission-response').

[avernet]

Example:

<property as="xs:string"  name="oxf.fr.detail.process.submit.*.*">
    send(
        method  = "GET",
        uri     = "https://www.w3schools.com/XML/simple.xml",
        replace = "instance"
    )
    then success-message(
        message = "First item on the menu: {xxf:instance('fr-send-submission-response')/food[1]/name}"
    )
</property>