Network Service Manager RESTAPI Users Guide - IBM Service Manager RESTAPI Users Guide for R2E2. Note...

Netcool Configuration ManagerVersion 6 Release 4

Network Service Manager REST APIUsers Guidefor R2E2

��

NoteBefore using this information and the product it supports, read the information in “Notices” on page 151.

This edition applies to version 6, release 4 of IBM Tivoli Netcool Configuration Manager (5725-F56) and to allsubsequent releases and modifications until otherwise indicated in new editions.

© Copyright IBM Corporation 2012, 2013.US Government Users Restricted Rights – Use, duplication or disclosure restricted by GSA ADP Schedule Contractwith IBM Corp.

Contents

About this publication . . . . . . . . vIntended audience . . . . . . . . . . . . vWhat this publication contains . . . . . . . . vPublications . . . . . . . . . . . . . . viAccessibility . . . . . . . . . . . . . . xTivoli technical training. . . . . . . . . . . xSupport information . . . . . . . . . . . . xConventions used in this publication . . . . . . x

Chapter 1. Overview of the NetworkService Manager REST API . . . . . . 1About the NSM REST API . . . . . . . . . . 1

NSM architecture . . . . . . . . . . . . 1NSM service lifecycle . . . . . . . . . . 2NSM parameter calculation . . . . . . . . 4

NSM roles . . . . . . . . . . . . . . . 5

Chapter 2. Designing a NSM servicetemplate . . . . . . . . . . . . . . 7Structure of a NSM service template . . . . . . 7

Parameters . . . . . . . . . . . . . . 8<implementations> element . . . . . . . . 9Configuring rules . . . . . . . . . . . 11Configuring service operations . . . . . . . 12

Deleting NSM service template instances . . . . 15Controlling the order and merging of serviceoperations . . . . . . . . . . . . . . . 17Posting a NSM service template . . . . . . . 21Submitting a NSM service template for execution. . 21

Chapter 3. Network Service Managerparameters . . . . . . . . . . . . . 25Constant parameters . . . . . . . . . . . 25

Constant parameter rules . . . . . . . . . 26Configuring constant parameters . . . . . . 26

Client parameters . . . . . . . . . . . . 27Client parameter rules . . . . . . . . . . 28Configuring client parameters . . . . . . . 28

Client parameter list parameters . . . . . . . 29Client parameter list parameter rules . . . . . 33Configuring client parameter lists . . . . . . 33

Inject parameters . . . . . . . . . . . . 34Inject parameter rules . . . . . . . . . . 36Types of inject parameters . . . . . . . . 36Configuring inject parameters . . . . . . . 38JavaScript restrictions . . . . . . . . . . 39

SQL parameters . . . . . . . . . . . . . 40Database connection tags . . . . . . . . . 40SQL parameter element and tags . . . . . . 41SQL parameter rules . . . . . . . . . . 42Configuring SQL parameters . . . . . . . 42

HTTP parameters . . . . . . . . . . . . 43HTTP parameter rules . . . . . . . . . . 45Configuring HTTP parameters . . . . . . . 45

Chapter 4. Understanding predefinedNetwork Service Manager functions . . 47concat . . . . . . . . . . . . . . . . 47divide . . . . . . . . . . . . . . . . 47ifEquals . . . . . . . . . . . . . . . 48ifGreaterThan. . . . . . . . . . . . . . 49ifGreaterThanOrEqualTo . . . . . . . . . . 50multiply . . . . . . . . . . . . . . . 51replace . . . . . . . . . . . . . . . . 52replaceAll . . . . . . . . . . . . . . . 53substring . . . . . . . . . . . . . . . 53substringFromBeginIndex. . . . . . . . . . 54subtract. . . . . . . . . . . . . . . . 55sum . . . . . . . . . . . . . . . . . 55

Chapter 5. Network servicemanagement command line interfacetool . . . . . . . . . . . . . . . . 57Running the CLI tool . . . . . . . . . . . 57CLI commands and options . . . . . . . . . 58clone command . . . . . . . . . . . . . 61create command . . . . . . . . . . . . . 62delete command . . . . . . . . . . . . . 63disable command . . . . . . . . . . . . 63disableall command . . . . . . . . . . . 64exportall command . . . . . . . . . . . . 64exportdate command . . . . . . . . . . . 65exportdaterange command . . . . . . . . . 66exportid command . . . . . . . . . . . . 67exportname command . . . . . . . . . . . 68exportvendor command . . . . . . . . . . 68getversion command . . . . . . . . . . . 69import command . . . . . . . . . . . . 70importlist command . . . . . . . . . . . 71list command . . . . . . . . . . . . . . 72purge command . . . . . . . . . . . . . 72read command . . . . . . . . . . . . . 73readall command . . . . . . . . . . . . 73update command . . . . . . . . . . . . 74removeserviceinstance command . . . . . . . 75NSM command-line logging . . . . . . . . . 75

Chapter 6. Understanding the NetworkService Manager URIs . . . . . . . . 77Realm URIs . . . . . . . . . . . . . . 78

HTTP GET for /realm . . . . . . . . . . 78HTTP GET for /realm/{realm-id} . . . . . . 80

Device URIs . . . . . . . . . . . . . . 81Short and long formats for device URIs . . . . 85HTTP GET for /device/{device-id}/currentnativeconfiguration . . . . . . . . 88HTTP GET for /device/{device-id}/currentmodeledconfiguration . . . . . . . 89

© Copyright IBM Corp. 2012, 2013 iii

HTTP GET for /device/{device-id}/currentsupplementalinformation . . . . . . 90

Service template URIs . . . . . . . . . . . 91HTTP GET for /servicetemplate/{servicetemplate-id}/deviceid/{device-id} . . . 92HTTP GET for /servicetemplate . . . . . . 95HTTP GET for /servicetemplate/deviceid/{device-id} . . . . . . . . . . . . . . 96

Service URIs . . . . . . . . . . . . . . 97HTTP GET for /service . . . . . . . . . 98HTTP GET for /service/{service-id} . . . . . 101HTTP GET for /service/referenceid/{reference-id} . . . . . . . . . . . . . . . . 103HTTP GET for /service/{service-id}/status . . 105HTTP GET for /service/{service-id}/device . . 106HTTP GET for /service/{service-id}/workitem 107HTTP GET for /service/{service-id}/workitem/{workitem-id} . . . . . . . . . . . . 108HTTP GET for /service/{service-id}/input . . 110HTTP POST for /service. . . . . . . . . 111HTTP POST for /service/{reference-id} . . . . 113HTTP DELETE for /service/{service-id} . . . 116

XSD URIs . . . . . . . . . . . . . . 117

Chapter 7. Understandingautomatically generated NSM servicetemplates . . . . . . . . . . . . . 119Rename action . . . . . . . . . . . . . 119Move action . . . . . . . . . . . . . . 120

Edit action . . . . . . . . . . . . . . 120Delete action . . . . . . . . . . . . . 121

Chapter 8. Troubleshooting . . . . . 123Interpreting NSM service execution status codes 123Interpreting HTTP status codes and NSM errorcodes . . . . . . . . . . . . . . . . 123Checking the NSM REST API installation . . . . 128Checking NSM when Netcool ConfigurationManager Recovers . . . . . . . . . . . . 128Checking the Intelliden.log file . . . . . . . 128Checking the nsmadmin.log file . . . . . . . 129Working with the database connection pool . . . 129

Appendix A. Sample XML responsesfor operation types . . . . . . . . . 131

Appendix B. XSD files. . . . . . . . 135

Appendix C. Example NSM servicetemplates . . . . . . . . . . . . . 141

Notices . . . . . . . . . . . . . . 151Trademarks . . . . . . . . . . . . . . 153

Index . . . . . . . . . . . . . . . 155

iv IBM Tivoli Netcool Configuration Manager: Network Service Manager REST API

About this publication

IBM Tivoli Netcool Configuration Manager provides configuration managementcapabilities for network devices, as well as extensive configuration policythresholding capabilities.

The IBM Tivoli Netcool Configuration Manager NSM REST API Guide describes theNetwork Service Manager REST API, hereinafter referred to as the NSM REST API.

Intended audienceThis publication is intended for network engineers who need to use the NSM RESTAPI. Specifically, the audience consists of NSM service designers who designservice templates and NSM client users who make use of these service templates.

What this publication containsThis publication contains the following sections:v Chapter 1, “Overview of the Network Service Manager REST API,” on page 1

Provides an introduction to the NSM REST API.v Chapter 2, “Designing a NSM service template,” on page 7

Provides information about how to design a NSM service template.v Chapter 3, “Network Service Manager parameters,” on page 25

Describes the types of NSM parameters.v Chapter 4, “Understanding predefined Network Service Manager functions,” on

page 47Describes the predefined NSM functions that can be used inside injectparameters to create and edit NSM service templates.

v Chapter 5, “Network service management command line interface tool,” on page57Provides information about the NSM command-line (CLI) tool.

v Chapter 6, “Understanding the Network Service Manager URIs,” on page 77Provides information about the Network Service Management URIs.

v Chapter 7, “Understanding automatically generated NSM service templates,” onpage 119Describes automatically generated NSM service templates.

v Chapter 8, “Troubleshooting,” on page 123Provides information about how to troubleshoot NSM issues when there areerrors.

v Appendix A, “Sample XML responses for operation types,” on page 131Provides sample XML responses for the EXTRACTION, DEVICESYNC, and COMMANDSEToperation types.

v Appendix B, “XSD files,” on page 135Provides XSD files for the NSM REST API.

v Appendix C, “Example NSM service templates,” on page 141Provides example NSM service templates that NSM service designers can use asmodels for creating their own NSM service templates.

© Copyright IBM Corp. 2012, 2013 v

PublicationsThis section lists publications in the Netcool Configuration Manager PDFdocument set. The prerequisite publications in the IBM Tivoli Network Manager IPEdition and IBM Tivoli Netcool/OMNIbus library are also listed here. The sectionalso describes how to access Tivoli publications online and how to order Tivolipublications.

Netcool Configuration Manager PDF document set

The following documents are available in the Netcool Configuration Managerlibrary:v IBM Tivoli Netcool Configuration Manager Installation and Configuration Guide

Describes how to install IBM Tivoli Netcool Configuration Manager. It alsodescribes necessary and optional post-installation configuration tasks. Thispublication is for administrators who need to install and set up IBM TivoliNetcool Configuration Manager.

v IBM Tivoli Netcool Configuration Manager User Guide

Describes user tasks for IBM Tivoli Netcool Configuration Manager, such as howto access reports, use devices, and execute the different utilities to maintain andsupport Auto-Discovery. This publication is for users working with IBM TivoliNetcool Configuration Manager.

v IBM Tivoli Netcool Configuration Manager Administration Guide

Describes administration tasks for IBM Tivoli Netcool Configuration Manager,such as how to set up user accounts, create and manage the OS registry,administer database and policy exports and imports, and perform housekeepingand security tasks. This publication is for administrators who are responsible forthe maintenance and availability of IBM Tivoli Netcool Configuration Manager.

v IBM Tivoli Netcool Configuration Manager Reference Guide

Contains reference information about IBM Tivoli Netcool ConfigurationManager.

v IBM Tivoli Netcool Configuration Manager API Guide

Provides information about how to use the Java API to programmatically accessIBM Tivoli Netcool Configuration Manager.

v IBM Tivoli Netcool Configuration Manager NSM REST API GuideDescribes the Service Management Interface API.

v IBM Tivoli Netcool Configuration Manager Integration Guide

Describes how to integrate Netcool Configuration Manager with TivoliNetcool/OMNIbus and Network Manager.

v IBM Tivoli Netcool Configuration Manager Quick Start Guide

Gets you started with a typical installation for IBM Tivoli Netcool ConfigurationManager.

v IBM Tivoli Netcool Configuration Manager Release Notes

Gives important and late-breaking information about IBM Tivoli NetcoolConfiguration Manager. This publication is for deployers and administrators,and should be read first.

Prerequisite publications: IBM Tivoli Network Manager IP Edition

To use the information in this publication effectively when dealing with anintegrated installation of Netcool Configuration Manager, Network Manager, and

vi IBM Tivoli Netcool Configuration Manager: Network Service Manager REST API

Tivoli Netcool/OMNIbus, you must have some prerequisite knowledge, which youcan obtain from the Network Manager documentation, especially the followingpublications:v IBM Tivoli Network Manager IP Edition Release Notes

Gives important and late-breaking information about IBM Tivoli NetworkManager IP Edition. This publication is for deployers and administrators, andshould be read first.

v IBM Tivoli Network Manager Getting Started Guide

Describes how to set up IBM Tivoli Network Manager IP Edition after you haveinstalled the product. This guide describes how to start the product, make sure itis running correctly, and discover the network. Getting a good networkdiscovery is central to using Network Manager IP Edition successfully. Thisguide describes how to configure and monitor a first discovery, verify the resultsof the discovery, configure a production discovery, and how to keep the networktopology up to date. Once you have an up-to-date network topology, this guidedescribes how to make the network topology available to Network Operators,and how to monitor the network. The essential tasks are covered in this shortguide, with references to the more detailed, optional, or advanced tasks andreference material in the rest of the documentation set.

v IBM Tivoli Network Manager IP Edition Product Overview

Gives an overview of IBM Tivoli Network Manager IP Edition. It describes theproduct architecture, components and functionality. This publication is foranyone interested in IBM Tivoli Network Manager IP Edition.

v IBM Tivoli Network Manager IP Edition Installation and Configuration Guide

Describes how to install IBM Tivoli Network Manager IP Edition. It alsodescribes necessary and optional post-installation configuration tasks. Thispublication is for administrators who need to install and set up IBM TivoliNetwork Manager IP Edition.

v IBM Tivoli Network Manager IP Edition Administration Guide

Describes administration tasks for IBM Tivoli Network Manager IP Edition, suchas how to administer processes, query databases and start and stop the product.This publication is for administrators who are responsible for the maintenanceand availability of IBM Tivoli Network Manager IP Edition.

v IBM Tivoli Network Manager IP Edition Discovery Guide

Describes how to use IBM Tivoli Network Manager IP Edition to discover yournetwork. This publication is for administrators who are responsible forconfiguring and running network discovery.

v IBM Tivoli Network Manager IP Edition Event Management Guide

Describes how to use IBM Tivoli Network Manager IP Edition to poll networkdevices, to configure the enrichment of events from network devices, and tomanage plug-ins to the Tivoli Netcool/OMNIbus Event Gateway, includingconfiguration of the RCA plug-in for root-cause analysis purposes. Thispublication is for administrators who are responsible for configuring andrunning network polling, event enrichment, root-cause analysis, and EventGateway plug-ins.

v IBM Tivoli Network Manager IP Edition Network Troubleshooting Guide

Describes how to use IBM Tivoli Network Manager IP Edition to troubleshootnetwork problems identified by the product. This publication is for networkoperators who are responsible for identifying or resolving network problems.

v IBM Tivoli Network Manager IP Edition Network Visualization Setup Guide

About this publication vii

Describes how to configure the IBM Tivoli Network Manager IP Edition networkvisualization tools to give your network operators a customized workingenvironment. This publication is for product administrators or team leaders whoare responsible for facilitating the work of network operators.

v IBM Tivoli Network Manager IP Edition Management Database Reference

Describes the schemas of the component databases in IBM Tivoli NetworkManager IP Edition. This publication is for advanced users who need to querythe component databases directly.

v IBM Tivoli Network Manager IP Edition Topology Database Reference

Describes the schemas of the database used for storing topology data in IBMTivoli Network Manager IP Edition. This publication is for advanced users whoneed to query the topology database directly.

v IBM Tivoli Network Manager IP Edition Language Reference

Describes the system languages used by IBM Tivoli Network Manager IPEdition, such as the Stitcher language, and the Object Query Language. Thispublication is for advanced users who need to customize the operation of IBMTivoli Network Manager IP Edition.

v IBM Tivoli Network Manager IP Edition Perl API Guide

Describes the Perl modules that allow developers to write custom applicationsthat interact with the IBM Tivoli Network Manager IP Edition. Examples ofcustom applications that developers can write include Polling and DiscoveryAgents. This publication is for advanced Perl developers who need to write suchcustom applications.

v IBM Tivoli Monitoring for Tivoli Network Manager IP User's Guide

Provides information about installing and using IBM Tivoli Monitoring for IBMTivoli Network Manager IP Edition. This publication is for systemadministrators who install and use IBM Tivoli Monitoring for IBM TivoliNetwork Manager IP Edition to monitor and manage IBM Tivoli NetworkManager IP Edition resources.

Prerequisite publications: IBM Tivoli Netcool/OMNIbus

To use the information in this publication effectively when dealing with anintegrated installation of Netcool Configuration Manager, Network Manager, andTivoli Netcool/OMNIbus, you must have some prerequisite knowledge, which youcan obtain from the Tivoli Netcool/OMNIbus documentation, especially thefollowing publications:v IBM Tivoli Netcool/OMNIbus Installation and Deployment Guide

Includes installation and upgrade procedures for Tivoli Netcool/OMNIbus, anddescribes how to configure security and component communications. Thepublication also includes examples of Tivoli Netcool/OMNIbus architectures anddescribes how to implement them.

v IBM Tivoli Netcool/OMNIbus User's Guide

Provides an overview of the desktop tools and describes the operator tasksrelated to event management using these tools.

v IBM Tivoli Netcool/OMNIbus Administration Guide

Describes how to perform administrative tasks using the TivoliNetcool/OMNIbus Administrator GUI, command-line tools, and process control.The publication also contains descriptions and examples of ObjectServer SQLsyntax and automations.

v IBM Tivoli Netcool/OMNIbus Probe and Gateway Guide

viii IBM Tivoli Netcool Configuration Manager: Network Service Manager REST API

Contains introductory and reference information about probes and gateways,including probe rules file syntax and gateway commands.

v IBM Tivoli Netcool/OMNIbus Web GUI Administration and User's Guide

Describes how to perform administrative and event visualization tasks using theTivoli Netcool/OMNIbus Web GUI.

Accessing terminology online

The IBM Terminology website consolidates the terminology from IBM productlibraries in one convenient location. You can access the Terminology website at thefollowing Web address:

http://www.ibm.com/software/globalization/terminology

Accessing publications online

IBM posts publications for this and all other Tivoli products, as they becomeavailable and whenever they are updated, to the Tivoli Information Center websiteat:

http://publib.boulder.ibm.com/infocenter/tivihelp/v3r1/index.jsp

Note: If you print PDF documents on other than letter-sized paper, set the optionin the File > Print window that allows Adobe Reader to print letter-sized pages onyour local paper.

Ordering publications

You can order many Tivoli publications online at the following website:

http://www.elink.ibmlink.ibm.com/publications/servlet/pbi.wss

You can also order by telephone by calling one of these numbers:v In the United States: 800-879-2755v In Canada: 800-426-4968

In other countries, contact your software account representative to order Tivolipublications. To locate the telephone number of your local representative, performthe following steps:1. Go to the following website:

http://www.elink.ibmlink.ibm.com/publications/servlet/pbi.wss2. Select your country from the list and click Go. The Welcome to the IBM

Publications Center page is displayed for your country.3. On the left side of the page, click About this site to see an information page

that includes the telephone number of your local representative.

About this publication ix

http://www.ibm.com/software/globalization/terminology

http://publib.boulder.ibm.com/infocenter/tivihelp/v3r1/index.jsp



AccessibilityAccessibility features help users with a physical disability, such as restrictedmobility or limited vision, to use software products successfully.

With this product, you can use assistive technologies to hear and navigate theinterface. You can also use the keyboard instead of the mouse to operate allfeatures of the graphical user interface.

Tivoli technical training

For Tivoli technical training information, refer to the following IBM TivoliEducation website:

http://www.ibm.com/software/tivoli/education

Support informationIf you have a problem with your IBM software, you want to resolve it quickly. IBMprovides the following ways for you to obtain the support you need:

OnlineGo to the IBM Software Support site at http://www.ibm.com/software/support/probsub.html and follow the instructions.

IBM Support AssistantThe IBM Support Assistant (ISA) is a free local software serviceabilityworkbench that helps you resolve questions and problems with IBMsoftware products. The ISA provides quick access to support-relatedinformation and serviceability tools for problem determination. To installthe ISA software, go to http://www.ibm.com/software/support/isa

Conventions used in this publicationThis publication uses several conventions for special terms and actions andoperating system-dependent commands and paths.

Typeface conventions

This publication uses the following typeface conventions:

Bold

v Lowercase commands and mixed case commands that are otherwisedifficult to distinguish from surrounding text

v Interface controls (check boxes, push buttons, radio buttons, spinbuttons, fields, folders, icons, list boxes, items inside list boxes,multicolumn lists, containers, menu choices, menu names, tabs, propertysheets), labels (such as Tip: and Operating system considerations:)

v Keywords and parameters in text

Italic

v Citations (examples: titles of publications, diskettes, and CDs)v Words defined in text (example: a nonswitched line is called a

point-to-point line)

x IBM Tivoli Netcool Configuration Manager: Network Service Manager REST API

http://www.ibm.com/software/tivoli/education

http://www.ibm.com/software/support/probsub.html

http://www.ibm.com/software/support/probsub.html

http://www.ibm.com/software/support/isa

v Emphasis of words and letters (words as words example: "Use the wordthat to introduce a restrictive clause."; letters as letters example: "TheLUN address must start with the letter L.")

v New terms in text (except in a definition list): a view is a frame in aworkspace that contains data

v Variables and values you must provide: ... where myname represents....

Monospace

v Examples and code examplesv File names, programming keywords, and other elements that are difficult

to distinguish from surrounding textv Message text and prompts addressed to the userv Text that the user must typev Values for arguments or command options

Operating system-dependent variables and paths

This publication uses the UNIX convention for specifying environment variablesand for directory notation.

When using the Windows command line, replace $variable with %variable% forenvironment variables, and replace each forward slash (/) with a backslash (\) indirectory paths. For example, on UNIX systems, the $NCHOME environmentvariable specifies the directory where the Network Manager core components areinstalled. On Windows systems, the same environment variable is %NCHOME%.The names of environment variables are not always the same in the Windows andUNIX environments. For example, %TEMP% in Windows environments isequivalent to $TMPDIR in UNIX environments.

If you are using the bash shell on a Windows system, you can use the UNIXconventions.

About this publication xi

xii IBM Tivoli Netcool Configuration Manager: Network Service Manager REST API

Chapter 1. Overview of the Network Service Manager RESTAPI

Use this information to obtain an overview of the Network Service Manager RESTAPI.

About the NSM REST APINetcool Configuration Manager is an intelligent tool for managing networkoperations and compliance. It includes a new REST API called the Network ServiceManager REST API (NSM REST API) that allows client users to access the featuresthat the Netcool Configuration Manager tool provides.

Netcool Configuration Manager offers features that include configurationmanagement, device discovery, configuration backup, configuration extraction, andcommand sets. The NSM REST API allows NSM client users to integrate theirexisting systems to Netcool Configuration Manager to benefit from the NetcoolConfiguration Manager product features.

NSM architectureThe NSM REST API offers a comprehensive REST API to enable easy integrationwith client user systems to the Netcool Configuration Manager system.

Specifically, the NSM REST API offers access to the following objects:v Devicesv Realmsv Service templatesv Services

NSM allows the NSM client user to access the Netcool Configuration Managerdevice inventory through the NSM REST API by using the NSM device URIs. Thisallows client users to access device information gathered from the NetcoolConfiguration Manager device discovery features such as the device Vendor, Type,Model, and OS (VTMOS). NSM can also retrieve the device's current configurationas stored on the Netcool Configuration Manager system.

The NSM client user can also use the NSM realm URIs to search NetcoolConfiguration Manager realms. Searching realms through the NSM REST APIenables client users to view the Netcool Configuration Manager artifacts withinrealms. Netcool Configuration Manager realms are used to structure the commandsets, devices, and other Netcool Configuration Manager artifacts on the NetcoolConfiguration Manager system.

NSM has a framework that NSM service designers use to define NSM servicetemplates that can be used to create network services. Network services can be anynetwork service from simple Firewall Zones established for a client user on asingle device, to a VLAN being created across a network. To create a networkservice, the configuration of the network devices need to be changed. NetcoolConfiguration Manager command sets are used to apply this configuration in acontrolled manner on the network devices.

© Copyright IBM Corp. 2012, 2013 1

NSM service templates allow for the easy and consistent execution of NetcoolConfiguration Manager command sets. NSM service templates allow the executionof Netcool Configuration Manager device synchronizations and extractions. NSMservice templates also allow client users to:v Simplify the creation, modification, and deletion of network services on network

devicesv Hide the complexity of the network service away from the client userv Support multiple device types with the one NSM service templatev Create a robust and reproducible network configuration service solution

NSM service lifecycleNSM provides the NSM client user with NSM service URIs to enable the creationof network services from the NSM service templates. NSM allows for networkservices to be managed from creation to deletion.

Figure 2 on page 3 depicts the flow of the NSM service lifecycle.

C: \ >

NSM URIs

Submit work

NSM command line tools

Managed Devices

POST

Netcool ConfigurationManager

NSM REST API

NSM Parameter Engine

Retrievestatus

DELETE

GET

Client System

NSM Architecture

Figure 1. NSM Architecture

2 IBM Tivoli Netcool Configuration Manager: Network Service Manager REST API

As the figure shows, the NSM service lifecycle consists of the following:v Network service design — The NSM service designer plans the type of network

service that client users want to offer.v Command set creation — The NSM service designer uses the Netcool

Configuration Manager tools to create and maintain the command setsassociated with the network service on the network devices.

v Service template creation — The NSM service designer uses the NSM servicetemplate XML to design how the service should be exposed to client users. TheNSM service designer also decides how the parameters for the command setsshould be calculated and in what order they should execute.

v Import NSM service templates — The NSM service designer uses the NSMcommand line tools to import the NSM service template design XML files intothe Netcool Configuration Manager database.

v Client views new service — The client user uses the NSM service template RESTURIs to view the new network service being offered.

v Client requests new service — The client user can now request the NSM serviceof choice using the NSM REST URIs.

v NSM executes service — NSM executes the network service as dictated by theNSM service template. NSM communicates with Netcool Configuration Managerto create the work items needed to complete the service on the network device.

v Client checks for service status — The client user can view service executionstatus using the NSM service URIs. The client user can also check for specificconfiguration changes using extractions.

C: \ >

XML

Cancel

OK

NSM executesservice

Client checks servicestatus

Client requests newservice

NSM Service Lifecycle

Command setcreation

Servicetemplatecreation

Import servicetemplates

Network service design

Service removal

Client views newservice

Full changehistory and

control

Figure 2. NSM Service Lifecycle

Chapter 1. Overview of the Network Service Manager REST API 3

v Service removal — Depending on how the NSM service template was designed,either the client user can request for a network service to be deleted using theNSM REST API or the service designer can create a schedule for when thenetwork service can be removed.

NSM parameter calculationNSM provides the NSM service designer the ability to decide how to calculateparameters used in the NSM service lifecycle.

Figure 3 shows the NSM parameter calculation engine and how it calculates NSMparameters.

Specifically, the NSM parameter engine calculates the following types ofparameters:v Client parameters — NSM can accept parameter name/values from the client to

pass directly to command sets or NSM can use the parameter name/values inthe NSM parameter engine to calculate other parameters.

v SQL parameters — NSM can query external or internal databases to retrieveparameter values. The arguments to the SQL query can be provided by the clientuser or can be injected by the NSM service designer.

v JavaScript parameters — NSM allows the execution of NSM provided JavaScriptmethods to manipulate parameters. NSM also allows the NSM service designerto provide their own controlled JavaScript.

v HTTP parameters — NSM allows the retrieval of parameters by calling an HTTPclient using the URL that the NSM service designer provides.

Figure 3 also shows that Netcool Configuration Manager command sets applyparameter values as calculated by the NSM parameter engine. The NSM servicedesigner sets up parameters in the NSM service template so that:

HTTP parameters

Client parameters

JavaScript parameters

NCM commandsets

NSM Parameter Calculation

SQL parameters

NSM parameter engine

Figure 3. NSM Parameter Calculation


v Client users can specify values for the client parametersv Client users can specify inject parameters through preset NSM functions or

user-defined JavaScript functionsv NSM can query external or internal databases to retrieve parameter values for

SQL queriesv NSM can retrieve parameter values using an HTTP request

NSM rolesUsers with the roles of NSM service designer, NSM client user, and NetcoolConfiguration Manager administrator can complete tasks on a Netcool ServiceManager system. This topic describes the main responsibilities for each NSM role.The users are referred to throughout NSM information topics.

Table 1. NSM user roles and functions

NSM role Responsibilities

NSM servicedesigner

The NSM service designer designs NSM service templates that can beused by NSM client users. The NSM service designer can create NSMservice templates so that the NSM service execution engine will call theNetcool Configuration Manager artifacts such as command sets,extractions, and device synchronizations with the required parameters.The NSM service templates are designed so that NSM client users canpopulate the correct information for some parameters while otherparameters are calculated by the NSM Parameter Engine. By using thecommand-line tool, NSM service designers can create and maintain theseNSM service templates.

NSM service designers must have the activity Service TemplateManagement assigned to them by the Netcool Configuration Manageradministrator. In addition, the NSM service designer can also use anyNSM REST API URI that an NSM client user can access.

Note: NSM service designers require the Netcool Configuration Manageradministrator to grant them access to the realms that hold devices theywant to retrieve and access to realms that have the command sets andextractions that the NSM service templates need to execute.

NSM client user The NSM client user uses NSM REST API URIs to retrieve provisionedNSM service templates lists, retrieve device inventory, search realms andsubmit and monitor services from a client application. Depending onhow the NSM service designer defines the NSM service template, theseNSM client users might need to provide values for some parameters.NSM client users do not require any knowledge of underlying NetcoolConfiguration Manager command sets that the NSM Service Engineexecutes.

NSM client users must have the activity Service Management assigned tothem by the Netcool Configuration Manager administrator. NSM clientusers do not have permission to create NSM service templates.

Note: NSM client users require the Netcool Configuration Manageradministrator to grant them access to the realms that hold devices theywant to retrieve and access to realms that have the command sets andextractions that the NSM service templates need to execute.

Chapter 1. Overview of the Network Service Manager REST API 5

Table 1. NSM user roles and functions (continued)

NSM role Responsibilities

NetcoolConfigurationManageradministrator

The Netcool Configuration Manager administrator is responsible foradministering Netcool Configuration Manager in the context of users,access, configuration, installations, upgrade, and so forth. After NetcoolConfiguration Manager is installed and configured, the NetcoolConfiguration Manager administrator does not need to be active onNSM.

The Netcool Configuration Manager administrator is responsible forassigning the activities Service Template Management to NSM servicedesigners and Service Management to NSM client users.

The Netcool Configuration Manager is also responsible for granting NSMservice designers and NSM client users access to the necessary realms.The Netcool Configuration Manager administrator must ensure that theNSM service designer has execute permissions for the nsmadmin.shcommand line script.

NSM client users can skip to Chapter 6, “Understanding the Network ServiceManager URIs,” on page 77 and Chapter 8, “Troubleshooting,” on page 123. NSMservice designers should read the entire guide.


Chapter 2. Designing a NSM service template

NSM service designers configure NSM service templates to allow NSM client usersto initiate services for execution.

This information unit explains the main tasks involved in designing a NSM servicetemplate.

To illustrate the main tasks, an example to design a NSM service template to createzones for a firewall is used.

Structure of a NSM service templateThe following sample XML shows the basic structure of a NSM service template tocreate zones for a firewall.

The sample XML identifies the main tags that a NSM service template can contain.<serviceTemplate name="FirewallCreateZones" description="Create a Firewall Zone" timeToDelete="1" ><clientParameter><name>FIREWALLZONENAME</name><description>The Customer Zone Name e.g. cz_8262</description></clientParameter>

<implementations><implementation><rules><rule type="DeviceType"><ruleProperty name="Vendor" value="IBM"/><ruleProperty name="Type" value="Router"/><ruleProperty name="Model" value=".*"/><ruleProperty name="OS" value=".*"/></rule></rules><serviceOperations><serviceOperation type="CREATE"><operations><operation name="ITNCM/FirewallCreateZones" type="COMMANDSET"><parameters><parameter name="FIREWALLZONENAME"/></parameters></operation></operations></serviceOperation></serviceOperations></implementation></implementations>

</serviceTemplate>

Note: Some of the XML tags can include additional optional attributes that are notshown in this NSM service template.


ParametersNSM service designers use parameters in NSM service templates to enableappropriate values to be passed on to Netcool Configuration Manager commandsets as command set parameters.

NSM service designers can use the following types of parameters when defininghow parameters values can be calculated:v Constant parameters — NSM service designers can define constant parameters

in the NSM service template XML using the <constantParameter> element andassign values to them using the <name> and <value> tags when they design NSMservice templates.

v Client parameters — NSM service designers can define client parameters in theNSM service template XML using the <clientParameter> element and theirvalues are populated by NSM client users. The <clientParameter> elementmakes use of the <name> tag.

v Inject parameters — NSM service designers can define inject parameters in theNSM service template XML using the <injectParameter> element and theirvalues are populated by evaluating the results of functions when the service isexecuted. The <injectParameter> element makes use of the <name>,<methodCall>, and <arguments> tags.

v SQL parameters — NSM service designers can define SQL parameters in theNSM service template XML using the <sqlParameter> element. SQL parametervalues are validated when they are submitted and before the service is run. The<sqlParameter> element makes use of the <name> and <sql> tags.

v HTTP parameters — NSM service designers can define HTTP parameters in theNSM service template XML using the <httpParameter> element. HTTPparameters are populated by running a GET command and are evaluated whenthe service is run. The <httpParameter> element makes use of the <name>,<arguments>, and <url> tags.

v Client parameter lists — NSM service designers can define client parameter listsin the NSM service template XML using the <clientParameterList> element andtheir values are populated by NSM client users. The <clientParameterList>element makes use of the name attribute and the <parameter name> and <value>tags.

Each parameter type can be either global or local. Global parameters are used byall implementations. Local parameters are specific to the <implementation> elementin which they are defined. For example, if there is a global client parameter calledZONENAME and a local SQL parameter also called ZONENAME then the value of thelocal SQL parameter will be used.

Client parameters that are global are sent to the NSM client user to be populatedirrespective of the <implementation> element that is selected for the NSM servicetemplate. The data is set in the <value> tag of the <clientParameter> element.

SQL, HTTP, and inject parameters that are global are also used by the<implementation> element that is selected for the NSM service template. The datais set in the <value> tags of these parameters when the service is executed.

Local parameters are specific to their own <implementation> element, and they donot affect anything outside this implementation. For client parameters that arelocal, if the <implementation> element in which they are contained is selectedbased on the device type, only then are they sent to the NSM client user to bepopulated at service run time.


For SQL, HTTP, and inject parameters that are local, they are only calculatedduring service execution if the <implementation> element in which they arecontained is selected based on the device type.

Client parameter lists that are placed at the global level of the NSM servicetemplate can be used by all implementation. Use of client parameter lists within animplementation is determined by the placement of the name attribute found in the<clientParameterList> element, for example, <clientParameterListname="CPL_01"> . The name attribute should be placed in the list of parameterswithin an <operation> element. The <clientParameterList> elements at a globallevel are similar to <clientParameter> elements at a global level in that they aresent to the NSM client user to be populated irrespective of the <implementation>element that is selected for the NSM service template. The data is set in the<value> tag of the <clientParameterList> element and can contain multiple valuesthat can be populated by the NSM client user.Related reference:“Constant parameters” on page 25“Client parameters” on page 27“Client parameter list parameters” on page 29“Inject parameters” on page 34“SQL parameter element and tags” on page 41“HTTP parameters” on page 43“<implementations> element”

<implementations> elementThe <implementations> element is a container that includes rules, local parameters,and the operations for the NSM service template.

The purpose of the <implementations> element is to ensure that the NSM clientuser is presented with the correct implementation in a particular NSM servicetemplate based on the device that the NSM client user has selected to run theservice on. Local client parameters such as inject, SQL, and HTTP parameters canalso be contained in the <implementations> element and executed at this stage. Forexample, if SQL parameters are configured, the SQL statement is executed on thedatabase connection that is specified in the <databaseConnection> element.

Operations are also contained in the <implementations> element. Operations cancontain individual operations, all of which are selected for service execution.

The following XML shows the full implementation details to create zones for afirewall service. Note that the <implementations> and </implementations>elements encapsulate the XML elements and tags that define the zones for afirewall service with separate implementations for Juniper and CISCO Routers.Thus, if the NSM client user wants the Firewall service to run on a CISCO device,the operation ITNCM/FirewallCreateZones-Cisco-Router (<operationname="ITNCM/FirewallCreateZones-Cisco-Router") will run. If the NSM client userwants to execute the Firewall service on a Juniper router, then the operationITNCM/FirewallCreateZones (<operation name="ITNCM/FirewallCreateZones") willrun.<implementations><implementation description="Implementation Rule for all Cisco Routers"><rules><rule type="DeviceType"><ruleProperty name="Vendor" value="Cisco"/><ruleProperty name="Type" value="Router"/>

Chapter 2. Designing a NSM service template 9

