| Author |
Message
|
| wallflower |
 Posted: Thu Oct 09, 2008 8:19 pm Post subject: Routing of messages |
 |
|
Newbie
Joined: 08 Oct 2008
Posts: 3
|
Hi,
We have these huge collection of flows( like 1000+ interfaces), we are trying to create a generic flow where all the message come in to a single flow and from there the message route based on message types.
Currently we have designed the flow using:
1. RouteToLabel and Label Nodes - Using the RouteToLabel and Label Nodes, we will have to manipulate the flow again and again every time we add a new interface, which might not be feasible if the number of interfaces is huge in number.
2. Using Route Node - As the number of interfaces is huge in number, using this node will not be feasible as many will be accessing these flows and it might be prone to modification/deletion of some links in the creation of new interfaces.
Is there a way to route message based on message types using a route to label and label nodes, but the label nodes have to be a part of a different subflow so that the addition of the new interfaces will not affect the existing interfaces
Any help/approach would be appreciated. |
|
| Back to top |
|
 |
| hopsala |
| Posted: Fri Oct 10, 2008 12:03 am Post subject: |
|
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
I think you're going about this the wrong way. Subflows, when deployed, become a part of the main flow itself. As such, what you'll get is a huge flow, which takes up an enormous amout of resources, and you won't have any control over the way the routing is load-balanced. Also, in order to have one entry flow, all sending applications will have to work using the same message structure, which usually takes some doing.
I'd recommend using many seperate flows, employing MQ queues for routing purposes. If you're insistant upon the "one point of entry" scheme (any particular reason?) you'll have one main flow "MQInput -> Compute -> MQOutput" that routes messages to other, smaller flows, each with its own Input queue. Routing will be done according to a database table, using a singelton pattern.
If this is a request-reply scenario, no problem - save the replyToQ in a hashmap or whatnot according to the correlID before you send to the secondary flows, and on the way back retrieve it.
This is much easier to maintain. You won't have to redeploy anything. Any change to routing will be done in the database, and any change in a secondary flow will not affect any other flow. Adding a flow becomes laughably easy. Malfunctions and poisoned messages will only affect the secondary flows, and you'll be able to control performance by determining how many instances each secondary flow has. There are many other advantages, but my reply is long enough as it is  |
|
| Back to top |
|
|
| wallflower |
| Posted: Fri Oct 10, 2008 1:25 am Post subject: |
|
|
Newbie
Joined: 08 Oct 2008
Posts: 3
|
we have an already existing flow structure using Neon Formats and Rules, we need to retain the existing flows as it is, but also include the new message set and flows that the gradually developed(which are free of Neon) but has to follow the existing structure.
We need to replicate the Routing techinque of the Neon, in message broker. This can be doneeither by RouteToLabel node or the Route node. The requitement is to manipulate the least amount of the message flows when adding new flows to existing flow structure. |
|
| Back to top |
|
|
| fschofer |
| Posted: Fri Oct 10, 2008 2:30 am Post subject: |
|
|
Knight
Joined: 02 Jul 2001
Posts: 524
Location: Mainz, Germany
|
Sorry didn't saw hopsala posting which suggested already the same approach like me.
Hi,
you could use queues for routing and dynamically set the destination queue using
OutputLocalEnvironment.Destination.MQDestinationList.DestinationData.queueName
and by setting the MQOutput Node destination mode to destination list.
The routing rules itself could then be stored in a database and changed on demand.
Greetings
Frank |
|
| Back to top |
|
|
| broker_new |
| Posted: Fri Oct 10, 2008 7:45 am Post subject: |
|
|
Yatiri
Joined: 30 Nov 2006
Posts: 614
Location: Washington DC
|
Think twice about the database hit for each transaction vs deploying the bar file once if there is a change...  |
|
| Back to top |
|
|
| Gemz |
| Posted: Fri Oct 10, 2008 9:01 am Post subject: |
|
|
Centurion
Joined: 14 Jan 2008
Posts: 124
|
broker_new,
In that case we can think of shared variable. So that database hit will be reduced much....
-GemZ |
|
| Back to top |
|
|
| broker_new |
| Posted: Fri Oct 10, 2008 9:23 am Post subject: |
|
|
Yatiri
Joined: 30 Nov 2006
Posts: 614
Location: Washington DC
|
user defined variable would be much better  |
|
| Back to top |
|
|
| marcin.kasinski |
| Posted: Mon Oct 13, 2008 3:06 am Post subject: |
|
|
Sentinel
Joined: 21 Dec 2004
Posts: 850
Location: Poland / Warsaw
|
| broker_new wrote: |
| user defined variable would be much better |
Are you suggesting to store 1000+ mappings interface to queue in UDP ?
In my opinion the best way is to create generic flow which read mapping interface to queue from DB and store this data in shared variable. Then using timer node you can refresh this data.
In this way yon can have one generic flow and many specific flows.
In this DB data you can use pattern to rout all interface CLIENT.* to queue CLIENT.IN.
_________________
Marcin |
|
| Back to top |
|
|
|
|
