| Author |
Message
|
| Konrad |
 Posted: Tue Nov 04, 2008 12:12 am Post subject: WMB MQOutput invalid destination list |
 |
|
Newbie
Joined: 04 Nov 2008
Posts: 5
|
Hey guys,
I have a problem with a pretty simple message flow where I want to use a destination list at the output node.
MQInput ---> Compute ---> MQOutput
The compute node looks like the following and the MQOutput's destination mode is set to destination list:
| Code: |
CREATE COMPUTE MODULE FAST_ServiceResponseFlow_Compute
CREATE FUNCTION Main() RETURNS BOOLEAN
BEGIN
CALL ChangeDestinationQueue();
RETURN TRUE;
END;
CREATE PROCEDURE ChangeDestinationQueue()
BEGIN
SET OutputRoot = InputRoot;
SET OutputLocalEnvironment.Destination.MQDestinationList.DestinationData[1].queueName = 'ADV.RESPONSE';
SET OutputLocalEnvironment.Destination.MQDestinationList.DestinationData[1].queueManagerName = 'WBRK61_DEFAULT_QUEUE_MANAGER';
END;
END MODULE; |
At runtime I get the following exception. Any ideas what may be wrong?
the queue and the queue manager do exist
| Code: |
MessageException
File:CHARACTER:F:\build\S610_P\src\DataFlowEngine\ImbMqOutputNode.cpp
Line:INTEGER:942
Function:CHARACTER:ImbMqOutputNode::handleListMessage
Type:CHARACTER:ComIbmMQOutputNode
Name:CHARACTER:FAST_ZipCodeServiceResponseFlow#FCMComposite_1_2
Label:CHARACTER:FAST_ZipCodeServiceResponseFlow.MQOutput
Catalog:CHARACTER:BIPv610
Severity:INTEGER:3
Number:INTEGER:2665
Text:CHARACTER:Invalid destination list
Insert
Type:INTEGER:2
Text:CHARACTER:-1
Insert
Type:INTEGER:5
Text:CHARACTER:MQW005
Insert
Type:INTEGER:2
Text:CHARACTER:0
Insert
Type:INTEGER:5
Text:CHARACTER:
|
Thanks in advance |
|
| Back to top |
|
 |
