Automation–Orchestrating Service Manager–Unexpected Activity Filter Behavior Workaround

Hello Readers/Viewers!

I realize it has been a little while since I posted, but I thought I would come back with a tip/trick that might just help your next Orchestrator / Service Manager project.

This post is all about a Runbook configuration that can be implemented, which will workaround some unexpected activity filter behavior.

But first, a word from our sponsor:

"Automation! You can’t have a cloud without automation because one of the driving principles of private clouds is minimizing human involvement. Two ways you can minimize human involvement is to provide self-service and the other is automation."

What is the Issue?

It is described a bit here: KB2821208 - Orchestrator 'Monitor Event Log' activity fires every time there is a new event, regardless of filters (https://support.microsoft.com/kb/2821208)

Obviously, KB2821208 is not specifically related to Service Manager, but I recently confirmed the same issue for the “Get Object” activity, at least for a specific configuration.

The following represent screen shots of the unexpected behavior:

1. Service Request and Activities (one Manual Activity, two Review Activities)

   • 
   • 

2. Runbook and Activities

   • 
   • 
   • 
   • 

   NOTE: The screen shot directly above was taken after a few tests. The first test I tried was with the “SC Object Guid” at the top of the “Filters” list. My second test was to switch the order, verifying it was not precedence causing the issue. Subsequent tests were attempted swapping out the secondary filter with different fields (Status, Severity, etc.). In the end, no configuration including two filters made any difference to the results – confirming the overall issue.

3. Execution Results

   • 
   • 

4. Observation

   • Interestingly, the Orchestrator Runbook Activity for “Get Object” leveraging the “Review Activity” Class from Service Manager contains fields (e.g. Priority, Severity, etc.) which show up as filter options, but no data actually comes through during execution time. So, this may be an indication that the filter isn’t actually failing, as the “Review Activity” Class doesn’t actually contain this object data. Either way, you will want to test your specific use case to see if the data you are looking for is available. If it is not, keying off of something else, or data from some other Class will be necessary. The following workaround will only work for field data that exists in the Class for the Activity being used.

What is the Workaround?

Use a link filter after the “Get Object” Activity (the Activity where the unexpected filter behavior is occurring) in the Orchestrator Runbook.

It would also be a good idea (for Runbook cleanliness) to remove the non-working filters from the “Get Object” Activity.

The following represent screen shots of the unexpected behavior:

1. Configuration

   • 
   • 

2. Results

   • 

   NOTE: The screen shot directly above illustrates that the LINK between “Get RAs” and “Send Platform Event” successfully filtered the execution and the Runbook was stopped as expected.

3. Observation

   • This is guaranteed to work, as the link logic is 100% based on Orchestrator Runbook logic and exists outside any specific Runbook Activity or Integration Pack.

For more information and tips/tricks about Orchestrating Service Manager, be sure to watch for blog posts in the Automation Track and IT Service Management Track!

enJOY!