JS7 JobScheduler

Space shortcuts

Page tree

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 15 Next »

Introduction

  • Notice Boards implement dependencies between jobs and between workflows.
  • A Notice Board allows a workflow to use the JS7 - PostNotices Instruction to create a notice and allows the same or different workflow to use the JS7 - ExpectNotices Instruction to await a notice.
  • Notices are JS7 - Expressions for Variables that are specified for both the posting order and the expecting order of a notice. Expressions make use of the Order ID or parts of it, for example to match the daily plan date in both Order IDs of the posting order and of the expecting order.

Notice Boards

A workflow dependency by use of Notice Boards can look like this:

Explanation:

  • Order 1 in Workflow 1 executes Job 1a and Job 1b, then posts a Notice 1 and continues with Job 1c. Posting a notice is a non-blocking operation, therefore Order 1 in Workflow 1 will complete without waiting for Order 2  to pick up the notice and to execute Workflow 2.
  • Order 2 in Workflow 2 expects Notice 1 with its first instruction. This workflow will not start unless Notice 1 has been posted by Workflow 1.

Notice

  • A Notice is considered an event that the ExpectNotice Instruction is waiting for. One or more corresponding PostNotice Instructions create the Notice from the same or from different workflows.
  • Both PostNotice and ExpectNotice Instructions reference a common Notice Board identified by its name. The Notice Board implements expressions for the PostNotice Instruction and for the ExpectNotice Instruction to identify a common Notice ID. The Notice ID typically is identified from a common part of each Order ID of the posting order and of the expecting order, for example from the daily plan date.
    • Example
      • An Order ID #2021-07-24#T7142453954-myOrder1 is running in a workflow and meets a PostNotice Instruction. The Notice Board referenced by this instruction includes an expression for the posting order to create a Notice ID based on the daily plan date included with the Order ID. The expression extracts the date from the Order ID, i.e. 2021-27-24, and makes this date the Notice ID.
      • An expecting Order ID #2021-07-24#T7142454683-myOrder2 meets an ExpectNotice Instruction in its workflow. The instruction similarly applies the expression from the referenced Notice Board to create a Notice ID. In most situations the rule what to extract from an Order ID is the same for the posting order and for the expecting order.
        • If both instructions identify the same Notice ID, i.e. the daily plan date 2021-27-24, then the expectation is met and the order proceeds with the next step following the ExpectNotice Instruction.
        • If the expectation is not met, for example if the Notice has not yet been created by a posting order or if the daily plan date of the Notice ID is not the same for the posting order and for the expecting order then the expecting order will wait until a matching Notice becomes available.
    • If no posting order exists at the point in time when an expecting order meets an ExpectNotice Instruction then the expecting order continues and ignores the instruction.
      • This behavior boils down to the fact that Notices are intended for synchronization. If there is no posting order that creates the Notice, e.g. due to calendar restrictions to specific days, then expecting orders continue.
      • Only an existing, posting order that did not yet arrive with its PostNotice Instruction, e.g. being in a SCHEDULED state, can make an expecting order wait with the ExpectNotice Instruction.
  • Notices can be assigned a lifetime that starts after being posted.
    • If an expecting order starts before expiration of a notice's lifetime then this order can continue.
    • If an expecting order starts after expiration of a notice's lifetime then this order will wait for the next notice or will start immediately if there is no further posting order in place.
  • Any number of workflows can implement PostNotice Instructions and ExpectNotice Instructions referencing the same or different Notice Boards.

Configuration

Notice Boards are available from the Configuration View:


Explanation:

  • The "Notice ID for the posting order" specifies an expression that extracts the daily plan date from the Order ID of the posting order. This creates a Notice ID for matching daily plan dates.
  • The "Notice ID for the expecting order" applies the same expression. As a result both posting order and expecting order have to match the same daily plan date for synchronization.
  • The "End of Life of Notice" specifies the lifetime for which a posted notice is available and that is counted when the notice is posted.
  • For details about expressions used to identify matching Notice IDs see JS7 - Expressions for Variables.

Example

The following sample configuration files implement a basic scenario:

The sample files can be uploaded in the Configuration view after creating the respective empty Notice Board and Workflows by using the  icon for the respective objects.

  • Adding an order to the jduNoticeDailyPalnExpect workflow makes the workflow wait for the Notice.
  • You can post the Notice manually from the Resources->Notice Boards view and you can add an order to the jduNoticeDailyPlanPost workflow to verify that the Notice is created by this workflow and that the jduNoticeDailyPalnExpect workflow is continued.

Use Cases

Static Dependency of Workflows

In this scenario orders are scheduled for both Workflow1 and Workflow 2. 

  • If Order 2 for Workflow 2 starts earlier than Notice 1 has been created by Order 1 then Order 2 will wait until Notice 1 becomes available.
  • The business requirement includes
    • to start Workflow 1 at any point in time during the day.
    • not to start Workflow 2 before - optionally partial - completion of Workflow 1.
    • to start repeated executions of Workflow 2 immediately if Workflow 1 was successfully executed once during the same daily plan date.
  • As there is an Order 1 for each day that an Order 2 is created this practically means that Order 2 for Workflow 2 can start only after a number of jobs or after all jobs in Workflow 1 completed successfully.
    • The PostNotice Instruction in Workflow 1 can be at any position in the workflow, allowing e.g. to post Notice 1 before completion of the workflow.
    • The ExpectNotice Instruction in Workflow 2 can be at any position, allowing e.g. to execute a few jobs before expecting Notice 1.

Calendar based Dependency of Workflows

