• Message Services are a common means for Enterprise Application Interation (EAI). Users who operate a Message Service want to integrate their applications with JobScheduler. Patterns for Enterprise Application Integration include:
    • applications send job start requests to JobScheduler.
    • applications receive processing results from jobs and job chains executed with JobScheduler.
  • Such EAI scenarios provide the following advantages:
    • reduce complexity
      • at a the topological level, i.e. each application implements only one interface to the Message Servcice.
      • of error handling as a Message Service would be considered to be highly available.
    • manage messages centrally
  • The JMS integration scenario includes a separate Java based consumer to be implemented in order to receive and parse messages and to translate messages received into job start requests. The reasons for this decision are:
    • JMS is certainly standardized, however, the content and format of messages requires individual parsing.
    • JobScheduler offers an XML command interface that can be used by any consumer to request job starts.

Use with Generic Jobs


  • The implementation is independent from the JobScheduler release and consists of Java examples that are separately available, see below references.
  • JMS support is added with  JITL-282 - Getting issue details... STATUS

Szenario 1: Detached JobScheduler JMS Interface

1. Use Case

  • An application prompts JobScheduler to start a job.

2. Producer

  • Creates a text message in the XML format for the queue "JobChains". The content of the message can be e.g.:
    <add_order job_chain='REL_PATH/JOBCHAIN_NAME' at='now'></add_order>
  • sends the message to the specific queue

3. Consumer

  • Reads a message from the queue „JobChains" and sends the XML snippet via TCP/UDP to a JobScheduler instance.

Szenario 2: Generic JobScheduler JMS Interface

1. Use Case

  • A Java job runs in a job chain and implements the Producer to send information to the Message Service after completion of a number of job nodes in a job chain.
  • A Java job runs in a job chain and implements the Consumer, i.e. connects to the Message Service to check for new messages that include possible job start requests.
  • The Producer as well as the Consumer run in any job chain.

2. Producer

  • Producer: Jobs sends some information to a message queue to signal completion of a job chain.

3. Consumer

  • Consumer: Reads JobScheduler XML API command from a message and hands over the XML command to JobScheduler for execution.

Use with File Transfer jobs


  • YADE is extended to pre-process XML snippets from messages that have been received from a queue.
  • JMS support is added with  YADE-409 - Getting issue details... STATUS

Starting Situation

The YADE Client reads a configuration from an ini file. The configuration items are mapped to an Option class. The file transfers are processed.

  • The ini file configuration will be replaced with an XML configuration in the future.
  • At the time of writing it is only possible to create an XML configuration via the XML Editor. To use the configuration it has to be exported to an ini configuration for YADE to use.

Desired Behavior

Extending the YADE Client with a pre-processing functionality.

  • The pre-processing starts after the configuration has already been mapped to the options and before the actual processing of the file transfer.
  • Advantages:
    • This is based on the decision to use the YADE XML in the future for configuration instead of the old ini configuration.
    • The pre-processing is independent of the initial configuration (ini or xml)
    • No need to save a temporary (merged) configuration to the file system for later use. The update values will be directly mapped to the options.
    • The changes to the YADE Client are kept simple, the processing of the file transfers does not have to be adjusted.

The pre-processing includes to:

  • merge the received XML snippet of a YADE configuration into the existing configuration
    • determine from the delivered nodes which options have to be changed
    • extract the values
    • map the extracted values to the relevant options

The XML snippet has to consist of YADE XML compliant elements.

Use with the JobScheduler Monitoring Interface


  • The implementation allows a Message Service to be used in order to forward notifications to a System Monitor
  • Support for notifications via Message Services is added with  JITL-280 - Getting issue details... STATUS


Change Management References

T Key Linked Issues Fix Version/s Status P Summary Updated

Further Resources