<ruleProperty name="Model" value=".*"/><ruleProperty name="OS" value=".*"/></rule></rules><databaseConnection><driverClassName>oracle.jdbc.driver.OracleDriver</driverClassName><url>jdbc:oracle:thin:@test.example.com:testdb2</url><username>oracleuser</username><password>password</password></databaseConnection><clientParameterLists><clientParameterList name="ZONEID">

<parameter name="ZONE_NAME"/></clientParameterList><clientParameterList name="ROUTEDETAILS"><parameter name="SOURCEROUTETABLE"/><parameter name="TARGETROUTETABLE"/><parameter name="VIRTUALROUTERNAME"/>

</clientParameterList></clientParameterLists><sqlParameters><sqlParameter><name>SOURCEROUTETABLE</name><sql>select servername from task where id = 3</sql></sqlParameter></sqlParameters><serviceOperations><serviceOperation name="createOperation" type="Create">

<operations><operation name="ITNCM/FirewallCreateZones-Cisco-Router" rollback="true"

type="COMMANDSET"><parameters><parameter name="VIRTUALROUTERNAME"/><parameter name="NAME"/><parameter name="SOURCEROUTETABLE"/><parameter name="TARGETROUTETABLE"/>

<parameter name="ZONEID"/><parameter name="ROUTEDETAILS"/>

</parameters></operation></operations></serviceOperation></serviceOperations>

</implementation><implementation description="Implementation Rule for all Juniper Routers"><rules><rule type="DeviceType"><ruleProperty name="Vendor" value="Juniper"/><ruleProperty name="Type" value="Router"/><ruleProperty name="Model" value=".*"/><ruleProperty name="OS" value=".*"/></rule></rules><clientParameters><clientParameter><name>RIBGROUPNAME</name></clientParameter></clientParameters><serviceOperations><serviceOperation name="createOperation" type="Create"><operations><operation name="ITNCM/FirewallCreateZones" rollback="true" type="COMMANDSET"><parameters><parameter name="VIRTUALROUTERNAME"/><parameter name="NAME"/><parameter name="SOURCEROUTETABLE"/><parameter name="TARGETROUTETABLE"/><parameter name="RIBGROUPNAME"/></parameters></operation></operations></serviceOperation></serviceOperations>

</implementation></implementations>


Related concepts:“Parameters” on page 8

Configuring rulesA <rule> element includes one type called DeviceType. The DeviceType includesfour properties, which are attributes of the device.

A <rule> element must include a type attribute and one or more <ruleProperty>elements which define the effect of the rule. The <ruleProperty> element specifiesa name and value pair for each of the rule properties the rule contains. At presentonly DeviceType rules are supported and the <ruleProperty> elements for this ruletype define the attributes of devices to which the rules can be applied. There arefour attributes which can be specified for a device: the vendor or manufacturer ofthe device, its type, model, and the operating system version of the onboardsoftware. Together these properties are known as VTMOS. The VTMOS data isstored on the Netcool Configuration Manager presentation server for every devicethat has been discovered. The DeviceType rule for an implementation must specifyall four values for the VTMOS data of the devices to which it can be applied. Anindividual <ruleProperty> element is expected within a DeviceType rule for each ofthe following four names:v Vendorv Typev Modelv OS

The name attribute of the <ruleProperty> element must be specified as shown inthe procedure. You can use regular expressions for each of the four names (forexample, value=".*").

Use the <rule> element to determine which implementation to select when anNSM client user requests a NSM service template for service execution. If the NSMclient user that is requesting the NSM service template uses a device id for adevice that equals the vendor, type, model, and operating system that are specifiedin the following <ruleProperty> tags, then the implementation based on this rule isselected.

Procedure

The NSM service designer can manage, using regular expressions, which devicesshould be allowed to execute operations in this implementation based on the ruleproperties (using the <ruleProperty> tags) that they define. For example, if anNSM service designer wants an implementation that can run operations for allCISCO routers, regardless of model and operating system, then they would createa rule such as shown in the following example. The ".*" for Model and the OS inregular expression format means match anything for model and operating system.Thus, the regular expression would select all CISCO routers.<rules>

<rule type="DeviceType"><ruleProperty name="Vendor" value="Cisco"/><ruleProperty name="Type" value="Router"/><ruleProperty name="Model" value=".*"/><ruleProperty name="OS" value=".*"/></rule></rules>


Example

To exactly match devices that have a Model "10.*", then the regular expressionformat in the <ruleProperty> tag must be written as follows:<ruleProperty name="Model" value="10\.\*"/>

where: the \ (backslash) is used to escape the . (period) and * (asterisk) characters,which have special meaning in regular expressions.

If the device operating system that you want to match is C2600-IS-M-12.2(3), thenthe regular expression format in the <ruleProperty> tag must be written asfollows:<ruleProperty name="Model" value="C2600-IS-M-12\.2$3$"/>

where: the \ (backslash) is used to escape the . (period) and () (left and rightparentheses) characters, which have special meaning in regular expressions.

If the device operating system that you want to match is *M56*, then the regularexpression format in the <ruleProperty> tag must be written as follows:<ruleProperty name="Model" value= "\*M56\*"/>

where: the \ (backslash) is used to escape the * (asterisk) characters, which havespecial meaning in regular expressions.

Configuring service operationsA service operation specifies the type of service operation to be carried outaccording to the specified operations. Operations are encapsulated in the<serviceOperation> and </serviceOperation> elements.

There are two types of service operations: CREATE and DELETE. The operationsthemselves are encapsulated in <operation> and </operation> elements. Eachservice operation requires the type attribute. This type attribute currently supportstwo types: CREATE, which sets up a service and DELETE, which tears down a service.An optional name attribute can be specified to identify a service operation.

An <operation> element includes a name attribute. It also includes the parameterlist that is used when the service is submitted for execution and other attributes.The NSM service designer uses this parameter list to verify that the requiredparameters are specified in the NSM service template during its creation. The NSMservice designer also uses this parameter list to filter parameters so that only therequired ones are submitted to execute the service.

Procedure1. As the NSM service designer use the following example as a guide to

configuring service operations and operations. The example presents aconfigured operation for creating zones for a firewall.<serviceOperations><serviceOperation name="createOperation" type="CREATE"><operations><operation name="ITNCM/FirewallCreateZones-Cisco-Router" rollback="true" type="COMMANDSET"><parameters><parameter name="VIRTUALROUTERNAME"/><parameter name="NAME"/><parameter name="SOURCEROUTETABLE"/><parameter name="TARGETROUTETABLE"/><parameter name="ZONEID"/></parameters>


</operation></operations>

</serviceOperation></serviceOperations>

2. Specify values for the <serviceOperation> element as follows:a. (Optional) Enter the name of the service operation in the name attribute. In

the example, the service operation name is createOperation.b. Enter the service operation type in the type attribute. In the example, the

service operation type specified is CREATE, which specifies a create service.3. Specify values for the <operation> element as follows:

a. Enter the name of the operation in the name attribute. In the example, theoperation name is ITNCM/FirewallCreateZones-Cisco-Router, which is thefully qualified name of the command set on Netcool ConfigurationManager.

b. Set the value for rollback in the rollback attribute to either true or false.In the example, the rollback is set to true.If an operation fails while it is being executed and rollback is set to "true",the operation is reverted and the device is returned to its originalconfiguration before the operation started. If rollback is set to "false", thenrollback is not configured and the operation is not reverted to its originalconfiguration.

c. Enter the operation type in the type attribute. In the example, the operationtype is COMMANDSET.Valid values for the type attribute are: COMMANDSET, EXTRACTION, andDEVICESYNC.

4. Populate the parameters list with the required parameters for the NSM servicedesigner to be used in service execution.If the operation type is COMMANDSET, the parameters specified in the nameattributes must match the parameters that are required in the command setconfigured on the Netcool Configuration Manager presentation server.

Note: For a client parameter list to specify the parameters to be used within anoperation, the name attribute of the <clientParameterList> element must beused to link the client parameter list to the operation.For example:<clientParameterLists><clientParameterList name="CPL_NAME"><parameter name="SOURCEROUTETABLE"/><parameter name="TARGETROUTETABLE"/><parameter name="VIRTUALROUTERNAME"/></clientParameterList></clientParameterLists>...<serviceOperations><serviceOperation name="createOperation" type="CREATE"><operations><operation name="ITNCM/FirewallCreateZones-Cisco-Router" rollback="true" type="COMMANDSET"><parameters><parameter name="CPL_NAME"/></parameters></operation></operations></serviceOperation></serviceOperations>

Related reference:“Operation attributes and types” on page 14


Operation attributes and typesThe <operation> element can include the following attributes. Each operation canbe one of three types: COMMANDSET, EXTRACTION, and DEVICESYNC. NSM servicedesigners define <operation> elements to use one of these types.

Table 2. Operation attributes

Attribute name Description

name A mandatory attribute that specifies the operation name. The value ofthe name depends on the type of operation that is specified.

description An optional attribute that includes a description of the operation.

rollback An optional attribute that specifies whether an operation should bereverted if the operation fails. The default value is false. If it is set totrue, the operation is reverted when a failure occurs. The rollbackoptional attribute is only applicable to operations of type COMMANDSET.

type A mandatory attribute that specifies the type of the operation. The typesare: COMMANDSET, EXTRACTION, and DEVICESYNC.

order An optional attribute that specifies the order that operations areexecuted. For example, if one operation has order 1 and anotheroperation has order 2, the operation with order 1 is executed first, theoperation with order 2 is executed next. The order must be ascendingand order numbers can be repeated. For example, 1, 1, 1, 2, 2, 3,3means all operations with order 1 will get executed first, then operationswith order 2, and so on. Ordered and unordered operations cannot bemixed.

For more details on operation ordering and merging considerations, see“Controlling the order and merging of service operations” on page 17.

parameters An optional element that includes a list of parameters that the operationuses during its execution. For operations of type COMMANDSET, all NetcoolConfiguration Manager command set parameters must be listed here.

Table 3. Operation types

Operation type Description

COMMANDSET Runs a Netcool Configuration Manager command set on a target device.This command set is either NATIVE, SMARTMODEL, or COMMANDSET GROUP.

EXTRACTION Runs a Netcool Configuration Manager device configuration extractionon a target device.

The following example shows an EXTRACTION operation:

<operation name="ITNCM/ExtractZones" type="EXTRACTION"><parameters><parameter name="ZONENAME"/></parameters></operation>

DEVICESYNC Runs a Netcool Configuration Manager function to synchronize thelatest configuration from the target device and return it to NetcoolConfiguration Manager.

The following example shows a DEVICESYNC operation:

<operation name="DEVICESYNC" type="DEVICESYNC"></operation>

Depending on the type of operation that is defined by the NSM service designer inthe operation, the attributes that the designer can include in the operation varies.


For an operation that has a COMMANDSET type configured, the name attribute ismandatory and it specifies the fully qualified name of the Netcool ConfigurationManager command. Any parameters that are required by the command set mustbe named in the parameter list of the operation. The values of these parameters areevaluated at service execution time and supplied to the command set beforeexecution in Netcool Configuration Manager.

For an operation that has an EXTRACTION type configured, the name attribute ismandatory and it specifies the fully qualified name of the Netcool ConfigurationManager extraction that is executed. All other attributes are optional for this type.The rollback attribute is not used by the EXTRACTION type. Any parameters that arerequired by the extraction must be named in the parameter list of the operation.The values of these parameters are evaluated at service execution time andsupplied to the extraction before execution in Netcool Configuration Manager.

For an operation that has a DEVICESYNC type configured, the name attribute ismandatory and must be specified as DEVICESYNC. All other attributes are optionalfor this type. The rollback and the parameter attributes are not used by theDEVICESYNC type.Related tasks:“Controlling the order and merging of service operations” on page 17“Configuring service operations” on page 12Related reference:“HTTP GET for /service” on page 98

Deleting NSM service template instancesNSM service designers delete NSM service template instances using either thetimeToDelete attribute or the <serviceOperation> element type attribute. Use thetimeToDelete attribute in the <serviceTemplate> element and specify the numberof minutes to deletion of the NSM service template instance. Use the type attributein the <serviceOperation> element and specify a type of DELETE.

There are two ways to delete a NSM service template instance from the system.Both mechanisms have different constraints on their usage and both executedifferently within the system. Specify only one of the deletion options in a NSMservice template: either the timeToDelete attribute in the <serviceTemplate>element or the type attribute with type DELETE in the <serviceOperation> element.The time to delete of a service instance starts from the point of service executioncompleting successfully. If service execution results in a failure, the automaticpurge will be cancelled.

The timeToDelete attribute is an optional attribute of the <serviceTemplate>element. The value specified for this attribute should be a positive integer greaterthan zero. The value represents the number of minutes to deletion of a NSMservice template instance. Using the timeToDelete attribute in the<serviceTemplate> element specifies when the NSM service template instancerecord can be purged from the system. This method removes the NSM servicetemplate instance record on NSM and no work will be submitted to NetcoolConfiguration Manager.

In the Procedure, you should perform either step 1 or step 2.


Procedure1. As the NSM service designer use one of the following examples as a guide to

deleting a NSM service template instance using the timeToDelete attribute inthe <serviceTemplate> element:<serviceTemplate name="FirewallCreateZones" timeToDelete="5">..

<implementations><implementation description="Implementation Rule for all Cisco Routers">...<serviceOperations><serviceOperation name="createOperation" type="CREATE"><operations>...</operations></serviceOperation></serviceOperations>

a. Specify the timeToDelete attribute in the <serviceTemplate> XML element.b. Assign a positive integer greater than zero that specifies the number of

minutes to deletion of the service instance. In the example, an instance ofthe NSM service template called FirewallCreateZones is posted to NSMwith a timeToDelete attribute set to five minutes. At some point after that, aservice is submitted for that NSM service template. Once the serviceinstance executes successfully, its record exists within NSM for the durationof the timeToDelete value. At that time the record of the service instancewill be removed from the system.

2. As the NSM service designer use the following example as a guide to deletinga NSM service template instance using the type attribute in the<serviceOperation> element:<serviceTemplate name="FirewallCreateZones" >...<implementations><implementation description="Implementation Rule for all Cisco Routers">...<serviceOperations><serviceOperation name="createOperation" type="CREATE">...</serviceOperation><serviceOperation name="deleteOperation" type="DELETE"><operations><operation name="ITNCM/FirewallDeleteZones-Cisco-Router" rollback="true" type="COMMANDSET"><parameters><parameter name="VIRTUALROUTERNAME"/><parameter name="NAME"/><parameter name="SOURCEROUTETABLE"/><parameter name="TARGETROUTETABLE"/></parameters></operation></operations></serviceOperation></serviceOperations></implementation><implementation description="Implementation Rule for all Juniper Routers"><serviceOperations><serviceOperation name="createOperation" type="CREATE">......</serviceOperation><serviceOperation name="deleteOperation" type="DELETE"><operations><operation name="ITNCM/FirewallDeleteZones" rollback="true" type="COMMANDSET"><parameters><parameter name="VIRTUALROUTERNAME"/><parameter name="NAME"/>parameter name="SOURCEROUTETABLE"/><parameter name="TARGETROUTETABLE"/><parameter name="RIBGROUPNAME"/></parameters></operation></operations>


</serviceOperation></serviceOperations></implementation></implementations></serviceTemplate>

a. Specify the type attribute with a value of DELETE in the <serviceOperation>XML element for each implementation of a NSM service template.In the example:v The service operation encapsulated within the Implementation Rule for

all Cisco Routers implementation specifies the type attribute with a valueof DELETE in the <serviceOperation> element.

v The service operation encapsulated within the Implementation Rule forall Juniper Routers implementation specifies the type attribute with avalue of DELETE in the <serviceOperation> element.

Note: Each service operation must have at least one operation to performthe deletion.

b. Use the HttpMethod DELETE on URI nsm/service/{service-id} to initiate thedelete of this service. This type of delete will result in work on the NetcoolConfiguration Manager server to complete the delete operations and thenremove the NSM record of the service instance.

Observe the following points when deleting NSM service template instances:v It is acceptable to specify both a service operation of type CREATE in the type

attribute and the timeToDelete attribute in the <serviceTemplate> element.v It is acceptable to specify both a service operation of type CREATE and type

DELETE in the type attributes in the <serviceOperation> element within the<implementation> element.

v When a NSM service template is posted, the system checks to ensure eachNSM service template has indicated a way to handle deletion. If thetimeToDelete value is set, then each <implementation> element must containjust one <serviceOperation> element with a type CREATE in the typeattribute. If the timeToDelete attribute is not set, then each <implementation>element must contain two <serviceOperation> elements: one with a typeattribute set to CREATE and the other type attribute set to DELETE.

v If a NSM service template does not conform to these rules, then the systemprovides an appropriate error code and message.

Controlling the order and merging of service operationsUse this information to learn how to use the order attribute in the <operation>element to control the order and merging of service operations in a NSM servicetemplate.

The order attribute controls the order in which the service operations get processedand how these operations get merged on the Netcool Configuration Managersystem. The following scenarios are worth considering when deciding whether andhow to use the order attribute:v The order in which the service operations get executed is not important and thus

no order attribute is specified. In this case, Netcool Configuration Manager canexecute the service operations in any order and thus for performance reasonsmay combine and merge these service operations in one Unit of Work (UOW).

v The order in which the service operations are executed is important. In this case,specify the order attribute in each of the configured <operation> elements.Netcool Configuration Manager creates a UOW for each of the configuredservice operations and executes them in the order specified.


v The order and merging are important. In this case, specify a group of orderattributes for the service operations. For example, service operation 1 and serviceoperation 2 might have order attributes with a value of 1 and service operation3 an order attribute with a value of 2. This scheme gives Netcool ConfigurationManager the ability to combine and merge some service operations to help withperformance and to also maintain the order for certain groups of serviceoperations.

v The order attribute is specified with a client parameter list.

The examples that follow cover the previously described scenarios.

Procedure1. As the NSM service designer use the following example as a guide to specify

service operations that can be executed in any order....<operations><operation name="ITNCM/FirewallDeleteZones" type="COMMANDSET"><parameters><parameter name="VIRTUALROUTERNAME1"/></parameters></operation><operation name="ITNCM/FirewallDeleteZones2" type="COMMANDSET"><parameters><parameter name="VIRTUALROUTERNAME2"/></parameters></operation><operation name="ITNCM/FirewallDeleteZones3" type="COMMANDSET"><parameters><parameter name="VIRTUALROUTERNAME3"/></parameters></operation></operations>...

a. Specify the name and type attribute in each of the <operation> elementsassociated with service operations.In the example, there are three service operations (ITNCM/FirewallDeleteZones1, ITNCM/FirewallDeleteZones2, andITNCM/FirewallDeleteZones3) configured as command sets with no orderattributes specified in the <operation> elements. In this case, NetcoolConfiguration Manager detects that these three command sets can executein any order and thus for performance reasons may combine and mergethese command sets in one UOW.Merging of native command sets and modelled command sets is notpossible, so the number of UOWs depends on the type of command sets inthe list. For example, if all three command sets are modelled command sets,or if all three command sets are native command sets then the work willexecute as one UOW on Netcool Configuration Manager. If one of thecommand sets is modelled and the other two are native, then the work willexecute as two UOWs on Netcool Configuration Manager, with the twonative command sets merged and executed as one of those two UOWs. Ifthe CommandSet Type on Netcool Configuration Manager is a CommandSet Group then merging depends on the constituent type of the commandsets within the Group. For example if the Command Set Group containsmodelled command sets these may be combined and merged with othermodelled command sets. The same applies to native command sets.

2. As the NSM service designer use the following example as a guide to specifyservice operations in a specific order:


.

.

.<operations><operation name="ITNCM/FirewallDeleteZones1" type="COMMANDSET" order=”1”><parameters><parameter name="VIRTUALROUTERNAME1"/></parameters></operation><operation name="ITNCM/FirewallDeleteZones2" type="COMMANDSET" order=”2”><parameters><parameter name="VIRTUALROUTERNAME2"/></parameters></operation><operation name="ITNCM/FirewallDeleteZones3" type="COMMANDSET" order=”3”><parameters><parameter name="VIRTUALROUTERNAME3"/></parameters></operation></operations>...

a. Specify the name and type attribute in each of the <operation> elementsassociated with service operations.In the example there are three service operations of type COMMANDSET:ITNCM/FirewallDeleteZones1, ITNCM/FirewallDeleteZones2, andITNCM/FirewallDeleteZones3.

b. Specify the order attribute in each of the <operation> elements associatedwith service operations. In the example, the order attribute is specified asfollows: the value 1 for ITNCM/FirewallDeleteZones1, the value 2 forITNCM/FirewallDeleteZones2, and the value 3 for ITNCM/FirewallDeleteZones3. In this scenario, Netcool Configuration Managercreates three UOWs, one for each of the configured service operations.Netcool Configuration Manager executes the UOWs in this order:v First, ITNCM/FirewallDeleteZones1 is executed in one UOW.v When the UOW for ITNCM/FirewallDeleteZones1 completes, the UOW

for ITNCM/FirewallDeleteZones2 is executed in a second UOW.v When the UOW for ITNCM/FirewallDeleteZones2 completes, the UOW

for ITNCM/FirewallDeleteZones3 is executed in a third UOW.3. As the NSM service designer use the following example as a guide to specify

service operations in a group order:...<operations><operation name="ITNCM/FirewallDeleteZones1" type="COMMANDSET" order=”1”><parameters><parameter name="VIRTUALROUTERNAME1"/></parameters></operation><operation name="ITNCM/FirewallDeleteZones2" type="COMMANDSET" order=”1”><parameters><parameter name="VIRTUALROUTERNAME2"/></parameters></operation><operation name="ITNCM/FirewallDeleteZones3" type="COMMANDSET" order=”2”><parameters><parameter name="VIRTUALROUTERNAME3"/></parameters></operation>...

a. Specify the name and type attribute in each of the <operation> elementsassociated with service operations.


In the example there are three service operations of type COMMANDSET:ITNCM/FirewallDeleteZones1, ITNCM/FirewallDeleteZones2, andITNCM/FirewallDeleteZones3.

b. Specify a group order in the order attribute in each of the <operation>elements associated with service operations. In the example, the orderattribute is specified as follows: the value 1 for ITNCM/FirewallDeleteZones1, the value 1 for ITNCM/FirewallDeleteZones2, andthe value 2 for ITNCM/FirewallDeleteZones3. In this scenario, NetcoolConfiguration Manager combines and merges the ITNCM/FirewallDeleteZones1/ITNCM/FirewallDeleteZones2 service operationsinto one UOW as they both have a group order number of 1. TheITNCM/FirewallDeleteZones3 service operation is executed as a separateUOW. Netcool Configuration Manager executes the UOWs in this order:v The ITNCM/FirewallDeleteZones1 and ITNCM/FirewallDeleteZones2

UOW is executed first, as they both have a group order number of 1.v When the UOW for ITNCM/FirewallDeleteZones1/ITNCM/

FirewallDeleteZones2 completes, the UOW for ITNCM/FirewallDeleteZones3 is executed.

Note: Ordering of operations into groups is allowed For example:1,1,1,1,2,2,2,3,3,4,4,4,4,4,4.

In some cases where the operation types differ, Netcool ConfigurationManager will not merge the operations, even if the operations areunordered or have the same order number. This is because NetcoolConfiguration Manager cannot merge operations of different types. Forexample, operations of type EXTRACTION cannot be merged with DEVICESYNCor COMMANDSET type operations.So if there are three unordered operations of types EXTRACTION, DEVICESYNC,and COMMANDSET this will result in three UOWs on the Netcool ConfigurationManager System as no combining and merging can be achieved as theoperations are all of different types.

4. As the NSM service designer use the following example as a guide to specifythe order attribute with a client parameter list:...<operations><operation name="ITNCM/FirewallDeleteZones1" type="COMMANDSET" order=”1”><parameters><parameter name="CPL1"/></parameters></operation></operations>....

For operations that take a client parameter list (specified in the<clientParameterList> element) as a parameter, then Netcool ConfigurationManager will merge the execution of each iteration of the client parameter listinto one UOW. For example, if the client parameter list, CPL1, has five values,then Netcool Configuration Manager will merge the five iterations ofITNCM/FirewallDeleteZones1 into one UOW.

Note: All operations must either be specified with the order attribute or not.Mixed order/non order operations are not allowed.


Related reference:“Operation attributes and types” on page 14

Posting a NSM service templateWhen the NSM service designer is finished designing the NSM service template, itmust be posted.

Procedure1. As the NSM service designer, copy the XML file that contains the NSM service

template to the NSM server.2. Change directory to the location of the NSM Command Line Tool. For example:

cd /opt/IBM/tivoli/netcool/ncm/bin/nsm

3. Run the NSM Command Line Tool with the create option, for example:./nsmadmin.sh command=create filename=<filename>

Substitute the options for the correct values.Related reference:“create command” on page 62

Submitting a NSM service template for executionTo submit a NSM service template so that it can be executed, the NSM client usermust ensure that the NSM service template ID and the ID of the device that theservice is executed on are supplied. The NSM service template might also includea list of client parameters that are supplied by the client to ensure that the serviceexecutes properly.

In the following procedure, the NSM service template that is being submitted andexecuted creates zones for a firewall.

Procedure1. As the NSM client user, request the details of the NSM service template to

execute by running the /servicetemplate/{servicetemplate-id}/deviceid/{device-id} URI using the GET method.The latest version of the required NSM service template that matches the NSMservice template ID and device ID entered is returned.

2. The NSM client user should populate any required client parameter values. Thefollowing XML is a sample of a NSM service template that is ready to beexecuted after the NSM client user has populated the values for the clientparameters.<serviceTemplate id="123"><deviceID>4</deviceID><clientParameters><clientParameter><name>ZONE_NAME</name><value>Cisco_Zone_Name</value></clientParameter><clientParameter><name>SOURCEROUTETABLE</name><value>CISCO_SRT</value></clientParameter><clientParameter><name>TARGETROUTETABLE</name><value>CISCO_TRT</value>


</clientParameter><clientParameter><name>VIRTUALROUTERNAME</name><value>CISCO_VRN</value></clientParameter></clientParameters></serviceTemplate>

The following XML is a sample of a NSM service template that is ready to beexecuted using the clientParameterList element to enable multiple executionof the same operation in a single request.<serviceTemplate id="123"><deviceID>4</deviceID><clientParameterLists><clientParameterList name="ZONE_NAME_ID"><parameter name="ZONE_NAME"><values><value order="1">Cisco_Zone_Name1</value><value order="2">Cisco_Zone_Name2</value></values></parameter><parameter name="SOURCEROUTETABLE"><values><value order="1">CISCO_SRT_1</value><value order="2">CISCO_SRT_2</value></values></parameter><parameter name="TARGETROUTETABLE"><values><value order="1">CISCO_TRT_1</value><value order="2">CISCO_TRT_2</value></values></parameter></clientParameterList><clientParameterLists></serviceTemplate>

By supplying a third value to each <parameter> tag the service will be executeda third time for that operation request.

Note: You can combine both <clientParameterList> and <clientParameters>in the same NSM service template for service execution.

3. As the NSM client user, submit the NSM service template XML from step 2 soit can be executed by running the /service URI using the POST method. Thefollowing is a sample of the response that is returned for the NSM servicetemplate submitted.<service id="4" createdByUser="administrator" createDate="2012-07-18 12:52:38.744 GMT+00:00"><status>Submitted</status><devices><device><id>4</id></device></devices><appliedServiceTemplates><serviceTemplate version="1" id="123"/></appliedServiceTemplates>

When the service is submitted, it is processed by the NSM service executionengine. If the execution processing succeeds, work item entries are submitted toNetcool Configuration Manager so that it can complete the operations that theservice requires. The service content is updated with serviceWorkItem entriesthat identify the work item entries in Netcool Configuration Manager for theservice.

4. Check the status of the work item that is submitted to Netcool ConfigurationManager for processing updates by running the /service/{service-id} URI


using the GET method. Enter the service ID that is returned in the sampleresponse in the previous step. This URI returns the information about the workitems.

5. If the work item status is Success, it means that the service executedsuccessfully. If the work item status is Failed, it means that the service failed toexecute.Complete the following steps to examine the result and log content for asuccessful or failed service execution.a. Check the success or failure by running the /service/{service-id}/

workitem URI using the GET method.A list of work items for the service with information about them isreturned.

b. Identify the work item you want to investigate by running the/service/{service-id}/workitem/{workitem-id} URI with the specific workitem ID and the GET method.Information about the work item status, the result content, and the logcontent is returned. Depending on the type of work item, the result contentvaries. For example, when a work item is for an operation whose type isEXTRACTION, the result content includes the result of the extraction.See Netcool Configuration Manager documentation for more informationabout troubleshooting Netcool Configuration Manager work item failures.

6. If further information is needed then review the service logs for NSM serviceson the Netcool Configuration Manager user interface. NSM services are listedas entries in the Queue Manager of the Netcool Configuration Manager GUI.Each service has a service log that can be opened to display some informationabout the execution of the service. The log contains information about theservice execution and any child UOWs that were created as part of theexecution of the service. Information relating to the failure of a service'sexection may also be found in this log.

Related reference:“Service URIs” on page 97“HTTP GET for /servicetemplate/{servicetemplate-id}/deviceid/{device-id}” onpage 92“HTTP POST for /service” on page 111“HTTP GET for /service/{service-id}” on page 101Appendix A, “Sample XML responses for operation types,” on page 131“HTTP GET for /service/{service-id}/workitem/{workitem-id}” on page 108“HTTP GET for /servicetemplate/deviceid/{device-id}” on page 96“HTTP GET for /service/referenceid/{reference-id}” on page 103“HTTP GET for /service/{service-id}/status” on page 105“HTTP POST for /service/{reference-id}” on page 113“HTTP DELETE for /service/{service-id}” on page 116“Interpreting HTTP status codes and NSM error codes” on page 123


Chapter 3. Network Service Manager parameters

NSM service designers use NSM parameters so that NSM client users can passvalues from the NSM REST API client to command sets that are run on NetcoolConfiguration Manager. The parameters are evaluated at service run time. The fivetypes of parameters are: constant, client, inject, sql, and http parameters.

Constant parametersNSM service designers use the <constantParameter> element and the <name>,<description>, and <value> tags to define constant parameters when designingNSM service templates. Constant parameters can be passed as arguments to inject,SQL, or HTTP parameters. Constant parameters can be used as both global andlocal parameters in a NSM service template.

NSM service designers specify values for the constant parameters in the <value>tag. The value is set, and it is not precalculated and it cannot change. The <value>tag is populated when the parameter is defined. When the service is run, the valueis used where the parameter is referenced.

The following sample XML shows the layout of the constant parameter elements.

Note: The constant parameter element and tags are encapsulated within the<constantParameters> and </constantParameters> tags.<constantParameters><constantParameter><name>PORTNUMBER</name><description>PORTNUMBER is always 5000</description><value>5000</value></constantParameter></constantParameters>

Table 4. Constant parameter element and tag details

Tag Type Description

<constantParameters> Containing list Contains a list of one or more<constantParameter> elements.

<constantParameter> Container Contains the constant parameterdetails. Each constant parameter isencapsulated within a<constantParameter></constantParameter> element pair.

<name> String Specifies the name of the constantparameter. In the example, the nameof the constant parameter isPORTNUMBER.

<description> String Specifies the description of theconstant parameter. In the example,the description of the constantparameter is PORTNUMBER is always5000.

<value> String Specifies the value of the constantparameter. In the example, the valueof the constant parameter is 5000.


Related concepts:“Parameters” on page 8Related reference:“Predefined NSM functions” on page 36

Constant parameter rulesRemember the following points when you are working with constant parameters.v The <description> tag is optional, and can be empty or not listed at all.v Constant, client, inject, SQL, and HTTP parameters can be passed as arguments

to other inject, SQL, and HTTP parameters.v Constant parameters that are passed to the service must be valid parameters for

the command sets that are called by the service.

Configuring constant parametersNSM service designers can configure and populate constant parameters withconstant values in the NSM service template XML when they design NSM servicetemplates. The value is set, and it is not precalculated and it cannot changewithout having to update the NSM service template.

Procedure

As the NSM service designer use the following example as a guide to configuringconstant parameters:<constantParameters><constantParameter><name>UNTRUSTZONENAME</name><value>untrust</value></constantParameter><constantParameter><name>HTTPPARAMIPADDRESS</name><value>10.1.1.4</value></constantParameter></constantParameters>

Note: The <constantParameters> and </constantParameters> elements encapsulateone or more <constantParameter> and </constantParameter> elements.1. Enter the required constant parameter name in the <name> tag for each

<constantParameter> XML element. In the example, two constant parameternames are defined: UNTRUSTZONENAME and HTTPPARAMIPADDRESS.

2. Enter the required value in the <value> tag for each <constantParameter> XMLelement. In the example, two constant parameter values are defined: untrustand 10.1.1.4.

When the service is executed, the values untrust and 10.1.1.4 are used.Observe the following points when working with constant parameters:v Constant parameters can be passed as arguments to inject, SQL, or HTTP

parameters.v The <value> tag is populated when the parameter is defined.v When the service is run, the value is used where the constant parameter is

referenced.v Constant parameters can be used as both global and local parameters in a NSM

service template.


Client parametersNSM service designers use the <clientParameter> element and the <name>, and<description> tags to define client parameters when designing NSM servicetemplates. Client parameters can be passed as arguments to inject, SQL, or HTTPparameters. Client parameters can be used as both global and local parameters in aNSM service template.

When the service is submitted, the NSM client user populates the <value> tag withthe appropriate value. This value is then used where the parameter is referenced.

The following sample XML shows the layout of the <clientParameter> elementand associated tags that NSM service designers specify when creating a NSMservice template:<clientParameters><clientParameter><name>SOURCEZONE</name><description>SOURCEZONE name is a string</description></clientParameter></clientParameters>

The following sample XML shows the use of the <value> tag that NSM client usersspecify when submitting a NSM service template for execution:<clientParameters><clientParameter><name>SOURCEZONE</name><description>SOURCEZONE name is a string</description><value>Customer100_Zone</value>

</clientParameter></clientParameters>

Table 5. Client parameter element and tag details

Element/Tag Type Description

<clientParameters> Containing list Contains a list of one or more<clientParameter> elements.

<clientParameter> Container Contains the client parameterdetails. Each client parameter isencapsulated within a<clientParameter></clientParameter> element pair.

<name> String Specifies the name of the clientparameter. In the example, theclient parameter name isSOURCEZONE.

<description> String Specifies the description of theclient parameter. In the example,the client parameter description isSOURCEZONE name is a string.

<value> String The NSM client user populatesthis tag with an appropriate value.This tag is not required forgenerating a NSM servicetemplate, but it is required whenan NSM client user submits aNSM service template. In theexample, the client parametervalue is Customer100_Zone.

Chapter 3. Network Service Manager parameters 27


Client parameter rulesRemember the following points when you are working with client parameters.v The <description> tag is optional, and can be empty or not listed at all.v Constant, client, inject, SQL, and HTTP parameters can be passed as arguments

to other inject, SQL, and HTTP parameters.v Client parameter values are supplied by the NSM client user when submitting

the service for execution.v Client parameters that are passed to the service must be valid parameters for the

command sets that the service calls.

Configuring client parametersNSM service designers can configure client parameters in the NSM servicetemplate XML when they design NSM service templates, and NSM client userspopulate these client parameters with appropriate values.


configuring client parameters:<clientParameters><clientParameter><name>ZONE_NAME</name></clientParameter><clientParameter><name>SOURCEROUTETABLE</name></clientParameter><clientParameter><name>TARGETROUTETABLE</name></clientParameter><clientParameter><name>VIRTUALROUTERNAME</name></clientParameter></clientParameters>

Note: The <clientParameters> and </clientParameters> elements encapsulateone or more <clientParameter> elements.a. Enter the required client parameter name in the <name> tag for each

<clientParameter> XML element. In the example, four client parameternames are defined: ZONE_NAME, SOURCEROUTETABLE, TARGETROUTETABLE, andVIRTUALROUTERNAME.

2. When the service is submitted, as the NSM client user, populate the <value>tags for each <clientParameter> element with the appropriate values. Observethe following points when working with client parameters:v Client parameters can be passed as arguments to inject, SQL, or HTTP

parameters.v The <value> tag is populated by the NSM client user when the service is

submitted.v When the service is run, the value is used where the client parameter is

referenced.


v A client parameter value is used where the parameter is referenced.v Client parameters can be used as both global and local parameters in a NSM

service template.

Example

The following example shows the use of the <value> tag that NSM client usersspecify to populate values for each <clientParameter> when submitting a NSMservice template for execution:<clientParameters><clientParameter><name>ZONE_NAME</name><value>customer100_Zone</value></clientParameter><clientParameter><name>SOURCEROUTETABLE</name><value>customer100.inet.0<value></clientParameter><clientParameter><name>TARGETROUTETABLE</name><value>customertarget.inet.0</value></clientParameter><clientParameter><name>VIRTUALROUTERNAME</name><value>virtualrouter1</value></clientParameter></clientParameters>

Client parameter list parametersA client parameter list enables the execution of a service for multiple items in asingle request. NSM service designers use the <clientParameterList> element andthe name attribute to define the name of a client parameter list when designingNSM service templates. NSM service designers define parameters within that listusing the <parameter name> tag. NSM client users specify values and the order thevalue should be evaluated by using the <values> and </values> tags and the orderattribute when submitting a NSM service template.

