How to Switching between the Escalation (SLA) Engine and the SLA Plugin (2011 SLA Engine)
Before reading this article, please familiarize yourself with the section "Moving to the SLA Plugin from the old Engine" in the product documentation article Moving from the Escalation Engine to the SLA Plugin.
The key to switching between the Escalation (SLA) Engine and the SLA Plugin (2011 SLA Engine) is understanding the architecture differences between the original Escalation (SLA) Engine and the SLA engines in the SLA Plugin.
The SLA plugin contains both the 2010 SLA Engine and the 2011 SLA Engine. Because of unresolved known issues, ServiceNow recommends using the 2011 SLA Engine.
Note – This article refers to the SLA Engine for the plugin as the 2011 SLA Engine. Although both the 2010 and 2011 versions are present in the SLA plugin (com.snc.sla), you will use the 2011 SLA Engine.
The original Escalation (SLA) Engine uses definitions stored in the sysrule_escalate table. The data is stored as fields in the underlying task record (fields like sla_due, made_sla, etc.). Because of this setup, you can have only a single SLA applicable to any given task.
For the SLA plugin engines (2010 and 2011), the SLA definitions are stored in the contract_sla table and the SLA data is stored in the task_sla table.
In the prerequisite wiki article, the focus of the upgrade from the Escalation engine to the SLA Plugin engines is to create new SLA definitions (in the contract_sla table) to take over for the existing SLA definitions (in the sysrule_escalate table). However, because of the additional capability of the 2011 SLA Engine, you are likely to be expanding functionality rather than trying to duplicate what already exists.
Due to the limitations of the original SLA engine, the upgrade process is not concerned about the data. The Escalation Engine data is stored in the underlying task record, and is not touched or moved or copied.
Because the original SLA engine allowed only one active SLA definition per task, when using the 2011 SLA Engine, it is typical to develop additional SLA Definitions that will apply to the same task. For example, frequently both Response and Resolution SLAs are defined and both apply to any given task.
Switching to the 2011 SLA Engine
When you activate the plugin, the following actions occur:
- The contract_sla table and task_sla tables are created.
- The com.snc.sla.run_old_sla_engine property is added to the instance and set to false to deactivate the old SLA engine.
- Some default SLA definitions (such as contract_sla records) are added.
- A Default SLA workflow is added.
- SLA workflows are used to send notifications only, and not to drive the 2011 SLA Engine processing.
For helpful information about creating or customizing your SLA workflow, see Configure SLAs in the product documentation.
IMPORTANT: Test the following process in a subproduction environment.
To activate the plugin without changing the operation of your instance:
- Activate the plugin.
- Ensure the Active field of any contract_sla records is set to false. (The new engine will not be used if the definitions are not active.)
- Set the com.snc.sla.run_old_sla_engine property to true.
Prepare new SLA definitions, which provide the instructions to make the new engine do work, for the 2011 SLA Engine:
- Follow the guidelines in the prerequisite wiki article and create new contract_sla records for your existing SLA definitions (these are the records in the sysrule_escalate table).
- Determine whether you have additional SLA requirements that can be met by the additional capability of the 2011 SLA Engine. If so, create the new contract_sla records to meet these additional SLA requirements.
- Test each of the new SLA definitions (the new contract_sla records) to make sure they produce expected results.
- Set Active to false so the new records will not be running.
When you are ready to go live with the switch in this instance from the Escalation SLA Engine to the 2011 SLA Engine:
- Set the com.snc.sla.run_old_sla_engine property to false.
- Set Active to true on all of the SLA definitions.
When you are ready to apply these definitions to another instance:
- Activate the plugin in the target instance.
- Use an update set to move the SLA definitions (contract_sla records) into the target instance.
Note – Because Inactivity Monitors are extended off sysrule_escalate, the Escalation Engine code is still present and running in every instance, even with the com.snc.sla.run_old_sla_engine property set to false.
Express to ITSM Enterprise conversion