Date: Fri, 29 Mar 2024 01:45:58 +0000 (UTC)
Message-ID: <625706989.12239.1711676758710@change.sos-berlin.com>
Subject: Exported From Confluence
MIME-Version: 1.0
Content-Type: multipart/related;
boundary="----=_Part_12238_880708074.1711676758710"
------=_Part_12238_880708074.1711676758710
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Content-Location: file:///C:/exported.html
How to use JMS integration with a Message Service
How to use JMS integration with a Message Service
Scope
- Message Services are a common means for Enterprise Application Interati=
on (EAI). Users who operate a Message Service want to integrate their appli=
cations with JobScheduler. Patterns for Enterprise Application Integration =
include:
- applications send job start requests to JobScheduler.
- applications receive processing results from jobs and job chains execut=
ed with JobScheduler.
- Such EAI scenarios provide the following advantages:
- reduce complexity
- at a the topological level, i.e. each application implements only one i=
nterface 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 mes=
sages received into job start requests. The reasons for this decision are:
- JMS is certainly standardized, however, the content and format of messa=
ges requires individual parsing.
- JobScheduler offers an XML command interface that can be used by any co=
nsumer to request job starts.
Use=
with Generic Jobs
Impleme=
ntation
- The implementation is independent from the JobScheduler release and con=
sists of Java examples that are separately available, see below references.=
FEATURE AVAILABILITY STARTING FROM RELEASE 1.9
- JMS support is added with JITL-282 - Getting issue de=
tails... STATUS
Szenario 1: Detached JobScheduler JMS Interface
1. Use Case<=
/h4>
- An application prompts JobScheduler to start a job.
2. Producer=
3. Consumer=
- Reads a message from the queue =E2=80=9EJobChains" and sends the XML sn=
ippet via TCP/UDP to a JobScheduler instance.
Szenario 2: Generic JobScheduler JMS Interface
1. Use Cas=
e
- 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 p=
ossible job start requests.
- The Producer as well as the Consumer&n=
bsp;run in any job chain.
2. Produc=
er
- Producer: Jobs sends some information to a message queue to signal comp=
letion of a job chain.
3. Consum=
er
- Consumer: Reads JobScheduler XML API command from a message and hands o=
ver the XML command to JobScheduler for execution.
Use with File Transfer jobs
Imple=
mentation
- YADE is extended to pre-process XML snippets from messages that have be=
en received from a queue.
FEATURE AVAILABILITY STARTING FROM RELEAS=
E 1.11
- JMS support is added with YADE-409 - Getting issue de=
tails... STATUS
Star=
ting Situation
The YADE Client reads a configuration from an ini file. The configuratio=
n items are mapped to an Option class. The file transfers are processed.
- The ini file configuration will be replaced with an XML configuration i=
n the future.
- At the time of writing it is only possible to create an XML configurati=
on via the XML Editor. To use the configuration it has to be exported to an=
ini configuration for YADE to use.
Desire=
d Behavior
Extending the YADE Client with a pre-processing functionality.
- The pre-processing starts after the configuration has already been mapp=
ed 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 con=
figuration 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 f=
or 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 f=
ile transfers does not have to be adjusted.
The pre-processing includes to:
- merge the received XML snippet of a YADE configuration into the existin=
g configuration
- determine from the delivered nodes which options have to be changed
- extract the values
- map the extracted values to the relevant options
Prerequisites
The XML snippet has to consist of YADE XML compliant elements.
Use with the JobScheduler Monitoring Interface
Imple=
mentation
- The implementation allows a Message Service to be used in order to forw=
ard notifications to a System Monitor
FEATURE AVAILABILITY STARTING=
FROM RELEASE 1.11
- Support for notifications via Message Services is added with JITL-280 - Getting issue details... STATUS =
References<=
/h2>
Change Management References
Furth=
er Resources
------=_Part_12238_880708074.1711676758710--