System Center Service Manager (SCSM) and Orchestrator (SCORCH) integration and using the SCSM self-service portal (SSP) as a front-end to Orchestrator

Alrighty, that’s a real long, loaded name for a blogpost, but hopefully it does what it says on the tin  

Please note this post focuses on the techniques / mechanisms required.

For more detailed walkthroughs, please go to https://aka.ms/stayclassyonboard or https://aka.ms/stayclassyprovisionvm for 2 complete detailed examples

SCENARIO AND DESIRED OUTCOME:

A lot of the time folks will want to run some cool time / money-saving automation magic in orchestrator, but they are missing a tool that will take required inputs from a user and pass them into Orchestrator.  Well ladies and gentlemen, here is the best tool available for this: System Center Service Manager and the new shiny all signing-dancing HTML Portal!! :-)

The desired outcome is to prompt for the required values:

An then we pass 5 values such as VM NAME, VM IP, datacenter name, cluster name and cluster LUN to a runbook:

In the above example, we just take those values and create an event in Orchestrator (platform event) showing those values.  But there is no reason why you cannot take those values, and use them in a run.net script (powershell) activity, configman task sequence, SCVMM / VMWare activity or indeed any series of activities you may ‘craft’ together in an Orchestrator runbook.

First of all you can check out some info on the new portal here: https://blogs.technet.microsoft.com/antoni/2016/04/06/the-new-html5-based-self-service-portal-ssp-in-system-center-2012-r2-service-manager-ur8/ 

And then once you're acquainted with our new portal, here's some more information on how you can integrate orchestrator with it.

We will examine 3 approaches here, but ultimately for simplicity and avoidance of limitations, I always recommend approach 3 (and deluxe if needed), so if you want to skip to the best way (and especially if you have not played around with any of this before), I recommend you go straight to approach 3, and start there.  Alternatively, you can go to https://aka.ms/stayclassyonboard or https://aka.ms/stayclassyprovisionvm for 2 complete detailed walkthrough examples.

• APPROACH 1) Allow SCSM to automatically map Runbook Automation Activity Properties (SCSM) to Initialize Data (SCORCH) parameters
• APPROACH 2) Map prompt outputs to OOB Work Item (IR/SR/RA/MA) Properties and access these within Orchestrator using the RBA Activity ID as the entry point and one passed initialize data parameter.
• APPROACH 3) Use the SCSM Authoring Tool to extend (EXTEND OR INHERIT FROM – ) a work item class with the desired custom properties, Map Prompt outputs to these custom properties and then access these within Orchestrator using the RBA Activity ID as the entry point and one passed initialize data parameter.
• APPROACH 3 ‘DELUXE’) Same as Approach 3 but we also use some custom Configuration Item classes to do achieve the query filtering.

Let’s drill down on each of these approaches.

APPROACH 1) Allow SCSM to automatically map Runbook Automation Activity Properties (SCSM) to Initialize Data (SCORCH) parameters

When you have an initialize Data activity in Orchestrator, you can have a number of parameters in here.  For example:

When created these parameters in Initialize Data, they can be either a string or integer ‘parameter type’ (the significance of this will come to light further down, as will why I have 10 string parameters and 5 integer parameters):

Once you've synced this runbook with Service Manager and created a Runbook Automation Activity template (In Library>Runbooks) based on it, you will see these parameters you created show up in the runbook tab:

Notice here how these values are AUTOMATICALLY (no configuration done on my part for this) mapped to the OOB runbook automation activities properties Integer1, Text1 / Text2 etc.  The same happens for up to 10 string properties and up to 5 integers that you can have in the ‘initialize data’ activity.  If you create more Initialize Data parameters than this, you will be unable to save a template based on this runbook.

Given that this mapping takes place automatically (you cannot map set the mapping of prompt output to property yourself in the Request Offering ‘Map Prompts’ page like you can with other work items such as SR / IR / MA / RA)  This means that unfortunately there is no way to take advantage of the other properties that are part of a Runbook Automation Activity: Longtext 1-5, DateTime1-5 and boolean1-4.

