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.
Step Dispatch
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>.
Saving Results
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.
Comments
0 comments
Please sign in to leave a comment.