Page History
...
- Download (upload .json): pdwOrderOperations.workflow.json
Anchor | ||||
---|---|---|---|---|
|
Orders in PENDING, SCHEDULED, IN PROGRESS, RUNNING, SUSPENDED, PROMPTING, WAITING, BLOCKED and FAILED states can be cancelled: for details see the JS7 - Order State Transitions article:
- Cancel: This operation allows the order to complete the current instruction, for example, executing a job, and after completion of the instruction the order will leave the workflow with a failed history outcome.
- Cancel/Kill Taskforce: The operation kills processing of forcibly terminates the current instruction, for example a running task for a job, and makes the order leave the workflow.
...
- Cancelling an order is performed as an asynchronous operation which includes the JOC Cockpit, Controller and Agent.
- In a first step the order is displayed with a green/red bullet icon indicating that the order still is running and that the cancel operation is in progress.
- If the Controller or Agent cannot be accessed then the display of the order will remain unchanged.
- Note that "inaccessible" can mean that the network connection has been lost and that the Agent in fact is up and running. In this situation the order will continue to be processed by the Agent until the order cancel operation is successfully transmitted to the Agent.
- In a first step the order is displayed with a green/red bullet icon indicating that the order still is running and that the cancel operation is in progress.
Anchor | ||||
---|---|---|---|---|
|
Orders in PENDING, SCHEDULED, IN PROGRESS, RUNNING, PROMPTING, WAITING, BLOCKED states can be suspended:
- Suspend: This operation allows the order to complete the current instruction, for example, executing a job, and after completion of the instruction the order is put to the SUSPENDED state.
- Suspend/Kill Taskforce: The operation kills processing of forcibly terminates the current instruction, for example, a running task, and puts the order in the SUSPENDED state.
...
- Suspending an order is performed as an asynchronous operation which includes the JOC Cockpit, Controller and Agent.
- In a first step the order is displayed with a green/orange bullet icon, indicating that the order still is running and that the suspend operation is in progress.
- If the Controller or Agent cannot be accessible then the display of the order will remain unchanged.
- Note that "inaccessible" can mean that the network connection has been lost and that the Agent in fact is up and running. In this situation the order will continue to be processed by the Agent until the suspend operation is successfully transmitted to the Agent.
- In a second step the order will be displayed with an orange bullet icon indicating that the order has been suspended.
- In a first step the order is displayed with a green/orange bullet icon, indicating that the order still is running and that the suspend operation is in progress.
Anchor | ||||
---|---|---|---|---|
|
FAILED and SUSPENDED orders can be resumed from the Workflows view as follows:
...
- A period shorter than configured with the Cycle Instruction can be specified.
- Periods are specified by relative dates, for example
1h
(1 hour),10m
(10 minutes),01:30:00
(1 hour, 30 minutes). - Specifying a value
0
for the period will cause the order to continue from the resumed position in the workflow, to execute subsequent jobs and to leave the cycle next time it meets the Cycle Instruction.
- Periods are specified by relative dates, for example
- A period that is specified longer than configured with the Cycle Instruction will be ignored
Anchor | ||||
---|---|---|---|---|
|
Orders in a PENDING, SCHEDULED or WAITING state for a JS7 - Cycle Instruction or JS7 - Retry Instruction can be forced to run immediately from the Workflows view as follows:
...
Jira | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
|
Let Run Order from Workflows View
The functionality is available from the Workflows view like this:
Let Run Order from Daily Plan View
When used the with the JS7 - Daily Plan view the operation brings the following behavior:
- The order remains assigned its original Daily Plan date though it is executed at an earlier date/time. This means that the order will not consider Notices from JS7 - Notice Boards of an earlier Daily Plan date but Notices of its original Daily Plan date if the “let run” operation causes the order to start before begin of the assigned Daily Plan.
- Users who wish to modify an order's assignment to the Daily Plan and to Notices matching the order's effective start date can use the operation "Modify start time" with option "Now" from the Daily Plan view.
- The "let run" operation is available for non-cyclic orders in the submitted state. For bulk operations users have to apply the One-time order
Display feature availability | ||
---|---|---|
|
Jira | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
The operation is available with the Workflows view and can be applied in a situation when users find more than one version of the same workflow:
- When modifying and deploying workflows then a new version of the workflow is created.
- Orders that did not yet start and that hold the PENDING or SCHEDULED state can make use of the new workflow version.
- Orders that have started and that hold any other state will remain with the previous workflow version. The reason being that changes to the workflow can disrupt orders that have been added to a previous version of the workflow. For example, if certain jobs or instructions have been added before the order's current position in the workflow, then this will break execution of an exiting order.
The operation to transfer orders is available for previous workflow versions and includes to transfer all orders to the latest version of the workflow.
Explanation:
- The previous version of the workflow holds 2 orders in the SCHEDULED and in the SUSPENDED state. This version of the workflow will not accept new orders but will continue to run orders previously assigned.
- The latest version of the workflow currently is not assigned any orders.
The previous version of the workflow offers the "Transfer Orders to latest Version" action menu item like this:
As a result of the transfer operation users find all orders assigned the latest workflow version. The previous workflow version disappears as it is no longer needed with all orders being transferred.
Transfer is possible within limits of the order state:
- If orders are in the PENDING, SCHEDULED, FAILED, SUSPENDED, PROMPTING state then this will work.
- If orders are in the IN PROGRESS, RUNNING or BLOCKED state then this cannot work.
- If orders are in the WAITING state then it depends on what orders are waiting for:
- Orders waiting for Notices from JS7 - Notice Boards can be transferred.
- Orders waiting for JS7 - Admission Times for Jobs or for a JS7 - Cycle Instruction cannot be transferred.
Users can suspend WAITING orders. When orders are in the SUSPENDED state then they can be transferred to the latest workflow version and can be resumed.
Bulk Operations
The Workflows view displays a maximum of three orders for each workflow. The overall number of orders available for the workflow is displayed by the grey order indicator:
...