Creating and Updating Services › Request SLAs and Calendars › How Request SLAs Are Processed

How Request SLAs Are Processed

Request SLAs are processed according to both the fixed rules specified by CA Service Catalog and the Maximum Delay for Request SLA Alerts setting that you specify.

Fixed Rules

Request SLAs are processed according to the following fixed rules specified by CA Service Catalog:

• After a request that contains one or more SLAs is submitted, the SLA clock for each SLA instance starts tracking time when the request reaches the starting status specified for the SLA. For example, if an SLA monitors the period from Pending Approval to Approved, the SLA clock for this SLA instance starts tracking time when the request status changes to Pending Approval.
• An SLA instance completes when either of the following occur:
  • The request reaches the ending status of the SLA before the SLA violation time expires. In this case, the SLA instance completes successfully. The SLA violation time is the maximum length of time permitted for the request reach the ending status of the SLA.

    Thus, in the previous example, if the request status changes from Pending Approval (starting status) to Approved (ending status) before the SLA violation time expires, the SLA instance completes successfully.

  • The SLA violation time expires before the request reaches the ending status of the SLA. In this case, the SLA instance completes unsuccessfully, causing an SLA violation to occur.
• The SLA clock tracks time for each active SLA instance and alerts the Catalog system if the SLA warning or violation time expires. The SLA clock is paused and resumed only when a CA Service Catalog user holds or resumes the request containing the SLA instance. If a user changes a request with an active SLA instance to Hold status, then the SLA clock is paused. When a user changes such a request to Resume status, the SLA clock is resumed.

  Note: If the user of another product integrated with CA Service Catalog puts a request on hold in that product, the CA Service Catalog request, the SLA instance remains active. For example, if CA Service Catalog is integrated with CA Service Desk Manager and a CA Service Desk Manager user holds a CA Service Desk Manager request or change order associated with a CA Service Catalog request that has an active SLA instance, the SLA clock is not paused. To pause the SLA clock, you must hold the request in CA Service Catalog.

• The SLA clock is stopped immediately when a request is canceled.
• The SLA clock is never restarted (reset to zero) under any circumstances, even if the request is rejected and resubmitted.

  For example, consider an SLA named “Approved within 1 Day SLA.” This SLA monitors from “Submitted” status to “Approved” status with a one day SLA violation time. In this example, the approval process also follows this request status cycle, in the following order:

  1. Submitted
  2. Pending Approval
  3. Approved
  4. Approval Done or Submitted
  5. Pending Approval
  6. Rejected

  In this example, if an end user requests a service, one day passes, and an approver rejects the request, then the SLA “Approved within 1 Day SLA” is violated. After the rejection, if the affected end user updates the request detail and re-submits it, the request approval process is repeated, but the SLA instance is not monitored again because it has already been monitored once and completed with a violation.

• As illustrated in the previous example, if an SLA instance completes, either successfully or with a violation, that same instance is never monitored again under any circumstances.
• Once a monitored request SLA instance is violated, the violation is included in SLA-related BusinessObjects Enterprise reports, even if the related request is canceled or rejected after the violation occurs. To exclude such records from a report, customize the report.

Request SLA Processor

The request SLA processor is part of Catalog Component and performs these functions:

• Listens for status changes for requests that have active SLA instances
• Sends alert messages when SLA warnings or SLA violations occur
• Tracks time for the SLA clock

Maximum Delay for Request SLA Alerts

The request SLA processor checks for SLA instances to be processed at these times:

• When the SLA clock for an active SLA instance alerts the Catalog system that the SLA warning or violation time has expired
• When it receives a message of a change in the status of a request with an active SLA instance
• When the time period specified in the Maximum Delay for Request SLA Alerts setting expires. To access this setting, select Administration, Configuration, Request SLA. This setting specifies how frequently the request SLA processor checks for SLA warnings or violations. This setting applies to all SLA instances managed by a Catalog Component computer.

In a Catalog Component-clustered environment, if a clustered computer fails, then event notifications, including SLA alert messages, may be delayed until the failed computer is restored or until other computers in the cluster begin doing the work of the failed computer. Consequently, SLA warning and violation messages may not be issued on time.

To minimize this possible delay in SLA processing time when a Catalog Component- clustered computer fails, you can configure the Maximum Delay for Request SLA Alerts to best meet your needs. The smaller the value you set, the greater the frequency with which the request SLA processor checks the SLA clock for warning and violation times. Therefore, set a less frequent time period, such as one hour, to be informed of SLA warnings and violations quickly. Otherwise, set a larger time period, such as one day, to be notified about SLA warnings and violations later, for example, when the failed clustered computer is restored.

Setting the Maximum Delay for Request SLA Alerts helps reduce any delay of SLA processing in case the clustered computer that started the SLA clock becomes unavailable for a length of time longer than a warning or violation period. In such cases, other active clustered computers take over SLA processing from the failed computer, as soon as any one of the following events occurs:

• The Maximum Delay for Request SLA Alerts time period expires
• An SLA warning or violation is issued
• A status change occurs in a request with an active SLA instance