Opalis Runbook Automation Fundamentals (Part 1)

Part 1 of series discussing OIS concepts and functionality

Thank you to Pete Zerger for contributing and collaborating on this posting. Pete is a System Center MVP and contributor to System Center Opalis Integration Server 6.3 Unleashed. As one speaks to customers about System Center these days, Opalis Integration Server (OIS) is a product that everyone wants to know more about. To that end, this series of postings covers some fundamental concepts to help get you started. This 3-part blog series discusses OIS 6.3 concepts and functionality, including real-world tips and sample automation sequences (policies) to jumpstart your process automation efforts. Here is what this first installment will look at:

  • The Building Blocks of a Policy

  • Data Publishing and the “Rules of the Data Bus”

  • Which Processes Should I Automate?

OIS provides IT Process Automation (ITPA) also known as Runbook Automation (RBA) - the ability to define, build, orchestrate, manage and report on policies that support system and network operational processes. This capability allows IT professionals to automate tasks with a minimal need for programming and scripting. RBA using OIS can cross multiple IT management disciplines in a single automation sequence, integrating multiple IT management tools and interacting with all types of infrastructure elements to automate processes ranging from simple to complex, such as automating resolution of a known error or provisioning a new server and installing the necessary applications.

First, the question: “What is a policy anyway?”

The Building Blocks of a Policy