In this scenario orders are scheduled for Workflow 1 and Workflow 2 based on different calendars. Let's assume

  • Workflow 1 runs for Asian stock exchanges based on specific working days and non-working days in this region.
  • Workflow 2 runs for European stock exchanges based on specific working days and non-working days in this region.
  • The business requirement includes
    • to delay the start of Workflow 2 until Workflow 1 completed for working days in the Asian region.
    • for non-working days in the Asian region to immediately start Workflow 2.

The dependency could look like this:

  • If there is a working day in the Asian region then an order will be created for Workflow 1.
    • If an order is created for the European region for the same date then this order will wait for completion of Workflow 1.
    • If no order is created for the European region for the same date then this does not affect Workflow 1.
  • If there is a non-working day in the Asian region then no order is created for Workflow 1.
    • If an order is created for the European region then this will start Workflow 2 without waiting for a notice as there is no posting order from the Asian region available for this date.
    • If no order is created for the European region then neither Workflow 1 nor Workflow 2 will be executed.

Dependencies for delayed Order Execution

This scenario starts from the above calendar based dependency and handles delayed execution of orders:

  • If Order 1 and Order 2 are scheduled for Day 1 but Order 1 cannot proceed in Workflow 1 and remains e.g. in a FAILED or SUSPENDED state for a period longer than Day 1 then Order 2 will wait for Day 2, Day 3 etc. until Order 1 posts the required Notice 1.
  • Users can specify a lifetime for Notice 1:
    • if the lifetime is shorter than or equal to Day 1 then Order 2 will start immediately with Notice 1 being expired - provided that there is no further posting order for Workflow 1 for the same daily plan date.
    • if the lifetime is longer than Day 1 then another pair of Order 1+ and Order 2+ will be started due to the underlying schedule. As both orders are scheduled for a new daily plan date their dependency is independent from Order 1 and Order 2 for the previous daily plan date.
  • The desired behavior includes
    • the use case to execute Order 1+ and Order 2+ before Order 1 and Order 2 completed. For this use case the lifetime of Notice 1 can be configured for any number of days.
    • the use case to execute Order 2 immediately after expiration of Notice 1 at the end of Day 1 or earlier independent from the state of Order 1 being FAILED, COMPLETED or CANCELLED.

Visualization and Navigation

Graphical View of Workflow Dependencies

From the Workflows view the  icon is offered to invoke the graphical view of a workflow:


The graphical view of the current workflow (blue) displays workflow instructions and dependent objects.

For the PostNotice and ExpectNotice Instructions related workflows are displayed in green:


Explanation:

  • Clicking on a job displays the job script.
  • Clicking a green workflow navigates to the respective workflow that is displays as indicated with the following screenshot.



Explanation:

  • This view allows to navigate by clicking Notice Board objects.
  • The view is updated with the respective workflow that expects/posts Notices from/to the respective Notice Board.

Tabular View of Workflow Dependencies

The Workflows view offers the icon to invoke the tabular view of workflow dependencies:


The tabular view displays dependencies for any ExpectNotice and PostNotice Instructions included with the current workflow:

Explanation:

  • For each ExpectNotice Instruction related workflows are displayed that include PostNotice Instructions for the same Notice Board. 
  • For each PostNotice Instruction related workflows are displayed that include ExpectNotice Instructions for the same Notice Board.

Graphical View of Object Dependencies

The following page is invoked from the  icon in the right upper corner of the graphical workflow view and displays all workflows that are involved in posting/expecting orders to/from the Notice Board that is used in the current workflow.


Explanation:

  • The green and the grey workflows both post to the same Notice Board from which a Notice is expected by the currently selected workflow (blue)
  • The current workflow (blue) and one more workflow (brown) both wait for a Notice from the same Notice Board.
  • Use of the icon switches to the graphical view, use of the he   icon displays the dependency view.

Execution View of Notice Boards and Notices

At run-time Notice Boards and Notices can be controlled from the Resources=>Notice Boards sub-view like this:


Explanation:

  • The tree in the left panel offers to navigate to folders to limit results displayed.
  • For each Notice Board
    • the Posting Order's and the Expecting Order's Notice ID are displayed.
    • expected Notices are displayed sorted by Notice ID, preferably including the Order's daily plan date.
    • Orders are displayed that wait for the expected Notice to become available.
  • The view offers the action
    • to post a Notice. This operation is similar to a Workflow executing the PostNotice Instruction. As a result any Orders waiting for the expected Notice will continue. The underlying use case is to simulate a Workflow's PostNotice Instruction and to manually resolve dependencies of Expecting Orders.
    • to delete the indicated Notice. As a consequence any Orders that will later on expect the given Notice have to wait for a new Notice to be added. This operation can be used to revert a Workflow's PostNotice Instruction and to make Expecting Orders wait until the Notice is posted from a different Workflow or is manually posted in this view.

Post Notice

The operation to post a Notice is available from the Notice Board's action menu like this:


This allows to freely chose a Notice ID for which the Notice is posted.

In addition, this action is available from the Notice ID's action menu like this:


This action offers to post the Notice for the indicated Notice ID.

Both actions bring forward a popup window that is populated with a Notice ID like this:


Explanation:

  • Users are free to modify the proposed Notice ID.
  • The lifetime of the Notice has to be specified by an absolute or relative date and time.
  • Consider that the lifetime is calculated for the indicated time zone. The time zone value is populated from JS7 - Profiles.

Delete Notice

The operation to delete a Notice is available from the Notice ID's action menu like this:


When deleting a Notice then Orders that will later on expect the given Notice have to wait for a new Notice to be posted either from a Workflow or from the corresponding Post Notice action of this view.



  • No labels