IBM webMethods Hybrid Integration

IBM webMethods Hybrid Integration

Join this online group to communicate across IBM product users and experts by sharing advice and best practices with peers and staying up to date regarding product enhancements.

 View Only
Expand all | Collapse all

MQ Adaptor Architecture Question

  • 1.  MQ Adaptor Architecture Question

    Posted Tue November 02, 2004 05:07 PM

    Hi Guys,

    I am doing a POV at a client site.

    In a nut shell, here what we are doing:

    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 …

    Any ideas are welcome!

    Merci !

    A+


    #webMethods
    #webMethods-Architecture
    #webMethods-General
    #Integration-Server-and-ESB


  • 2.  RE: MQ Adaptor Architecture Question

    Posted Tue November 02, 2004 08:10 PM

    Michael,

    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.

    Just some thoughts,


    #webMethods-Architecture
    #webMethods
    #webMethods-General
    #Integration-Server-and-ESB


  • 3.  RE: MQ Adaptor Architecture Question

    Posted Tue November 02, 2004 08:53 PM

    Thanks !

    A+

    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.

    Merci for your time!

    :slight_smile:


    #webMethods-General
    #webMethods-Architecture
    #Integration-Server-and-ESB
    #webMethods


  • 4.  RE: MQ Adaptor Architecture Question

    Posted Tue November 02, 2004 10:03 PM

    Michael,

    This process is also a nice idea,Thanks for sharing.


    #Integration-Server-and-ESB
    #webMethods-Architecture
    #webMethods-General
    #webMethods


  • 5.  RE: MQ Adaptor Architecture Question

    Posted Wed November 03, 2004 05:02 PM

    Bonjour Michel - Just thinking out loud … I see 3 steps here.

    1. You could use a listener to pick up the insurance claim messages on Queue A.

    2. Trigger service parses msg on Queue A and invokes requestReply MQ Adapter service that interfaces with MF.

    3. You have another listener that listens on MF’s response Queue.

    Hope that helps.
    Rajesh


    #webMethods
    #webMethods-Architecture
    #Integration-Server-and-ESB
    #webMethods-General


  • 6.  RE: MQ Adaptor Architecture Question

    Posted Wed November 10, 2004 08:16 PM

    Thank Rajesh and RMG.

    Another quick question …

    can i request/reply from different queues … say request from queue A and reply to another queue (b) ?

    Can i do the same with the Synchronous listener ? (from queue A and reply into another queue) ?

    merci !!!


    #Integration-Server-and-ESB
    #webMethods-General
    #webMethods-Architecture
    #webMethods


  • 7.  RE: MQ Adaptor Architecture Question

    Posted Thu November 11, 2004 06:01 AM

    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.

    HTH,
    Rajesh


    #Integration-Server-and-ESB
    #webMethods
    #webMethods-Architecture
    #webMethods-General


  • 8.  RE: MQ Adaptor Architecture Question

    Posted Thu November 11, 2004 12:46 PM

    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 ?

    Merci A+


    #webMethods-Architecture
    #webMethods
    #Integration-Server-and-ESB
    #webMethods-General


  • 9.  RE: MQ Adaptor Architecture Question

    Posted Sun November 21, 2004 01:02 AM

    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.

    HTH,
    Rajesh


    #webMethods-Architecture
    #webMethods
    #Integration-Server-and-ESB
    #webMethods-General


  • 10.  RE: MQ Adaptor Architecture Question

    Posted Mon January 24, 2005 09:20 AM

    You can do it like this :

    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.


    #webMethods-General
    #webMethods-Architecture
    #webMethods
    #Integration-Server-and-ESB


  • 11.  RE: MQ Adaptor Architecture Question

    Posted Wed March 16, 2005 05:09 PM

    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).

    Rohit


    #webMethods
    #Integration-Server-and-ESB
    #webMethods-Architecture
    #webMethods-General


  • 12.  RE: MQ Adaptor Architecture Question

    Posted Tue June 21, 2005 08:12 PM

    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.

    HTH


    #webMethods-Architecture
    #webMethods-General
    #Integration-Server-and-ESB
    #webMethods


  • 13.  RE: MQ Adaptor Architecture Question

    Posted Wed December 07, 2005 11:15 AM

    Hi,

    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.

    Thanks & Regards,
    Amit


    #Integration-Server-and-ESB
    #webMethods-Architecture
    #webMethods-General
    #webMethods


  • 14.  RE: MQ Adaptor Architecture Question

    Posted Wed December 07, 2005 03:03 PM

    Amit,

    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.).

    Mark


    #Integration-Server-and-ESB
    #webMethods-General
    #webMethods-Architecture
    #webMethods


  • 15.  RE: MQ Adaptor Architecture Question

    Posted Thu December 08, 2005 06:14 AM

    Hi Mark,

    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.

    Thanks
    Warm Regards,
    Amit


    #Integration-Server-and-ESB
    #webMethods-General
    #webMethods-Architecture
    #webMethods


  • 16.  RE: MQ Adaptor Architecture Question

    Posted Thu December 08, 2005 06:58 AM

    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”.

    Mark


    #Integration-Server-and-ESB
    #webMethods-General
    #webMethods-Architecture
    #webMethods


  • 17.  RE: MQ Adaptor Architecture Question

    Posted Thu December 08, 2005 05:45 PM

    Hello,

    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).

    Thanks.


    #webMethods
    #Integration-Server-and-ESB
    #webMethods-Architecture
    #webMethods-General


  • 18.  RE: MQ Adaptor Architecture Question

    Posted Thu December 08, 2005 07:31 PM

    Eric,

    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?

    Mark


    #webMethods
    #webMethods-Architecture
    #webMethods-General
    #Integration-Server-and-ESB


  • 19.  RE: MQ Adaptor Architecture Question

    Posted Thu July 02, 2009 09:12 PM

    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.

    Your thoughts are appreciated.


    #webMethods-Architecture
    #Integration-Server-and-ESB
    #webMethods
    #webMethods-General


  • 20.  RE: MQ Adaptor Architecture Question

    Posted Wed July 08, 2009 11:59 AM

    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.

    Regards,
    Senthil


    #webMethods-Architecture
    #webMethods-General
    #Integration-Server-and-ESB
    #webMethods