| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Dynamically Routing the message to approprate Sub-flow |
« View previous topic :: View next topic » |
| Author |
Message
|
| r1divya |
 Posted: Fri Jun 28, 2002 11:50 pm Post subject: Dynamically Routing the message to approprate Sub-flow |
 |
|
Newbie
Joined: 19 Jun 2002
Posts: 4
|
I am trying to develop message flows for different transactions. Now for each transaction , the format of the message and thus type is different. But all these messages are picked from the same Input Queue. The transaction type information is available in the message body. Also I can't parse the Input message using MRM parser and specifying the message set and messaege type etc. in the Input Node.
My requirement is that , i should be able to pick up the message , look at the transaction type and route it to the appropriate subflow ( each transaction has seperate subflow as transformation rules are different). One way of doing this could be to use filter node and based on the transaction type send it to the appropriate sub-flow. The number of transactions is quite large. Is there any way to accomplish it using the Primitive nodes available? BTW , the input message is either in XML format or CWF format. |
|
| Back to top |
|
 |
| CodeCraft |
| Posted: Sat Jun 29, 2002 2:05 am Post subject: |
|
|
Disciple
Joined: 05 Sep 2001
Posts: 195
|
The question you have to ask is, what piece of information in, or about, the message lets you identify the transaction type.
Without parsing, you should be able to examine some portion of the incoming BLOB to see does it contain a specific piece of information.
Where in the various messages is the transaction type identified?
You could also consider have something at the source add an RFH2 and put something in the "usr" field which makes your life easier.
What is it that ties you to using one input queue for all message types? |
|
| Back to top |
|
|
| kirani |
| Posted: Sat Jun 29, 2002 7:47 pm Post subject: |
|
|
Jedi Knight
Joined: 05 Sep 2001
Posts: 3779
Location: Torrance, CA, USA
|
I did something similar. We use to get different record types in CWF format on input queue. MQInput node was configured to read messages AS BLOB. By looking at some field (in BLOB domain) in input message we route to different paths dynamically using RouteToLabel node. After we determine what type of message it is, we parse the message using appropriate MRM message set/message type.
_________________
Kiran
IBM Cert. Solution Designer & System Administrator - WBIMB V5
IBM Cert. Solutions Expert - WMQI
IBM Cert. Specialist - WMQI, MQSeries
IBM Cert. Developer - MQSeries
|
|
| Back to top |
|
|
| r1divya |
| Posted: Sat Jun 29, 2002 11:50 pm Post subject: |
|
|
Newbie
Joined: 19 Jun 2002
Posts: 4
|
Thank you "CodeCraft" and "Kirani" for a quick response.
In our case, the information about the transaction type is in the application header ( which is common set of fields in the message body for all the messages).
In case I read the message as BLOB at the input node, where exactly in the flow ( I mean which node )and how I can parse the input message using the MRM message type.
The input queue is only one as per the current design. However you could have more input queues each servicing a set of transactions. However, having seperate input queues for each transaction type may not be feasible. |
|
| Back to top |
|
|
| CodeCraft |
| Posted: Sun Jun 30, 2002 5:26 am Post subject: |
|
|
Disciple
Joined: 05 Sep 2001
Posts: 195
|
Kiran:
In your case, how did you examine the BLOB contents. As I understand it, you can't compare a substring of a BLOB to another literal string, unless it also looks like a hexstring of the form X'HHHHHH...'.
If doing this I would normally attempt to parse against a pseudo message definition, perhaps something that represented the header, but defined the rest of the message as a BINARY, and having parsed the header to see what I really have, set the message properties for the known message in the properties folder, set my labels, and route through an RCD with the DOMAIN specified as MRM, followed by RouteToLabel.
In 2.1 speak, you can probably use CREATE/PARSE to extract the piece of the bitstream which identifies the transaction type but I'd need to work through that myself before posting an example.
To determine if a message is XML or not, you could first try parsing with the generic XML parser, and wire up the exception processing so that if XML parse fails you go to the piece of the flow that handles CWF messages. |
|
| Back to top |
|
|
| kirani |
| Posted: Sun Jun 30, 2002 9:29 am Post subject: |
|
|
Jedi Knight
Joined: 05 Sep 2001
Posts: 3779
Location: Torrance, CA, USA
|
Codecraft,
We used CAST function with CCSID and Encoding clause to Convert BLOB data to a STRING format and then compared against Literal. We do this to minimize the parsing and it works pretty good!
We get combination of messages (XML and CWF) on the input queue, we then use CAST function to determine whether the message is in XML or CWF format. Our input application guarantees that it will send only 2 Types of XML messages <InterfaceDataHeader> and <InterfaceDataTrailer>. In first filter node we check whether first few char has XML string or not.
I first thought of implementing tryCatch node approach to first parse using XML parser and in failure path handle CWF messages. But above solution looks better than this.
I required, I can post an example here.
_________________
Kiran
IBM Cert. Solution Designer & System Administrator - WBIMB V5
IBM Cert. Solutions Expert - WMQI
IBM Cert. Specialist - WMQI, MQSeries
IBM Cert. Developer - MQSeries
|
|
| Back to top |
|
|
| CodeCraft |
| Posted: Sun Jun 30, 2002 11:23 pm Post subject: |
|
|
Disciple
Joined: 05 Sep 2001
Posts: 195
|
| Sounds good. "r1divya" can let us know if examples are required. I wasn't aware of the use of CAST with CCSID and Encoding - this is useful information. |
|
| 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
|
|
|
|
