MQSeries.net :: View topic - Async Integration Pattern

ruimadaleno

Hi all,

we are documenting a pattern to provide guidance to development teams (internal and external) that build applications (message flows) that provide Async integration between information systems.

Here we assume that "target" and "source" information systems cannot communicate with MQ (eg: legacy systems).

A simple diagram shows the building block for this kind of applications:

http://1drv.ms/1ISn3Xj

(jpg file hosted in onedrive)

System A and System B don't have the ability to use message queue (MQ) - comunication is done via web services

System A information is integrated in System B
integration information is enriched with information from "other systems" (this enrichment is optional)

System A information is received via the conector message flow. This conector message flow uses a canonical message format (defined for out environment), however
some information systems cannot use the canonical message format, so these conector can use specialized message formats (example: comunication with legacy systems)

System B information receives the integration information via the dispatcher message flow, it uses a canonical message format. However, if system B cannot
understand/consume the canonical message format, a specialized message format is used (tipical in legacy systems)

Conector message flows puts business data (payload) in Queue (queuein)
messageflows1 .. messageflowsn reads data from queue in , process it, enrich it (optional) and put the resulting payload in queue (queue out)
Dispatcher message flow reads messages from queue out and send business data to system B

(optional) a retry controller message flow uses a retry queue to re-process payloads. This re-process is done n time (configurable max retry value) and
if exceeded , message is put in the error queue. Before putting in the error queue , the exception/error info is recorded in a rfh2 header.

Messages in error queue are analyzed by an operator that decides what should be done to proceceed (put message back to the retry queue, ignore message, contact
specialized/development team for debug and error solving)

A backout queue exists for every application.

Messages in backout queue are analyzed by an operator that decides what should be done to proceceed (put message back to in queue, ignore message)

So, from your experience what can/should be improved/clarified/change in this approach ?
_________________
Best regards

Rui Madaleno