Building a topology using Agile Service Manager’s REST Interface

In my previous blog of the series, we have seen that a resource is the building block of a topology. A resource can have properties, relationships, status, and snapshots. It will be easier to build the model when the resource and the relationship are defined separately. We have configured ASM to build the model from the JSON expression specified in a text file.

This blog will extend this topology modeling by using a script to interact with the ASM REST Interface.

The model as database tables

Late last year, our team was working together with a large telecommunication service provider in the Asia Pacific region on topology modeling. The customer gave us a large file which contained the export of their inventory system and tasked us to create a topology from that export file. We used a script to extract the output and build the topology.

This incident inspired the creation of this blog: how to use a script to build a topology from a known resource/relationship model. For confidentiality reasons, I cannot use the exact export file mentioned above, so let us create a topology of a publicly available example. Let’s build the topology of the GuestBook Stateless Application as mentioned in Kubernetes.io.

The Kubernetes GuestBook Application depends onthree containers:
a PHP based web front-end (PHPFrontEnd) and two Redis databases configured as a master and slave pair.

The PHPFrontEnd container deploysthe gbf_0_1_0 docker image. The RedisMaster and the RedisSlave containers deploy the gbrm_0_1_0 and gbrs_0_1_0 docker images, respectively. The RedisSlave and RedisMaster communicate with one another as they are master and slave. The PHPFrontEnd uses the RedisSlave to store and then query the data.

Let us start using a spreadsheet to list the resource and the relationship. Also, let us use the highlighted verbs from the previous paragraph to define the relationships.

Resource and Relationship in a spreadsheet

While a spreadsheet allows me to define the resource and relationship easily, a database table will be easier to manipulate using a script.

ASM is part of a bundle of a Netcool Operation Insight. So in the environment, I have access to a database management system in the form of OMNIbus database and a scripting engine in the way of Netcool/Impact. I will use Netcool/OMNIbus tables and Netcool/Impact policy engine here; however, you do not need OMNIbus nor Netcool/Impact for this. You can use any database management system and any scripting language.

I created two custom tables as follow.

create table custom.asm_resource virtual
(
    App         varchar(33) primary key,
    UniqueId    varchar(33) primary key,
    entityTypes varchar(33)
);
go
create table custom.asm_edge virtual
(
    App          varchar(33) primary key,
    FromRes      varchar(33) primary key,
    Relationship varchar(33) primary key,
    ToRes        varchar(33) primary key
);
go

I added the column “App” to both tables as I wanted to be able to use the same tables to model multiple topologies.

To populate the table from my spreadsheet definition, I used the spreadsheet’s string function to create the SQL insert statements. I then copied and pasted the statements into the database command-line interface.

Creating SQL inserts using the spreadsheet string function

By using these simple steps, I have now modeled the application in database tables.

We have just gone through a simple method of representing the model using database tables populated from a spreadsheet. In practice, these tables are typically created as views or exports from database tables of an Inventory or a Provisioning Applications.

ASM’s REST Interface

I am going to use ASM’s REST Interface to inject the data. In ASM, the process of injecting topology data is called a “job”. ASM REST Interface recognizes two job modes: Bulk Replace mode and Listen mode. The difference is on how complete we should specify the topology components at each update iteration.

In Bulk Replace mode, ASM expects the complete topology to be specified, whereas in Listen mode the components can be injected into ASM as they are available. A batch load in the Bulk Replace mode is marked as complete by a Synchronized https post call. ASM will keep only the resources and relationships mentioned in the last job. ASM will delete from the current snapshot all other existing resources and relationships not being mentioned.

In the previous database tables, I have stored the topology in its entirety. Thus, I am going to use the Bulk Update mode.

The script

I want to use the table to store multiple topology model. To support this, I have introduced one parameter the App, corresponding to the App column in our tables schema.

Here are the high-level actions of the script:

Here is the impact policy (you can download this impact policy and the corresponding library policy from this GitHub page):

We can then call the script like this, passing the single parameter AppName:

$IMPACT_HOME/bin/nci_trigger NCI -e/user/{AES}encryptedPassword asmCreateBulkExtParam AppName bg

Where

• $IMPACT_HOME/bin/nci_trigger is the full executable pathname.
• NCI is the (default) Netcool/Impact cluster name.
• asmCreateBulkExtParam is the script name
• AppName bg is the paramater name and value pair.

That’s it! We have built the topology from two simple tables. The created topology can be viewed through the Topology Viewer:

Topology of the GuestBook Application

We can create new topologies by specifying the resources and the relationship in the database and then run the script.

The current resource and relationship tables are very basic as its main purpose is to show how everything works together. As you are pulling the topology data from an Inventory or Provisioning Application, you might have additional information for the resource. The two database tables and the script can be extended to allow for this.

Automatic update

A topology will generally change. If the inventory system can maintain the tables, then we can maintain the currency of the topology by calling the script periodically. Netcool/Impact provides a service called a policy activator that can call a policy periodically. The Linux cronjob can also do this for us.

An alternative to the simple period update is a conditional update. The system can be configured to periodically check for update and only perform the update when there is a change in the resource or relationship tables. To do this, we can add a timestamp column to both tables to represent the last time the row was updated. This additional column allows us to poll the tables with a smaller period but only build the topology when changes are detected. I will provide an example in my next blog.

Topology VIewer Refresh rate setting

ASM Topology Viewer, the dashboard component of ASM, allows us to change the refresh rate of the dashboard. As we automatically update the backend topology data, ASM will automatically refresh the dashboard.

Cloud environment changes very quickly. We have just created a simple way to maintain the topology snapshot to support the display of the dynamic cloud environment.

Summary

We have gone through the simple process in creating and updating the topology of an application by using two simple database tables which are read and of which their content pushed into ASM through a script.

The topology we have built so far comes from a known set of resources/relationships such as from an inventory or a provisioning application. What happens if we do not have such inventory or provisioning application? My next blog will give an example of how we can address this.

The series

This blog is part two of the Topology Modeling using Agile Service Manager blog series. Part I can be read here.

Bring your plan to the IBM Garage.

Are you ready to learn more about working with the IBM Garage? We’re here to help. Contact us today to schedule a time to speak with a Garage expert about your next big idea. Learn about our IBM Garage Method, the design, development, and start-up communities we work in, and the deep expertise and capabilities we bring to the table.

Schedule a no-charge visit with the IBM Garage.