Service Level Management in AWA - Use Case

Service Level Management is a central task for all IT projects based on ITIL. The previous versions of Automic Service Orchestrator already offered a certain range of functions.
As of v12 of AWA you can easily set up and configure SLM services and their monitoring in connection with Service Level Agreements' (SLA) requirements using the 'Service Level Objectives' object as well as the associated functions without additional licensing.

Introduction

As Service Level Management (SLM) based on ITIL is an integral part of most IT businesses, also Service Level Agreements' (SLAs) conditions can be fulfilled or violated.
Therefore it is highly desirable to have the possibility to easily monitor services provided in regard to SLA conditions.
In an AWA system services would be implemented and provided via executable objects.

SLM Monitoring - The Service Level Objectives object

The SLM possibilities in CA Automic Workload Automation are based on the so-called Service Level Objectives (SLO) object, that can be used to monitor services.
The services would be provided via Automation Engine executable objects.
The SLO object provides the capability to set custom attributes as basis for the monitoring of any number of selected executable objects, that have these custom attributes assigned to them. Additionally you use custom attributes to assign service beneficiaries to the SLO.
You can configure the SLO object to trigger certain actions or executions or messages when the status of the executable objects (services) makes this necessary or appropriate.
The respective task or job status types in regard to services provided can also be configured in detail, to make sure reactions are triggered accordingly.

Automic recommends that you are familiar or make yourself familiar with the basic AWA concepts of executable objects and their usage first: Defining Objects

Below you find an overview and the detailed steps on how to set up a monitoring of services using the SLO object and the associated functions.

The SLM functions as well as SLO fulfillments page are only available in other clients of your system, not in client 0000. It is possible to create SLO objects in client 0000, for technical reasons, but SLM functions in general are not available.

Use Case Overview

In order to be able to use the monitoring functions a few configuration steps and prerequisites have to be fulfilled:

  1. Create service(s) (executable objects).
  2. Create custom attributes for services to be able to assign service beneficiaries (optional).
  3. Create a Service Level Objectives object (an SLO object).
  4. Select services and service beneficiaries for the SLO object.
  5. Create executable object(s) to react on service level fulfillment or violation (optional), for example a Notification object.
  6. Set the appropriate actions for the SLO object to react on service statuses.
    Service statuses here are executable objects' tasks and job statuses in accordance with individual SLAs.
  7. Check manually on the SLOs for SLA service fulfillment or violation.

Prerequisites

Steps to follow

ClosedI. Create Services

  1. Create one or more executable objects, which execute the services according to your needs.

ClosedII. Create Custom Attributes for Executable Objects

Custom attributes are used for monitoring of services and assigning service beneficiaries.
In order to be able to group or define the monitoring of services (one or more executable objects) to the SLO, you need to define these custom attributes as criteria.
The UC_CUSTOM_ATTRIBUTES variable's configuration is necessary to define custom attributes.

You have to assign custom attributes in two steps:

  1. Use the variable UC_CUSTOM_ATTRIBUTES to define custom attribute items for use with executable objects (services).
  2. Set the attributes in the General page, section Metadata of executable objects.
    Example:
    The attribute could be named "Departments" and the values you create for them could be "Finance", "Development" or "HumanResources".


    The image above shows a Workflow object. Layout is similar in all executable objects.


ClosedIII. Create a Service Level Objectives Object (SLO)

You have two possibilities to create and edit an SLO object:

  1. Use the Administration perspective, Service Level Objectives page.
    The Service Level Objectives page is not available on system client 0000.


    Example of the Service Level Objectives page

    1. Click the Add Objective button. A dialog window opens that allows you to set the name and choose a location for the object.
  2. Open the Process Assembly perspective, use the Explorer and add an SLO object, as described here: Defining Objects
    If you create a new SLO object by duplicating an existing one, the duplicate is disabled to prevent instantly doubling fulfillments / violations in the context of this new SLO.

ClosedIV. Select Services and Service Beneficiaries for the SLO object

Services you can select are executable objects of the AWA system you previously created. They are used to provide services (workflows, deployments, etc.).

Service Beneficiaries you can select are the custom attributes and their values you created earlier.

ClosedTo select services:

How to select services (popup).

ClosedTo define service beneficiaries:

How to define service beneficiaries (popup).

ClosedV. Define Fulfillment Criteria for the SLO object

How to define fulfillment criteria (popup).

ClosedVI. Create SLA Reactions to execute on Fulfillments or Violation

The fulfillment and violation criteria you define, depend on the respective Service Level Agreements (SLAs) first of all.

As executable objects represent the services of the SLA, you can use the executable objects' default functions in regard to runtime or status of the executed and or finished task to monitor them using SLOs.

You then can define reactions to the appropriate statuses using the SLOs special function in the Actions section.

How to define SLA reactions for SLOs (popup).

ClosedVII. Check on SLO Objects Manually

SLOs are passive objects, therefore the default monitoring functions for executable objects do not apply to them.

Automatic reactions in the form of executions you would have to define in the Actions section of the SLO objects themselves (optional). Thus for example a Notification object could be triggered on service fulfillments or violations.

There are several ways you can check manually on SLOs and their status:

See also:

Service Level Objective Object (SLO)

Service Level Objectives (SLO) Objects

Grouping Criteria in Executables - UC_CUSTOM_ATTRIBUTES