Tracking progress in a workflow involves determining where the work in a workflow is actually being performed, and tracking that work’s progress.
- To support tracking workflow progress, a workflow can, if desired, have a start of run and end of run defined on specific actions or triggers within the workflow. A workflow only supports one start of run and end of run. This is especially useful if the workflow is a recurring workflow such as those based on a timed event or those waiting for the arrival of files and then processing those files.
- The start of run should be defined on any action that occurs after any workflow waits have passed, such as waiting for a calendar event, a file to arrive, or a database condition to be met.
- When a workflow has no start-of-run or end-of-run, the workflow progress will reflect how much time has passed since the workflow was submitted to the engine (assuming it was not submitted in a paused state). For example, if a workflow with no start and end of run is submitted to the engine, and the start action is a timer trigger that will fire in 12 hours, the progress will start increasing toward 12 hours as soon as the workflow is submitted. This may not be a desired outcome of “progress.”
- If the start-of-run and end-of-run have been set in a workflow, the progress time will reflect where within the two points the workflow currently is.
- If you put start-of-run/end-of-run on a trigger, it will include the time it takes the trigger to fire in the progress calculation.
- To obtain the most accurate progress data and calculations of the length in which it takes to execute the “work” of the workflow, make sure to only include actions that actually do work within the margin in between the start-of-run and end-of-run. Timer triggers, delay triggers, and file exist triggers are not generally seen as “doing work.”
- When a workflow runs the first time, it accumulates its progress and writes that to the workflow’s run history. On a subsequent run of the same workflow, the % Complete of the workflow’s progress is computed by comparing the current runtime to the runtime for the prior run. You can erase the run history of a workflow to rest this calculation if the workflow has been modified and the accumulated history is no longer appropriate.