Provisioning Network Services in ITNCM

1. Provisioning Network Services in ITNCM

2. 2 ITNCM: Intelligent Tool for Network Operations & Compliance Backup Configuration Single instance repository for all configuration and change information Rollback or Restore Configuration Restore configuration with or without a device reboot Device Discovery Discover network devices in the networkor utilize ITNM or flat file loads. SmartModel™, Command Set Groups & Native Command Sets Intelligently apply changes with full error control or with vendor native scripts Security Role-based control of who accesses what devices and what changes they can make within the network, including full workflow approvals. Key Product Features Bulk Configuration Changes Automate bulk configuration changes through reusable command sets with full fallout management and error handling Open NSM REST API REST API enabling ITNCM to be integrated with existing customer systems e.g. network provisioning, Cloud Provisioning Full Network Change & Policy Management Lifecycle Support Synchronize Changes Update configuration repository with planned and un-planned configuration changes across the network OS Upgrade Support Automatically management theupgrade of a devices operating system Pre-emptive and Current StatePolicy Compliance Direct Device Access Including command filtering and full keystroke logging for audit purposes

3. Network Service Management ( NSM ) The Goals of NSM is to: • Simplify the Creation, Modification and Deletion of Network Services on Network Devices • Create Service Templates that can hide the complexity of the Service away from the Client User • Allow for easy management of the Service Templates in terms of Creation, Modification, Deletion, Importing and Exporting. • Create a robust and reproducible Network Configuration Service Solution • Allow the features of ITNCM to be available through a simple REST Interface

4. NSM Service Templates NSM Service Templates allow the Service Template Designer: • To Dictate how NCM Artifacts such as Native & Smart Modelled CommandSets are called in a controlled and ordered manner. • Allow access to the IT NCM Artifacts without the need to have in-depth ITNCM knowledge or Java Code experience , the Service Templates are simple XML Configuration Files, all the complexity to interface to ITNCM is hidden from the Service Template Designer by NSM. • Introduce the ability to manipulate client provided parameter values and inject new parameters values as needed for the ITNCM Commandsets. • Control the life Cycle of a Network Service and decide how the Service can be deleted.

5. 5 NSM Service LifeCycle Network Service Design Service Template Designer plans what type of Network Service is needed. Service Removal Depending on how the Service Template was designed either the Client Users can request for a Service to be Deleted using the NSM REST API or the Service Designer can create a schedule for when the Service is removed Client Checks for Service Status The Client Users can view Service execution status using the NSM Service URI's. The Client User can also check for specific the specific configuration changes using Extractions. Command Set Creation Service Template Designer Uses ITNCM Tools to create the necessary Command Sets to create and maintain the Network Service on the Devices NSM Service LifeCycle Service Template Creation Service Template Designer Uses Service Template XML to design how the Service should be Exposed to the Client User. They also decide how the Command Sets Parameters should be calculated and in what order they should execute. c NSM executes Service NSM executes the Service as dictated by the Service Template. NSM communicates with ITNCM to create the Workitems needed to complete the Service on the Network Devices. Full Change History and Control Client Requests new Service The Client Users can now request the NSM Service of their choice using the NSM Service REST URI's. Import Service Templates Service Template Designer Uses the NSM Commandline Tools to import the Service Tenplate Design XML files into the ITNCM database. Client Views new Service The Client User uses the NSM Service Template REST URI's to view the new Service being offered

6. NSM Parameter Calculation JavaScript Parameters NSM allow the execution of both NSM provided JavaScripts Methods to manipulate Parameters and also allows the Service Template Designer to provide their own Controlled JavaScript. SQL Parameters NSM can query external or internal databases to retrieve parameter values. The Arguments to the Query can be provided by the Client or can be injected by the Service Template designer Client Parameters NSM can accept Parameter Name/Values from the Client to pass directly to Commandsets or they NSM can use them in the NSM Parameter Engine to calculate other parameters. NSM Parameter Engine Http Parameters NSM allows the retrieval of parameters by calling a HttpClient using the URL supplied by the Service Template Designer NCM Command Sets NCM Commandsets takes parameter Values as calculated by NSM Parameter Engine and executes these on the Network Devices.

