Extending on our series’ on automation and orchestration, we’re going to look at building a web portal to allow us to safely delegate tasks to other teams or individual users. We’ll look at System Center Service Manager, given that many organisations already have a license. This approach could be taken with countless other tools however.
Here’s a screenshot of what we’ll end up with:
We’re essentially going to be walking through the items in the Service Catalog Checklist inside the Service Manager Console application:
First, we’ll create a management pack, which will give us a container to store the rest of the components we’ll create. We do this to allow us to more easily port this between Orchestrator instances (think development vs production as an example). Under Administration, right-click Management Packs and select Create Management Pack. It just needs a name and a description:
We’ll select this management pack whenever prompted for a management pack in subsequent components and that will keep them all neatly together.
Next, we’ll connect System Center Service Manager to System Center Orchestrator. This connector will allow you to call Orchestrator runbooks from inside Service Manager workflows. If you haven’t finished all of your runbooks (we’ll be adding some as part of this series), don’t worry. We can always add more and then sync Orchestrator and Service Manager after.
We create and label the connector:
We then point it at the System Center Orchestrator web service (on TCP port 81 by default), giving the credentials of a user who is allowed to run Orchestrator runbooks. Note that the Orchestrator Web Service URL has a path of Orchestrator2012/Orchestrator.svc even if you’re running Orchestrator 2016 (as I am below).
You can also provide access to runbook information (optional) by including the Web Console URL too. This is on port 82 by default.
In order to call our runbooks, we need to define a Runbook Activity Template. Select our management pack and make sure that the Class is set to Runbook Automation Activity.
This will open the template form dialogue box, where we set a few parameters….
…. and most importantly, the runbook that we wish to be executed. In our case, we’re selecting a runbook that has no input parameters (we’ll cover the runbook itself in the next article in the series). If you had parameters to pass in, you would map those here:
To expose this to our end users, we create a Service Request template. What we add here will be visible as task items that users can request. In our case, we’re going to create one to allow our end users to request the ability to restore files from the previous day’s snapshot:
In the template form for this SR, do hit the ‘+’ sign to add an activity and select the runbook automation template that we created earlier. It’s possible to add other activities here too to have things like approval performed for cases where that might be necessary.
This covers all of the plumbing for the backend connectivity to the automation and orchestration infrastructure. Next we need to package this all up into something consumable by the users of the self-service portal in Service Manager.
To do this, we package up the individual activities as Request Offerings. Each of these will be a clickable button to allow users to trigger an activity. We’ll also create a Service Offering to group these activities together in one place for a given set of users. There’s a screenshot of the finished product at the end of this page.
The Request Offering should use our File Level Restore template that we created earlier and should be added to the management pack we created. Had we had any inputs to our orchestration runbook and template, we would also configure user prompts and inputs here too.
Our Service Offering is the collection of Request Offerings we plan to publish together. Create it with the relevant labels, icons and knowledge articles, and as with everything else, add it to our management pack.
We also select all of the Request Offerings we want to include as part of this Service Offering. At the moment, we only have the one Request Offering we created above, but if you had already created others, you could add/include them all here:
And here’s a screenshot of how the finished product looks in the Service Manager Self-Service portal:
In the next article, we’ll go through the details of the orchestration workflow. It will use the template that we created in an earlier series with a few minor changes. At that point, it’s a case of replicating the workflow in this article and the automation/orchestration piece, and you can add any number of self-service tasks to make your end users more self-sufficient.
All of this could apply equally to placing useful functionality in the hands of helpdesk staff to delegate common tasks as you scale.