| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| When to use internal MQ flows instead of subflows? |
« View previous topic :: View next topic » |
| Author |
Message
|
| billybong |
 Posted: Tue Dec 20, 2005 6:05 am Post subject: When to use internal MQ flows instead of subflows? |
 |
|
Disciple
Joined: 22 Jul 2005
Posts: 150
Location: Stockholm, Sweden
|
I'm looking for some advice on when and how you should extract subflows to separate MQ queues.
The reason I'm considering this is because we basically have one big central subflow which is used by mostly all of our flows. Since the broker simply "copy and paste" all subflows into the main flow this makes version handling of the subflow and deployment of each flow a considerable task.
Therefore we're playing with the idea of extracting this flow to a central flow, most likely running in a separate execution group. The flow would be bridged by MQ inputs/outputs and running on the same QM and broker.
The problems arises when we take transactions in consideration, ie
if the central flow fails, how do we rollback the first flow?
Does anyone have any best practices on this topic? |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Tue Dec 20, 2005 6:13 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Your scenario is exactly when I would look at using separate flows instead of subflows.
The main advantages of separate flows is a real separation of concerns - in terms of change management and etc.
Are you sure you need to roll back the first flow if the second flow fails? Some additional infrastructure/error handling should allow you to deal with it as is, without trying to link transactions.
Alternately, you can look at something like Workflow or Process Server/Choreographer - this is what they are useful for.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| billybong |
| Posted: Tue Dec 20, 2005 6:41 am Post subject: |
|
|
Disciple
Joined: 22 Jul 2005
Posts: 150
Location: Stockholm, Sweden
|
Thanks for the quick reply Jeff.
As I see it there has to be some transactional linking somewhere, at least for the database, since the beginning and end of each flow (our system adapters) updates and modifies the database tables that the central flow uses. The alternative would be to migrate all the database logic into the central flow, which is a bad solution since we lose the generalisation of the central flow. I guess my problem description is all to vague to work with but I was more looking for general experiences and scenarios dealing with these issues.
I'm really interested about the "Workflow or Process Server/Choreographer" bit though. Could someone shed some more info?
Again, thanks for all the replies and extensive knowledge available on this forum. |
|
| 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
|
|
|
|
