Continuing our series on Orchestrator, if you have being following the previous posts in this series you should now be ready to get acquainted to the Runbook Designer. As a reminder these are the topics we have covered to date:
Let’s get comfortable as we introduce Orchestrator’s Runbook Designer, because this is the single tool in which we are going to spend the majority of our time as we design and debug our runbooks.
Orchestrator’s primary beauty lies within the Runbook Designer, a GUI-based tool that will instantly look and feel rather familiar to anyone who has ever used Visio, or most graphic design packages for that matter. Creating your runbooks is accomplished by simply drawing your task sequence on the design canvas, dragging predefined actions (called “activites”) from the Activities pane, and dropping them on the design canvas. You then “wire” up your activities through the use of links, enabling you to define the flow of your runbook.
In the above screen capture of Runbook Designer, we can clearly see and easily identify the main areas of the interface as follows
|Connection to the Orchestrator Environment, and a tree structure for managing and organizing our runbooks. Access permissions can be assigned on a folder or runbook level from the properties dialog.
|The Design Canvas, to the top of the canvas you will see a tab for each runbook stored in the folder. The Icon prefixing the runbook name will confirm if the runbook is checked out for editing and testing (Pencil and Paper), checked in and ready for execution (Parent Child cubes), or currently Executing (Green Arrow).
|This pane is also tabbed from the bottom, offering access to the logs, log history, audit tail and event notifications all of which are scoped to the context of the currently selected runbook in the design pane.
|Home to all our Integration Packs and their respective Activities, this area is by default sub-divided by Integration Pack. Once selected, it automatically expands to present all the activities stored within the pack. These activities can be dragged and dropped directly onto the current design canvas when it is in edit mode (Checked out).
As you being to design your runbooks, you will have two basic types of activities available for your use, these are Action and Monitoring activities.
Monitoring activities: Although not as common in the collection, these are very powerful activities. Their purpose is to monitor for something to occur, and once detected, to proceed to the proceeding activity in the flow. Referring back to our screen capture in the activities pane, we are exposing one called Monitor Folder, the purpose of which is to… well, you guessed it, monitor a folder for a change and then trigger any proceeding activities in your runbook. As you will appreciate, this type activity can expose enormous potential. Some examples of additional monitor activities included in the various integration packs are Exchange Mailbox Monitoring, SharePoint List monitoring, and others as simple as date and time monitoring to schedule activities.
A runbook is simply a collection of activities that are associated in a logical manner to accomplish a task. Complex tasks are often broken into multiple runbooks, so that repeatable processes are defined just once and triggered from other runbooks, allowing easy creation of a collection of modular runbooks. This is very common, for example, with reporting and logging. Similar to activities, runbooks also allow you to define your own parameters, enabling you to pass information to and from other runbooks. In the sample image, we could pass in the file name and folder and return back the path and name of the processed file.
Defining the flow of our runbook, we create links in the design canvas between our placed activities. These links are used to pass the execution data between the activities, and the link utilized can be determined by virtue of the data that is currently passing between two activities. This link data, is referred to as the data bus or pipeline, and it contains all the execution data for each activity in the runbook as they are triggered in sequence.
Considering our sample runbook again, our first activity initializes the runbook, and it might accept the input values for the file name and folder of the file to be archived. This data will be passed over by the data bus to the next activity, which in this example is DateCode Delta File. This Rename File activity requires three data items to function: the “folder of the file,” the “current name” of the file, and the “target name” of the file, each of which can be assigned from the information on the data bus. Once this activity has completed, there are two possible outcomes: It successfully renamed the file or it failed. In either case, we can easily decide how to proceed, and we can also use any new information that the activity may publish on the data bus for any subsequent activities in the runbook; for example, we may now have access to the file size of the renamed file.
It is important to realize that the same runbook may be running multiple times simultaneously, especially as you begin to build modular runbooks. However, Orchestrator ensures that the data bus is kept private to the specific instance of the running runbook, enabling a truly scalable and modular system, and removing all concerns from you the designer about dealing with runbooks running simultaneously.
Now, that we have a good feel for the designer, covered the process of deploying additional integration packs, and started to learn the potential power of the data bus, I think it’s about time that we got going with creating our first real runbook. Check back for the next post in the series, and we will do exactly that!