Endevor Package Integration with ServiceNow

Published in

Modern Mainframe

6 min readJun 12, 2023

DevOps is about reducing cycle time (actual clock time, not the processing time).

The easiest way to reduce cycle time is through automation. It reduces failure of communication, can happen at or near real-time, and saves a huge amount of communication if the rules are set up right.

Automation makes the process repeatable and easier to train new people on. They don’t need to perform the actions, they just need to know the results.

Integration with the mainframe is easy using modern APIs. Customers often ask, “How can we drive Endevor actions through ServiceNow?” Here’s an answer.

Prerequisites

We assume you have:

Knowledge of ServiceNow, or can get someone to assist
This includes the ability to create fields, create workflows and set up the MID Server
ServiceNow’s IntegrationHub
A MID Server installed and configured
Endevor
Endevor Web Services configured

Overview

In this use case, we want to drive Endevor Package operations based upon Incident operations. When an incident reaches a certain state, it will trigger an operation in Endevor. The tools can now drive the process, removing the need for human intervention and speeding up time to delivery.

The MID Server provides a way for ServiceNow to integrate with tools inside your firewall. It can perform a number of operations including calling command line utilities, REST services and operating system operations.

Endevor provides a REST interface. This interface can perform package and element actions or even perform data pulls.

Let’s start with a simple use case where we use Endevor’s REST Services as they are. We don’t need to install any prerequisites to perform more advanced features though for more complex use cases you might want to use something like Zowe CLI with a scripting language to create integrations.

For this integration, we will need to:

Create fields to hold data, such as the Endevor Package Name
Define the REST message object
Define the actions to be called
Create a workflow to bring it all together

Note: This is a simple example, and therefore error checking and other operations required for production are not being demonstrated here. We simply want to prove the concept for ServiceNow to Endevor integrations.

Creating the basics

We will need to create ServiceNow fields to hold basic information. In this basic use case, we are using a new field of String type on the Incident record type to hold the Endevor Change Package name.

We update the form to display the field.

We can then create the main interface for the glue: a REST Message in the Outbound integrations. This will allow us to define the interface into Endevor. In this case, we are adding three basic operations: cast, reset and execute.

Creating the REST Message

We need to create the REST Message item. Here we’ve called it EndevorPackages. For authentication, we use Basic and create a profile to hold the Endevor login information.

At the bottom of the form, you will see a section for HTTP Methods. Here we define the methods to call in the Endevor REST API. Using the documentation for the v1 API (currently, the most common), we know there are operations for packages, including Cast, Execute and Reset.

These services were chosen for utility (they actually do something) and require little additional information. They do not need any special headers, for example.

We need to define one for each operation we want to integrate. Here’s an example of Cast:

We defined the name of the operation, the method (PUT) and the endpoint URL in the Endpoint field.

We also need to say where this will execute. We assume you’ve defined your MID server, so we will use that. It is accessible from the HTTP Request tab.

At this point, you might want to test your web service calls. There’s a test link in the bottom section of the form.

Actions

ServiceNow actions can script up our actions. This provides more flexibility. Actions also allow inputs and outputs. We want two inputs, a package name and a package operation. This gives us a package to work on, and an operation to perform.

In the script step, we want to capture the action and pass it to the EndevorPackages service. Using inputs.pkgoperation, we pass the exact command we want to call. We will pass “Cast”, “Execute” or “Reset”.

As Cast, Execute and Reset all take the same parameters, this works with little effort. When we call EndevorPackages, we pass the method we want to call. We use setStringParameterNoEscape with the inputs.pkgname variable.

try { 
 var r = new sn_ws.RESTMessageV2('x_721645_zoweint_0.EndevorPackages', inputs.pkgoperation);
  r.setStringParameterNoEscape('packageName', inputs.pkgname);
  gs.info('PKGNAME: ', inputs.pkgname); 

r.setMIDServer('midserver');

 var response = r.execute();
 var responseBody = response.getBody();
 var httpStatus = response.getStatusCode();
}
catch(ex) {
 var message = ex.message;
}

You will need to make sure to publish your action, otherwise, it won’t show up in the next step.

Go with the Flow

We now need a Flow to drive the actual action. Here we link the data on the Incident to the web service method we want to call.

To create the flow, we define a trigger and the if/then conditions. These conditions will call the action we created above. By modifying that action, we simplify the system, as a single action works against multiple methods. We do have to add a little code here to make it work though.

Creating the trigger, we are saying if any Incident is created or updated and the Endevor Change Package field is not empty, we will execute some actions.

In the actions section, using the “If” action, we define the condition label, then define the actual condition.

The condition itself, for this definition, is the Incident State field being a specific value. When it has that specific value, we will then drive an action to perform the work we want based upon that condition.

In the actions field, we select the action we created in the previous step. If you recall, we have two inputs into this process. The name of the package and the action we want to perform.

To define the action, I chose to write a simple script. Using a single line, we return the action to call in the REST method:

return "Cast";

Keep in mind, this needs to be in the same format as the web service. The Endevor REST package operation endpoint is /Cast. So we must use “Cast” here, using the same case (capital C).

To create the script, use the box to the immediate right to enter the script mode. You will see a comment block.

Now we need to pass the packageName. To do this, there’s a Data section to the right.

Expand the Incident Record pill, then navigate to the Endevor Package Name and drag it to the pkgName field.

Choose any other actions you want to automate then save and activate your new workflow.

Wrapping it up

Automation is key to enabling DevOps. Using web services, we can build that automation to drive Endevor through related ServiceNow actions. The MID server enables this. This guide shows you the basic actions to create that integration.

If you are looking for more Zowe-related automation, check out other articles on Medium.

In our next installment, we will show you how to drive Zowe CLI through ServiceNow to create Endevor Change Packages.

This may look complex, but the payoff is streamlined and error-proof processes. We’re here to help. If you’d like to learn more about integrating Endevor with ServiceNow, please leave a comment below or reach out to your Broadcom representative.