ServiceNow Integration

Note: this article assumes you are already somewhat familiar with ServiceNow Change Management process, or a similar tool.

As some of you may already know, before joining Codefresh I was a Business Process Consultant (BPC) at ServiceNow for their DevOps application. So obviously on my to-do list from day 1 was to create an integration between Codefresh and ServiceNow. In case you’re not familiar with ServiceNow, they’re known for digitalizing enterprise processes and for their portfolio around IT Service Management. In their words, they “Make the world of work, work better for people”.

Recently, a couple of customers have requested an integration with ServiceNow Change Management solution, so it was time to get busy. The use case was very similar for those customers:

Automatically open a Change Request in ServiceNow from the Codefresh pipeline
Pause the pipeline until the Change Request has been approved or cancelled
Continue or stop the pipeline

For this first tentative, the decision was made to forgo the DevOps application to speed up the development and not force our customers to a specific solution. I will revisit that aspect when we have more demand. If you are already using ServiceNow DevOps, please reach out to your Account Exec to engage the ServiceNow partnership team, so Codefresh can sign up a technical partnership with ServiceNow.

Change Request creation

I decided to simply create a Change Request using the Table REST API. As in my experience, the Change process is heavily customized. This allows me to abstract that complexity. So simply pass a JSON body containing all the fields you need to open a Change Request.

Once the Change Request is created, Codefresh is able to get the Change Number as well as the sys_id. I do not use the sys_id in my current implementation, but it will allow you to update the Change request later on in the pipeline (required to change a record with a PATCH REST call to API /now/table/change_request/{sys_id}).

Callback preparation

The tricky part in my opinion was to design a mechanism for ServiceNow to callback Codefresh to approve/deny the pipeline. On one hand, it’s easy as Codefresh has an API for such action, but it requires the build id (CF_BUILD_ID). I could not come up with a satisfying solution for adding this id to the Change Request created (and adding a new field is a battle I don’t want to fight with Change Managers and ServiceNow developers).

Therefore, I created an update set that contains 3 pieces:

A subflow to manage the Change Request lifecycle
An action called from the subflow above to callback Codefresh
A Scripted REST API called from Codefresh to start the subflow

The reason behind the decision to use an update set instead of an application is that I’m not an official developer, and I thought having it in the ServiceNow store would be difficult. The update is available at https://github.com/codefresh-io/steps/tree/master/incubating/service-now/xml/ for easy access.

Let’s look in more detail at those pieces.

Scripted REST API

This is the point of entry. It will be called using a POST call to https://.servicenow.com/api/409723/codefresh/callback

The API namespace (409723) can be changed in the plugin if you decide to use your own implementation of this mechanism.

It takes four parameters in a JSON block:

cr_number, value: ServiceNow. Change Number Automatically captured from the previous step in the plugin that creates the Change Request
cf_build_id, value: ${{CF_BUILD_ID}}.
The Codefresh build number required to approve/deny the pipeline
cf_token, value: Codefresh API Token. As developers in my experience don’t like to get into ServiceNow, I wanted the solution to require as little as possible on the platform side. Using the API token, it means no need to create a credential and connection alias
cf_url, value ${{CF_URL}}. The Codefresh server URL. The idea is the same as above.

Behind this service is basically a simple Javascript script whose job is to call the subflow or return an error if anything goes wrong.

Subflow

The subflow is very simple (at least for now). I see it more as a basic example that ServiceNow admins will customize based on their needs.

It operates as seen in the diagram below:

Find the Change Request that was created previously
Wait for the state to reach some predefined state (implement or cancelled)
Callback Codefresh to approve/deny

Action

The action is a simple REST call using the info provided (Codefresh URL, Token, and build Id), plus the API call to make (approve or deny).

Again the idea here is to limit the amount of data to enter in ServiceNow. It would obviously be easy to change the implementation to use credentials and connection objects in ServiceNow instead if it’s your preference.

Codefresh Plugin

The plugin assembles all the pieces together. The code can be found at https://github.com/codefresh-io/steps/tree/master/incubating/service-now

Here is an example of the typed step invocation

  createCR:
    type: laurent-cf/service-now
    title: Create Service Now Change Request
    stage: deploy
    arguments:
      SN_USER: admin
      SN_PASSWORD: '${{SN_PASSWORD}}'
      SN_INSTANCE: https://xxxxxxx.service-now.com
      TOKEN: ${{CF_TOKEN}}
      data: '{"short_description": "Globex deployment to QA", "description": "Change for build ${{CF_BUILD_ID}}nThis change was created by the Codefresh plugin", "justification": "I do not need a justificationnMy app is awesome"}'

Aligning Codefresh pipelines with your company Change Management process

Change Management can be a heavy and complex process already in place at your company for which you may not have a lot of control or say about. We looked in this article on how to make your life slightly easier by :

reducing context switching
removing the need to connect to ServiceNow to open a Change Request manually,
keeping track of it before allowing or not your pipeline to proceed.

Please reach out to me if you have additional ideas or requirements.

New to Codefresh? Create your free account today!