Automation–System Center 2012 – Orchestrator Best Practice Series–Reduce Buried Logic

Hey Readers, welcome back to another post in the series on Orchestrator Best Practices. In my previous post Automation–System Center 2012 – Orchestrator Best Practice Series–Naming Conventions, I talked about Runbook and folder naming best practices as well as lightly touching on a concept called “DRY” or Don’t Repeat Yourself. This post was an important one to get you started with creating a structure that can assist in following the logic through the flow of your IT process automation Runbooks in Orchestrator. Again – there is always a better mouse trap (see this post in our “Just for Fun” track if you are curious ) but seeing examples on how other IT Pros use and construct their Orchestrator Runbooks seems to help solidify things for me sometimes – so give it a look and adapt your own “Best Practice”. The concepts covered in the previous post are worthy of a review as you move through your project of orchestrating orchestrator. You’ll likely rename, move, update, and tweak the structure up till the very end to ensure that it fits process flow and is organized in a matter that makes sense to you.

So What Am I Talking About in this Post?

Well, now that we covered how to get started naming and organizing your Runbooks, I thought this post could cover some details around how to avoid burying logic. What is buried logic? Buried logic is represented by anything that isn’t easily surfaced within your Runbooks and individual activities that may get impacted by updates or modifications to your Runbook(s). 

REDUCTION OF BURIED LOGIC

It is important to reduce any buried logic (when possible) to avoid adverse impact during future Runbook modifications. The next sections will cover a few areas to give you an idea on how to avoid falling into the buried logic trap and make your Runbooks more dynamic and easier to update as they change over time.

Types of buried logic we’ll focus on include the following:

• Data Manipulation
• Exit / Do Not Exit Loop Logic
• Link Logic
  • Include / Exclude Logic
  • Looping Exit Criteria within links

Data Manipulation

Data manipulation or field parsing is sometimes necessary to obtain data values embedded within strings for further processing in subsequent activities. In many cases these data manipulation processes are embedded as part of an activity that may not necessarily be apparent without deeper analysis. Ideally, these types of operations should be limited and optimized to avoid hidden logic and potential for broken Runbook execution due to updates. To illustrate what I mean by a data manipulation within an activity, take a look at the example below of a field parsing operation. In some situations, this type of parsing is absolutely required to get data to be represented properly for subsequent activities in your Runbook. Though the capability is there and is very powerful, it can many times get buried and be difficult to isolate as updates are made. As you can see below, the full field parsing details can be hidden from view unless a right click / expand is done on the field to show the operation. Again, this type of operation is great when used in moderation – just be aware and use wisely.

Exit / Do Not Exit Loop Logic

Another way to avoid buried logic is to take into consideration the use of Exit and Do Not Exit logic within loop operations. There are two ways to continue or exit a loop within an activity. The use of Do Not Exit logic can create unnecessary complexities in logic processing for the Runbook when combined with Exit criteria. In order to ensure simplicity for logic processing, Do Not Exit logic criteria while also using Exit logic should be avoided. This standard should be leveraged for every logic loop where possible to indicate the clear decision on looping or exiting. Ideally, create a standard and stick to it if you can. Consistency is key!

Link Logic

The following criteria on links should ideally be leveraged consistently throughout a Runbook hierarchy to help alleviate buried logic issues.

• Success / Failure of the previous activity to determine routing and what direction to take. Consistently handling success/failure/warning results of a previous activity and the movement down a particular path within the Runbook execution helps clarify direction at a glance. Any change in this standard could cause buried logic issues.
• Looping exit criteria implemented as part of the link criteria following loop. Keeping things as simple as possible, link logic following an loop exit should be exposed in the Include and avoid using the Exclude logic where possible. Buried decisions between Include and Exclude in combination could lead to orphaning the Runbook processing caused by circular references or no single evaluation to True.   Similar to loop criteria, links have Include and Exclude criteria to determine if the next activity will execute following the link. For simplicity sake, link criteria should be limited to Include logic and you should avoid using Exclude logic in combination with Include logic to ensure the logic isn’t buried. Links also have the ability to carry decision criteria on which direction to move in within a Runbook.  An example of a looping exit criteria shown below to give you an idea of what I’m talking about. As shown below, you can clearly define a state of “Running” and this link will only execute when the state is evaluated at True. If you also had a criteria buried in the Exclude criteria of “Not Running” or some other state, the result of this evaluation could have unpredictable results. Keep it simple and on the surface.

Summary

So in summary, what are we really saying here?

• Data Manipulation: Where you can, leverage native activities and avoid heavy data manipulation on data on the databus.  This isn’t always possible obviously but something to watch for and document as you are building your Runbooks to be dynamic, portable, flexible, and easy to update.
• Exit / Do not Exit Loop Logic: Where possible, avoid combining both Exit and Do Not Exit logic for loops.  In fact, just stick with Exit logic to ensure you don’t end up in an accidental circular reference.
• Link Logic: Establish clear guidelines for success / failure / warning criteria and path direction and stick to it throughout your Runbook authoring.   Any include or exclude logic should be consistently configured throughout your Runbooks to avoid logic issues due to buried excludes.  Stick with Includes as your go to logic for filtering decisions on links when you can!
• Consistency is key! I think I’ve said that enough in this post  - and to just make it easier, I made the text blue for you.  No matter what you do, consistently attacking the logic standards will be a huge help in the future as you go back and update or share your Runbooks.

Thanks for your attention on this second blog post in the series.  That’s it for now.

Till next time, Happy Automating!