Managing Microsoft

Kerrie Meyler

Previous Article Next Article

Opalis Runbook Automation Fundamentals (Part 3)

Last post in 3-part series discusses bridging gaps and extending capabilities

By Kerrie Meyler on Sat, 08/13/11 - 8:48am.

. What's this?

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. The final installment of this three part series delves into other Opalis / Orchestrator functionality, discussing these policy authoring topics:

Complex Link Logic (Advanced Branching)
Bridging the Gaps with PowerShell
Extending Your Capabilities with Community-Developed IPs
Policy Authoring Best Practices
Additional Resources

Opalis Integration Server (OIS) includes a number of features that facilitate creation of more complex, modular policies, which are described here. New to OIS and Orchestrator? Go back and read part 1 and part 2 in the series before continuing.

Complex Link Logic (Advanced Branching)

The default logic on a policy link in OIS is success, meaning that when the upstream object in the policy runs successfully, the next object in the policy is triggered. However, the filtering logic available in policy links lets you configure link conditions to evaluate published data (both numeric and string data) to add filtering and decision-making capabilities to policies. When an object runs, it can produce one or more data items. Each data item is evaluated by every link (attached to the source object), and each one of their link conditions. Only data items that satisfy the link conditions are passed to the downstream objects.

For example, the Query Database object runs and retrieves five rows of data from the database. These five rows of data will be evaluated by the link conditions. If only two of the data items satisfy the link conditions, the following object will run two times. That object does not need to subscribe to the previous object's data for this execution to happen. This was discussed in the "Rules of the Databus" section in part 1 of this series.

While the default link condition simply looks for successful execution of the previous object, more specific criteria can be configured - based on data output from the object-specific Published Data or through use of Common Published Data:

Date/Time Comparison: Allows comparison of date / time values including full date or date parts (second, minute, hour, month, year). Using the Include / Exclude tabs, you can configure a link to match a static date range.
Include / Exclude Logic: Link filtering includes both Include and Exclude tabs.A positive result (match) on the Include tab allows objects to pass while a positive result on the Exclude tab filters objects from passing to the next object.

Note: Or Logic is not configurable. If And Logic is needed, you can use a combination of Include and Exclude logic to create logic similar an OR statement.

RegEx Pattern matching on text-based objectoutput: If the output is a string, you can configure RegEx pattern matching including options such as an exact match and wildcard.
Numeric Comparisons: If the output is numeric, you can compare the outputagainst a desired value (equals, greater than, less than, and so on).
Matching based on multiple criteria: On the Include tab, you can check for multiple conditions. Since this uses OR logic, any matched expression will be considered successful.

Bridging the Gaps with PowerShell

When reading datasheets related to OIS, you will see mention of "without scripts" and "no scripting required"; these are true, most of the time. At some point, you will encounter an automation need for which there is no OIS object. Fortunately, OIS includes the Run .Net Script object as a Foundation object; this can run scripts written in VB.Net, JScript, C#, and Windows PowerShell. The Run .Net Script object is compatible with .Net CLR version 2.0 and later, and is an excellent way to create a custom object to bridge a feature gap when no object exists to address a specific need.

Understanding how to publish data from a Run .Net Script object is the key to using this object effectively. While you can process loads of data using PowerShell, by default no script-specific data is published from a Run .NET Script object. If you want to make the data output of your PowerShell scripts available to other objects on the databus, you must add each of the data elements that you want this object to publish on the Published Data tab of the Run .NET Script object.

Published data elements consist of three values (described here and shown in Figure 1):

Name: A label for the variable data being published.
Type: The data type contained in the variable (e.g. string, integer, or date/time).
Variable: The variable from within the script. This can be a variable containing a single value or an array of values. You can publish multiple variables from a single script, making multiple data sets available from a single Run .NET Script object.

Figure 1 - The Published Data Tab of the Run .Net Script Object

Data elements published from your PowerShell scripts in a Run .Net Script object can be single data items or data arrays. The Run .Net Script object automatically correlates multi-valued data from different items by aligning them. For example, if you choose to publish two items labeled "Name" and "Email" as collections, the Run .Net Script will try to line up each item in the Name collection with each item in the Email collection. If the collections are not sized equally, the Run .Net Script object will create blank values when it encounters a null value in the collection.

Note: The alignment of array data is demonstrated in the PowerShell scripted integrated policy included in the code download with this article.

An Example: Using PowerShell and Conditional Links in OIS Policies

