Workflows are dispatched automatically by system defined workflow triggers. Workflows are defined in Provider Settings.
- Based on the type of object being saved by an action, and a trigger evaluation rule tasks are added to the WorkflowQueue collection. NOTE: that queuing workflows does not require additional permissions provided the user has permission to perform the task that has been configured to trigger the workflow.
- Panel Service retrieves tasks from the WorkflowQueue based on a 1-minute polling loop (1 minute of inactivity between processing queries). Items are only dispatched if the querying service matches preferred service rules. When a task is dispatched it is deleted from the WorkflowQueue collection and added to the WorkflowRecord collection
- After Panel Service processes the workflow it posts the workflow record so it can be updated for reporting purposes in the WorkflowRecord collection.
Steps are dispatched by GET queries to /api/workflow/action/process
This query requires the Workflow license sku, and the "Execute|WorkflowRecord" permission. It also requires the user to be logged in with a Panel Service format username indicating the server the steps is to be dispatched to.
If there a no queued steps, an empty result is returned. This endpoint can only be effectively accessed as application/bson, since the JSON response does not provide sufficient type information for de-serialization into .NET objects.
Responses are returned as a ListWrap<WorkflowRecord>.
Workflow results are saved by POST to /api/workflow.
This action requires the "Write|WorkflowRecord" permission and saves data into the WorkflowRecord history collection. This endpoint does not have access to the workflow queue.
Results must be posted as a ListWrap<WorkflowRecord> object with application/bson transfer type as workflow records do not provide sufficient type annotation to support JSON deserialization.
Please sign in to leave a comment.