| Author |
Message
|
| meena05 |
 Posted: Wed Jun 29, 2016 7:54 pm Post subject: MQ Request-Response query |
 |
|
Apprentice
Joined: 26 Feb 2016
Posts: 39
|
Hi,
I have below scenario for IIB flow
1. Get records from database (unique is KEY)
2. send each database request record to MQ on request queue
3. Receive response on Reply Queue (Request-Reply will be processed by third party application
4. Based on response on reply queue update database to Success or Error (based on KEY value)
5. If reply received then SUCCESS . If reply is not received the ERROR.
How can I check in case I did not receive reply and update KEY record to ERROR? please help with any ideas |
|
| Back to top |
|
 |
| smdavies99 |
| Posted: Wed Jun 29, 2016 10:28 pm Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
Save the MQ MessageId from each output message
Do an MQGET looking for the CORRELID that matched the MQ Message ID that was sent.
This is providing that the applicatino you are sending this to sends the replied with the MQ Message Id it gets from the message it reads as the MQMD.CORRELID
The MQGET can have a timeout set so if nothing is returns before it times out then you have an error.
If the Application you are sending to does not do it then you have to find out how they are proposing to sync the replied with the requests.
MQ Client Server 101 - Chapter 1
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| meena05 |
| Posted: Thu Jun 30, 2016 8:56 am Post subject: |
|
|
Apprentice
Joined: 26 Feb 2016
Posts: 39
|
Thank you so much for your reply.
Yes the Application is mapping Request Message ID to response Correlation ID.
I have my first flow as below
MQ Input Node to trigger process -> Database Select Query (Compute Node) Propagate -> Add MQMD Header -> Store MQMD to local environment -> MQOutput NODE (Request queue) -> Build MQMD message body with Message ID -> MQOutput Node (local Queue ) for caching
Second flow
Reply Queue (MQ Input node) -> Compute node (Out = in) -> MQ Get (On local queue ) Request as InRoot MQMD -> Update database
These two flows are coordinating to see the replies coming up. If the reply does not come back then the messages are sitting on the local queue. In this case how can I handle the unprocessed messages in local queue to update database to ERROR? |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Jun 30, 2016 10:06 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
So you have what is essentially an asynchronous request reply.
Origin and final destination is the database.
So please hold the state in the DB. When extracting the record update it with the messages msgid.
In the second flow process all messages and link the response with the correlid on the message to the messageid saved in the DB.
Assumptions:
The second flow only receives responses to requests originating from the db. 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| meena05 |
| Posted: Thu Jun 30, 2016 10:54 am Post subject: |
|
|
Apprentice
Joined: 26 Feb 2016
Posts: 39
|
Thank you for your reply.
Can I have synchronous REQUEST-REPLY tracked in same message flow? how can I achieve this? |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Thu Jun 30, 2016 10:09 pm Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| meena05 wrote: |
Thank you for your reply.
Can I have synchronous REQUEST-REPLY tracked in same message flow? how can I achieve this? |
Yes.
After getting the records from the DB propagate a compute node that creates an MQ Message and sends it.
So all the selected records end up on a local Q (No the application one)
Add a new part of your flow that reads each message from this queue, created the application message and sends it. MQGET node with timeout to get the reply. Each request/reply to the application will be synchronous and if you don't have an additional instances then everything should be processed in the order it came out of the DB.
Each of these operations is a different (In IIB terms) transaction and isolated from any other one.
There are other ways to do this and I'm sure that someone else will be along to suggest one or more of them.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Jul 01, 2016 4:49 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Using your previous design, put the message on the local queue (caching) with expiry and full report as a request to go to queue 3.
3rd flow, read message set DB in error.
Have fun
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
