| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| MQ Nodes and synch-assynch behavior |
« View previous topic :: View next topic » |
| Author |
Message
|
| saviobarr |
 Posted: Thu Jun 08, 2017 5:53 pm Post subject: MQ Nodes and synch-assynch behavior |
 |
|
Centurion
Joined: 21 Oct 2014
Posts: 100
Location: Sao Paulo, Brazil
|
Hi,
Is it possible to put a message in a queue and wait a response in another queue, keeping the synchronous nature of a message?
The scenario/message flow:
SoapInput node --> MQOutput node --> MQInput node --> SoapReply node. The messagem should reach the SoapReply node only when a message arrives in the MQInput node. Until it occurs, the soap request sent by SoapUI should wait a response from the message flow.
I know it is weird, but I heard it from a co-work. I always learned from the IBM SPVCs that queues breaks the synchronicity.
Thanks in advance
Savio
_________________
Go as far as you can go. Then go farther! |
|
| Back to top |
|
 |
| zpat |
| Posted: Thu Jun 08, 2017 11:52 pm Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
You can't use a MQinput node this way. But you could use a MQget node in this manner.
However it's not really a design best suited to message broker as it would not scale up very well.
Don't wait too long - set a maximum wait in the MQGet node so that you don't hang the flow/EG/Broker if it never replies.
If you separate it into two flows, then MQinput node can be used. But whether you can separate the SOAP reply in another flow is something to check.
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Jun 09, 2017 4:09 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| zpat wrote: |
You can't use a MQinput node this way. But you could use a MQget node in this manner.
However it's not really a design best suited to message broker as it would not scale up very well.
Don't wait too long - set a maximum wait in the MQGet node so that you don't hang the flow/EG/Broker if it never replies.
If you separate it into two flows, then MQinput node can be used. But whether you can separate the SOAP reply in another flow is something to check. |
AFAIK you can but both flows need to be in the same integration service (execution group) and you need to pass the reply token from one flow to the other. 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| saviobarr |
| Posted: Fri Jun 09, 2017 6:58 am Post subject: |
|
|
Centurion
Joined: 21 Oct 2014
Posts: 100
Location: Sao Paulo, Brazil
|
Thank you guys for replying. I'm gonna take your considerations into account and build a POC to validate such solution.
Have a nice weekend
Savio Barros
_________________
Go as far as you can go. Then go farther! |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Jun 09, 2017 7:27 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
I thought there was a sample/template/whatever they're calling them these days that explicitly covered SOAP asynch processing.
Or maybe its was just documented somewhere.
If you're looking for round-trip performance, then using asynch is better, because each outgoing request doesn't have to wait for the previous reply to finish processing.
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
