The V12 is already a few months old and I already wrote an overview about its features and more detailed articles about V12 Analytics and the Zero Downtime Upgrade. In this article, I will present to you another new feature: The Service Level  Manager and the associated Object Type SLO (Service Level Objective).

Do you already know the Automic Service Orchestrator? Then the SLM is nothing special for you. Because both are about the same. But the SLM is directly integrated into Automic and does not have to be licensed separately. The Service Level Orchestrator, on the other hand, was only available as an add-on.

What’s the Use of SLM?

The SLM is all about the central monitoring of executable objects. It is an additional way to monitor tasks and to respond to events such as failures and too long runtimes.

 How does SLM Work?

SLM is only available in the AWI. Two components make up the SLM:

  1. Definition of the monitoring using the new object type SLO
    (Service Level Objective)
  2. Monitoring of services in the AWI perspective Process Monitoring

The New Object Type SLO

Objects of type Service Level Objective are used to define the monitoring.

You can create as many SLO objects as you want. This can be done through the Process Assembly perspective (via the Explorer), or, alternatively, through the Administration perspective, where there is a separate section called Service Level Objectives.

Each SLO object consists of three parts:

Part 1: The Monitoring Settings

Here you set whether this service should be monitored at all – and if so, when.You can find this setting under Service Level Objective in the SLO object (see screenshot).

You can find this setting under Service Level Objective within the SLO Object (see screenshot).

Part 2: The Service Selection

Here you define which executable objects this service is responsible for. You can also group multiple executable objects to a service group.

You can choose between two areas:

  • Service Beneficiaries
  • Service Selection

The service beneficiaries are optional; you can also leave them blank. But I’ll come back to that later.

In the service selection, you can set many filters and group these filters. This restricts what executable objects are added to this service definition.

In this example I select all Jobs and File Transfers that have either “WIN” or “FTP” in their names.

Note that if you enable monitoring in an SLO object, it must have at least one filter for ObjectType or one for ObjectName.

If this is not the case, you will receive an error message when saving the object, which is, fortunately, very clear and tells you exactly what you have done wrong.

The reason for this is that the SLM is executed by the JWP and the WP must trigger the JWP when a relevant object (i.e. an object that is part of a service monitoring) starts and/or ends. The definition for which objects the WP triggers the JWP is based on the client, object type filter, and object name filter.

The Service Beneficiaries are simply Custom Attributes. So you can filter your executable objects to the custom attributes you use.

This filter only considers objects with Custom Attributes, where Business Unit is either Finance or Human Resources.

Part 3: The Fulfilment Criterium

Here, you define two things:

First, when your service level is met. You define a state and all executable objects to which the filter that you defined earlier in “Service Selection” applies should reach this state.

And secondly, what action should be taken when the service level is fulfilled or violated.

When defining the target state, you can define runtime criteria, the end status, the latest start time, and the latest end time. Any combination of these criteria is possible.

For all SLO objects where you have enabled monitoring, the events fulfilled and violated are logged in the section Services of the Process Monitoring perspective.

These events are also transferred to V12 Analytics, which means you can also analyze this data in the Analytics dashboards.

Conclusion about the Service Level Manager

In my opinion, the integration of the SLM in Automic V12 is a very good step. As a result, sooner or later, Automic will completely replace the Automic Service Orchestrator.

If you want to get more information about the SLM, check out Automic’s video and check the V12 documentation for more information on how it works.

Should I still present one or more other feature of the V12? Then just write me a comment about it.