Opalis Runbook Automation Fundamentals (Part 2)

Part 2 of series discusses advanced OIS policy features and functions

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. This second installment in a three part series goes go a bit deeper into Opalis / Orchestrator functionality with a discussion of more advanced policy authoring topics:

  • Advanced Policy Features and Functionality
  • Testing and Troubleshooting Your Policies
  • Taking Automation to the next level with OIS and System Center

OIS includes a number of features that facilitate creation of more complex, modular policies, which are described here:

New to Opalis? Go back and read part 1 in the series before continuing.

Advanced Policy Features and Functionality

With the basics under your belt, it's time to explore some of the more advanced features of OIS. This section will touch a number of advanced policy elements, including:

  • Policy Nesting
  • Looping
  • Junctions
  • Data Manipulation Functions
  • Variables
  • Complex Link Logic (advanced branching) [coming in part 3]

Policy Nesting - You can initiate one OIS policy from within another policy using a Trigger Policy object. The policy being called is referred to as the child policy, and the policy that is making the call using the Trigger Policy object is known as the parent policy. It is possible for data to be passed to the child policy from the parent policy, allowing data from the child policy to be published for use in the parent policy.

As discussed in part 1, data publishing behavior at the object level is automatic. This is not the case when working with multiple policies. By default, no published data from within the child policy is visible to the parent; you must perform some additional configuration steps to make the output of the child policy available to the parent. For a look at how to configure data publishing between policies, check out this blog post "opalis: working around limitations with workflow objects and link operators" from System Center Opalis Integration Server 6.3 Unleashed contributing author Marcus Oh.

You will want to get familiar with Trigger Policy and publishing data between policies, because this plays an important role in OIS policy authoring best practices. This will be discussed more in part 3 of this series.

Looping -Looping allows you to build automatic retries, monitoring, and validation into a policy, and at multiple points within the policy if needed. OIS enables you to configure conditions to exit the loop. For example, if you wish to exit after a minimum number of executions or after a certain amount of time, you can select the associated "Loop" Common Published data on the Exit tab displayed in Figure 1.

Exit Tab Configuration in Policy

 Figure 1 - Exit Tab Configuration in Policy Properties

You can define looping behaviors on the Exit and Do Not Exit tabs in Looping properties. Note that the rules on the Do Not Exit tab always take precedence over the rules on the Exit tab.

  • The Exit tab shown in Figure 1 specifies the conditions that will determine if the loop will exit.
  • The Do Not Exit tab specifies the conditions that will cause the loop to continue.

Looping can be configured only available at the object level, not at the policy level. However, you can work around this limitation with the Trigger Policy object, as explained by Ryan Andorfer in his post "Looping a Policy."

Junctions - The Junction object enables you to configure a policy to allow multiple branches in the policy to complete before it continues past the Junction object. In addition, the Junction object can republish data from any one branch so that objects downstream of the Junction object can consume the data. Data from branches other than the one you select will not be available. You can also choose "None" to stop propagation of published data from any of the branches upstream of the Junction object if the data is not needed downstream in the policy.

For example, the Operations Manager maintenance mode policy in Figure 2 uses a Junction to ensure the Start Maintenance Mode objects for the Windows Computer, Operations Manager Health Service, and Health Service Watcher (HSW) have completed before attempting to restart the computer. A copy of this policy is included in the code download included with this article.

Maintenance Mode policy

Figure 2 - Operations Manager Computer Maintenance Mode Policy

Data Manipulation Functions - The data manipulation functions in OIS enable you to manipulate string, numeric, and date/time data from published data items or other sources, and convert this into a usable form. You can also perform arithmetic operations on numeric data, including addition, subtraction, multiplication, and division. For example, you can extract data from a text file using a text file management object, trim leading and trailing spaces from the text, and then retrieve specific parts of the text that you can pass to other objects as Published Data. Microsoft's article at http://technet.microsoft.com/en-us/library/gg440683.aspx provides a detailed description of all data manipulation functions.

Variables - As you are building policies, you may find there are values that are the same across different objects in multiple policies. When these values need to be updated, it becomes inconvenient to individually change each object. Variables act as a placeholder in your policies, enabling you to specify a value in one location and then use that value globally in any object. At run time, the workflow engine translates variables configured in an object during design time.

