Workflow Group Configuration (3.0)
The workflow group configuration will allow you to create and manage the workflow groups. You can set the scheduling as well as the execution behavior of the members in the workflow groups.
Workflow Group Buttons
Item | Description |
|---|---|
| Enables you to include or exclude the following from the Available to Add list:
|
Add
| Includes the selected member(s) into the workflow group. |
Right Click Menu
Available to Add Pane
Right clicking a workflow template, workflow group or workflow in the Available to Add upper and lower panes opens the following menu:
Entry | Description |
Add as Member | Include the selected workflow into a new or existing workflow group. Selecting a Static workflow template from the Available to Add list will include all the workflows that are contained in the template into the workflow group. This differs from a Dynamic workflow template. Adding a Dynamic workflow template will add the template itself as a member, allowing for every dynamic workflow generated by the template to be part of the workflow group. Other workflow groups can also be part of a workflow group. You can also select workflow, workflow template or workflow group from a workflow package to be a member of the workflow group. |
| Configuration Filter | Enables you to include or exclude the following from the Available to Add list:
|
Group Members Table
Right clicking a row in the Group Members table opens the following menu:
Entry | Description |
Prerequisites | Opens the prerequisites window, allowing you to add any members present in the workflow group as prerequisites to the currently selected member. When assigning prerequisites to any members in the workflow group, the idea is to have the member execute only after the prerequisite members have successfully run. Note! You will not be able to add members above your selected member as prerequisites. You will have to order members that you want to add as a prerequisite to be below the member you are adding the prerequisite for. Workflow template and workflows from the same workflow template can be added into same workflow group, provided prerequisite is set in either workflow template or workflow or both. Dynamic workflow templates cannot be added as a prerequisite. |
| Remove Member | Removes the selected member from the workflow group. |
| Move Member Up | Increases the order of the selected member in the workflow group. |
| Move Member Down | Decreases the order of the selected member in the workflow group. |
| Show Member Tool Bar | A check box to make tool bar with the Remove Member, Move Member Up and Move Member Down options visible. |
Workflow Group Tabs
The workflow group configuration has three different folder tabs: Members , Execution, and Scheduling which are all described in more detail below.
Members
This tab allows you to add and remove members into a workflow group. A workflow group member can be a workflow, workflow template or another workflow group.
Item | Description |
|---|---|
Available To Add | Upper pane: Displays a tree view of the workflow templates and workflow groups that are structured within their respective folders, and are available to you to add as members when creating a new workflow group. Lower pane: Displays a list of workflows that are included in the workflow template or workflow group that you select from the upper pane. For dynamic workflow templates added into the workflow group, any workflows generated by the template will be part of the workflow group. You can also select workflow , workflow template or workflow group from a workflow package to be a member of the workflow group. Info! A workflow group can be a member of another workflow group. |
Group Members | Shows the currently added workflow group members. Each group member will occupy a row in the table and will include its validity, name, type and prerequisites. A member can be a Batch workflow, Real-time workflow, Task workflow, Group or Template type if a dynamic workflow template was added into the workflow group, and it also can be from workflow package. |
The Member toolbar is located beneath the Group Members table, and consists of three buttons: Remove , Up and Down.
This option must be selected if you want to have these buttons visible in the view. To remove the buttons, clear the check box for this option from the right click menu. |
Create workflow group - Adding members from workflow package
Execution
The execution tab contains options that allow you to set the execution strategy for the members within the workflow group.
Entry | Description |
|---|---|
Max Simultaneous Running Workflows | Enter the maximum number of workflows you want to be able to run concurrently. Note! If you do not specify a limit, your specific work environment and equipment will determine the maximum number of workflows that can run simultaneously. This value applies only to the workflow group that you are defining and will not affect members that are workflow groups. |
Startup Delay | If Max Simultaneous Running Workflows is set to a value larger than 1, enter the delay (in seconds) of the execution start for each of the workflows that may run simultaneously. Info!
|
| Continuous Workflow Execution | Select this check box if you want to allow members in scheduled workflow groups to execute on schedule even though all workflow members in the group have not finished execution. This may be useful in case one member is delayed for some reason, whereby preventing the remaining workflow members from executing on schedule. Note! This feature is not supported for nested group members, only workflow members. For a workflow group with a member that is delayed over the next scheduled time, this setting will make the member execute immediately when it is finished. The workflow group will be in a continuous Running state, not switching to Idle in between executions as is the default behavior. This needs to be considered when making configurations based on workflow group states. |
Continue | Enabling this option will cause the workflow group to continue to run until all its members are fully executed or all are aborted. Note! This means that groups with real-time workflow members will continue to run until all the members are aborted or stopped manually. |
Stop | Enabling this option will cause the workflow group to stop when a member aborts. A batch Workflow member will finish the current batch and then stop, while a real-time workflow will de-initialize and then stop. |
Stop Immediately | Select this option to have the workflow group stop immediately when a member aborts. A batch workflow will stop even in the middle of processing a batch. |
Enable | Select this check box to enable the workflow group execution settings. Info! Execution settings that you configure here, will only apply for workflow members that have not been configured with any execution settings in the workflow properties. Any execution settings configured in the workflow properties will take priority over the ones configured in the workflow group. |
Distribution | A workflow executes on an Execution Context. Specific ECs, or groups of ECs, may be specified by the user, or the system can handle it automatically. The Distribution settings are applied to all included group members i e workflow- and workflow group configurations. When there are conflicting settings, the members that are lowest in the workflow group hierarchy have precedence. When the Distribution settings of workflow group configurations are set on the same level in the hierarchy, they do not conflict with each other. Note! If you select to configure the distribution using EC groups, the selected distribution type will also be applied on the ECs within the groups. Hint! You can combine both individual ECs and EC groups in the Execution Contexts list. The selected distribution will then be applied for all ECs stated either individually or in groups. The following options exist: Sequential - Valid only if Execution Contexts are defined. Starts the workflow on the first EC/EC group in the list. If this EC/EC group is not available, it will proceed with the next in line. Workflow Count - Starts the workflow on the EC running the fewest number of workflows. If the Execution Contexts list contains at least one entry, only this/these ECs/EC groups will be considered. Machine Load - Starts the workflow on the EC with the lowest machine load. If the Execution Contexts list contains at least one entry, only this/these ECs/EC groups will be considered. Which EC to select is based on information from the System Statistics sub-system. Round Robin - Starts the workflow on the available ECs/EC groups in turn, but not necessarily in a sequential order. If EC1, EC2 and EC3 are defined, the workflow may first attempt to start on EC2. The next time it may start on EC3 and then finally on EC1. This order is then repeated. If an EC is not available, the workflow will be started on any other available EC. |
Scheduling
The cause of execution for a workflow group can either be a planned time scheme or a specific event. You can configure the cause of execution in the Scheduling tab.
Note!
Changes to a running workflow group will not apply until the group has finished running, which means that a real-time workflow will have to be stopped manually for changes to apply.
Entry | Description |
|---|---|
Day Plans | Use this table to plan timed triggers that will execute your Workflow group. Note that you can define a list of various plans. The system will pick the plan that meets the top priority according to the section below, Day Plans Priority Rule. Click on the Show... button to open a calendar that displays the Workflow group execution plan, see the section below, To View an Execution Plan. |
Event Trigger | Use this table to define an event execution trigger for the Workflow group, see the section below, Event Triggers. |
Day Plans Priority Rule
The Day Plans table enables you to create a list of different execution schemes of the Workflow group. You configure each Day Plan to any interval between executions.
Note!
Two Day Plans should not contradict each another. An example of an invalid configuration: Day Plan A is set to Tuesdays Off, while Day Plan B is set to Every 5 minutes between 15:00:00 and 15:05:00 on Tuesdays.
The following priority rules will be applied for picking a Day Plan out of the list:
- Last day of month
- Day of month (1-31)
- Weekday (Monday-Sunday)
- Every day
Day Plans Configuration
The following fields are found in the Add Day Plan dialog box pop-up when adding a Day Plan to the workflow group.
Entry | Description |
|---|---|
Day | Select the target day. Valid options are:
|
Day Off | Select this check box to avoid execution on the day specified in the Day list. |
Start At | Enter a start time for the first execution. |
Stop At | Enter the time for when execution should stop. Note! If these fields are left empty, the default stop time, which is 23:59, will be applied. |
Repeat Every | Enter the interval between execution start time in seconds, minutes, or hours. Note! If this field is left empty, only one execution session will run at the specified start time. Note! If a member in a group is delayed for some reason, and not finished at the time the execution is set to be repeated, all members in the group will have to wait until the next repeat time. To override this behavior, you can use the Continuous Workflow Execution setting in the Execution tab, see the section above, Execution. |
To View an Execution Plan
- Click on the Show... button beneath the Day Plan table.
- The Execution Calendar opens.
The Execution Calendar
- A colored cell in the calendar represents at least one scheduled execution during that time.
- Click on a green cell.
- The Hourly Execution Plan opens.
The Hourly Execution Plan
Event Triggers
To trigger the execution of a Workflow group you add a row to the Event Trigger table. A row can be either a certain event, or a chain of events, that must occur in order for the Workflow group execution to set off.
Note!
An Event Trigger that is comprised of a chain of events will take effect only when all the events that it includes have occurred.
The events that have occurred are stored in memory. When Usage Engine is restarted this information is lost and none of the events on the event chain are considered to have occurred.