| Author |
Message
|
| wmbv7newbie |
 Posted: Fri Sep 26, 2014 6:19 am Post subject: Synchronous Webservice call - SOAPInput and SOAPReply node |
 |
|
Centurion
Joined: 13 May 2014
Posts: 121
|
Hi,
I have the following design to implement.
| Quote: |
Flow 1 : Receives a SOAP webservice request [message1] from ERP1, transforms data for processing, writes transformed data [message2] to a queue.
Flow 2 : Receives message2 from the queue, extracts relevant details and writes message3 to another queue.
Flow 3: Receives message3 and calls another webservice, ERP2. Receives response [message4] and writes to queue.
Flow 2 : Receives message4, extracts relevant details and writes message5 to another queue.
Flow 4 : Receives message5, uses data to form a SOAP response and sends response corresponding to message1 received from ERP1. |
All this has to be done synchronously. So I am using SOAPInput and SOAPReply nodes.
My only problem is how to identify the response with the correct request. Do I save the envelope from Flow 1 in some Environment and use it in Flow 4?
I read somewhere to use the below code but am yet to try it -
1) To save reply identifier when you receive request, so that it could be restored before sending response
| Code: |
| SET OutputRoot.XMLNSC.MyBody.MyReplyId = CAST(InputLocalEnvironment.Destination.SOAP.Reply.ReplyIdentifier AS CHARACTER) // for SOAPInput node |
2) To restore reply identifier before sending response
| Code: |
| SET OutputLocalEnvironment.Destination.SOAP.Reply.ReplyIdentifier = = CAST(OutputRoot.XMLNSC.MyBody.MyReplyId AS BLOB) // SOAPReply node |
Any suggestions would help. I am also reading about the same on InfoCentre. Hopefully I will find some hint there. |
|
| Back to top |
|
 |
