© 2010 IBM Corporation ® Provisioning Network Services in ITNCM

© 2010 IBM Corporation

®

Provisioning Network Services in ITNCM

IBM Software Group | Lotus software

IBM Software Group | Tivoli Software | IBM Security Systems

ITNCM: Intelligent Tool for Network Operations & Compliance

Device DiscoveryDiscover network devices in the networkor utilize ITNM or flat file loads.

Synchronize ChangesUpdate configuration repository with planned and un-planned configuration changes across the network

Direct Device AccessIncluding command filtering and full keystroke logging for audit purposes

Security Role-based control of who accesses what devices and what changes they can make within the network, including full workflow approvals.

Rollback or Restore ConfigurationRestore configuration with or without a device reboot

SmartModel™, Command Set Groups & Native Command Sets Intelligently apply changes with full error control or with vendor native scripts

OS Upgrade SupportAutomatically management theupgrade of a devices operating system

Full Network Change & Policy Management Lifecycle Support

Pre-emptive and Current StatePolicy Compliance

2

Backup ConfigurationSingle instance repository for all configuration and change information

Bulk Configuration Changes Automate bulk configuration changes through reusable command sets with full fallout management and error handling

Key Product Features

Open NSM REST API REST API enabling ITNCM to be integrated with existing customer systems e.g. network provisioning, Cloud Provisioning



Network Service Management ( NSM )The Goals of NSM is to:

Simplify the Creation, Modification and Deletion of Network Services on Network Devices

Create Service Templates that can hide the complexity of the Service away from the Client User

Allow for easy management of the Service Templates in terms of Creation, Modification, Deletion, Importing and Exporting.

Create a robust and reproducible Network Configuration Service Solution

Allow the features of ITNCM to be available through a simple REST Interface



NSM Service TemplatesNSM Service Templates allow the Service Template Designer:

To Dictate how NCM Artifacts such as Native & Smart Modelled CommandSets are called in a controlled and ordered manner.

Allow access to the IT NCM Artifacts without the need to have in-depth ITNCM knowledge or Java Code experience , the Service Templates are simple XML Configuration Files, all the complexity to interface to ITNCM is hidden from the Service Template Designer by NSM.

Introduce the ability to manipulate client provided parameter values and inject new parameters values as needed for the ITNCM Commandsets.

Control the life Cycle of a Network Service and decide how the Service can be deleted.



NSM Service LifeCycle

Full Change History and Control

5

NSM Service LifeCycle

Network Service DesignService Template Designer plans what type of Network Service is needed.

Command Set CreationService Template Designer Uses ITNCM Toolsto create the necessary Command Sets to create and maintain the Network Service on the Devices

Service Template CreationService Template Designer Uses ServiceTemplate XML to design how the Serviceshould be Exposed to the Client User. They also decide how the Command Sets Parameters should be calculated andin what order they should execute.

Import Service Templates Service Template Designer Uses the NSM Commandline Tools to import the Service Tenplate Design XML files into the ITNCM database.

Client Views new ServiceThe Client User uses the NSM ServiceTemplate REST URI's to view the newService being offered

Client Requests new ServiceThe Client Users can now request the NSM Service of their choice using the NSM Service REST URI's.

NSM executes ServiceNSM executes the Service as dictated by the Service Template. NSM communicates withITNCM to create the Workitems needed to complete the Service on the Network Devices.

Client Checks for Service StatusThe Client Users can view Service execution statususing the NSM Service URI's. The Client User can also check for specific the specific configuration changesusing Extractions.

c

Service RemovalDepending on how the Service Template was designedeither the Client Users can request for a Service to be Deletedusing the NSM REST API or the Service Designer can createa schedule for when the Service is removed



NSM Parameter Calculation

NCM Command SetsNCM Commandsets takes parameter Values as calculated by NSM ParameterEngine and executes these on the Network Devices.

NSM Parameter Engine

Client ParametersNSM can accept Parameter Name/Values from the Client to pass directly to Commandsets or they NSM can use them in the NSM Parameter Engine to calculate other parameters.

SQL ParametersNSM can query external or internal databases to retrieve parameter values. The Arguments to the Query can be provided by the Client or can be injected by the Service Template designer

JavaScript ParametersNSM allow the execution of both NSM provided JavaScripts Methods to manipulate Parameters and also allows the Service Template Designer to provide their own Controlled JavaScript.

Http ParametersNSM allows the retrieval of parameters by calling a HttpClient using the URL supplied by the Service Template Designer



NSM Service Template Tools

ITNCM Development ITNCM ProductionExport and Import ToolsNSM provides a range of tools to Export Service Templates and Import to other Systems. Typical use of these tools would be to move Service Templates fromDevelopment to Production Systems once verified.