A sample OIS policy demonstrating how to configure data publishing from the Run .Net Script object (shown in Figure 2) is available in the code download accompanying this article. This example will run in OIS 6.3 as well as the new System Center Orchestrator 2012 beta.

The policy shown in Figure 2 monitors for changes to a file containing wheat prices for cities in Texas, and logs an informational or warning event to the Windows Application Event Log depending on the price.
The Monitor File object monitors for changes to c:\labfiles\wheatprices.csv. If a change is detected, it triggers the next object in the policy - a Run .Net Script object.
The Run .Net Script object contains a PowerShell script that imports the contents of the file and publishes the city and price values using the techniques described in this article and shown in Figure 1.

Policy incorporating Run .Net Script

Figure 2 - Policy incorporating Run .Net Script and associated data file

Using conditional links, the policy follows the success branch (the green link) and logs informational event to the Windows Application Event Log for all cities for prices less than $2.
Alternatively, if the link data published from the Run .Net Script is greater than or equal to $2, the other conditional branch (the red link labeled 'GT or EQ 2') triggers the Send Event Log Message labeled Log High Price (Warning).

Note: Notice that the entry for Lubbock in the file has no price data (a null value). Try to run the policy in your own test environment to see how OIS handles the null value.

Extending Your Capabilities with Community-Developed IPs

There are times where you will encounter a scenario in which a Microsoft-developed integration pack (IP) does not exist. Fortunately, you can find many OIS IPs developed by members of the Opalis community and published on CodePlex (http://opalis.codexplex.com). A few of the more notable community-developed IPs on CodePlex include:

VMware vSphere: The objects in this IP map to a subset of about 25 of the PowerShell cmdlets in the vSphere PowerCLI. With objects like 'New VM,' 'New Hard Disk,' and 'New Network Adapter,' this IP is intended to facilitate automation of virtual machine provisioning in vSphere.
SCCM Extension IP: Currently in beta, this IP includes more than 60 functions that enable granular control over creating and modifying deployment-related objects, including collections, packages, programs, and advertisements.
System Center Configuration Manager Integration Pack Extension: This integration pack adds more than 50 objects to OIS for Configuration Manager 2007 (SCCM), enabling a variety of software, update and operating system deployment activities in SCCM initiated from OIS.
Service Manager Extension IP: This pack includes a number of objects to automate incident, problem, and change management. It focuses on work items that have slipped through the cracks - such as past due and unassigned change requests and unassigned incidents. It includes objects to close completed or resolved incidents, changes, and problems.

These are just the tip of the iceberg. You can find a complete list of OIS-related IPs and code samples on CodePlex at http://www.codeplex.com/site/search?query=Opalis&ac=8.

Policy Authoring Best Practices

There are a number of best practices to keep in mind when authoring OIS policies. Here are several:

Create Modular Policies: By creating smaller, modular policies that serve a specific function (such as error handling), you can reap a number of benefits:
- Reduced Complexity: Following the logic and branches within policies containing dozens of objects can be difficult. Using smaller nested policies (connected through use of the Trigger Policy object), you can ease the troubleshooting and ongoing authoring processes.
- Easy reuse: You can easily reuse policies in multiple workflows, minimizing the effort of rewriting activities you have written previously.
Establish Policy Naming Conventions: Work with your fellow administrators to establish naming conventions for policies, variables, schedules, and groups, and use description fields to add additional information. This should eliminate confusion about the purpose of objects and allow greater reuse across policies and among multiple authors.
Define a Folder Structure: Similar to policy naming conventions, using intuitive folder structures for policies, variables, schedules, and groups can eliminate confusion.
Export Policies Periodically: While OIS requires that you check policies in and out, it does not include a policy versioning functionality to accommodate rollback. On a recurring basis, export all your OIS policies so you can recover them if necessary.

You can find more information on policy authoring and publishing best practices in System Center Opalis Integration Server 6.3 Unleashed (Sams, 2011).

Additional Resources

OIS is a powerful platform for process automation and the native integration within the System Center suite ups the ante considerably. It is also a surprisingly easy product to learn. You can learn more about Opalis Integration Server at http://microsoft.com/opalis, where you can download the 180 day trial version and related product documentation.

You can find several System Center-integrated policy samples on the Internet, including:

You can also learn about OIS in depth by reading System Center Opalis Integration Server 6.3 Unleashed, which is now available for purchase. For a PDF version of the book, check out http://www.informit.com/store/product.aspx?isbn=0672335611.