The following sample XML shows the layout of the <clientParameterLists>element and associated tags that NSM service designers specify when creating aNSM service template:<clientParameterLists><clientParameterList name="ZONEID" description="Zone ID"><parameter name="ZONE_NAME" description="Zone Name"/>

</clientParameterList><clientParameterList name="ROUTEDETAILS" description="Route Details"><parameter name="SOURCEROUTETABLE" description="Source Route Table"/><parameter name="TARGETROUTETABLE" description="Target Route Table"/><parameter name="VIRTUALROUTERNAME" description="Virtual Route Table"/></clientParameterList></clientParameterLists>

The following sample XML shows the use of the <value> tag that NSM client usersspecify when submitting a NSM service template for execution:...<clientParameterLists><clientParameterList name="ZONEID"><parameter name="ZONE_NAME"/>


</clientParameterList><clientParameterList name="ROUTEDETAILS"><parameter name="SOURCEROUTETABLE"/>

<parameter name="TARGETROUTETABLE"/><parameter name="VIRTUALROUTERNAME"/></clientParameterList></clientParameterLists>

<clientParameterLists><clientParameterList name="ZONE_NAME_ID"><parameter name="ZONE_NAME"><values><value order="1">Cisco_Zone_Name1</value><value order="2">Cisco_Zone_Name2</value>...

Table 6 describes the client parameter list parameters elements and associated tagsfor NSM service template design and NSM service template submission.

Table 6. Client parameter list parameters elements and tag details for NSM service templatedesign and submission


<clientParameterLists> Containing list Contains the client parameter listand its associated parameters.Each client parameter list andassociated parameters isencapsulated within a<clientParameterLists></clientParameterLists> elementpair.

In the example, the<clientParameterLists> elementcontains two client parameterlists: ZONEID andROUTEDETAILS.

<clientParameterList> Container Contains the definition (parameternames and descriptions) of theclient parameter list. Each clientparameter list definition isencapsulated within a<clientParameterList></clientParameterList> elementpair.

clientParameterList.name String The name attribute specifies thename (alias) of the clientparameter list. This name is theidentifier used in the parameterlist within the <operation> tag forselection of parameters used forthe specified operation.

The example uses two instances ofthe <clientParameterList>element and description attributeto specify two client parameterlist descriptions: Zone ID andRoute Details.


Table 6. Client parameter list parameters elements and tag details for NSM service templatedesign and submission (continued)


clientParameterList.description String The description attributespecifies a description for theclient parameter list.

The example uses two instances ofthe <clientParameterList>element and name attribute todefine two client parameter lists:ZONEID and ROUTEDETAILS.

<parameter> Container Contains one or more clientparameters to be used in theservice operation. Each clientparameter is encapsulated withina <parameter> </parameter> tagpair.

parameter.name String The name attribute specifies thename of the parameter to be usedin setting the value for submissionto Netcool ConfigurationManager.

The example uses instances of the<parameter> tag and nameattribute to create:

v For the ZONEID parameter list:one parameter calledZONE_NAME.

v For the ROUTEDETAILSparameter list: three parameterscalled SOURCEROUTETABLE,TARGETROUTETABLE, andVIRTUALROUTERNAME.

parameter.description String The description attributespecifies a description for theparameter.

The example uses instances of the<parameter> tag and descriptionattribute to create the followingparameter descriptions:

v For the ZONEID parameter list:one parameter calledZONE_NAME with adescription of Zone ID.

v For the ROUTEDETAILSparameter list: three parameterscalled SOURCEROUTETABLEwith a description of SourceRoute Table,TARGETROUTETABLE with adescription of Target RouteTable, andVIRTUALROUTERNAMEwith a description of VirtualRoute Table.


Table 6. Client parameter list parameters elements and tag details for NSM service templatedesign and submission (continued)


<values> Containing list Contains the list of <value> tags.This can range from one to many.All of the <value> tags definedwithin a parameter list areencapsulated within a <values></values> tag pair.

Note: The NSM client user makesuse of the <values> and <value>tags and <order> attribute whenpopulating client parameter listparameters with appropriatevalues. NSM client users specifythese tags and attribute whensubmitting a NSM servicetemplate for execution. One clientparameter list can have manyvalues assigned to it. Theoperation that uses this clientparameter list name will getexecuted the same number oftimes as there are values assignedto it.

<value> Container Contains the value to be suppliedto the service operation.

The example uses two instances ofthe <value> tag to define twovalues: Cisco_Zone_Name1 andCisco_Zone_Name2.

value.order String A number representing whatorder a value should be in. Thisattribute is optional. It isrecommended that the orderattribute be used as it will ensurethat values that need to be set inthe same operation is guaranteed.For example if you have twoparameters in two<clientParameterList> elements,to ensure that the first parameteris paired with the first parameterin the second<clientParameterList> then theorder attribute should be used toguarantee this pairing.

The example uses two instances ofthe order attribute to define theorder of the values:Cisco_Zone_Name1 is evaluatedfirst followed byCisco_Zone_Name2.



Client parameter list parameter rulesRemember the following points when you are working with client parameter listparameters.v Parameter names within a <clientParameterList> element must be unique

throughout all <clientParameterList> elements at that level (global or local).v Parameter names within a <clientParameterList> element must also be unique

throughout all client, inject, constant, SQL, or HTTP parameter names.v The list name of a <clientParameterList> element must not be used by another

parameter type (<clientParameterList>, client, inject, constant, SQL, or HTTP)at that level (global or local).

v The list name of a <clientParameterList> cannot match the name of aparameter (<parameter> tag) in another <clientParameterList>.

v Note this exception: A global <clientParameterList> can be overridden by alocal parameter of any type.

Configuring client parameter listsNSM service designers can configure client parameter lists that contain one ormore client parameters in the NSM service template XML when they design NSMservice templates. NSM client users populate the client parameters in theparameter list with appropriate values.


configuring client parameter lists:<clientParameterLists><clientParameterList name="ZONEID"><parameter name="ZONE_NAME"/></clientParameterList><clientParameterList name="ROUTEDETAILS"><parameter name="SOURCEROUTETABLE"/><parameter name="TARGETROUTETABLE"/><parameter name="VIRTUALROUTERNAME"/></clientParameterList></clientParameterLists>

Note: The <clientParameterLists> and </clientParameterLists> elementsencapsulate one or more <clientParameterList> elements.a. Enter the required client parameter list name in the name attribute associated

with each instance of the <clientParameterList> XML element. In theexample two client parameter lists are defined: ZONEID and ROUTEDETAILS.

b. Enter the required parameter name in the name attribute associated witheach instance of the <parameter name> XML element. In the example, theZONEID client parameter list defines one client parameter: ZONE_NAME. TheROUTEDETAILS client parameter list defines three client parameters:SOURCEROUTETABLE, TARGETROUTETABLE, and VIRTUALROUTERNAME.

2. When the service is submitted, as the NSM client user, populate the <value>tags for each <parameter> element with the appropriate values. For example:...<parameter name="ZONE_NAME">


<values><value order="1">Zone1</value><value order="2">Zone2</value></values></parameter>

.

.

.

Note: The <values> and </values> tags encapsulate one or more <value> tags.In the example, the client parameter ZONE_NAME defines two values: Zone1 andZone2. The <order> attribute specifies the order in which to process the values.Observe the following points when working with client parameter lists:v Client parameter lists can be used as both global and local parameters in a

NSM service template.v When listing parameters to be passed to an operation, use the client

parameter list name as specified in the name attribute. This will result inpassing all parameters that belong to the client parameter list name specifiedto the operation. For example, use ZONEID to pass all parameters that belongto the client parameter list named ZONEID (<clientParameterListname="ZONEID">).

v Client parameter lists cannot be passed as arguments to inject, SQL, or HTTPparameters.

The NSM client user populates the <value> attributes with appropriate valueswhen the service is submitted. One client parameter list can have many valuesassigned to it. The operation that uses this client parameter list name will getexecuted as many times as necessary.

Inject parametersNSM service designers use the <injectParameter> element and the <name>,<description>, <methodCall>, <arguments>, and <code> tags to define injectparameters in the XML NSM service template when designing NSM servicetemplates. Inject parameters are populated by evaluating the results of executingfunctions.

There are two types of functions that can be used: predefined NSM functions anduser defined JavaScript functions. Inject parameters are evaluated when the serviceis executed.

The following sample XML shows the structure of an <injectParameter> elementand parameter tags.<injectParameters><injectParameter><name>IP01</name><description>inject parameter 01 description</description><methodCall>concat</methodCall><arguments>clientParameter1,clientParameter2</arguments><code></code></injectParameter></injectParameters>

Table 7. Inject parameter element and tag details


<injectParameters> Containinglist

Contains a list of one or more<injectParameter> elements.


Table 7. Inject parameter element and tag details (continued)


<injectParameter> Container Contains the inject parameter details. Eachinject parameter is encapsulated within a<injectParameter> </injectParameter>element pair.

<name> String Specifies the name of the inject parameter. Inthe example, the name of the inject parameteris IP01.

<description> String Specifies the description of the injectparameter. In the example, the description ofthe inject parameter is inject parameter 01description.

<methodCall> String Specifies the name of the function (NSMpredefined function or JavaScript function)that is called. This tag must be populated forpredefined NSM functions and JavaScriptfunctions.

In the example, the function is a predefinedNSM function called concat.

<arguments> Comma-separatedstring

Specifies a comma delimited list of parametersthat are passed into the function (NSMpredefined function or JavaScript function).The <arguments> tag must be populated forpredefined NSM functions. The <arguments>tag is populated for JavaScript functions onlyif the JavaScript function requires one or moreparameters.

The client parameters were defined previouslyin the NSM service template using the<clientParameter> element.

In the example, the names of the argumentspassed into the NSM function called concatare clientParameter1,clientParameter2. Thetwo values are supplied by the<clientParameter> elements that were definedpreviously in the NSM service template.

<code> JavaScript Specifies user-defined JavaScript code.

Note: The <code> tag is ignored forpredefined NSM functions.



Inject parameter rulesRemember the following points when working with inject parameters.v The <description> tag is optional and can be empty or not listed at all.v Constant, client, inject, SQL, and HTTP parameters can be passed as arguments

to other inject, SQL, and HTTP parameters.v Arguments that are listed in functions are processed in the order that they are

written.v Inject parameters are evaluated once per operation when a service is run.v Extra arguments that are not required by the function are ignored. However if

not enough arguments are passed to a function, any missing arguments areassumed to be null.

v Strings cannot be passed directly as arguments to a function.v Parameters that are passed to the service must be valid parameters for the

command set that is called by the service.v If the <code> tag contains characters that might require escaping in XML, the

information in this tag must be specified in an XML CDATA block.v For user-defined JavaScript, the function must return a string.v For predefined NSM functions, the <methodCall> and <arguments> tags must be

populated. The <code> tag is ignored for predefined NSM functions.v For JavaScript functions, the <code> and <methodCall> tags must be populated.

You must also specify any <arguments> that are used.

Types of inject parametersTwo types of inject functions exist: predefined NSM functions and user definedJavaScript functions that the NSM service designer defines in the NSM servicetemplate.

Predefined NSM functionsThe product includes a suite of predefined NSM functions that can be called insideinject parameters.

For more information about these functions, see Chapter 4, “Understandingpredefined Network Service Manager functions,” on page 47.

Note: For predefined NSM functions, the <methodCall> and <arguments> tags mustbe populated. The <code> tag is ignored for predefined NSM functions.

The <methodCall> tag contains the name of the predefined NSM function that is tobe called. The <arguments> tag contains the arguments that are passed to thepredefined NSM function defined in the <methodCall> tag. In the following sampleXML, the concat predefined NSM function takes two client parameters.<clientParameters><clientParameter><name>clientParameter1</name></clientParameter><clientParameter><name>clientParameter2</name></clientParameter></clientParameters>

<injectParameters><injectParameter><name>IP02</name>


<methodCall>concat</methodCall><arguments>clientParameter1,clientParameter2</arguments></injectParameter></injectParameters>

The <arguments> tag can contain client parameters, constant parameters, SQLparameters, HTTP parameters, or even another inject parameter.Related reference:Chapter 4, “Understanding predefined Network Service Manager functions,” onpage 47“Constant parameters” on page 25“Client parameters” on page 27“SQL parameter element and tags” on page 41“HTTP parameters” on page 43

User-defined JavaScriptNSM client users can define their own JavaScript to use in the JavaScriptparameters. Two types of user-defined JavaScript exist: JavaScript functions andcustom JavaScript.

JavaScript functions

NSM client users can define their own JavaScript in the <code> tag of an injectparameter definition.

Note: For JavaScript functions, the <code> and <methodCall> tags must bepopulated. You must also specify any <arguments> that are used.

The <code> tag contains the full JavaScript function. This function must return astring. The <arguments> tag is populated depending on whether the user-definedJavaScript function takes arguments. The <methodCall> tag specifies the name ofthe function to call in the <code> tag.

The following example shows a JavaScript function that takes arguments in aninject parameter definition called IP03 in a NSM service template XML....<injectParameter><name>IP03</name><description>Returns the sum of three numbers</description><methodCall>sumOfThree</methodCall><arguments>param1,param2,param3</arguments><code>function sumOfThree(x,y,z){ var k = parseInt(x) + parseInt(y) + parseInt(z); return k.toString(); }</code></injectParameter>...

The following example shows a JavaScript function that does not take argumentsin an inject parameter definition called IP04 in a NSM service template XML. Notethat the <arguments> /<arguments> tag pair is not specified....


<injectParameter><name>IP04</name><description>Returns the string 10</description><methodCall>theMethodName</methodCall><code>function theMethodName() { var k = 10; return k.toString(); }</code></injectParameter>...

Custom JavaScript

NSM client users might want to define their own custom JavaScript. The <code>tag contains a JavaScript statement.

Note: For custom JavaScript, the <code> tag must be populated. The <arguments>and <methodCall> tags are ignored.The following example shows a custom JavaScript function in an inject parameterdefinition called IP06 in a NSM service template XML. Note that the <arguments>/<arguments> tag pair and the <methodCall> /<methodCall> are not specified....<injectParameter><name>IP06</name><description>Returns the current year</description><code>var d = new Date(); d.getFullYear().toString();</code></injectParameter>...

Configuring inject parametersNSM service designers can configure inject parameters in the NSM servicetemplate XML and their values are populated by evaluating the results of functionswhen the service is executed.


configuring inject parameters:<injectParameters><injectParameter><name>FULL_ZONE_NAME</name><methodCall>concat</methodCall><arguments>CON01,ZONE_NAME</arguments></injectParameter></injectParameters>

Note: The <injectParameters> and </injectParameters> elements encapsulateone or more <injectParameter> elements.a. Enter the required inject parameter name in the <name> tag associated with

each instance of the <injectParameter> XML element. In the example oneinject parameter is defined: FULL_ZONE_NAME.


b. Enter the required predefined function name in the <name> tag associatedwith each instance of the <methodCall> tag. In the example one predefinedfunction is specified: concat.

c. Enter the required arguments for the predefined function in the <arguments>tag associated with each instance of the <methodCall> tag. In the exampletwo arguments are specified for the concat predefined function: CON01 andZONE_NAME. When the service is executed, the results of functions areevaluated.

2. If a predefined NSM function is not available for the method that you aretrying to complete, then as the NSM service designer, write your ownJavaScript function and insert it in the code tag, for example:<injectParameters><injectParameter><name>FULL_ZONE_NAME</name><methodCall>concat_alternative</methodCall><arguments>CON01,ZONE_NAME</arguments>

<code>function concat_alternative(target, append) {testNotNull(target,"concat","target");testNotNull(target,"concat","append");var x = target + append;return x;}</code></injectParameter></injectParameters>

When the service is executed the results of the JavaScript function areevaluated.Observe the following points when working with inject parameters:v Inject parameters are populated by evaluating the results of functions. There

are two types of functions that can be used: predefined NSM functions anduser defined JavaScript functions.

v Inject parameters (that is the predefined functions and JavaScript functions)are evaluated when the service is executed.

v When the service is run, the value is used where the inject parameter isreferenced.

v Inject parameter values are then used where the parameters are referenced.v Inject parameters can be used as both global and local parameters in a NSM

service template.

JavaScript restrictionsA white list can be defined that includes a list of Java packages and Java classesthat can be used in JavaScript functions defined in inject parameters of a NSMservice template. All other Java packages and Java classes not listed in the whitelistwill not be allowed.

The whitelist is formed by setting the values of two Netcool ConfigurationManager system variables: Scripting - Classes allowed in a script andScripting - Packages allowed in a script. The system variables represent thelist of allowed Java classes and Java packages respectively. At install time thesevariables do not contain any values, so before attempting to execute custom scriptsin a service, these values should be set. If more then one value for a systemvariable is specified, then the values should be separated by commas.


SQL parametersSQL parameters are populated by running an SQL query on a database. SQLparameters are defined in the NSM service template XML. They are run when youPOST a service for execution. SQL parameter values are validated when they aresubmitted and before the service is run. To execute an SQL query, a selectstatement is run on the database that is specified in the <databaseConnection> tag.

Database connection tagsA database connection is required to run the SQL query that is contained in theSQL parameters in a NSM service template. NSM service designers use the<databaseConnection> element and the <driverClassName>, <url>, <username>, and<password> tags to define a database connection in the NSM service template XMLwhen designing NSM service templates. This definition applies to all SQLparameters that are defined in the NSM service template.

The following sample XML shows the layout of the database connection elementand tags for a DB2 database.<databaseConnection><driverClassName>com.ibm.db2.jcc.DB2Driver</driverClassName><url>jdbc:db2://test.example.com:50000/testdb1</url><username>db2user</username><password>password</password></databaseConnection>

The following sample XML shows the layout of the database connection elementand tags for an Oracle database.<databaseConnection><driverClassName>oracle.jdbc.driver.OracleDriver</driverClassName><url>jdbc:oracle:thin:@test.example.com:testdb2</url><username>oracleuser</username><password>password</password></databaseConnection>

Table 8. Database connection details


<databaseConnection> Container Contains the databaseconnection details. Thedatabase connectiondefinition is encapsulatedwithin a<databaseConnection></databaseConnection>element pair.

<driverClassName> String Specifies the name of thedriver that connects to thedatabase. In the DB2example, the name of thedriver iscom.ibm.db2.jcc.DB2Driver.

<url> String Specifies the database details.In the DB2 example, thedatabase details arejdbc:db2://test.example.com:50000/testdb1.


Table 8. Database connection details (continued)


<username> String Specifies the database username. In the DB2 example,the database user name isdb2user.

<password> String Specifies the databasepassword. In the DB2example, the databasepassword is password.

NSM encrypts all databaseuser names and passwords.On exporting NSM servicetemplates, NSM does not setthe user name or passwordfields. This is done to protectthe user name and password.

SQL parameter element and tagsNSM service designers use the <sqlParameter> element and the <name>,<description>, <arguments>, and <sql> tags to define SQL parameters in the NSMservice template XML when designing NSM service templates. SQL parameters canbe passed as arguments to inject, other SQL, or HTTP parameters. HTTPparameters can be used as both global and local parameters in a NSM servicetemplate.

The following sample XML shows the layout of the SQL parameter element andtags.<sqlParameters><sqlParameter><name>DESTINATIONADDRESS</name><description>A description of the DESTINATIONADDRESS parameter</description><arguments>SOURCEADDRESS</arguments><sql>select VLAN_ID from VLAN where uniquekey = ?</sql></sqlParameter></sqlParameters>

Table 9. SQL parameter element and tag details


<sqlParameters> Container list Contains a list of one ormore <sqlParameter>elements.

<sqlParameter> Container Contains the SQL parameterdetails. Each SQL parameteris encapsulated within a<sqlParameter></sqlParameter> elementpair.

<name> String Specifies the name of theSQL parameter. In theexample, the name of theSQL parameter isDESTINATIONADDRESS.


Table 9. SQL parameter element and tag details (continued)


<description> String Specifies the description ofthe SQL parameter. In theexample, the description ofthe SQL parameter is Adescription of theDESTINATIONADDRESSparameter.

<arguments> Comma-separated string Specifies a comma delimitedlist of parameters that areused in the SQL statement.In the example, the SQLparameter argument isSOURCEADDRESS.

<sql> SQL statement Specifies the select SQLstatement with arguments,which are denoted by the"?" symbol in the example.


SQL parameter rulesRemember the following points when you are working with SQL parameters.v The <description> tag is optional and can be empty or not listed at all.v Constant, client, inject, SQL, and HTTP parameters can be passed as arguments

to other inject, SQL, and HTTP parameters.v Arguments that are listed in SQL statements are processed in the order that they

are written.v Strings cannot be passed directly as arguments to an SQL statement.v SQL statements return a string.v SQL parameters accept select statements only. Insert, update, delete, or insertion

DDLs (data definition language) such as create table, drop table, and so on arenot allowed.

Configuring SQL parametersNSM service designers can configure SQL parameters in the NSM service templateXML. SQL parameter values are validated when they are submitted and before theservice is run.

Procedure

As the NSM service designer use the following example as a guide to configuringSQL parameters:<databaseConnection><driverClassName>oracle.jdbc.driver.OracleDriver</driverClassName><url>jdbc:oracle:thin:@test.example.com:testdb2</url><username>oracleuser</username><password>password</password></databaseConnection>


<sqlParameters><sqlParameter><name>SOURCEROUTETABLE</name><sql>select servername from task where uniqueid = 3</sql></sqlParameter></sqlParameters>

Note: The <sqlParameters> and </sqlParameters> elements encapsulate one ormore <sqlParameter> elements.

Note: The <sqlParameters> element will use the database connection as specifiedin the <dataBaseConnection> element and associated tags as shown in the exampleto access the database on which to execute the SQL query.1. Enter the required SQL parameter name in the <name> tag associated with each

instance of the <sqlParameter> XML element. In the example one SQLparameter is defined: SOURCEROUTETABLE.

2. Enter the required SQL select statement in the <sql> tag associated with eachinstance of the <sqlParameter> XML element. In the example one SQL selectstatement is defined: select servername from task where uniqueid = 3. TheSQL is executed on the database connection that is located in the selectedimplementation at service execution time.Observe the following points when working with SQL parameters:v SQL parameter values are validated when they are submitted and before the

service is run.v SQL parameters can be used as both global and local parameters in a NSM

service template.

HTTP parametersNSM service designers use the <httpParameter> element and the <name>,<description>, <url>, and <arguments> tags to define HTTP parameters in theNSM service template XML when designing NSM service templates. HTTPparameters can passed as arguments to inject, SQL, or other HTTP parameters.HTTP parameters can be used as both global and local parameters in a NSMservice template.

HTTP parameters are:v Evaluated when the service is run.v Populated with values by running a GET command, which retrieves these values

from the <url> tag.

