Mahmoud,

I have done quite a bit of fiddling with just this situation.  

Simply put, out-of-the-box the Escalation process is single threaded, which 
means that with no further adjustments only one escalation can operate at any 
given time. A long running escalation will delay the start of others, and a 
very long running escalation can cause some cases of the shorter ones to be 
skipped entirely.

To fix this you can add threads to the escalation process (390603). This will 
allow more than one escalation to run at the same time. This will allow more of 
your escalations to complete without blocking each other, but still might allow 
some to be delayed.  

There is also the chance that some escalations depend on other escalations to 
be completed before they will do what is expected. The notification engine has 
a couple cases like this.  These sorts of escalations can be grouped together 
using escalation pools.

Please do not be tempted to add one thread or pool for every escalation! That 
would work, but would waste a lot of resources and potentially slow things 
down.  You will need to turn on escalation logging and see how many escalations 
are ready too fire each minute, then adjust the number of threads so that more 
of them will fire and complete. Then group the ones which should not be blocked 
into unique pools. You can experiment with all of these pools and threads a 
bit, and remember that each thread, whether in an escalation queue or any other 
queue will tax the system somewhat. You want those threads to be mostly busy, 
and for there to be at least one thread/pool combination to be available every 
minute for your essential one.

One way to be certain this happens might be to isolate your critical escalation 
in a pool by itself (let’s say pool 3), set your escalation threads to 3, and 
set all the other escalations to either pool NULL (which is the default) or 
pools 1-2. Anything in pool 1 or 2 will run on one of the first two available 
threads, and your essential one will be the only thing that runs in thread 3.

You might have several escalations which need to fire every minute. As long as 
those don’t take a long time to run they could be all in the same pool. If you 
find that running all the escalations assigned to pool 3 takes longer than a 
minute, you’ll need to look at more threads or more pools.

You can also investigate scheduling of the escalations. It is very common to 
find that a lot are scheduled to run at :00 in each hour (the default value). 
Perhaps some of these can be mored to another time so they do not all trigger 
at once.

All that said, there is also the possibility that some of your escalations 
might be poorly written and just be doing things very inefficiently. Look 
closely at the RUNIF qualifications of those that seem to take a long time to 
complete, and turn those just as you would an inefficient filter qualification 
or search for a report or other lookup…

Hope this helps!

Doug Blair


On Aug 19, 2014, at 4:04 AM, Mahmoud Mahdy-Mohamed, Vodafone Egypt 
<mahmoud.mahdy-moha...@vodafone.com> wrote:

> **
> Dears,
> Kindly help as I’m facing a critical issue, the escalations are running 
> randomly regardless the execution time that it should execute in. For example 
> I have escalation that has to run every minute however it is running after 30 
> min which causes a delay in other related work flows.
> Note:- I’m using 7.6.04 SP4
>  
> Thanks,
> Best Regards,
>  
> Mahmoud Mahdy Mohammed,PMP | Business Process Automation 
> Technology | Products & Services Delivery
> Phone: +20(0)1004999638 
> Mail: mahmoud.mahdy-moha...@vodafone.com
>  
> *************************************************************************************************************************
> 
> The content of this document is classified as Vodafone Egypt S.A.E. 
> Confidential and Proprietary Information.
> 
> The recipient hereby is committed to hold in strict confidence the contents 
> of this (e-mail, document, information) and not to disclose to any third 
> party without the prior written consent of Vodafone Egypt S.A.E. Recipient 
> will be held liable for any unauthorized disclosure.
> 
> If you have received this message in error, please notify the sender by 
> return e-mail and delete the message in its entirety, including any 
> attachments.
> 
> http://www.vodafone.com.eg
> 
> 
> *************************************************************************************************************************
> 
> _ARSlist: "Where the Answers Are" and have been for 20 years_



Doug

--
Doug Blair
d...@blairing.com
+1 224-558-5462

1208 East Fremont Street
Arlington Heights, Illinois 60004



ITILv3


_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
"Where the Answers Are, and have been for 20 years"

Reply via email to