OIS automation capabilities are based on the concept of policies (sometimes referred to as workflows…more on this later) which are visual representations of your data center processes as they are automated in OIS. You create policies by dragging and dropping objects into a workspace in the OIS Client (the primary administration and authoring interface of OIS) and connecting them with links. Each object performs a specific action when it is executed (the precise behavior depending on how the object is configured by the policy author). Once an object has completed it will output one or more data elements and trigger any objects that are linked to it. For example, the policy in Figure 1 contains an object that monitors a folder. When a file enters the folder, the object triggers a second object to move the file to an archive directory (here's a very basic backup approach!), which in turn links an object to log an event.

Figure 1 - Sample OIS Policy

Links connect objects in a policy directing the flow of activity and data within a policy based on conditions encountered at runtime. Whenever you create a link in a policy, by default it is configured to trigger the next object in the policy when the previous one succeeds. However, links also provide filtering; this allows you to limit the data arriving at the following object in the policy and control the flow of policy execution based on the result of object execution. Link conditions provide a set of author-configurable functions for creating complex decision logic involving text, numeric or time-related data. Links configured with conditional filtering logic as described here are called Conditional Links. Configuring policies with multiple branches driven by conditional links is a concept called branching. To make your policies visually more intuitive, you can also change the display name of objects and link labels to make them more descriptive of their purpose in the policy. You can also change link color to highlight success and failure branches within your policies.

For example, look at the policy depicted in Figure 2, where the link labeled “Clean Shutdown Failure” is configured to trigger the next object in the policy only if the Shut Down VM object returns a warning or failed result (as pictured in the link properties in Figure 3).

Sample Conditional Links and Branching

Figure 2- Sample policy implementing conditional links and branching

You can configure conditional filtering in link properties, using both include and exclude logic. The Include tab specifies the conditions that will allow data to flow to the next object in the policy. The Exclude tab specifies the conditions that will cause data to be excluded from the next object in the policy.  

Link Properties

Figure 3 - Link properties of 'Clean Shutdown Failed' link from policy in Figure 2

Note: When implementing conditional filtering, bear in mind that rules on the Exclude tab always supersede the rules on the Include tab.

OIS comes with several dozen product-agnostic objects that perform a variety of functions; these are known as Foundation Objects. To expand and customize the functionality of OIS, you can add additional product-specific objects, contained in packages known as integration packs (IPs). There currently exist System Center IPs with product-specific objects available for each member product in the System Center suite, as well as more than 20 third party applications, including several network monitoring platforms and service desk products. You can register and deploy integration packs using the Deployment Manager interface. You can even download community-developed integration packs and policy samples from codeplex.com or the TechNet Gallery.

OIS policies will fall into one of two categories based on the first object in the policy:

  • An ad hoc policy is a policy started on demand by a policy operator, author or from another policy as needed. An ad hoc policy will run once, perform the tasks it is configured to complete, and terminate.
  • A monitor policy runs automatically or on a schedule, waiting for a specific condition to trigger further action. You can usually tell the difference between the two because a monitor policy will begin with an object that has ‘monitor’ in the name. For example, the policy shown in Figure 1 is a monitor policy, which runs perpetually.

TIP: Monitor type objects must always be the first object in the policy. Monitor objects are triggered by the condition they are monitoring for, not by another object.


Policies and Workflows…is there a difference?

You will often here the terms policy and workflow used interchangeably. However, this is not exactly correct. A workflow is actually an automation sequence involving multiple (nested) policies. 1`More on this in “Advanced Policy Features and Functionality,” in Part 2 of this series.


Data Publishing and the “Rules of the Data Bus”

OIS features a publish-and-subscribe data bus, which is the mechanism used within OIS to pass information from one object in a policy to the next object. The data flowing along the path of the policy is called published data, and each subsequent object in the policy adds its own data to the databus. As the policy progresses, more data becomes available. The published data capability of OIS is automatic and not configurable. Figure 4 illustrates policy execution and data publishing.

Policy execution and data publishing

Figure 4 - Policy execution and data publishing (concept)

The data collected or created by an object is automatically published to the OIS databus. As later objects execute, they can draw information from one or more previous objects. The policy author can subscribe to this published data and use it in the configuration of objects within the policy. For example, in the example policy shown in Figure 4, the Query Web Service object retrieves a SOAP message from a .Net web service, which is published to the data. The Query XML object is configured to subscribe to this SOAP message and perform a query to retrieve a specific piece of data within the message. Finally, the Write Results to SQL object is configured to subscribe to the XML query result and then write it to the database.

Every policy runs within its own windows process (PolicyModule.exe – shown in Figure 4) and the databus exists within this process. When the policy completes execution, the data published to the databus is lost. The number of data elements produced by an object, as well as the configuration of the object properties can affect how many times an object executes and how many data elements are in the object output. Here are some rules of the databus that describe object execution behavior in OIS:

Single Execution:  An object will run one time for each time the previous object runs.

Multi-Value Data:  An object will run one time for each data item generated by the previous object. For example, if you a Read Line object that retrieves five lines of text, the next object in the workflow will execute five times as well. If the next object in the workflow were a Send Event Log Message, five events would be logged to the Application Event Log (each with one line of data if the object is configured to subscribe to the line text output of the Read Line object). 

Flatten:  When you select the Flatten option, a multi-value data set will be consolidated to a single array with data items separated by the delimiter of your choice. The object that follows will run only one time. This is handy when you want to write a multi-value data set to a single Windows event or database record. For example, if you a Read Line object that retrieves five  lines of text and you check the Flatten checkbox, the next object in the workflow will only execute once,  so only one  event would be logged to the Application Event Log ( data if the object is configured to subscribe to the line text output of the Read Line object).

Multiple Executions: You can configure Looping on an object and enable multiple execution attempts. The Flatten option mentioned earlier does not affect an object configured to execute multiple times. In short, when Looping is enabled on an object and configured to exit only after five attempts, the object will run the requested number of times whether Flatten is selected or not. Figure 5 shows an example of Looping configured to allow multiple execution attempts.

Read Line Looping

Figure 5 – Looping configuration on a Read Line object

Which Processes Should I Automate?

A common question often heard when talking to customers and partners is “Which processes should I automate? Where should I start?

You could start by asking yourself a few of the more obvious questions:

  • Which processes are the most time-consuming?

  • Where are service levels suffering the most?

  • Which problems recur most frequently? Which are most expensive for the company?

  • Which process failures are visible to customers?

However, processes do not have to be inherently time consuming, complicated or expensive for OIS to deliver benefits. The fact of the matter is that any predictable or repetitive task a human can perform OIS can perform just as well, with greater consistency, speed, logging, and integration with change management processes. In addition, every process automated saves money and time, freeing administrators up for other tasks.

Next Installment

That’s all for this post. The next installment continues this discussion of OIS fundamentals, including:

  • Advanced Policy Features and Functionality

  • Testing and Troubleshooting Your Policies

  • Taking Automation to the next level with OIS and System Center

Join the Network World communities on Facebook and LinkedIn to comment on topics that are top of mind.

Copyright © 2011 IDG Communications, Inc.

IT Salary Survey 2021: The results are in