Search ToolsNSM provides tools to search for Service Template with a range of filters such as Name, Creation Date and Device Vendors that the Service Template Supports,

Cloning ToolsNSM provides tools to take an existing Service Template and Clone it, thus making it easier to create Service Templates that are similar to other Service Templates.

CRUD ToolsNSM provides a range of tools to easily Create, Update and Delete Services Templates.



NSM Service Templates main elements

Parameters – Decide how the Parameters are to be calculated ( Client Provided, SQL, HTTP Request, Inject JavaScript or Constant

Implementations – Controls which operations will get called and how/which parameters get calculated based on the Devices Vendor-Type-Model-OS (VTMOS). The Designer can use regular expressions to allow one implementation to support multiple Devices. One Service Template can have many implementations.

ServiceOperations – Operations can be classified as CREATE or DELETE. Depending on the Http Method used on the Service URI, NSM will run either execute the CREATE operations when HTTP POST is used, and execute the DELETE Operations when HTTP DELETE is used by the Client using the NSM REST API.

Operations – Define which ITNCM Artifacts need to run and in which order they should execute. Operations types can be COMMANDSET, EXTRACTION or DEVICE SYNC



Service

ServiceTemplate

Device

Realm

NSM REST URI's

Device URI's can be used for Device Inventory gathering. It is also possible to retrieve the devices current configuration

Realm URI's for searching ITNCM realms which are used to organize ITNCM Artifacts by Geographic, Policy, Security or any Customer specific realms.

ServiceTemplate URI's allow the NSM REST API Client user query the ITNCM system for available Services that can

be executed on a device.

Service URI's allow the NSM REST API Client user to create, monitor and delete the Network Services provided by the Service Templates.



NSM war is installed with the NCM Presentation Servers on IT NCM 6.4

NCMDB

Presentation Server1 Presentation Server2

NSM war NSM war

Worker Servers


NSM Main Client URI's

• Http GET http://host:port/nsm/device/

• Http GET http://host:port/nsm/servicetemplate/

• Http GET http://host:port/nsm/servicetemplate/{st-id}/device/{device-id}

• Http POST http://host:port/nsm/service

• Http GET http://host:port/nsm/service/{service-id}

• Http DELETE http://host:port/nsm/service/{service-id}


NSM Service Template basic structure


NSM Service Template Parameters


Constant Parameters structure

• Static values for a NSM Service Template Designer to Use


Client Parameters structure

• Enables a Client to set values before service execution

• Used in the client submission for service execution• Client data is set to the value element of the

clientParameter


Client List Parameters structure• Special case Client parameter. Allows client to specify a list of values

before service execution• Each value in the list is used once during execution• Creates repeated operation execution where Operation uses the list• Order is optional and indicates order in which values must be used and

repeat operations must be executed• Allows for variable repetition of the same command to be executed


Inject Parameters structure• Enables parameters to be manipulated before service

execution using a JavaScript Engine• Pre supplied JavaScript functions including sum, subtract,

multiply, divide, ifEquals, concat and string manipulations• Allows template designer to supply there own JavaScript

code, using the <code> element (executed under white list conditions)

• Uses a white list to exclude certain functionality from being executed

• Result is set to the value element of the injectParameter


Http Parameters structure

• Enables parameters to be manipulated before service execution

• HTTP REST GET requests are executed at service execution time

• Result is set to the value element of the httpParameter


SQL Parameters structure

• Enables parameters to be manipulated before service execution

• SQL is executed against the Database Connection located in the selected implementation at service execution time

• Result is set to the value element of the sqlParameter• Note The database password is encrypted when stored.


Operation structure• Operations are located under implementation• Operation name is a combination of Realm and

CommandSet name


Rules structure• Rules are used to select the correct implementation for the

client to submit for service execution• Rule has one type currently “DeviceType” • DeviceType expects 4 properties Vendor, Type, Model and

OS – VTMOS• Rule can be specified using Regular Expressions


Client service submission example• The structure of the service template for execution is

expected to have at least the ID of the service template and the ID of the device to execute the service against.

• Optionally it may have a list of client parameters needed to ensure the proper execution of the service.


Client POSTs ServiceTemplate XML for Service creation.Response contains Service with a new ID and state = SUBMITTED

Client uses GET /service/{service-id}/status to poll service state. Responses contains minimal service record with ID and latest state.

Client uses GET /service/{service-id} to retrieve full record with child workitem entries

Client uses GET /service/{service-id}/workitem/{workitem-id} to retrieve workitem data. Contains UOW Log and a task result (if present)

Client service submission cont'd


Service Processing After client submits the service, NSM begins processing received XML into an active Service

instance

Processing covers – CommandSet or Extraction resolution from ITNCM data systems

– NSM Parameter evaluation and subsequent application to UOW CommandSet data

If any part of initial processing fails Service fails and processing stops– Initial processing includes

• Resolution of device and operation targets (commandset, extraction)• Runtime Parameter evaluation

Active instance produces the following in ITNCM– 1 Service UOW

– 1 or more UOWs in ITNCM (UOW merging is used if possible by the underlying submission system)

Service UOW provides a log of Service activity in ITNCM Client

NSM receives UOW processing/state change events to trigger updates in Service status

NSM updates Service UOW Log as state changes happen

Service UOW state reflects the state of the NSM Service


Service Processing Flow

NSM

REST Client

ITNCMService UOWs

Work Queue

Active Service

List

Managed Devices

Service Status

Updates

Configuration data

UOW Events Worker

Server

POST ServiceTemplate

XML


Service Delete ServiceTemplates provide 2 mutually exclusive mechanisms for

handling deletion of Services they create– DELETE Service operation for cleanup/removal of service actions

– Timed delete for transient Services

Delete mechanisms only apply to Services which were successful

Delete serviceOperation provides dedicated work execution block to be carried out in response to DELETE /service/{service-id} URI

Time To Delete specifies time in minutes after which a Service will be removed from the database

ServiceTemplate may only specify either of TTD or DELETE serviceOperation


Reference ID• A Service can be Posted for execution in 2 ways

• The first is by using the URI shown next and supplying the client service template for service execution• Http POST to http://host:port/nsm/service

• The Second is by using the URI shown next and suppling the client service template for service execution and a client generated reference ID• Http POST to http://host:port/nsm/service/referenceid/{reference-

id}

