There's not a lot I miss about the Opalis Operator Console compared to the new Orchestration Console….however, there was one feature that is not present in the new OC. That is the ability to stop all Runbook Jobs. Whenever there's maintenance that needs to be done to the runbook servers or database, to prevent creating orphaned jobs, all running/pending jobs need to be stopped.
This is a job for the new web service and powershell! In my previous posts, I showed how to query runbooks that have a status of running or pending and how to stop/cancel a runbook job. This ties them together creating a workflow right in Orchestrator using a combination of the two to stop all running and pending jobs.
The runbook below queries jobs with a status of running and then invokes the runbook which actually stops the job. The query returns the necessary properties of the runbook to pass to the stopping job – jobID, RunbookID, and LastModifiedTime. I have another similar runbook that runs in parallel that queries for pending jobs and calls the same stopping runbook. These runbooks will loop until the total running/pending jobs = 0.
Be sure to exclude the runbooks that are running this workflow from the query or this runbook will stop itself :) . Here is an example of the url in the query script to exclude the runbookIDs of the runbooks which run the workflow.
$url = "https://scorch.domain:81/Orchestrator2012/Orchestrator.svc/Jobs()?`$filter=Status eq 'Running' and RunbookId ne guid'10000000-0000-0000-0000-000000000000' and RunbookId ne guid'20000000-0000-0000-0000-000000000000' and RunbookId ne guid'30000000-0000-0000-0000-000000000000'&`$select=Id,RunbookId,LastModifiedTime,Status"
Figure A
Figure B
In Figure A, I reset a counter and then run the powershell script to query for running jobs. For every running job it finds, it then increments a counter and invokes the stop jobs runbook. I also decrement the same counter in Figure B so that we know every runbook found was processed successfully. After the junction, we check to make sure the counter was decremented back to 0. Then we query for any running jobs again and publish that back to the main runbook that will loop until that is 0.
In Figure B, I implement the Standard Logging IP by Charles Joy to log the stopping script. This will allow parsing the table for failures and reporting at the end. As mentioned above, on success or failure, I decrement the counter again to ensure the running job was processed.
Now with one click to start a runbook, you can stop all runbook jobs again! I had to come up with another workflow to automate starting all necessary jobs again that run with a Monitor Date/Time activity from a Sharepoint list….but that’ll be saved for the next post.
No comments:
Post a Comment