Using Activities in Service Manager allows you to collect Information about tasks and build them together in Change Requests. In the first Part I talked about custom activity classes and how to use them in Templates. In the second Part I want to show you, how these tasks could be fully automated by using Microsoft Opalis to save time and money … and make your life easier!

First we are going to build a new workflow in Opalis. The workflow will look something like this:

Sure, you could build a much more complex workflow, but for demo purposes this is enough. Let’s take a look at the three objects.

The “Monitor Object” comes from the Service Manager Integration Pack and checks for Changes in the Service Manager Database. I configured the object to watch for newly created objects as well as for update objects of the class “Database Order Activity”. An additional filter will only look for such objects if they are in a “In Progress” state. I such an object is discovered (no matter how the object is created in the Service Manager database …) the workflow kicks in.

The second object holds most of the workflow magic. It an object of type “Query Database” and is one of the Opalis foundation objects. The name of the object is a really misleading as you can not only query databases, but run any statement you want. In this example I will configure the object to create a new SQL database on a specific server with specific settings … all contained in the Activity that comes from a Service Manager Change Request.

First, a connection to a SQL Server is established. Because the Servername on which the new database will be created is contained in the Change Request activity, I will not hardcode the servername, but use published data from the “Monitor Object” object. as you can see, it’s possible to access data from other object by using the Opalis data bus. This is very powerful as you have the possibility to exchange data very easily between objects. In this case I use the attribute “Database Server Name” that we configured for our custom activity in the first Part.

Now comes the fun part: the SQL query. It will look something like this (again, this is very basic stuff and could be much more complex):

CREATE DATABASE itnetx

ON

(NAME = itnetx, FILENAME = ‘c:\SQLDB\itnetx.mdf’, SIZE = 100MB)

Now we’ll again use published data from the “Monitor Object” object to generate a dynamic statement. We will use information such as “Database Size” and “Database Name” from the custom activity. The query will then look like this:

The last object of the workflow is again very simple as it only updates the custom activity status in Service Manager to “completed”. Again, published data will be used because we have to define which object we want to update. Therefore we will use the object GUID that will be published by the “Monitor Object” object.

Now it’s time to check if our Opalis Workflow executes as expected. Therefore I create a new Change Request based on the Database Order Change Request Template and I configure the details in the Database Order Activity.

After a short while, the workflow should execute, create the database and update the activity status to “completed” (which automatically changes the Change Request status to “completed” as well because it’s the last activity in the Change Request). Let’s check the result.

The database was successfully created on the correct server …

The database files have the size that we configured in the Change Request …

and the activity has the status “completed” …

If you were not sure if automation of Service Management Tasks by using Opalis is a cool thing … now you know it! I really like the way how Opalis integrates into Service Manager and lets you automate tasks that normally needs to be done manually. This is only a simple example, but there are many tasks out there where you can use this procedure to make your life easier. Start your journey to the dynamic datacenter today – or tonight … depending on what time of the day you read this blogpost 🙂

see you
Marcel