• The Client can now request the service by their own supplied reference ID ( e.g. CustomerService_12345 ) using the URI shown next• Http GET to http://host:port/nsm/service/referenceid/{reference-id}


Command Line Tool Commands:

• create - creates a service template by using information from an XML file• Format: /nsmadmin.sh command=create filename=<filename> [username=<username>

password=<password>][port=<port>]• Example: /nsmadmin.sh command=create filename=/opt/IBM/serviceTemplate1.xml

• read - gets information about the latest version of a service template and outputs it to an XML file• Format: /nsmadmin.sh command=read filename=<filename> id=<id> [username=<username>

password=<password>][port=<port>]• Example: /nsmadmin.sh command=read filename=serviceTemplateOutput.xml id=4

• list - lists the latest versions of all service templates in an XML file• Format: /nsmadmin.sh command=list filename=<filename> [username=<username>

password=<password>][port=<port>]• Example: /nsmadmin.sh command=list filename=serviceTemplateOutputList.xml

• update - creates a new version of a service template by updating information in an existing service template. • Format: /nsmadmin.sh command=update id=<id> filename=<filename> [username=<username>

password=<password>][port=<port>]• Example: /nsmadmin.sh command=update id=19

filename=/opt/IBM/tivoli/netcool/ncm/bin/QAJavaST.xml

• purge, clone, exportall, exportid, exportname, exportvendor, exportdaterange, import and importlist are the other tools options available


Troubleshooting I Discussed in NSM API Guide

– Generally, when a request encounters an error, NSM returns a HTTP Status code along with a specific NSM Error code.

– HTTP Code indicates protocol level processing outcome

– NSM Error codes documented in the API Guide and indicate failure category within NSM

– For Service processing errors, detailed information can be found in ITNCM Service UOW log in the client and appropriate errors in the ITNCM log file $NCMHOME/logs/Intelliden.log

Diagnostic tools

– Service UOW Log in ITNCM Client for Services

– Intelliden.log for general & REST operation debugging

Logs

– Logging system uses ITNCM logging

– CLI import tool logs


Troubleshooting II Detailed diagnosis and problem location for Services

– Identify Service ID and execute GET on nsm/service/{service-id} in a browser to retrieve Service record

– Examine service record and note serviceWorkKey attribute of the Service and id attributes of the child workItems.

– Open ITNCM Client and locate Service UOW with ID matching value of serviceWorkKey. Open the log of this entry for detailed processing information. Also, use workItem id attributes to identify and examine individual UOWs via the client.

– Execute GET nsm/service/{service-id}/workitem/{workitem-id} to retrieve UOW log and status info for a service workItem (or use the ITNCM Client to view the UOW log)

– Open Intelliden.log to look for NSM processing error information

Documents

© 2010 IBM Corporation ® Provisioning Network Services in ITNCM