7. NSM Service Template Tools CRUD Tools NSM provides a range of tools to easily Create, Update and Delete Services Templates. Cloning Tools NSM provides tools to take an existing Service Template and Clone it, thus making it easier to create Service Templates that are similar to other Service Templates. Search Tools NSM provides tools to search for Service Template with a range of filters such as Name, Creation Date and Device Vendors that the Service Template Supports, ITNCM Development ITNCM Production Export and Import Tools NSM provides a range of tools to Export Service Templates and Import to other Systems. Typical use of these tools would be to move Service Templates from Development to Production Systems once verified.

8. NSM Service Templates main elements • Parameters – Decide how the Parameters are to be calculated ( Client Provided, SQL, HTTP Request, Inject JavaScript or Constant • Implementations – Controls which operations will get called and how/which parameters get calculated based on the Devices Vendor-Type-Model-OS (VTMOS). The Designer can use regular expressions to allow one implementation to support multiple Devices. One Service Template can have many implementations. • ServiceOperations – Operations can be classified as CREATE or DELETE. Depending on the Http Method used on the Service URI, NSM will run either execute the CREATE operations when HTTP POST is used, and execute the DELETE Operations when HTTP DELETE is used by the Client using the NSM REST API. • Operations – Define which ITNCM Artifacts need to run and in which order they should execute. Operations types can be COMMANDSET, EXTRACTION or DEVICE SYNC

9. NSM REST URI's • Device URI's can be used for Device Inventory gathering. It is also possible to retrieve the devices current configuration • Realm URI's for searching ITNCM realms which are used to organize ITNCM Artifacts by Geographic, Policy, Security or any Customer specific realms. • ServiceTemplate URI's allow the NSM REST API Client user query the ITNCM system for available Services that can be executed on a device. • Service URI's allow the NSM REST API Client user to create, monitor and delete the Network Services provided by the Service Templates. Device Realm ServiceTemplate Service

10. NSM war is installed with the NCM Presentation Servers on IT NCM 6.4 NCM DB Presentation Server1 Presentation Server2 NSM war NSM war Worker Servers

11. NSM Main Client URI's • Http GET http://host:port/nsm/device/ • Http GET http://host:port/nsm/servicetemplate/ • Http GET http://host:port/nsm/servicetemplate/{st-id}/device/{device-id} • Http POST http://host:port/nsm/service • Http GET http://host:port/nsm/service/{service-id} • Http DELETE http://host:port/nsm/service/{service-id}

12. NSM Service Template basic structure

13. NSM Service Template Parameters

14. Constant Parameters structure • Static values for a NSM Service Template Designer to Use

15. Client Parameters structure • Enables a Client to set values before service execution • Used in the client submission for service execution • Client data is set to the value element of the clientParameter

16. Client List Parameters structure • Special case Client parameter. Allows client to specify a list of values before service execution • Each value in the list is used once during execution • Creates repeated operation execution where Operation uses the list • Order is optional and indicates order in which values must be used and repeat operations must be executed • Allows for variable repetition of the same command to be executed

17. Inject Parameters structure • Enables parameters to be manipulated before service execution using a JavaScript Engine • Pre supplied JavaScript functions including sum, subtract, multiply, divide, ifEquals, concat and string manipulations • Allows template designer to supply there own JavaScript code, using the <code> element (executed under white list conditions) • Uses a white list to exclude certain functionality from being executed • Result is set to the value element of the injectParameter

18. Http Parameters structure • Enables parameters to be manipulated before service execution • HTTP REST GET requests are executed at service execution time • Result is set to the value element of the httpParameter

19. SQL Parameters structure • Enables parameters to be manipulated before service execution • SQL is executed against the Database Connection located in the selected implementation at service execution time • Result is set to the value element of the sqlParameter • Note The database password is encrypted when stored.

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

21. Rules structure • Rules are used to select the correct implementation for the client to submit for service execution • Rule has one type currently “DeviceType” • DeviceType expects 4 properties Vendor, Type, Model and OS – VTMOS • Rule can be specified using Regular Expressions

22. Client service submission example • The structure of the service template for execution is expected to have at least the ID of the service template and the ID of the device to execute the service against. • Optionally it may have a list of client parameters needed to ensure the proper execution of the service.

23. Client service submission cont'd • Client POSTs ServiceTemplate XML for Service creation.Response contains Service with a new ID and state = SUBMITTED • Client uses GET /service/{service-id}/status to poll service state. Responses contains minimal service record with ID and latest state. • Client uses GET /service/{service-id} to retrieve full record with child workitem entries • Client uses GET /service/{service-id}/workitem/{workitem-id} to retrieve workitem data. Contains UOW Log and a task result (if present)

24. Service Processing • After client submits the service, NSM begins processing received XML into an active Service instance • Processing covers • CommandSet or Extraction resolution from ITNCM data systems • NSM Parameter evaluation and subsequent application to UOW CommandSet data • If any part of initial processing fails Service fails and processing stops • Initial processing includes • Resolution of device and operation targets (commandset, extraction) • Runtime Parameter evaluation • Active instance produces the following in ITNCM • 1 Service UOW • 1 or more UOWs in ITNCM (UOW merging is used if possible by the underlying submission system) • Service UOW provides a log of Service activity in ITNCM Client • NSM receives UOW processing/state change events to trigger updates in Service status • NSM updates Service UOW Log as state changes happen • Service UOW state reflects the state of the NSM Service

25. Service Processing Flow Service UOWs ITNCM NSM Work Queue REST Client POST ServiceTemplate XML Service Status Updates UOW Events Active Service List Worker Server Configuration data Managed Devices

26. Service Delete • ServiceTemplates provide 2 mutually exclusive mechanisms for handling deletion of Services they create • DELETE Service operation for cleanup/removal of service actions • Timed delete for transient Services • Delete mechanisms only apply to Services which were successful • Delete serviceOperation provides dedicated work execution block to be carried out in response to DELETE /service/{service-id} URI • Time To Delete specifies time in minutes after which a Service will be removed from the database • ServiceTemplate may only specify either of TTD or DELETE serviceOperation

27. Reference ID • A Service can be Posted for execution in 2 ways • The first is by using the URI shown next and supplying the client service template for service execution • Http POST to http://host:port/nsm/service • The Second is by using the URI shown next and suppling the client service template for service execution and a client generated reference ID • Http POST to http://host:port/nsm/service/referenceid/{reference-id} • The Client can now request the service by their own supplied reference ID ( e.g. CustomerService_12345 ) using the URI shown next • Http GET to http://host:port/nsm/service/referenceid/{reference-id}

28. Command Line Tool Commands: • create - creates a service template by using information from an XML file • Format: /nsmadmin.sh command=create filename=<filename> [username=<username> password=<password>][port=<port>] • Example: /nsmadmin.sh command=create filename=/opt/IBM/serviceTemplate1.xml • read - gets information about the latest version of a service template and outputs it to an XML file • Format: /nsmadmin.sh command=read filename=<filename> id=<id> [username=<username> password=<password>][port=<port>] • Example: /nsmadmin.sh command=read filename=serviceTemplateOutput.xml id=4 • list - lists the latest versions of all service templates in an XML file • Format: /nsmadmin.sh command=list filename=<filename> [username=<username> password=<password>][port=<port>] • Example: /nsmadmin.sh command=list filename=serviceTemplateOutputList.xml • update - creates a new version of a service template by updating information in an existing service template. • Format: /nsmadmin.sh command=update id=<id> filename=<filename> [username=<username> password=<password>][port=<port>] • Example: /nsmadmin.sh command=update id=19 filename=/opt/IBM/tivoli/netcool/ncm/bin/QAJavaST.xml • purge, clone, exportall, exportid, exportname, exportvendor, exportdaterange, import and importlist are the other tools options available

29. Troubleshooting I • Discussed in NSM API Guide • Generally, when a request encounters an error, NSM returns a HTTP Status code along with a specific NSM Error code. • HTTP Code indicates protocol level processing outcome • NSM Error codes documented in the API Guide and indicate failure category within NSM • For Service processing errors, detailed information can be found in ITNCM Service UOW log in the client and appropriate errors in the ITNCM log file $NCMHOME/logs/Intelliden.log • Diagnostic tools • Service UOW Log in ITNCM Client for Services • Intelliden.log for general & REST operation debugging • Logs • Logging system uses ITNCM logging • CLI import tool logs

30. Troubleshooting II • Detailed diagnosis and problem location for Services • Identify Service ID and execute GET on nsm/service/{service-id} in a browser to retrieve Service record • Examine service record and note serviceWorkKey attribute of the Service and id attributes of the child workItems. • Open ITNCM Client and locate Service UOW with ID matching value of serviceWorkKey. Open the log of this entry for detailed processing information. Also, use workItem id attributes to identify and examine individual UOWs via the client. • Execute GET nsm/service/{service-id}/workitem/{workitem-id} to retrieve UOW log and status info for a service workItem (or use the ITNCM Client to view the UOW log) • Open Intelliden.log to look for NSM processing error information