Testing Integration

After the integration is finished, for every chatbot story created, an incident will be created in ServiceNow. For example, the creation of the following story number 9 in Slack:

This story has a corresponding incident created in ServiceNow. To access these incidents, from the ServiceNow home page search for agent, and click on Agent Workspace Home, as shown below

In the Agent Workspace, if you click on the burger menu and select CloudPak for AIOps Incidents, you will see the list of incidents created by CloudPak for AIOps as shown below

This is the incident in ServiceNow that corresponds to the story number 9 that was mentioned before

When an incident occurs, it can be helpful to review details for similar incidents to help determine a resolution. This AI model aggregates information about similar messages, anomalies, and events for a component or application. It can also extract the steps used to fix previous incidents, if documented. Training this AI model will help you discover historical incidents to aid in the remediation of current problems.

Important: Incidents in ServiceNow must contain meaningful entries in the Resolution notes (close_notes value in the logs) field to successfully populate the Search recommended actions feature in your ChatOps interface. If your incidents do not include resolutions, or include default entires like Closed by Caller, these values do not identify paths to remediation. As a result, empty or non-meaningful entries yield no results in your ChatOps interface because they provide no potential actions.

The process can be defined in the following steps:

1) Change at least five existing incidents in your ServiceNow developer instance in order to match the stories you already have in Slack. To see the existing sample incidents in your ServiceNow developer instance search for incidents and select Service Desk -> Incidents as shown below

Select an existing open incident and update the description and short description with some known log anomaly error from an existing story. For example the next picture shows the description as “Unknown Error web”. Then click on the Resolution Information tab and Close the incident with resolution code Solved and fill the Resolution Notes with some resolution such as “web service was restarted”. Repeat this process for at least five tickets.

2) Now we can load the historical incidents data. We will verify that there is no incident data loaded yet by running the following command

Now run the following CURL command

As you can see there is no data yet.

We will enable the incident data flow now.

Now incident data is being loaded into WAIOPS. Wait for an hour.

Note: this is a limitation of the vV3.1.1product in the sense that there is no feedback in the UI regarding how the data is being loaded or what data has been loaded already.

After an hour wait, we will verify that now there is indeed incident data loaded by running the same command:

Now run the following CURL command

As you can see there is incident data now loaded in elastic search. Now we need to disable the data flow. Click on the ServiceNow integration and select the 3dot menu on the far right and select “Disable Ticket Data Flow”.

3) Now its time to use that data for historical similar incident training. Click AI Model Management from the Home page and select the Similar Incidents card as shown below.

Create a training definition by clicking on the Create Training Definition button. Select “manually” for the schedule option and click save. The next picture shows a training definition (not that in this case it has already been used for training)

Now its time to run the training. From the top right Actions menu select Start Training. After some time, you will the training results and the confirmation that the model has been deployed as shown in the next picture:

Now, lets take a look at elastic search again and see if the new model is there. Run the following commands:

Now run the following CURL command

As you can see, there is a new model created for incidents.

As we can see in the previous picture, when we click search, a historical incident is found and a summary of the ticket resolution activities are shown. You can click on the text in blue to go to the actual ticket in your ServiceNow developer instance.

Using the WAIOPS ServiceNow Observer job, you can retrieve the Configuration Management Database (CMDB) data from ServiceNow. The ServiceNow developer instance comes loaded with sample topology and inventory data. In this section, we will define an observer job to pull this information into WAIOPS, that can be later be seen from the Topology Viewer.

The ServiceNow Configuration Management data base creates and maintains the logical configurations the network infrastructure needs to support a ServiceNow service. These logical service configurations are mapped to the physical layout data of the supporting network and application infrastructure in each of the respective domains. They track the physical and logical state of IT service elements and associate incidents to the state of service elements, which helps in analyzing trends and reducing problems and incidents. The configurations are stored in a configuration management database which consists of entities, called Configuration Items (CI), that are part of your environment. A CI may be:

A CI does not exist on its own. CIs have dependencies and relationship with other CIs. For example, the loss of disk drives may take a database instance down, which affects the requisition service that the HR department uses to order equipment for new employees.

In order to see existing CMDB data in ServiceNow, from the developer instance home page, from the top left you can search for CI, click on CI Class Manager and click the ‘Hierarchy’ button at the upper left of this page to start the CI Class Manager.

For example, on the CI Classes column, click on Hardware, select the CI List to see the actual items and search for SAP. You will find a number of SAP servers own by the Lenovo Organization as shown below. We will see these same SAP servers later in the Topology Viewer in WAIOPS.

In CP4AIOPS there are two ways to enable a ServiceNow observer job: the first way is inside the ServiceNow main integration form and the second way is as a regular observer job. In this cookbook, we will follow the second option.

From the WAIOPS home page, click on Data and tool integrations, then click on the Advanced tab and finally select Manage observer jobs. You will see the list of available observers after you click on the Add a new job card as shown below (note that the number of observer cards will vary depending on what observers are enabled in your WAIOPS instance)

Click on the ServiceNow card and complete the observer job form as shown below:

Leave the optional Additional parameters section unchanged. Click on the Job schedule section and confirm that Run time is set to now and Time interval as once only

The following screenshot shows the complete form:

Finally click on Save to save the observer job configuration and run the job. This job will pull all the existing topology and inventory data from your ServiceNow developer instance into WAIOPS.

After you let the job run, lets check the logs of the observer pod by running the following command:

Open the log output file servicenow-observer-logs.txt and verify that you see log lines like those shown below:

Finally, lets verify the ServiceNow inventory and topology data in the Topology Viewer. From the WAIOPS home page click on Topology viewer and search for Lenovo and click on the search result blue target. You will see that the topology for the ServiceNow Organization Lenovo is shown. If you zoom-in, you will see that this topology includes the SAP servers (SAP-SD-01, SAP-SD-02, etc) we saw before in ServiceNow.

Important: You must specify an IBM CloudPak for AIOps encrypted version of your ServiceNow password to collect inventory and topology data from ServiceNow. To encrypt your ServiceNow password, complete the following steps: