| Author |
Message
|
| Herbert |
 Posted: Fri Dec 18, 2009 5:41 am Post subject: SOAP.Reply.ReplyIdentifier to MQMD.MsgId ? |
 |
|
Centurion
Joined: 05 Dec 2006
Posts: 146
Location: Leersum, The Netherlands
|
Hi,
Is there a definition of the LocalEnvironment.Destination.SOAP.Reply.ReplyIdentifier field?
With debugging I see it is a hex string of 48 long. This can be converted to a 24 long BLOB for MQMD.MsgId or MQMD.CorrelId. Or is this a bad idea?
Kind Regards, Herbert |
|
| Back to top |
|
 |
| amiivas |
| Posted: Fri Dec 18, 2009 1:56 pm Post subject: |
|
|
Apprentice
Joined: 14 Oct 2007
Posts: 44
Location: Texas, USA
|
Hi,
As you might be knowing, replyIdentifier is the most important field for a reply node either be a httpreply or soapreply node for replying the output of an http input. Even the path is important as this is only way to identify the source of the request.
Now why do you need it as MsgID or CorrelID which have their own specific purpose.
Thanks,
Amit |
|
| Back to top |
|
|
| Herbert |
| Posted: Sat Dec 19, 2009 1:43 am Post subject: |
|
|
Centurion
Joined: 05 Dec 2006
Posts: 146
Location: Leersum, The Netherlands
|
| amiivas wrote: |
As you might be knowing, replyIdentifier is the most important field for a reply node either be a httpreply or soapreply node for replying the output of an http input. Even the path is important as this is only way to identify the source of the request.
Now why do you need it as MsgID or CorrelID which have their own specific purpose. |
My scenario is that I want to wrap SOAPinput and SOAPreply asynchronous around a existing MQ service.
flow 1: SOAPInput ..... MQoutput
flow 2: MQinput .... SOAPReply
Is this scenario I need to store/restore this identifier. I do get the MsgId from the MQoutput node back as CorrelId on the MQinput, this would be a quick solution, without asking for a interface change, or using a MQ queue, ...
Kind Regards, Herbert |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sat Dec 19, 2009 5:45 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
You may need to run an aggregation pattern passing the soap reply information to the aggregation
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| amiivas |
| Posted: Sat Dec 19, 2009 8:34 am Post subject: |
|
|
Apprentice
Joined: 14 Oct 2007
Posts: 44
Location: Texas, USA
|
| Quote: |
My scenario is that I want to wrap SOAPinput and SOAPreply asynchronous around a existing MQ service.
flow 1: SOAPInput ..... MQoutput
flow 2: MQinput .... SOAPReply |
Yes you need to store the reply identifer, and then need to restore it back for SOAPReply node. If there is a transaction boundary, what I suggest is store the reply identifier from the LocalEnvironment.Destination.SOAP.Reply.ReplyIdentifier to MQRFH2.usr folder [Header information] pass it along the MQInput-MQOutput flow and then restore it in the main flow.
MsgId and correlId is useful when there are multiple message processing at a single time and u need to co-relate them
There are other ways also to store the reply identifier, let me know if above solution works.
-Amit |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Sat Dec 19, 2009 9:54 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| Quote: |
If there is a transaction boundary, what I suggest is store the reply identifier from the LocalEnvironment.Destination.SOAP.Reply.ReplyIdentifier to MQRFH2.usr folder [Header information] pass it along the MQInput-MQOutput flow and then restore it in the main flow.
|
Using the MQRFH2 header method will only work if you can guarantee that the app that receiveds your message and sends the reply will know what to do with the header. There is a good chance that if it is a legacy app then it will get thrown away.
Using the aggregation approach (as has been discussed here) will allow you save everything you need in an MQ message that is retrieived as part of the aggregation.
_________________
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 |
|
|
| Herbert |
| Posted: Mon Dec 21, 2009 11:04 pm Post subject: |
|
|
Centurion
Joined: 05 Dec 2006
Posts: 146
Location: Leersum, The Netherlands
|
| smdavies99 wrote: |
| Using the MQRFH2 header method will only work if you can guarantee that the app that receiveds your message and sends the reply will know what to do with the header. There is a good chance that if it is a legacy app then it will get thrown away. |
Indeed, I was looking for a solution that did not involve changing the existing interface/app.
I do get the MQMD.MsgId back as MQMD.CorrelId and it looks like that the LocalEnvironment.Destination.SOAP.Reply.ReplyIdentifier field is a hex string of 48, perfect to change into MQMD.MsgId ... |
|
| Back to top |
|
|
| Herbert |
| Posted: Mon Dec 21, 2009 11:21 pm Post subject: |
|
|
Centurion
Joined: 05 Dec 2006
Posts: 146
Location: Leersum, The Netherlands
|
| fjb_saper wrote: |
You may need to run an aggregation pattern passing the soap reply information to the aggregation
Have fun |
Nice solution, thanks for the tip. |
|
| Back to top |
|
|
| SANTYP |
| Posted: Tue Dec 22, 2009 12:26 am Post subject: |
|
|
Centurion
Joined: 27 Mar 2007
Posts: 142
|
| smdavies99 wrote: |
Using the aggregation approach (as has been discussed here) will allow you save everything you need in an MQ message that is retrieived as part of the aggregation. |
How it works,..? |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Tue Dec 22, 2009 1:00 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| SANTYP wrote: |
| smdavies99 wrote: |
Using the aggregation approach (as has been discussed here) will allow you save everything you need in an MQ message that is retrieived as part of the aggregation. |
How it works,..? |
Put everything you want to preserve into an MQ Message and send it out as part of the aggregation fan-out. This branch uses the name of the Aggregation fan-in queue as its destination. Then it all gets synced together as part of the fan-in
Read up on the Aggregation nodes and how they work.
_________________
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 |
|
|
| Santosh_Ghalsasi |
| Posted: Mon Aug 20, 2012 5:28 am Post subject: More complexity in this scenario |
|
|
Novice
Joined: 01 Feb 2011
Posts: 19
|
Hi,
I also have same kind of scenario with some more complaxities.
The flows structure is as below
Flow 1 - SOAPInput Node--> MQOutput Node
Flow 2 - MQInput Node--> SOAPReply Node
Below are the points for more clear idea -
1. These flows are deployed on two brokers say MB1 and MB2
2. The brokers use queue managers say MQ1 and MQ2 respectively.
3. There is a Gateway queue manager say GQ which is interacting with all external applications that connect to MB layer.
4. MQ1, MQ2 and GQ are in a cluster and GQ being a full repository and rest are partial.
5. The request message comes in SOAPInput Node(web service). That message is transformed and sent to an external application for further processing using MQOutput node in Flow 1. MQOutput node puts request on the queue residing on GQ.
6. External application processes that request and puts the response on a queue which is residing on both MQ1 and MQ2 and its a cluster queue(Cluster does the load balancing to send the responses to either queue in round robin fashion).
7. The response message is taken by MQInput Node of Flow 2 and the reply is sent via SOAPReply Node.
Now the issue is
Once the application hitting the web service sends a request, it waits for the response on the same thread, say either on broker-1 or broker-2. But it may happen that the broker on which the request is landed may not receive the processed response (cluster might route that response to the queue on other broker) and might keep waiting forever.
Please let me know if anything can be done so that the reply should land back on the broker from which the request has been sent.
Thanks, |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Mon Aug 20, 2012 5:29 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
|
| Back to top |
|
|
| Santosh_Ghalsasi |
| Posted: Mon Aug 20, 2012 5:36 am Post subject: |
|
|
Novice
Joined: 01 Feb 2011
Posts: 19
|
| I will open a new one. Thanks. |
|
| Back to top |
|
|
|
|
