When building runbooks you sometimes need to include a delay or a sleep. You can configure a delay on the links between activities, but it is not always a good solution. In the example in the image below I have a delay on each link. As you can see it looks like the runbook is on the first activity, but it is not, it is on the link, waiting. You don’t see the link as a step in the runbook and you cant see the link delay as a step in the history log either. A better alternative is to use a “wait” or “sleep” activity. In this blog post I will show you how you can build a “sleep” activity with Orchestrator Integration Toolkit. We will use a Powershell cmdlet named start-sleep and input number of seconds we want to sleep.
- Download and install the Orchestrator Integration Toolkit
- Start the Orchestrator Command-Line Activity Wizard
- On the welcome page click Next
- Assembly Details. Input a name a assembly file, for example ContosoSleep as name and C:\IP\ContosoSleep.dll as assembly file
- Commands. Click Add
- Add/Edit Command. Input
Name:Â Sleep
Mode: Run Windows PowerShell - Switch to the Arguments tab, click Add parameter
- Add/Edit Parameter. Input
Name: Number of seconds to sleep
Usage mode: Command Argument
Display Style: Text
Default value:Â <leave blank> - Click Ok
- On the Arguments tab, in the Command Line text field, input
start-sleep -s
then click Insert and Number of seconds to sleep
- Click Ok
- Commands. Click Next
- When you see “The wizard completed successfully” click “Build Integration Pack”
- Product Details. Fill in the information, for example
Product Name: Contoso Sleep
Category Name: Sleep
Company: Contoso
You can click Modify and change the icon. Click Next - Activities. Verify that your Sleep activity is listed, then click Next
- Dependencies and included files. Our example don’t need any extra files so click Next
- Orchestrator Integration Pack File. Input a path where the Integration Pack will be created. Click Next
- The integration pack is created. Click Finish to exit the wizard
Now, register and deploy the integration pack with Deployment Manager. After that is successfully you can restart your Runbook Designer console and you will see a new Integration Pack with your new activity.
As you can see in the image below we can now easy see that the runbook is in “sleep mode” as Sleep is its own activity. More examples with the Orchestrator Integration Toolkit can be found here. You can download my sleep IP here. ContosoSleep . Please note that this is provided “as is†with no warranties at all.
[…] http://contoso.se/blog/?p=2802 […]
[…] Link delays […]
[…] activities for the specified time. This is great, however as Anders Bergstrom has pointed out both here, the trigger delay functionality is difficult to track, as the pause is subsurface or does not […]
Hi, I am actually working on a blog post around that. Give me 1-2 Days and you will see it here on the blog.
Hi Anders,
I’ve been looking for a way to “schedule” a runbook from Service Manager. The case is that I want a request offering that will allow a manager to request the deletion of a user on a specific date. How do I ensure that the runbook activity is not started until the “planned start date” (being the date on which the user object should be deleted)? I don’t want a runbook to be “sleeping” for such a long time.
Thx
Fred
KILROY travels
Thanks for the Post Anders …. you showed me how much easier the QIK is than what I previously thought.
Sleep activity works like a charm after following your guide
Hi, thanks for reading my blog. Yes you could of course use run program, I wrote a blog post about Run Program activity some time ago, it could be a bit trickey to use. .NET script also work.
Update on my previous comment:
I tried doing what I described on a test environment and ran into some weird behaviour, but then realised that it could be even easier done with a Run.Net-script Object (Language: Powershell, Script: start-sleep -s {parameter}. That worked like a charm, although on my test server there was some overhead adding a few seconds to the specified time-out duration.
Hi Anders,
Excellent example of leveraging an integration pack to provide clarity in your runbooks/policies.
Sadly, it will not always be possible to introduce a custom Integration Pack to an environment for technical or even political reasons.
To still achieve the goal of using non-link delays and those advantages, I think a “poor man’s” alternative would be to simply use the “Run Program” object in command execution mode with “powershell start-sleep -s {parameter}” as command to run.
– Alain
DB Able