The funny thing about a variable in OIS is that it varies at all! A variable is almost always set to a static value, meaning a variable in OIS is much like a constant in common programming languages. However, there are two exceptions to the rule:

  • The NOW() function
  • System environment variables (such as %WINDIR%, shown in Figure 3)
Environment variable used as variable value

Figure 3 - An environment variable used as the variable value

You can read more about these special OIS variables at http://technet.microsoft.com/en-us/library/gg440631.aspx.

Complex Link Logic (advanced branching) - Links connect objects in a policy and direct the flow of activity and data within a policy. Links provide precedence between two objects. The default logic on a link between two objects is "Success." This means that if the object runs (regardless of result), the downstream object to which it is linked will execute. However, link conditions can provide sophisticated functionality for implementing complex decision flows involving text, numeric or time-related data.

Part 3 of this series discusses some of the possibilities of links and branching in depth.

Testing and Troubleshooting Your Policies

When it is running, every policy generates a log which you can view in the OIS Client. When you are viewing a policy, the Log and Log History windows will display the real-time and historic logs for the selected policy. The Operator Console allows you to view policy execution in real time:

  • The Log window displays the logging of the current run of the policy. The log displays when the Policy started, and the object currently running in the policy will have the running label beside it. The log enables you to determine if there are any problems with specific objects in your policy.
  • The Log History window, shown in Figure 4, displays all previous executions of the policy you selected. The time that the policy started and ended is displayed at the top of each log entry, and the result of each object execution is displayed for each entry.
Log and Log History tabs

Figure 4 - Log and Log History tabs in the OIS Client 

Double-clicking an object log entry in the log lets you view the result of the execution of that object. The Details dialog displays the Name, Type, Status, Start Time, and End Time of the object. If enabled, the Details dialog also enables you to browse the Published Data of the object when it was executed. Use this information when troubleshooting your policy.

During the development process, you can click the Test button in the toolbar of the OIS Client to launch the Policy Testing Console to test policy execution. You can step through the policy object-by-object in the Policy Testing Console, manually advancing through the policy objects and viewing detailed object output. Keep in mind that the Policy Testing Console actually executes the policy objects; this is not a theoretical execution. For example, if you test a policy that deletes records from a database, those records are actually deleted!

Notes from the Field: A common issue encountered by OIS users is a policy that generates a different result in the Policy Testing Console than returned when running the policy from the OIS Client. This is usually explained by user security. Policies you run in the OIS Client run in the context of the Action Server service account. On the other hand, policies you run in the Policy Testing Console execute in the context of your current user credentials. If your user account does not have the same permissions as the Action Server action account, some policies that successfully run in the OIS Client may fail when run from the Policy Testing Console.

Taking Automation to the next level with OIS and System Center

The System Center IPs for OIS deliver integration between System Center products for a variety of use case scenarios, including:

  • Incident Remediation (via Operations Manager 2007 R2)
  • Virtual Machine Provisioning (via Virtual Machine Manager 2008 R2)
  • Change Management and CMDB automation (via Service Manager 2010)
  • Backup and Recovery (via Data Protection Manager 2010)
  • Software and Update Distribution (via Configuration Manager 2007)

For example, the policy shown in Figure 5 interacts with Operations Manager 2007 R2 to automate incident remediation.

Sample Incident Remediation Policy

Figure 5 - Sample Incident Remediation Policy from Opalis Integration Server 6.3

Here is a high-level description of the steps performed in this policy:

  • The Monitor Alert object monitors for an alert titled 'DHCP Service Stopped'.
  • The Get Service Status object checks to verify the DHCP Client service is actually stopped.
  • If the service is running, a custom field on the Operations Manager alert is updated with a note indicating a false alarm.
  • If the service is stopped, the Start DHCP Service object restarts the service.
  • Once the service is started, the alert is updated with a note that the service has been restarted by OIS.

The objects from these IPs also can be used together to create advanced automation scenarios incorporating multiple System Center products in a single automation sequence. A copy of the sample policy shown in Figure 5 is included in the code download included with this article.

Next Installment

That's it for this installment. The third installment continues this discussion of OIS fundamentals, including:

  • Complex Link Logic (Advanced Branching)
  • Bridging the Gaps with PowerShell
  • Extending Your Capabilities with Community-Developed IPs
  • Policy Authoring Best Practices
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: The results are in