Introduction
Working with the Orchestrator system has some limitations that exist as part of the product, such as lack of 64-bit Powershell modules, undeveloped integration packages, a web console that supports a variety of browsers, and more.
The system currently offered on On-Premise as an alternative to Orch is SMA – Service Management Automation, SMA is different from Orch processes, SMA run on the Windows PowerShell engine, it can run and manage running lists for integration, orchestration, and business process automation IT.
It runs Powershell scripts when the system schedules these processes, the SMA itself does not have a GUI and the currently proposed GUI is the ‘Windows Azure Pack’ dashboard that connects to the SMA and allows the processes to be run and receive status for success and failure.
Customers looking to expand their Orch and SMA capabilities are migrating to Azure Automation
Switching from Orchestrator to Azure requires converting the processes using Activities from integration packs to PowerShell scripts to switch to Azure, while switching from SMA to Azure Automation is much simpler, because the scripts are ready and relocated relatively easily [Powershell scripts and Workflows].
As part of the transition planning, after learning all the technical aspects of the product, and understanding the ability to continue running on-premise processes through the creation of a “Hybrid worker” used by us as a “Runbook server”, we need to know in advance what the estimated costs involved in moving to Azure are.
Automation pricing
In Azure automation – process automation, the costs are in calculating the run time of the processes, so in preparation for the transition, we will export the ‘Runbooks run times’ from Orchestrator.
The process automation model has the option of running a job similar to Runbook, and is priced per minute, and Watcher gives the option of running a first process as a trigger and another process that is followed by an “action” that is priced at run time.
Orchestrator SQL Database query
To extract this figure, we can look at the history of the processes in the Orchestrator Database, what the last month’s running time is, averages over the past year, and so on.
How to simply extract the data from the DB over the past X days:
The POLICIYINSTANCES table combines the information from the POLICIES table, to see the run-time data for all processes, this query is calculated by the number of minutes and seconds, and the total number of seconds per process, as well as the total run-time of the processes that were run in the specified query, in case It’s 43800 minutes.
The Query:
Select
SUM(DateDiff(second, ins.TimeStarted,ins.TimeEnded)) as TotalAllRunbooksSeconds,
SUM(DateDiff(MINUTE, ins.TimeStarted,ins.TimeEnded)) as TotalAllRunbooksMinutes
from POLICYINSTANCES as Ins
inner join POLICIES on Ins.PolicyID=POLICIES.UniqueID
Where DATEDIFF(MINUTE,ins.TimeStarted,getdate()) < 43800
select
Policies.name,
DateDiff(second, ins.TimeStarted,ins.TimeEnded) as TotalRunbookSeconds,
DateDiff(second, ins.TimeStarted,ins.TimeEnded) / 3600 as Hours,
(DateDiff(second, ins.TimeStarted,ins.TimeEnded) % 3600) / 60 as Minutes,
DateDiff(second, ins.TimeStarted,ins.TimeEnded) % 60 as Seconds
from POLICYINSTANCES as Ins
inner join POLICIES on Ins.PolicyID=POLICIES.UniqueID
Where DATEDIFF(MINUTE,ins.TimeStarted,getdate()) < 43800
The result:
Total seconds and Minutes and the running time of each Runbook separately
