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

Compare with Current View Page History

« Previous Version 8 Next »

Introduction

  • Message Queue Services are a common means for Enterprise Application Integration (EAI). Users who operate a Message Queue Service want to integrate their applications with JS7. Patterns for EAI include:
    • applications sending requests to add orders to workflows using the JS7 - REST Web Service API.
    • applications receiving processing results from jobs and workflows executed by JS7.
  • EAI scenarios provide the following advantages:
    • reduction of complexity:
      • at the topological level each application implements only one interface to the Message Queue Service.
      • of error handling as a Message Queue Service is considered to be highly available.
    • centralized management of messages.
  • The JMS integration scenario includes a separate Java-based consumer which is implemented in order to receive and parse messages and to translate messages into requests to add orders. Reasons for this approach include:
    • JMS is standardized. However, the content and format of messages requires individual parsing.
    • JS7 offers a JSON based REST Web Service API that can be used by any consumer to add orders using REST API calls.

Use with Generic Jobs

Implementation

  • The implementation is independent of the JS7 release and consists of Java examples that are separately available, see the references below.

Scenario 1: Detached JS7 JMS Interface

1. Use Case

  • An application makes use of the JS7 REST Web Service API to start a workflow.

2. Producer

  • Creates a text message in JSON format for the queue "Workflows". The content of the message could be, for example:
    {"controllerId":"testsuite","orders":[{"workflowPath":"/JS7Demo/01_HelloWorld/jdHelloWorld","scheduledFor":"now"}],"auditLog":{}}
  • Sends the message to the specific queue.

3. Consumer

  • Reads a message from the queue „Workflows" and sends the JSON body using the JS7 REST Web Service API.

Scenario 2: Generic JS7 JMS Interface

1. Use Case

  • A Java job runs in a workflow and implements the Producer to send information to the Message Queue Service after completion of a number of JS7 - Job Instructions in a workflow.
  • A Java job runs in a workflow and implements the Consumer, i.e. connects to the Message Queue Service to check for new messages that include parameters for adding orders to JS7.
  • The Producer as well as the Consumer can run in any workflow.

2. Producer

  • Producer:
    • A job sends some information to a Message Queue to signal completion of a workflow.

3. Consumer

  • Consumer:
    • Reads JS7 REST Web Service API body from a message in JSON format and hands over the JSON body to a JS7 REST Web Service API call for execution.

TBD: Use with File Transfer jobs

Implementation

  • YADE is extended to pre-process XML snippets from messages that have been received from a queue.
    FEATURE AVAILABILITY STARTING FROM RELEASE 1.11  
  • 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:

  • merging the received XML snippet of a YADE configuration into the existing configuration:
    • determining which options have to be changed from the nodes that are delivered
    • extracting the values
    • mapping the extracted values to the relevant options

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

Use with the JS7 Monitoring Interface

Implementation

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

Resources


  • No labels