Author |
Message
|
sunny_30 |
Posted: Tue Feb 24, 2015 6:38 pm Post subject: soapReply & ReplyIdentifier |
|
|
 Master
Joined: 03 Oct 2005 Posts: 258
|
Have a question reg whether its the ReplyIdentifier thats internally used by Broker to correlate which webclient socket the soap response gets sent to.
If the value in the 'LocalEnvironment.Destination.HTTP.RequestIdentifier' is lost before the soapReply is processed, is there a risk that the response might get sent to a different requestor (tcp/ip socket) ? |
|
Back to top |
|
 |
fjb_saper |
Posted: Wed Feb 25, 2015 6:48 am Post subject: Re: soapReply & ReplyIdentifier |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
sunny_30 wrote: |
Have a question reg whether its the ReplyIdentifier thats internally used by Broker to correlate which webclient socket the soap response gets sent to.
If the value in the 'LocalEnvironment.Destination.HTTP.RequestIdentifier' is lost before the soapReply is processed, is there a risk that the response might get sent to a different requestor (tcp/ip socket) ? |
Chances are that without it you will not be able to send a reply at all.  _________________ MQ & Broker admin |
|
Back to top |
|
 |
Simbu |
Posted: Wed Feb 25, 2015 7:46 am Post subject: Re: soapReply & ReplyIdentifier |
|
|
 Master
Joined: 17 Jun 2011 Posts: 289 Location: Tamil Nadu, India
|
sunny_30 wrote: |
Have a question reg whether its the ReplyIdentifier thats internally used by Broker to correlate which webclient socket the soap response gets sent to.
If the value in the 'LocalEnvironment.Destination.HTTP.RequestIdentifier' is lost before the soapReply is processed, is there a risk that the response might get sent to a different requestor (tcp/ip socket) ? |
I think if a message flow contain both SOAPInput and SOAPReply then it will work even without retaining RequestIdentifier. |
|
Back to top |
|
 |
ganesh |
Posted: Wed Feb 25, 2015 1:37 pm Post subject: |
|
|
Master
Joined: 18 Jul 2010 Posts: 294
|
If you loose the reply identifier then you cannot send a soap reply back, for example you have a flow where there is a change in the transport protocol before sending a soap reply in that case you would loose the reply identifier. In such scenarios store the reply identifier in a environment variable and use it for the soap response later. |
|
Back to top |
|
 |
mgk |
Posted: Wed Feb 25, 2015 11:37 pm Post subject: |
|
|
 Padawan
Joined: 31 Jul 2003 Posts: 1642
|
As long as the reply is made from the same flow instance as the request arrived on then it does not matter if the ID is "lost". The ID only need to be set when switching the reply to another flow, in which case if the ID is not set then an exception will be thrown to say "no ID", but it will not send the reply to the wrong socket (client).
Kind regards, _________________ MGK
The postings I make on this site are my own and don't necessarily represent IBM's positions, strategies or opinions. |
|
Back to top |
|
 |
sunny_30 |
Posted: Thu Feb 26, 2015 10:05 am Post subject: |
|
|
 Master
Joined: 03 Oct 2005 Posts: 258
|
Great! Thanks all. I had noticed where if in the same flow it has soapInput+Reply, it doesnt throw an error if the ID isnt set (but I do have it set all the times). Wondered how it impacts correlation. Looks like its already internally taken care of ! |
|
Back to top |
|
 |
ganesh |
Posted: Thu Feb 26, 2015 10:30 am Post subject: |
|
|
Master
Joined: 18 Jul 2010 Posts: 294
|
ganesh wrote: |
If you loose the reply identifier then you cannot send a soap reply back, for example you have a flow where there is a change in the transport protocol before sending a soap reply in that case you would loose the reply identifier. In such scenarios store the reply identifier in a environment variable and use it for the soap response later. |
I stand corrected from my earlier comment.
If you have a soap reply in the same flow then the reply is sent to the correct client regardless of whether you loose the id or not as mentioned by others.
I tried deleting the local environment tree but still the reply was sent to the correct client. |
|
Back to top |
|
 |
|