Orchestrator Integration Packs; Do it Yourself or Ready Made Integration?

Why Should I Buy An Integration Pack When I Could…

Kelverion Best Practices; Using a Persistent Data Store

It is Kelverion’s recommendation that in nearly…

Optimising Runbook Performance

Changing the maximum number of simultaneous…

System Center Orchestrator Best Practices Guide

A best practices guide and e-book for Microsoft…

Orchestrator Integration Packs; Do it Yourself or Ready Made Integration?

Why should I buy an Integration Pack when I could build my own solution?

The simple answer is it is quicker and cheaper to buy an IP than try and build and then maintain you own DIY solution.

Here we give you the information on what is required to build a DIY integration against what you get from a ready build Integration Pack and you can make up your own mind.


Many customers have made large investments in both Microsoft System Center and other Datacenter Management Tools.  Historically integrating these multi-vendors product sets has been challenging and time consuming.

With the purchase of Opalis (an IT Process Automation Solution) in December 2009 and the release of Opalis 6.3, but particularly with its replacement System Center 2012 Orchestrator, Microsoft has laid the foundations for a much easier and speedier interaction between product suites.

The challenge with any integration and automation product is keeping the interfaces to vendor products current and when a customer has many different vendor management products to integrate this only becomes more complex.

System Center 2012 Orchestrator makes the job of integrating multi-vendor management products together much easier due to its published databus technology, standard activities and its suite of ready to use Integration Packs.  These ready to use Integrations are provided as part of the System Center distribution by Microsoft and by Third Parties as chargeable options. 

In addition to these capabilities, in Orchestrator the User has the option to build their own Product Integration rather than use an existing Integration Pack.   The question is do you buy an Integration Pack or build your own solution?

Do It Yourself Integration What’s Involved

You can build your own integration to a third party application in Orchestrator using the Orchestrator Integration Toolkit. Most applications allow integration via a Web Service API and within Orchestrator you can utilise the Standard Invoke Web Services Activity. 

To create a DIY integration with a third party product you need to have completed the following tasks:

  1. Understand in great detail the Published API so that you know which methods to use interact with the API and know how the results will be returned to you from the API.  Know if you need to generate a Web Service Security Key before you can interact with the Web Service API to insert or extract data.
  2. Create a Pre-processing Runbook to generate the Security Key which has to be passed to the Insert Into or Extract From API Interaction Activity
  3. Create a Post Processing runbook to manipulate the output of the API extract call into a format which is easily useable within Orchestrator

There are also other considerations;

  • The published APIs to many third party products are not straight forward to understand and take a large investment in time and effort to comprehend
  • The APIs often change between version releases of the product.  If this happens it is now your responsibility to insure that your solution will work with the latest version of the target product, so you have to undertake detailed testing to prove that the DIY solution will still work.
  • The many post processing steps required in a DIY solution take time to execute in Orchestrator and so often a DIY solution is slower to operate than a full Integration Pack solution.  With a large volume of interactions this soon adds up and comes apparent in end to end performance and operation
  • Support and maintenance of the DIY solution is the responsibility of the person who built the runbooks and is therefore a large overhead and single point of failure in a DIY solution.

The Integration with a target system will be made up of an number of discrete interaction steps which ultimately form individual Activities in Orchestrator.

A DIY solution often takes 3+ days to create, per interaction you want to achieve with the target system.  This is fine, in principal, if you only want to do one or two simple interactions with the target system but if you are looking at say a Service Desk application as a target you won’t be looking at just one or two interactions, you will want many interactions; create incident, update incident, close incident, create change, update change, close change etc.

Before you know it you need 10 to 15 separate interactions and your project now becomes 30 to 50 days worth of effort and you haven’t even started to build the automation Runbooks yet.

Ready Built Integration Packs

Ready built Integration Packs are fully engineered integrations to Vendor Management Tools.  They install straight into Orchestrator and give you instant interaction with the Vendor product.  Now you only need to concern yourself with designing the processes in Orchestrator and not with wondering how to interact with the Vendor product.

The use of an Integration Pack relieves you of all the complexity of API comprehension and support and allows you to concentrate on building the end to end automated process in your Runbooks rather than handling individual product interactions.

By using a ready built integration pack even the most complex end to end process can be automated in Orchestrator in 30 days.  So using an ready built IP you have built your automation solution before the guy doing the DIY solution has even got his System Interaction working.


With System Center 2012 Orchestrator Microsoft have significantly simplified the integration challenge involved in a heterogeneous datacenter but the individual Management Tool APIs are still as complex as ever.

Understanding those APIs and determining how to interact with the individual methods is hard work and very time consuming.  The coding and Runbooks required to actually achieve the integration are highly intricate and labour intensive.  Then having just completed your integration the vendor releases a new version of their product and you have to start the testing and checking all over again.

Many people who choose a Do It Yourself integration path significantly under estimate the effort that will be required to create and maintain their integration.  A functional Integration takes significant time to create and then needs resource to fix and test per Vendor Product release to keep in step with the API changes.

At this point it becomes impractical to use a DIY solution over purchasing a ready built Integration Pack as the amount of time required to build and maintain the DIY solution is far more than the cost of the Integration Pack.

Download this White Paper