Synchronous communication: webservice-MSMQ-NAS.

Hi, I am investigating providing realtime two way communication between a webservice and navision. The option I am particularily interested in using is MSMQ and the NAS. I have been piecing together information found on this forum, the product CD and msdn. For synchronous communication a reasonable example can be found here… (only reasonable - it appears to get the diagram wrong at the top of the article.) …however this example does not take into account the possibility of multiple different users making requests simultaneously. This needs to be handled using the Id property (lets call this GUID_IN) of the incoming message. Then, the reply message sent (on a different message queue) must assign the CorrelationId property := GUID_IN. This enables the requester to peek or to receive where CorrelationId=mysentmessage.Id PROBLEM: It would seem that the MSMQ bus adapter provided on the product cd does not go far enough in exposing MSMQ message properties to enable the Navision programmer to set this correlationid property or read the incoming id property. It seems that this must have become an issue when Commerce Portal was developed so they answered this issue with the CPhandler’s ability on receiving a message to extract this Id from the incoming message and append it to the incoming xml. QUESTIONS: 1. Does CP handle setting the CorrelationId property of the reply message if there is a GUID node on the outgoing message? 2. Since CP is no longer shipped since v4 it seems to me that using the CP handler dll is not a viable option anyway (suggested in another thread for incoming messages). 3. So is the answer to write our own extended bus adapter and comcom objects? Any opinions/answers greatly appreciated as ever [8D] Jon

Hi Jon, This is what I would do: 1. Write my own MSMQ handler (.NET) 2. Create a new reply queue for every unique request (programmatically). 3. Use the ReplyQueue property (I think that is the right name) of the MSMQ message and have it point back to the unique MSMQ. Also consider using XMLHTTP (included in IE) for making the request on the client side in order to avoid having to install the assembly/dll on every workstation. /Bruno

Hi Bruno, thanks for that, further questions if I may… So the requestor passes an instruction/value that is used by my app to dynamically create the reply msmq? How else would the requestor know where to listen for its reply? Are you suggestions based on a very flexible solution that any website could communicate with my back end application? I would have thought if its my website and my back end system i can always look for a reply on the same reply Q and with the ability to use CorrelationId, there will no no issues with any delays. Jon