Table of Contents

Dependencies of job chains implemented by events

One Event handlers are one of the methods to implement dependencies between  available for implementing dependencies between JobScheduler job chains is using event handlers. Whenever an event is created an entry is made into in the data base table scheduler_events database table. In the The event handler contains the conditions are defined to add that define whether an order is to be started for the a job chain to be startetwhen an event is detected.

Events are processed by a Job Scheduler Supervisor Instance.  If the JobScheduler is not registered with a supervisor,  the current JobScheduler Instance. This could be a Supervisor JobScheduler if a Workload JobScheduler is registered with that instance otherwise the Workload JobScheduler is used.

Notice that the event service will not work with data base H2.

The  The events can be monitored with  with the JOC Cockpit web interface, which replaces the JID - JobScheduler Information Dashboard interface, which is deprecated as of JobScheduler Release 1.12.0.

Event

...

Service

The Before events can be used the event service has to be installed . It before events can be used. The event service is part of the JobScheduler installation if ordered within it has been configured during the installation procedure.

But it is also possible to install  the event service The Event Service can also be installed in an existing JobScheduler instance. For more information  for this purpose have a look at  information see  How to install the Event Service feature in JobScheduler.

The job chain scheduler_event_service job chain is running in run at predetermined intervals or whenever an event is created and . The event service checks all .xml data files in folderthe $SCHEDULER_DATA/config/events folder for information matching the active events which are stored in the data base scheduler_events database table .  All job chains within the actual live folder may be concerned.

Event handler

The event handler is a  an .xml data file which contains the definitions of the events and the commands which are to be triggered .

For each job chain which is started by events we need an action to be defined in the event handler. An action has the two parts:

...

An event is uniquely defined by event class and event ID. Together with and/or/not the events of a group are combined to the condition.

In the command part the order Order is defined to start the job chain Job Chain as soon as the condition becomes true. It  It is also possible to use the  command the add event for creating command to create new events.

Every event which is used in the condition has to be deleted from the database with the command remove event command .

Handling events

...

in jobs / job chains

As part of the JobScheduler installation there are some Java classes to handle events.:

• JobSchedulerSubmitEventTaskAfterMonitor
  • JobSchedulerSubmitEventMonitor can be configured as a monitor for (not shell-) jobs to submit an event.The event is then submitted to the supervisor. If the JobScheduler is not registered with a supervisor, the event is submitted to the current JobScheduler. The event can be configured using job and/or order parameters. All other parameters are treated as event parameters. For shell jobs the bin/jobscheduler_ event.sh script has to be used instead of the monitor.   

     

• JobSchedulerSubmitEventJob
  • JobSchedulerSubmitEventJob can be configured  to submit an event.The event is then submitted to the Job Scheduler configured with scheduler_event_handler_host and scheduler_event_handler_port or else to the supervisor. If the Job Scheduler is not registered with a supervisor, the event is submitted to the current Job Scheduler. The event can be configured using job and/or order parameters  All other parameters are treated as event parameters.
    
    
• JobSchedulerDequeueEventsJob
  • During job execution in a Job Scheduler Workload instance events could be created that should be processed by a Job Scheduler Supervisor Instance. Therefore event handlers are configured in the Supervisor that implement individual conditions  that state to which events should be reacted, e.g. by starting other jobs and job chains. 
       
  • Dequeues Events. This job is triggered by orders or by standard job starts.
      
• JobSchedulerExistsEventJob
  JobSchedulerExistsEventJob
  • During job execution in a JobScheduler Workload instance events could be created that should be processed by a JobScheduler Supervisor Instance. This job checks if certain events event exists. The job processes orders which are configured with an event specification. Depending on whether these events exist or not the order will be put into the next_state or into the error_state.      
    
    
  • JobSchedulerCheckEvents
    
    • Check if events exist. This job is executed order driven, i.e. it starts automatically if an order is received.
      
      
  • JobSchedulerEventJob
    
    • During job execution in a Job Scheduler Workload instance events could be created that should be processed by a Job Scheduler Supervisor Instance. Therefore event handlers are configured in the Supervisor that implement individual conditions that state to which events should be reacted, e.g. by starting other jobs and job chains.  Process events.  This job is executed order driven

  Documentation

  For more information about eventing see the reference guide JobScheduler Events, Definition and Processing

  ...