One thing that may surprise you however (it did me ) is that you can map any of the following types of prompts (String, Decimal, Integer, SimpleList, String or Boolean(true/false))to a ‘text’ property:

Integer prompts can be mapped to an Integer property.  Even though it looks like you can map a decimal to an integer, if you configure a decimal to be mapped to an integer, you’ll get this when you try and submit the request:

So decimals need to be mapped to a string / text property.

So to recap, with this approach, you can pass 10 text prompts to properties text1-10 and 5 integer prompts to integer1-5 but this mapping is done automatically.  The bit you can control here is which prompt is mapped to which of these 15 properties (on the map prompts page of the request offerings)

The three big limitations here are as follows:

1)  You’re stuck with the property names like integer1 / text1 etc which can make things a little difficult to manage as you want to use these values in Orchestrator / Views / Reporting etc.

2) MP enumeration Lists (A value selected from a list in Library>Lists) cannot be passed to these parameters

3) You are limited to 10 text and 5 string fields.

APPROACH 2) Map prompt outputs to OOB Work Item (IR/SR/RA/MA) Properties / Relationships and access these within Orchestrator using the RBA Activity ID as the entry point and one passed initialize data parameter.

If you want to avoid use of the authoring tool and / or extending classes, and have spare OOB fields in a work item (Alternate Contact Method for example) you can map your prompts to those fields.

The big limitations here are as follows:

1)  You’re stuck with the property names like Alternate Contact Method etc which can make things a little difficult to manage as you want to use these values in Orchestrator / Views / Reporting etc.

2) You are limited to OOB fields that you may be already using or wish to use for their original intended purpose.

APPROACH 3) Create Custom Properties in the Authoring Tool, and map to those and or OOB Relatiosnhips

Create Custom Properties in the Authoring Tool,

Map the prompts to the custom properties and  / or OOB Relationships

Pass the unbook Automation Activity ID into a single-parameter initialize data in Orchestrator

Use the Get Object and Get related Object Activities inside Orchestrator to get to the properties you want.

If using this approach, be sure to understand the difference between inherit and extend as listed at the base of this article) and then add the required properties you wish to prompt for.

The benefits of this approach are as follows:

1) You get to control the property names, making this a lot easier to manage

2) You can do this for any property as all property types are available in the authoring tool.

* You can use the ‘Create Relationship’ button in the Authoring  tool to create a custom relationship, but I have seen problems with doing that before, both when trying to pass these values from some of the 3rd party portals and it also requires some XML hacking to configure a Query results field to store to a custom relationship

** Incidents and Service request have a default area where file attachments are saved to.

APPROACH 3 ‘Deluxe’) Add Custom Configuration Item Classes to the mix

Now lets say that you want the ability for one field in the portal to depend on the selection in a previous prompt. So when creating a Request Offering to allow self-service requests for VM creation,  you want to first choose datacenter, then Cluster, and then Cluster LUN.   You want the clusters to be narrowed down to those available in the selected cluster, and You want the LUNs to be narrowed down to those available on the selected cluster.

Now we need Custom CI Classes.

See this detailed example for more detail on how to implement this:  https://aka.ms/stayclassyprovisionvm

NOTE: This is an EXTREMELY simplified example but maybe you would have other properties in any of these such as Cluster FQDN as an additional property or LUN Volume Path in as an additional property of CLUSTER LUN.  Anything that needs to be passed to SCORCH or displayed to aid the user’s selection should be added as an additional property. 

NOTE: You will want to designate one of your properties as a primary key so figure out what is unique ahead of time.  If needed create your own ID property like Cluster LUN ID etc.

If you create custom classes like this you can use the ‘token’ option in the criteria page of the request offering, such that the available values in each prompt match the criteria.

For example as shown below, part of the Cluster LUN’s Cluster TAG property contains the Cluster Display Name for the Cluster that was chosen in the previous prompt.

You can Store each of these objects in an OOB relationship in the CI and then get to each of these using a string of Get Related Objects Activities in a runbook and then pass these to Orchestrator.

Refer to the more detailed example for more details on this: https://aka.ms/stayclassyprovisionvm