For Campaign SMS deliveries we are utilizing a routing option to direct SMS deliveries to an external server via an external account definition and technical work flow. Routinely we noticed that there is a delay of one to four days for some deliveries and we are unable to determine why this is occurring. Since many SMS deliveries are time sensitive this has become a real issue.
High Level Flow
The delay occurs between the delivery node in the campaign being executed and the External Signal in the technical work flow detecting the delivery event.
Any suggestions as to what might be causing the issue would be welcome.
Solved! Go to Solution.
Views
Replies
Total Likes
Hi @Ken_Qrious, sorry for the delay, for me, you need first to be sure that those continuous deliveries are not integrated in an operation. If this is the case, regarding how to troubleshoot here is the process I suggest you: open the technical workflow "operationMgt" and open the "scheduler" js activity.
On line 1: you have a hint for bad solution (I'll come back to it later): it takes the value of the option "NmsOperation_LimitConcurrency" in order to know the max operation activities that can be run in parallel. So, dirty solution should to increase option value higher. Now, heatmap is not necessarily helping here as we not talking about just workflows but about workflows/deliveries/import/simulation/hypothesis activities.
But first, let's add a logInfo('alert: max activities(' + maxRunnings +') reached - Jobs in queue: ' + iJobCount). Normally it should near line 338 (in the "iJobCount >= maxRunnings" condition) If you see this log Message in the workflow logs when you have the issue => you've pin pointed the problem
The best thing to do is then to understand why you reach the max... In your case, the highest probability is about creating continuous deliveries in some operations. I would then recommend you to ask your tech lead to find another implementation method as this is not part of a best practice at all for this reason
As a temporary workarround your can increase the NmsOperation_LimitConcurrency option value... But it should be only temporary:
having a huge number of operations activities in parallel is not recommended for global performance platform. This solution will not change the fact that you'll need to implement in a different way as this type of implementation is a structural problem and will not get over with time
Views
Replies
Total Likes
Hello,
simple naive question: is campaign module involved?
If yes, it can be an issue of implementation related to operationMgt: by default, you can have 50 paralled activities related to operations (workflow operation / deliveries in operation).
operationMgt manages the queue: if the 50 paralled activities are taken, it waits for a / some release(s).
This is why you should not use for example continuous deliveries inside operation as it hardly release the token
Views
Replies
Total Likes
Views
Replies
Total Likes
Views
Replies
Total Likes
Hi @Ken_Qrious, sorry for the delay, for me, you need first to be sure that those continuous deliveries are not integrated in an operation. If this is the case, regarding how to troubleshoot here is the process I suggest you: open the technical workflow "operationMgt" and open the "scheduler" js activity.
On line 1: you have a hint for bad solution (I'll come back to it later): it takes the value of the option "NmsOperation_LimitConcurrency" in order to know the max operation activities that can be run in parallel. So, dirty solution should to increase option value higher. Now, heatmap is not necessarily helping here as we not talking about just workflows but about workflows/deliveries/import/simulation/hypothesis activities.
But first, let's add a logInfo('alert: max activities(' + maxRunnings +') reached - Jobs in queue: ' + iJobCount). Normally it should near line 338 (in the "iJobCount >= maxRunnings" condition) If you see this log Message in the workflow logs when you have the issue => you've pin pointed the problem
The best thing to do is then to understand why you reach the max... In your case, the highest probability is about creating continuous deliveries in some operations. I would then recommend you to ask your tech lead to find another implementation method as this is not part of a best practice at all for this reason
As a temporary workarround your can increase the NmsOperation_LimitConcurrency option value... But it should be only temporary:
having a huge number of operations activities in parallel is not recommended for global performance platform. This solution will not change the fact that you'll need to implement in a different way as this type of implementation is a structural problem and will not get over with time
Views
Replies
Total Likes
Views
Replies
Total Likes
Views
Replies
Total Likes
Views
Replies
Total Likes
Views
Replies
Total Likes
Views
Replies
Total Likes
Views
Replies
Total Likes
Views
Replies
Total Likes
Views
Replies
Total Likes
Views
Likes
Replies