| Vitor |
| Posted: Fri Sep 26, 2014 6:35 am Post subject: Re: Synchronous Webservice call - SOAPInput and SOAPReply no |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| wmbv7newbie wrote: |
| Do I save the envelope from Flow 1 in some Environment and use it in Flow 4? |
No. The Environment (and LocalEnvironment) are not shared between separate flows; each flow has it's own copy.
The code snippit:
| Code: |
| SET OutputRoot.XMLNSC.MyBody.MyReplyId = CAST(InputLocalEnvironment.Destination.SOAP.Reply.ReplyIdentifier AS CHARACTER) // for SOAPInput node |
and
| Code: |
| SET OutputLocalEnvironment.Destination.SOAP.Reply.ReplyIdentifier = = CAST(OutputRoot.XMLNSC.MyBody.MyReplyId AS BLOB) // SOAPReply node |
will work great if used in a single flow that recieves a webservice, does a lot of stuff and needs to restore the details.
You need to use the same principle, but apply it to a pan-flow storage medium like a shared variable or (on more modern versions) the global cache.
Note that because all the response info will be stored together, you'll need some means of correlating which message5 goes with which original request.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Sep 26, 2014 6:39 am Post subject: Re: Synchronous Webservice call - SOAPInput and SOAPReply no |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| wmbv7newbie wrote: |
| All this has to be done synchronously. So I am using SOAPInput and SOAPReply nodes. |
Nitpickingly, it's not really a synchronous process with WMQ in it. By definition the sender and receiver of a WMQ message are decoupled. I assume you mean "synchronous" in the sense of "has to be completed before the original web service requestor times out".
You'll need to code for scenarios where the MQ response returns late or not at all, i.e. all of the intermediate flows need the ability to retrieve the request id so they can send a SOAP Fault.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| wmbv7newbie |
| Posted: Fri Sep 26, 2014 6:49 am Post subject: |
|
|
Centurion
Joined: 13 May 2014
Posts: 121
|
So if I understand correctly -
1. Have a sort of a correlationID assigned to each request.
2. Save the ID and the ReplyIdentifier on (may be) a shared variable per request.
3. Identify and use both of these while creating the response.
| Quote: |
| Note that because all the response info will be stored together, you'll need some means of correlating which message5 goes with which original request. |
Since I am using synchronous mode, I could clear the shared data after creating my response. Wont that remove the problem of which response corresponds to which original request? |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Sep 26, 2014 6:52 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
ESQL shared variables are not global across different message flows.
They are global across different instances of the same message flow.
Presumably there will be more than one instance of the input flow running at the same time, therefore there must be different sets of request Ids stored at one time. Therefore there must be some way of identifying a given response to a currently in-flight request, without assuming that there's only one request in-flight.
A database is a typical way to solve this problem. |
|
| Back to top |
|
|
| wmbv7newbie |
| Posted: Fri Sep 26, 2014 6:56 am Post subject: |
|
|
Centurion
Joined: 13 May 2014
Posts: 121
|
| Quote: |
| I assume you mean "synchronous" in the sense of "has to be completed before the original web service requestor times out". |
Right. I meant that the calling party is actually waiting for a response after they send the request.
| Quote: |
| You'll need to code for scenarios where the MQ response returns late or not at all, i.e. all of the intermediate flows need the ability to retrieve the request id so they can send a SOAP Fault. |
Agreed. I believe I can save that data on a shared variable, like you said earlier. But I know, a lot of things have to be thought about, since many flows are involved.
For now, we wanted to find out if this could work. If yes, we will get into more depths and details. |
|
| Back to top |
|
|
| wmbv7newbie |
| Posted: Fri Sep 26, 2014 7:08 am Post subject: |
|
|
Centurion
Joined: 13 May 2014
Posts: 121
|
mqjeff
| Quote: |
| Therefore there must be some way of identifying a given response to a currently in-flight request, without assuming that there's only one request in-flight. |
Yes. I missed to think on these lines. Thanks for the direction. We will try with the global cache to save request details with some identifier.
Lets see how this works.
Thanks for all your inputs! |
|
| Back to top |
|
|
| ganesh |
| Posted: Fri Sep 26, 2014 7:22 am Post subject: |
|
|
Master
Joined: 18 Jul 2010
Posts: 294
|
| Quote: |
| We will try with the global cache to save request details with some identifier. |
You could use the MQRFH2 header to store your soap reply identifier. |
|
| Back to top |
|
|
| wmbv7newbie |
| Posted: Mon Sep 29, 2014 2:15 am Post subject: |
|
|
Centurion
Joined: 13 May 2014
Posts: 121
|
@ganesh :
| Quote: |
You could use the MQRFH2 header to store your soap reply identifier. |
This was a brialliant idea. Since I am using all MQ in between the SOAPInput and SOAPReply, I saved the ReplyIdentifier in my MQRFH2.
| Code: |
CREATE LASTCHILD OF OutputRoot.MQRFH2.usr NAME('Response');
SET OutputRoot.MQRFH2.usr.Response.ReplyId = CAST(InputLocalEnvironment.Destination.SOAP.Reply.ReplyIdentifier AS CHARACTER); |
I did some processing in all medieval flows and made sure to keep passing the MQRFH2.
| Code: |
| SET OutputLocalEnvironment.Destination.SOAP.Reply.ReplyIdentifier = CAST(InputRoot.MQRFH2.usr.Response.ReplyId AS BLOB); |
It worked!
I also tried with multiple requests 4-5 at the same time to see if the responses are synchronized. And yes, they were.
However, we are still to consider other scenarios and config details. Please do drop a note if you think we are missing something.
Thanks for your help everybody  |
|
| Back to top |
|
|
| campbela |
| Posted: Mon Sep 29, 2014 6:02 am Post subject: |
|
|
Newbie
Joined: 15 Dec 2011
Posts: 6
|
We have built similar interactions but using HTTP nodes rather than SOAP. As with SOAP, there is a HTTP Reply Identifier which we used as the message id for the first MQ request message. As long as everything in the chain is geared up to passing this back in the responses correlation id you could do it that way.
As for passing other info between seperate request and response flows, we tend to use a cache queue. The request flow will place a message containing all of the required info onto a cache queue using the requests message id. The response flow will retrieve the corresponding cache message using the correlation id from the response message.
Alan |
|
| Back to top |
|
|
|
|