| Subha |
| Posted: Tue Nov 04, 2008 1:03 am Post subject: WMB MQOutput invalid destination list |
|
|
Apprentice
Joined: 14 Nov 2006
Posts: 33
Location: Toronto
|
It appears that you did not choose "Local Environment and Message" for "Compute mode" property of Compute Node.
Please check the compute node properties you have configured.
Thanks,
Subha
_________________
Subh |
|
| Back to top |
|
|
| Konrad |
| Posted: Tue Nov 04, 2008 6:33 am Post subject: |
|
|
Newbie
Joined: 04 Nov 2008
Posts: 5
|
You're right. Thank you!
Another question regarding message flows:
I have a request flow as the counterpart to this response flow where I 'move' requests from different consumer interfaces to the request queue of one specific service.
After the request is executed by the service it goes to the above listed response flow where I have to 'move' the service' response from to the right consumer interface.
My problem is how do I know or how do I memorize which message belongs to which consumer. Is there a best practise for this since I guess this is a pretty common scenario.
Thanks,
Konrad |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Nov 04, 2008 7:06 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
You could specify a reply queue.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Konrad |
| Posted: Wed Nov 05, 2008 12:18 am Post subject: |
|
|
Newbie
Joined: 04 Nov 2008
Posts: 5
|
What do you mean by reply queue?
Maybe I should explain it in more detail. I have two applications and each one has one request and one reply queue. Further on I have one service which is used by both applications with one request and one response queue as well.
The messages from the application request queues are transfered to the service request queue by a message flow in which I guess I have to store the message id as well as the application the request comes from. I need that information in the second flow which transfers the service response to one of the applications depending on which application send the request.
| Code: |
APP1.REQUEST ---->
----> | Message Flow | ----> SERVICE.REQUEST
APP2.REQUEST ---->
APP1.RESPONSE <----
<----| Messaqe Flow | <---- SERVICE.RESPONSE
APP2.RESPONSE <---- |
My question is what is the best way to store this information? |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Nov 05, 2008 2:44 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Konrad wrote: |
What do you mean by reply queue?
|
I meant that if the message originates from APP1.REQUEST specify a reply queue of APP1.RESPONSE and so forth. Either the app can do this, or it can be done by your flow.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| hopsala |
| Posted: Wed Nov 05, 2008 5:20 am Post subject: |
|
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
| Konrad wrote: |
| I have two applications and each one has one request and one reply queue. Further on I have one service which is used by both applications with one request and one response queue as well. |
I'm not sure I understand your requirement, but this seems like a pretty odd design pattern to me. There is no such thing as a "response" queue, as it is not needed. If you have 2 applications and 1 flow, all you need is four queues - APPL1.INPUT, APPL2.INPUT, FLOW1.1TO2 and FLOW1.2TO1 (illustrative names, shouldn't be used as a standard).
In order to match a reply to a specific request, simply store the MsgId of the request in one direction (key- MsgId, data- replyToQ), and match it to the CorrelId on the way back to retrieve the replyToQ. How should you store it? If you write in Java, use a hashmap and a singelton pattern. If you write in ESQL use a SHARED ROW variable. |
|
| Back to top |
|
|
| Konrad |
| Posted: Thu Nov 06, 2008 12:47 am Post subject: |
|
|
Newbie
Joined: 04 Nov 2008
Posts: 5
|
It probably looks odd because I've tried to simplify the whole thing.
Our broker has been splitted into two parts.
First, a consumer interface where the applications have its request and response queue with which they can call all available services. (There is a message flow beyond each request queue which determines the service the request is for and transfers the message to the right service facade)
The service facade is the second part of the broker where each service has its interface (request and response queue) and a message flow beyond it which transfers the message to the actual service.
So it looks like that:
| Code: |
consumer interface service facade
APP1.REQUEST -> | message flow |
APP2.REQUEST -> | message flow |
-> SRV1.REQUEST -> | message flow | ->
-> SRV2.REQUEST -> | message flow | ->
...
| actual |
| service 1-n |
<- | message flow | <- SRV1.RESPONSE <-
<- | message flow | <- SRV2.RESPONSE <-
...
APP1.RESPONSE
APP2.RESPONSE
... |
My problems are the message flows of the service facade where I want to store the msgid and the app at the request flow and retrieve the msgid and app at the response flow to determine the application response queue.
As far as I know the scope of shared variables are limited to its message flow and this doesn't work for me since I have to use two flows for every service. |
|
| Back to top |
|
|
| Subha |
| Posted: Thu Nov 06, 2008 12:57 am Post subject: |
|
|
Apprentice
Joined: 14 Nov 2006
Posts: 33
Location: Toronto
|
You can try using MQRFH2-usr folder of MQ message. Sending application can define properties in it.
_________________
Subh |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Nov 06, 2008 2:27 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Subha wrote: |
| You can try using MQRFH2-usr folder of MQ message. Sending application can define properties in it. |
Or pass context with a Reply queue set in the MQMD (I dislike letting go of an idea  )
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| hopsala |
| Posted: Sat Nov 08, 2008 4:20 am Post subject: |
|
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
It still seems to me that you've got the wrong design and name convention. The names should be something that denotes the queues as the input to some service, not according to requester. Since many applications can send a request to Serv1, it is senseless to create a queue for each; rather you create one service queue and call it Serv1 (or consumeServ1 in the backend).
In short, queues are input queues, not request or reply or anything else. What's a reply if not a message in your input[/] queue, and what's a request if not a message in someone else's [i]input queue?. One does not create a service per requesting application, but a general service that can service (haha) whoever calls it; thus each service has one input queue, and each client has one input queue, nothing more. If you use this paradigm, things will become much simpler.
(end rant)
| Konrad wrote: |
| As far as I know the scope of shared variables are limited to its message flow and this doesn't work for me since I have to use two flows for every service. |
Note that if you use Java nodes and a singleton pattern, data in the singelton can be shared between flows in the same execution group, since each execution group is a JVM. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sat Nov 08, 2008 6:27 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Bad Idea on each side.
Back to the design board.
From what Konrad showed he has in fact 2 flows dealing with request/reply.
I will make the assumption here that each flow (consumer interface and service facade) has an MQInput node, an MQOutput node, an MQGet node and an MQReply node.
So each flow should keep the state in it's Environment.
Use SET Environment.original = InputRoot; at the beginning of the flow and the MQMD from the input queue is available before using the MQReply node to set all the parameters as needed....
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
