Exploiting Orchestrator - Tips to avoid the hidden bear traps

Following on from my last post about getting started with System Center 2012 Orchestrator, I asked a good friend of mine Greg Charman from Kelverion, to share some of his experience.

 

System Center 2012 Orchestrator and its predecessor Opalis 6.3 are a very new subject to many IT Professionals and using IT Process Automation tools is not just as easy as install them and then learn on the job. Each ITPA tool is fully customizable to support the business process you wish to implement so they largely start as a blank sheet of paper.

It is very easy to install Orchestrator or Opalis and create simple workflows but very quickly people find themselves hitting problems when they want to do more complex activities like branching, looping, persisting data and monitoring process completion. There are pitfalls to be avoided when implementing the solution and although some information exists, the reasons why you should avoid these and the correct approaches are not so well documented.

After more than 4 years of using and implementing Opalis and Orchestrator I have learn what to do and not do to make the implementation successful. Some of the key points for success are as follows.

Things to do before you start:

1. Configure the Designer Client – in Orchestrator and Opalis you can define the behaviour of the Runbook/Policy Designer Client. There are a number of settings you can adjust but the key ones you want to set are;

• Turn on Show Link Labels – Then you will be able to see the Labels that have been added to the Links in the runbooks
• Turn on Automatic check out – The benefit with Auto Checkout is that it is easy in Orchestrator to make modifications to a Runbook and then find you haven’t checked it out which means all your changes are lost. Orchestrator does not prompt you to Checkout if you try to make a change.

Things to be avoided:

1. Counters - Never use Counters in Orchestrator as they are Global Counters and can thus be modified by any Runbook at any time. You cannot therefore rely on their value at anyone point unless you are running in a Single Thread. This defeats the fundamental benefit of Orchestrator - parallel execution and multi-threading.

2. Variables - Variables in Orchestrator are also Global. When you export a Runbook all the variables in Orchestrator are exported not just the ones in use in the Runbook, it is therefore very easy to pollute your installation with variables gained from imported Runbooks. Therefore use them sparingly; they are ideal for Database Server Names, Table Names etc.; which will be used in many runbooks.

3. Text Files for data storage or processing – using text files for persisting data or data manipulation in a Runbook is a recipe for disaster. Text files can only be accessed by one process at a time, the file is locked whilst interaction takes place, you therefore force Orchestrator to become Single Thread. This defeats the fundamental benefit of Orchestrator - parallel execution and multi-threading. You will also find you will do a huge amount of post processing manipulation when you try and extract the data back out of the text file and the post processing is not a simple or pretty activity to implement in Orchestrator.

Best Practices:

1. Implement Orchestrator with a Runtime Database – if you want to persist data, have a run time variable in a Runbook, dynamic input data, complex look up logic, audit History, you are struggling to parse data or have got XML/CSV as an input or have got to manipulate the data, then put it in a Microsoft SQL Server Database and use the Database Activities to process it.

Why put it in a Microsoft SQL Server Database? Because all the database objects are much more powerful against Microsoft SQL than any other database type.
You design this database to meet the needs of the IT Processes you are automating in Orchestrator and the needs of the Runbooks you are creating.

2. Keep Monitor Runbooks very short - Got a Runbook which starts with Monitor some enterprise tool and when new/update event do something?

Keep the workflow very short for maximum performance. Grab the event and write it to a Microsoft SQL Server Database and use a Database Activity to process it. This way there is less chance of Orchestrator missing a new event because it is still busy processing the last set of events.

3. If you are not already a database guru then Kelverion also offers a Database Integration Pack for Orchestrator and Opalis, which gives you easy script free interaction with databases from within Orchestrator or Opalis and formats the columns selected from a Database Table into individual items of published data – no more need for the dreaded [Field(…..)] statement.

Summary

It is difficult in a blog to emphasise how powerful Orchestrator becomes when implemented with its own run time database. There has been nothing I haven’t been able to achieve using Orchestrator and a runtime database but there has been many instances where things could not be achieved if a database was not in use.

There is a good Microsoft MVP book by SAMS press called System Center Opalis Integration Server 6.3 Unleashed which provides information and guidance on Opalis implementation. Although written for Opalis all the principals apply to Orchestrator.

If you don’t fancy learning everything from a book or you would like more hints and tips then Kelverion provide a range of training courses and offer bespoke training offering based around specific customer requirements. Kelverion is an established systems integration and software development organisation specializing in IT Process Automation solutions, founded in April 2010 by previous employees of Opalis.

For more information on Kelverion Training and our other offerings got to www.kelverion.com/itpa