Anypoint Platform and Mule ESB convergance

I got introduced to Mule ESB and Anypoint Platform by my colleagues who already work using the tools in a project. Initially I paid no attention but as I decided to add this popularly emerging skill-set to my stack -- day by day I am more impressed with the way Mulesoft's approach towards integration and SOA.

The way it is organised and the simplicity in handling complex matters are really interesting.

The tooling stack really is designed to conceive any business of any scale from the decision making phase - to - design phase -to - implementation -to- service management.

At each step it seems to support different users flavor including end user to business analysts and developers which I hope is well suited for agile mode of development.

This technology stack is something that brings all sort of stakeholders on a single platform integrated and allow collaboration.

Queue Manager Hoping in IBM MQ Using IBM BPM Advanced Process Server

Queue Manager Hoping in IBM MQ Using IBM BPM Advanced Process Server

Introduction:

This document talks about how to achieve Queue Manager hoping for IBM MQ using and ESB mediation component which is developed in IBM BPM Advanced Process Server.

Systems Involved

IBM BPM Advanced Process Server v8.5

IBM Integration Developer v8.5

IBM MQ

Assumptions

-          The local Queue Manager has a transmission Queue with the same name as of Remote Queue Manager.

Reference

-          http://www-01.ibm.com/support/knowledgecenter/SSFTBX_8.5.0/com.ibm.wbpm.main.doc/topics/esbprog_bindings_wmq4.html

Context

There will cases when applications may want to connect to one queue manager in IBM MQ and put message into local queue of another queue manager. This document explains how we do that using an ESB mediation component.

Scenario

Here we talk about two queue managers QM1 and QM2. Queue manager QM1 must have a transmission queue named with the same name as of the remote queue manager which in this case is QM2.

QM2 has a queue named TargetQ to which the client application wants to put messages into. The application is going to connect to QM1.

In case of a pojo client we have to use like below:

MQQueue targetQ =                                 qMgr.accessQueue("TargetQ",                                                                                 openOptions,                                                                                 "QM2",                                                                                           null,                                                                                       null);

Solution

Create a Module using IID. The module could either be a Mediation Module or a Module. This solution revolves around implementation of a mediation component where we will have the ‘callout’ primitive used with ‘Use dynamic endpoint if set in the message header’ as in the figure below.

Use a XSLT map or a BO map so that we access the SMO Headers for the target interface which is set as the Partner interface for MQ Import.

Map the wires into smo->headers->SMOHeader->Target->address. The value should be in the below form:

wmq:/msg/queue/<Target Queue Name>@<Target Queue Manager Name>

In this case it has to be: wmq:/msg/queue/TargetQ@QM2.

See below the SMO structure as seen in the map.

One after this, you can try testing this module to see whether the message is going into the TargetQ.