We are receiving claims (insurance) from MQ (queue A). We need to pick it up (in wM) and then parse it – map it and send it to another queue on the MF.
Then wait for the responses and map it back to an XML document and send it back to the original application that is waiting for the reply (on another queue).
We have setup wM MQ Adaptor listener on the inbound queue (queue A) – that picks up the original request.
We have IBM MQ peoples ask if it is possible to call our webMethods MQ Adaptors listener directly … instead of have it « listener» ….
The reason, is we would like to avoid the polling of the queue (from the listener) … instead we will like to trigger wM when ever there is a message in the queue …
As far i know there is no such option other than configuring a webMethods MQ Adapter Listen handler,so that this will trigger when ever there is a message put in the queue and delivers to IS/Broker (pub/sub)and pass it to a IS Service this is the architecture of latest MQ Adapter6.0.
PS: When a message will be put in a queue, we will use a JAVA stub (from the MQ application) that will push a dummy document in the broker and in turn will trigger a FS that will read or peek the queue for processing.
Michel - The answer to your first question is “yes”. We have implemented this in our requestReply adapter service. And if I understand your second question correctly (listen on Queue A, do some data transformation to the message from Queue A, then put the transformed message on Queue B), the answer is “yes” here also. I have done this too, though I don’t recall if the listener was Synchronous.
According to the documentation (MQ Adaptor User Guide), unless i misinterpret, but it seem that the request/reply AND the listener (synch) are attached to the same queue … so request from queues A (put) and reply (wait) from the same queue (A).
Do you remember how to set the inbound queue and outbound queue ? So if want to request from (A) and wait (reply) in queue (B), i need to set the msgheader ?
Bon soir Michel - There is a nice diagram and a run-time processing discussion of the RequestReply service on pages 29 through 32 of the MQ Adapter v6.0 Users Guide.
As for setting the queue names, I believe the Request queue is defaulted to the the queue we specify in the non-transactional connection object. The Reply queue is read in via a property file which populates the ReplyToQueue parameter.
Create one remote sending queue in your side, which put data in a local queue in IBM MF side.
Create one remote queue in IBM MF side which put data in your reciving local queue.
Create a request reply handler from WM MQ adapter.
so when u put a message it will go directly to IBM MF and when reply come from MF it will come directly to you.
I am not sure if Michel is still looking for the answer to his question (replying on a different queue)… but just for the benefit of others who might come looking for an answer to the same question in future - The name of a queue or a queue manager may be changed in an adapter service at the run time using the connection’s overrideConnection property. This property is available in the input of the adapter services for Put, Get, Peek and Request/Reply.
This feature is available in version 6.0 of MQ Adapter (I am not sure about the earlier versions).
Hi,
We do the same thing here… we get the xml data from a MF queue,we parse it according to business rules and put it back on the MF queue.
We did not use a broker in our architecture.We use the “get” and “put” adapter services.The get service runs in a loop based on the flag we use.It gets the data from the MF queue.If there is no data it does not fetch anything.It does a destructive get.
I am implementing Edi tranformaion using MQ adapter having MQ on both sides of Integration server. How should i code & configure for it.
Please let me know about the design of applications and pre defined flow services to be used in the development.
your urgent help is appreciated. Thanking You in advance.
The fastest way to do this is by using the webMethods Websphere MQ Adapter to get and put messages from MQ queues and, optionally, to create notifications that publish documents to the IS when messages arrive on an MQ queue.
You can also create java services that use the MQ API to interact directly with MQ queues, but that is much more work and does not provide the advantages of the ART architecture (connection pooling, notifications, etc.).
Thanks for your response. I understood your method. Can u please help me more details about how to implement and where can i find the get/put/peek services etc. I wud be really thankful if you can help me with a detailed document if possible.
You can find the detailed document on webMethods Advantage in the Bookshelf section or in your MQ Adapter’s \doc folder. It’s called the “webMethods Websphere MQ Adapter User’s Guide”.
Another option is have that MQ user exit program, send message directly to Broker via JMS. Then on IS, have a trigger looking for message on Broker, which fires a flow service to do the needful via MQAdapter(Request/Reply). This way you could avoid the listener/notifier(i.e. polling of MQueues).
I agree that this will work, but if an organization had not yet configured a JMS provider that would represent another “moving part”.
Also, isn’t that just replacing one listener/notifier (MQ) for another (BrokerJMS)? Or does the BrokerJMS listener register callbacks on JMS queues without polling that queue?
From a development perspective, is it a good practice to use the “overrideConnection” option in an MQ PUT?
Here’s the scenario: wM connects to an MQ Queue Manager that hosts about 15 queues we need. I’m wondering if it’s better to create a single wM MQ connection to that single Queue Manager; or create 15 different wM MQ connections which specify the 15 different queue names in each of the connection objects?
If we use a single wM MQ connection, I guess that would force our code to specify the queue name which would have to be either hard-coded or retained in some table or property file. The advantage of using a single wM MQ connection is that we’d have fewer connections to maintain.
There should not be performance issues either way you configure, both can get lots of data processed quickly. So your single connection could be allowed to have 15 threads, equaling the 15 different queues you are accessing.
Individual connections are more administration overhead but they make it easier for a support person to tell what service was calling the connection and why they were calling it.
Shared connections are less administration and allow more developer control of the process.
