| Author |
Message
|
| nilayms |
 Posted: Wed Aug 15, 2007 4:07 am Post subject: Delay Node |
 |
|
Apprentice
Joined: 01 Jun 2006
Posts: 31
Location: UK
|
Is there any node by which i can introduce delay in processing the message.
The messages that arrive on a queue must be updated 10 min after they arrive at the queue.
I use a database node to connect to a oracle database.
Which node has to be used to introduce a delay?
_________________
Regards,
Nilay. |
|
| Back to top |
|
 |
| Vitor |
| Posted: Wed Aug 15, 2007 4:11 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
If you're using WMBv6 you can use the timing nodes. Earlier than that I think you'd need to produce a custom node that did it.
Pedantically I point out that you can't update a message on a queue, only read it off and add another one back, and using a queue for this kind of data storage is not a good idea.
Come to that, holding messages for 10 mins isn't exactly best practice but hey.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| nilayms |
| Posted: Wed Aug 15, 2007 4:42 am Post subject: |
|
|
Apprentice
Joined: 01 Jun 2006
Posts: 31
Location: UK
|
Yes we are using wmb6.0.
Actually this the 10 min delay is a business requirement.
Can i know why exactly using another queue for intermidiate storage is a not a good idea?
What are the disadvantages involved?
_________________
Regards,
Nilay. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Aug 15, 2007 4:49 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| nilayms wrote: |
| Actually this the 10 min delay is a business requirement. |
Is this a real requirement, or something a focus/management group has come up with? I'd be interested to know what the justification is in business terms to have unprocessed data laying round. But we move forwards.....
| nilayms wrote: |
Can i know why exactly using another queue for intermidiate storage is a not a good idea?
What are the disadvantages involved? |
A queue is not a database table, it's not designed to act like one. Consider your statement "we update the message" - WMQ has no update statement so you must read, process and readd the message. This is computationally expensive, more so than an SQL UPDATE statement against a holding table.
It's also harder to identify a given message. To locate messages that have been in a queue more than 10 minutes you must browse the queue one message at a time, examining the message as you go. This requires hand rolled code and browsing a queue costs a lot. Compare this to the simple elegance of an SQL SELECT statement.
If you search through the forum you'll find other discussions of this with more points than I've made here. You're by no means the first poster to consider using a queue like a database table, and you won't be the last I'm certain.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| nilayms |
| Posted: Wed Aug 15, 2007 5:26 am Post subject: |
|
|
Apprentice
Joined: 01 Jun 2006
Posts: 31
Location: UK
|
Actually we have a certain data that should reach the database first and another set of data that should reach only after this data is processed.
for example :
We create agreements on SIEBEL and we create orders.
These are sent to oracle for financial calculations.
The sequence shud be 1st -> AGREEMENTS and then 2 -> ORDERS
Right now the JAVA database adaptor is scheduled on TIVOLI and the orders job is dependent on the agreement job.
On the other side when using message flows we have 2 different flows for agreement and orders.These flows are not linked as the TIVOLI jobs are.
So it was just a idea to introduce a 5 min(approximate time to process agreements) + 5 min (buffer time - just in case we are laggin behind) delay in the orders message flow.
This again prompts me to ask another question :
Is it possible to make a message flow dependent on another message flow?
Also thanks for the detail explaination for the disadvantages part. It certainly increased my knowledge.
_________________
Regards,
Nilay. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Aug 15, 2007 5:34 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| nilayms wrote: |
| Actually we have a certain data that should reach the database first and another set of data that should reach only after this data is processed. |
This is classic message affinity. It causes (as you've discovered) a range of interesting problems, especially when you start trying to use workload balancing.
You need to design this out. Not a short term task I agree, but well worth doing. And not that tricky in your situation I'd have thought (from the limited details you've given - there may of course be other complexities inappropriate for this forum).
You can't syncronise message flows the way you're trying to. This is one of the many reasons message affinity is a bad idea.
I think your key exposure is the exceptional situation where the lag is more than 5 minutes. Yes, I know that's outside SLA & impossible but it will happen one day and at the worst possible time.  
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| nilayms |
| Posted: Wed Aug 15, 2007 5:59 am Post subject: |
|
|
Apprentice
Joined: 01 Jun 2006
Posts: 31
Location: UK
|
coudnt hold back myself....
What strategy will you follow given that you have to use the database node?
i know this is asking too much.........just for opinion sake.....
_________________
Regards,
Nilay. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Aug 15, 2007 6:04 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| nilayms wrote: |
What strategy will you follow given that you have to use the database node?
|
I'd remove the message affinity for starters (and with it the delay & consequent queue use), get the DBA to ensure the database is properly configured, plug the database node into it and dance into the sunset.
Personal view, other solutions may be equally valid.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| nilayms |
| Posted: Wed Aug 15, 2007 6:15 am Post subject: |
|
|
Apprentice
Joined: 01 Jun 2006
Posts: 31
Location: UK
|
I think we share the same opinion..........to dance in the sunset.......provided we do get some sun.....haha.....
cheers...
_________________
Regards,
Nilay. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Aug 15, 2007 6:45 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
If you want message flows to happen synchrononously, use a synchronous method to invoke them.
If you need to control when a message flow is invoked, use Timeout* nodes.
The only thing that should really matter is that you don't process a PARTICULAR order until a PARTICULAR agreement (that relates to the order) has been created.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Aug 15, 2007 9:45 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Think about how SAP processes IDOC's that have the same type of affinity.
Put both your agreement in a message, put your order in a message, and finally put a process instruction message.
That process instruction message should say
- Process all unprocessed agreements prior to this timestamp
- Process all unprocessed orders prior to this timestamp
Now if your processing system only takes action on the messages as received you should not have any problems with message affinity...
On the extreme case the process instruction could come before the agreement. Now if you roll back any "agreement" order that you could not find the agreement for (I believe the order type will tell you whether an agreement is needed or not) and just try to process it the next time around you might have achieved message affinity without too much problems...
Of course this all means you process from the DB. The flow just inserts messages into the DB.
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
