By now, you may have read Tiander Turpijn’s blog series on how Service Management Automation (SMA) Runbooks can call Orchestrator Runbooks (and vice versa). If not, I highly encourage you to do so, as the scripts used in this blog post build on the concepts Tiander explained!
In this blog post, I will show you an application of this integrations points, where SMA and Orchestrator trigger each other’s Runbooks, and pass data along when doing so.
While it’s unlikely that the associated Runbooks will have a direct application in a production IT environment, it should still be a fun way to learn how both automation engines can call each other when needed!
The scenario and the output
Orchestrator and SMA are going to play a short ping-pong game.
At the beginning of the game, the score is 0-0, and then it goes to 1-0 or 0-1, and then 2-0, 0-2, 1-1, etc….
The winner is the first one to reach 3 points.
As the game progresses, a log file is being created, by default in the “C:\Temp” on the SMA server
How does it work?
It all starts with SMA, where a new game can be started. SMA will compute a ramdom number between 0 and a 100, and will call an Orchestrator Runbook, passing along this number.
We will see the SMA Runbook later in this post, here is the Orchestrator Runbook first:
As you can see, the SMA number is the only parameter for this Runbook:
Orchestrator then computes its own random number between 0 and 100, and compares it with the SMA number. The highest number determines a winner for the round. If the numbers are the same, SMA wins, being the youngest of the two
The Orchestrator Runbook ends by calling SMA back, and passing along the winner of the round:
The SMA Runbook being called is the same one we used to start the game. The Runbook expects 3 possible values for the “Winner” parameter : “SMA”, “Orch”, “New Game” (Orchestrator will always pass along either “SMA” or “Orch” as the “Winner” parameter, and “New Game” is only used when starting the game. To do this is a better and more explicit way, the “New Game” option could abd should have been a separate boolean parameter).
Here is the full PowerShell script for the SMA Runbook, and you can see how it processes new or existing games. More specifically:
- Lines 20 and 21 : We can see how score is being read and kept, by leveraging variables.This is one of the nice things with SMA, where you can also store data in variables, whereas Orchestrator only allows to read from variables (counters being the exception).
- Line 45 : We can see that Orchestrator is being called again for a new round, if a score of 3 has not been reached yet.
The different rounds can be seen in the Orchestrator events (in the Runbook Designer):
Do you want to try it?
Here is a download link. the ZIP file contains an Orchestrator export, as well as a SMART export for the SMA Runbook.
You should import both Runbooks, and update:
- The Orchestrator variables to reflect your SMA server name, and account/password to connect to the Orchestrator Web Service.
- The SMA variables to reflect your Orchestrator server name, Path to the Runbook you imported (if not imported at the root) and log file path (should you want the log file to be created elsewhere than in “C:\Temp”)
Note : The log file path directory must exist. The Runbook will not create it.
The two first variables below do not need to be modified. They are the variables used by SMA to keep tabs on the score during a game.
To start a new game between Orchestrator and SMA, you can go to your WAP administration portal, and enter “New Game” as the parameter:
Thanks for reading! I hope this helped you better understand how both engines can talk one to another, in a fun way.