The following sample XML shows the layout of the HTTP parameter element andtags.<httpParameters><httpParameter><name>httpparam1</name><description>Get param1 from HTTP server</description><arguments>SOURCEZONENAME</arguments><url><![CDATA[http://www.example.com:3456/getparam&param1={SOURCEZONENAME}]]></url></httpParameter></httpParameters>


Table 10. HTTP parameter details


<httpParameters> Container list Contains a list of one or more<httpParameter> elements. HTTPparameters and associated tagsare encapsulated within a<httpParameters></httpParameters> element pair.

<httpParameter> Container Contains the HTTP parameterdetails. Each HTTP parameter isencapsulated within a<httpParameter></httpParameter> element pair.

<name> String Specifies the name of the HTTPparameter. In the example, theHTTP parameter name ishttpparam1.

<description> String Specifies the description of theHTTP parameter. In the example,the HTTP parameter descriptionis Get param1 from HTTP server.

<url> String Specifies the HTTP URL thatreturns the parameter value. Inthe example, the HTTP parameterurl is ![CDATA[http://www.example.com:3456/getparam&param1={SOURCEZONENAME}]]Note that characters that mightrequire escaping in XML arespecified in an XML CDATAblock.

<arguments> Comma-separated string Specifies a comma delimited listof parameter names. The valuesof these parameters aresubstituted in the template URLto create a complete runtime URLfor evaluation. In the example,the HTTP parameter argument isSOURCEZONENAME.



HTTP parameter rulesRemember the following points when you are working with HTTP parameters.v The <description> and <arguments> tags are optional, and can be empty or not

listed at all.v Constant, client, inject, SQL, and HTTP parameters can be passed as arguments

to other inject, SQL, and HTTP parameters.v Strings cannot be passed directly as arguments to a URL.v HTTP parameters that are passed to the service must be valid parameters for the

command sets that are called by the service.v If the <url> tag contains characters that might require escaping in XML, the

information in this tag must be specified in an XML CDATA block.v HTTP is currently the only supported protocol. So, for example, the HTTPS and

similar protocols are not supported.

Configuring HTTP parametersNSM service designers can configure HTTP parameters in the NSM servicetemplate XML. They are populated by running a GET command and are evaluatedwhen the service is run.

Procedure

As the NSM service designer use the following example as a guide to configuringHTTP parameters:<httpParameters><httpParameter><name>httpparam1</name><arguments>SOURCEZONENAME</arguments><url><![CDATA[http://www.example.com:3456/getparam&param1={SOURCEZONENAME}]]></url></httpParameter></httpParameters>

Note: The <httpParameters> and </httpParameters> elements encapsulate one ormore <httpParameter> elements.1. Enter the required HTTP parameter name in the <name> tag associated with

each instance of the <httpParameter> element. In the example one HTTPparameter is defined: httpparam1.

2. Enter the required HTTP argument in the <arguments> tag associated with eachinstance of the <httpParameter> element. In the example one HTTP argument isdefined: SOURCEZONENAME.

3. Enter the required HTTP url information in the <url> tag associated with eachinstance of the <httpParameter> element. In the example one HTTP url isdefined: ![CDATA[http://www.example.com:3456/getparam&param1={SOURCEZONENAME}]]>. When the service is run, the parameter valuesare retrieved from the <url> tag.Observe the following points when working with HTTP parameters:v HTTP parameters are populated by running a GET command and are

evaluated when the service is run.v HTTP parameters can be used as both global and local parameters in a NSM

service template.


Chapter 4. Understanding predefined Network ServiceManager functions

NSM service designers can use the following predefined NSM functions insideinject parameters. All function names are case-sensitive and all arithmetic functionsreturn values up to three decimal places.Related reference:“Predefined NSM functions” on page 36

concatThe concat NSM predefined function concatenates two strings together.

Syntaxconcat(string1,string2)

Parameters

string1Specifies a string.

string2Specifies a string.

Description

The concat NSM predefined function concatenates the string value specified instring1 with the string value specified in string2.

Returns

This functions returns the string that is concatenated.

Examplesconcat("source ip"," 10.1.1.0") returns "source ip 10.1.1.0"concat("te","st") returns "test"

divideThe divide NSM predefined function divides one value by another value.

Syntaxdivide(param1,param2)

Parameters

param1Specifies a positive or negative number. The number can also include adecimal point.



Description

The divide NSM predefined function divides the value specified in param1 by thevalue specified in param2.

Returns

This functions returns a string that is derived from the result of dividing param1 byparam2.

Examplesdivide("10","5") returns "2"divide("5","10") returns "0.5"divide("38.33856","7.488") returns "5.12"divide("five","56") /* ERROR is thrown here*/

ifEqualsThe ifEquals NSM predefined function returns the string specified in onTrue ifparam1 equals param2. Otherwise, the function returns the string specified inonFalse.

SyntaxifEquals(param1,param2,onTrue,onFalse)

Parameters

param1Specifies a string or a number.

param2Specifies a string or a number.

onTrueSpecifies a string that is returned if param1 equals param2.

onFalseSpecifies a string that is returned if param1 is not equal to param2.

Description

The ifEquals NSM predefined function compares the strings specified in param1and param2. The function returns the string specified in onTrue if param1 equalsparam2. Otherwise, the function returns the string specified in onFalse.

Returns

This function returns the string specified in onTrue if param1 equals param2.Otherwise, the function returns the string specified in onFalse.

ExamplesifEquals("345.000","345","true","false") returns "true"ifEquals("41.6",".09","34","50") returns "50"ifEquals("four","five","Y","N") returns "N"ifEquals("four","four","t","f") returns "t"

The following descriptions explain how the ifEquals function operates on theparameters:


v In the first example, the ifEquals NSM predefined function compares the stringspecified in param1 ("345.000") with the string specified in param2 ("345").Because the strings are equal, the ifEquals function returns the string "true"that is specified in onTrue.

v In the second example, the ifEquals NSM predefined function compares thestring specified in param1 ("41.6") with the string specified in param2 (".09").Because the strings are not equal, the ifEquals function returns the string "50"that is specified in onFalse.

v In the third example, the ifEquals NSM predefined function compares the stringspecified in param1 ("four") with the string specified in param2 ("five"). Becausethe strings are not equal, the ifEquals function returns the string "N" that isspecified in onFalse.

v In the fourth example, the ifEquals NSM predefined function compares thestring specified in param1 ("four") with the string specified in param2 ("four").Because the strings are equal, the ifEquals function returns the string "t" that isspecified in onTrue.

As can be seen in the examples, the ifEquals function provides flexibility inspecifying the strings to return in the onTrue and onFalse parameters.

ifGreaterThanThe ifGreaterThan NSM predefined function returns the string specified in onTrueif param1 is greater than param2. Otherwise, the function returns the string specifiedin onFalse.

SyntaxifGreaterThan(param1,param2,onTrue,onFalse)

Parameters

param1Specifies a number.


onTrueSpecifies a string that is returned if param1 is greater than param2.

onFalseSpecifies a string that is returned if param1 is not greater than param2.

Description

The ifGreaterThan NSM predefined function compares the strings specified inparam1 and param2. The function returns the string specified in onTrue if param1 isgreater than param2. Otherwise, the function returns the string specified in onFalse.

Returns

This function returns the string specified in onTrue if param1 is greater than param2.Otherwise, the function returns the string specified in onFalse.

Chapter 4. Understanding predefined Network Service Manager functions 49

ExamplesifGreaterThan("45.5","45.0","t","f") returns "t"ifGreaterThan("3455.000","3455","true","false") returns "false"ifGreaterThan("6","7","yes","no") returns "no"ifGreaterThan("four","five","t","f") /* ERROR is thrown here*/

The following descriptions explain how the ifGreaterThan function operates on theparameters:v In the first example, the ifGreaterThan NSM predefined function compares the

string specified in param1 ("45.5") with the string specified in param2 ("45.0").Because the string specified in param1 is greater than the string specified inparam2, the ifGreaterThan function returns the string "t" that is specified inonTrue.

v In the second example, the ifGreaterThan NSM predefined function comparesthe string specified in param1 ("3455.000") with the string specified in param2("3455"). Because string specified in param1 is not greater than the stringspecified in param2, the ifGreaterThan function returns the string "false" that isspecified in onFalse.

v In the third example, the ifGreaterThan NSM predefined function compares thestring specified in param1 ("6") with the string specified in param2 ("7"). Becausestring specified in param1 is not greater than the string specified in param2, theifGreaterThan function returns "no" that is specified in onFalse.

v In the fourth example, the ifGreaterThan NSM predefined function comparesthe string specified in param1 ("four") with the string specified in param2("five"). The param1 and param2 parameters require numbers. Because the stringvalue does not resolve to a number, ifGreaterThan returns an error.

As can be seen in the examples, the ifGreaterThan function provides flexibility inspecifying the strings to return in the onTrue and onFalse parameters.

ifGreaterThanOrEqualToThe ifGreaterThanOrEqualTo NSM predefined function returns the string specifiedin onTrue if param1 is greater than or equal to param2. Otherwise, the functionreturns the string specified in onFalse.

SyntaxifGreaterThanOrEqualTo(param1,param2,onTrue,onFalse)

Parameters



onTrueSpecifies a string that is returned if param1 is greater than or equal to param2.

onFalseSpecifies a string that is returned if param1 is not greater than or not equal toparam2.


Description

The ifGreaterThanOrEqualTo NSM predefined function compares the stringsspecified in param1 and param2. The function returns the string specified in onTrueif param1 is greater than or equal to param2. Otherwise, the function returns thestring specified in onFalse.

Returns

This function returns the string specified in onTrue if param1 is greater than orequal to param2. Otherwise, the function returns the string specified in onFalse.

ExamplesifGreaterThanOrEqualTo("45","45","true","false") returns "true"ifGreaterThanOrEqualTo("45.5","45.0","y","n") returns "y"ifGreaterThanOrEqualTo("6","7","yes","no") returns "no"ifGreaterThanOrEqualTo("four","five","t","f") /* ERROR is thrown here*/

The following descriptions explain how the ifGreaterThan function operates on theparameters:v In the first example, the ifGreaterThanOrEqualTo NSM predefined function

compares the string specified in param1 ("45") with the string specified in param2("45"). Because the string specified in param1 is equal to the string specified inparam2, the ifGreaterThanOrEqualTo function returns the string "true" that isspecified in onTrue.

v In the second example, the ifGreaterThanOrEqualTo NSM predefined functioncompares the string specified in param1 ("45.5") with the string specified inparam2 ("45.0"). Because string specified in param1 is greater than the stringspecified in param2, the ifGreaterThanOrEqualTo function returns the string "y"that is specified in onTrue.

v In the third example, the ifGreaterThanOrEqualTo NSM predefined functioncompares the string specified in param1 ("6") with the string specified in param2("7"). Because string specified in param1 is not greater than the string specifiedin param2, the ifGreaterThanOrEqualTo function returns "no" that is specified inonFalse.

v In the fourth example, the ifGreaterThanOrEqualTo NSM predefined functioncompares the string specified in param1 ("four") with the string specified inparam2 ("five"). The param1 and param2 parameters require numbers. Becausethe string value does not resolve to a number, ifGreaterThanOrEqualTo returnsan error.

As can be seen in the examples, the ifGreaterThanOrEqualTo function providesflexibility in specifying the strings to return in the onTrue and onFalse parameters.

multiplyThe multiply NSM predefined function multiplies one value by another value.

Syntaxmultiply(param1,param2)

Parameters




Description

The multiply NSM predefined function multiplies the value specified in param1 bythe value specified in param2.

Returns

This function returns a string that is derived from multiplying param1 by param2.

Examplesmultiply("5","6") returns "30"multiply("0.5","10") returns "5"multiply(".1456",".33") returns "0.048"multiply("five","56") /* ERROR is thrown here*/

replaceThe replace NSM predefined function replaces the first occurrence of the searchstring in the target string with the replacement string. The process of replacementis case sensitive.

Syntaxreplace(target,search,replacement)

Parameters

targetSpecifies the target string.

searchSpecifies the string for which to search.

replacementSpecifies the replacement string.

Description

The replace NSM predefined function replaces the first occurrence of the searchstring specified in search in the target string specified in target with thereplacement string specified in replacement.

Returns

This function returns a string that is derived from replacing the first occurrence ofthe search string specified in search in the target string specified in target withthe replacement string specified in replacement.

Examplesreplace("10.2.3.10", "10", "4") returns "4.2.3.10"replace("100.1.1.23", "1", "5") returns "500.1.1.23"replace("ge10 GE10 ge10","GE10","")returns "ge10 ge10"replace("1234", "", "1") ERROR is thrown herereplace("", "3", "8") /* ERROR is thrown here*/


replaceAllThe replaceAll NSM predefined function replaces all occurrences of the searchstring in the target string with the replacement string. The process of replacementis case sensitive.

SyntaxreplaceAll(target,search,replacement)

Parameters

targetSpecifies the target string.

searchSpecifies the string for which to search.

replacementSpecifies the replacement string.

Description

The replaceAll NSM predefined function replaces all occurrences of the searchstring specified in search in the target string specified in target with thereplacement string specified in replacement.

Returns

This function returns a string that is derived from replacing all occurrences of thesearch string specified in search in the target string specified in target with thereplacement string specified in replacement.

ExamplesreplaceAll("10.4.4.4","4","10") returns "10.10.10.10"replaceAll("1376512","1","3") returns "3376532"replaceAll("1234", "", "1") /* ERROR is thrown here*/replaceAll("", "3", "8") /* ERROR is thrown here*/

substringThe substring NSM predefined function extracts the characters from a string,between two specified indexes, and returns the substring.

Syntaxsubstring(string,beginIndex,endIndex)

Parameters

stringSpecifies the string for which to extract characters.

beginIndexSpecifies the index where to start the extraction. It includes the beginIndex.The first character is at index 0. It must be a whole number and must be lessthan the length of the string specified in string.


endIndexSpecifies the index where to stop the extraction. It excludes the endIndex itself.It must be a whole number, greater than the beginIndex and less than thelength of the string parameter.

Description

The substring NSM predefined function extracts the characters from the stringspecified in string, between the indexes specified in beginIndex and endIndex, andreturns the substring.

Returns

This function returns a substring of the string specified in string between theindexes specified in beginIndex and endIndex.

Examplessubstring("demand", "3", "6") returns "and"substring("demand", "1", "5") returns "eman"substring("demand", "3", "7") /* ERROR is thrown here*/substring("demand", "three", "six") /* ERROR is thrown here*/substring("demand", "3", "1") /* ERROR is thrown here*/

substringFromBeginIndexThe substringFromBeginIndex NSM predefined function returns a string that is asubstring of the string.

SyntaxsubstringFromBeginIndex(string,beginIndex)

Parameters

stringSpecifies the string for which to extract characters.

beginIndexSpecifies the index where to start the extraction. It includes the beginIndex.The first character is at index 0. It must be a whole number and must be lessthan the length of the string specified in string.

Description

The substringFromBeginIndex NSM predefined function extracts the charactersfrom the string specified in string, starting at the index specified in beginIndex,and returns a string that is a substring of string.

Returns

This function returns a substring of the string specified in string.

ExamplessubstringFromBeginIndex("10.3.2.1","3") returns "3.2.1""substringFromBeginIndex("10.3.2.1","10") /* ERROR is thrown here*/substringFromBeginIndex("5.3.2.1.18","6") returns "1.18substringFromBeginIndex("10.3.2.1","three") /* ERROR is thrown here*/


subtractThe subtract NSM predefined function subtracts one value from the other.

Syntaxsubtract(param1,param2)

Parameters



Description

The subtract NSM predefined function subtracts the value specified in param2from the value specified in param1.

Returns

This function returns a string that is derived from subtracting param2 from param1.

Examplessubtract("45","12") returns "33"subtract("1.1","1.1") returns "0"subtract("1.23254","10.1343") returns "-8.901"subtract("five","56") /* ERROR is thrown here*/

sumThe sum NSM predefined function adds two numbers together.

Syntaxsum(param1,param2)

Parameters



Description

The sum NSM predefined function adds the value specified in param1 to the valuespecified in param2.

Returns

This function returns a string that is derived from the sum of param1 and param2.


Examplessum("3","4") returns "7"sum("1","-2") returns "-1"sum("12.16","57.87623") returns "70.036"sum("five","4") /* ERROR is thrown here*/


Chapter 5. Network service management command lineinterface tool

NSM service designers use the NSM command line interface (CLI) tool to create,update, and maintain NSM service templates and also to remove failed NSMservice entries which are no longer required. The tool includes a command-lineinterface to run commands with specified input options.

Running the CLI toolYou can execute the NSM CLI by running the /opt/IBM/tivoli/netcool/ncm/bin/nsm/nsmadmin.sh shell script with specific input options on the NetcoolConfiguration Manager presentation server where NSM is installed.

Each command-line tool requires a username and password of a user that has theactivity Service Template Management assigned to them by the NetcoolConfiguration Manager administrator.

Procedure

For example, to create a NSM service template, run the /opt/IBM/tivoli/netcool/ncm/bin/nsm/nsmadmin.sh shell script by executing the following command withthe correct input options:$ /opt/IBM/tivoli/netcool/ncm/bin/nsm/nsmadmin.shcommand=create filename=/opt/IBM/tivoli/netcool/ncm/servicetemplate_CreateZones.xml

The NSM CLI tool user will be prompted to enter a username and password of avalid NSM service designer.The following output is an example of the output that is sent to the console for thecreate command:Jul 3, 2012 1:17:06 PM com.ibm.tivoli.nsm.cli.NsmAdminCommandLineTool processCommandINFO: Argument 1 is [command=create]Jul 3, 2012 1:17:06 PM com.ibm.tivoli.nsm.cli.NsmAdminCommandLineTool processCommandINFO: Argument 2 is [filename=/opt/IBM/tivoli/netcool/ncm/servicetemplates/servicetemplate_CreateZones.xml]Jul 3, 2012 1:17:07 PM com.ibm.tivoli.nsm.cli.NsmAdminCommandLineTool mainINFO: ServiceTemplate has returned with a HTTP Status Code of [201] ServiceTemplate Name is[CreateZones_J110] with a ServiceTemplate ID of [103]

Note: The arguments entered in the command-line are printed in the consoleoutput. In the case of the username and password arguments, only the keys ofthose parameters are printed to the screen. The values are not shown.The nsmadmin.sh shell script checks the input options that are supplied.If errors occur the script reports these errors and exits without submitting a requestto NSM. If the input options are accepted, the request is submitted to NSM to beprocessed. If issues occur during processing, NSM returns the required HTTPstatus code and message. The HTTP status code and message include informationabout whether the request is received by the NSM server. The Intelliden.log filecontains the NSM error code. The NSM error code contains information aboutissues that occurred while processing the request.In some cases, the CLI script reports an HTTP status code that tells the NSM clientuser that the specific request could not be submitted because of connectivity or


server issues.See Chapter 8, “Troubleshooting,” on page 123 for more information about NSMerror codes and their meaning.Related information:Chapter 8, “Troubleshooting,” on page 123

CLI commands and optionsBy using the NSM CLI, NSM service designers can run the following commandswith specific input options on NSM service templates and NSM services.

Note: NSM service designers can run ./nsmadmin.sh -h from the CLI to displayhelp text and examples of the following commands and input options.

The following options can be specified for any of the commands described inTable 11 and Table 12 on page 61. If you supply them in the command, thecommand-line tool uses these values in executing the command. Thecommand-line tool also prompts for the password, regardless of whether apassword is supplied inline for the command being executed. If neither theusername or password is supplied the command-line tool prompts for both theusername and password.v username is a mandatory option that specifies the NSM service designer user

name. It is not a required argument in the command because the command-linetool prompts the user for the username if omitted in the command.

v password is a mandatory option that specifies the NSM service designerpassword. It is not a required argument in the command because thecommand-line tool prompts the user for the password if omitted in thecommand.

v port is the Netcool Configuration Manager presentation server HTTP portnumber. The default value is 7001. It is optional.

v -v displays detailed output to both the console and the log file. It can bespecified anywhere in a command. It is optional.

Table 11. NSM CLI service template commands and input options

Commands Description Options

clone Copies details of the latestenabled version of anexisting NSM servicetemplate to an XML file.

v filename is a mandatory option thatspecifies the fully qualified file namewhere the NSM service templateinformation that is being requested iswritten to.

v id is a mandatory option that specifiesthe NSM service template identifier.

create Creates a NSM servicetemplate by usinginformation from an XMLfile.

v filename is a mandatory option thatspecifies the fully qualified file name ofthe XML file that contains theinformation for the NSM service templatethat is being created.

delete Deletes the latest enabledversion of a NSM servicetemplate.


disable Disables the latest versionof a NSM servicetemplate.



Table 11. NSM CLI service template commands and input options (continued)


disableall Disables all versions of aNSM service template.


exportall Exports all latest enabledversion NSM servicetemplate details to anXML file.

v filename is a mandatory option thatspecifies the location of the file that willbe written to as a result of the commandbeing executed.

exportdate Exports the latest enabledversion NSM servicetemplates to an XML file,where the create date issince the start dateparameter.

v start is a mandatory option thatspecifies the date in the format ofyyyy-mm-dd. The value is used tocompare against the create date of a NSMservice template. In the case of thiscommand, matching NSM servicetemplates are returned whereby the startdate is since the create date of a NSMservice template.


exportdaterange Exports the latest enabledversion NSM servicetemplates to an XML file,where the create date isbetween the start and enddate parameters.

v start is a mandatory option thatspecifies the date in the format ofyyyy-mm-dd. The value is used tocompare against the create date of a NSMservice template. In the case of thiscommand, matching NSM servicetemplates are returned whereby the startdate is since the create date of a NSMservice template.

v end is a mandatory option that specifiesthe date in the format of yyyy-mm-dd.The value is used to compare against thecreate date of a NSM service template. Inthe case of this command, matching NSMservice templates are returned wherebythe end date is until the create date of aNSM service template.


exportid Exports the latest enabledversion NSM servicetemplate matching the idparameter to an XML file.



Chapter 5. Network service management command line interface tool 59



exportname Exports the latest enabledversion NSM servicetemplates matching thename parameter to anXML file.

v name is a mandatory option that specifiesthe name of the NSM service template. Itcan be an exact match or a partial match.


exportvendor Exports the latest enabledversion NSM servicetemplates matching thevendor parameter to anXML file.

v vendor is a mandatory option thatspecifies the NSM service templatevendor. It is an exact match but is notcase sensitive.


getversion Gets information about aversion of a NSM servicetemplate and outputs thisinformation to an XMLfile.

v filename is a mandatory option thatspecifies the fully qualified file name ofthe file where the results are written.


v version is a mandatory option thatspecifies the NSM service templateversion.

import Imports a single NSMservice template by usinginformation from an XMLfile.

v filename is a mandatory option thatspecifies the file from which the importinformation is read.

Note: Username and password valueswithin <databaseConnection> elements of aNSM service template will not be exportedas a result of executing any of the exportcommands. If any of these exportedtemplates are to be imported into anotherenvironment, the user must provide theusername and password values beforeexecuting the import functionality.

importlist Imports a number ofNSM service templates byusing information froman XML file.

v filename is a mandatory option thatspecifies the file from which the importinformation is read.

Note: Username and password valueswithin <databaseConnection> elements of aNSM service template will not be exportedas a result of executing any of the exportcommands. If any of these exportedtemplates are to be imported into anotherenvironment, the user must provide theusername and password values beforeexecuting the import functionality.

list Lists summaryinformation of all enabledversions.





purge Deletes all versions of aNSM service template.


read Gets information aboutthe latest enabled versionof a NSM servicetemplate and outputs thisinformation to an XMLfile.



readall Gets information about allversions of a NSM servicetemplate and outputs thisinformation to an XMLfile.



update Creates a new version ofa NSM service templateby updating theinformation in an existingNSM service template.The update information isretrieved from an XMLfile.


v filename is a mandatory option thatspecifies the fully qualified file name ofthe file where the update information isretrieved from.

Table 12. NSM CLI service management commands and input options


removeserviceinstance Removes the database recordof a failed service. No otherprocessing is performed onthe service.

service-id is a mandatoryoption which specifies theNSM service identifier

clone commandThe NSM service designer can run the clone command from the NSM CLI to copythe latest enabled version of an existing NSM service template to an XML file.Designers can use this XML file to design a new NSM service template.

Usage./nsmadmin.sh command=clone filename=<filename> id=<id> username=<username>password=<password> port=<port> -v

Options

filename is a mandatory option that specifies the fully qualified file name wherethe NSM service template information that is being requested is written to.

id is a mandatory option that specifies the NSM service template identifier.

username is a mandatory option that specifies the NSM service designer user name.

password is a mandatory option that specifies the NSM service designer password.


port is the Netcool Configuration Manager presentation server port number. Thedefault value is 7001. It is optional.

-v displays detailed output to both the console and the log file. It can be specifiedanywhere in a command. It is optional.

Examples./nsmadmin.sh command=clone filename=/opt/clone.txt id=45./nsmadmin.sh command=clone filename=/opt/clone.txt id=45 username=adminpassword=password01./nsmadmin.sh -v command=clone filename=/opt/clone.txt id=45 username=adminpassword=password01 port=7001./nsmadmin.sh command=clone filename=/opt/clone.txt id=45 username=adminpassword=password01 port=7001 -v

create commandThe NSM service designer can run the create command from the NSM CLI tocreate a NSM service template.

Usage./nsmadmin.sh command=create filename=<filename> username=<username>password=<password> port=<port> -v

Options

filename specifies the location of the file that contains the NSM service templateXML being posted. It is mandatory.





Examples./nsmadmin.sh command=create filename=/opt/IBM/serviceTemplate1.xml./nsmadmin.sh command=create filename=/opt/IBM/serviceTemplate1.xml username=adminpassword=password01./nsmadmin.sh -v command=create filename=/opt/IBM/serviceTemplate1.xml username=adminpassword=password01 port=7001./nsmadmin.sh command=create filename=/opt/IBM/serviceTemplate1.xml username=adminpassword=password01 port=7001 -v

Related tasks:“Posting a NSM service template” on page 21


delete commandThe NSM service designer can run the delete command from the NSM CLI todelete the latest enabled version of a NSM service template.

Usage./nsmadmin.sh command=delete id=<id> username=<username> password=<password> port=<port> -v

Options






Examples./nsmadmin.sh command=delete id=19./nsmadmin.sh command=delete id=19 username=admin password=password01./nsmadmin.sh -v command=delete id=19 username=admin password=password01 port=7001./nsmadmin.sh command=delete id=19 username=admin password=password01 port=7001 -v

disable commandThe NSM service designer can run the disable command from the NSM CLI todisable the latest enabled version of an existing NSM service template.

Usage./nsmadmin.sh command=disable id=<id> username=<username> password=<password>port=<port> -v

Options






Examples./nsmadmin.sh command=disable id=45./nsmadmin.sh command=disable id=45 username=admin password=password01./nsmadmin.sh -v command=disable id=45 username=admin password=password01 port=7001./nsmadmin.sh command=disable id=45 username=admin password=password01 port=7001 -v


disableall commandThe NSM service designer can run the disableall command from the NSM CLI todisable all versions of an of an existing NSM service template.

Usage./nsmadmin.sh command=disableall id=<id> username=<username> password=<password>port=<port> -v

Options






Notes

If the NSM service designer disables the last enabled version of a NSM servicetemplate, then that NSM service template can no longer be used. The disabledNSM service template versions can still be retrieved by using the readallcommand. However, the NSM NSM service template id cannot be re-enabled onceall versions are disabled.

Examples./nsmadmin.sh command=disableall id=45./nsmadmin.sh command=disableall id=45 username=admin password=password01./nsmadmin.sh -v command=disableall id=45 username=admin password=password01 port=7001./nsmadmin.sh command=disableall id=45 username=admin password=password01 port=7001 -v

exportall commandThe NSM service designer can run the exportall command from the NSM CLI toexport all enabled latest version NSM service template details to an XML file.

Usage./nsmadmin.sh command=exportall filename=<filename> username=<username>password=<password> port=<port> -v

Options

filename is a mandatory option that specifies the location of the file that will bewritten to as a result of the command being executed.






Notes

If the NSM service template that is being exported contains the<databaseConnection> element for an SQL parameter, then the username andpassword of the database connection will not be exported to the filename.

If the NSM service designer issues the disableall command, then that NSMservice template can no longer be used. The disabled NSM service templateversions can still be retrieved by using the readall command. However, the NSMNSM service template id cannot be re-enabled once all versions are disabled.

Examples./nsmadmin.sh command=exportall filename=/opt/IBM/serviceTemplates.xml./nsmadmin.sh command=exportall filename=/opt/IBM/serviceTemplates.xmlusername=admin password=password01./nsmadmin.sh command=exportall filename=/opt/IBM/serviceTemplates.xmlusername=admin password=password01 port=7001./nsmadmin.sh command=exportall filename=/opt/IBM/serviceTemplates.xmlusername=admin password=password01 port=7001 -v

exportdate commandThe NSM service designer can run the exportdate command from the NSM CLI toexport the latest enabled version NSM service templates to an XML file, where thecreate date is since the start date parameter.

Usage./nsmadmin.sh command=exportdate start=<date> filename=<filename> username=<username>password=<password> port=<port> -v

Options

start is a mandatory option that specifies the date in the format of yyyy-mm-dd.The value is used to compare against the create date of a NSM service template. Inthe case of this command, matching NSM service templates are returned wherebythe start date is since the create date of a NSM service template.







Notes


Examples./nsmadmin.sh command=exportdate start=2012-01-01 filename=/opt/IBM/serviceTemplate.xml./nsmadmin.sh command=exportdate start=2012-01-01 filename=/opt/IBM/serviceTemplate.xmlusername=admin password=password01./nsmadmin.sh command=exportdate start=2012-01-01 filename=/opt/IBM/serviceTemplate.xmlusername=admin password=password01 port=7001./nsmadmin.sh command=exportdate start=2012-01-01 filename=/opt/IBM/serviceTemplate.xmlusername=admin password=password01 port=7001 -v

exportdaterange commandThe NSM service designer can run the exportdaterange command from the NSMCLI to export the latest enabled version NSM service templates to an XML file,where the create date is between the start and end date parameters.

Usage./nsmadmin.sh command=exportdaterange start=<date> end=<date> filename=<filename>username=<username> password=<password> port=<port> -v

Options

start is a mandatory option that specifies the date in the format of yyyy-mm-dd.The value is used to compare against the create date of a NSM service template. Inthe case of this command, matching NSM service templates are returned wherebythe start date is since the create date of a NSM service template.

end is a mandatory option that specifies the date in the format of yyyy-mm-dd.The value is used to compare against the create date of a NSM service template. Inthe case of this command, matching NSM service templates are returned wherebythe end date is until the create date of a NSM service template.






Notes



Examples./nsmadmin.sh command=exportdaterange start=2012-01-01 end=2012-01-10filename=/opt/IBM/serviceTemplate.xml/nsmadmin.sh command=exportdaterange start=2012-01-01 end=2012-01-10filename=/opt/IBM/serviceTemplate.xml username=admin password=password01./nsmadmin.sh command=exportdaterange start=2012-01-01 end=2012-01-10filename=/opt/IBM/serviceTemplate.xml username=admin password=password01 port=7001./nsmadmin.sh command=exportdaterange start=2012-01-01 end=2012-01-10filename=/opt/IBM/serviceTemplate.xml username=admin password=password01 port=7001 -v

exportid commandThe NSM service designer can run the exportid command from the NSM CLI toexport the latest enabled version NSM service template matching the id parameterto an XML file.

Usage./nsmadmin.sh command=exportid id=<id> filename=<filename> username=<username>password=<password> port=<port> -v

Options







Notes


Examples./nsmadmin.sh command=exportid id=1 filename=/opt/IBM/serviceTemplate.xml./nsmadmin.sh command=exportid id=1 filename=/opt/IBM/serviceTemplate.xmlusername=admin password=password01./nsmadmin.sh command=exportid id=1 filename=/opt/IBM/serviceTemplate.xmlusername=admin password=password01 port=7001./nsmadmin.sh command=exportid id=1 filename=/opt/IBM/serviceTemplate.xmlusername=admin password=password01 port=7001 -v


exportname commandThe NSM service designer can run the exportname command from the NSM CLI toexport the latest enabled version NSM service templates matching the nameparameter to an XML file.

Usage./nsmadmin.sh command=exportname name=<name> filename=<filename> username=<username>password=<password> port=<port> -v

Options

name is a mandatory option that specifies the name of the NSM service template. Itcan be an exact match or a partial match.






Notes


Examples./nsmadmin.sh command=exportname name=FullServiceTemplateName filename=/opt/IBM/serviceTemplate.xml./nsmadmin.sh command=exportname name=FullServiceTemplateName filename=/opt/IBM/serviceTemplate.xmlusername=admin password=password01./nsmadmin.sh command=exportname name=FullServiceTemplate* filename=/opt/IBM/serviceTemplate.xmlusername=admin password=password01 port=7001./nsmadmin.sh command=exportname name=FullServiceTemplateName filename=/opt/IBM/serviceTemplate.xmlusername=admin password=password01 port=7001 -v

exportvendor commandThe NSM service designer can run the exportvendor command from the NSM CLIto export the latest enabled version NSM service templates matching the vendorparameter to an XML file.

Usage./nsmadmin.sh command=exportvendor vendor=<name> filename=<filename> username=<username>password=<password> port=<port> -v

Options

vendor is a mandatory option that specifies the NSM service template vendor. It isan exact match but is not case sensitive.







Notes


Examples./nsmadmin.sh command=exportvendor vendor=Cisco filename=/opt/IBM/serviceTemplate.xml./nsmadmin.sh command=exportvendor vendor=Cisco filename=/opt/IBM/serviceTemplate.xml username=adminpassword=password01./nsmadmin.sh command=exportvendor vendor=Cisco filename=/opt/IBM/serviceTemplate.xml username=adminpassword=password01 port=7001./nsmadmin.sh command=exportvendor vendor=Cisco filename=/opt/IBM/serviceTemplate.xml username=adminpassword=password01 port=7001 -v

getversion commandThe NSM service designer can run the getversion command from the NSM CLI toretrieve information about a version of a NSM service template and output thisinformation to an XML file.

Usage./nsmadmin.sh command=getversion filename=<filename> id=<id> version=<version>username=<username> password=<password> port=<port> -v

Options

filename is a mandatory option that specifies the fully qualified file name of thefile where the results are written.


version is a mandatory option that specifies the NSM service template version thatshould be returned.

username is a mandatory option that specifies the NSM service designer user name.It is not a required argument in the command because the command-line toolprompts the user for the username if omitted in the command.

password is a mandatory option that specifies the NSM service designer password.It is not a required argument in the command because the command-line toolprompts the user for the password if omitted in the command.




Examples./nsmadmin.sh command=getversion filename=serviceTemplateOutput.xml id=45 version=2./nsmadmin.sh command=getversion filename=serviceTemplateOutput.xml id=45 version=2username=admin password=password01./nsmadmin.sh -v command=getversion filename=serviceTemplateOutput.xml id=45version=2username=admin password=password01 port=7001./nsmadmin.sh command=getversion filename=serviceTemplateOutput.xml id=45version=2 username=admin password=password01 port=7001 -v

import commandThe NSM service designer can run the import command from the NSM CLI toimport a single NSM service template by using information from an XML file.

Usage./nsmadmin.sh command=import filename=<filename> username=<username> password=<password>port=<port> -v

Options

filename is a mandatory option that specifies the file from which the importinformation is read.





Notes

Username and password values within <databaseConnection> elements of a NSMservice template will not be exported as a result of executing any of the exportcommands. If any of these exported templates are to be imported into anotherenvironment, the user must provide the username and password values beforeexecuting the import functionality.

Examples./nsmadmin.sh command=import filename=/opt/IBM/importServiceTemplate.xml./nsmadmin.sh command=import filename=/opt/IBM/importServiceTemplate.xml username=adminpassword=password01./nsmadmin.sh command=import filename=/opt/IBM/importServiceTemplate.xml username=adminpassword=password01 port=7001./nsmadmin.sh command=import filename=/opt/IBM/importServiceTemplate.xml username=adminpassword=password01 port=7001 -v


importlist commandThe NSM service designer can run the importlist command from the NSM CLI toimport a number of NSM service templates by using information from an XMLfile.

Usage./nsmadmin.sh command=importlist filename=<filename> username=<username> password=<password>port=<port> -v

Options

filename is a mandatory option that specifies the file from which the importinformation is read.





Notes

Username and password values within <databaseConnection> elements of a NSMservice template will not be exported as a result of executing any of the exportcommands. If any of these exported templates are to be imported into anotherenvironment, the user must provide the username and password values beforeexecuting the import functionality.

The importlist command implies importing a number (or list) of NSM servicetemplates at once. It is a requirement that the NSM service templates in thereferenced file be wrapped in <serviceTemplates> tags as follows:<serviceTemplates>

<serviceTemplate name="TemplateOne"></serviceTemplate><serviceTemplate name=”TemplateTwo”></serviceTemplate>

.

.

.</serviceTemplates>

Examples./nsmadmin.sh command=importlist filename=/opt/IBM/importServiceTemplates.xml./nsmadmin.sh command=importlist filename=/opt/IBM/importServiceTemplates.xml username=adminpassword=password01./nsmadmin.sh command=importlist filename=/opt/IBM/importServiceTemplates.xml username=adminpassword=password01 port=7001./nsmadmin.sh command=importlist filename=/opt/IBM/importServiceTemplates.xml username=adminpassword=password01 port=7001 -v


list commandThe NSM service designer can run the list command from the NSM CLI to listthe latest enabled versions of all NSM service templates in an XML file. Theinformation returned contains only the NSM service template summary and doesnot contain detailed information on the template. If a full NSM service template isrequired then use the read or readall command

Usage./nsmadmin.sh command=list filename=<filename> username=<username>password=<password> port=<port> -v

Options




port is the Netcool Configuration Manager presentation server HTTP port number.The default value is 7001. It is optional.


Examples./nsmadmin.sh command=list filename=serviceTemplateOutputList.xml./nsmadmin.sh command=list filename=serviceTemplateOutputList.xml username=adminpassword=password01./nsmadmin.sh -v command=list filename=serviceTemplateOutputList.xml username=adminpassword=password01 port=7001./nsmadmin.sh command=list filename=serviceTemplateOutputList.xml username=adminpassword=password01 port=7001 -v

purge commandThe NSM service designer can run the purge command from the NSM CLI todelete all versions of a NSM service template.

Usage./nsmadmin.sh command=purge id=<id> username=<username> password=<password> port=<port> -v

Options




port is the Netcool Configuration Manager presentation server HTTP port number.The default value is 7001. It is optional.



Examples./nsmadmin.sh command=purge id=20./nsmadmin.sh command=purge id=20 username=admin password=password01./nsmadmin.sh -v command=purge id=20 username=admin password=password01 port=7001./nsmadmin.sh command=purge id=20 username=admin password=password01 port=7001 -v

read commandThe NSM service designer can run the read command from the NSM CLI toretrieve information about the latest enabled version of a NSM service templateand output this information to an XML file.

Usage./nsmadmin.sh command=read filename=<filename> id=<id> username=<username>password=<password> port=<port> -v

Options







Examples./nsmadmin.sh command=read filename=serviceTemplateOutput.xml id=45./nsmadmin.sh command=read filename=serviceTemplateOutput.xml id=45 username=adminpassword=password01./nsmadmin.sh -v command=read filename=serviceTemplateOutput.xml id=45 username=adminpassword=password01 port=7001./nsmadmin.sh command=read filename=serviceTemplateOutput.xml id=45 username=adminpassword=password01 port=7001 -v

readall commandThe NSM service designer can run the readall command from the NSM CLI toretrieve information about all versions of a NSM service template and output thisinformation to an XML file.

Usage./nsmadmin.sh command=readall filename=<filename> id=<id> username=<username>password=<password> port=<port> -v

Options








Examples./nsmadmin.sh command=readall filename=serviceTemplateOutput.xml id=45./nsmadmin.sh command=readall filename=serviceTemplateOutput.xml id=45 username=adminpassword=password01./nsmadmin.sh -v command=readall filename=serviceTemplateOutput.xml id=45 username=adminpassword=password01 port=7001./nsmadmin.sh command=readall filename=serviceTemplateOutput.xml id=45 username=adminpassword=password01 port=7001 -v

update commandThe NSM service designer can run the update command from the NSM CLI tocreates a new version of a NSM service template by updating the information in anexisting NSM service template. The update information is retrieved from an XMLfile.

Usage./nsmadmin.sh command=update id=<id> filename=<filename> username=<username>password=<password> port=<port> -v

Options


filename is a mandatory option that specifies the fully qualified file name of thefile where the update information is retrieved from.





Examples./nsmadmin.sh command=update id=19 filename=/opt/bin/QAJavaST.txt./nsmadmin.sh command=update id=19 filename=/opt/bin/QAJavaST.txtusername=admin password=password01./nsmadmin.sh -v command=update id=19 filename=/opt/bin/QAJavaST.txtusername=admin password=password01 port=7001./nsmadmin.sh command=update id=19 filename=/opt/bin/QAJavaST.txtusername=admin password=password01 port=7001 -v


removeserviceinstance commandThe NSM service designer can run the removeserviceinstance command from theNSM CLI to remove the database entry for an NSM service that reached any of thefollowing states: 'Failed', 'Failed to Delete', or 'Failed with indeterminate state'.

See “Interpreting NSM service execution status codes” on page 123 for moreinformation on NSM service states.

Usage./nsmadmin.sh command=removeserviceinstance service-id=<id> username=<username>username=<username> password=<password> port=<port> -v

Options

service-id is a mandatory option that specifies the NSM service identifier.





Examples./nsmadmin.sh command=removeserviceinstance service-id=45./nsmadmin.sh command=removeserviceinstance service-id=45 username=admin password=password01./nsmadmin.sh -v command=removeserviceinstance service-id=45 username=admin password=password01 port=7001./nsmadmin.sh command=removeserviceinstance service-id=45 username=admin password=password01 port=7001 -v

NSM command-line loggingYou can configure logging for the NSM CLI tool in the /opt/IBM/tivoli/netcool/ncm/bin/nsm/commons-logging.properties file. This configuration file controls theoutput to the log file and the console. You can also set the logging level and otherlogging options.

The NSM CLI tool log file is called /opt/IBM/tivoli/netcool/ncm/bin/nsm/nsmadmin.log. When you run CLI commands, all the output that is written to theconsole is also written to this log file. The detail of the information that is writtento the log file depends on the logging level that you can set in the/opt/IBM/tivoli/netcool/ncm/bin/nsm/commons-logging.properties file.

Note: The log file name may have a suffix of .* (dot star), where * (star)represents a number. This can occur if the configuration is set to produce multiplelog files. The file with the highest numeric suffix contains the most recent loginformation.


Chapter 6. Understanding the Network Service Manager URIs

The NSM REST API uses a RESTful web service model. REST (RepresentationalState Transfer) uses the HTTP protocol because this protocol provides an extensivevocabulary for specifying various operations on specific resources.

Specifically, the NSM REST API uses the following HTTP methods to operate onNSM and Netcool Configuration Manager resources:v GET - Lists the specified resource or collection of resourcesv POST - Creates the specified resourcev PUT - Updates or replaces the specified resourcev DELETE - Removes the specified resource

For a REST client the following HTTP headers need to be set in order to get therequired functionality working for NSM. The NSM REST API support both XMLand JSON in the request and response body of any URL defined here. The defaultcontent type is XML based.

To correctly use the NSM REST API a client should adhere to the followingguidelines:v For any of the HTTP methods GET/POST/DELETE/PUT requests, the HTTP

headers should include an “Accept: text/xml” if the client requires the responsein XML. The HTTP response will then contain an HTTP content type of“Content-Type: text/xml”.For a client that requires the response body to contain JSON, the HTTP headersshould have the following set “Accept: application/json” with a HTTP responseheader of “Content-Type: application/json”.

v For HTTP methods that are submitting a request body (POST/PUT), the contenttype HTTP header is required.For a request body that contains XML the content type header needs to be set asfollows “Content-Type: text/xml”.For a client that supports JSON the content type needs to be set as follows“Content-Type: application/json”.

The various combinations supported by the NSM REST API are shown in thefollowing tables:

Table 13. POST/PUT methods

Media types(Request/Response) Accept Header Content-Type

JSON/JSON application/json application/json

JSON/XML application/json text/xml

XML/JSON text/xml application/json

XML/XML text/xml text/xml

Table 14. GET/DELETE methods

Media types (Request/Response) Accept Header

JSON/JSON application/json


Table 14. GET/DELETE methods (continued)

Media types (Request/Response) Accept Header

JSON/XML application/json

XML/JSON text/xml

XML/XML text/xml

The Netcool Configuration Manager and NSM resources on which the previouslylisted HTTP operations can be completed include the following resources:v Realmv Devicev Service templatev Service

Use this information to obtain an understanding of the NSM URIs and the HTTPmethods that can be applied to each URI.

Realm URIsA realm represents a folder or hierarchy of folders on the Netcool ConfigurationManager presentation server. By making HTTP requests, NSM service designers orclient users can query the API for information about the realms and their content.

NSM service designers and client users can retrieve the following information byexecuting HTTP requests on realms.

Table 15. Realm URIs

URI syntaxHTTPmethod Description

nsm/realm GET This HTTP request returns a list of realms on theNetcool Configuration Manager presentationserver.

nsm/realm/{realm-id} GET This HTTP request returns information about aspecific realm. The realm that is returned is basedon the specific realm ID that is entered.

HTTP GET for /realmWhen the NSM user requests the /realm URI using the GET method, a list of realmsis returned. The sample response shows a list of realms and information aboutthem.

Input parameters

None

Available HTTP Headers

Accept: application/json

Accept: text/xml


Sample requesthttp://www.example.com:7001/nsm/realm/

Sample response

XML<realms><realm><fqName>ITNCM</fqName><id>101</id><name>ITNCM</name><parentId>0</parentId></realm><realm><fqName>ITNCM/Content</fqName><id>102</id><name>Content</name><parentId>101</parentId><parentName>ITNCM</parentName></realm><realm><fqName>ITNCM/EMULATED</fqName><id>1</id><name>EMULATED</name><parentId>101</parentId><parentName>ITNCM</parentName></realm></realms>

JSON{

"realms": [{

"fqName": "ITNCM","id": -101,"name": "ITNCM","parentId": 0

},{

"fqName": "ITNCM/Content","id": -102,"name": "Content","parentId": -101,"parentName": "ITNCM"

},{

"fqName": "ITNCM/EMULATED","id": 1,"name": "EMULATED","parentId": -101,"parentName": "ITNCM"

}]

}

XML response details

Table 16. Response details


fqName String Specifies the fully qualified realm name.

id Long Specifies the realm identifier as supplied by NetcoolConfiguration Manager.

Chapter 6. Understanding the Network Service Manager URIs 79

Table 16. Response details (continued)


name String Specifies the name of the realm.

parentId Long Specifies the parent realm identification or null if the baserealm.

parentName String Specifies the name of the parent realm.

HTTP GET for /realm/{realm-id}When the NSM client user requests the /realm/{realm-id} URI using the GETmethod, the realm that matches the realm ID is returned. The sample responsereturns the EMULATED realm and information about it based on its ID of 1.

Input parameters

{realm-id}



Accept: text/xml

Sample requesthttp://www.example.com:7001/nsm/realm/1

Sample response<realm><fqName>ITNCM/EMULATED</fqName><id>1</id><name>EMULATED</name><parentId>101</parentId><parentName>ITNCM</parentName></realm>

JSON{

"fqName": "ITNCM/EMULATED","id": 1,"name": "EMULATED","parentId": 101,"parentName": "ITNCM"

}


For more information about the /realm/{realm-id} response details, see the XMLresponse details table for “HTTP GET for /realm” on page 78 where the XML tagsare explained.


Device URIsNSM client users use device URIs to retrieve information about devices that theywant to run services on.

NSM service designers and NSM client users can retrieve (GET) the followinginformation by executing HTTP requests on devices.

Table 17. NSM device URIs


List/specificdetail Format

nsm/device GET This HTTP request returns thelist of devices in NetcoolConfiguration Manager.

List Short

nsm/device/long GET This HTTP request returns thelist of devices in NetcoolConfiguration Manager

List Long

nsm/device/{id} GET This HTTP request returns adescription of a specific deviceinNetcool ConfigurationManager based on the deviceID that is entered.

Specificdetail

Short

nsm/device/long/{id} GET This HTTP request returns adescription of a specific deviceinNetcool ConfigurationManager based on the deviceID that is entered.

Specificdetail

Long

nsm/device/created/after/{date} GET This HTTP request returns alist of devices that are createdin Netcool ConfigurationManager after a particulardate, in the format ofYYYYY-MM-DD.

List Short

nsm/device/long/created/after/{date} GET This HTTP request returns alist of devices that are createdin Netcool ConfigurationManager after a particulardate, in the format ofYYYYY-MM-DD.

List Long

nsm/device/created/before/{date} GET This HTTP request returns alist of devices that are createdin Netcool ConfigurationManager before a particulardate, in the format ofYYYY-MM-DD.

List Short

nsm/device/long/created/before/{date} GET This HTTP request returns alist of devices that are createdin Netcool ConfigurationManager before a particulardate, in the format ofYYYY-MM-DD.

List Long


Table 17. NSM device URIs (continued)



nsm/device/deleted/after/{date} GET This HTTP request returns alist of devices that are deletedfrom Netcool ConfigurationManager after a particulardate, in the format ofYYYY-MM-DD.

List Short

nsm/device/long/deleted/after/{date} GET This HTTP request returns alist of devices that are deletedfrom Netcool ConfigurationManager after a particulardate, in the format ofYYYY-MM-DD.

List Long

nsm/device/deleted/before/{date} GET This HTTP request returns alist of devices that are deletedfrom Netcool ConfigurationManager before a particulardate, in the format ofYYYY-MM-DD.

List Short

nsm/device/long/deleted/before/{date} GET This HTTP request returns alist of devices that are deletedfrom Netcool ConfigurationManager before a particulardate, in the format ofYYYY-MM-DD.

List Long

nsm/device/modified/after/{date} GET This HTTP request returns alist of devices that are modifiedin Netcool ConfigurationManager after a particulardate, in the format ofYYYY-MM-DD.

List Short

nsm/device/long/modified/after/{date} GET This HTTP request returns alist of devices that are modifiedin Netcool ConfigurationManager after a particulardate, in the format ofYYYY-MM-DD.

List Long

nsm/device/modified/before/{date} GET This HTTP request returns alist of devices that are modifiedin Netcool ConfigurationManager before a particulardate, in the format ofYYYY-MM-DD.

List Short

nsm/device/long/modified/before/{date} GET This HTTP request returns alist of devices that are modifiedin Netcool ConfigurationManager before a particulardate, in the format ofYYYY-MM-DD.

List Long





nsm/device/name/{name} GET This HTTP request returns alist of devices in NetcoolConfiguration Manager thatmatch the name that isspecified. The wildcards: "*"and "_" are permitted in thesearch.

List Short

nsm/device/long/name/{name} GET This HTTP request returns alist of devices in NetcoolConfiguration Manager thatmatch the name that isspecified. The wildcards: "*"and "_" are permitted in thesearch.

List Long

nsm/device/realm/{realmid} GET This HTTP request returns alist of devices in NetcoolConfiguration Manager in aspecific realm based on therealm ID that is entered.

List Short

nsm/device/long/realm/{realmid} GET This HTTP request returns alist of devices in NetcoolConfiguration Manager in aspecific realm based on therealm ID that is entered.

List Long

nsm/device/type/*/*/*/{OS} GET This HTTP request returns alist of devices in NetcoolConfiguration Manager thatmatch the operating systemthat is specified. The wildcards"*" and "_" are permitted in thesearch.

List Short

nsm/device/long/type/*/*/*/{OS} GET This HTTP request returns alist of devices in NetcoolConfiguration Manager thatmatch the operating systemthat is specified. The wildcards"*" and "_" are permitted in thesearch.

List Long

nsm/device/type/*/*/{Model} GET This HTTP request returns alist of devices in NetcoolConfiguration Manager thatmatch the model that isspecified. The wildcards "*"and "_" are permitted in thesearch.

List Short

nsm/device/long/type/*/*/{Model} GET This HTTP request returns alist of devices in NetcoolConfiguration Manager thatmatch the model that isspecified. The wildcards "*"and "_" are permitted in thesearch.

List Long





nsm/device/type/*/{Type} GET This HTTP request returns alist of devices in NetcoolConfiguration Manager thatmatch the device type that isspecified. The wildcards "*"and "_" are permitted in thesearch.

List Short

nsm/device/long/type/*/{Type} GET This HTTP request returns alist of devices in NetcoolConfiguration Manager thatmatch the device type that isspecified. The wildcards "*"and "_" are permitted in thesearch.

List Long

nsm/device/type/{Vendor} GET This HTTP request returns alist of devices in NetcoolConfiguration Manager thatmatch the vendor that isspecified. The wildcards "*"and "_" are permitted in thesearch.

List Short

nsm/device/long/type/{Vendor} GET This HTTP request returns alist of devices in NetcoolConfiguration Manager thatmatch the vendor that isspecified. The wildcards "*"and "_" are permitted in thesearch.

List Long

nsm/device/{device-id}/currentnativeconfiguration

GET This HTTP request returns acopy of the current nativeconfiguration for a specificdevice based on the device IDthat is entered.

Specificdetail

Nativeconfiguration

nsm/device/{device-id}/currentmodeledconfiguration

GET This HTTP request returns acopy of the current modeledconfiguration for a specificdevice based on the device IDthat is entered.

Specificdetail

Modeledconfiguration

nsm/device/{device-id}/currentsupplementalinformation

GET This HTTP request returns acopy of supplementalinformation about a specificdevice information based onthe device ID that is entered.

Specificdetail

Supplementalinformation


Short and long formats for device URIsWhen the NSM client user requests device URIs using the GET method, informationabout the devices on the Netcool Configuration Manager presentation server isreturned.

Most of the device URIs have two types of format: short and long. The onlyexceptions are the currentnativeconfiguration, currentmodeledconfiguration, andcurrentsupplementalinformation URIs. The following XML is a sample of therequests and XML that are returned from the short and long formats.

Sample requests for the short typehttp://www.example.com:7001/nsm/devicehttp://www.example.com:7001/nsm/device/created/after/2012-09-16http://www.example.com:7001/nsm/device/modified/before/2012-10-07http://www.example.com:7001/nsm/device/name/south*http://www.example.com:7001/nsm/device/realm/75http://www.example.com:7001/nsm/device/type/ibm/router/*/*http://www.example.com:7001/nsm/device/type/*/router/*/*

Sample response for the short type

XML<devices><device><id>2</id><name>emulcli4-17</name><fqName>ITNCM/EMULATED/emulcli4-17</fqName><vendor>Cisco</vendor><type>Router</type><model>2621</model><os>C2600-IS-M-12.2(3)</os><parentId>1</parentId><parentName>ITNCM/EMULATED</parentName><createdDate>2012-10-25 16:49:04.717 GMT+00:00</createdDate><lastModifiedDate>2012-11-19 17:56:42.412 GMT+00:00</lastModifiedDate><lastModifiedBy>administrator</lastModifiedBy><status>Managed</status></device><device><id>4</id><name>emulcli4-20</name><fqName>ITNCM/EMULATED/emulcli4-20</fqName><vendor>Juniper</vendor><type>Router</type><model>srx*</model><os>10.*</os><parentId>1</parentId><parentName>ITNCM/EMULATED</parentName><createdDate>2012-10-25 16:55:41.869 GMT+00:00</createdDate><lastModifiedDate>2012-10-25 16:55:52.440 GMT+00:00</lastModifiedDate><lastModifiedBy>administrator</lastModifiedBy><status>Staged</status></device></devices>

JSON{

"devices": [{

"id": 2,"name": "emulcli4-17","fqName": "ITNCM/EMULATED/emulcli4-17",


"vendor": "Cisco","type": "Router","model": "2621","os": "C2600-IS-M-12.2(3)","parentId": 1,"parentName": "ITNCM/EMULATED","createdDate": 1351183744717,"lastModifiedBy": "administrator","status": "Managed","lastModifiedDate": 1353347802412

},{

"id": 4,"name": "emulcli4-20","fqName": "ITNCM/EMULATED/emulcli4-20","vendor": "Juniper","type": "Router","model": "srx*","os": "10.*","parentId": 1,"parentName": "ITNCM/EMULATED","createdDate": 1351184141869,"lastModifiedBy": "administrator","status": "Staged","lastModifiedDate": 1351184152440

}]

}

Sample requests for the long typehttp://www.example.com:7001/nsm/device/longhttp://www.example.com:7001/nsm/device/long/created/after/2012-09-16http://www.example.com:7001/nsm/device/long/modified/before/2012-10-07http://www.example.com:7001/nsm/device/long/name/south*http://www.example.com:7001/nsm/device/long/realm/75http://www.example.com:7001/nsm/device/long/type/ibm/router/*/*http://www.example.com:7001/nsm/device/long/type/*/router/*/*

Sample response for the long type

XML<devices><device><id>2</id><name>emulcli4-17</name><fqName>ITNCM/EMULATED/emulcli4-17</fqName><vendor>cisco</vendor><type>router</type><model>2621</model><os>C2600-IS-M-12.2(3)</os><parentId>1</parentId><parentName>ITNCM/EMULATED</parentName><createdDate>2012-10-25 16:49:04.717 GMT+00:00</createdDate><createdBy>administrator</createdBy><lastModifiedDate>2012-11-19 17:56:42.412 GMT+00:00</lastModifiedDate><lastModifiedBy>administrator</lastModifiedBy><status>Managed</status><currentDriver>Isd0000104971</currentDriver><driverStatus>Optimal</driverStatus><driverType>CLI</driverType><label1> </label1><label2> </label2><label3> </label3><label4> more info</label4><supportLevel>SmartModel</supportLevel></device>


JSON{

"devices": [{

"id": 2,"name": "emulcli4-17","fqName": "ITNCM/EMULATED/emulcli4-17","vendor": "Cisco","type": "Router","model": "2621","os": "C2600-IS-M-12.2(3)","parentId": 1,"parentName": "ITNCM/EMULATED","createdDate": 1351183744717,"createdBy": "administrator","lastModifiedBy": "administrator","status": "Managed","currentDriver": "Isd0000104971","driverStatus": "Optimal","driverType": "CLI","label1": " ","label2": " ","label3": " ","label4": " ","supportLevel": "SmartModel","lastModifiedDate": 1353347802412

}]}


Note: The XML tags in the following table are Netcool Configuration Managertags.

Table 18. Response details - Tags, types descriptions for XML tags for both short and longtypes


id Integer Specifies the device ID as supplied by NetcoolConfiguration Manager.

name String Specifies the device name.

fqName String Specifies the fully qualified device name.

vendor String Specifies the manufacturer of the device.

type String Specifies the type of the device.

model String Specifies the model of the device.

os String Specifies the operating system on the device.

parentId Integer Specifies the ID of the parent realm.

parentName String Specifies the name of the parent realm.

createdDate String Specifies the date when the device was created.

lastModifiedDate String Specifies the date when the device was lastmodified.

lastModifiedBy String Specifies the who last modified the device.

status String Specifies the status of the device. The possiblestatuses are:

currentDriver String Specifies the device driver name that is used tocommunicate with the device.


Table 18. Response details - Tags, types descriptions for XML tags for both short and longtypes (continued)


driverStatus String Specifies the status of the driver. It possible statusesare: Optimal, Non_Optimal, Compatible, andNon_Compatible.

driverType String Specifies the type of driver that is used tocommunicate with the device.

label String Specifies additional information that the user caninsert about the device.

supportLevel Specifies the support level for the device. Thepossible levels are: Limited, SmartModel, andStandard.

Related reference:“HTTP GET for /service/{service-id}/device” on page 106

HTTP GET for /device/{device-id}/currentnativeconfigurationWhen the NSM client user requests the /device/{device-id}/currentnativeconfiguration URI using the GET method, a copy of the currentnative configuration of the device that matches the device ID entered is returned.

Input parameters

{device-id}



Accept: text/xml

Sample requesthttp://www.example.com:7001/nsm/device/2/currentnativeconfiguration

Sample response

XML<device><currentNativeConfiguration>version 12.2no service timestamps debug uptimeno service timestamps log uptimeno service password-encryptionservice compress-config!hostname bfo2610a!boot system flash dummy;exec-timeout 0 0transport input pad v120 telnet rlogin udptn!ntp clock-period 17208292end</currentNativeConfiguration></device>


JSON{

"currentNativeConfiguration": "version 12.2no service timestamps debug uptimeno service timestamps log uptimeno service password-encryptionservice compress-config!hostname bfo2610a!boot system flash dummy;exec-timeout 0 0transport input pad v120 telnet rlogin udptn!ntp clock-period 17208292end”}




currentNativeConfiguration Containertag

Specifies the current native configuration ofthe device in text format. The sampleresponse shows a sample deviceconfiguration, the full device configurationis not documented because it is large.

HTTP GET for /device/{device-id}/currentmodeledconfigurationWhen the NSM client user requests the /device/{device-id}/currentmodeledconfiguration URI using the GET method, a copy of the currentmodeled configuration of the device that matches the device ID entered isreturned.

Input parameters

{device-id}



Accept: text/xml

Sample requesthttp://www.example.com:7001/nsm/device/2/currentmodeledconfiguration

Sample response

XML<device><currentmodeledConfiguration><?xml version="1.0"?> <configuration schemaUID="201203160659"xmlns:deviceMarkup="http://www.intelliden.com/deviceMarkup"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><service><timestamps><debug><uptime deviceMarkup:disable="true"/></debug><log><uptime deviceMarkup:disable="true"/></log></timestamps><password-encryption deviceMarkup:disable="true"/><compress-config/></service><hostname>


<ARG.001>bfo2610a</ARG.001></hostname><boot><system><ARG.001>flash dummy;</ARG.001></system></boot><logging><buffered><ARG.001>10000</ARG.001><debugging/></buffered></logging><aaa><new-model/><authentication><login><default/><group><tacacs_2B/><none/></group></login><login><ARG.001>CONSOLE</ARG.001><none/></login><enable><default><group><tacacs_2B/><none/></group></default></enable></authenticationARG.001>0</ARG.001><ARG.002>0</ARG.002></exec-timeout><transport><input><pad/><v120/><telnet/><rlogin/><udptn/></input></transport></vty></line></configuration></currentmodeledConfiguration></device>

JSON{"currentModeledConfiguration": "<?xml version="1.0"?> <configuration schemaUID="201203160659"

xmlns:deviceMarkup="http://www.intelliden.com/deviceMarkup"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><service><timestamps><debug><uptime deviceMarkup:disable="true"/></debug><log><uptime deviceMarkup:disable="true"/></log></timestamps><password-encryption deviceMarkup:disable="true"/><compress-config/></service><hostname><ARG.001>bfo2610a</ARG.001></hostname><boot><system><ARG.001>flash dummy;</ARG.001></system></boot><logging><buffered><ARG.001>10000</ARG.001><debugging/></buffered></logging><aaa><new-model/><authentication><login><default/><group><tacacs_2B/><none/></group></login><login><ARG.001>CONSOLE</ARG.001><none/></login><enable><default><group><tacacs_2B/><none/></group></default></enable></authenticationARG.001>0</ARG.001><ARG.002>0</ARG.002></exec-timeout><transport><input><pad/><v120/><telnet/><rlogin/><udptn/></input></transport></vty></line></configuration>”}




currentmodeledConfiguration Containertag

Specifies the current modeled configurationof the device in XML format. The sampleresponse shows a sample deviceconfiguration, the full device configurationis not documented because it is large.

HTTP GET for /device/{device-id}/currentsupplementalinformation

When the NSM client user requests the /device/{device-id}/currentsupplementalinformation URI using the GET method, a supplementalinformation about the device that matches the device ID entered is returned.

Input parameters

{device-id}



Accept: text/xml

Sample requesthttp://www.example.com:7001/nsm/device/2/currentsupplementalinformation


Sample response

XML<device><currentSupplementalInformation>show versionImage text-base: 0x80008088, data-base: 0x8103F020

ROM: System Bootstrap, Version 12.1(3r)T2, RELEASE SOFTWARE (fc1)

2600h uptime is 5 weeks, 3 days, 9 hours, 2 minutesSystem returned to ROM by reload at 08:24:35 BFS Fri Mar 19 1993System image file is "flash:c2600-is-mz.122-3.bin"</currentSupplementalInformation></device>

JSON{

"currentSupplementalInformation": “show versionImage text-base: 0x80008088, data-base: 0x8103F020ROM: System Bootstrap, Version 12.1(3r)T2, RELEASE SOFTWARE (fc1)2600h uptime is 5 weeks, 3 days, 9 hours, 2 minutesSystem returned to ROM by reload at 08:24:35 BFS Fri Mar 19 1993System image file is "flash:c2600-is-mz.122-3.bin"”}




currentSupplementalInformation Container tag Specifies the supplemental information about the devicein text format. The sample response shows a samplesupplemental information, the full set of information isnot documented because it is large.

Service template URIsService templates are created by NSM service designers. These templates are usedto design services that can be executed by NSM client users.

NSM allows service designers and client users to retrieve the following informationby executing HTTP requests on NSM service templates.

Table 22. Service template URIs


nsm/servicetemplate/{servicetemplate-id}/deviceid/{device-id}

GET Gets the latest version of a user service templatebased on the service template ID that the NSMclient user or service designer enters. The servicetemplate that is returned matches the VTMOS fora particular device based on the device ID that theNSM client user or service designer enters.

nsm/servicetemplate/ GET Gets a list of the latest version of all NSM servicetemplates. The service template list that isreturned shows which NSM service templates arecurrently active on the system.


Table 22. Service template URIs (continued)


nsm/servicetemplate/deviceid/{device-id}

GET Gets a list of the latest version of all NSM servicetemplates applicable to a specific device. Theservice template list that is returned shows whichNSM service templates are currently active on thesystem that have an implementation that matchesthe device VTMOS based on the device ID that theNSM client user or service designer enters.

HTTP GET for /servicetemplate/{servicetemplate-id}/deviceid/{device-id}

When the NSM client user requests the /servicetemplate/{servicetemplate-id}/deviceid/{device-id} URI using the GET method, the latest version of a particularNSM service template that matches the NSM service template ID and device IDentered is returned. The NSM service template that is returned contains clientparameters that can be populated.

Input parameters

{servicetemplate-id} and {device-id}



Accept: text/xml

Sample requesthttp://www.example.com:7001/nsm/servicetemplate/1/deviceid/4

Sample response

XML<serviceTemplate id="2"><deviceID>2</deviceID><clientParameters><clientParameter><name>CPO1</name><value></value>

</clientParameter><clientParameter><name>CPO2</name><value></value>


</serviceTemplate>

JSON{

"deviceID": 2,"clientParameters": [

{"name": "CP01","value": ""

},


{"name": "CP02","value": ""

}],"id": 2

}




<serviceTemplate> Integer The <serviceTemplate> and </serviceTemplate>element pair encapsulates the followinginformation:

v Device identifier (encapsulated within the<deviceID> and </deviceID> tag pair).

v One or more client parameters (encapsulatedwithin the <clientParameter> and</clientParameter> tag pair).

v One or more client parameter lists(encapsulated within the<clientParameterList> and</clientParameterList> tag pair).

id String Specifies the unique identifier of the NSM servicetemplate. In the Sample Response, the specifiedNSM service template identifier is the value 2.

<deviceID> Integer Specifies the device identifier for the device thatthis NSM service template is being appliedagainst. In the Sample Response, the specifieddevice identifier is the value 2.

Client parameter descriptions

<clientParameters> Container Specifies a container that includes one or moreclient parameters that the NSM client user canedit. The client parameters are encapsulatedwithin the <clientParameters> and</clientParameters> element pair. In the SampleResponse, two client parameters are defined.

<clientParameter> String Specifies each parameter. Each client parameter isencapsulated within the <clientParameter> and</clientParameter> element pair.

<name> String Specifies the name of the parameter. Each clientparameter name is encapsulated within the <name>and </name> tag pair. In the Sample Response, thename of the first defined client parameter isCPO1.

<value> String Specifies the tag where the NSM client user canpopulate the value of each client parameter. In theSample Response, the NSM client user canpopulate the CPO1 client parameter in this tagpair: <value> </value>.

Client parameter lists descriptions




<clientParameterLists> Container Specifies a container that includes one or moreclient parameter lists. The client parameter listsare encapsulated within the<clientParameterLists> and</clientParameterLists> element pair. In theSample Response, no client parameter list isdefined.

<clientParameterList> String The <clientParameterList> and</clientParameterList> element pairencapsulates the following information:

v One or more client parameters (encapsulatedwithin the <parameter> and </parameter> tagpair).

v One or more value containers that are specifiedwith the <values> and </values> tag pair.

v One or more client parameter valueplaceholders (encapsulated within the <value>and </value> tag pair).

name Specifies the name of the client parameter list.

<parameter> String Each client parameter defined within a clientparameter list is encapsulated within the<parameter> and </parameter> tag pair.

name String Specifies the name of the parameter.

<values> Container Specifies a container that includes a clientparameter value for the client parameter specifiedin the <parameter> tag. This containerencapsulates each client parameter value withinthe <values> and </values> tag pair.

<value> String Specifies the tag where the NSM client user canpopulate values for each client parameter in theclient parameter list. The NSM client user canpopulate the client parameter value in this tagpair: <value> and </value>. There can be multiple<value> and </value> tag pairs defined within thecontainer <values> and </values> tag pair.

For example:

<clientParameterList name="PARAMETER_ALIAS"><parameter name="PARAMETER06"><values><value>Value1</value><value>Value2</value></values></parameter><clientParameterList>

Related tasks:“Submitting a NSM service template for execution” on page 21Related reference:“HTTP GET for /service/{service-id}/input” on page 110


HTTP GET for /servicetemplateWhen the NSM client user requests the /servicetemplate URI using the GETmethod, the latest versions of all NSM service templates that are deployed on thesystem is returned. The NSM service templates list that is returned contains theNSM service template id, description and name.

Input parameters

None



Accept: text/xml

Sample requesthttp://www.example.com:7001/nsm/servicetemplate/

Sample response

XML<serviceTemplates><serviceTemplate name="Servicetemplate_1" id="1" description="A Firewall Service Template"/><serviceTemplate name="Servicetemplate_2" id="2" description="A Load balancer Service Template"/><serviceTemplate name="Servicetemplate_3" id="3" description="A VLAN Service Template"/></serviceTemplates>

JSON{

"templates": [{

"description": "A Firewall Service Template","name": "Servicetemplate_1","id": 1

},{

"description": "A Load balancer Service Template","name": "Servicetemplate_2","id": 2

},{

"description": "A VLAN Service Template","name": "Servicetemplate_3","id": 3

}]

}




<serviceTemplates> List ofstrings

Includes information about the NSM service template.




<serviceTemplate> List ofstrings

Includes information about the NSM service template.The NSM service template can be specified with thefollowing attributes:

v id — Specifies the unique identifier of the NSMservice template.

v description — Specifies a description for the NSMservice template.

v name — Specifies the name of the NSM servicetemplate.

HTTP GET for /servicetemplate/deviceid/{device-id}When the NSM client user requests the /servicetemplate/deviceid/{device-id}URI using the GET method, the latest versions of all NSM service templates that aredeployed on the system applicable to a specific device is returned. The NSMservice template list that is returned shows which NSM service templates arecurrently active on the system that have an implementation that matches thedevice VTMOS based on the device ID that the NSM client user or service designerenters. The NSM service templates list that is returned contains the NSM servicetemplate id, description, and name. The NSM service templates list that is returnedcontains the NSM service template id, description, and name.

Input parameters

{device-id}



Accept: text/xml

Sample requesthttp://www.example.com:7001/nsm/servicetemplate/deviceid/4

Sample response

XML<serviceTemplates><serviceTemplate name="Servicetemplate_1" id="1" description="A Firewall Service Template"/><serviceTemplate name="Servicetemplate_2" id="2" description="A Load balancer Service Template"/></serviceTemplates>

JSON{

"templates": [{

"description": "A Firewall Service Template","name": "Servicetemplate_1","id": 1

},{

"description": "A Load balancer Service Template","name": "Servicetemplate_2",


"id": 2}

]}




<serviceTemplates> List ofstrings

Includes information about the NSM service template.

<serviceTemplate> List ofstrings

Includes information about the NSM service template.The NSM service template can be specified with thefollowing attributes:

v id — Specifies the unique identifier of the NSMservice template.

v description — Specifies a description for the NSMservice template.

v name — Specifies the name of the NSM servicetemplate.

Related tasks:“Submitting a NSM service template for execution” on page 21

Service URIsServices are used to initiate the execution of tasks, which execute work items onthe Netcool Configuration Manager presentation server.

NSM service designers and client users can retrieve (GET) and create (POST) thefollowing information by executing HTTP requests on services.

Table 26. Service URIs


nsm/service GET This HTTP request returns a list of services.

nsm/service/{service-id} GET This HTTP request returns the description of aspecific service. The service that is returned isbased on the specific service ID that is entered.

nsm/service/referenceid/{reference-id}

GET This HTTP request returns the description of aspecific service. The service that is returned isbased on the specific reference ID that isentered.

nsm/service/{service-id}/status

GET This HTTP request returns the status of aspecific service. The service that is returned isbased on the specific service ID that is entered.

nsm/service/{service-id}/device

GET This HTTP request returns a list of devicesaffected by a specific service. The service devicesthat are returned are based on the specificservice ID that is entered.

nsm/service/{service-id}/workitem

GET This HTTP request returns a list of the workitems executed for a specific service. The servicework items that are returned are based on thespecific service ID that is entered.


Table 26. Service URIs (continued)


nsm/service/{service-id}/workitem/{workitem-id}

GET This HTTP request returns a description of aspecific work item in a specific service. Theservice work item that is returned is based onthe specific service ID that is entered and thenthe specific work item ID that is entered.

nsm/service/{service-id}/input

GET This HTTP request returns a description of theinput that the client submitted to activate aservice.

nsm/service POST Creates a service for one device by using oneapplied NSM service template.

nsm/service/{reference-id} POST Create a service for one device by using oneapplied NSM service template and a reference idthat is supplied by the NSM client user.

Related tasks:“Submitting a NSM service template for execution” on page 21

HTTP GET for /serviceWhen the NSM client user requests the /service URI using the GET method, a listof services is returned. The sample response shows a list of services andinformation about them.

Input parameters

None



Accept: text/xml

Sample requesthttp://www.example.com:7001/nsm/service

Sample response

XML<services><service id="311" createdByUser="administrator"createDate="2012-10-26 10:59:19.313 GMT+00:00"lastUpdatedDate="2012-11-05 15:45:47.19 GMT+00:00" serviceWorkKey="29975">

<status>Success</status><devices><device><id>2</id></device></devices><appliedServiceTemplates><serviceTemplate version="1" id="2"><deviceID>2</deviceID></serviceTemplate></appliedServiceTemplates><serviceWorkItems><workItem status="FINISHED_SUCCESS" id="30083" type="COMMANDSET"

name="ITNCM/CommandSet1" deviceId="2"/><workItem status="FINISHED_SUCCESS" id="30084" type="COMMANDSET"


name="ITNCM/CommandSet2" deviceId="2"/></serviceWorkItems></service></services>

JSON{

"services": [{

"id": 311,"referenceId": "311","status": "SUCCESS","createDate": 1351249159313,"devices": [

{"id": 2

}],"appliedServiceTemplates": [

{"version": 2,"deviceID": 2,"id": 1

}],"serviceWorkItems": [

{"status": "FINISHED_SUCCESS","workItemId": 30083,"workType": "COMMANDSET","deviceId": 2,"name": "ITNCM/command1"

},{

"status": "FINISHED_SUCCESS","workItemId": 30084,"workType": "COMMANDSET","deviceId": 2,"name": "ITNCM/command2"

}],"createdByUser": "administrator","lastUpdatedDate": 1352130347019,"serviceWorkKey": 29975

}]

}




<services> Container Specifies a container that includes the list ofservices. The list of services are encapsulatedwithin the <services> and </services>element pair.




<service> List ofstrings

The <service> element includes the followinginformation about the service:

v The id attribute specifies the uniqueidentifier of the service.

v If it is present, the referenceid attributespecifies the reference ID that is suppliedby the NSM client user when they areposting a service.

v The createdByUser attribute specifies theidentifier (name) of the user who createdthe service.

v The createDate attribute specifies the dateand time when the service was created.

v The lastUpdateDate attribute specifies thedate and time when the service was lastupdated.

v The serviceWorkKey attribute specifies theunit of work (UOW) ID that can be foundin Netcool Configuration Manager. Thisallows a user to link the service executionwith the UOW item that was run onNetcool Configuration Manager.

<status> String Specifies the status of the service, for example,Success, Submitted, In Progress, Failed.

For information about status codes, see“Interpreting NSM service execution statuscodes” on page 123.

<devices> Container Specifies a container that includes the list ofdevices affected by the service. The list ofdevices are encapsulated within the <devices>and </devices> element pair.

<device> String,integer

Specifies the list of devices affected by theservice. Each device is identified by its <id>tag. For example, in the Sample response adevice is defined by its associated <id> tag (2).

<appliedServiceTemplates> Container Specifies a container that includes the list ofapplied NSM service templates. The list ofsupplied NSM service templates areencapsulated within the<appliedServiceTemplates> and</appliedServiceTemplates> element pair.

<appliedServiceTemplate> Strings,integer

Specifies the list of applied NSM servicetemplates that are submitted for the service.Each applied NSM service template includesthe following information:

v The version attribute specifies the NSMservice template version.

v The id attribute specifies the NSM servicetemplate identifier.

v The <deviceID> tag specifies the device thatthe NSM service template is applied.




<serviceWorkItems> Container Specifies a container that includes the list ofservice work item entries. The list of servicework item entries are encapsulated within the<serviceWorkItems> and </serviceWorkItems>element pair.

<workItem> Strings,integer

Specifies the list of work item entries that aresubmitted for the service. Each service workitem includes the following information:

v The description attribute includes adescription of the service work item.

v The status attribute specifies the status ofthe service work item. The statuses include:CANCELLED, EXPIRED, PENDING_APPROVAL,READY_FOR_EXECUTION, EXECUTING,FINISHED_SUCCESS, and FINISHED_FAILED.

v The id attribute specifies the unique servicework item identifier.

v The type attribute specifies the operationtype. The operation types are: COMMANDSET,DEVICESYNC, and EXTRACTION.

v The name attribute contains the name of theoperation that the service work itemrepresents.

v The deviceId attribute specifies the deviceto which the service work item is applied.

Related reference:“Operation attributes and types” on page 14“Interpreting HTTP status codes and NSM error codes” on page 123“HTTP GET for /service/{service-id}”“HTTP GET for /service/referenceid/{reference-id}” on page 103“HTTP GET for /service/{service-id}/status” on page 105“HTTP GET for /service/{service-id}/workitem” on page 107“HTTP GET for /service/{service-id}/workitem/{workitem-id}” on page 108“HTTP POST for /service” on page 111“HTTP POST for /service/{reference-id}” on page 113“HTTP DELETE for /service/{service-id}” on page 116

HTTP GET for /service/{service-id}When the NSM client user requests the /service/{service-id} URI using the GETmethod, a description of the service that matches the service ID entered isreturned.

Input parameters

{service-id}




Accept: text/xml

Sample requesthttp://www.example.com:7001/nsm/service/106

Sample response

XML<service id="312" referenceId="312" createdByUser="administrator"createDate="2012-10-26 10:59:19.313 GMT+00:00"lastUpdatedDate="2012-11-05 15:40:47.19 GMT+00:00" serviceWorkKey="29975"><status>Success</status><devices><device><id>2</id></device></devices><appliedServiceTemplates><serviceTemplate version="1" id="2"><deviceID>2</deviceID></serviceTemplate></appliedServiceTemplates><serviceWorkItems><workItem status="FINISHED_SUCCESS" id="30083" type="COMMANDSET"name="ITNCM/command1" deviceId="2"/><workItem status="FINISHED_SUCCESS" id="30084" type="COMMANDSET"name="ITNCM/command2" deviceId="2"/></serviceWorkItems></service>

JSON{

"id": 312,"referenceId": "312","status": "SUCCESS","createDate": 1351249158313,"devices": [

{"id": 2





},{

"status": "FINISHED_SUCCESS","workItemId": 30084,


"workType": "COMMANDSET","deviceId": 2,"name": "ITNCM/command2"


}


For more information about the /service/{service-id} XML response details, seethe XML response details table for “HTTP GET for /service” on page 98 where theXML tags are explained.Related tasks:“Submitting a NSM service template for execution” on page 21Related reference:“HTTP GET for /service” on page 98

HTTP GET for /service/referenceid/{reference-id}When the NSM client user requests the /service/referenceid/{reference-id} URIusing the GET method, a description of the service that matches the reference IDentered is returned.

Input parameters

{reference-id}



Accept: text/xml

Sample requesthttp://www.example.com:7001/nsm/service/referenceid/Doc01

Sample response

XML<service id="312" referenceid="Doc01"createdByUser="administrator"createDate="2012-10-26 10:59:19.313 GMT+00:00"lastUpdatedDate="2012-11-05 15:40:47.19 GMT+00:00" serviceWorkKey="29975"><status>Success</status><devices><device><id>2</id></device></devices><appliedServiceTemplates><serviceTemplate version="1" id="2"/><deviceID>2</deviceID></serviceTemplate></appliedServiceTemplates><serviceWorkItems><workItem status="FINISHED_SUCCESS" id="0083" type="COMMANDSET"

name="ITNCM/command1" deviceId="2"/>


<workItem status="FINISHED_SUCCESS" id="0084" type="COMMANDSET"name="ITNCM/command2" deviceId="2"/></serviceWorkItems></service>

JSON{

"id": 312,"referenceId": "Doc01","status": "SUCCESS","createDate": 1351249158313,"devices": [

{"id": 2





},{

"status": "FINISHED_SUCCESS","workItemId": 30084,"workType": "COMMANDSET","deviceId": 2,"name": "ITNCM/command2"


}


For more information about the /service/referenceid/{reference-id} XMLresponse details, see the XML response details table for “HTTP GET for /service”on page 98 where the XML tags are explained.Related tasks:“Submitting a NSM service template for execution” on page 21Related reference:“HTTP GET for /service” on page 98


HTTP GET for /service/{service-id}/statusWhen the NSM client user requests the /service/{service-id}/status URI usingthe GET method, a description of the status of the service that matches the serviceID entered is returned.

Input parameters

{service-id}



Accept: text/xml

Sample requesthttp://www.example.com:7001/nsm/service/4/status

Sample response

XML<service id="312" referenceId="312" createdByUser="administrator"createDate="2012-10-26 10:59:19.433 GMT+00:00"lastUpdatedDate="2012-11-05 15:56:54.285 GMT+00:00" serviceWorkKey="36517"><status>Success</status></service>

JSON{

"id": 312,"referenceId": "312","status": "SUCCESS","createDate": 1351249159433,"createdByUser": "administrator","lastUpdatedDate": 1352131014285,"serviceWorkKey": 36517

}


For more information about the /service/{service-id}/status response details,see the XML response details table for “HTTP GET for /service” on page 98 wherethe XML tags are explained.Related tasks:“Submitting a NSM service template for execution” on page 21Related reference:“HTTP GET for /service” on page 98


HTTP GET for /service/{service-id}/deviceWhen the NSM client user requests the /service/{service-id}/device URI usingthe GET method, a list of devices affected by the service that matches the service IDentered is returned.

Input parameters

{service-id}



Accept: text/xml

Sample requesthttp://www.example.com:7001/nsm/service/4/device

Sample response

XML<devices><device><id>2</id><name>192.168.16.22</name><fqName>ITNCM/EMULATED/emulcli4-17</fqName><vendor>Cisco</vendor><type>Router</type><model>2621</model><os>C2600-IS-M-12.2(3)</os><parentId>1</parentId><parentName>ITNCM/EMULATED</parentName><createdDate>2012-10-25 16:49:04.717 GMT+00:00</createdDate><lastModifiedDate>2012-11-19 17:56:42.412 GMT+00:00</lastModifiedDate><lastModifiedBy>administrator</lastModifiedBy><status>Managed</status></device>

</devices>

JSON{

"devices": [{

"id": 2,"name": "192.168.16.22","fqName": "ITNCM/EMULATED/emulcli4-17","vendor": "Cisco","type": "Router","model": "2621","os": "C2600-IS-M-12.2(3)","parentId": 1,"parentName": "ITNCM/EMULATED","createdDate": 1351183744717,"lastModifiedBy": "administrator","status": "Managed","lastModifiedDate": 1353347802412

}]

}



For more information about the /service/{service-id}/device XML responsedetails, see the XML response details table for “Short and long formats for deviceURIs” on page 85 and HTTP GET for /device/{device-id} where the XML tags areexplained.Related reference:“Short and long formats for device URIs” on page 85

HTTP GET for /service/{service-id}/workitemWhen the NSM client user requests the /service/{service-id}/workitem URIusing the GET method, the list of work items in a specific service that matches theservice ID entered is returned.

Input parameters

{service-id}



Accept: text/xml

Sample requesthttp://www.example.com:7001/nsm/service/106/workitem

Sample response

XML<serviceWorkItems><workItem status="FINISHED_SUCCESS" id="36518" type="COMMANDSET" name="ITNCM/command1"deviceId="2"/><workItem status="FINISHED_SUCCESS" id="36519" type="COMMANDSET" name="ITNCM/command2"deviceId="2"/></serviceWorkItems>

JSON{

"workItems": [{

"status": "FINISHED_SUCCESS","workItemId": 36518,"workType": "COMMANDSET","deviceId": 2,"name": "ITNCM/Command1"

},{

"status": "FINISHED_SUCCESS","workItemId": 36519,"workType": "COMMANDSET","deviceId": 2,"name": "ITNCM/Command2"

}]

}



For more information about the /service/{service-id}/workitem response details,see the XML response details table for “HTTP GET for /service” on page 98 wherethe XML tags are explained.Related reference:“HTTP GET for /service” on page 98

HTTP GET for /service/{service-id}/workitem/{workitem-id}When the NSM user requests the /service/{service-id}/workitem/{workitem-id}URI using the GET method, a description of the work item that matches the workitem ID entered for a specific service that matches the service ID entered isreturned.

Input parameters

{service-id} and {workitem-id}



Accept: text/xml

Sample requesthttp://www.example.com:7001/nsm/service/11/workitem/25

Sample response

XML<workItem status="FINISHED_SUCCESS" id="36518"><workItemResults><workItemResult/></workItemResults><workItemLog>2012-11-05 15:56:30.731373 : Task Start Time: 2012/11/05 15:56:25.846 GMT+00:00*******************************************************Task: Work submitted by service UOW 36517 Device: emulcli4-17 Command Set: Declan1*******************************************************2012-11-05 15:56:30.731373 :Allocating 25MB of task memory (100% of the default task memory)...2012-11-05 15:56:30.731373 : >>> Operation Started on Worker Server ’taraz4’...(constants): 2012/11/05 15:56:25.856 GMT+00:002012-11-05 15:56:30.731373 :<<< Operation Finished in 0 seconds (constants):2012/11/05 15:56:25.856 GMT+00:002012-11-05 15:56:30.731373 :>>> Operation Started on Worker Server ’taraz4’... (checkCommandSet):2012/11/05 15:56:25.856 GMT+00:002012-11-05 15:56:30.731373 :<<< Operation Finished in 0 seconds 15:56:30.731373 :Task End Time: 2012/11/05 15:56:28.58 GMT+00:00</workItemLog></workItem>

JSON{

"status": "FINISHED_SUCCESS","workItemId": 36518,"workItemResults": [

{}],"2012-11-05 15:56:30.731373 : Task Start Time: 2012/11/05 15:56:25.846 GMT+00:00

*******************************************************Task: Work submitted by service UOW 36517 Device: emulcli4-17 Command Set: Declan1*******************************************************2012-11-05 15:56:30.731373 :


Allocating 25MB of task memory (100% of the default task memory)...2012-11-05 15:56:30.731373 :>>> Operation Started on Worker Server ’taraz4’... (constants):2012/11/05 15:56:25.856 GMT+00:002012-11-05 15:56:30.731373 :<<< Operation Finished in 0 seconds (constants):2012/11/05 15:56:25.856 GMT+00:002012-11-05 15:56:30.731373 :>>> Operation Started on Worker Server ’taraz4’... (checkCommandSet):2012/11/05 15:56:25.856 GMT+00:002012-11-05 15:56:30.731373 :<<< Operation Finished in 0 seconds 15:56:30.731373 :Task End Time: 2012/11/05 15:56:28.58 GMT+00:00"}


For more information about the /service/{service-id}/workitem/{workitem-id}response details, see the XML response details table for “HTTP GET for /service”on page 98 where the XML tags are explained.

The additional parameters listed in the Sample response that are not explained in“HTTP GET for /service” on page 98 are described in Table 28.



<workItem> Container The <workItem> element representsan operation that is or has been runagainst a device from NetcoolConfiguration Manager. It gives thestate of the operation as it executes.It also reports the final status of theoperations after execution. The<workItem> element includes thefollowing information about theservice work item:

v The status attribute specifies thestatus of the service work item.The statuses include: CANCELLED,EXPIRED, PENDING_APPROVAL,READY_FOR_EXECUTION, EXECUTING,FINISHED_SUCCESS, andFINISHED_FAILED.

v The id attribute specifies theunique service work itemidentifier.

<workItemResults> String Specifies the service work itemresults. Depending on the type ofservice work item, the resultcontent varies. For example, whena service work item is for anoperation whose type isEXTRACTION, the result contentincludes the result of the extraction.When a service work item is for anoperation whose type is COMMANDSETor DEVICESYNC, no result content isproduced in the workItemResultelement, as show in the Sampleresponse.

<workItemLog> String Specifies the contents of the servicework item log.


Related tasks:“Submitting a NSM service template for execution” on page 21Related reference:Appendix A, “Sample XML responses for operation types,” on page 131“HTTP GET for /service” on page 98

HTTP GET for /service/{service-id}/inputWhen the NSM user requests the /service/{service-id}/input URI using the GETmethod, a description of the input that the client submitted to activate a service isreturned.

Input parameters

{service-id}



Accept: text/xml

Sample requesthttp://www.example.com:7001/nsm/service/11/input

Sample response

XML<string><serviceTemplate id="2"><deviceID>4</deviceID><clientParameters><clientParameter><name>PARAMETER01</name><value>P1</value></clientParameter></clientParameters><clientParameterLists><clientParameterList name="PARAMETER_ID"><parameter name="PARAMETER06"><values><value order="1">P5</value><value order="2">P6</value></values></parameter><clientParameterList></clientParameterLists></serviceTemplate></string>

JSON“<serviceTemplate id="2"><deviceID>4</deviceID><clientParameters><clientParameter><name>PARAMETER01</name><value>P1</value></clientParameter>


</clientParameters><clientParameterLists><clientParameterList name="PARAMETER_ID"><parameter name="PARAMETER06"><values><value order="1">P5</value><value order="2">P6</value></values></parameter><clientParameterList></clientParameterLists></serviceTemplate>”


For more information about the /service/{service-id}/input response details, seethe XML response details table for “HTTP GET for/servicetemplate/{servicetemplate-id}/deviceid/{device-id}” on page 92 where theXML tags are explained. .Related reference:“HTTP GET for /servicetemplate/{servicetemplate-id}/deviceid/{device-id}” onpage 92

HTTP POST for /serviceWhen the NSM client user requests the /service URI using the POST method, aservice is created for one device and from one NSM service template.

NSM creates a service instance using the <serviceOperation> element with aservice operation of type CREATE defined in the NSM service template.

Input parameters

None

Sample input XML

Service URIs that use the POST method require XML to be posted into the requestbody. Enter the following input XML when you are running the POST /serviceURI:XML<serviceTemplate id="202"><deviceID>2</deviceID><clientParameters><clientParameter><name>CP02</name><value>B</value><description>description cpd</description></clientParameter></clientParameters><clientParameterLists><clientParameterList name="CP01"><parameter name="CP083"><values><value order="1">P9</value><value order="2">P10</value></values></parameter></clientParameterList></clientParameterLists></serviceTemplate>


JSON{


{"name": "CP02","value": "B","description": "description cpd"

}],"clientParameterLists": [

{"name": "CP01","clientParameterLists": [

{"name": "CP083","values": [

{"value": "P9"

},{

"value": "P10"}

]}

]}

],"id": 202

}

After entering the input XML, run the POST /service URI.



Accept: text/xml

Content-Type: application/json

Content-Type: text/xml

Sample requesthttp://www.example.com:7001/nsm/service

Sample response

XML<service id="801" referenceId="801" createdByUser="administrator"createDate="2012-11-21 12:56:53.472 GMT+00:00"><status>Submitted</status><devices><device><id>2</id></device></devices><appliedServiceTemplates><serviceTemplate id="202" version="1"><deviceID>2</deviceID></ServiceTemplates></appliedServiceTemplates><serviceWorkItems/></service>


JSON{

"id": 801,"referenceId": "801","status": "SUBMITTED","createDate": 1353502667046,"devices": [

{"id": 2



}],"serviceWorkItems": [],"createdByUser": "administrator"

}


For more information about the /service response details, see the XML responsedetails table for “HTTP GET for /service” on page 98 where the XML tags areexplained.Related tasks:“Submitting a NSM service template for execution” on page 21Related reference:“HTTP GET for /service” on page 98

HTTP POST for /service/{reference-id}When the NSM client user requests the /service/{reference-id} URI using thePOST method, a service is created for one device by using one applied NSM servicetemplate and a reference id that is supplied by the NSM client user.

NSM creates a service instance using the <serviceOperation> element with aservice operation of type CREATE defined in the NSM service template.

Note: The NSM client user must supply the reference ID, which can be used onceper service POST and it must be unique. This reference ID supports the followingcharacters:v Alphanumeric characters that are not case-sensitivev Numeric charactersv Underscores: "_"v Dashes: "-"

Input parameters

{reference-id}


Sample input XML

Service URIs that use the POST method require XML to be posted into the requestbody. Enter the following input XML when you are running the POST/service/{reference-id} URI:XML<serviceTemplate id="202"><deviceID>2</deviceID><clientParameters><clientParameter><name>CP02</name><value>B</value><description>description cpd</description></clientParameter></clientParameters><clientParameterLists><clientParameterList name="CP01"><parameter name-"CP083"><values><value order="1">P9<\value><value order="2">P10<\value></value></values></clientParameterList></clientParameterLists></serviceTemplate></service>

JSON{


{"name": "CP02","value": "B","description": "description cpd"

}],"clientParameterLists": [

{"name": "CP01","clientParameterLists": [

{"name": "CP083","values": [

{"value": "P9"

},{

"value": "P10"}

]}

]}

],"id": 202

}



Accept: text/xml


Content-Type: application/json

Content-Type: text/xml

Sample requesthttp://www.example.com:7001/nsm/service/ServiceTicket-1

Sample response

XML<service id="801" referenceid="ServiceTicket-1" createdByUser="administrator"createDate="2012-11-21 12:56:53.472 GMT+00:00"><status>Submitted</status><devices><device><id>2</id></device></devices><appliedServiceTemplates><serviceTemplate id="202" version="1"><deviceID>2</deviceID></serviceTemplate></appliedServiceTemplates><serviceWorkItems/></service>

JSON{

"id": 801,"referenceId": "ServiceTicket-1","status": "SUBMITTED","createDate": 1353502667046,"devices": [

{"id": 2



}],"serviceWorkItems": [],"createdByUser": "administrator"

}


For more information about the /service response details, see the XML responsedetails table for “HTTP GET for /service” on page 98 where the XML tags areexplained.Related tasks:“Submitting a NSM service template for execution” on page 21Related reference:“HTTP GET for /service” on page 98


HTTP DELETE for /service/{service-id}When the NSM client user requests the /service/{reference-id} URI using theDELETE method, NSM creates a service instance using the <serviceOperation>element with a service operation of type DELETE defined in the NSM servicetemplate.

NSM submits this service instance to Netcool Configuration Manager forprocessing using the same service used in the create process. NSM returns adescription of the service that matches the service ID entered. NetcoolConfiguration Manager executes all operations defined in the NSM servicetemplate that are needed to clean up the system when a request for deleting theservice is received.

Note: The status of the service is now set to “deleting”. Once submitted, theservice execution process can be checked in the same way as for the create process.

Input parameters

{service-id}



Accept: text/xml

Sample requesthttp://www.example.com:7001/nsm/service/106

Sample response

XML<service id="3" createdByUser="administrator" createDate="2012-08-1512:33:31.0 GMT+00:00"lastUpdatedDate="2012-08-15 12:33:47.0 GMT+00:00" serviceWorkKey="9"><status>Deleting</status><devices><device><id>4</id></device></devices><appliedServiceTemplates><serviceTemplate version="1" id="1"><deviceID>4</deviceID></serviceTemplate></appliedServiceTemplates><serviceWorkItems><workItem status="FINISHED_SUCCESS" id="10" type="COMMANDSET" name="ITNCM/commandset_J110"deviceId="4"/></serviceWorkItems></service>

JSON{

"id": 3,"referenceId": "3","status": "DELETING","createDate": 1351249159433,"devices": [

{"id": 4

}


],"appliedServiceTemplates": [



{"status": "FINISHED_SUCCESS","workItemId": 10,"workType": "COMMANDSET","deviceId": 4,"name": "ITNCM/commandset_J110"


}


For more information about the /service/{service-id} response details, see theXML response details table for “HTTP GET for /service” on page 98 where theXML tags are explained. This Delete response is similar to the GET response.Related tasks:“Submitting a NSM service template for execution” on page 21Related reference:“HTTP GET for /service” on page 98

XSD URIsNSM service designers and client users can retrieve (GET) the NSM.xsd file thatexplains the NSM schema by executing an HTTP request on the nsm/xsd URI.

Table 29. XSD URIs


nsm/xsd GET This HTTP request returns a copy of the NSM.xsd file whichdescribes the NSM schema. The NSM.xsd schema filecontains the schema of devices, realms, services andservicetemplates.

HTTP GET for /nsm/xsdWhen the NSM client user requests the /nsm/xsd URI using the GETmethod, a copy of the NSM.xsd file is returned. The NSM.xsd schema filereturned contains the schema of devices, realms, services andservicetemplates.

Input parameters

none

Sample request

http://www.example.com:7001/nsm/xsd


Sample response<?xml version="1.0" encoding="utf-8"?><xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">



<xs:element name="serviceTemplates" type="serviceTemplatesListType"/><xs:complexType name="serviceTemplatesListType"><xs:sequence><xs:element name="serviceTemplate" type="serviceTemplateType" minOccurs="1"

maxOccurs="unbounded"/></xs:sequence></xs:complexType>

.......

<xs:complexType name="appliedServiceTemplateType"><xs:attribute name="id" type="StringNotBlank" use="required"/><xs:attribute name="version" type="StringNotBlank" use="required"/><xs:attribute name="deviceID" type="StringNotBlank" use="optional"/></xs:complexType>

</xs:schema>


Table 30. XML response details


Schema Containertag

Specifies the NSM schema (NSM.xsd file).Note: The sample response shows a sample portion of the NSM.xsdfile, the full NSM.xsd file is not included as it is too large. SeeAppendix B, “XSD files,” on page 135 for NSM XSD file details.

Chapter 7. Understanding automatically generated NSMservice templates

NSM automatically generates NSM service templates when Netcool ConfigurationManager is used to create command set groups. The complete lifecycle of theseNSM service templates is controlled by NSM in response to changes in thecommand set group for which a template is created. While you can use thecommand-line tool on these NSM service templates it is not recommended unlessyou are using it as a template to create a new NSM service template.

NSM synchronizes (that is, automatically generates or updates) the NSM servicetemplate when the command set group has any of the following actions carriedout on it:v Rename

v Move

v Edit

v Delete

Note: If the NSM service designer attempts to use the update command to changethe auto-generated NSM service template, then an NSM error code of 55 isgenerated and the NSM service template will not be updated. The NSM servicedesigner should instead use the clone command to make an editable copy of thisNSM service template.

Use this information to obtain an understanding of how these actions affect howNSM synchronizes NSM service templates.

Rename actionThe Rename action triggers NSM to update the NSM service template for thatcommand set group.

Specifically, the Rename action causes NSM to update the following items in theNSM service template:v name attribute of the <serviceTemplate> elementv name attribute of the <operation> tag

The sample XML shows examples of the name attributes for the <serviceTemplate>element and the <operation> tag. On a Rename action, NSM updates:v The name attribute of the NSM service template, which in the example is

cmsSetGroupName.v The name attribute of the operation, which in the example is

ITNCM/realm1/cmsSetGroupName. Note that the operation name consists ofthe fully qualified realm and the name. Thus, in the example NSM updates onlythe command set group name (cmsSetGroupName) in the name attribute of the<operation> tag.

.

.

.<serviceTemplate name="cmsSetGroupName" version="1">.


.

.<operation name="ITNCM/realm1/cmsSetGroupName" rollback="true" type="COMMANDSET">...

Move actionThe Move action triggers NSM to update the NSM service template for thatcommand set group.

Specifically, the Move action causes NSM to update the following item in the NSMservice template:v name attribute of the <operation> tag

The sample XML shows an example of the name attribute for the <operation> tag.On a Move action, NSM updates:v The name attribute of the operation, which in the example is

ITNCM/realm1/cmsSetGroupName. Note that the operation name consists ofthe fully qualified realm and the name. Thus, in the example NSM updates onlythe command set group name (cmsSetGroupName) in the name attribute of the<operation> tag.

.

.

.<operation name="ITNCM/realm1/cmsSetGroupName" rollback="true" type="COMMANDSET">...

Edit actionThe Edit action relates to editing a command set group. The Edit action involvesadding, removing, or updating of embedded command sets within the commandset group. Any of the previously described Edit actions triggers NSM to update theNSM service template for that command set group.

The NSM service template is updated in two sections:v The client parameters section (identified by the<clientParameter> and

</clientParameter> element pair) where client parameters are either added orremoved. In the following example, the client parameter calledNew_Parameter_added triggers NSM to update the name attribute of the<clientParameter> element:<clientParameters><clientParameter><name>PARAMETER01</name></clientParameter><clientParameter><name>New_Parameter_added</name></clientParameter></clientParameters>

v The parameter list within the operation (identified by the<operation> and</operation> element pair) that defines the list of parameters required by thisoperation in order for Netcool Configuration Manager to execute the commandset group. In the following example, the parameter called


New_Parameter_added triggers NSM to update the name attribute of the<parameter> tag within the operation called ITNCM/realm1/cmsSetGroupName"rollback:operation in order for NCM to execute the command set group.<operation name="ITNCM/realm1/cmsSetGroupName" rollback="true" type="COMMANDSET"><parameters><parameter name="PARAMETER01"/><parameter name="New_Parameter_added"/></parameters>

Delete actionThe Delete action triggers NSM to delete the NSM service template for thatcommand set group.

The sample XML shows an example of a NSM service template calledcmsSetGroupName. On a Delete action, NSM deletes the NSM service templatecalled cmsSetGroupName....<serviceTemplate name="cmsSetGroupName" version="1">...

Chapter 7. Understanding automatically generated NSM service templates 121

Chapter 8. Troubleshooting

Use this information to learn about the NSM REST API message and HTTP statuscodes.Related tasks:“Running the CLI tool” on page 57

Interpreting NSM service execution status codesWhen a service executes, the service execution response from NSM includesinformation about the status of the service.

Table 31 lists all of the NSM service execution status codes, associated text, andtheir meanings.

Table 31. NSM service status codes

NSM statuscode NSM status text Description

0 Success Service executed successfully.

10 Submitted Service submitted for execution.

20 In Progress Service execution in progress.

30 Failed Service failed execution.

50 Deleting A service has been submitted forservice deletion.

60 Deleted Service is deleted.

70 Failed to Delete Failed to delete service.

80 In Progress Deleting A service is in the process of beingdeleted.

90 Failed with indeterminate state A service would be in this state ifany preprocessing of command sets,devices, or parameters used by theservice was found to have failed.

Interpreting HTTP status codes and NSM error codesIf an NSM client user runs an invalid command that results in an error, an HTTPstatus code and NSM error code are returned. The HTTP status code includesinformation about whether a request is received by the NSM server. The NSMerror codes give an indication on why NSM failed the request.

Format of error responses from URI requests

If a URI request causes an error, the HTTP status code and NSM error codereturned are in this format:Response code: 404Response message: NSM-ERR-XX

where XX is the NSM error code. For example, if NSM cannot find the requesteddevice ID, the NSM client user sees the following:


Response code: 404Response message: NSM-ERR-1

where the NSM error code of 1 means that a device was not found.

Table 32 lists all of the NSM error codes and their meaning.

Format of error responses from the CLI

If the error occurs when the user is using the command-line tool, the HTTP statuscode and message returned are in this format:An error occurred in request processing, a HTTP Status Code of [404] with a Messageof [Not Found] was received.See the Intelliden.log for details.

The user should then look at the Intelliden.log to find more information aboutthe error that occurred, including the NSM error code. The default path for theIntelliden.log file is /opt/IBM/tivoli/netcool/ncm/logs.

The HTTP status code can be one of the following responses:HttpStatus.NOT_FOUND 404HttpStatus.FORBIDDEN 403HttpStatus.UNAUTHORIZED 401HttpStatus.BAD_REQUEST 400

For the example where the NSM service template ID is not found, theIntelliden.log may show:2012/10/24,12:41:10.250,com.ibm.tivoli.itncm.logging.ItncmLogger,THR:246,ERROR,NotFoundException - NSM Error Code: 3 SERVICETEMPLATE_NOT_FOUNDcom.ibm.tivoli.nsm.web.exceptions.NotFoundException: Unable to find Service Template with ID :[101]

Table 32 lists all of the NSM error codes and their meaning.

Table 32. NSM error codes and descriptions

NSM error code NSM error code meanings

1 The Device was not found. This error can occur when thedeviceid is missing from the XML when submitting newservices. This error can also occur when the NSM client user isusing the NSM REST device URIs and they do not havepermission to view the deviceid or the deviceid does not existon the NCM system.

2 The Realm does not exist. This error can occur when a Realm IDis supplied to the realm NSM REST URI that does not exist onthe NCM system.

3 The Service template was not found. This error can occur if nomatching implementation was found in an existing NSM servicetemplate based on the VTMOS of the device supplied and theregular expression DeviceType rules specified within theImplementations. This error can also occur if the NSM servicetemplate id supplied does not exist on the NCM system.

This error can occur when the NSM service designer is using thecommand-line tool on NSM service templates. This error canalso occur when the NSM client user is using the NSM RESTNSM service template URIs or submitting new services.


Table 32. NSM error codes and descriptions (continued)


4 The inject method to call was not specified. This error can occurwhere a NSM service template has been created with InjectParameters that have arguments defined but with no JavaScriptMethod to call.

5 An Error occurred while executing the inject parameter. Thiserror can occur during service execution while processing Injectparameters.

6 Inject parameter has been configured incorrectly. This error canoccur where a NSM service template has been created withInject Parameters that are missing either Code or arguments.

7 This error can occur at NSM startup when the Work Managerhas not been initialized correctly.

8 An Error occurred while the JavaScript Engine is executing theJavaScript associated with the inject parameter.

9 An Error occurred when marshalling a NSM service template toXML while Importing during service execution.

10 An SQL parameter has been configured incorrectly in a NSMservice template; it has no parameters.

11 An Error occurred with security (encryption) of a databasepassword within a NSM service template.

12 The SQL query to execute was omitted in a SQL parameterdefined within a NSM service template.

13 An SQL parameter has been configured incorrectly in a NSMservice template; it has no SQL Query and no parametersdefined.

14 The HTTP URL was omitted in the HTTP parameter definedwithin a NSM service template.

15 During service execution a parameter argument was not found.

16 During service execution a parameter argument was calculatedbut produced an empty value.

17 An error occurred on the NSM system when performing a GETfor an HTTP parameter.

18 An error occurred on the destination server when performing aGET for an HTTP parameter.

19 A general HTTP error occurred when performing a GET for anHTTP parameter.

20 An error occurred due to bad SQL grammar in an SQL query ofan SQL parameter within a NSM service template.

21 Failed to connect to database for an SQL parameter within aNSM service template.

22 It is not valid to have one parameter that requires an argumentwhich is another parameter that requires the first parameter asan argument. This is an example of an infinite loop and,therefore, the parameters cannot be calculated.

23 An error occurred when evaluating a parameter within a NSMservice template.

Chapter 8. Troubleshooting 125



24 The service instance was not found on the NCM system.

Note: The service instance may have been deleted by thescheduler based on the timeToDelete attribute used in the NSMservice template to create the service instance.

25 The work item was not found on the NCM system.

26 More than one device was found to match the device nameprovided.

27 An error occurred as the entity to be persisted already exists.

28 The supplied constant parameter (<constantParameter>), clientparameter (<clientParameter>), or client parameter list(<clientParameterList>) has no value.

29 The operation type specified in the NSM service template isinvalid.

30 The operation's (<operation>) parameter was not found in eitherthe global or local parameters for this NSM service template.

31 A duplicate rule was found in the NSM service template.

32 A NSM service template was defined without a rule of typeDeviceType (<rule type="DeviceType">).

33 An invalid device search direction was used when searching fordevices using the NSM REST API device URIs.

34 An invalid device search action was used when searching fordevices using the NSM REST API device URIs.

35 An error occurred during service execution when trying tocreate a service UOW on the NCM system.

36 An invalid date format was supplied to a command-line tool.Use date format YYYY-MM-DD.

37 An NSM internal error occurred. Monitor the Initelliden.logfor more information.

38 The operation order attribute (for example, <operationorder="1">) defined within a NSM service template cannotcontain a negative value.

39 The supplied XML failed validation against the NSM XMLschema definition.

40 The NSM REST API URI HTTP request was not valid.

41 The service instance cannot be deleted as the service status isnot SUCCESS.

42 The service instance does not exist on the NCM System.

43 There was no service operation found in the NSM servicetemplate during service execution.

44 The NSM service template contains a timeToDelete attribute (forexample, <serviceTemplate timeToDelete="5">), but the serviceinstance failed to be scheduled for deletion.

45 The NSM service template cannot be deleted as it is referencedas an applied NSM service template in an existing serviceinstance.

46 The received values for a client parameter list's order attribute(for example, <value order="1">) has not be populated correctly.




47 The received values for a client parameter list(<clientParameterList>) has a mismatch in the number ofvalues received for its constituent parameters.

48 Duplicate parameter names have been found in the NSM servicetemplate.

49 Neither a timeToDelete attribute (for example, <serviceTemplatename="FirewallCreateZones" timeToDelete="5">) or serviceoperation of type DELETE (for example, <serviceOperationname="deleteOperation" type="DELETE">) was found. Oneservice delete mechanism has to be supplied.

50 A timeToDelete attribute (for example, <serviceTemplatetimeToDelete="5">) and a service operation of type DELETE (forexample, <serviceOperation name="deleteOperation"type="DELETE">) was found in a NSM service template. Oneservice delete mechanism has to be supplied.

51 The service reference ID supplied in an NSM REST URI request(for example, POST http://www.example.com:7001/nsm/service/{"Doc56789}) already exists on the system.

52 An invalid NSM service template rule was found.

53 An SQL parameter is referenced in a service execution, but arequired database connection has not been found.

54 An invalid ruleProperty (for example, <rulePropertyname="VENOR" value="Cisco"/> ) has been found in the NSMservice template.

55 No manual updates to auto generated NSM service templatesare allowed.

56 General Validation error. The accompanying message providesmore detailed information.

57 A value for an optional element has been provided, but thatvalue was empty.

58 Invalid Service operation type was found.

59 Invalid operation rollback type was found

60 The service template was incorrectly configured for servicedeletion. The accompanying message provides more detailedinformation.

61 A service template id is required.

62 A service template name is required.

63 A device id is required for the service template.

64 A request was made to remove a service entry using the CLI butthe requested service was not in a valid state for removal.

Related tasks:“Submitting a NSM service template for execution” on page 21Related reference:“HTTP GET for /service” on page 98


Checking the NSM REST API installationTo verify that the NSM REST API is installed correctly, complete two checks:request the /realm URI using the GET method and verify that the NSM CLI tool isinstalled.

Procedure1. To request the /realm URI using the GET method, open a web browser.2. Enter the following command:

http://www.example.com:7001/nsm/realm/

where www.example.com is the server address of the Netcool ConfigurationManager presentation server. Confirm that a list of realms and informationabout them are returned.

Note: The credentials for an NSM client user are required for this procedure.The credentials for the NSM user are required for this procedure.

3. Verify that the NSM CLI tool is installed correctly. Change to the/opt/IBM/tivoli/netcool/ncm/bin/nsm directory. The nsmadmin.sh andcommons-logging.properties files must be in this directory.

4. Execute the nsmadmin.sh script as an NSM service designer user and verify thatit runs. The nsmadmin.sh script should print the help message.

Checking NSM when Netcool Configuration Manager RecoversUse this information to understand how NSM deals with services when theNetcool Configuration Manager is shutdown and then started up again to recoverfrom some system issues.

When Netcool Configuration Manager is shutdown, all active services are pausedat their current state. When Netcool Configuration Manager is started again, NSMmakes a best effort to recover and continue all services not yet completed atshutdown time.v Services that are currently executing, whether it is a create or delete action, will

continue as normal.v Services that have been submitted but have not yet started executing, whether it

is a create or delete action, will either begin execution as normal or will defaultto a failed status if NSM is unable to determine the service state. These failedservices will appear with a status of INDETERMINATE through the NSM REST APIbut will appear as a standard fail within the Netcool Configuration ManagerUser Interface. The resultant state can be investigated by using the NetcoolConfiguration Manager User Interface.

Checking the Intelliden.log fileUse the Intelliden.log file for detailed error messages.

The Intelliden.log file provides more detailed information on where the errororiginated. The default path for the Intelliden.log file is /opt/IBM/tivoli/netcool/ncm/logs.

The following is an example from an Intelliden.log file:2012/10/24,10:38:13.110,com.ibm.tivoli.itncm.logging.ItncmLogger,THR:121,ERROR,NotFoundException - NSM Error Code: 3 SERVICETEMPLATE_NOT_FOUNDcom.ibm.tivoli.nsm.web.exceptions.NotFoundException: Unable to find Service Template with ID :[2] for Device Id :401at com.ibm.tivoli.nsm.business.ServiceTemplateManagerImpl.getServiceTemplateByIdAndDeviceId(ServiceTemplateManagerImpl.java:185)


The following is another example from the Intelliden.log file. In this example, aservice instance ID of 3001 could not be deleted because this service has a status of90. The status number 90 has a meaning of Failed with indeterminate state forthe service.ERROR, NSMException - NSM Error Code: 41 SERVICE_INSTANCE_CANNOT_BE_DELETEcom.ibm.tivoli.nsm.web.exceptions.NSMException: Unable to delete service instance with an id of [3001]because its status is 90

Checking the nsmadmin.log fileUse the nsmadmin.log file for gathering extra information on the execution of thecommand-line tools.

The default path for the nsmadmin.log file is /opt/IBM/tivoli/netcool/ncm/bin/nsm.

The following example shows the output in the nsmadmin.log file from a failedexecution of the read command on a NSM service template ID of 101 that does notexist:INFO: Argument 1 is [command=read]Oct 24, 2012 1:41:10 PM com.ibm.tivoli.nsm.cli.NsmAdminCommandLineTool printArgumentsINFO: Argument 2 is [id=101]Oct 24, 2012 1:41:10 PM com.ibm.tivoli.nsm.cli.NsmAdminCommandLineTool printArgumentsINFO: Argument 3 is [filename=read.xml]Oct 24, 2012 1:41:10 PM com.ibm.tivoli.nsm.cli.NsmAdminCommandLineTool printArgumentsINFO: Argument 4 is [username]Oct 24, 2012 1:41:10 PM com.ibm.tivoli.nsm.cli.NsmAdminCommandLineTool printArgumentsINFO: Argument 5 is [password]Oct 24, 2012 1:41:10 PM com.ibm.tivoli.nsm.cli.NsmAdminCommandLineTool processCliRequestSEVERE: An error occurred in request processing, a HTTP Status Code of [404] with a Messageof [Not Found] was received. See the Intelliden.log for details.

Working with the database connection poolUse the database connection pool to adjust settings associated with serviceexecutions.

By default the database connection pool is configured with the following settings:nsm/jpa/minIdle=2nsm/jpa/maxIdle=8nsm/jpa/maxActive=10

These settings can be found in the rseries.properties file located in the/opt/IBM/tivoli/netcool/ncm/config/properties directory.

If you require a larger pool due to high levels of activity (that is, serviceexecutions) then it is recommended that you increase these values appropriately toimprove performance and responses from the system.

Note: A restart of Netcool Configuration Manager is required for any changesmade to these settings.


Appendix A. Sample XML responses for operation types

Sample XML responses for the EXTRACTION, DEVICESYNC, and COMMANDSET operationtypes are included.

Sample XML result content for the EXTRACTION operation type<serviceWorkItem workItemId="33" type="EXTRACTION"name="ITNCM/QA/" deviceId="2"><workItemResults><workItemResult><result>

/configuration/ip/host/ARG.001/text()Hostname</result></workItemResult></workItemResults><workItemLog>2012-07-27 14:12:45.985277 : Task Start Time: 2012/07/27 14:12:44.726 GMT+00:00*******************************************************Task: Work submitted by service UOW 31Device: emulcli4-17*******************************************************2012-07-27 14:12:50.57152 :Allocating 15MB of task memory (100% of the default task memory)...2012-07-27 14:12:50.57152 :>>> Operation Started on Worker Server ’taraz5’... (ApplyExtraction):2012/07/27 14:12:46.568 GMT+00:002012-07-27 14:12:50.57152 :Starting extraction 2012-07-27 14:12:50.57152 :Retrieved extraction and currentConfig2012-07-27 14:12:50.57152 : Result from extraction =/configuration/ip/host/ARG.001/text()Hostname2012-07-27 14:12:50.57152 :<<< Operation Finished in 1 seconds (ApplyExtraction): 2012/07/27 14:12:47.833 GMT+00:002012-07-27 14:12:50.57152Task End Time: 2012/07/27 14:12:48.254 GMT+00:00</workItemLog></serviceWorkItem>

Sample XML result content for the DEVICESYNC operation type<serviceWorkItem status="FINISHED_SUCCESS" workItemId="34" type="DEVICESYNC"name="DEVICESYNC" deviceId="2"><workItemResults><workItemResult/></workItemResults><workItemLog>2012-07-27 14:13:35.631763 : Task Start Time: 2012/07/27 14:13:35.333 GMT+00:00*******************************************************Task: Work submitted by service UOW 31Device: emulcli4-17*******************************************************2012-07-27 14:13:35.631763: Allocating 15MB of task memory (100% of the default task memory)2012-07-27 14:13:35.631763 : >>> Operation Started on Worker Server ’taraz5’...(constants): 2012/07/27 14:13:35.345 GMT+00:002012-07-27 14:13:35.631763 :<<< Operation Finished in 0 seconds (constants): 2012/07/27 14:13:35.345 GMT+00:002012-07-27 14:13:35.631763 : >>>Operation Started on Worker Server ’taraz5’...(getCurrent): 2012/07/27 14:13:35.345 GMT+00:002012-07-27 14:13:35.631763 :<<< Operation Finished in 0 seconds (getCurrent): 2012/07/27 14:13:35.351 GMT+00:002012-07-27 14:13:35.631763 : >>>Operation Started on Worker Server ’taraz5’... (radCheck): 2012/07/27 14:13:35.351 GMT+00:002012-07-27 14:13:35.631763 :<<< Operation Finished in 0 seconds (radCheck): 2012/07/27 14:13:35.393GMT+00:002012-07-27 14:13:35.631763 : >>> Operation Started on Worker Server ’taraz5’...(radCheckForImport): 2012/07/27 14:13:35.393 GMT+00:002012-07-27 14:13:35.631763 :<<< Operation Finished in 0 seconds (radCheckForImport): 2012/07/27 14:13:35.402GMT+00:002012-07-27 14:13:35.631763 : >>> Operation Started on Worker Server ’taraz5’... (getConfig): 2012/07/27 14:13:35.402 GMT+00:002012-07-27 14:13:35.631763 :Importing configuration for device 2012-07-27 14:13:35.631763 :WARNING : Using Loopback Comms Driver - device will not be accessed2012-07-27 14:13:35.631763: PreWrite requested : running config copied to startup config2012-07-27 14:13:35.631763: Configuration imported emulcli4-172012-07-27 14:13:35.631763 :Device info obtained for device2012-07-27 14:13:35.631763 : <<< Operation Finished in 0 seconds(getConfig): 2012/07/27 14:13:35.405 GMT+00:002012-07-27 14:13:35.631763 : >>>


Operation Started on Worker Server ’taraz5’...(modelConfig): 2012/07/27 14:13:35.405 GMT+00:002012-07-27 14:13:35.631763: Using driver: cisco_router_26xx_c2600-ik9o3s-m-12.2-21a_v16.03 (DIsd0000001666)2012-07-27 14:13:35.631763 : Allocating 114MB of driver memory(94MB for the schema and 20MB for the config)...2012-07-27 14:13:35.631763 : Converting CLI to XML2012-07-27 14:13:40.634778 :Number of processed lines 442Number successfully converted 442Number of rejected lines 0

Conversions breakdown:As modeled 441Via CLI_LINE 1

Rejections breakdown:Cause undetermined 0Parent was rejected 0Invalid indentation 0

Percent converted 100.00%2012-07-27 14:13:40.634778 : Conversion successful2012-07-27 14:13:40.634778 :<<< Operation Finished in 0 seconds (modelConfig): 2012/07/27 14:13:36.041 GMT+00:002012-07-27 14:13:40.634778 : >>>Operation Started on Worker Server ’taraz5’... (reconcileAfterSync): 2012/07/27 14:13:36.041 GMT+00:002012-07-27 14:13:40.634778 :<<< Operation Finished in 0 seconds (reconcileAfterSync): 2012/07/27 14:13:36.041 GMT+00:002012-07-27 14:13:40.634778 : >>>Operation Started on Worker Server ’taraz5’...(getPreviousAndCurrent): 2012/07/27 14:13:36.042 GMT+00:002012-07-27 14:13:40.634778 :<<< Operation Finished in 0 seconds (getPreviousAndCurrent): 2012/07/27 14:13:36.042 GMT+00:002012-07-27 14:13:40.634778 : >>>Operation Started on Worker Server ’taraz5’... (diffConfigs):2012/07/27 14:13:36.043 GMT+00:002012-07-27 14:13:40.634778 :Allocating 116MB of driver memory (94MB for the schema and 22MB for the config)...2012-07-27 14:13:40.634778 :Performing difference between two configurations2012-07-27 14:13:40.634778 :Getting keyed configuration2012-07-27 14:13:40.634778 :Keyed configuration got successfully2012-07-27 14:13:40.634778 :Getting keyed configuration2012-07-27 14:13:40.634778 :Keyed configuration got successfully2012-07-27 14:13:40.634778 :Diffing configurations successful2012-07-27 14:13:40.634778 :No Differences2012-07-27 14:13:40.634778 : <<< Operation Finished in 0 seconds (diffConfigs): 2012/07/27 14:13:36.681 GMT+00:002012-07-27 14:13:40.634778 : >>>Operation Started on Worker Server ’taraz5’... (storeConfig): 2012/07/27 14:13:36.682GMT+00:002012-07-27 14:13:40.634778 : <<< Operation Finished in 0 seconds (storeConfig): 2012/07/27 14:13:36.699 GMT+00:002012-07-27 14:13:40.634778 : >>>Operation Started on Worker Server ’taraz5’... (modelHardware): 2012/07/27 14:13:36.699GMT+00:002012-07-27 14:13:40.634778 : Model hardware info2012-07-27 14:13:40.634778: Model hardware info successful2012-07-27 14:13:40.634778 :Hardware inventory was modeled successfully2012-07-27 14:13:40.634778 :Comparing hardware inventory with current hardware inventory...2012-07-27 14:13:40.634778 : Model hardware info2012-07-27 14:13:40.634778 :Model hardware info successful2012-07-27 14:13:40.634778 :Hardware inventory is identical to current2012-07-27 14:13:40.634778 :<<< Operation Finished in 0 seconds (modelHardware): 2012/07/27 14:13:36.887GMT+00:002012-07-27 14:13:40.634778 : Task End Time: 2012/07/27 14:13:36.914 GMT+00:00</workItemLog></serviceWorkItem>

Sample XML result content for the COMMANDSET operation type<serviceWorkItem status="EXECUTING" workItemId="32" type="COMMANDSET"name="ITNCM/QA/QA_commandset_C105" deviceId="2"><workItemResults><workItemResult/>

</workItemResults><workItemLog>2012-07-27 14:12:50.57152 : Task Start Time: 2012/07/27 14:12:49.605 GMT+00:00*******************************************************Task: Work submitted by service UOW 31Device: emulcli4-17Command Set: QA_commandset_C105*******************************************************2012-07-27 14:12:50.57152 :Allocating 15MB of task memory (100% of the default task memory)...2012-07-27 14:12:50.57152 : >>> Operation Started on Worker Server ’taraz5’...(constants): 2012/07/27 14:12:49.709 GMT+00:002012-07-27 14:12:50.57152 :<<< Operation Finished in 0 seconds (constants): 2012/07/27 14:12:49.709GMT+00:002012-07-27 14:12:50.57152 : >>>Operation Started on Worker Server ’taraz5’...(checkCommandSet): 2012/07/27 14:12:49.709 GMT+00:002012-07-27 14:12:50.57152 :


<<< Operation Finished in 0 seconds (checkCommandSet): 2012/07/27 14:12:49.720GMT+00:002012-07-27 14:12:50.57152 : >>> Operation Started on Worker Server ’taraz5’...(radCheck1): 2012/07/27 14:12:49.721 GMT+00:002012-07-27 14:12:50.57152 :<<< Operation Finished in 0 seconds (radCheck1): 2012/07/27 14:12:49.900GMT+00:002012-07-27 14:12:50.57152 : >>>Operation Started on Worker Server ’taraz5’... (radCompareDeviceIntelliden):2012/07/27 14:12:49.901 GMT+00:002012-07-27 14:12:50.57152 :<<< Operation Finished in 0 seconds (radCompareDeviceIntelliden):2012/07/27 14:12:49.901 GMT+00:002012-07-27 14:12:50.57152 : >>>Operation Started on Worker Server ’taraz5’... (getRunningCompare):2012/07/27 14:12:49.902 GMT+00:002012-07-27 14:12:50.57152 :Importing configuration for device 2012-07-27 14:12:50.57152 : WARNING :Using Loopback Comms Driver - device will not be accessed2012-07-27 14:12:50.57152 :Configuration imported emulcli4-172012-07-27 14:12:50.57152 :Device info obtained for device2012-07-27 14:12:50.57152 :<<< Operation Finished in 0 seconds (getRunningCompare):2012/07/27 14:12:50.048 GMT+00:002012-07-27 14:12:50.57152 : >>>Operation Started on Worker Server ’taraz5’... (radNativeCompareCurrentRunning):2012/07/27 14:12:50.048 GMT+00:002012-07-27 14:12:50.57152 :<<< Operation Finished in 0 seconds (radNativeCompareCurrentRunning):2012/07/27 14:12:50.048 GMT+00:002012-07-27 14:12:50.57152 : >>>Operation Started on Worker Server ’taraz5’... (convertRunningToXml2):2012/07/27 14:12:50.049 GMT+00:002012-07-27 14:12:55.585273 :Using driver: cisco_router_26xx_c2600-ik9o3s-m-12.2-21a_v16.03(DIsd0000001666) 2012-07-27 14:12:55.585273 :Allocating 114MB of driver memory (94MB for the schema and 20MB for the config)...2012-07-27 14:12:55.585273 : Converting CLI to XML2012-07-27 14:13:20.62344 :Number of processed lines 442Number successfully converted 442Number of rejected lines 0



Percent converted 100.00%2012-07-27 14:13:20.62344 : Conversion successful2012-07-27 14:13:20.62344 :<<< Operation Finished in 29 seconds (convertRunningToXml2):2012/07/27 14:13:19.832 GMT+00:002012-07-27 14:13:20.62344 : >>>Operation Started on Worker Server ’taraz5’...(getCurrentAndRunning): 2012/07/27 14:13:19.832GMT+00:002012-07-27 14:13:20.62344 :<<< Operation Finished in 0 seconds (getCurrentAndRunning):2012/07/27 14:13:19.848 GMT+00:002012-07-27 14:13:20.62344 : >>>Operation Started on Worker Server ’taraz5’...(diffRunningAndCurrent): 2012/07/27 14:13:19.849 GMT+00:002012-07-27 14:13:20.62344 :Allocating 116MB of driver memory (94MB for the schema and 22MB for the config)...2012-07-27 14:13:20.62344 :Performing difference between two configurations2012-07-27 14:13:20.62344 :Getting keyed configuration2012-07-27 14:13:25.623274 :Keyed configuration got successfully2012-07-27 14:13:25.623274 :Getting keyed configuration2012-07-27 14:13:25.623274 :Keyed configuration got successfully2012-07-27 14:13:30.633226 :Diffing configurations successful2012-07-27 14:13:30.633226 :<<< Operation Finished in 6 seconds (diffRunningAndCurrent):2012/07/27 14:13:26.156 GMT+00:002012-07-27 14:13:30.633226 : >>>Operation Started on Worker Server ’taraz5’... (applyNativeCommandSet):2012/07/27 14:13:26.256 GMT+00:002012-07-27 14:13:30.633226 :WARNING : Using Loopback Comms Driver -device will not be accessed2012-07-27 14:13:30.633226 : Apply mode:Configuration Change2012-07-27 14:13:30.633226 :Config applied to device2012-07-27 14:13:30.633226 :<<< Operation Finished in 0 seconds (applyNativeCommandSet):2012/07/27 14:13:26.301 GMT+00:002012-07-27 14:13:30.633226 : >>>Operation Started on Worker Server ’taraz5’... (CheckNCSResult):2012/07/27 14:13:26.302 GMT+00:002012-07-27 14:13:30.633226 :<<< Operation Finished in 0 seconds (CheckNCSResult):2012/07/27 14:13:26.302 GMT+00:002012-07-27 14:13:30.633226 : >>>Operation Started on Worker Server ’taraz5’...(radImportConfigAfterApply): 2012/07/27 14:13:26.303 GMT+00:002012-07-27 14:13:30.633226 :<<< Operation Finished in 0 seconds (radImportConfigAfterApply):2012/07/27 14:13:26.303 GMT+00:002012-07-27 14:13:30.633226 : >>>Operation Started on Worker Server ’taraz5’... (getConfig):2012/07/27 14:13:26.303 GMT+00:002012-07-27 14:13:30.633226 :Importing configuration for device 2012-07-27 14:13:30.633226 :

Appendix A. Sample XML responses for operation types 133

WARNING : Using Loopback Comms Driver- device will not be accessed2012-07-27 14:13:30.633226 :Configuration imported emulcli4-172012-07-27 14:13:30.633226 :<<< Operation Finished in 0 seconds (getConfig):2012/07/27 14:13:26.633 GMT+00:002012-07-27 14:13:30.633226 : >>>Operation Started on Worker Server ’taraz5’... (modelConfig):2012/07/27 14:13:26.634 GMT+00:002012-07-27 14:13:30.633226 :Allocating 114MB of driver memory (94MB for the schema and 20MB for the config)...2012-07-27 14:13:30.633226 : Converting CLI to XML2012-07-27 14:13:30.633226 :Number of processed lines 442Number successfully converted 442Number of rejected lines 0



Percent converted 100.00%2012-07-27 14:13:30.633226 : Conversion successful2012-07-27 14:13:30.633226 :Imported configuration marked as current for device2012-07-27 14:13:30.633226 :<<< Operation Finished in 3 seconds (modelConfig): 2012/07/27 14:13:30.330GMT+00:002012-07-27 14:13:30.633226 : >>> Operation Started on Worker Server ’taraz5’...(writeVerifiedChanges): 2012/07/27 14:13:30.330 GMT+00:002012-07-27 14:13:30.633226 :<<< Operation Finished in 0 seconds (writeVerifiedChanges): 2012/07/27 14:13:30.330GMT+00:002012-07-27 14:13:30.633226 : >>> Operation Started on Worker Server ’taraz5’...(reconcileAfterImport): 2012/07/27 14:13:30.331 GMT+00:002012-07-27 14:13:30.633226 :<<< Operation Finished in 0 seconds (reconcileAfterImport): 2012/07/27 14:13:30.331GMT+00:002012-07-27 14:13:30.633226 : >>> Operation Started on Worker Server ’taraz5’...(radImportInfoAfterApply): 2012/07/27 14:13:30.331 GMT+00:002012-07-27 14:13:30.633226 :<<< Operation Finished in 0 seconds (radImportInfoAfterApply): 2012/07/27 14:13:30.331GMT+00:002012-07-27 14:13:30.633226 : >>> Operation Started on Worker Server ’taraz5’...(getInfo): 2012/07/27 14:13:30.332 GMT+00:002012-07-27 14:13:30.633226 : WARNING :Using Loopback Comms Driver - device will not be accessed2012-07-27 14:13:30.633226 :Device info obtained for device2012-07-27 14:13:30.633226 :<<< Operation Finished in 0 seconds (getInfo): 2012/07/27 14:13:30.514GMT+00:002012-07-27 14:13:30.633226 : >>> Operation Started on Worker Server ’taraz5’...(modelHardware): 2012/07/27 14:13:30.515 GMT+00:002012-07-27 14:13:30.633226 :Model hardware info2012-07-27 14:13:35.631763 :Model hardware info successful2012-07-27 14:13:35.631763 :Hardware inventory was modeled successfully2012-07-27 14:13:35.631763 :modeled hardware inventory was written to the database2012-07-27 14:13:35.631763 :<<< Operation Finished in 0 seconds (modelHardware):2012/07/27 14:13:31.130 GMT+00:002012-07-27 14:13:35.631763 :Task End Time: 2012/07/27 14:13:31.149 GMT+00:00</workItemLog></serviceWorkItem>

Related tasks:“Submitting a NSM service template for execution” on page 21Related reference:“HTTP GET for /service/{service-id}/workitem/{workitem-id}” on page 108


Appendix B. XSD files

The following XSD files are provided: common.xsd, clientservicetemplate.xsd,servicetemplate.xsd, device.xsd, realm.xsd, and service.xsd.

Common XSD file: common.xsd<?xml version="1.0" encoding="utf-8"?><xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">

<xs:simpleType name="StringNotBlank"><xs:restriction base="xs:string"><xs:minLength value="1" /><xs:pattern value=".*[^\s].*" />

</xs:restriction></xs:simpleType>

</xs:schema>

Client Service Template XSD file: clientservicetemplate.xsd

The following shows the clientservicetemplate.xsd file:<?xml version="1.0" encoding="utf-8"?><xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"><xs:include schemaLocation="./common.xsd"/><xs:element name="serviceTemplates" type="serviceTemplatesListType"/><xs:complexType name="serviceTemplatesListType"><xs:sequence><xs:element name="serviceTemplate" type="serviceTemplateType" minOccurs="1" maxOccurs="unbounded"/>

</xs:sequence></xs:complexType><xs:element name="serviceTemplate" type="serviceTemplateType" /><xs:complexType name="serviceTemplateType"><xs:sequence><xs:element name="deviceID" type="StringNotBlank" minOccurs="0" maxOccurs="1" /><xs:element name="clientParameters" type="clientParametersType" minOccurs="0" maxOccurs="1" /><xs:element name="clientParameterLists" type="clientParameterListsType" minOccurs="0" maxOccurs="1" />

</xs:sequence><xs:attribute name="id" type="StringNotBlank" use="required"/><xs:attribute name="name" type="StringNotBlank" use="optional"/><xs:attribute name="description" type="xs:string" use="optional"/>

</xs:complexType><xs:complexType name="clientParametersType"><xs:sequence><xs:element name="clientParameter" type="clientParameterType" minOccurs="0" maxOccurs="unbounded" />

</xs:sequence></xs:complexType><xs:complexType name="clientParameterType"><xs:sequence><xs:element name="name" type="StringNotBlank" minOccurs="1" maxOccurs="1" /><xs:element name="value" type="xs:string" minOccurs="0" maxOccurs="1"/><xs:element name="description" type="xs:string" minOccurs="0" maxOccurs="1"/>

</xs:sequence></xs:complexType><xs:complexType name="clientParameterListsType">

<xs:sequence><xs:element name="clientParameterList" type="clientParameterListType" minOccurs="1" maxOccurs="unbounded" />

</xs:sequence></xs:complexType><xs:complexType name="clientParameterListType">

<xs:sequence><xs:element name="parameter" type="clientParameterListParameterType" minOccurs="1" maxOccurs="unbounded" />

</xs:sequence><xs:attribute name="name" type="StringNotBlank" use="required"/><xs:attribute name="description" type="StringNotBlank" use="optional"/>

</xs:complexType><xs:complexType name="clientParameterListParameterType">

<xs:all><xs:element name="values" type="clientParameterListParameterValueType" minOccurs="1" maxOccurs="1" />

</xs:all><xs:attribute name="name" type="StringNotBlank" use="required"/><xs:attribute name="description" type="StringNotBlank" use="optional"/>

</xs:complexType>

<xs:complexType name="clientParameterListParameterValueType"><xs:sequence><xs:element name="value" type="clientParameterListParameterValueElementType" minOccurs="1" maxOccurs="unbounded" />

</xs:sequence></xs:complexType>

<xs:complexType name="clientParameterListParameterValueElementType"><xs:simpleContent>

<xs:extension base="StringNotBlank"><xs:attribute name="order" type="StringNotBlank" use="optional"/></xs:extension>

</xs:simpleContent></xs:complexType>

</xs:schema>

NSM service template XSD file: servicetemplate.xsd

The following shows the servicetemplate.xsd file:<?xml version="1.0" encoding="utf-8"?><xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"><xs:include schemaLocation="./common.xsd"/><xs:element name="serviceTemplates" type="serviceTemplatesListType"/><xs:complexType name="serviceTemplatesListType">

<xs:sequence><xs:element name="serviceTemplate" type="serviceTemplateType" minOccurs="1" maxOccurs="unbounded"/>

</xs:sequence></xs:complexType><xs:element name="serviceTemplate" type="serviceTemplateType" /><xs:complexType name="serviceTemplateType">

<xs:all><xs:element name="deviceName" type="StringNotBlank" minOccurs="0" maxOccurs="1" /><xs:element name="deviceID" type="StringNotBlank" minOccurs="0" maxOccurs="1" /><xs:element name="implementations" type="implementationsType" minOccurs="1" maxOccurs="1" /><xs:element name="constantParameters" type="constantParametersType" minOccurs="0" maxOccurs="1" /><xs:element name="clientParameters" type="clientParametersType" minOccurs="0" maxOccurs="1" /><xs:element name="injectParameters" type="injectParametersType" minOccurs="0" maxOccurs="1" /><xs:element name="sqlParameters" type="sqlParametersType" minOccurs="0" maxOccurs="1" /><xs:element name="httpParameters" type="httpParametersType" minOccurs="0" maxOccurs="1" /><xs:element name="clientParameterLists" type="clientParameterListsType" minOccurs="0" maxOccurs="1" />

</xs:all><xs:attribute name="name" type="StringNotBlank" use="required"/><xs:attribute name="id" type="StringNotBlank" use="optional"/><xs:attribute name="version" type="StringNotBlank" use="optional"/><xs:attribute name="description" type="xs:string" use="optional"/><xs:attribute name="createdBy" type="StringNotBlank" use="optional"/><xs:attribute name="createDate" type="StringNotBlank" use="optional"/><xs:attribute name="timeToDelete" type="xs:positiveInteger" use="optional"/>

</xs:complexType><xs:complexType name="implementationsType">

<xs:sequence><xs:element name="implementation" type="implementationType" minOccurs="1" maxOccurs="unbounded" />

</xs:sequence></xs:complexType><xs:complexType name="implementationType">

<xs:all><xs:element name="databaseConnection" type="databaseConnectionType" minOccurs="0" maxOccurs="1" /><xs:element name="serviceOperations" type="serviceOperationsType" minOccurs="1" maxOccurs="1"/><xs:element name="constantParameters" type="constantParametersType" minOccurs="0" maxOccurs="1" /><xs:element name="clientParameters" type="clientParametersType" minOccurs="0" maxOccurs="1" /><xs:element name="injectParameters" type="injectParametersType" minOccurs="0" maxOccurs="1" /><xs:element name="sqlParameters" type="sqlParametersType" minOccurs="0" maxOccurs="1" /><xs:element name="httpParameters" type="httpParametersType" minOccurs="0" maxOccurs="1" /><xs:element name="rules" type="rulesType" minOccurs="1" maxOccurs="1"/><xs:element name="clientParameterLists" type="clientParameterListsType" minOccurs="0" maxOccurs="1" />

</xs:all><xs:attribute name="id" type="StringNotBlank" use="optional"/><xs:attribute name="description" type="xs:string" use="optional"/><xs:attribute name="version" type="StringNotBlank" use="optional"/><xs:attribute name="type" type="StringNotBlank" use="optional"/>

</xs:complexType><xs:complexType name="databaseConnectionType">

<xs:all><xs:element name="driverClassName" type="StringNotBlank" minOccurs="1" maxOccurs="1" /><xs:element name="url" type="StringNotBlank" minOccurs="1" maxOccurs="1"/><xs:element name="username" type="xs:string" minOccurs="1" maxOccurs="1"/><xs:element name="password" type="xs:string" minOccurs="1" maxOccurs="1"/><xs:element name="description" type="xs:string" minOccurs="0" maxOccurs="1" />

</xs:all></xs:complexType><xs:complexType name="rulesType">

<xs:sequence><xs:element name="rule" type="ruleType" minOccurs="1" maxOccurs="unbounded"/>

</xs:sequence><xs:attribute name="description" type="xs:string" use="optional"/>

</xs:complexType><xs:complexType name="ruleType">

<xs:sequence><xs:element name="ruleProperty" type="rulePropertyType" minOccurs="1" maxOccurs="unbounded"/>

</xs:sequence><xs:attribute name="type" type="StringNotBlank" use="required"/><xs:attribute name="description" type="xs:string" use="optional"/>

</xs:complexType><xs:complexType name="rulePropertyType"><xs:attribute name="name" type="StringNotBlank" use="required"/><xs:attribute name="value" type="StringNotBlank" use="required"/>

</xs:complexType><xs:complexType name="operationsType">

<xs:sequence><xs:element name="operation" type="operationType" minOccurs="1" maxOccurs="unbounded" />

</xs:sequence></xs:complexType><xs:complexType name="serviceOperationsType"><xs:sequence>

<xs:element name="serviceOperation" type="serviceOperationType" minOccurs="1" maxOccurs="unbounded" /></xs:sequence>

</xs:complexType><xs:complexType name="serviceOperationType">

<xs:sequence><xs:element name="operations" type="operationsType" minOccurs="1" maxOccurs="1" />

</xs:sequence><xs:attribute name="name" type="xs:string" use="optional"/><xs:attribute name="type" type="allowedServiceOperationTypeValues" use="required"/>

</xs:complexType><xs:complexType name="operationType">

<xs:sequence><xs:element name="parameters" type="operationParametersType" minOccurs="0" maxOccurs="unbounded"/>

</xs:sequence><xs:attribute name="name" type="StringNotBlank" use="required"/>


<xs:attribute name="type" type="allowedOperationTypeValues" use="required"/><xs:attribute name="rollback" type="allowedOperationRollbackTypeValues" use="optional"/><xs:attribute name="order" type="StringNotBlank" use="optional"/><xs:attribute name="description" type="xs:string" use="optional"/>

</xs:complexType><xs:complexType name="operationParametersType">

<xs:sequence><xs:element name="parameter" type="operationParameterType" minOccurs="0" maxOccurs="unbounded" />

</xs:sequence></xs:complexType><xs:complexType name="operationParameterType"><xs:attribute name="name" type="StringNotBlank" use="required"/>

</xs:complexType><xs:complexType name="constantParametersType">

<xs:sequence><xs:element name="constantParameter" type="constantParameterType" minOccurs="0" maxOccurs="unbounded" />

</xs:sequence></xs:complexType><xs:complexType name="clientParametersType">

<xs:sequence><xs:element name="clientParameter" type="clientParameterType" minOccurs="0" maxOccurs="unbounded" />

</xs:sequence></xs:complexType><xs:complexType name="injectParametersType">

<xs:sequence><xs:element name="injectParameter" type="injectParameterType" minOccurs="0" maxOccurs="unbounded" />

</xs:sequence></xs:complexType><xs:complexType name="sqlParametersType">

<xs:sequence><xs:element name="sqlParameter" type="sqlParameterType" minOccurs="0" maxOccurs="unbounded" />

</xs:sequence></xs:complexType><xs:complexType name="httpParametersType"><xs:sequence>

<xs:element name="httpParameter" type="httpParameterType" minOccurs="0" maxOccurs="unbounded" /></xs:sequence>

</xs:complexType>

<xs:complexType name="clientParameterListsType"><xs:sequence>

<xs:element name="clientParameterList" type="clientParameterListType" minOccurs="1" maxOccurs="unbounded" /></xs:sequence>

</xs:complexType>

<xs:complexType name="constantParameterType"><xs:all>

<xs:element name="name" type="StringNotBlank" minOccurs="1" maxOccurs="1" /><xs:element name="value" type="StringNotBlank" minOccurs="1" maxOccurs="1"/><xs:element name="description" type="xs:string" minOccurs="0" maxOccurs="1"/>

</xs:all></xs:complexType><xs:complexType name="clientParameterType"><xs:all>

<xs:element name="name" type="StringNotBlank" minOccurs="1" maxOccurs="1" /><xs:element name="value" type="xs:string" minOccurs="0" maxOccurs="1"/><xs:element name="description" type="xs:string" minOccurs="0" maxOccurs="1"/>

</xs:all></xs:complexType><xs:complexType name="injectParameterType">

<xs:all><xs:element name="name" type="StringNotBlank" minOccurs="1" maxOccurs="1" /><xs:element name="methodCall" type="xs:string" minOccurs="0" maxOccurs="1"/><xs:element name="arguments" type="xs:string" minOccurs="0" maxOccurs="1"/><xs:element name="code" type="xs:string" minOccurs="0" maxOccurs="1"/><xs:element name="description" type="xs:string" minOccurs="0" maxOccurs="1"/>

</xs:all></xs:complexType><xs:complexType name="sqlParameterType">

<xs:all><xs:element name="name" type="StringNotBlank" minOccurs="1" maxOccurs="1" /><xs:element name="description" type="StringNotBlank" minOccurs="0" maxOccurs="1"/><xs:element name="value" type="StringNotBlank" minOccurs="0" maxOccurs="1"/><xs:element name="sql" type="StringNotBlank" minOccurs="1" maxOccurs="1"/><xs:element name="arguments" type="StringNotBlank" minOccurs="0" maxOccurs="1"/>

</xs:all></xs:complexType><xs:complexType name="httpParameterType"><xs:all>

<xs:element name="name" type="StringNotBlank" minOccurs="1" maxOccurs="1" /><xs:element name="description" type="StringNotBlank" minOccurs="0" maxOccurs="1"/><xs:element name="value" type="StringNotBlank" minOccurs="0" maxOccurs="1"/><xs:element name="url" type="StringNotBlank" minOccurs="1" maxOccurs="1"/><xs:element name="arguments" type="StringNotBlank" minOccurs="0" maxOccurs="1"/>

</xs:all></xs:complexType>

<xs:complexType name="clientParameterListType"><xs:sequence><xs:element name="parameter" type="clientParameterListParameterType" minOccurs="1" maxOccurs="unbounded" />

</xs:sequence><xs:attribute name="name" type="StringNotBlank" use="required"/><xs:attribute name="description" type="StringNotBlank" use="optional"/>

</xs:complexType>

<xs:complexType name="clientParameterListParameterType"><xs:all>

<xs:element name="values" type="clientParameterListParameterValueType" minOccurs="0" maxOccurs="1" /></xs:all><xs:attribute name="name" type="StringNotBlank" use="required"/><xs:attribute name="description" type="StringNotBlank" use="optional"/>

</xs:complexType>

<xs:complexType name="clientParameterListParameterValueType"><xs:sequence><xs:element name="value" type="clientParameterListParameterValueElementType" minOccurs="0" maxOccurs="unbounded" />

Appendix B. XSD files 137

</xs:sequence></xs:complexType>

<xs:complexType name="clientParameterListParameterValueElementType"><xs:simpleContent>

<xs:extension base="StringNotBlank"><xs:attribute name="order" type="StringNotBlank" use="optional"/></xs:extension>

</xs:simpleContent></xs:complexType>

<xs:simpleType name="allowedOperationTypeValues"><xs:restriction base="xs:string"><xs:enumeration value="EXTRACTION"/><xs:enumeration value="DEVICESYNC"/><xs:enumeration value="COMMANDSET"/>

</xs:restriction></xs:simpleType><xs:simpleType name="allowedOperationRollbackTypeValues"><xs:restriction base="xs:string"><xs:enumeration value="true"/><xs:enumeration value="TRUE"/><xs:enumeration value="false"/><xs:enumeration value="FALSE"/>

</xs:restriction></xs:simpleType><xs:simpleType name="allowedServiceOperationTypeValues"><xs:restriction base="xs:string"><xs:enumeration value="CREATE"/><xs:enumeration value="DELETE"/>

</xs:restriction></xs:simpleType>

</xs:schema>

Device XSD file: device.xsd<?xml version="1.0" encoding="utf-8"?><xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"><xs:include schemaLocation="./common.xsd"/><xs:element name="devices" type="deviceListType"/><xs:element name="device" type="deviceType"/><xs:complexType name="deviceListType"><xs:sequence><xs:element name="device" type="deviceType" minOccurs="1" maxOccurs="unbounded"/>

</xs:sequence></xs:complexType><xs:complexType name="deviceType"><xs:all><xs:element name="id" type="StringNotBlank" minOccurs="1" maxOccurs="1"/><xs:element name="name" type="StringNotBlank" minOccurs="0" maxOccurs="1"/><xs:element name="fqName" type="StringNotBlank" minOccurs="0" maxOccurs="1"/><xs:element name="vendor" type="StringNotBlank" minOccurs="0" maxOccurs="1"/><xs:element name="type" type="StringNotBlank" minOccurs="0" maxOccurs="1"/><xs:element name="model" type="StringNotBlank" minOccurs="0" maxOccurs="1"/><xs:element name="os" type="StringNotBlank" minOccurs="0" maxOccurs="1"/><xs:element name="parentId" type="StringNotBlank" minOccurs="0" maxOccurs="1"/><xs:element name="parentName" type="StringNotBlank" minOccurs="0" maxOccurs="1"/><xs:element name="currentNativeConfiguration" type="StringNotBlank" minOccurs="0" maxOccurs="1"/><xs:element name="currentModeledConfiguration" type="StringNotBlank" minOccurs="0" maxOccurs="1"/><xs:element name="currentSupplementalInformation" type="StringNotBlank" minOccurs="0" maxOccurs="1"/><xs:element name="deviceLoginOverride" type="StringNotBlank" minOccurs="0" maxOccurs="1"/><xs:element name="overrideDeviceLoginName" type="StringNotBlank" minOccurs="0" maxOccurs="1"/><xs:element name="overrideDevicePassword" type="StringNotBlank" minOccurs="0" maxOccurs="1"/><xs:element name="createdDate" type="StringNotBlank" minOccurs="0" maxOccurs="1"/><xs:element name="createdBy" type="StringNotBlank" minOccurs="0" maxOccurs="1"/><xs:element name="lastModifiedDate" type="StringNotBlank" minOccurs="0" maxOccurs="1"/><xs:element name="lastModifiedBy" type="StringNotBlank" minOccurs="0" maxOccurs="1"/><xs:element name="status" type="StringNotBlank" minOccurs="0" maxOccurs="1"/><xs:element name="currentDriver" type="StringNotBlank" minOccurs="0" maxOccurs="1"/><xs:element name="driverStatus" type="StringNotBlank" minOccurs="0" maxOccurs="1"/><xs:element name="driverType" type="StringNotBlank" minOccurs="0" maxOccurs="1"/><xs:element name="label1" type="StringNotBlank" minOccurs="0" maxOccurs="1"/><xs:element name="label2" type="StringNotBlank" minOccurs="0" maxOccurs="1"/><xs:element name="label3" type="StringNotBlank" minOccurs="0" maxOccurs="1"/><xs:element name="label4" type="StringNotBlank" minOccurs="0" maxOccurs="1"/><xs:element name="label5" type="StringNotBlank" minOccurs="0" maxOccurs="1"/><xs:element name="label6" type="StringNotBlank" minOccurs="0" maxOccurs="1"/><xs:element name="label7" type="StringNotBlank" minOccurs="0" maxOccurs="1"/><xs:element name="label8" type="StringNotBlank" minOccurs="0" maxOccurs="1"/><xs:element name="label9" type="StringNotBlank" minOccurs="0" maxOccurs="1"/><xs:element name="label10" type="StringNotBlank" minOccurs="0" maxOccurs="1"/><xs:element name="supportLevel" type="StringNotBlank" minOccurs="0" maxOccurs="1"/>


</xs:schema>

Realm XSD file: realm.xsd<?xml version="1.0" encoding="utf-8"?><xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"><xs:include schemaLocation="./common.xsd"/><xs:element name="realms" type="realmListType"/><xs:element name="realm" type="realmType"/><xs:complexType name="realmListType"><xs:sequence><xs:element name="realm" type="realmType" minOccurs="1" maxOccurs="unbounded"/>

</xs:sequence></xs:complexType><xs:complexType name="realmType"><xs:all><xs:element name="id" type="StringNotBlank" minOccurs="1" maxOccurs="1"/><xs:element name="name" type="StringNotBlank" minOccurs="1" maxOccurs="1"/><xs:element name="fqName" type="StringNotBlank" minOccurs="1" maxOccurs="1"/>


<xs:element name="parentId" type="StringNotBlank" minOccurs="1" maxOccurs="1"/><xs:element name="parentName" type="StringNotBlank" minOccurs="0" maxOccurs="1"/>


</xs:schema>

Service XSD file: service.xsd<?xml version="1.0" encoding="utf-8"?><xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"><xs:include schemaLocation="./common.xsd"/><xs:element name="serviceWorkItems" type="serviceWorkItemListType"/><xs:element name="services" type="serviceListType"/><xs:element name="service" type="serviceType"/><xs:element name="workItem" type="serviceWorkItemType"/><xs:element name="string" type="serviceInputType"/><xs:complexType name="serviceListType"><xs:sequence><xs:element name="service" type="serviceType" minOccurs="1" maxOccurs="unbounded"/>

</xs:sequence></xs:complexType><xs:complexType name="serviceWorkItemListType"><xs:sequence><xs:element name="workItem" type="serviceWorkItemType" minOccurs="1" maxOccurs="unbounded"/>

</xs:sequence></xs:complexType><xs:complexType name="serviceType"><xs:all><xs:element name="status" type="StringNotBlank" minOccurs="1" maxOccurs="1"/><xs:element name="devices" type="serviceDevicesType" minOccurs="1" maxOccurs="1"/><xs:element name="appliedServiceTemplates" type="appliedServiceTemplatesType" minOccurs="1" maxOccurs="1" /><xs:element name="serviceWorkItems" type="serviceWorkItemsType" minOccurs="0" maxOccurs="1" />

</xs:all><xs:attribute name="id" type="StringNotBlank" use="required"/><xs:attribute name="serviceWorkKey" type="StringNotBlank" use="optional"/><xs:attribute name="referenceId" type="StringNotBlank" use="optional"/><xs:attribute name="description" type="xs:string" use="optional"/><xs:attribute name="createdByUser" type="StringNotBlank" use="optional"/><xs:attribute name="createDate" type="StringNotBlank" use="optional"/><xs:attribute name="lastUpdatedDate" type="StringNotBlank" use="optional"/>

</xs:complexType><xs:complexType name="serviceDevicesType"><xs:sequence><xs:element name="device" type="serviceDeviceType" minOccurs="0" maxOccurs="unbounded"/>

</xs:sequence></xs:complexType><xs:complexType name="serviceInputType"><xs:sequence><xs:any namespace="##any" processContents="skip" minOccurs="0" maxOccurs="unbounded"/>

</xs:sequence></xs:complexType><xs:complexType name="serviceDeviceType"><xs:all><xs:element name="id" type="StringNotBlank" minOccurs="1" maxOccurs="1"/>

</xs:all></xs:complexType><xs:complexType name="serviceWorkItemsType"><xs:sequence><xs:element name="workItem" type="serviceWorkItemType" minOccurs="0" maxOccurs="unbounded"/>

</xs:sequence></xs:complexType><xs:complexType name="serviceWorkItemType"><xs:all><xs:element name="workItemResults" type="workItemResultsType" minOccurs="0" maxOccurs="1"/><xs:element name="workItemLog" type="workItemLogType" minOccurs="0" maxOccurs="1"/>

</xs:all><xs:attribute name="id" type="StringNotBlank" use="required"/><xs:attribute name="deviceId" type="StringNotBlank" use="required"/><xs:attribute name="description" type="xs:string" use="optional"/><xs:attribute name="status" type="StringNotBlank" use="optional"/><xs:attribute name="type" type="StringNotBlank" use="optional"/><xs:attribute name="name" type="StringNotBlank" use="optional"/>

</xs:complexType><xs:complexType name="workItemResultsType"><xs:sequence><xs:element name="workItemResult" type="workItemResultType" minOccurs="0" maxOccurs="unbounded"/>

</xs:sequence></xs:complexType><xs:complexType name="workItemResultType"><xs:sequence><xs:element name="result" type="StringNotBlank" minOccurs="0" maxOccurs="unbounded"/>

</xs:sequence></xs:complexType><xs:complexType name="workItemLogType"><xs:sequence><xs:element name="log" type="StringNotBlank" minOccurs="0" maxOccurs="1"/>

</xs:sequence></xs:complexType><xs:complexType name="appliedServiceTemplatesType"><xs:sequence><xs:element name="serviceTemplate" type="appliedServiceTemplateType" minOccurs="0" maxOccurs="unbounded"/>

</xs:sequence></xs:complexType><xs:complexType name="appliedServiceTemplateType"><xs:sequence><xs: element name="deviceID" type="StringNotBlank" minOccurs="0" maxOccurs="1"/>

</xs:sequence><xs:attribute name="id" type="StringNotBlank" use="required"/><xs:attribute name="version" type="StringNotBlank" use="required"/>

</xs:complexType></xs:schema>

Appendix B. XSD files 139

Appendix C. Example NSM service templates

NSM service designers can use the following example NSM service templates asmodels for creating their own NSM service templates.

Example NSM service template for a VLAN service

The following example NSM service template manages VLAN routing on a CISCOrouter.<serviceTemplate name="VLAN Routing" description="Create VLAN and add Vlan Routing for a Cisco Router">

<clientParameters><clientParameter><name>VLAN_NUMBER</name><description>The VLAN number to create</description>

</clientParameter><clientParameter><name>ACCESS_VLAN_IP</name><description>The Access IP address for the new VLAN</description>

</clientParameter><clientParameter><name>SVI_IP</name><description>The Switch Virtual Interface IP</description>

</clientParameter><clientParameter><name>SVI_SUBNET</name><description>The Switch Virtual Interface IP’s sub Network</description>


<implementations><implementation description="Implementation Rule which covers all Cisco Routers">

<rules><rule type="DeviceType"><ruleProperty name="Vendor" value="Cisco"/><ruleProperty name="Type" value="Router"/><ruleProperty name="Model" value=".*"/><ruleProperty name="OS" value=".*"/>

</rule></rules>

<serviceOperations><serviceOperation type="CREATE"><operations><operation name="ITNCM/ADD_VLAN_ACCESS_PORT" type="COMMANDSET" order="1"><parameters><parameter name="VLAN_NUMBER"/><parameter name="ACCESS_VLAN_IP"/>

</parameters></operation><operation name="ITNCM/ADD_VLAN_ROUTING" type="COMMANDSET" order="2"><parameters><parameter name="VLAN_NUMBER"/><parameter name="SVI_IP"/><parameter name="SVI_SUBNET"/>

</parameters></operation>

</operations></serviceOperation><serviceOperation type="DELETE"><operations><operation name="ITNCM/REMOVE_VLAN_ACCESS_PORT" type="COMMANDSET" order="1"><parameters><parameter name="VLAN_NUMBER"/>

</parameters></operation><operation name="ITNCM/REMOVE_VLAN_ROUTING" type="COMMANDSET" order="2"><parameters><parameter name="VLAN_NUMBER"/><parameter name="SVI_SUBNET"/>

</parameters></operation>

</operations></serviceOperation>

</serviceOperations>

</implementation></implementations>

</serviceTemplate>

The following example shows the corresponding VLAN native command set forthe NSM service template that manages VLAN routing on a CISCO router.


FileType=NativeCommandSetName=ADD_VLAN_ACCESS_PORTVendor=CiscoType=RouterModel=*Os=*CommandType=Configuration ChangeLineByLine=trueStopOnError=trueString=exit

vlan databasevlan $VLAN_NUMBER$exitconfig terminterface FastEthernet0/13description New Hostno shutdownswitchport access vlan $VLAN_NUMBER$no ip addressspanning-tree portfast

!interface Vlan$VLAN_NUMBER$ip address $ACCESS_VLAN_IP$ 255.255.255.0

!int f0/0switchport trunk allowed vlan add $VLAN_NUMBER$

int f0/1switchport trunk allowed vlan add $VLAN_NUMBER$

!FileType=NativeCommandSetName=ADD_VLAN_ROUTINGVendor=CiscoType=RouterModel=*Os=*CommandType=Configuration ChangeLineByLine=trueStopOnError=trueString=exit

vlan databasevlan $VLAN_NUMBER$exit

config term

interface Vlan$VLAN_NUMBER$description SVI

ip vrf forwarding blueip address $SVI_IP$ 255.255.255.0exit

!interface FastEthernet0/2switchport trunk allowed vlan add $VLAN_NUMBER$exit

!router ospf 2 vrf bluenetwork $SVI_SUBNET$ 0.0.0.255 area 0exit

!FileType=NativeCommandSetName=REMOVE_VLAN_ROUTINGVendor=CiscoType=RouterModel=*Os=*CommandType=Configuration ChangeLineByLine=trueStopOnError=trueString=no interface Vlan$VLAN_NUMBER$

interface FastEthernet0/2switchport trunk allowed vlan rem $VLAN_NUMBER$

router ospf 2 vrf blueno network 10.10.50.0 0.0.0.255 area 0

end

!vlan databaseno vlan $VLAN_NUMBER$exitFileType=NativeCommandSetName=REMOVE_VLAN_ACCESS_PORTVendor=CiscoType=RouterModel=*Os=*CommandType=Configuration ChangeLineByLine=falseStopOnError=trueString=default interface FastEthernet0/13!int f0/0switchport trunk allowed vlan remove $VLAN_NUMBER$

int f0/1switchport trunk allowed vlan remove $VLAN_NUMBER$

!no interface Vlan$VLAN_NUMBER$!end!vlan databaseno vlan $VLAN_NUMBER$exit


Example NSM service template for a Firewall service

The following example NSM service template manages Firewall Zones andInterface on a Juniper router.<serviceTemplate name="NSM_Firewall_Zones_and_Interfaces" description="NSM Service Template to manage

Firewall Zones and Interfaces on a Juniper SRX"><clientParameters><clientParameter><name>TARGETROUTETABLE</name><description>The Target Router Table e.g. MEET_ME_VR.inet.0</description>

</clientParameter><clientParameter>

<name>VIRTUALROUTERNAME</name><description>The Virtual Router Name e.g. vr_8262</description>


<name>NAME</name><description>The Customer Zone Name e.g. cz_8262</description></clientParameter><clientParameter><name>PARENTINTERFACENAME</name><description>The Parent Interface Name e.g. 0/0/1</description>


<name>VLANID</name><description>The VLAN ID e.g. 3999</description>


<name>PROJECTSUBNET</name><description>The Project SUBNET e.g. 10.100.200.1/24</description>


<name>SECURITYZONENAME</name><description>The Security Zone Name e.g. cz_8262</description>


<name>UNTRUSTEDZONENAME</name><description>The Untrusted Zone Name e.g. untrust</description>


<name>DESCRIPTION</name><description>The description of the Interface e.g. test description</description>


<name>POOLNAME</name><description>The POOL NAME e.g. pool-P999-cz_8262-dest-NAT-pool</description>


<name>SRCRULESETNAME</name><description>The Source Rule Set Name e.g. cz_8262-untrust-src-NAT</description>


<name>SRCRULENAME</name><description>The Source Rule Name e.g. P999-cz_8262-src-NAT-rule</description></clientParameter><clientParameter>

<name>DESTRULESETNAME</name><description>The destination Rule Set Name e.g. untrust-dest-NAT</description>


<name>DESTRULENAME</name><description>The destination Rule Name e.g. P999-cz_8262-dest-NAT-rule</description>


<name>CHILDINTERFACENAME</name><description>The Child Interface Name e.g. ge-0/0/1.3999</description>


<name>ANYADDRESS</name><description>The Any Address e.g. 0.0.0.0/0</description></clientParameter></clientParameters>

<clientParameterLists><clientParameterList name="SOURCETARGETZONE_CPL" description="A Client ParameterList to collect Source and Target Zones">

<parameter name="SOURCEZONENAME" description="The Source Zone Name"/><parameter name="TARGETZONENAME" description="The Target Zone Name"/>

</clientParameterList></clientParameterLists>

<constantParameters><constantParameter><name>SOURCEROUTETABLE_CONST</name><description>Always add .inet.0 to the end of the Source Route Table Value</description><value>.inet.0</value></constantParameter><constantParameter><name>RIBGROUPNAME_CONST</name><description>Always add -inetrib to the end of the RIB Group Name Value</description><value>-inetrib</value></constantParameter></constantParameters>

<injectParameters><injectParameter>

<name>SOURCEROUTETABLE</name><description>The Source Route Table is VIRTUALROUTERNAME with .inet.0 added to it e.g. vr_8262.inet.0</description><methodCall>concat</methodCall><arguments>VIRTUALROUTERNAME,SOURCEROUTETABLE_CONST</arguments><code></code>

</injectParameter><injectParameter>

<name>RIBGROUPNAME</name><description>The RIB Group Name is VIRTUALROUTERNAME with -inetrib added to it e.g. vr_8262-inetrib</description><methodCall>concat</methodCall><arguments>VIRTUALROUTERNAME,RIBGROUPNAME_CONST</arguments><code></code>

</injectParameter></injectParameters>

<implementations><implementation><rules><rule type="DeviceType"><ruleProperty name="Vendor" value="Juniper"/><ruleProperty name="Type" value="Router"/><ruleProperty name="Model" value="srx.*"/><ruleProperty name="OS" value="10.*"/>

</rule></rules><serviceOperations>

Appendix C. Example NSM service templates 143

<serviceOperation type="CREATE"><operations><operation name="ITNCM/FirewallCreateZones" type="COMMANDSET" order="1"><parameters><parameter name="TARGETROUTETABLE"/><parameter name="SOURCEROUTETABLE"/><parameter name="VIRTUALROUTERNAME"/><parameter name="RIBGROUPNAME"/><parameter name="NAME"/></parameters></operation>

<operation name="ITNCM/FirewallInitializeZones" type="COMMANDSET" order="2"><parameters><parameter name="SOURCETARGETZONE_CPL"/></parameters></operation>

<operation name="ITNCM/FirewallCreateInterfaces" type="COMMANDSET" order="3"><parameters><parameter name="PARENTINTERFACENAME"/><parameter name="VLANID"/><parameter name="PROJECTSUBNET"/><parameter name="VIRTUALROUTERNAME"/><parameter name="SECURITYZONENAME"/><parameter name="UNTRUSTEDZONENAME"/><parameter name="DESCRIPTION"/><parameter name="POOLNAME"/><parameter name="SRCRULESETNAME"/><parameter name="SRCRULENAME"/><parameter name="DESTRULESETNAME"/><parameter name="DESTRULENAME"/><parameter name="CHILDINTERFACENAME"/><parameter name="ANYADDRESS"/></parameters></operation>

</operations></serviceOperation>

<serviceOperation type="DELETE"><operations><operation name="ITNCM/FirewallDeleteInterfaces" type="COMMANDSET" order="1"><parameters><parameter name="PARENTINTERFACENAME"/><parameter name="VLANID"/><parameter name="VIRTUALROUTERNAME"/><parameter name="SECURITYZONENAME"/><parameter name="SRCRULESETNAME"/><parameter name="SRCRULENAME"/><parameter name="DESTRULESETNAME"/><parameter name="DESTRULENAME"/><parameter name="POOLNAME"/><parameter name="CHILDINTERFACENAME"/></parameters></operation>

<operation name="ITNCM/FirewallDeleteZonesPolicies" type="COMMANDSET" order="2"><parameters><parameter name="SOURCETARGETZONE_CPL"/></parameters></operation>

<operation name="ITNCM/FirewallDeleteZones" type="COMMANDSET" order="3"><parameters><parameter name="SRCRULESETNAME"/><parameter name="RIBGROUPNAME"/><parameter name="VIRTUALROUTERNAME"/><parameter name="NAME"/></parameters></operation>

</operations></serviceOperation></serviceOperations></implementation></implementations></serviceTemplate>

Example NSM service template to manage Firewall SecurityPolicies on a Juniper Router

The following example NSM service template manages Firewall Security Policieson a Juniper router.<serviceTemplate name="NSM_Firewall_Security_Policies" description="NSM Service Template to manage Security Policies on a Juniper SRX">

<clientParameterLists><clientParameterList name="POLICIES_CPL" description="A Client List Parameter to collect Firewall Policies">

<parameter name="SOURCEZONENAME" description="The Source Zone Name"/><parameter name="TARGETZONENAME" description="The Target Zone Name"/><parameter name="APPLICATIONNAME" description="The Application Name to apply the Policy to"/><parameter name="PORT" description="The Port Number of the Application"/><parameter name="PROTOCOL" description="The Protocol used to communicate with the application"/><parameter name="SRCADDRESSLABEL" description="The Source Address Label"/><parameter name="SOURCESUBNET" description="The Source Sub Network"/><parameter name="DESTADDRESSLABEL" description="The Destination Addess Label"/><parameter name="TARGETSUBNET" description="The Target Sub Network"/><parameter name="POLICYNAME" description="The name to give to this Policy"/>

</clientParameterList></clientParameterLists>

<implementations><implementation><rules><rule type="DeviceType"><ruleProperty name="Vendor" value="Juniper"/><ruleProperty name="Type" value="Router"/><ruleProperty name="Model" value="srx.*"/><ruleProperty name="OS" value="10.*"/></rule>

</rules><serviceOperations><serviceOperation type="CREATE"><operations><operation name="ITNCM/FirewallCreateSecurityPoliciesSpecifiedSourceAndTargetAddress" type="COMMANDSET"><parameters><parameter name="POLICIES_CPL"/></parameters></operation></operations>


</serviceOperation>

<serviceOperation type="DELETE"><operations><operation name="ITNCM/FirewallDeleteSecurityPolicies" type="COMMANDSET"><parameters><parameter name="POLICIES_CPL"/></parameters></operation></operations></serviceOperation></serviceOperations></implementation></implementations></serviceTemplate>

The following example shows the corresponding Smart Model command set forthe NSM service template that manages Firewall Security Policies on a Juniperrouter.

Note: The Smart Model command set example contains extra line-feeds. If youneed to import the example Smart Model command set into Netcool ConfigurationManager, then copy and paste the example into create a file to be imported. Editthe file so that there are no line-feeds included in any of the XML sections. Theimport command set should then function correctly.FileType=CommandSetName=FirewallDeleteSecurityPoliciesVendor=JuniperType=RouterModel=srx*Os=10.*Detail=<configuration xmlns:deltaxml="http://www.deltaxml.com/ns/well-formed-delta-v1"deltaxml:delta="WFmodify" xmlns:cmdSetMarkup="http://www.intelliden.com/ns/cmdSetMarkup"xmlns:deviceMarkup="http://www.intelliden.com/deviceMarkup" xmlns:idm="http://www.intelliden.com/ns/idMarkup"xmlns:securityMarkup="http://intelliden.com/securityMarkup" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><applications deltaxml:delta="WFmodify"><application deltaxml:delta="delete"><name cmdSetMarkup:param="APPLICATIONNAME"/></application> </applications><security deltaxml:delta="WFmodify"><policies deltaxml:delta="WFmodify"><policy deltaxml:delta="WFmodify"><from-zone-name cmdSetMarkup:param="SOURCEZONENAME" cmdSetMarkup:match="true" deltaxml:delta="unchanged"/><to-zone-name cmdSetMarkup:param="TARGETZONENAME" cmdSetMarkup:match="true" deltaxml:delta="unchanged"/><policy deltaxml:delta="delete"><name cmdSetMarkup:param="POLICYNAME"/></policy></policy></policies><zones deltaxml:delta="WFmodify"><security-zone deltaxml:delta="WFmodify"><name cmdSetMarkup:param="TARGETZONENAME" deltaxml:delta="unchanged"/><address-book deltaxml:delta="WFmodify"><address deltaxml:delta="delete"><name cmdSetMarkup:param="DESTADDRESSLABEL"/></address></address-book></security-zone><security-zone deltaxml:delta="WFmodify"><name cmdSetMarkup:param="SOURCEZONENAME" deltaxml:delta="unchanged"/><address-book deltaxml:delta="WFmodify"><address deltaxml:delta="delete"><name cmdSetMarkup:param="SRCADDRESSLABEL"/></address></address-book></security-zone></zones></security></configuration>FileType=CommandSetName=FirewallCreateSecurityPoliciesSpecifiedSourceAndTargetAddressVendor=JuniperType=RouterModel=srx*Os=10.*Detail=<configuration xmlns:deltaxml="http://www.deltaxml.com/ns/well-formed-delta-v1"deltaxml:delta="WFmodify"xmlns:cmdSetMarkup="http://www.intelliden.com/ns/cmdSetMarkup"xmlns:deviceMarkup="http://www.intelliden.com/deviceMarkup"xmlns:idm="http://www.intelliden.com/ns/idMarkup"xmlns:securityMarkup="http://intelliden.com/securityMarkup"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><applications cmdSetMarkup:addIfMissing="true" deltaxml:delta="WFmodify"><application deltaxml:delta="add"><name cmdSetMarkup:param="APPLICATIONNAME"/><source-port>1-65535</source-port><destination-port cmdSetMarkup:param="PORT"/><protocol cmdSetMarkup:param="PROTOCOL"/></application></applications><security cmdSetMarkup:addIfMissing="true" deltaxml:delta="WFmodify"><policies cmdSetMarkup:addIfMissing="true" deltaxml:delta="WFmodify"><policy deltaxml:delta="add"><from-zone-name cmdSetMarkup:param="SOURCEZONENAME"/><to-zone-name cmdSetMarkup:param="TARGETZONENAME"/><policy><name cmdSetMarkup:param="POLICYNAME"/><match><application cmdSetMarkup:param="APPLICATIONNAME"/><destination-address cmdSetMarkup:param="DESTADDRESSLABEL"/><source-address cmdSetMarkup:param="SRCADDRESSLABEL"/></match><then><permit/><log><session-close/></log></then></policy></policy></policies><zones deltaxml:delta="WFmodify"><security-zone deltaxml:delta="WFmodify"><name cmdSetMarkup:param="SOURCEZONENAME" deltaxml:delta="unchanged"/><address-book cmdSetMarkup:addIfMissing="true" deltaxml:delta="WFmodify"><address deltaxml:delta="add"><name cmdSetMarkup:param="SRCADDRESSLABEL"/><ip-prefix cmdSetMarkup:param="SOURCESUBNET"/></address></address-book>


</security-zone><security-zone deltaxml:delta="WFmodify"><name cmdSetMarkup:param="TARGETZONENAME" deltaxml:delta="unchanged"/><address-book cmdSetMarkup:addIfMissing="true" deltaxml:delta="WFmodify"><address deltaxml:delta="add"><name cmdSetMarkup:param="DESTADDRESSLABEL"/><ip-prefix cmdSetMarkup:param="TARGETSUBNET"/></address></address-book></security-zone></zones></security></configuration>FileType=CommandSetName=FirewallCreateSecurityPoliciesAnyTargetAddressVendor=JuniperType=RouterModel=srx*Os=10.*Detail=<configuration xmlns:deltaxml="http://www.deltaxml.com/ns/well-formed-delta-v1" deltaxml:delta="WFmodify"xmlns:cmdSetMarkup="http://www.intelliden.com/ns/cmdSetMarkup" xmlns:deviceMarkup="http://www.intelliden.com/deviceMarkup"xmlns:idm="http://www.intelliden.com/ns/idMarkup" xmlns:securityMarkup="http://intelliden.com/securityMarkup"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><applicationscmdSetMarkup:addIfMissing="true" deltaxml:delta="WFmodify"><application deltaxml:delta="add"><name cmdSetMarkup:param="APPLICATIONNAME"/><source-port>1-65535</source-port><destination-port cmdSetMarkup:param="PORT"/><protocol cmdSetMarkup:param="PROTOCOL"/></application></applications><security cmdSetMarkup:addIfMissing="true" deltaxml:delta="WFmodify"><policies cmdSetMarkup:addIfMissing="true" deltaxml:delta="WFmodify"><policy deltaxml:delta="add"><from-zone-name cmdSetMarkup:param="SOURCEZONENAME"/><to-zone-name cmdSetMarkup:param="TARGETZONENAME"/><policy><name cmdSetMarkup:param="POLICYNAME"/><match><application cmdSetMarkup:param="APPLICATIONNAME"/><destination-address>any</destination-address><source-address cmdSetMarkup:param="SRCADDRESSLABEL"/></match><then><permit/><log><session-close/></log></then></policy></policy></policies><zones deltaxml:delta="WFmodify"><security-zone deltaxml:delta="WFmodify"><name cmdSetMarkup:param="SOURCEZONENAME" deltaxml:delta="unchanged"/><address-book cmdSetMarkup:addIfMissing="true" deltaxml:delta="WFmodify"><address deltaxml:delta="add"><name cmdSetMarkup:param="SRCADDRESSLABEL"/><ip-prefix cmdSetMarkup:param="SOURCESUBNET"/></address></address-book></security-zone></zones></security></configuration>FileType=CommandSetName=FirewallCreateSecurityPoliciesAnySourceOrTargetAddressVendor=JuniperType=RouterModel=srx*Os=10.*Detail=<configuration xmlns:deltaxml="http://www.deltaxml.com/ns/well-formed-delta-v1"deltaxml:delta="WFmodify" xmlns:cmdSetMarkup="http://www.intelliden.com/ns/cmdSetMarkup"xmlns:deviceMarkup="http://www.intelliden.com/deviceMarkup"xmlns:idm="http://www.intelliden.com/ns/idMarkup"xmlns:securityMarkup="http://intelliden.com/securityMarkup"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><applications cmdSetMarkup:addIfMissing="true" deltaxml:delta="WFmodify"><application deltaxml:delta="add"><name cmdSetMarkup:param="APPLICATIONNAME"/><source-port>1-65535</source-port><destination-port cmdSetMarkup:param="PORT"/><protocol cmdSetMarkup:param="PROTOCOL"/></application></applications><security cmdSetMarkup:addIfMissing="true" deltaxml:delta="WFmodify"><policies cmdSetMarkup:addIfMissing="true" deltaxml:delta="WFmodify"><policy deltaxml:delta="add"><from-zone-name cmdSetMarkup:param="SOURCEZONENAME"/><to-zone-name cmdSetMarkup:param="TARGETZONENAME"/><policy><name cmdSetMarkup:param="POLICYNAME"/><match><application cmdSetMarkup:param="APPLICATIONNAME"/><destination-address>any</destination-address><source-address>any</source-address></match><then><permit/><log><session-close/></log></then></policy></policy></policies></security></configuration>FileType=CommandSetName=FirewallCreateSecurityPoliciesAnySourceAddressVendor=JuniperType=RouterModel=srx*Os=10.*Detail=<configuration xmlns:deltaxml="http://www.deltaxml.com/ns/well-formed-delta-v1"deltaxml:delta="WFmodify" xmlns:cmdSetMarkup="http://www.intelliden.com/ns/cmdSetMarkup"xmlns:deviceMarkup="http://www.intelliden.com/deviceMarkup" xmlns:idm="http://www.intelliden.com/ns/idMarkup"xmlns:securityMarkup="http://intelliden.com/securityMarkup"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><applications cmdSetMarkup:addIfMissing="true" deltaxml:delta="WFmodify"><application deltaxml:delta="add"><name cmdSetMarkup:param="APPLICATIONNAME"/><source-port>1-65535</source-port><destination-port cmdSetMarkup:param="PORT"/><protocol cmdSetMarkup:param="PROTOCOL"/></application></applications><security cmdSetMarkup:addIfMissing="true" deltaxml:delta="WFmodify"><policies cmdSetMarkup:addIfMissing="true"deltaxml:delta="WFmodify"><policy deltaxml:delta="add"><from-zone-name cmdSetMarkup:param="SOURCEZONENAME"/><to-zone-name cmdSetMarkup:param="TARGETZONENAME"/><policy><name cmdSetMarkup:param="POLICYNAME"/><match><application cmdSetMarkup:param="APPLICATIONNAME"/><destination-address cmdSetMarkup:param="DESTADDRESSLABEL"/><source-address>any</source-address></match><then><permit/><log><session-close/></log></then></policy></policy></policies><zones deltaxml:delta="WFmodify"><security-zone deltaxml:delta="WFmodify"><name cmdSetMarkup:param="TARGETZONENAME" deltaxml:delta="unchanged"/><address-book cmdSetMarkup:addIfMissing="true" deltaxml:delta="WFmodify"><address deltaxml:delta="add"><name cmdSetMarkup:param="DESTADDRESSLABEL"/><ip-prefix cmdSetMarkup:param="TARGETSUBNET"/></address>


</address-book></security-zone></zones></security></configuration>FileType=CommandSetName=FirewallInitializeZonesVendor=JuniperType=RouterModel=srx*Os=10.*Detail=<configuration xmlns:deltaxml="http://www.deltaxml.com/ns/well-formed-delta-v1" deltaxml:delta="WFmodify"xmlns:cmdSetMarkup="http://www.intelliden.com/ns/cmdSetMarkup"xmlns:deviceMarkup="http://www.intelliden.com/deviceMarkup"xmlns:idm="http://www.intelliden.com/ns/idMarkup" xmlns:securityMarkup="http://intelliden.com/securityMarkup"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><security cmdSetMarkup:addIfMissing="true"deltaxml:delta="WFmodify"><policies cmdSetMarkup:addIfMissing="true"deltaxml:delta="WFmodify"><policy deltaxml:delta="add"><from-zone-name cmdSetMarkup:param="SOURCEZONENAME"/><to-zone-name cmdSetMarkup:param="TARGETZONENAME"/><policy><name>deny-all</name><match><source-address>any</source-address><destination-address>any</destination-address><application>any</application></match><then><deny/><log><session-init/></log><count/></then></policy></policy></policies></security></configuration>FileType=CommandSetName=FirewallDeleteZonesPoliciesVendor=JuniperType=RouterModel=srx*Os=10.*Detail=<configuration xmlns:deltaxml="http://www.deltaxml.com/ns/well-formed-delta-v1"deltaxml:delta="WFmodify" xmlns:cmdSetMarkup="http://www.intelliden.com/ns/cmdSetMarkup"xmlns:deviceMarkup="http://www.intelliden.com/deviceMarkup" xmlns:idm="http://www.intelliden.com/ns/idMarkup"xmlns:securityMarkup="http://intelliden.com/securityMarkup" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><security deltaxml:delta="WFmodify"><policies deltaxml:delta="WFmodify"><policy deltaxml:delta="delete"><from-zone-name cmdSetMarkup:param="SOURCEZONENAME"/><to-zone-name cmdSetMarkup:param="TARGETZONENAME"/></policy></policies></security></configuration>FileType=CommandSetName=FirewallDeleteZonesVendor=JuniperType=RouterModel=srx*Os=10.*Detail=<configuration xmlns:deltaxml="http://www.deltaxml.com/ns/well-formed-delta-v1"deltaxml:delta="WFmodify" xmlns:cmdSetMarkup="http://www.intelliden.com/ns/cmdSetMarkup"xmlns:deviceMarkup="http://www.intelliden.com/deviceMarkup" xmlns:idm="http://www.intelliden.com/ns/idMarkup"xmlns:securityMarkup="http://intelliden.com/securityMarkup" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><routing-instances deltaxml:delta="WFmodify"><instance deltaxml:delta="delete"><name cmdSetMarkup:param="VIRTUALROUTERNAME"/></instance></routing-instances><routing-options deltaxml:delta="WFmodify"><rib-groups deltaxml:delta="delete"><name cmdSetMarkup:param="RIBGROUPNAME"/></rib-groups></routing-options><security deltaxml:delta="WFmodify"><nat deltaxml:delta="WFmodify"><source deltaxml:delta="WFmodify"><rule-set deltaxml:delta="delete"><name cmdSetMarkup:param="SRCRULESETNAME"/></rule-set></source></nat><zones deltaxml:delta="WFmodify"><security-zone deltaxml:delta="delete"><name cmdSetMarkup:param="NAME"/></security-zone></zones></security></configuration>FileType=CommandSetName=FirewallDeleteInterfacesVendor=JuniperType=RouterModel=srx*Os=10.*Detail=<configuration xmlns:deltaxml="http://www.deltaxml.com/ns/well-formed-delta-v1"deltaxml:delta="WFmodify" xmlns:cmdSetMarkup="http://www.intelliden.com/ns/cmdSetMarkup"xmlns:deviceMarkup="http://www.intelliden.com/deviceMarkup" xmlns:idm="http://www.intelliden.com/ns/idMarkup"xmlns:securityMarkup="http://intelliden.com/securityMarkup"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><interfaces deltaxml:delta="WFmodify"><interface_20ge- deltaxml:delta="WFmodify"><name cmdSetMarkup:param="PARENTINTERFACENAME" deltaxml:delta="unchanged"/><unit deltaxml:delta="delete"><name cmdSetMarkup:param="VLANID"/></unit></interface_20ge-></interfaces><routing-instances deltaxml:delta="WFmodify"><instance deltaxml:delta="WFmodify"><name cmdSetMarkup:param="VIRTUALROUTERNAME" deltaxml:delta="unchanged"/><interface deltaxml:delta="delete"><name cmdSetMarkup:param="CHILDINTERFACENAME"/></interface></instance></routing-instances><security deltaxml:delta="WFmodify"><nat deltaxml:delta="WFmodify"><source deltaxml:delta="WFmodify"><rule-set deltaxml:delta="delete"><name cmdSetMarkup:param="SRCRULESETNAME"/><rule><name cmdSetMarkup:param="SRCRULENAME"/></rule></rule-set></source><destination deltaxml:delta="WFmodify"><pool deltaxml:delta="delete"><name cmdSetMarkup:param="POOLNAME"/>


</pool><rule-set deltaxml:delta="WFmodify"><name cmdSetMarkup:param="DESTRULESETNAME" deltaxml:delta="unchanged"/><rule deltaxml:delta="delete"><name cmdSetMarkup:param="DESTRULENAME"/></rule></rule-set></destination></nat><zones deltaxml:delta="WFmodify"><security-zone deltaxml:delta="WFmodify"><name cmdSetMarkup:param="SECURITYZONENAME" deltaxml:delta="unchanged"/><interfaces deltaxml:delta="delete"><name cmdSetMarkup:param="CHILDINTERFACENAME"/></interfaces></security-zone></zones></security></configuration>FileType=CommandSetName=FirewallCreateZonesVendor=JuniperType=RouterModel=srx*Os=10.*Detail=<configuration xmlns:deltaxml="http://www.deltaxml.com/ns/well-formed-delta-v1"deltaxml:delta="WFmodify" xmlns:cmdSetMarkup="http://www.intelliden.com/ns/cmdSetMarkup"xmlns:deviceMarkup="http://www.intelliden.com/deviceMarkup"xmlns:idm="http://www.intelliden.com/ns/idMarkup" xmlns:securityMarkup="http://intelliden.com/securityMarkup"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><routing-instances cmdSetMarkup:addIfMissing="true" deltaxml:delta="WFmodify"><instance deltaxml:delta="add"><name cmdSetMarkup:param="VIRTUALROUTERNAME"/><routing-options><interface-routes><rib-group><inet cmdSetMarkup:param="RIBGROUPNAME"/></rib-group></interface-routes><static><route><name>0.0.0.0/0</name><next-table>inet.0</next-table></route></static></routing-options><instance-type>virtual-router</instance-type></instance></routing-instances><routing-options cmdSetMarkup:addIfMissing="true" deltaxml:delta="WFmodify"><rib-groups deltaxml:delta="add"><name cmdSetMarkup:param="RIBGROUPNAME"/><apply-groups-except/><import-rib cmdSetMarkup:param="SOURCEROUTETABLE"/><import-rib cmdSetMarkup:param="TARGETROUTETABLE"/></rib-groups></routing-options><security cmdSetMarkup:addIfMissing="true" deltaxml:delta="WFmodify"><zones cmdSetMarkup:addIfMissing="true" deltaxml:delta="WFmodify"><security-zone deltaxml:delta="add"><name cmdSetMarkup:param="NAME"/><screen>SAA</screen><host-inbound-traffic><system-services><name>all</name></system-services></host-inbound-traffic></security-zone></zones></security></configuration>FileType=CommandSetName=FirewallCreateInterfacesVendor=JuniperType=RouterModel=srx*Os=10.*Detail=<configuration xmlns:deltaxml="http://www.deltaxml.com/ns/well-formed-delta-v1" deltaxml:delta="WFmodify"xmlns:cmdSetMarkup="http://www.intelliden.com/ns/cmdSetMarkup"xmlns:deviceMarkup="http://www.intelliden.com/deviceMarkup"xmlns:idm="http://www.intelliden.com/ns/idMarkup" xmlns:securityMarkup="http://intelliden.com/securityMarkup"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><interfaces deltaxml:delta="WFmodify"><interface_20ge- deltaxml:delta="WFmodify"><name cmdSetMarkup:param="PARENTINTERFACENAME" deltaxml:delta="unchanged"/><unit deltaxml:delta="add"><name cmdSetMarkup:param="VLANID"/><description cmdSetMarkup:param="DESCRIPTION"/><vlan-id cmdSetMarkup:param="VLANID"/><family><inet><address><name cmdSetMarkup:param="PROJECTSUBNET"/></address></inet></family></unit></interface_20ge-></interfaces><routing-instances deltaxml:delta="WFmodify"><instance deltaxml:delta="WFmodify"><name cmdSetMarkup:param="VIRTUALROUTERNAME" deltaxml:delta="unchanged"/><interface deltaxml:delta="add"><name cmdSetMarkup:param="CHILDINTERFACENAME"/></interface><instance-type deltaxml:delta="unchanged">virtual-router</instance-type></instance></routing-instances><security cmdSetMarkup:addIfMissing="true" deltaxml:delta="WFmodify"><nat cmdSetMarkup:addIfMissing="true" deltaxml:delta="WFmodify"><source cmdSetMarkup:addIfMissing="true" deltaxml:delta="WFmodify"><rule-set deltaxml:delta="add"><name cmdSetMarkup:param="SRCRULESETNAME"/><from><zone cmdSetMarkup:param="SECURITYZONENAME"/></from><to><zone cmdSetMarkup:param="UNTRUSTEDZONENAME"/></to><rule><name cmdSetMarkup:param="SRCRULENAME"/><src-nat-rule-match><destination-address cmdSetMarkup:param="ANYADDRESS"/><source-address cmdSetMarkup:param="PROJECTSUBNET"/></src-nat-rule-match><then><source-nat><interface/></source-nat></then></rule></rule-set></source><destination cmdSetMarkup:addIfMissing="true" deltaxml:delta="WFmodify"><pool deltaxml:delta="add"><name cmdSetMarkup:param="POOLNAME"/><routing-instance><ri-name cmdSetMarkup:param="VIRTUALROUTERNAME"/></routing-instance><address><ipaddr cmdSetMarkup:param="PROJECTSUBNET"/>


</address></pool><rule-set deltaxml:delta="WFmodify"><name cmdSetMarkup:param="DESTRULESETNAME" deltaxml:delta="unchanged"/><rule deltaxml:delta="add"><name cmdSetMarkup:param="DESTRULENAME"/><dest-nat-rule-match><source-address cmdSetMarkup:param="ANYADDRESS"/><destination-address><dst-addr cmdSetMarkup:param="PROJECTSUBNET"/></destination-address></dest-nat-rule-match><then><destination-nat><pool><pool-name cmdSetMarkup:param="POOLNAME"/></pool></destination-nat></then></rule></rule-set></destination></nat><zones deltaxml:delta="WFmodify"><security-zone deltaxml:delta="WFmodify"><name cmdSetMarkup:param="SECURITYZONENAME" deltaxml:delta="unchanged"/><interfaces deltaxml:delta="add"><name cmdSetMarkup:param="CHILDINTERFACENAME"/></interfaces></security-zone></zones></security></configuration>


Notices

This information was developed for products and services offered in the U.S.A.

IBM® may not offer the products, services, or features discussed in this documentin other countries. Consult your local IBM representative for information on theproducts and services currently available in your area. Any reference to an IBMproduct, program, or service is not intended to state or imply that only that IBMproduct, program, or service may be used. Any functionally equivalent product,program, or service that does not infringe any IBM intellectual property right maybe used instead. However, it is the user's responsibility to evaluate and verify theoperation of any non-IBM product, program, or service.

IBM may have patents or pending patent applications covering subject matterdescribed in this document. The furnishing of this document does not grant youany license to these patents. You can send license inquiries, in writing, to:

IBM Director of LicensingIBM CorporationNorth Castle DriveArmonk, NY 10504-1785U.S.A.

For license inquiries regarding double-byte (DBCS) information, contact the IBMIntellectual Property Department in your country or send inquiries, in writing, to:

Intellectual Property LicensingLegal and Intellectual Property LawIBM Japan Ltd.19-21, Nihonbashi-Hakozakicho, Chuo-kuTokyo 103-8510, Japan

The following paragraph does not apply to the United Kingdom or any othercountry where such provisions are inconsistent with local law: INTERNATIONALBUSINESS MACHINES CORPORATION PROVIDES THIS PUBLICATION "AS IS"WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED,INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OFNON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULARPURPOSE. Some states do not allow disclaimer of express or implied warranties incertain transactions, therefore, this statement may not apply to you.

This information could include technical inaccuracies or typographical errors.Changes are periodically made to the information herein; these changes will beincorporated in new editions of the publication. IBM may make improvementsand/or changes in the product(s) and/or the program(s) described in thispublication at any time without notice.

Any references in this information to non-IBM Web sites are provided forconvenience only and do not in any manner serve as an endorsement of those Websites. The materials at those Web sites are not part of the materials for this IBMproduct and use of those Web sites is at your own risk.


IBM may use or distribute any of the information you supply in any way itbelieves appropriate without incurring any obligation to you.

Licensees of this program who wish to have information about it for the purposeof enabling: (i) the exchange of information between independently createdprograms and other programs (including this one) and (ii) the mutual use of theinformation which has been exchanged, should contact:

IBM Corporation958/NH04IBM Centre, St Leonards601 Pacific HwySt Leonards, NSW, 2069Australia

IBM Corporation896471/H128B76 Upper GroundLondon SE1 9PZUnited Kingdom

IBM CorporationJBF1/SOM1294 Route 100Somers, NY, 10589-0100United States of America

Such information may be available, subject to appropriate terms and conditions,including in some cases, payment of a fee.

The licensed program described in this document and all licensed materialavailable for it are provided by IBM under terms of the IBM Customer Agreement,IBM International Program License Agreement or any equivalent agreementbetween us.

Any performance data contained herein was determined in a controlledenvironment. Therefore, the results obtained in other operating environments mayvary significantly. Some measurements may have been made on development-levelsystems and there is no guarantee that these measurements will be the same ongenerally available systems. Furthermore, some measurements may have beenestimated through extrapolation. Actual results may vary. Users of this documentshould verify the applicable data for their specific environment.

Information concerning non-IBM products was obtained from the suppliers ofthose products, their published announcements or other publicly available sources.IBM has not tested those products and cannot confirm the accuracy ofperformance, compatibility or any other claims related to non-IBM products.Questions on the capabilities of non-IBM products should be addressed to thesuppliers of those products.

All statements regarding IBM's future direction or intent are subject to change orwithdrawal without notice, and represent goals and objectives only.

This information contains examples of data and reports used in daily businessoperations. To illustrate them as completely as possible, the examples include the


names of individuals, companies, brands, and products. All of these names arefictitious and any similarity to the names and addresses used by an actual businessenterprise is entirely coincidental.

COPYRIGHT LICENSE:

This information contains sample application programs in source language, whichillustrate programming techniques on various operating platforms. You may copy,modify, and distribute these sample programs in any form without payment toIBM, for the purposes of developing, using, marketing or distributing applicationprograms conforming to the application programming interface for the operatingplatform for which the sample programs are written. These examples have notbeen thoroughly tested under all conditions. IBM, therefore, cannot guarantee orimply reliability, serviceability, or function of these programs. The sampleprograms are provided "AS IS", without warranty of any kind. IBM shall not beliable for any damages arising out of your use of the sample programs.

If you are viewing this information softcopy, the photographs and colorillustrations may not appear.

TrademarksIBM, the IBM logo, ibm.com®, Netcool®, Passport Advantage®, Tivoli®, the Tivolilogo and WebSphere are trademarks or registered trademarks of InternationalBusiness Machines Corp., registered in many jurisdictions worldwide. Otherproduct and service names might be trademarks of IBM or other companies. Acurrent list of IBM trademarks is available on the Web at “Copyright andtrademark information” at www.ibm.com/legal/copytrade.shtml.

Adobe, Acrobat, Portable Document Format (PDF), PostScript, and all Adobe-basedtrademarks are either registered trademarks or trademarks of Adobe SystemsIncorporated in the United States, other countries, or both.

Java™ and all Java-based trademarks and logos are trademarks orregistered trademarks of Sun Microsystems, Inc. in the United States,other countries, or both.

Linux is a registered trademark of Linus Torvalds in the United States, othercountries, or both.

Microsoft, Windows, Windows NT, and the Windows logo are trademarks ofMicrosoft Corporation in the United States, other countries, or both.

UNIX is a registered trademark of The Open Group in the United States and othercountries.

Other company, product, or service names may be trademarks or service marks ofothers.

Notices 153

http://www.ibm.com/legal/copytrade.shtml

http://www.ibm.com/legal/copytrade.shtml

Index

Aaccessibility x

Cconventions, typeface x

Eeducation

see Tivoli technical training xenvironment variables, notation x

Mmanuals vi

Oonline publications viordering publications vi

Ppublications vi

Ssupport information x

TTivoli software information center viTivoli technical training xtraining, Tivoli technical xtypeface conventions x

Vvariables, notation for x


��

Printed in the Republic of Ireland

Network Service Manager RESTAPI Users Guide - IBM Service Manager RESTAPI Users Guide for R2E2. Note...

Documents

Transcript of Network Service Manager RESTAPI Users Guide - IBM Service Manager RESTAPI Users Guide for R2E2. Note...