Creating Change Requests from Service Requests using System Center Orchestrator

Author by Nathan Lasnoski

I was working on several different engagements where I needed to map relationships.  A particular example is where I need to map relationships from one request to another request (such as a Service Request to a Change Request).  In our example, we want to open a Service Request to gather information from our end user, use the data to make a decision, then map that data into a Change Request.   The starting point for our request process is to gather information and construct our templates.  We'll need to create the usual Service Manager 2012 components, including:

  • A Service Request template
  • A Change Request template
  • A Service Offering

  In my case, I'm gathering information from the customer using my Service Request, then sending the request information into the Change Request.  You would use this process for any Change Request with Service Manager, as Request Offerings are only used with Incidents and Service Requests.  Since we likely want to use the self service portal for Change Requests as well, I like to use Service Requests to gather Change Request data, then use the data to intelligently create a Change Request.  Pretty cool, eh?    As with every Service Manager integration, we'll start with initialize data:     You can see this maps up to the runbook which was synchronized to Service Manager through our Orchestrator connector.  Note that every time you modify the initialize data fields you will need to delete and resynchronize your runbook.  This is intentional to protect the integrity of the data transfer in automations:     Then we'll get the runbook using the ID.  We'll be doing this to pull additional information from the Service Request.  You use this technique to pull data from within a Service Request where you haven't already mapped the fields in the initialize data process.     Next we'll get the Service Request GUID.  This will enable us to get the Service Request itself.     Next we'll get the Service Request.  We'll use the Service Request to get its related items so we can map them to the Change Request (which we'll create).     Following getting the Service Request we'll create the Change Request.  There are a couple things to specifically note here.  First, you need to make sure your Change Request has a title.  Second, if you want your Change Request to have the correct naming convention, you'll need to set it here.  You'll see that I'm using the CR{0} structure, which will create CR with the appropriate ID.  This is the same structure as the SDK.  If you don't set the CR you'll have a really inconsistent CR naming.     Next we'll create a relationship between the new Change Request and the Service Request.   You'll see that the source class is the Change Request and is mapped up to the source object GUID.     Next we'll get the relationship of the Service Request and its related configuration items.  This will enable us to map the configuration items to the change request.     Finally we'll relate the configuration items from the Service Request to the Change Request.      I hope this was helpful .  This should show you how to bring initialized data into the Orchestration, retrieve data using the ID, as well as creating relationships and new objects.   Happy automating!   Nathan Lasnoski

Author

Nathan Lasnoski

Chief Technology Officer