Hi @Ramya,

Do you use the SME at all?

Might be a candidate for this. Basically when the escalation fires another XML business rule is triggered and it will have a 2 day expiry on it. You specify the hierarchy select and if that matches after two days then another XML is triggered i.e. the one to create the escalation for the second person in the hierarchy.

That to me is something I would look into.

Ady

@AdrianEgley thanks for the response.

Can you please explain in brief about what is the triggering point for second business rule.

can I use scheduler to do the same?

Thanks

Ramya 

Hi @Ramya,

The Service Monitor Engine (SME) is a FSM Feature that is used to perform time based actions. It would be triggered by an XML Business Rule that would likely be fired when the initial escalation is created. The process requires MSMQ (Microsoft Message Queuing) be enabled on the application server. The SME Message is then split into 3 parts;

• action_time_value - basically do something in ‘x’ minutes or hours
• monitor_action - what XML is going to be triggered
• monitor_validation - check the previous escalation is still open prior to doing the action

In the example below the valid_if_found is ‘True’, so if the hierarchy select locates that escalation id and it’s still open then it will fire your XML to create a new one. You’d just need to add in your <monitor_action> below to create the new escalation.

<perform_send_to_monitor>
  <parameters>
    <action_time_value>@expressionecreated_dttm + hours(48)]</action_time_value>
    <monitor_action>
    
<!-- Add in the XML to trigger if the escalation is still in the same status after 48 hrs This is the Monitor Action.-->

    </monitor_action>
    <monitor_validation>
     <valid_if_found>True</valid_if_found>
     <hierarchy_select>
        <attrs>
          <attr>escalation.esc_id</attr>
        </attrs>
        <primary_table>escalation</primary_table>
        <from>
          <table>escalation</table>
        </from>
        <where>
          <data_constraint>
            <constraint>
              <left_operand>escalation.esc_id</left_operand>
              <operator>eq</operator>
              <right_operand>@esc_id</right_operand>
            </constraint>
          </data_constraint>
          <data_constraint>
            <constraint>
              <left_operand>escalation.esc_status</left_operand>
              <operator>eq</operator>
              <right_operand>OPEN</right_operand>
            </constraint>
          </data_constraint>
        </where>
      </hierarchy_select>
    </monitor_validation>
  </parameters>
</perform_send_to_monitor>

To see what’s in the queue then log on to your application server using the Services Account. Once drilling into the Message Queuing you’ll be able to see what’s in there, and what’s pending to be fired and it’s execution date and time.

I hope this helps and I have explained it correctly.

But it really helps us drive some processes being able to check the current status of something and then action it if needed.

Ady