Integrate Applications with Service Manager
When I work on client projects, I’m commonly asked “Can we integrate applications XYZ with Service Manager?” That immediately gets the wheels turning for me to come up with a solution that takes two different systems that know nothing about each other and teaches them to communicate.
With any integration, the first question you are asking yourself is what options are available as far as how systems communicate. From a Service Manager perspective, we generally have 4 options to integrate applications.
Option 1 – C#
The first is directly interacting with the Service Manager SDK. This would rely on building some sort of C# solution that can access both systems. If you do not have that expertise or the internal resources, this option would be the most time intensive and have the steepest learning curve. I would consider this the most advanced implementation.
Option 2 – Cireson Portal API
The next option is by using the Cireson Portal API’s. These can be called from any external source that can send GET or POST commands to the Portal API and receive/process the response. This is a pretty good option as most systems today can interact with Web APIs. These Cireson Portal APIs end up talking directly with the Service Manager SDK and can be used to do most anything in Service Manager. We also have a bunch of documentation on this topic that can be found here.
Option 3 – Orchestrator Web Service
This is another option that can leverage a REST API as well. You would create a Runbook in Orchestrator which then automatically exposes it via the Orchestrator Web Service. The Runbook you create would then interact directly with Service Manager to complete whatever it is you need done.
Option 4 – PowerShell
There is always PowerShell, right? If your external system can call a Script, you can leverage PowerShell to interact with Service Manager. You basically have 2 options for PowerShell which are highlighted in this blog post series, here. If you go this route, I highly suggest giving this series a read.
Integrating IdentityNow with Service Manager
I recently completed a project that required the integration of IdentityNow with Service Manager. Following the chart above for the case of IdentityNow, it was determined that we could leverage the calling of a PowerShell script to do our work in Service Manager. That system uses rules that can initiate a PowerShell script from an IQService server. These rules are triggered after an Identity (Active Directory in this case) has been created or modified. They can initiate the PowerShell script and send the Request Information as a Parameter. This request information is stored in XML which can be deconstructed to get the Identity that was created or modified. If you take a new user creation in Active Directory as an example, that Identity would be created in IdentityNow.
Once created, a rule would be triggered that passes this new Identity information to a PowerShell script on the IQService server. That script would first look at the XML sent in and figure out the user that was just created. From there, you then connect to Service Manager in that same script and initiate whatever process or action that is tied to a New User being created in Active Directory. In this case, we go ahead and create a User Configuration Item in Service Manager and then kick off an Onboarding Service Request Template that handles the remaining items that need to occur for this new user.
Would you have chosen the same option to integrate applications?
There are various ways to integrate applications with Service Manager. Which one you choose really comes down to which one you are most comfortable with and which one your other system can support. In the case of IdentityNow, the calling of a PowerShell script fit because it can call scripts via rules. When it comes to integrating with Service Manager, the question should not be if, rather it’s a question of how.
