JS7 JobScheduler

Space shortcuts

Page tree

Introduction

The JS7 - Daily Plan holds the orders that will be executed for future dates. Basically there two approaches how to plan orders:

  • Let the JS7 - Daily Plan Service do the job. It runs automatically each day and plans ahead for a configurable number of days.
  • Manually plan orders from the GUI.

Inconsistencies can arise if both planning mechanisms are used at the same time. For example, if users cancel orders from existing Daily Plan dates or add indiividual orders to dates that have not yet been planned. The reason for inconsistency is the fact that the Daily Plan Service will not plan orders for days for which it finds existing orders. 

It is reccommended to check the Daily Plan, particularly for environments that are subject to frequent changes of workflows and schedules. To this purpose users can apply the below solution that will check consistency of the Daily Plan.

FEATURE AVAILABILITY STARTING FROM RELEASE 2.8.0

Solution

The solution is available from a sample workflow that can be adjusted to user's needs.

Download (upload .json):

Workflow: CheckDailyPlanSubmission

The workflow is implemented for use with Agents running on Unix or Windows from the follows steps:

  • Optionally the Daily Plan Service is started to ensure that all orders are planned. There is no harm in running the Daily Plan Service a number of times, though this will not change results.
  • Next, the settings for the JS7 - Daily Plan Service will be retrieved that specify the number of days ahead for which orders will be planned and will be submitted.
  • Next, planned and submitted orders will be retrieved from the Daily Plan.
  • Finally, the following checks are performed to verify
    • if the overall number of planned orders meets the expectation (should be zero).
    • if the overall number of submitted orders meets the expectation (individual assumption).
    • if the number of submitted orders per day of week meets the expectation (individual assumption).

Workflow arguments are available as follows:

ArgumentDefaultPurpose
max_planned_orders0Specifies the expected number of planned orders for the number of days ahead for which the Daily Plan is calculated. Frequently zero planned orders are expected.
min_submitted_orders0Specifies the expected number of submitted orders for the number of days ahead for which the Daily Plan is calculated. This is not the number of daily orders but the number of all orders during the period. Users can specify their expectation about the number of submitted orders.
min_orders_monday
min_orders_tuesday
min_orders_wednesday
min_orders_thursday
min_orders_friday
min_orders_saturday
min_orders_sunday		0Specifies the expected number of submitted orders for the related day of week. Users can specify their expectation about the number of submitted orders.
except_days''Specifies a list of days that will not be considered when checking the Daily Plan, for example non-working days or public holidays.
The list is created from the format: <yyyy-mm-dd[,yyyy-mm-dd]> or from an empty string indicated by two single quotes, for example:
  • 2025-07-14
  • 2025-07-14,2025-12-25
  • ''
run_daily_plan_servicetrue

Specifies that the JS7 - Daily Plan Service should be started before checking the Daily Plan. Can be set to false if the Daily Plan Service was executed before the check of the Daily Plan is performed..

wait_for_daily_plan_service60

If the Daily Plan Service is started by this workflow (run_daily_plan_service = true), then the argument specifies the duration in seconds of the period for which the workflow will wait for the Daily Plan Service to complete. A period of 60s should be sufficient for the Daily Plan Service creating some 3000 orders.


Users can provide arguments to the workflow by creating an order that will specify arguments for which default values should not be applied. In the Configuration->Inventory view the workflow looks like this:


The workflow will fail

  • if the number of planned orders found in the period ahead will exceed the number specified from the max_planned_orders workflow variable.
  • if the number of submitted orders for the period ahead will be lower than the number specified  with the min_submitted_orders workflow variable.
  • if the number of submitted orders per day of week will be lower than the number specified with the min_orders_<weekday> workflow variables.

Users can apply JS7 - Notifications to receive alerts in case of failure of the workflow.

The workflow is implemented using the JS7 - JITL JS7RESTClientJob that will access JOC Cockpit's REST Web Service. Therefore, the workflow requires connections settings and credentials from a job resource.

Job Resource: AuthenticationSettings

The workflow is assigned the AuthenticationSettings job resource, see JS7 - Job Resources.

The job resource holds connection settings and credentials for access to the JS7 REST Web Service API.

  • js7.api-server.url: Specification of the URL is required and has to be adjusted:
    • The hostname in the example is localhost. This will match only if JOC Cockpit and Agent are operated for the same server. Users should specify the hostname of the server for which JOC Cockpit is operated. If more than one JOC Cockpit instance is available, then they can be specified spearated by a pipe character |.
    • The port in the example is 4446. The port might be different depending on JOC Cockpit installation.
  • js7.api-server.username: The account that is used to authenticate with JOC Cockpit.
  • js7.api-server.password: The password used by the account.

The example is simplistic. The JS7 supports a number of more secure ways of authentication, for details see JS7 - JITL Common Authentication.

Resources


  • No labels