RELATED IDEAS
Capture of Request Content in workflow variable
External start workflow required the "Request content (parameters)" to be provided in the body of the REST call, capturing the "Request content" into a workflow variable, allows capture of additional data that are not defined as Start Variable(s) of the workflow. This capability supports External Start workflow in Nintex Workflow Cloud to be used as a "Callback URL" end point. This end point with the "Request Content" captured, supports the parsing of returned data and actions to be taken against the returned data.
External Start workflow if capable of capturing Request Content is important as it supports action to be taken on the callback request such as writing the returned value(s) to Sharepoint online list item, etc.
Please feel free to discuss the concept and usage behind.
External Start workflow if capable of capturing Request Content is important as it supports action to be taken on the callback request such as writing the returned value(s) to Sharepoint online list item, etc.
Please feel free to discuss the concept and usage behind.
-
ADMIN RESPONSESep 7, 2022Closing out the suggestion due to low votes.
Our recently released and revised 'Call a workflow' action in Nintex Workflow Cloud also automates the configuration of these External start features you have mentioned when using external start to call a workflow from another workflow. To explain further, when designing what will be a child (or called) workflow, the designer can in addition to determining start variables, can now also specify what variables should be considered 'output' variables of the workflow.
When configuring the 'Call a workflow' action in the parent (or calling) workflow, the designer can choose which External start workflow from within the tenancy the action should call. Once selected, the action configuration panel renders controls for configuring the input and output variables that should be sent to and received from the called workflow.
I hope you find this information useful.
Regards,
David
The concept/idea presented here is very different and with different opbjective than the External Start with "Output" variables. Let me try to provide more details here:
We can now call/trigger Nintex Workflow Cloud's External Start workflow today with the following payload.
{
"startData":
{
"se_firstname_11": "John",
"se_secondname_21": "Smith",
},
"options":
{
"callbackUrl": "https://callbackurl.com"
}
}
This is great as the workflow once completed will be able to make a callback to the "callbackurl".
Now, as the External Start workflow only understand the payload of above (i.e. with "startData"), we can only parse the payload to take passed parameters/values into the workflow's variable(s).
If a External Start workflow besides parsing the mentioned payload, it also take the entire payload/request content into a variable. We can now make the External Start as a service endpoint for "call back" purpose. Meaning we can now parse the return of another workflow of the following content:
{"returnData":
{
"c_status":"Review",
"se_firstname_11":"John",
"se_secondname_21":"Smith"
},
"workflow":{"id":"a58a5b90-eda6-41af-8acb-00fe299c68a6",
"name":"",
"publishedId":"3cace836-0323-4f79-b56f-5480bf79aab7"
}
}
This External Start workflow is now handling the return/ reponse of the first External Start workflow, and process the returns the way we want it. Such as feeding that responded data to Sharepoint Online list item, etc.
Support of "callbackurl" in the return is good, but it is not easy to implement, as we need to create endpoint to receive the response from the called "External Start" workflow. Now, with this idea, we can simple turn another "External Start" workflow as the endpoint for the callback.
Hope that clarifies.