Per schedule business rule doesn't trigger

Hi,


We have an issue with the business rule "Per schedule".
Our use case :
We can create an incident from a request.
For such incident, when we resolve it, the incident goes to the Phase Review, and the incident's solution is copied to the request, which goes to the Phase Accept.
At this point if the end-user, whom submitted the request, doesn't accept nor reject the solution, the request will close itself after 14 days.
And so for the incident.
If the user accept the solution, the request will be closed directly, but the incident will go through the 14 days before closure.

Our issue is with the incident closure.
Indeed, in the business rule the condition to trigger it is that all related request should not be active.

We tested the condition (1 hour instead of 14 days) :
${entity.CompletionCode != null && entity.CompletionCode != ''
&& entity.Solution != null && entity.Solution != '' &&
is_empty_collection(entity.IncidentCausedByRequest[Active=true])}

in "after change" and it triggers correctly, but not in "per schedule".

Are we missing something ?

  • 0  

    Hi Daniel,

    Normally any Per Schedule rule can take upto 5 mins after the expected start time of the the rule to actually start running. So it could be 1hr5mins from the moment the record entered the desired Phase before the rule actually runs.

    Now you can also start to hit problems with the Per Schedule rules actually activating if the itom-xruntime-platform-offline pod isn't performing to well. For instance in my environment I'm seeing my own per schedule rules aren't always running based upon the schedule I've set. Using the xdoctor tool available on the marketplace I can see the resources for my environment are heavily overloaded. An example of that is shown here:

     "deployment": "itom-xruntime-platform-offline",
    "deployment_container": "itom-xruntime-platform",
    "health": "yellow",
    "health_reason": "Mem saturated",
    "mem": {
    "average": 6869,
    "health": "red",
    "percent": 83,
    "total": 8244,
    "used": 6869

    Here is a doc link which is useful for troubleshooting why Per Schedule rules can hit issues and have performance issues:

    Per-schedule rules experience slow performance - Service Management

    So if you know the rule to work based upon the After Change rule works, I'd consider looking at the performance of your SMAX environment to see if that is having an impact on the Per Schedule rule not working.

  • 0 in reply to   

    Thanks for your feedback, Dave,

    We know the rule can take a few minutes to run, but in the rule "per schedule", the part “then every 1 hour” should at some point trigger the closure, right ?

    We waited several hours (and days), but it never happened.
    As far as performance is concerned, we're in a development environment, where nothing happens except our tests. And we have another "per schedule" rule for incident closure when there is not ticket linked to the incident, and this rule works fine.

    To sum up:

    • When there is no request linked to the incident, the condition is_empty_collection(entity.IncidentCausedByRequest) works fine
    • When there is a request linked to the incident, and we want to close the incident only if the request is closed, the condition is_empty_collection(entity.IncidentCausedByRequest[Active=true]) doesn't work
  • Verified Answer

    0   in reply to 

    Did you close the request after the incident entered the Validation phase? If the condition already evaluated to false, it will not try to run the rule again.

  • 0 in reply to   

    Yes, in most of the cases, the request is closed after the incident entered the Validation phase (Review).
    I'm not sure to understand when you say "If the condition already evaluated to false, it will not try to run the rule again".
    Does it mean that after 14 days, if the request is not yet closed, the rule will never try to check if the condition is fulfilled after a while ?
    Then, what is the purpose of the frequency in the business rule ?
    "After the record is in this phase for 14 days, then every 1 days, if"

  • 0   in reply to 

    That's correct, the rule is not re-scheduled if the first evaluation returns false, unless there is a trigger on the record to re-save it.

    In order to trigger an update, you can add a business rule on the request, when it closes, to update something on the related incident (can be a field or can be a comment added)

  • 0 in reply to   

    We added a bussiness rule, triggered byt the request closure, that updates a checkbox in the incident.

    But again it seems the per schedule business rule doesn't work :