HP TeMIP Software - HPE Software Support

HP TeMIP Software
TeMIP NNMi Advanced Integration
Customization Guide
Edition: 6.0
April 2010
© Copyright 2010 Hewlett-Packard Development Company, L.P.
Legal Notices
Warranty
The information contained herein is subject to change without notice. The only warranties for HP
products and services are set forth in the express warranty statements accompanying such products and
services. Nothing herein should be construed as constituting an additional warranty. HP shall not be
liable for technical or editorial errors or omissions contained herein.
License Requirement and U.S. Government Legend
Confidential computer software. Valid license from HP required for possession, use or copying.
Consistent with FAR 12.211 and 12.212, Commercial Computer Software, Computer Software
Documentation, and Technical Data for Commercial Items are licensed to the U.S. Government under
vendor's standard commercial license.
Copyright Notices
© Copyright 2010 Hewlett-Packard Development Company, L.P.
Trademark Notices
Adobe®, Acrobat® and PostScript® are trademarks of Adobe Systems Incorporated.
HP-UX Release 10.20 and later and HP-UX Release 11.00 and later (in both 32 and 64-bit
configurations) on all HP 9000 computers are Open Group UNIX 95 branded products.
Red Hat and the Red Hat "Shadow Man" logo are registered trademarks of Red Hat, Inc. in the United
States and other countries.
Linux is a registered trademark of Linus Torvalds.
Java™ is a U.S. trademark of Sun Microsystems, Inc.
Microsoft® , Windows® and Windows NT® are U.S. registered trademarks of Microsoft Corporation.
Sun Solaris® is a registered trademark of Sun Microsystems, Inc.
Oracle® is a registered U.S. trademark of Oracle Corporation, Redwood City, California.
UNIX® is a registered trademark of The Open Group.
X/Open® is a registered trademark, and the X device is a trademark of X/Open Company Ltd. in the
UK and other countries.
CISCO® is a registered trademark of Cisco Systems, Inc. in the U.S. or certain other countries.
2
Contents
Chapter 1 Introduction .................................................................................12
1.1
1.2
1.3
1.4
1.5
Introduction to ATNI .........................................................................................12
ATNI Architecture.............................................................................................13
How Does ATNI Work?....................................................................................15
Why the Need to Customize? ..........................................................................16
An Overview of the Customization Guide ........................................................16
Chapter 2 Customization Context ...............................................................17
2.1
2.1.1
2.2
2.2.1
2.2.2
2.2.3
2.3
2.3.1
2.3.2
2.4
2.4.1
2.4.2
2.4.3
2.4.4
2.4.5
2.4.6
Introduction to the Customization Concept......................................................17
The ATNI Customization File Definition......................................................18
Introduction to the TNT Runtime Kit ................................................................22
The Input Directory .....................................................................................23
The Output Directory...................................................................................23
The External Directory ................................................................................24
Introduction to the TNT Custom Toolkit ...........................................................24
The TNT Customization Methodology ........................................................24
Introduction to Customization Toolkit..........................................................25
Integration of NNM Views into TeMIP Client ...................................................28
Overview .....................................................................................................28
NNM Station Configuration .........................................................................30
IP View Integration......................................................................................31
Alarm Drill-down View Integration...............................................................33
Integration of the NNMi Views within TeMIP ..............................................33
Integration of TeMIP into NNMi Views........................................................34
Chapter 3 Designing a Customization ........................................................36
3.1
3.1.1
3.1.2
3.2
3.3
3.3.1
3.3.2
3.3.3
3.4
3.4.1
3.4.2
3.5
Generating a Template Customization ............................................................36
Usage..........................................................................................................37
Input ............................................................................................................38
The tnt_mib_scanner Tool ...............................................................................39
Validating the Customization ...........................................................................40
Entity Model File Checking .........................................................................40
Default Generation Rules ...........................................................................41
The tnt_custom_gen Tool Output ...............................................................55
An example using the tnt_custom_gen tool.....................................................56
Loading the MIB into the NNM Repository .................................................56
Generating a Customization Template .......................................................56
TeMIP Registration Process ............................................................................60
Chapter 4 Updating the Customization.......................................................61
4.1 Introduction ......................................................................................................61
4.2 General Customization Information .................................................................61
4.2.1
The NNM Predefined Variables ..................................................................63
3
4.2.2
4.2.3
4.3
4.3.1
4.3.2
4.4
4.4.1
4.4.2
4.4.3
4.4.4
4.4.5
4.5
4.5.1
4.5.2
4.5.3
4.5.4
4.5.5
4.6
4.6.1
4.6.2
4.7
4.7.1
4.7.2
4.8
4.8.1
4.9
4.9.1
4.9.2
4.10
4.11
The Event Retention Policy ........................................................................65
Impact of changes to Customization file .....................................................65
The TeMIP Model Definition ............................................................................67
The AM Definition .......................................................................................67
The Entity Model .........................................................................................67
Topology Auto Discovery Configuration ..........................................................68
Filtering Capabilities ...................................................................................69
Naming Capabilities ....................................................................................69
TeMIP Distribution in the Auto Population..................................................70
Multiple Naming Rules................................................................................70
Multiple Customizations..............................................................................71
Incident Mapping..............................................................................................72
Global Event Information ............................................................................75
The Event Mapping Rules ..........................................................................76
How to use the Computed Variables ..........................................................88
Test Case..................................................................................................104
How to discard NNMi Incidents that need not be sent to TeMIP?............106
TeMIP Similarity and Clearance ....................................................................107
Incident Definition Taking into Consideration TeMIP Clearance ..............107
Incident Definition Using the Notification Identifier ...................................109
Specific Use Cases........................................................................................110
How to Support Proxy Management.........................................................110
How to Support Multiple Indexes Naming ................................................113
Customization Management Rules................................................................113
Custom Deployment Use Case Example .................................................115
Migrating to ATNI V6......................................................................................115
How to Migrate from ATNI V540...............................................................115
How to Migrate from IST Customization ...................................................115
Recommendation...........................................................................................116
Limitations ......................................................................................................116
Chapter 5 Generating a TNT Runtime Kit .................................................118
5.1 The Customization Package Tool..................................................................118
5.1.1
The tnt_custom_tool Usage......................................................................119
5.1.2
The tnt_custom_tool Input ........................................................................119
5.1.3
The Runtime Kit Validation Process .........................................................119
5.1.4
The tnt_custom_tool Output .....................................................................122
5.2 Generating a Runtime Kit Example ...............................................................123
5.2.1
Preparing the Topology Filter File.............................................................123
5.2.2
Building the Runtime Kit ...........................................................................123
Chapter 6 Deploying a TNT Runtime Kit ...................................................125
6.1 Introduction ....................................................................................................125
6.2 Deploying a New TNT Runtime Kit ................................................................126
6.2.1
The tnt_rt_create_nnm_am_application.sh Script ....................................126
6.2.2
The tnt_rt_create_nnm_am_application Prerequisites .............................127
6.2.3
The tnt_rt_create_nnm_am_application.sh Usage...................................127
6.2.4
A tnt_rt_create_nnm_am_application Example........................................130
6.2.5
The tnt_rt_create_nnm_am_application Output .......................................131
6.3 Updating an Already Deployed TNT Runtime Kit ..........................................132
6.3.1
The tnt_nnm_am_load_custom.sh Script .................................................132
6.3.2
The tnt_nnm_am_load_custom Prerequisites ..........................................133
4
6.3.3
The tnt_nnm_am_load_custom Usage.....................................................134
6.3.4
A tnt_nnm_am_load_custom Example .....................................................136
6.3.5
The tnt_nnm_am_load_custom Output ....................................................136
6.3.6
Tips when updating Event Mapping only (tuning).....................................137
6.4 Removing a Deployed TNT Runtime Kit........................................................137
6.4.1
The tnt_rt_delete_nnm_am_application.sh Script ....................................137
6.4.2
The tnt_rt_delete_nnm_am_application Prerequisites .............................138
6.4.3
The tnt_rt_delete_nnm_am_application Usage........................................138
6.4.4
An tnt_rt_delete_nnm_am_application Example ......................................138
6.4.5
The tnt_rt_delete_nnm_am_application Output .......................................138
Chapter 7 Configuring the NNM Views within TeMIP Client....................139
7.1
7.2
7.2.1
7.2.2
7.3
7.4
Manual Configuration.....................................................................................139
Automatic Configuration.................................................................................140
The tnt_launch_generation.sh Script ........................................................140
The Launch Generation Tool Process ......................................................144
How to Add a new NNMi View in TeMIP Client? ...........................................151
Interaction with TeMIP NNMi Advanced Integration Plug-in..........................154
Chapter 8 Troubleshooting .......................................................................158
8.1
8.1.1
8.1.2
8.2
8.2.1
8.2.2
8.2.3
8.2.4
8.2.5
8.3
8.4
8.4.1
8.4.2
8.4.3
8.4.4
TNT Customization Toolkit.............................................................................158
The tnt_custom_gen Tool .........................................................................158
The tnt_custom_tool Tool .........................................................................160
TNT Deployment Tools ..................................................................................169
The tnt_rt_create_nnm_am_application.sh Script ....................................169
The tnt_nnm_am_load_custom.sh Script .................................................171
The tnt_rt_delete_nnm_am_application.sh Script ....................................172
The TNT Launch Generation Tool ............................................................172
The TNT Launch Publication Tool ............................................................174
TeMIP Client TeMIP NNMi Advanced Integration Plug-in (TNT Plug-in) ......174
NNMi View Integration ...................................................................................175
How to Check the TeMIP TNT Plug-in is Installed and Running..............175
How to Check the Configuration in the TeMIP Client ...............................176
TNT Plug-in Can not Find the Director or Stations ...................................177
Can not Access the NNM Home Base......................................................178
Appendix A The Customization File..........................................................179
A.1 Customization DTD............................................................................................179
A.2 Customization File format ..................................................................................185
Appendix B The Entity Model File .............................................................191
B.1 The Entity Model DTD .......................................................................................191
B.2 The Entity Model File Format.............................................................................191
B.3 The Entity Model Default File.............................................................................193
Appendix C Launch Generation Tool........................................................196
Appendix D Launch Applications Configuration File Format .................203
Appendix E TNT Plug-in System Configuration File Format...................205
E.1
E.2
Versioning ......................................................................................................205
General Resources ........................................................................................205
5
E.3
E.4
Alarm Object Custom Fields ..........................................................................205
NNMi Views Resources .................................................................................206
Glossary ......................................................................................................212
6
Figures
Figure 1
Figure 2
Figure 3
Figure 4
Figure 5
Figure 6
Figure 7
Figure 8
Figure 9
Figure 10
Figure 11
Figure 12
Figure 13
Figure 14
Figure 15
Figure 16
Figure 17
Figure 18
Figure 19
Figure 20
Figure 21
Figure 22
Figure 23
Figure 24
Figure 25
Figure 26
Figure 27
Figure 28
Figure 29
Figure 30
Figure 31
Figure 32
ATNI Conceptual Architecture ....................................................................... 14
An overview of the Event Mapping rules ....................................................... 21
Global picture of the customization process .................................................. 24
A TNT Toolkit Conceptual view...................................................................... 25
The TNT customization toolkit presentation .................................................. 26
TNT tools in detail .......................................................................................... 27
NNMi Views Integrated into the TeMIP Client ............................................... 28
TeMIP-NNM Advanced integration Overview ................................................ 29
The TNT plug-in Options Tab ........................................................................ 30
Selecting the Non Contextual NNMi Views.................................................... 31
Selecting the Contextual NNMi Views ........................................................... 32
Alarm Drill-down – Tree of Correlated Events ............................................... 33
An overview of the Launch Generation Tool.................................................. 34
TeMIP Services integrated into NNM Menu .................................................. 35
Designing a customization using the tnt_custom_gen tool............................ 36
Generated Entity Model from SNMP MIB Tree Hierarchy ............................. 48
An example of the SNMP MIB Tree Hierarchy .............................................. 49
Corresponding Entity Model........................................................................... 50
Generating a Runtime kit using the tnt_custom_tool................................... 118
The deployment process overview [ Venkt] ................................................. 125
Overview of the Launch Generation Tool .................................................... 141
The launch menu integration of the NNM views .......................................... 145
The launch generation rules example.......................................................... 146
Publishing the Launch definition file using the TeMIP resource server ....... 149
Overview of the TNT Plug-in integration...................................................... 154
The TeMIP Client about dialog box ............................................................. 175
TeMIP Client Patch and Versions dialog box .............................................. 176
TeMIP TNT Plug-in Options......................................................................... 177
Home Base Port checking command .......................................................... 178
Overview of the Customization DTD using XML tags.................................. 186
An overview of the Entity Model XML file .................................................... 192
A representation of the default Entity Model................................................ 195
7
Tables
Table 1 Acronyms and their Description.................................................................................. 10
Table 2
The runtime kit structure ................................................................................ 23
Table 3
The custom_gen_tool usage.......................................................................... 37
Table 4
The tnt_mib_scanner usage .......................................................................... 40
Table 5
NNM Predefined Variables ............................................................................ 43
Table 6
Event Severity mapping ................................................................................. 51
Table 7
Event Type mapping ...................................................................................... 51
Table 8
Probable Cause mapping table...................................................................... 51
Table 9
The default data type values.......................................................................... 53
Table 10
Auto Population attribute values .................................................................... 54
Table 11
The default Auto Population attributes........................................................... 54
Table 12
Custom deployment possible scenarios ...................................................... 115
Table 13
The tnt_custom_tool usage.......................................................................... 119
Table 15
The tnt_rt_create_nnm_am_application.sh usage ...................................... 127
Table 16
The tnt_nnm_am_load_custom.sh usage.................................................... 134
Table 17
The tnt_rt_delete_nnm_am_application.sh usage....................................... 138
Table 18
NNM view with PathView on a Map Viewer................................................. 139
Table 19
Pop-up only a MB3 menu for the customized classes................................. 140
Table 20
The tnt_launch_generation.sh usage .......................................................... 141
Table 21
Launch Definition Template - Supported Keywords .................................... 147
Table 22
The tnt_launch_publication.sh usage .......................................................... 150
Table 23
Examples of Non Contextual View callback ................................................ 155
Table 24
Examples of the Contextual View callback .................................................. 156
Table 25
Error messages for the tnt_custom_gen tool............................................... 158
Table 26
Error messages for the tnt_custom_tool tool ............................................... 160
Table 27
Error messages for the tnt_rt_create_nnm_am_application.sh script ......... 170
Table 28
Error messages for the tnt_nnm_am_load_custom.sh script ...................... 171
Table 29
The tnt_rt_delete_nnm_am_application.sh Error Messages ....................... 172
Table 30
Error messages for the Launch Generation Tool......................................... 172
Table 31
Error messages for the Launch Publication Tool......................................... 174
Table 32
TeMIP Client Level Trace Mask................................................................... 174
Table 33
TeMIP Client TNT Plug-in Trace Mask ........................................................ 174
Table 34
The launch definition file grammar............................................................... 203
Table 35
TNT configuration versioning ....................................................................... 205
Table 36
TNT configuration general resources .......................................................... 205
Table 37
Alarm Object custom fields .......................................................................... 205
Table 38
Resources for the NNMi views..................................................................... 206
Table 39
NNMi Dynamic views ................................................................................... 207
8
Preface
This guide describes how to use the Customization toolkit that is provided with the
TeMIP-NNMi Advanced Integration (ATNI).
After defining the concept of ATNI Customization, the guide presents a methodology
that helps the user to design, create, update, install, and use a Customization in an
ATNI context. Of course, each important part is illustrated by examples.
The Default customization will be often used as reference but the purpose of this
document is to help the user to design a new customization that matches both the
Topology and Event Mapping requirements.
This guide assumes that the ATNI has already been installed. For information on how
to install ATNI, refer to the HP TeMIP NNMi Advanced Integration Installation and
Configuration Guide.
All SNMP capabilities are delegated to NNMi that acts as Mediation layer.
Knowledge of SNMP, such as, knowledge of MIB or SNMP traps is a not necessary
to really take benefit from the entire toolkit, it is recommended. This document
provides neither SNMP nor NNMi background information. For further information
on the topic, please refer to the documentation in the Associated Documentation.
Intended Audience
This document is aimed at the personnel who want to integrate new equipment or
new events into the TeMIP-NNMi Toolkit.
System Administrators
SNMP Agent Developers or network equipment Integrators
Prior knowledge of TeMIP and NNMi is a prerequisite to fully appreciate the
contents of this document.
Software Versions
The term UNIX is used as a generic reference to the operating system, unless
otherwise specified.
The following table lists the software versions referred to in this document:
Product Version
Operating Systems
TeMIP NNMi Toolkit V6.00
HP-UX Itanium 11.31 and RHEL AP 5
Update 2 (Customization toolkit, TeMIP
Adapter, NNMi AM),
TeMIP Framework V6.00
HP-UX Itanium 11.31, and RHEL AP 5
Update 2,3 & 4 (TeMIP Framework)
TeMIP Client V6.1 L01
Windows (TeMIP Client + TNT Plugin)
NNMi V 9.0
HP-UX Itanium 11.31, and RHEL AP 5
Update 2
9
Typographical Conventions
Courier Font:
Source code and examples of file contents.
Commands that you enter on the screen.
Pathnames
Keyboard key names
Italic Text:
Filenames, programs and parameters.
The names of other documents referenced in this manual.
Bold Text:
To introduce new terms and to emphasize important words.
Associated Documents
 HP TeMIP Software Client Overview
 HP TeMIP Software Client Integration Applications into the TeMIP Desktop
For a full list of TeMIP user documentation, refer to Appendix A of the HP TeMIP
Software Product Family Introduction.
Acronyms
Table 1 lists the acronyms used in this document.
Table 1 Acronyms and their Description
10
Acronym
Description
ACS
Alarm Collection Server
AHFM
Alarm Handling Functional Module
AM
Access Module
AO
Alarm Object
APA
NNMi Active Problem Analyzer
ARP
Advanced Resolution Protocol
ATNI
TeMIP NNMi Advanced Integration
CIA
Custom Incident Attribute in NNMi
CA
Custom Attribute for Nodes in NNMi
CONF
Configuration File Format
DTD
Document Type Definition
FCL
TeMIP Framework Command Line
FM
Functional Module
FTM
TeMIP Fault Management
HSRP
Hot Standby Router Protocol
IA
Itanium
Acronym
Description
JAR
Java Archive
JDK
Java Development Kit
LRF
Local Registration File
MIB
Management Information Base
NAT
Network Address Translation
NNMi
HP Network Node Manager i Software
OAD
Overlapping Address Domain
OSI
Open System Interconnection
PM
Presentation Module
PSF
Product Specification File
SNMP
Simple Network Management Protocol
TAL
TeMIP Access Library
TNT
TeMIP NNMi Toolkit
UUID
NNMi Unique Universal Identifier
WAR
Web Application Archive
WSDL
Web Service Definition Language
XML
Extensible Markup Language
Support
Please visit our HP Software web site at: www.hp.com/go/hpsoftwaresupport
There you will find contact information as well as details about the products, services,
and support HP Software has to offer.
The HP Software support area of the HP Software web site includes:
 Troubleshooting information
 Patches and updates
 Problem reporting
 Training information
 Support program information
11
Chapter 1
Introduction
The purpose of this chapter is to give the user the necessary foundation required
before reading this document by providing a brief overview of the HP Software
TeMIP NNMi Advanced Integration (ATNI). This chapter also presents an overview
of the Customization Guide.
The following parts will be developed

1.1 Introduction to ATNI

1.2 ATNI Architecture

1.3 How Does ATNI Work?

1.4 Why the Need to Customize?

1.5 An Overview of the Customization Guide
For a more detailed and complete overview of ATNI it is recommended that the user
reads the TeMIP NNMi Advanced Integration Overview document.
1.1 Introduction to ATNI
HP Software family provides two products, HP TeMIP platform for
Telecommunications networks management and HP Network Node Manager i
Software for IP networks management. Currently, more and more
Telecommunication networks rely on IP equipment. The seamless integration of
NNMi within TeMIP gives TeMIP users more evolved IP capabilities allowing them
to manage fully their network.
NNMi offers the following sophisticated features:
 Automatic discovery of the network i.e. IP Discovery layer 3 and 2,
 Support for many types of devices by using SNMP MIBs
 IP Node polling and monitoring,
 Advanced correlation services (Root Cause Analysis and Service Impact
Analysis)
 Web interfaces
 Smart Plug Ins dedicated to one specific technology such as VPN PMLS, IP
Telephony.
The purpose of this seamless integration is to leverage all capabilities of NNMi
within TeMIP. It gives TeMIP the following additional features:
 To translate SNMP traps into TeMIP OSI alarms with a sophisticated and usercustomizable mapping.
 To automatically populate SNMP managed devices within TeMIP
 To integrate the NNMi Web GUI within the TeMIP Client
12
 To leverage NNMi correlation within TeMIP which allows the user to pinpoint
the NNMi original problem events (Drill-down capability)
 User facilities to design, develop and install a customization (ATNI toolkit)
 Special operations allowing the user the ability of Topology and Event
resynchronization.
The ATNI integration is based on the NNMi Topology information. HP NNMi
Advanced Topology functionalities discover layer 2 devices information and display
device connectivity.
Within an ATNI configuration, all IP management is handled by NNMi, including
discovery, configuration, traps reception, event correlation and SNMP polling.
TeMIP offers a new Management Module (Access Module), the NNMi AM which
allows for an in-depth hierarchical model similar to the IST 1 model, including alarm
generation and status management.
The TeMIP Adapter resides along side NNMi and is responsible for communicating
the NNMi information to TeMIP. The communication between the TeMIP Adapter
and TeMIP is a Web-Service based communication allowing a reliable and firewall
friendly transport.
Finally, ATNI provides a seamless integration of the Web NNMi GUI within the
TeMIP Client. The NNMi Views describes the family of browser-based views whose
content is created as result of choices the users makes when they launch the view, and
which continue to provide the most current status information. NNMi Topology
presents detailed layer 2 network information, ATM information, VLAN information,
and others in several specific Views. ATNI integration allows displaying them inside
the TeMIP Client.
1.2 ATNI Architecture
Looking at the diagram below the following components are of interest:
 The Customization Toolkit
 The Master NNMi AM
 The NNMi AM Clone
 The TeMIP Adapter
 Integration of the NNMi Web GUI within the TeMIP Client
1.
1
IST is an acronym for Internet SNMP Toolkit
13
Figure 1
ATNI Conceptual Architecture
TeMIP Client
ATNI Toolkit
Custom Tools
(generation,
install, GUI
config)
PM
TeMIP Framework
FM
FM
FM
Admin
Tools
Topology
Utilities Tools
ATNI plugin
NNM AM
Clones
NNM AM
Master
http
TeMIP Adapter
Drilldown
NNMi W-S Layer
NNMi
The ATNI product is composed of the following:
NNMi AM
This mandatory Access Module implements the default MSL model that represents
the IP equipment. Its associated customization package (deployed to the TeMIP
Adapter) provides the mapping for the NNMi Status events so that the NNMi AM can
generate the corresponding OSI alarms.
NNMi AM clone
This optional Access Module implements a user specific entity model and its
associated package contains the specific event mapping for managing this equipment
or network service managed through NNMi.
TeMIP Adapter
The TeMIP Adapter is an integral component of the NNMi platform. This adapter is
responsible for collecting NNMi information and translates IP Status events (SNMP
traps) into OSI type messages based on the deployed customizations.
GUI Seamless Integration
NNMi Web GUI’s (Launch URL’s) are integrated within the TeMIP Client. The user
also has the ability to display correlated NNMi events associated to one top level
TeMIP alarm (Drill-down feature). This feature could be used for Root Cause
Analysis.
14
Customization Toolkit
This toolkit contains a set of tools that enables and helps the user to design a
customization and to generate an associated Runtime kit with the intention of
installing it.
1.3 How Does ATNI Work?
The term customization is used to describe a set of rules that allows the user to
manage a certain type of network equipment or service. While the customization
process is explained further on in this document it is important at this stage to
introduce some basic concepts before progressing.
In its basic form, the customization is a set of rules that allows ATNI to manage
specific network equipment or a specific service. These rules are defined in an XML
file called a customization.xml and it is principally made up of three main types of
rules or definitions:
 The Entity Model definition
 The Event Mapping Rules
 The Auto Population Rules
The TeMIP Entity Model that is defined corresponds to the TeMIP Entity tree for the
customization and any of the global or child class instances within the TeMIP Enity
Model becomes the managing object for the generated OSI alarms.
The Event Mapping rules describe the set of rules that are used to translate the NNMi
SNMP traps and management incidents to their corresponding OSI alarm equivalents.
The rules define which traps or management incidents will be managed and how they
are mapped.
Finally, the Auto Population rules describe the naming rules that enable ATNI to
discover, register, and create the necessary TeMIP Entities corresponding to the
NNMi Nodes in the managed network. The customization designer can define which
IP Devices (NNMi nodes) will be populated into TeMIP using an associated naming
rule.
After the installation of ATNI there is no required user customization. Once the
Default customization package is installed, it automatically collects traps coming
from NNMi. A default TeMIP Entity model has been defined to represent as close as
possible any IP device.
NNMi discovers automatically new IP devices in the managed network. TeMIP
Adapter retrieves the user selected IP Devices (NNMI node) previously discovered
and communicates them to the NNMi AM that will populate the corresponding
TeMIP NNMi_NODE entities. The TeMIP naming of these selected NNMi nodes are
stored in the NNMi database. The TeMIP Adapter collects both the SNMP traps
originating from these IP devices (via NNMi) and management incidents generated
by NNMi. It then translates them into OSI type messages using the rules defined in a
customization. The NNMi AM polls the TeMIP Adapter to retrieve the messages and
generates associated TeMIP OSI alarms.
From TeMIP Client, the user has the possibility to have Layer 2 diagnosis of the
network problem in accessing NNMi Views. For example, when selecting an alarm
from the TeMIP Alarm Handling such as Router If Down, he can display the
associated specific NNMi view (such as a neighbor view) in which the Topology is
present. Within this selected view he can then use the standard NNMi tools to identify
the faulty node in question (it could be a switch for example). Then when selecting
this node he can locate the entity using the geographical view options within TeMIP.
15
1.4 Why the Need to Customize?
The default package provides a default TeMIP model and default processing for any
enterprise SNMP trap. The Customer environment may contain specific Network
equipment and in that case, the default package is too generic as follows:
 The default model is not sufficiently specialized meaning that it does not closely
represent the IP device equipment (SNMP MIB) in the managed network
 There is only one generic mapping rule to map all specific SNMP Traps
originating from this equipment
For all the reasons above, ATNI provides the ability to customize. Based on specific
MIB information corresponding to the IP equipment, a new TeMIP model may be
generated accordingly. The associated rules for mapping SNMP traps will be adapted
to benefit from this new model and take all SNMP equipment information such as
events content into account.
The Customization process helps the user to design, develop, generate, and install a
Customization package corresponding to their specific equipment in an ATNI
configured environment. ATNI provides a set of tools to facilitate the user in the
Customization process and the purpose of this document is to go into detail on how to
use these tools.
1.5 An Overview of the Customization Guide
The purpose of this document is to provide the customization designer all the correct
knowledge and theory that will enable them to develop a customization that matches
their network configuration needs.
The first part of the document will introduce the customization concept and give an
overview of the customization and the ATNI tools used to design and develop the
runtime kit. Also, an introduction to the NNMi GUI integration within the TeMIP
client is presented.
The next part of the document explains how to generate a customization template
followed with a more detailed chapter on how to manually modify this customization
to match the users’ requirements. Then the document proceeds to detail how to
generate a runtime kit and deploy it.
Following on from this the document presents a more detailed view of the NNMi
GUI integration within the TeMIP client and on how to configure this integration to
match the users needs.
The final chapter in document is for troubleshooting which can be used as reference
by customization designer in the case of difficulties occurred.
16
Chapter 2
Customization Context
The purpose of this chapter is to present a global picture of the ATNI customization
concept along with all its possible configurations.
The first part of this chapter will introduce the Customization concept which includes
an introductory presentation of the complete process of developing and applying a
customization. The final section then focuses on the integration of the NNMi Views
into TeMIP Client.
The TNT Customization Toolkit provides a set of tools that allows the user to
customize, configure, and adapt their configuration data enabling a complete
integration of TeMIP and NNMi.
The customization toolkit is divided into two different tool sets each having separate
roles:
 The “ATNI out-of-the-box” customization that is implemented as a default
package. This is package is installed by default and allows TeMIP to
communicate with NNMi (to retrieve NNMi node, to catch and map NNMi trap
and incident)
 The TeMIP Client GUI customization that enables all of the NNMi views to be
embedded easily within the TeMIP client
A certain subset of the tools is designed to facilitate the user in developing their own
customization. For example, it is possible to automatically generate a customization
package given certain NNMi information such as the Incident Configuration file and
from SNMP MIB files loaded. This package then requires manually intervention
needing further customization in order to map specific SNMP devices discovered
during the NNM Topology selection process and for specific mapping of SNMP traps
or management incidents.
Finally, a tool is provided that will automatically generate the Launch file that is
necessary for the GUI navigation needed to navigate the NNMi GUI integrated with
the TeMIP client.
The following sections will be discussed in more detail:
 Section 2.1 Concept of the ATNI Customization
 Section 2.2 Integration of the NNMi Views into TeMIP Client
2.1 Introduction to the Customization
Concept
The term customization is used to describe a set of resources and rules that enables
the user to manage specific network equipment or service. The customization
provides specific rules for the management of the network equipment topology and
the management of events originating from this equipment. The implementation of
the customization corresponds to a package that contains all the necessary
17
information required to take into account any new or existing equipment or service
within each level of its architecture (the event and topology mapping and naming).
One important aspect of the customization is the Entity Model definition that enables
the implementation of a TeMIP global class hierarchy which provides the following
features:
 Enables the operator the possibility to have a “fine grain model” which means the
user can define a topology node model by adding relevant specific equipment or
service that corresponds to it.
 Allows the possibility to specify suitable mapping for all or specific NNMi
incidents in the associated model. Each NNMi incident must use a specific
grammar to determinate what are the values of the different output OSI-like fields.
The grammar offered could be based on predefined variables or incident content.
ATNI provides a customization by default and it is referred to as the default
customization and it corresponds to the implementation of the NNMi AM Master that
is installed by default when installing ATNI.
2.1.1
The ATNI Customization File Definition
In its basic form, the customization is a set of rules that allows ATNI to manage
specific network equipment or a specific service. These rules are defined in an XML
file call the customization.xml and this information permits ATNI to generate a
TeMIP model corresponding to the SNMP equipment discovered being managed by
NNMi and to map SNMP traps originating from this equipment or management
incidents originating from NNMi
The customization XML file is packaged with other required input files such as the
NNMi filter file and the NNMi Incident configuration file. This package is known as
a customization package and it is loaded by the TeMIP Adapter component that
interfaces with NNMi and this rule based knowledge is used to process the topology
selection and event mapping.
The NNMi AM is a generic management module that implements any customization
package. The NNMi AM master implements the default customization that is
installed as part of the ATNI installation. An NNMi AM module that implements any
customization package other than the default package is known as an NNMi AM
clone.
The following sections give a brief overview of the different parts of the
customization XML file. The complete customization configuration will be explained
in more detail in Chapter 4 Updating the Customization.
The customization XML file is principally made up of the following set of different
rules or definitions:
 The properties of the customization
 The customization deployment
 The TeMIP model definition
 The topology automatic discovery configuration
 Incident management
2.1.1.1
The Properties of the Customization
The purpose of this information is to facilitate the user in providing useful
information for naming and managing their customization.
18
The properties of the customization are as follows:
 The name or identifier of the customization. This is also used for versioning.
 The name of the TeMIP global class that the customization corresponds to.
 A list of revisions made to the customization ordered by date and time.
 The date and time.
 The author of the customization.
 The description of the customization.
2.1.1.2
The Customization Deployment
The customization deployment definition contains the information required for the
installation and deployment of the customization. It mainly defines all the TeMIP
objects that need to be created in order to prepare the TeMIP environment. This
enables TeMIP to be populated with any discovered NNM nodes and in a ready state
to collect alarms generated from these populated objects:
Default Entities: This definition sets the default entities name for
OPERATION_CONTEXT, DOMAIN, and entity classes. It also sets the Managing
Director of these OPERATION_CONTEXT and DOMAIN entities.
2.1.1.3
The TeMIP Model Definition
The TeMIP entity model definition contains all the necessary TeMIP information
required to implement the TeMIP model corresponding to the SNMP device
discovered and managed by NNMi in partnership with the TeMIP Adapter. The
TeMIP entity model that is defined is a TeMIP tree that corresponds to the
customization of the SNMP devices and any of the global or child class instances
within the TeMIP Entity Model becomes the managing object for the generated OSI
alarms.
It also defines the necessary properties of the NNMi AM clone that implements the
customization.
The AM Definition
The AM definition contains the following AM information:
 Application Identifier.
 Application Name.
The above properties of the AM should be unique.
The Entity Model
The customization corresponds to the implementation of a TeMIP global class and so
this information is mandatory. This definition contains the:
 Global class customization.
 Any child classes of the global class.
The designer can define the entity model by either:
 Modifying the default equipment model.
 Merging the current model with a MIB tree hierarchy.
2.1.1.4
The Topology Automatic Population Configuration
This auto population definition describes the naming rules enabling ATNI to
discover, register, and create the necessary TeMIP entities corresponding to the
19
NNMi nodes in the managed network. The customization designer can define which
IP devices (NNMi nodes) will be populated into TeMIP and how they are named
using an associated naming rule.
Its main purpose is to indicate what NNMi nodes are to be selected and populated
into TeMIP and how they are to be named within TeMIP.
This is implemented using a naming rule that defines the following information:
 The TNS directory for naming the Topology object
 The name of the domain in which the populated objects are automatically created
as members which will allow for automatic collection.
 The optional Domain managing director.
 The Operation Context name that uses the domain name as a collection domain.
 The optional Operation Context managing director.
 The NNMi filter name that is used to select the NNMi filter. This filter defines the
criteria for selecting certain IP devices based on their Node properties.
The auto population definition can contain one or more naming rules.
2.1.1.5
Incident Management
Within the customization XML file the Incident management rules are defined in the
following parts:
 The retention policy of the incident
 The event mapping of the incident
Firstly, the retention policy enables ATNI to implement a retention policy for any
incident being mapped. This means that it is possible to prioritize the event after the
mapping depending on the severity of the incident. The event messages are retained
for a specific time in accordance to the severity of the incident instead of being
directly propagated to the NNMi AM.
Finally the event mapping rules describe the set of rules that are used to translate the
NNMi Incidents (SNMP traps or management incidents) to their corresponding OSI
alarm equivalents. The rules define which traps will be managed and how they are
mapped. A mapping contains a set of rules that make up the final TeMIP OSI alarm
that is generated. As described in the diagram below an Event Mapping rule is
composed of three different rule types:
20
Figure 2
An overview of the Event Mapping rules
The Event mapping Rule
For each incident being managed, it is possible to define a single dedicated mapping.
A single event mapping rule contains the following information and definitions:
 The Incident name of the SNMP trap or management incident being managed or
mapped
 The trap OID of the SNMP trap being managed or mapped

The mandatory Managed Object rule that corresponds to the Managed Object of
the final OSI alarm (target entity). This rule is based on:

either a list of class instance definitions that corresponds to TeMIP entity
levels

or a definition where the children classes part is defined under String form.
It is possible to have a managed object rule that targets the event to an associated
TeMIP model (independent of the SNMP MIB tree) .For example on the
NNM_CONFIGURATION NNM_STATION instance.
 The TeMIP Enumeration rules correspond to the different OSI alarm attributes
(one rule for each attribute) that results in an enumeration or integer. Below is the
list of the mandatory OSI fields:
 The Event Type OSI field (generally corresponds to NNMi Category field in
the Incident)
 The Probable Cause OSI field
 The Perceived Severity OSI field (generally corresponds to NNMi Severity
field in the Incident)
 The TeMIP enumeration rule can also be used to map other OSI attributes
such as the Specific Problem OSI field, Notification Identifier and the
Correlation Notification Identifier etc.
 The Additional Text rule corresponds to the Additional Text of the final OSI
alarm. It is possible either to specify the Message text from the NNMi incident or
21
to define a free text (containing NNMi incident variable and/or computed
variable) or to depend on the result of a computed variable.
Computed Variables
Any OSI field can be based on following mapping type:
 either a Constant
 or a Mapping Table (simple correspondence table)
 or a Trap/IncidentVariable (varbind of the trap or Variable in the Incident or CIA
in the Incident)
 or depend on the computation of a variable. Any ‘computed’ variable can be
either a Condition expression (If/Then/Else structure) or a Regular expression or a
Switch (included several cases) or an External variable (Java code developed
separately and packaged into the Runtime Time kit).
This specific part contains the list of all ‘computed’ variables used by the trap. It may
be possible to define ‘global’ computed variable for which the scope is the entire
customization file.
Test Cases for SNMP Traps
The event mapping rules not only include the rules required to map specific SNMP
traps but they also provide a facility to test the mapping for testing them. The user can
define test cases within the event mapping rules with contain information required to
emit a specific SNMP Trap that permits the user to troubleshoot the event and check
if the rule mapping functions as expected.
The Default Flag
One important aspect of the Event Mapping rules is the default flag. There must be
one and only one default event mapping rule within the customization XML file. The
value of the default flag can be either true or false and indicates if the current rule is
the default. The default event mapping is used to map SNMP traps or incidents that
have no specific mapping rules defined within the customization.
2.2 Introduction to the TNT Runtime Kit
The TNT runtime kit is a JAR file structured package and it contains resources
required by the NNMi AM and TeMIP Adapter. These resources are shared by all
components meaning that each component will get its required information from
within the JAR file under the appropriate directory. The naming convention of the
TNT runtime kit is as follows:
<class name>_<customization identifier>.jar
For example, in the case of a CISCO configured network where the version of the
customization is V1 we have the following:
Example 1
A TNT runtime kit naming for a CISCO configured network
CISCO_V1.jar
In the above example the <class name> and the <customization identifier>
information is retrieved from the customization XML file stored in the JAR file. The
runtime kit is a JAR file composed of three directories each having a specific
purpose:
22
Table 2
The runtime kit structure
Directory
Description
/input
This contains all data, except for the MIB Modules. This data is
used to create the customization. It is included for traceability
and to keep a backup.
/output
This contains all the generated data required by the NNMi AM
and the TeMIP Adapter components. It includes the
customization XML file.
/external
This usually contains all other forms of data, including for
example optional additional information such as
documentation.
A more detailed examination of the purpose of this structure will be presented further
on in this chapter.
2.2.1
The Input Directory
The input directory contains all the data used to create the runtime kit and this data is
saved under this directory for tracking purposes. It contains the following files:
 TNT Filter files (mandatory)
 TNTNNMiIncidentConf.xml :- NNMi Incident Configuration (optional)
 tnt_external_lib.jar (optional)
This directory should contain a NNMi topology filter files based on the filter names
specified in the entity naming rules in the customization. The filter files should be of
the following naming format.
<Filter name>.xml
For each of the filters specified in the naming rule a filter file is mandatory in the
input directory. The filter file should contain the criteria for what nodes should be
selected for the specific naming rule in the discovery process.
The selection of IP Node that the user intends to manage relies on the usage of the
NNMi filter. This filter defines criteria for selecting certain devices based on the
attributes of the NNMi Node such as the name of the device or its manufacturer or
capability. For example this criterion could be a range of DNS naming.
It uses the NNMi Node filter grammar to define class selectors which are used to
identify which nodes should be mapped into instance or instances of the global class.
The directory can also contain optionally a NNMi Incident configuration file
generated from the /opt/OV/bin/nnmconfigexport.ovpl tool (using the –c “incident” –
f “TNTNNMiIncidentConf.xml” option). This file contains the configuration and
descriptions for all Incidents available in NNMi.
This directory can also contain optionally an external library called
tnt_external_lib.jar. This file contains the source code of the external variables
defined in the customization.xml file (External Computed variable).
2.2.2
The Output Directory
The output data can contain the following files:
 customization.xml (mandatory)
The customization XML file is mandtory and it corresponds to the input
customization file provided to the tnt_custom_tool tool. The content of this XML file
will be validated and its name changed to customization.xml. For more details about
23
the contents of this file, see Error! Reference source not found. Error! Reference
source not found..
2.2.3
The External Directory
The external directory can be used to store user specific data such as documentation.
The user can manually add resources into this folder if required. Any resources
provided should be OS independent. This is because the runtime kit has been
designed to be OS independent and the user has the responsibility to ensure this.
Also, the designer is responsible to ensure that all resources included are valid before
generating the runtime kit.
2.3 Introduction to the TNT Custom Toolkit
The purpose of this section is to introduce the TNT custom toolkit and to present the
general methodology that is used when developing a customization. Also, all tools
required for each step in the process will be introduced.
2.3.1
The TNT Customization Methodology
The Customization process helps the user to design, develop, generate, and install a
Customization package corresponding to their specific equipment in an ATNI
configured environment. ATNI provides a set of tools to facilitate the user in the
Customization process. This process is split into four main steps as shown in the
figure below:
Figure 3
Global picture of the customization process
These steps above entail the following:
24
1. The first step is the automatic generation of the Customization template files by
taking SNMP equipment information in the formal of MIB modules already loaded in
NNMi as an input, along with NNMi Incident configuration if provided.
2. The second step is a manual operation where the user can update the auto
generated template files so that they will better fit their specific requirements.
3. The third step is the generation of a runtime kit corresponding to the
Customization.
4. The fourth and final step is the installation of this Customization runtime kit.
2.3.2
Introduction to Customization Toolkit
The TNT customization toolkit is mostly responsible for the creation of a
customization and for generating a runtime kits that will be deployed to a TeMIP
director as shown in figure below:
Figure 4
A TNT Toolkit Conceptual view
Once the runtime kit is generated, the user can install it to their intended TeMIP
platform. As different resources from the package need to be installed to different
locations within the ATNI environment, ATNI provides a tool to facilitate this
process.
The diagram below shows the role of the TNT tools within the customization process
workflow. It outlines the process used to generate and deploy a new runtime kit to a
TeMIP director.
25
Figure 5
The TNT customization toolkit presentation
Incident Configuration
MIB Modules
[Entity Model]
Runtime
Use
TNT
Tools
Contains
Customization
file
Generate
Designer
Runtime
TeMIP
Director
Adapter
--NNM
Station
NNM
NNM
AM
Deploy
runtime
System
Integrator
TeMIP
As outlined in the above diagram, the role of the TNT customization toolkit is to help
the Designer to create an NNMi AM runtime kit from resources such as incident
configuration, MIB data, and optionally an Entity Model file.
The TNT customization toolkit is composed of the following tools:
 The tnt_custom_gen tool
 The tnt_custom_tool tool
The diagram below illustrates in more detail how these tools are used to ultimately
create a runtime kit from the required resources such as the incident configuration and
or the MIB data.
26
Figure 6
TNT tools in detail
The figure above displays the steps necessary to create a TNT runtime kit:
Firstly, the tnt_custom_gen tool is used to generate a template customization file from
input data such as incident configuration and or from MIB data and optionally from
an Entity Model file and a template filters file.
The user then modifies the generated template customization file and the template
filters file with an XML editor of his choice.
Important Note
The TNT customization toolkit does not provide a tool that enables the user to modify
or update the customization.xml. User has to manually modify the customization
using xml editors.
The tnt_custom_tool tool is then used to generate a runtime kit from the following
resources:
 The user updated customization.xml file
 The user updated NNMi Topology filter files
 An optional external library
 An optional Incident configuration file.
After introducing the customization concept, this guide will then focus on how to
design a customization (Chapter 3). The purpose of this chapter is to help the designer
understand the necessary steps required to generate a new customization
corresponding to their requirements based on MIB, type of managed equipment and
specific incident mapping.
Then Chapter 4 narrows the focus to the internal content of the customization XML
file. All XML fields will be described in detail enabling the designer to modify the
customization to match their specific customer requirements.
After, the life cycle of the Customization is continuing with the generation of the
Runtime kit (that is installed physically in Customer platform) in the Chapter 5 and
its deployment in the Chapter 6.
27
2.4 Integration of NNM Views into TeMIP Client
2.4.1
Overview
As part of the TeMIP-NNMi Advanced Integration the TeMIP Client displays the
maximum NNMi views such as the NNMi console views, Incident views called
Launched URL’s. These NNMi views are seamlessly integrated along with others
TeMIP Plug-ins and it can be customized to modify the Graphical User interface.
TeMIP Client Advanced Integration (TNT) Plug-in provides within the TeMIP
desktop a bi-directional contextual integration of NNMi views and TeMIP Plug-in
(Real-time and History Alarm Handling, Map Viewer, Entity Browser). The NNMi
Views are displayed in a browser window inside the TeMIP Client, with a fully
integrated look and feel using the TeMIP Client Web Browser plug-in and its
sophisticated features.
Figure 7
NNMi Views Integrated into the TeMIP Client
In other words, from a selected alarm in TeMIP Alarm Handling, for example, an
Router IF Down alarm, the operator can choose to display a specific NNMi view (for
instance the neighbor view). From this view displayed inside the TeMIP desktop, the
operator can use the standard NNMi views in order to identify the faulty node (for
instance a switch). For the selected node in NNMi View, either the user can find this
entity in the associated geographic map maintained within TeMIP or display
associated TeMIP alarms.
28
The following picture illustrates how this bi-directional integration is achieved.
TeMIP to NNMi
 Integration of NNMi Web Browser-based views from the TeMIP Plug-ins (Map
Viewer, RT Alarm Handling, History Alarm Handling, and Entity Browser) into
an embedded Web browser.
 The TeMIP Alarm Handling also offer a menu to drill down from an OSI alarm
collected by NNMi AM to the incidents queried from NNMi. A tree view of
correlated alarms is displayed and the user can select an alarm to get details.
NNMi to TeMIP
 Update of the TeMIP Client Plug-in (Map Viewer, Alarm Handling) in response
to user interactions in NNMi View. For example,Find Entity, Display Associated
Alarms, and Open Management View etc.)
Here is the TeMIP NNMi Advanced Integration architecture and the main
components integrated in TeMIP Client:
Figure 8
TeMIP-NNM Advanced integration Overview
TeMIP NNMi Advanced Integration Plug-in (TNT)
This is a Plug-in that is responsible for the interaction between NNMi and TeMIP. It
integrates the following main services:
 TeMIP/NNMi Name resolution (both sides)
 Manage NNMi Server configuration
 Compute final URL to access an NNMi View
 Drive the embedded Web Browser / External Default Web Browser
 Integrate TeMIP Services in NNMi Views to access to other TeMIP Plug-ins (
Map Viewer, Alarm Handling, Management View)
29
 Display NNMi correlated events associated with selected alarm in the TeMIP
Alarm Handling plug-in.
TeMIP Client Controller Launch Application
This launch is used by the NNMi Graphical User Interface to navigate to TeMIP and
request some TeMIP Client plug-in services (Open a Management View, Display
Associated Alarms, and Find TeMIP Entity) via external services (http).
Alarm Drill-down View
The user can display NNMi correlated events associated to selected TeMIP alarms in
the TeMIP Alarm Handling plug-in. The result is displayed in a Web Browser with a
tree of events. The user can also display details of specific events.
The integration of such views into the TeMIP Client is materialized by one tool that
allows to generate all suitable Launch data (on TeMIP side for navigation
TeMIP=>NNMi) and all NNMi suitable file for managing navigation
(NNMi=>TeMIP).
2.4.2
NNM Station Configuration
At startup, the TNT Plug-in uses the defined list of TeMIP directors and contacts the
associated NNMi AMs to retrieve the list of available NNM stations available and
their associated configurations.
The list of directors to contact is defined in an environment variable
(TEMIP_TNT_SERVERS). By default the director hostname is the same as the one
running the TAL server.
This list of directors and station found are displayed in the Tools – Option Tab
Windows, and the user can also force a refresh of this list clicking a Refresh button.
Example: TEMIP_TNT_SERVERS=.honda2_nnm_conf,.tom_nnm_conf
Figure 9
30
The TNT plug-in Options Tab
2.4.3
IP View Integration
Integration of NNM into TeMIP is done via the main menu of the TeMIP Desktop
and contextual MB3 menus. New features will be available depending on the selected
TeMIP object and the active Plug-in.
The following plug-in should support the NNMi integration by default:
 Map Viewer
 Entity Browser
 Real-time Alarm Handling
 History Alarm Handling
Figure 10
Selecting the Non Contextual NNMi Views
31
Figure 11
Selecting the Contextual NNMi Views
The TeMIP NNMi Advanced Integration is based on the launch mechanism and the
powerful plug-in callback. So, it will be easy for an administrator to fully customize
the integration menu for his operators.
Note
To ease the customization of the launch in the TeMIP Client, a tool named Launch
Generation Tool is available on the UNIX platform. It is in charge of generating a
launch definition file ready-to-use by TeMIP Client. This tool will be called after
deployment of a customization during the run time kit creation.
NNMi Views describe the family of browser-based views whose content is created as
a result of choices the user makes when he launch the view(Launch URL’s), and
which continue to provide the most current status information available.
There are three types of NNMi Views:
 NNMi Console View : The console view will open up the NNMi console on the
TeMIP Client web browser.. The user would be access all the views available in
the NNMi console..
 Contextual View which require a selection (TeMIP Entity) to start the NNMi
View. This selection is used to identify the context to display (resolution of entity
between NNM Node and TeMIP Entity). The Contextual Views are:
 Neighbor View
 Path View
 Non Contextual Views that do not require such argument. The non contextual
Views are:
 Router view
 Switches view
 Network view
 All Incidents view
32
 Inventory Nodes view
TeMIP can integrate contextual menu to launch NNMi IP Views.
2.4.4
Alarm Drill-down View Integration
This launch application is used by TeMIP Alarm Handling to display NNMi
correlated events associated to the TeMIP Alarm. This window is not real-time.
A check is performed first to validate that correlated events associated to the selected
alarm exist.
This Alarm Drill-down View is available in the MB3 menus of the Alarm Handling.
The drilldown view has two frames in a Web browser. The left hand frame displays
as a tree of incidents . The user can open and close different node in the tree view.
The tree view provides a tooltip details when the cursor is in focus. The right hand
frame displays the alarm details from NNMi. The user can click on a link of the
alarms in the tree view to get the NNMi details view in the right frame..
Figure 12
2.4.5
Alarm Drill-down – Tree of Correlated Events
Integration of the NNMi Views within TeMIP
By default, after installation of the TeMIP NNMi Advanced Integration Plug-in (TNT
plug-in), there is no customization installed, it means there is no menu allowing to
start NNMi Views.
These menus are only available on specific customized classes and then will require a
specific launch (associated to the correct classes).
There are two ways to populate these menus:
1. Manually: the user can define the launch via the Add or Edit Launch dialog box.
The user can enter the definition of the launch and associate it to the correct
classes using the Classes Control Panel.
2. Automatically: To ease the customization of launch in TeMIP Client, a tool
named Launch Generation Tool is available on the UNIX platform. It is in charge
of generating a launch definition file ready-to-use by TeMIP Client. This tool
will be called after deployment of a customization. This Launch Definition File
33
will need to be distributed to all TeMIP Client ‘s PC using for example a TeMIP
Resource Server).
Figure 13
An overview of the Launch Generation Tool
Please see Chapter 7 Configuring the NNM Views within TeMIP Client for more
information. This tool is installed during the installation of the NNMi AM master or
the TNT_BASE installation and called during the configuration step of the NNMi
AM.
2.4.6
Integration of TeMIP into NNMi Views
The following new TeMIP operations have been integrated into the NNMi main
menu “Tools”, and these operations are also available in the NNMi MB3 menu.
 TeMIP Find Entity
 TeMIP Display Associated Alarms
 TeMIP Open Management View
34
Figure 14
TeMIP Services integrated into NNM Menu
35
Chapter 3
Designing a Customization
This chapter focuses on one important aspect of ATNI which is the ability to design
and create a customization using the appropriate tool. The first section of this chapter
will explain in detail how to generate a template customization file. After which there
will be a presentation on validating the customization. Finally this chapter will
present a detailed example of how to design a customization.
3.1 Generating a Template Customization
ATNI provides a tool called tnt_custom_gen that generates a set of Customization
files given input from the SNMP equipment information (SNMP MIB) and optionally
the NNMi Incident Configuration Configuration file generated. For example,
incidentconfig.xml generated from the nnmconfigexport.ovpl. Figure 15 outlines this
process:
Figure 15
Designing a customization using the tnt_custom_gen tool
This tool will generate a Customization XML file called customization.xml that
contains the resulting TeMIP entities model definition and the associated Event
mapping rules. The TeMIP model and the Event Mapping rules are generated based
on the following recommendations and guidelines:
 By default or if the pruning is used (option –p yes), the TeMIP model does not
match exactly the MIB tree of the SNMP equipment but it is optimized in order to
keep the levels where SNMP traps are defined only. In case of non-pruning
36
(option –p no), the TeMIP model matches exactly the MIB tree of the SNMP
equipment.
 Concerning SNMP traps mapping, the process generates one rule for each SNMP
trap definition. The event mapping is augmented with an incident defined in the
incident configuration file, and the Mapping tables in TeMIP severity and
Probable Cause are modified based on the NNMi incident configuration. The
TeMIP Event Type and Add Text fields are defined in the incident configuration
file.
The generated customization.xml file is essentially a skeleton customization and it
contains default mapping rules and a default entity model (see section 3.3.2 for
details). This file is ready to be customized by the user in order to take into account
the specific configuration of their managed network.
Also, the tool generates a Template XML Filter file (<custom name>_<custom
identifier>Filter.xml) that contains default filter selecting all the nodes in NNMi. This
filter definition follows the NNMi xpath filter definition grammer.
Important Note
The designer using this tool to generate a customization should be on the NNMi
machine.
3.1.1
Usage
Shown below are two possible ways to use the tnt_custom_gen tool in order to
generate a customization template:
SYNOPSIS 1
tnt_custom_gen [-v] [-h] [-c className] [-i classId] [o classOID] [-a AMName] [-r AMId] [-e
entityModelFileName] [-t incidentConfigFileName] [-m
nnm/user] [-p yes/no] [-n encoding] moduleName1
moduleName2 ...
SYNOPSIS 2
tnt_custom_gen [-v] [-h] [-c className] [-i classId] [o classOID] [-a AMName] [-r AMId] [-e
entityModelFileName] [-m nnm/user] -t
incidentConfigFileName [-p yes/no] [-n encoding]
Table 3
The custom_gen_tool usage
Options
Description
-v
Verbose mode to enable the traces facility.
-h
Displays help usage.
-e entityModelFileName
Specifies the Entity Model file (xml format). If parameter
is not supplied, default Entity Model file (located in
/opt/OV/TNT/customToolkit/include/EntityModel.xml) is
used (see Appendix B The Entity Model File).
-t incidentConfigFileName
Specifies the input Incident Configuration file. For
example, incidentconfig.xml generated from
nnmconfigexport.ovpl..
-c className
Specifies the Global TeMIP Class name. The default
Global Class name value is "NNMi_NODE"
(customizable in the command line script). If this option
is used, you must use i, -o, -a, and -r options.
37
Options
Description
-i classID
Specifies the Global TeMIP Class identifier. The default
Global Class identifier value is "2010" (customizable in
the command line script). If this option is used, you must
use -c, -o, -a, and -r options.
-o classOID
Specifies the Global TeMIP Class SNMP OID. It should
represent the MIB root OID of the customization, i.e. the
OID of the global node. The default value is
"1.3.6.1.4.1.11.2.17.1". As soon as this option is used,
options -c, -i, -a, and -r must be used.
-a AMName
Specifies the AM application name. The default AM
name is "nnm_am". As soon as this option is used,
options -c, -i, -o and -r must be used.
-r AMId
Specifies the AM application identifier. The default AM
identifier is "1315". As soon as this option is used,
options -c, -i, -o and -a must be used.
-m nnm/user
Specifies if the Additional Text is based on the NNM
trapd.conf file (nnm) or on a user definition (user). When
no option is specified, the Additional Text is NNM based
(default).
-p yes/no
Specifies if the pruning is activated or not. If the pruning
is activated (default behavior), the tool generates TeMIP
classes for trap and attribute levels. If the pruning is not
activated a TeMIP class is generated of each MIB level.
The default value is “yes”
-n encoding
Specifies the encoding of XML customization file.
It is important to note that some of the input arguments have constraints:
 The global class (TeMIP class Name, TeMIP ID and SNMP OID) and AM
information (AM Name and TeMIP ID) is dependant and can not be passed
separately. When these are not specified it is assumed to be a customization of the
default custom.
 If MIB module names are supplied on input then each module name must exist in
the NNMi MIB repository.
Any user error will force the tool to exit with a corresponding error message.
3.1.2
Input
Concerning the usage of the tool there are possible scenarios that can be considered
regarding how to use the possible input files:
 Only the incident configuration file
 The incident configuration file and SNMP MIB selection.
 SNMP MIB modules only.
In the first scenario, incident are already pre-integrated within NNMi. This means,
some incidents already exists within NNMi through the NNMi incident configuration
file. The incident configuration file can be exported by using the
nnmconfigexport.ovpl tool..
In the second scenario, incidents that are known by NNMi through the incident
configuration and also corresponding SNMP MIB files that are loaded into the NNMi
38
MIB repository. The NNMi MIB repository snmpmib.bin is augmented by using the
xnmloadmib tool. The incident configuration for the traps in the MIB is augmented
by using the nnmincidentcfg.ovpl tool.
The final scenario to consider is using MIB files that are loaded into the NNMi MIB
repository - and where the incident configuration is not up to date regarding the
events that are declared in the MIB files. Note that the MIB files can be loaded using
an NNMi tool called xnmloadmib.
Important Note
The MIB selection is done using the MIB module names. The tool retrieves the OIDs
associated with the module names and retrieves the entire SNMP containment tree
located under these OIDs. So, in a way, the selection is not based on MIB files, but on
the MIB tree.
For example, if the module CISCO-SMI is chosen, then all CISCO objects located
under the CISCO-SMI OID are got (this means all CISCO objects), and not only the
objects defined in the CISCO-SMI MIB file (which contains no objects).
In addition to above information there is optional input information that can also be
passed as input arguments as indicated below:
 Global class name.
 Global class identifier.
 Global class OID.
 AM name.
 AM identifier.
These parameters cannot be supplied independently, so as soon as one of these
options is specified then all of them are required.
Another possible parameter is the Entity Model XML file. If the Entity Model XML
file is not specified in the command line if using the appropriate option the default
Entity Model file that is located under
/opt/OV/TNT/customToolkit/include/EntityModel.xml will be used instead.
3.2 The tnt_mib_scanner Tool
As described previously the tnt_custom_gen can take SNMP MIB modules as input
and not directly the name of the MIB. In order to facilitate easy usage of this tool,
another tool is provided called tnt_mib_scanner allowing the generation of the SNMP
modules names from a MIB directory.
SYNOPSIS
tnt_mib_scanner [-R|-a|-o <output filename> | -h] [-s
suffix]
This tool searches for MIBs that are located in the specified directory by using the
environment variable TNT_MIB_PATH or in the case that it is not defined the default
location /opt/OV/misc/nnm/snmp-mibs/. It creates a list of MIB modules
found in the search directory and then stores this list in an output file. By default the
output filename is tnt_asn1modules.cfg and is located in the default directory
/var/opt/OV/TNT/customToolkit/conf/.
39
Note
It is possible to change the default output directory by setting the
TNT_CONFIG_FILE_LOCATION environment variable with the intended path.
Table 4
The tnt_mib_scanner usage
Options
Description
-R
Searches recursively MIBs starting from the default or specified
directory
-a
Appends the new list to the existing one if the output file already
exists (by default, tnt_asn1modules.cfg)
-o <filename>
Name of the output file
-s
Specifies the suffix of the MIB files to search for (default value is
mib)
For example: if the user wants to search recursively starting from the default directory
and append the new list to an existing list it can be done as follows:
Example 2
Using the tnt_mib_scanner tool
tnt_mib_scanner -aR -s mib1
In the above example, if the environment variables TNT_MIB_PATH and
TNT_CONFIG_FILE_LOCATION are not set then the command will search
recursively from the default directory /opt/OV/misc/nnm/snmp-mibs/ for
any MIBs with the suffix .mib1 and will append the new generated list to the content
of the tnt_asn1modules.cfg file that is located in default directory
/var/opt/OV/TNT/customToolkit/conf/.
The following example illustrates how both tools may be used in sequence to
accomplish the goal of generating the customization using SNMP MIB inputs:
Example 3
Using both tools
tnt_mib_scanner –aR; tnt_custom_gen –c CISCO –i 1481 –o 1.3.6.1.4.9
–a CISCO_AM –r 1350 `cat
/var/opt/OV/TNT/customToolkit/conf/tnt_asn1modules.cfg | awk ‘{print
$1}’`
3.3 Validating the Customization
The tnt_custom_gen tool helps to validate whether the generated customization file
respects the following rules:
3.3.1
Entity Model File Checking
There are mainly two types of validation performed on the input Entity Model file
(see Appendix B:- The Entity Model File for a description of this file):
 Syntax checking (using the DTD)
 Rules checking
40
Syntax Checking
The input customization file is validated using the DTD file
/opt/OV/TNT/customToolkit/include/EntityModel.dtd.
If the syntax of the input file is not matching the DTD, an error message is displayed
and the tool exits.
Rules Checking
The purpose of the rule checking is to validate and ensure the integrity of the Entity
Model file. If the rule checking fails for any one of the reasons outlined below it can
avoid the deployment of an invalid customization. This ensures that an invalid or non
conforming customization will not be loaded and used by the NNMi AM or the
TeMIP Adapter. The following list of rules will be validated for the Entity Model file:
 The class depth should not be greater than 10 levels. If it exceeds, a warning is
displayed to warn user to do manual update before generating the Runtime kit.
This warning does not exit the tool.
 For any given class level the class name must be a unique and non empty.
 The snmpOID attribute must be a valid SNMP OID starting with a “.” or not,
having numbers separated by “.” characters and finishing or not by a “.*”
character (i.e. matching the regular expression "^([.]?)[0-9]+([.][09]+)*(([.][*])?)$").
 All snmpOID attributes must be unique for all classes.
Note
 The above rules are applicable only for the Entity Model file specified in the input
 All the above rules may not be validated for the entities generated from MIB
Modules.
3.3.2
Default Generation Rules
The tnt_custom_gen generates a customization XML file using default customization
rules.
Important
These rules are dependent on the input information and the result usually needs to be
modified manually with an XML editing tool of the users’ choice. In order to avoid
syntax errors it is strongly recommended to use an XML editor and validate the XML
with the associated DTD.
The following section will describe each element of the generated customization.
3.3.2.1
Header and Document Type
In all cases the header element is generated with the DOCTYPE always pointing to
the DTD. The customization.xml can not be parsed if the DOCTYPE does not contain
a URI with the correct DTD. See the example below:
Example 4
The Customization DTD
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE Customization SYSTEM
"/opt/OV/TNT/customToolkit/include/Customization.dtd">
41
3.3.2.2
Customization
The Customization element is completed based on the input parameters. In the
following example, note that AM information is not specified in input arguments:
Example 5 The Customization definition when no input is provided
<Customization classIdentifier="2010" isExclusive="False"
identifier="V1" className="NNMi_NODE" description="This is
the default customization that provides a generic
modelization of a NNMi node (NNMi_NODE)" isDefault="True">
In the following example, the input ClassName and ClassID are provided:
Example 6 The Customization definition when the class name and identifier is
provided
<Customization
identifier="V1"
className="CISCO"
classIdentifier="123"
isExclusive="True"
description="This is a customization of CISCO">
</Customization>
3.3.2.3
Revisions
In all cases the Revision element is generated as follows:
Example 7
<Revisions>
<Revision
date="<UNIX Current date>"
author="<UNIX User name>"
id="1">Custom created by the tnt_custom_gen tool</Revision>
</Revisions>
Please not that the date uses the format is “YYYY-MM-DDThh: mm:ss”. For
example:
Example 8
Date format
“2001-11-19T19:20:30” corresponds to November 19, 2001, 7:20:30 pm.
3.3.2.4
AM Definition
If the AM Definition section of the customization XML is generated without
specifying the AM information as an input parameter, it results in the following
definition:
Example 9
The AM Definition with no provided inputs
<AMDefinition name="nnm_am" identifier="1315"/>
42
If the AM information is provided, it results in the following definition:
Example 10
The AM Definition generated from provided inputs
<AMDefinition name="CISCO_AM" identifier="847"/>
3.3.2.5
MIB Modules
In the case that MIB modules names are supplied as input to the tool the MIB
Modules element is defined as shown below with information corresponding to each
module name:
Example 11 MIB Module Definition
<MIBModules>
<MIBModule
name="<Module1 name>"
description="<MIB Module1 description>"
rootSnmpOID="<Module1 OID>"/>
<MIBModule
name="<Module2 name>"
description="<MIB Module2 description>"
rootSnmpOID="<Module2 OID>"/>
</MIBModules>
In the case that no MIB module is supplied then an empty element is generated as
follows:
Example 12 An empty MIB Modules element
<MIBModules/>
3.3.2.6
NNM Predefined Variables
The NNM Predifiend variables are very much familiar to NNMi. Based on the
requirement, a default set of variables that can be augemented are provided for
customization.
By default, seven NNM predefined variables are generated in the customization file
as listed in the following table:
Table 5
NNM Predefined Variables
Name
Data Type
Remarks
openViewSourceName
OctetString
Deprecated variable
openViewCategory
OctetString
Deprecated variable
openViewSeverity
OctetString
Deprecated variable
openViewTrapdConfMessage
OctetString
Deprecated variable
openViewMessage
OctetString
Deprecated variable
sourceName
OctetString
Incident variable
category
OctetString
Incident variable
severity
OctetString
Incident variable
nature
OctetString
Incident variable
sourceNodeName
OctetString
Incident variable
43
cia.address
OctetString
CIA variable
cia.snmpoid
OctetString
CIA variable
cia.eventoid
OctetString
CIA variable
cia.remotemgr
OctetString
CIA variable
cia.remotetopoid
OctetString
CIA variable
cia.thresholdReason
OctetString
SPI Related CIA Variable
cia.thresholdParameter
OctetString
SPI Related CIA Variable
cia.thresholdLowerBound
OctetString
SPI Related CIA Variable
cia.thresholdUpperBound
OctetString
SPI Related CIA Variable
cia.thresholdPreviousValue
OctetString
SPI Related CIA Variable
cia.thresholdCurrentValue
OctetString
SPI Related CIA Variable
cia.thresholdMeasuredValue
OctetString
SPI Related CIA Variable
cia.thresholdMeasurementTime
OctetString
SPI Related CIA Variable
While the following XML code is generated:
Example 13
NNM Predefined Variable definitions in XML
<NNMPredefinedVariables>
<!-- Deprecated variables -->
<NNMPredefinedVariable dataType="OctetString"
label="openviewTrapdConfMessage"/>
<!-- Standard variables -->
<NNMPredefinedVariable dataType="OctetString"
label="openViewSourceName"/>
<NNMPredefinedVariable dataType="OctetString"
label="openViewSeverity"/>
<NNMPredefinedVariable dataType="OctetString"
label="openViewCategory"/>
<NNMPredefinedVariable dataType="OctetString"
label="openviewMessage"/>
<NNMPredefinedVariable dataType="OctetString"
label="temipConfigurationName"/>
<NNMPredefinedVariable dataType="OctetString"
label="temipStationName"/>
<!-- New Incidents variables -->
<NNMPredefinedVariable dataType="OctetString"
label="sourceName"/>
<NNMPredefinedVariable dataType="OctetString"
label="category"/>
<NNMPredefinedVariable dataType="OctetString"
label="severity"/>
<NNMPredefinedVariable dataType="OctetString"
label="nature"/>
<NNMPredefinedVariable dataType="OctetString"
label="sourceNodeName"/>
<!-- New CIA Variable -->
<NNMPredefinedVariable dataType="OctetString"
label="cia.address"/>
<NNMPredefinedVariable dataType="OctetString"
label="cia.snmpoid"/>
<NNMPredefinedVariable dataType="OctetString"
label="cia.eventoid"/>
44
<NNMPredefinedVariable dataType="OctetString"
label="cia.remotemgr"/>
<NNMPredefinedVariable dataType="OctetString"
label="cia.remotetopoid"/>
<!-- SPI Related CIA Variabel-->
<NNMPredefinedVariable dataType="OctetString"
label="cia.thresholdReason"/>
<NNMPredefinedVariable dataType="OctetString"
label="cia.thresholdParameter"/>
<NNMPredefinedVariable dataType="OctetString"
label="cia.thresholdLowerBound"/>
<NNMPredefinedVariable dataType="OctetString"
label="cia.thresholdUpperBound"/>
<NNMPredefinedVariable dataType="OctetString"
label="cia.thresholdPreviousValue"/>
<NNMPredefinedVariable dataType="OctetString"
label="cia.thresholdCurrentValue"/>
<NNMPredefinedVariable dataType="OctetString"
label="cia.thresholdMeasuredValue"/>
<NNMPredefinedVariable dataType="OctetString"
label="cia.thresholdMeasurementTime"/>
</NNMPredefinedVariables>
3.3.2.7
Entity Model
The tool implements a TeMIP class hierarchy enabling new events to be targeted to a
fine grain TeMIP entity model.
The global class definition is mandatory and is deduced from the input data used by
the tool. If optional information is not provided the tool will use the default values
class NNMi_NODE and its corresponding identifier 2010.
The Entity Model file can be used to create a base TeMIP class hierarchy under the
global class. The Entity Model file format is explained further on in the document in
Appendix B -The Entity Model File. If no explicit Entity Model file is provided then
a default entity model is used. In this case, the TeMIP class hierarchy created is the
same model as described in the default Entity Model file.
If the incident configuration file is used as the only other input resource, the Entity
Model is only composed of the hierarchy defined in the Entity Model file.
Otherwise, the tool parses the provided SNMP MIB tree to determine any useful child
classes. The output will not remain the same as it depends on the pruning option.
Note
In MIB, the same name may repeat at the same level of Entity Model with different
OIDs. In such a scenario, the custom generation tool and validation tools do not
generate any error. The customization entity model should be manually verified for
the same names under each entity level. The same names should be modified to have
unique names at each entity level.
45
By default, if no option is provided (or if option “–p yes” is specified), the pruning is
activated. In this mode, a new class is added under the most relevant class for each
SNMP node that has:

any traps

and/or any attributes

and also for each SNMP table.
These new child classes are instanceless, except those corresponding to SNMP tables.
If the option “-p no” (means no pruning) is specified, the tool generates as many
classes as the SNMP Mibs contain.
Note
The most relevant parent class for any new class is the one that already exists in the
TeMIP hierarchy at this point. The new class is created from the Entity Model file
and from the previously-added classes of the MIB tree. This start of the SNMP OID
of this class should match the parent OID. The parent class selected is the class that
where it’s OID is a best fit match.
If no relevant class is found, the new class will be added under the global class. If the
class being added already exists in the hierarchy, that is, has the same SNMP OID
then the class is not added.
All the following examples illustrate the behavior of the ‘tnt_cutom_gen’ tool when
pruning is activated:
Example 1:
Using an SNMP OID of .1.3.6.1.4.1.9 is to be added from the OLD-CISCOCHASSIS-MIB file.
No children class already exists in the hierarchy: the new CISCO class will be
created under the global class.
Example 2:
cardTable class (SNMP OID: .1.3.6.1.4.1.9.3.6.11) is to be added from the OLDCISCO-CHASSIS-MIB file.
Two direct children classes of the global class already exist:
 chassis (SNMP OID: .1.3.6.1.4.1.9.3.6) previously created from the same MIB
file
 cisco (SNMP OID: .1.3.6.1.4.1.9) created from the Entity Model file
The new cardTable class will be created under the chassis class, as the chassis class
SNMP OID is the most direct parent of the cardTable class OID.
Example 3:
cardTable class (SNMP OID: .1.3.6.1.4.1.9.3.6.11) is to be added from the OLDCISCO-CHASSIS-MIB file.
Two direct children classes of the global class already exist, as well as a grand-child
class:
 cisco (SNMP OID: .1.3.6.1.4.1.9) previously created from the same MIB file
 chassis (SNMP OID: .1.3.6.1.4.1.9.3.6) previously created from the same MIB
file
46
 myCardTable (SNMP OID: .1.3.6.1.4.1.9.3.6.11) created from the Entity Model
file
The new cardTable class will not be created as it already exists under the name
myCardTable (same SNMP OID).
Example 4:
cardTable class (SNMP OID: .1.3.6.1.4.1.9.3.6.11) is to be added from the OLDCISCO-CHASSIS-MIB file.
Two direct child classes of the global class already exist:
 cisco (SNMP OID: .1.3.6.1.4.1.9) previously created from the same MIB file
 chassis (SNMP OID: .1.3.6.1.4.1.9.3.6) created from the Entity Model file
The new cardTable class will be created under the chassis class, as the chassis class
SNMP OID is the most direct parent of the cardTable class (even if the chassis class
was not created from the MIB file).
As the Entity Model depth should not exceed ten, the maximum depth for a child
corresponding to a SNMP node which has traps and or attributes should be nine. This
is to ensure if needed the possibility to add classes corresponding to SNMP tables.
The maximum depth for a child corresponding to a SNMP table is ten. If the
maximum depth is reached, the corresponding behavior is to add only classes
corresponding to SNMP tables under the class corresponding to the last SNMP node
having traps and or attributes.
Note
The tnt_custom_gen tool ignores all SNMP nodes named “{No_Name=0}” which can
be added by NNMi during the SNMP MIB file loading into the NNMi MIB
Repository (in case of a translation between SNMPv1 traps into SNMPv2
notifications).
47
Using this algorithm, the generated Entity Model would be as follows:
Figure 16
Generated Entity Model from SNMP MIB Tree Hierarchy
Example:
If the following hierarchy is defined in the MIB:
48
Figure 17
An example of the SNMP MIB Tree Hierarchy
49
Then, the generated model would be as follows:
Figure 18
3.3.2.8
Corresponding Entity Model
Deployment
The generated deployment information is:
Example 14
Deployment
<Deployment>
<RetentionPolicy clear="0"
clearanceDetectionDelay="0" major="0" warning="60"
minor="60" critical="0" indeterminate="60"/>
<DefaultEntities ocName="DefaultOC"
collectionDomainName="DefaultCollectionDomain"
unknownEntityName="UnknownEntity" domainManagingDirector=""
ocManagingDirector=""/>
</Deployment>
Note
 Ensure that unique names are provided for OCName and unknownEntityname.
The recommended name format is <Respective Name>_customID. For example,
UnknownEntity NNMi NODE
 The OcName and DomainName attributes should be suffixed by a class name.
 After installing or deleting the AM using RT Create/ Delete respectively, the
metadata in all directors should be synchronized using temip_synchro_mdata.
3.3.2.9
Mapping Tables
This section presents the mapping tables generated for Event Severity, Event Type
(using NNM Category), and Probable Cause.
50
Event Severity
The default mapping between the NNM severity and the TeMIP severity is the
following:
Table 6
Event Severity mapping
NNMi
name
TeMIP
Severit
y
TeMIP name
NORMAL
5
Clear
MINOR
3
Minor
CRITICAL
1
Critical
WARNING
4
Warning (default)
MAJOR
2
Major
Event Type
The default mapping between the NNMi category and the TeMIP Event Type is the
following:
Table 7
Event Type mapping
NNM
Category
TeMIP
Event
Type
com.hp.nms.incident.category.Accounting
11
com.hp.nms.incident.category.Application
Status
10
TeMIP Name
QualityofServiceAlarm
ProcessingErrorAlarm
2
CommunicationsAlarm
com.hp.nms.incident.category.Configuration.
com.hp.nms.incident.category.Fault
4
EquipmentAlarm (default)
com.hp.nms.incident.category.Performance
11
QualityofServiceAlarm
13
SecurityServiceOrMechan
ismViolation
2
CommunicationsAlarm
com.hp.nms.incident.category.Security
com.hp.nms.incident.category.Status
If a new category is found in the supplied incident configuration, one row is added in
the mapping table and maps to the default value mentioned in the above table...
Probable Cause
The default mapping between the NNM category and the TeMIP Probable Cause is
the following:
Table 8
Probable Cause mapping table
NNM
Category
TeMIP
Probable Cause
com.hp.nms.in
cident.category
.Application
Status
2
TeMIP name
ApplicationSubsystem
Failure
51
com.hp.nms.in
cident.category
.Configuration
7
ConfigurationOrCusto
mizationError
com.hp.nms.in
cident.category
.Fault
15
EquipmentMalfunction
(default)
com.hp.nms.in
cident.category
.Performance
34
PerformanceDegraded
com.hp.nms.in
cident.category
.Security
10126
Status
6
CommunicationsSubsy
stemFailure
SNMPColdSta
rt
58
SnmpTrapColdStart
SNMPWarmSt
art
59
SnmpTrapWarmStart
SNMPLinkUp
61
SnmpTrapLinkUp
SNMPLinkDo
wn
60
SnmpTrapLinkDown
SNMPAuthenti
cationFailure
62
SnmpTrapAuthenticati
onFailure
SNMPEgpNei
ghborLoss
63
SnmpTrapEgpNeighbo
rloss
IntrusionDetection
If a new category is found in the supplied incident configuration,one row is added in
the mapping table and maps to the default value mentioned in the above table.
3.3.2.10
Event Mapping
For each event retrieved from the incident configuration or from the MIB repository,
the tool will create an event mapping definition that will enable mapping of any event
coming from NNM into a TeMIP OSI alarm. The event mapping definition that is
created based on the following rules:
The Managed Object Rule
If the event is provided by the incident configuration file, the managed object is the
default one, that is, the global class instance. In this case, the instance value is given
by the NNM predefined variable SourceNodeName.
Otherwise, if the event is an SNMP trap originating from the MIB repository, in
addition to the default managed object, a child class is added corresponding to the
SNMP Node associated to the SNMP trap. In this case the child class is instanceless.
The Event Type Rule
Using the Event Type mapping table, this event attribute is set to the corresponding
value of the NNM predefined variable Category. This setting is independent of the
information provided to the tool as all events that are mapped have to be configured
according to the NNM environment via the incident configuration file.
52
The Probable Cause Rule
This like the Event Type is deduced from the NNMi category.
The Severity Rule
Using a mapping table, the corresponding value is deduced from the NNMi severity.
Specific Problem Rule
For each trap, a unique integer value is set, as well as a label representing the name of
the trap. The integer value starts from 1 and is incremental.
Note
For the Specific Problem, numerical value from 10000 to 11000 is reserved. Hence,
Specific problem generation is controlled such that after 9999, the next value would
be 11001.
The Additional Text Rule
If the event is defined within the incident configuration file, the additional text value
is obtained from the FormattedMessage text of the incident configuration. Otherwise,
the value is the following string “Received event $o”. The $o means trap Oid.
By default (or if the option “-m nnm” is specified), the Additional Text rule is nnmbased means the runtime processing takes directly the text from the Incident received
from NNMi instead of reading the what is defined in the customization file
description.
If the option “-m user” is specified, the Additional Text rule is user-based and this
time the runtime processing will use exactly what is defined in the customization file.
The Notification ID Rule or Correlation ID Rule
These event attributes are not set by the tool but should be set by the customization
designer. This enables the designer control and fine tune how the events are
correlated. For more information concerning the correlation id please refer to the HP
TeMIP Software NNM Advanced Integration User Guide documentation.
Test Cases for SNMP Traps
If the event originates from the incident configuration file, no test case is created.
Otherwise, using the SNMP trap varbinds, a test case is created that will contain all
retrieved varbinds as an input set with a default value. The default values applied
depend on the varbind datatype and are listed in Table 9.
Table 9
The default data type values
Varbind datatype
Default value applied
Opaque
101101
Counter32
256
Counter64
256
Gauge32
50
Integer
1
Unsigned32
1
53
3.3.2.11
Varbind datatype
Default value applied
IpAddress
111.222.333.444
OctetString
Default String
TimeTicks
123456789
other
Default Value
Auto Population
The AutoPopulation XML element is set according to the ClassName input
information if supplied:
Table 10
Auto Population attribute values
Attribute
Value
NNMFilter Name
ClassNameFilters
tnsDirectory
ClassName_V1_tns
ocName
ClassName_V1_oc
collectionDomainName
ClassName_V1_domain
All other attributes are left blank. The example below shows the auto population
XML generated:
Example 15
Auto Population definition for class CISCO
<AutoPopulation>
<EntityNamingRules>
<EntityNamingRule
ocManagingDirector=""
domainManagingDirector=""
ocName="CISCO_V1_oc"
entityNamePrefix=""
entityNameSuffix=""
tnsDirectory="CISCO_V1_tns"
collectionDomainName="CISCO_V1_domain"
isDefaultRule="True">
<NNMFilter name="CISCO_V1Filter"/>
</EntityNamingRule>
</EntityNamingRules>
</AutoPopulation>
If no class name information is provided as an input argument, then AutoPopulation
XML element is set as follows:
Table 11
54
The default Auto Population attributes
Attribute
Value
NNMFilter Name
TNTFilters
tnsDirectory
NODE_V1_tns
ocName
NODE_V1_oc
Attribute
Value
collectionDomainName
NODE_V1_domain
All other attributes are left blank. The example below shows the auto population
XML generated:
Example 16
The default Auto Population attributes generated
<AutoPopulation>
<NNMFilter name="NODEFilters"/>
<EntityNamingRules>
<EntityNamingRule domainManagingDirector=""
ocName="NODE_V1_oc" entityNamePrefix="" entityNameSuffix=""
tnsDirectory="NODE_V1_tns" collectionDomainName="NODE_V1_domain"
ocManagingDirector="" isDefaultRule="True">
<NNMFilter name="TNTFilters"/>
</EntityNamingRule>
</EntityNamingRules>
</AutoPopulation>
3.3.3
The tnt_custom_gen Tool Output
The command line result is a customization file (XML format) which contains the
information described in the next sections and a filter file (XML format) which
contains a default filter selecting all nodes.
Depending on the global class and AM information passed to the command line, two
types of customization XML files can be generated:
A NNM_NODE_temip.xml file is created when there is no global class information.
This customization file has only trap information and must be merged to the default
customization before any deployment.
The file is named using this convention, <Global class name>_temip.xml when the
global class information has been supplied as part of the tool input.
The filter file generated is named using the following convention: <Global class
name>_<custom Identifier>Filter.xml. It selects all nodes.
Example 17
The default Filter generated for the CISCO Global Class
<?xml version="1.0" encoding="UTF-8"?>
<filters
xmlns="http://www.hp.com/openview/NetworkTopology/TopologyFilter"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.hp.com/open
view/NetworkTopology/TopologyFilter TopoFilter.xsd">
<filter name="CISCO_V1Filter" objectType="Node" title="All Nodes"
description="Default Filter">
<operator oper="NOOP">
<filterName>isNode</filterName>
</operator>
</filter>
<nodeAssertion name="isNode" description="Is Node">
<operator oper="NOOP">
55
<attribute><name><string>*</string></name></attribute>
</operator>
</nodeAssertion>
</filters>
The filtername “CISCO_V1Filter” in the file CISCO_V1Filter.xml is the filtername
of the “NNMFilter name” of the generated Auto population definition.
Example 18
A generated auto population definition
<AutoPopulation>
<NNMFilter name="CISCOFilters"/>
<EntityNamingRules>
<EntityNamingRule
ocManagingDirector=""
domainManagingDirector=""
ocName="CISCO_V1_oc"
entityNamePrefix=""
entityNameSuffix=""
tnsDirectory="CISCO_V1_tns"
collectionDomainName="CISCO_V1_domain"
isDefaultRule="True">
<NNMFilter name=”CISCO_V1Filter”/>
</EntityNamingRule>
</EntityNamingRules>
</AutoPopulation>>
3.4 An example using the tnt_custom_gen tool
This section describes step by step how to generate a customization XML file using
the tnt_custom_gen tool using an example.
In this example, we suppose that we want to create a customization XML file from
the CISCO-STACK-MIB module.
3.4.1
Loading the MIB into the NNM Repository
Before using the TNT customization toolkit it is important to ensure that the CISCOSTACK-MIB is correctly loaded into the NNM repository.
To verify that this is the case it is possible to launch the MIB loader application as
super user:
/opt/OV/bin/xnmloadmib
If the CISCO-STACK-MIB appears in the list of loaded MIBs then select it and click
the Unload button. Then click the Load button and a new window should appear.
Then select the /opt/OV/misc/nnm/snmp-mibs/Vendor/Cisco directory
and then select the CISCO-STACK-MIB.my file and click OK to validate
The MIB should now be loaded. Finally, verify that it appears at the end of the MIB
list and close the application. In order to augment the Incident Configuration in
NNMi along with loading of the MIB, you should use nnmincidentcfg.ovpl, which is
an NNMi tool.
3.4.2
Generating a Customization Template
As explained in the introduction the first step in customization is to generate a
customization template using the tnt_custom_gen tool. In this example, it was decided
56
to define a new AM called CISCO_AM (ID=867) with a global class called CISCO
(ID=15687 and OID=1.2.3.6.1.4.1.9.5.1).
The first step is to execute the tnt_custom_gen tool with the required input parameters
as shown below:
/opt/OV/TNT/customToolkit/bin/tnt_custom_gen -c CISCO i 15687 -o 1.2.3.6.1.4.1.9.5.1 -a CISCO_AM -r 867
CISCO-STACK-MIB
The generated customization is called CISCO_temip.xml and it can be seen in this file
how the default rules are applied. In particular, it can be seen how the generated
Entity Model is rather simple. It contains the global class CISCO along with the
content of the default Entity Model and only one child class defined as
ciscoStackNotificationPrefix:
The Entity Model definition
Example 19
The Entity Model definition that is generated
<EntityModel>
<ClassDefinition
snmpOID="1.2.3.1.4.1.9.5.1"
identifier="15687"
name="CISCO"
snmpType="OID"
isGlobalClass="True">
</ClassDefinition>
</EntityModel>
The following example shows a model structure that is imported from an Entity
Model file. For more information concerning the content of the Entity Model file
please refer to Appendix B The Entity Model File.
Example 20
Class Definition imported from the Entity Model
<EntityModel>
<ClassDefinition
snmpOID=".1.3.6.1.4.1.9.5.0"
isInstanceless="True" identifier="1"
name="ciscoStackNotificationsPrefix"
snmpType="Scalar">
</ClassDefinition>
</ClassDefinition>
</EntityModel>
Note
Even though SNMP OID and Identier fields are different, the Entity Model name
should be unique in a user customization. For better understanding, consider the
following example:
<EntityModel>
<ClassDefinition snmpOID=".1.3.6.1.2.1.83.1.1"
isInstanceless="True" identifier="322" name="ipMRoute"
snmpType="Scalar">
<ClassDefinition snmpOID=".1.3.6.1.3.60.1.1"
isInstanceless="True" identifier="332" name="ipMRoute"
snmpType="Scalar">
57
is modified as follows:
<EntityModel>
<ClassDefinition snmpOID=".1.3.6.1.2.1.83.1.1"
isInstanceless="True" identifier="322" name="ipMRoute_1"
snmpType="Scalar">
<ClassDefinition snmpOID=".1.3.6.1.3.60.1.1"
isInstanceless="True" identifier="332" name="ipMRoute_2"
snmpType="Scalar">
The Event Mapping definition
On examination of the next example concerning the event mapping definition, it can
be seen that a default mapping has been defined for the nine following traps that are
defined in the MIB:
 lerAlarmOn
 tokenRingSoftErrExceededTrap
 lerAlarmOff
 moduleUp
 moduleDown
 chassisAlarmOn
 chassisAlarmOff
 ipPermitDeniedTrap
 sysConfigChangeTrap
In addition the mapping of the default event known as the MIBModulesDefault is
defined and can be seen also in the following example of the generated event
mapping:
Example 21
A generated event mapping
<EventMapping admin="Defined" eventName="CiscoLinkUp"
eventType="Snmp"
eventOID="1.3.6.1.6.3.1.1.5.4.1.3.6.1.4.1.9">
<EventMappingRules>
<ManagedObjectMappingRule>
<EventMappingRule alarmFieldID="9"
type="ManagedObject" alarmFieldName="Managed Object"/>
<ExtendedClassInstance>
<GlobalInstanceLookup>
<TrapVariable label="sourceNodeName"
type="Reference"/>
</GlobalInstanceLookup>
<ChildClasses value="INTERFACE
${interfaceid}">
<Resolver label="interfaceid"
inputType="variable" inputValue=".1.3.6.1.2.1.2.2.1.1"/>
</ChildClasses>
</ExtendedClassInstance>
</ManagedObjectMappingRule>
<TeMIPEnumMappingRule
type="MappingTableReference">
<EventMappingRule alarmFieldID="4"
type="TeMIPEnumeration" alarmFieldName="Perceived
Severity"/>
58
<MappingTableReference
mappingTable="perceivedSeverity" inputType="TrapVariable">
<TrapVariable label="severity"
type="Reference">
</TrapVariable>
</MappingTableReference>
</TeMIPEnumMappingRule>
<TeMIPEnumMappingRule
type="MappingTableReference">
<EventMappingRule alarmFieldID="1"
type="TeMIPEnumeration" alarmFieldName="Event Type"/>
<MappingTableReference mappingTable="eventType"
inputType="TrapVariable">
<TrapVariable label="category"
type="Reference">
</TrapVariable>
</MappingTableReference>
</TeMIPEnumMappingRule>
<TeMIPEnumMappingRule type="Constant">
<EventMappingRule alarmFieldID="3"
type="TeMIPEnumeration" alarmFieldName="Probable Cause"/>
<Constant label="SnmpTrapLinkUpDown"
type="Enum">65</Constant>
</TeMIPEnumMappingRule>
<TeMIPEnumMappingRule type="Constant">
<EventMappingRule alarmFieldID="200"
type="TeMIPEnumeration" alarmFieldName="Specific Problem"/>
<Constant label="Cisco_Link_UpDown"
type="Enum">467</Constant>
</TeMIPEnumMappingRule>
<AdditionalTextMappingRule>
<EventMappingRule alarmFieldID="7"
type="AdditionalText" alarmFieldName="Additional Text"/>
<MessageText>Cisco Agent Interface Up (linkUp
Trap) on interface $.1.3.6.1.2.1.2.2.1.1</MessageText>
</AdditionalTextMappingRule>
</EventMappingRules>
<TestCases>
</TestCases>
</EventMapping>
The Auto Population Definition
The AutoPopulation section of the customization is generated as follows with the
default entity naming rules:
59
Example 22
A generated auto population definition
<AutoPopulation>
<NNMFilter name="NODEFilters"/>
<EntityNamingRules>
<EntityNamingRule
domainManagingDirector="" ocName="NODE_V1_oc"
entityNamePrefix="" entityNameSuffix=""
tnsDirectory="NODE_V1_tns"
collectionDomainName="NODE_V1_domain"
ocManagingDirector="" isDefaultRule="True">
<NNMFilter name="TNTFilters"/>
</EntityNamingRule>
</EntityNamingRules>
</AutoPopulation>
3.5 TeMIP Registration Process
The TeMIP registration process ensures that names and codes (that is, numbers)
representing certain information remain unique across a set of appropriate name and
number spaces. To register your Management Module, please contact the TeMIP
Support Team at: VBETEMIPSUPP@hp.com.
60
Chapter 4
Updating the Customization
This chapter focuses on the customization file content and will present all the
necessary information required to help the user leverage the full capabilities offered
by the ATNI Customization.
The chapter should enable the user to:
 Learn how to create, modify, or update all of the Customizations fields such as the
Topology and Event mapping sections.
 Learn how to create, develop the Computed Variables and use in any TeMIP OSI
field
 Manage all the possible SNMP scenarios such as Proxy Management or the
Multiple Indexes Naming.
Important Note
It is recommended to invest in a choice XML editor in order to facilitate the
modifying of the customization. It is important that the XML editor supports DTD
validation so as to ensure at all times the integrity of the customization.
4.1 Introduction
As described in Chapter 2, the Customization file is the most important aspect of the
ATNI customization. This file is composed of four main parts:
 General information for the customization, that being the TeMIP global class, the
Management Module that implements this class and the Class Identifier.
 The TeMIP Model definition
 The Event Mapping rules that defines any traps managed by this customization.
 The Topology definitions
This chapter focuses on each of these main sections of the customization. It details
what is possible to do in terms of configuration and also outlines common user
scenarios when customizing these main sections.
4.2 General Customization Information
The following example is extracted from the NNMi_NODE Default Customization:
61
Example 23
Customization Attributes
<!DOCTYPE Customization SYSTEM
"/var/opt/OV/TNT/adapter/conf/customs/Customization.dtd">
<Customization
classIdentifier="2010"
isExclusive="False"
identifier="V1"
className="NNMi_NODE"
description="This is the default customization that provides a
generic modelization of a NNMi node (NNMi_NODE)"
isDefault="True">
The classIdentifier and className correspond to the TeMIP class implemented by
this customization. Changing it is possible but it is then considered to be new
customization.
The Custom Identifier
The Custom Identifier attribute identifies the version of the customization. The user
should keep in mind that there is a limitation in the size of the <classname> and
<customId> combination for a customization. It is important to remember is that
internally the class name and custom identifier are joined together and used in the
naming of the NNMi database CA that store information concerning the mapping of
NNMi nodes to their TeMIP entity equivalents. These attributes are coupled together
as <classname>_<customId> and the maximum length is 18 characters. The
combination of classname and customId should be unique for all customs deployed
on an NNMi Station.
The default value of custom Identifier generated by the tnt_custom_gen tool is
“V1”.The custom identifier is used to enable versioning of the customization on the
same class. It is also considered as new customization and can be deployed from a
different director.
Important Note
The deployment of the same custom from multiple directors on the same NNMi
station is not supported. Such a deployment does not generate any error. However,
the auto-population does not happen.
For deployment of the same custom (including the default custom) from multiple
directors, the customId must be changed to different values so that the combination of
classname and customId is unquie for each deployed custom..
The Exclusive Flag
The customization can either be exclusive or not indicated by the Boolean values
True or False. If a customization is exclusive, the TeMIP Adapter will enforce the
uniqueness of the mapping and if required will remove the previously defined
mapping by using topology deletion events on the NNMi AM.
The Default Flag
The default flag is used to indicate whether the customization is to be considered as a
default customization and is determined by the Boolean values True or False.
If the user has installed an NNMi AM master the associated customization is the
default customization. The user can deploy other customizations with the default flag
set to True when installing NNMi AM clones but they will not used for default
processing by ATNI.
62
.Note
If NNMi_NODE is specified as the Global Class name, the Default Flag is always set
to “True”,
The Default and Exclusive Flag Considerations
It is incompatible to have a customization that is both default and exclusive. This
incompatibility is detected in the diagnosis of the tnt_custom_tool. The purpose of
having default processing via a default customization is to enable management of any
objects that are not managed by other customizations. In contrast, the purpose of an
exclusive customization is that it is designated to manage specific objects determined
by specific selection criteria exclusively.
4.2.1
The NNM Predefined Variables
The customization XML file that is generated by tnt_custom_gen tool contains the
following list of variable definitions that can be used in the event mapping rules. This
allows the designer to reuse these variables by referencing them where appropriate in
the customization:
Standard variables
openViewSourceName
openViewSeverity
openViewCategory
openviewMessage
temipConfigurationName
temipStationName
New Incidents variables
sourceName
Category
Severity
Nature
sourceNodeName
New CIA Variable
cia.address
cia.snmpoid
cia.eventoid
cia.remotemgr
cia.remotetopoid
SPI Related CIA Variabel
cia.thresholdReason
cia.thresholdParameter
cia.thresholdLowerBound
cia.thresholdUpperBound
cia.thresholdPreviousValue
cia.thresholdCurrentValue
cia.thresholdMeasuredValue
cia.thresholdMeasurementTime
The variables temipStationName and temipConfigurationName are used exclusively
to enable the possibility of targeting traps to other special class instances other than
the global class. These are administration classes named in TeMIP as
NNM_CONFIGURATION and NNM_STATION. The NNM_CONFIGURATION
63
class is used for storing NNMi configuration data while the NNM_STATION class is
used to stored information concerning the NNMi station or stations where a
customization is deployed.
Important Note
Any variable used in the Global Class Instance should be predefined.
The example below shows the NNMPredefinedVariables XML definition that is
generated:
Example 24
NNM Predefined Variables
<NNMPredefinedVariables>
<!-- New Incidents variables -->
<NNMPredefinedVariable dataType="OctetString"
<NNMPredefinedVariable dataType="OctetString"
<NNMPredefinedVariable dataType="OctetString"
<NNMPredefinedVariable dataType="OctetString"
<NNMPredefinedVariable dataType="OctetString"
<!-- New CIA Variable -->
<NNMPredefinedVariable dataType="OctetString"
<NNMPredefinedVariable dataType="OctetString"
<NNMPredefinedVariable dataType="OctetString"
<NNMPredefinedVariable dataType="OctetString"
<NNMPredefinedVariable dataType="OctetString"
<!-- SPI Related CIA Variabel-->
<NNMPredefinedVariable dataType="OctetString"
<NNMPredefinedVariable dataType="OctetString"
<NNMPredefinedVariable dataType="OctetString"
<NNMPredefinedVariable dataType="OctetString"
<NNMPredefinedVariable dataType="OctetString"
label="cia.thresholdPreviousValue"/>
<NNMPredefinedVariable dataType="OctetString"
label="cia.thresholdCurrentValue"/>
<NNMPredefinedVariable dataType="OctetString"
label="cia.thresholdMeasuredValue"/>
<NNMPredefinedVariable dataType="OctetString"
label="cia.thresholdMeasurementTime"/>
<!-- Standard variables -->
<NNMPredefinedVariable dataType="OctetString"
<NNMPredefinedVariable dataType="OctetString"
<!-- Deprecated variables -->
<NNMPredefinedVariable dataType="OctetString"
<NNMPredefinedVariable dataType="OctetString"
<NNMPredefinedVariable dataType="OctetString"
<NNMPredefinedVariable dataType="OctetString"
<NNMPredefinedVariable dataType="OctetString"
</NNMPredefinedVariables>
label="sourceName"/>
label="category"/>
label="severity"/>
label="nature"/>
label="sourceNodeName"/>
label="cia.address"/>
label="cia.snmpoid"/>
label="cia.eventoid"/>
label="cia.remotemgr"/>
label="cia.remotetopoid"/>
label="cia.thresholdReason"/>
label="cia.thresholdParameter"/>
label="cia.thresholdLowerBound"/>
label="cia.thresholdUpperBound"/>
label="temipConfigurationName"/>
label="temipStationName"/>
label="openViewSourceName"/>
label="openViewSeverity"/>
label="openViewCategory"/>
label="openviewMessage"/>
label="openviewTrapdConfMessage"/>
Important Note
It is highly recommended not to remove or modify the already existing list of NNM
predefined variables. User can add new predefined variables depending on their
availability in specific incidents.
How the NNM predefined variables are used will be discussed further on in the
chapter when the Event Mapping is presented.
64
4.2.2
The Event Retention Policy
The retention policy can be modified and defined according to the users’ specific
needs. For each TeMIP severity, it is possible to define the retention value in seconds.
4.2.3
Impact of changes to Customization file
Severity of
Impact on
deployed
custom(s)
Custom
Attribute
modified
Impact
(TeMIP,
NNM or
both
sides)
Class
Identifier
TeMIP
&NNM
High
Class Name
TeMIP
&NNM
High
The Exclusive
Flag
NNM
Medium
The Custom
Identifier
TeMIP
&NNM
High
The Default
Flag
None
Low
The Default
Flag
TeMIP
&NNM
High
Additional Information &
Tools/commands to use
Re-install using
tnt_nnm_am_load_cust
om.sh
Re-install using
tnt_nnm_am_load_cust
om.sh
Run deployCustom
directive of AM
This change can be
verified and tuned
by updating
customization.xml
directly in the NNM
station
Re-install using
tnt_nnm_am_load_cust
om.sh
None if default
custom (NNMi_NODE)
is also deployed in
the same TeMIP
director.
NNMi_NODE is always
the default if
present.
If default custom is
not deployed in the
same TeMIP director,
Re-install using
tnt_nnm_am_load_cust
om.sh
The NNM Predefined
Variables
NNM
Low
Run deployCustom
directive of AM
The Event
Retention
Policy
NNM
Low
Run deployCustom
directive of AM
TeMIP &
NNM
High
Re-install using
tnt_nnm_am_load_cust
om.sh
The AM
Definition
(AM
identifier/na
me)
Trouble Shooting /
Tuning information
This change can be
verified and tuned
by updating
customization.xml
directly in the NNM
station and restarting the AM
This change can be
verified and tuned
by updating
customization.xml
directly in the NNM
station and restarting the AM
65
The Entity
Model
TeMIP &
NNM
High
Topology Auto
population –
filtering
TeMIP &
NNM
High
Topology Auto
population –
Naming rules
TeMIP &
NNM
High
Entity naming
rules
TeMIP &
NNM
High
Re-install using
tnt_nnm_am_load_cust
om.sh
Run deployCustom
directive of AM
followed by
resynchTopoReapply directive
of NNM_STATION
Run deployCustom
directive of AM
followed by
resynchTopoReapply directive
of NNM_STATION
Re-install using
tnt_nnm_am_load_cust
om.sh
Event Mapping
– Mapping
Table
NNM
Medium
Run deployCustom
directive of AM
Event Mapping
– Managed
Object
Mapping Rule
NNM
Medium
Run deployCustom
directive of AM
Event Mapping
–
TeMIP Enum
Mapping
Rule(s)
NNM
Medium
Run deployCustom
directive of AM
Event Mapping
Additional
Text Mapping
Rule
NNM
Medium
Run deployCustom
directive of AM
66
This change can be
verified and tuned
by updating
customization.xml
directly in the NNM
station and restarting AM. This
change can be
verified and tuned
by updating
customization.xml
directly in the NNM
station and restarting AM
This change can be
verified and tuned
by updating
customization.xml
directly in the NNM
station and restarting AM.
This change can be
verified and tuned
by updating
customization.xml
directly in the NNM
station and restarting AM.
This change can be
verified and tuned
by updating
customization.xml
directly in the NNM
station and restarting AM.
4.3 The TeMIP Model Definition
4.3.1
The AM Definition
This section shows the AM information definition which must be unique. The user
can change the Application Identifier and the Application Name in order to define
which AM will be responsible for managing this global class.
Example 25
The AM Definition
<AMDefinition identifier=”1315” name=”NNMi_AM”/>
4.3.2
The Entity Model
A customization corresponds to the implementation of one TeMIP global class so the
Entity model definition is mandatory. The entity model in the customization will
define:
 The customization of the global class.
 And its subsequent child classes.
The designer can create the entity model definition by either:
 Modifying the default equipment model.
 Merging the current model with MIB tree hierarchy.
Changing the entity model is possible and it will be automatically taken into account
if the runtime kit is redeployed. Then default entity model file “EntityModel.xml” is
located in the directory /opt/OV/TNT/customToolkit/include
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE EntityModel SYSTEM "/opt/OV/TNT/customToolkit/include/EntityModel.dtd">
<EntityModel>
<ClassDefinition snmpOID="1.3.6.1.2.1.1" name="SYSTEM" ID="1" snmpType="OID"
isInstanceless="True">
</ClassDefinition>
<ClassDefinition snmpOID="1.3.6.1.2.1.2" name="INTERFACE" ID="2" snmpType="OID">
</ClassDefinition>
<ClassDefinition snmpOID="1.3.6.1.2.1.4" name="IP" ID="4" snmpType="OID"
isInstanceless="True">
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE EntityModel SYSTEM "/opt/OV/TNT/customToolkit/include/EntityModel.dtd">
<EntityModel>
<ClassDefinition snmpOID="1.3.6.1.2.1.1" name="SYSTEM" ID="1" snmpType="OID"
isInstanceless="True">
</ClassDefinition>
<ClassDefinition snmpOID="1.3.6.1.2.1.2" name="INTERFACE" ID="2" snmpType="OID">
</ClassDefinition>
<ClassDefinition snmpOID="1.3.6.1.2.1.4" name="IP" ID="4" snmpType="OID"
isInstanceless="True">
</ClassDefinition>
<ClassDefinition snmpOID="1.3.6.1.2.1.5" name="ICMP" ID="5" snmpType="OID"
isInstanceless="True">
</ClassDefinition>
<ClassDefinition snmpOID="1.3.6.1.2.1.6" name="TCP" ID="6" snmpType="OID"
isInstanceless="True"
>
67
</ClassDefinition>
<ClassDefinition snmpOID="1.3.6.1.2.1.7" name="UDP" ID="7" snmpType="OID"
isInstanceless="True"
>
</ClassDefinition>
<ClassDefinition snmpOID="1.3.6.1.2.1.8" name="EGP" ID="8" snmpType="OID"
isInstanceless="True"
>
</ClassDefinition>
<ClassDefinition snmpOID="1.3.6.1.2.1.11" name="SNMP" ID="11" snmpType="OID"
isInstanceless="True">
</ClassDefinition>
<ClassDefinition snmpOID="1.3.6.1.4.1" name="ENTERPRISES" ID="16" snmpType="OID"
isInstanceless ="True">
</ClassDefinition>
<ClassDefinition snmpOID="1.3.12.2.1011.2.22.1.201" ID="201" name="CHASSIS"
snmpType="OID">
</ClassDefinition>
<ClassDefinition snmpOID="1.3.12.2.1011.2.22.1.202" ID="202" name="RACK"
snmpType="OID">
</ClassDefinition>
<ClassDefinition snmpOID="1.3.12.2.1011.2.22.1.203" ID="203" name="SHELF"
snmpType="OID">
</ClassDefinition>
<ClassDefinition snmpOID="1.3.12.2.1011.2.22.1.204" ID="204" name="SLOT"
snmpType="OID">
</ClassDefinition>
<ClassDefinition snmpOID="1.3.12.2.1011.2.22.1.205" ID="205" name="CARD"
snmpType="OID">
</ClassDefinition>
<ClassDefinition snmpOID="1.3.12.2.1011.2.22.1.206" ID="206" name="PORT"
snmpType="OID">
</ClassDefinition>
<ClassDefinition snmpOID="1.3.12.2.1011.2.22.1.207" ID="207" name="FAN"
snmpType="OID">
</ClassDefinition>
<ClassDefinition snmpOID="1.3.12.2.1011.2.22.1.208" ID="208" name="POWER_SUPPLY"
snmpType="OID"
>
</ClassDefinition>
</EntityModel>
Recommendation
Do not change either the Naming or Identification of the default model structure, that
is, the SNMP child class semantic. Adding new child that corresponds to the
equipment defined in the MIB model is considered the normal situation and has no
impact – events will be targeted to the new classes.
The typical customization approach is to add child classes that correspond to the
SNMP equipment interface.
4.4 Topology Auto Discovery Configuration
This section addresses the Topology auto configuration and population aspects of the
customization. The auto population defines two important rules:
 Which IP nodes, that is, NNMi nodes are candidates and associated with
customization.
68
 How they are to be named and in which domain are they created in order that the
TeMIP collection can take place automatically.
The following example is extracted from the Default Customization:
Example 26
Topology Auto Population rules
<AutoPopulation>
<NNMFilter name="NNMi_NODEFilters"/>
<EntityNamingRules>
<EntityNamingRule ocManagingDirector=""
domainManagingDirector="" ocName="NNMi_NODE_V1_oc"
entityNamePrefix="" entityNameSuffix=""
tnsDirectory="NNMi_NODE_V1_tns" collectionDomainName="NNM
i_NODE_V1_domain" isDefaultRule="True">
<NNMFilter name="NNMi_NODE_V1Filter"/>
</EntityNamingRule>
</EntityNamingRules>
</AutoPopulation>
Each part of the AutoPopulation is customizable.
4.4.1
Filtering Capabilities
Using the NNMFilter element it is possible to change the NNMi filter name and
provide another filter name that points to a specific filter definition in a specific filter
xml file. Note that, the filter name should be the same as the filter filename. E.g. if
the filter is “CISCO_Filter”, the file name should be “CISCO_Filter.xml”.. The
purpose of this filter is to provide the capability to the user to select only nodes he is
interested in. The filter definition is based on NNMi XML filter grammar defined by
NNMi Please refer to the NNMi SDK Documentation for filter details.
Whenever there’s a filter change, the customization package will need to be
redeployed and the directive resynchTopoReapply needs to be called in order that all
Topology information can be resynchronized. The resynchronization process is when
nodes that are no longer selected are deleted and new nodes are created.
Note
Because ATNI uses offset, maxObjects, and includeCustomAttributes constraints
internally, do not use these constraints in the filters.
User should not use the ATNI specfic Custom Attributes persisted in IP Node like
customs details, global status etc in the filter.
4.4.2
Naming Capabilities
A naming rule enables the selection of specific NNMi Nodes based on a specific filter
and it allows the possibility to name these nodes according to the rule. It is possible to
modify or change the naming rule attributes as follows:
 TNS directory (tnsDirectory field) can be changed. In the case that it is changed, a
new deployment of the customization will lead to the creation of this new TNS
directory within TeMIP.
 The Domain (in which the nodes are inserted) and Operation Context can also be
changed. In this case the original domain and Operation Contexts are not deleted
and will need to be removed manually.
It is important to note that a Topology Resynchronization is then needed in order to
propagate this change within ATNI.
69
4.4.3
TeMIP Distribution in the Auto Population
The naming rule enables the creation on a Domain and an Operation Context that will
depend on any different TeMIP director. The associated TeMIP director of this
Topology definition will always be the TeMIP director that deployed the
customization.
By providing this capability it enables a certain level of flexibility in how the ATNI
platform is configured. It is possible to have all objects on the same director or to
have a configuration with different layers which respects a typical TeMIP
configuration.
4.4.4
Multiple Naming Rules
In any customization it is possible to define one or more naming rules. Any naming
rule can share the same information. In the example below the naming rule
definitions are sharing the same Collection Domain and Operation Context. They also
use the same TNS directory as seen below:
Example 27
TeMIP Entity naming rules
<EntityNamingRules
<EntityNamingRule
domainManagingDirector=""
ocName="NODE_V1_oc"
entityNamePrefix=""
entityNameSuffix=""
tnsDirectory="NODE_V1_tns"
collectionDomainName="NODE_V1_domain"
isDefaultRule="True">
<NNMFilter name="AllNodes15"/>
</EntityNamingRule>
<EntityNamingRule
domainManagingDirector=""
ocName="NODE_V1_oc"
entityNamePrefix=""
entityNameSuffix=""
tnsDirectory="NODE_V1_tns"
collectionDomainName="NODE_V1_domain"
isDefaultRule="True">
<NNMFilter name="AllNodes16"/>
</EntityNamingRule>
</EntityNamingRules
On close examination of the example above it can be seen that the nodes will be
selected through two different naming rules using different NNMi filters where there
are no overlapping. The naming rule definition will be named using the same TNS
director, created in the same Domain and have the TeMIP collect using the same
Operation Context.
4.4.4.1
Topology Overlapping Rules
However, some precautions need to be taken when using multiple Naming rules.
What can happen if the same node is selected by several naming rules?
To fully understand all the possibilities concerning this, an understanding of how
these nodes remain persistent is necessary. Taking for example a customization
whose class name is NNMi_NODE and its custom identifier is V1; three NNMi Node
Custom Attributes will be created with the purpose of storing all TeMIP relevant
information for that specific node. ATNI stores the name, director, and status of the
node enabling to map to its appropriate TeMIP entity.
70
So whatever the number of naming rule for any one customization, ATNI has only
one possible mechanism for storing the TeMIP mapping for one node. Based on this
limitation the following rule is applied:
 In the case of overlapping in the naming rules the first naming rule definition
within the customization file is used to auto populate the object. All other naming
rules will have configuration problems. The deployment does not check this
information and so it is during the topology internal processing that this
configuration problem will be detected.
4.4.5
Multiple Customizations
One more capability of ATNI is the possibility to have several customizations
deployed to any TeMIP Adapter. From a topology point of view this means an NNMi
node could correspond to either of the following:
 Several TeMIP objects, for example CISCO_ROUTER and ORACLE_SERVER.
In this example both customizations are not exclusive.
 One and only one object, for example a CISCO_ROUTER. In this example this
customization is exclusive.
4.4.5.1
Topology Overlapping Rules
As in the case of the customizations, what happens if several exclusive
customizations select the same object?
 In the case of overlapping it is the first naming rule of the first customization
deployed that will manage the object population.
 The order of the different customizations is used in evaluating a node as follows:
 Exclusive customizations are selected first
 Followed by all other customizations
4.4.5.2
ATNI Versioning
ATNI supports versioning as follows:
The custom identifier attribute is used for versioning a customization. It is possible to
deploy two customizations that have the same class name but from two different
TeMIP directors. Where the first customization has a custom identifier V1 and the
second is V2.
However, precautions need to be taken concerning the TeMIP dictionary propagation
in the case of a distributed environment.
4.4.5.3
Customization Mirroring
The three following use cases highlight the non-support of the mirroring in some
ATNI configurations:
 The same (non-exclusive) customization (same global class) is deployed from
two different TeMIP directors with same naming (for instance
.temip.A_director) but with two different TNS namespaces.
In this context, the mirroring does not work because in fact the second
deployment is considered as an Update of the first one. Indeed, the
deployment phase is based on the couple: TeMIP Global Class name/ TeMIP
director name.
 The same (non-exclusive) customization (same global class and same
identifier) is deployed from two different TeMIP directors with different
TNS namespaces.
71
In this context, as there are same class and identifier, the NNMi Node Custom
Attributes are the same ones for both customizations and so only one
customization can map, manage a NNM node.
 There are two exclusive customizations deployed from two TeMIP directors
with two different TNS namespaces on one NNM station (via the TeMIP
Adapter):
 MINILINK_V1 (where MINILINK is the Global Class name and V1
the identifier) that has been deployed from TeMIP director A
 and the customization MINILINK_V2 (which is the same as
MINILINK_V1 except the identifier set to V2 and the TeMIP
director name changed) that has been deployed from TeMIP director
B.
In that specific case, one NNMi Node can be mapped as either a
MINILINK_V1 or a MINILINK_V2 object (exclusivity). As consequence, a
trap that originates from this node is targeted on the customization that
corresponds to the mapped node.
Important Note
For additional information, please refer to the Consulting Team.
4.5 Incident Mapping
The following section presents the part of the customization that is responsible for the
processing or mapping of the incidents( SNMP traps or management incidents) and
explains in more details the event mapping rule definition.
An event mapping rule is a set of rule definitions for one incident only except in one
special case the default event that acts as a ‘Default’ definition for a set of traps. One
event mapping for one specific incident allows defining for each TeMIP OSI field the
expected value (deduced from a varbind of the trap or values from incident or cia or
from the computation of a variable or directly a constant).
Shown below is an example of an entire event mapping rule definition for the
SNMPLinkUp trap:
Example 28
One SNMP Trap Event mapping rule
<EventMapping admin="Defined" eventName="SNMPLinkUp"
eventType="Snmp" eventOID="1.3.6.1.6.3.1.1.5.4">
<EventMappingRules>
<ManagedObjectMappingRule>
<EventMappingRule alarmFieldID="9"
type="ManagedObject" alarmFieldName="Managed Object"/>
<ExtendedClassInstance>
<GlobalInstanceLookup>
<TrapVariable label="sourceNodeName"
type="Reference"/>
</GlobalInstanceLookup>
<ChildClasses value="INTERFACE ${interfaceid}">
<Resolver label="interfaceid"
inputType="variable" inputValue=".1.3.6.1.2.1.2.2.1.1"/>
</ChildClasses>
</ExtendedClassInstance>
</ManagedObjectMappingRule>
<TeMIPEnumMappingRule type="MappingTableReference">
72
<EventMappingRule alarmFieldID="4"
type="TeMIPEnumeration" alarmFieldName="Perceived Severity"/>
<MappingTableReference
mappingTable="perceivedSeverity" inputType="TrapVariable">
<TrapVariable label="severity" type="Reference">
</TrapVariable>
</MappingTableReference>
</TeMIPEnumMappingRule>
<TeMIPEnumMappingRule type="MappingTableReference">
<EventMappingRule alarmFieldID="1"
type="TeMIPEnumeration" alarmFieldName="Event Type"/>
<MappingTableReference mappingTable="eventType"
inputType="TrapVariable">
<TrapVariable label="category" type="Reference">
</TrapVariable>
</MappingTableReference>
</TeMIPEnumMappingRule>
<TeMIPEnumMappingRule type="Constant">
<EventMappingRule alarmFieldID="3"
type="TeMIPEnumeration" alarmFieldName="Probable Cause"/>
<Constant label="SnmpTrapLinkUpDown"
type="Enum">65</Constant>
</TeMIPEnumMappingRule>
<TeMIPEnumMappingRule type="Constant">
<EventMappingRule alarmFieldID="200"
type="TeMIPEnumeration" alarmFieldName="Specific Problem"/>
<Constant label="SNMP_Link_UpDown"
type="Enum">411</Constant>
</TeMIPEnumMappingRule>
<AdditionalTextMappingRule>
<EventMappingRule alarmFieldID="7"
type="AdditionalText" alarmFieldName="Additional Text"/>
<MessageText>Agent Interface Up (linkUp Trap) on
interface $.1.3.6.1.2.1.2.2.1.1</MessageText>
</AdditionalTextMappingRule>
</EventMappingRules>
<TestCases>
</TestCases>
</EventMapping>
Shown below is an example of an entire event mapping rule definition for the
ConnectionDown Incident:
Example 29
One Management Incident Event mapping rule
<EventMapping admin="Defined" eventName="ConnectionDown"
eventType="NNM" eventOID="">
<EventMappingRules>
<ManagedObjectMappingRule>
<EventMappingRule alarmFieldID="9"
type="ManagedObject" alarmFieldName="Managed Object"/>
<ExtendedClassInstance>
<GlobalInstanceLookup>
<TrapVariable
label="sourceNodeName" type="Reference"/>
</GlobalInstanceLookup>
</ExtendedClassInstance>
</ManagedObjectMappingRule>
<TeMIPEnumMappingRule
type="MappingTableReference">
73
<EventMappingRule alarmFieldID="4"
type="TeMIPEnumeration" alarmFieldName="Perceived Severity"/>
<MappingTableReference
mappingTable="perceivedSeverity" inputType="TrapVariable">
<TrapVariable
label="severity" type="Reference">
</TrapVariable>
</MappingTableReference>
</TeMIPEnumMappingRule>
<TeMIPEnumMappingRule
type="MappingTableReference">
<EventMappingRule alarmFieldID="1"
type="TeMIPEnumeration" alarmFieldName="Event Type"/>
<MappingTableReference
mappingTable="eventType" inputType="TrapVariable">
<TrapVariable
label="category" type="Reference">
</TrapVariable>
</MappingTableReference>
</TeMIPEnumMappingRule>
<TeMIPEnumMappingRule type="Constant">
<EventMappingRule alarmFieldID="3"
type="TeMIPEnumeration" alarmFieldName="Probable Cause"/>
<Constant
label="CommunicationsSubsystemFailure" type="Enum">6</Constant>
</TeMIPEnumMappingRule>
<TeMIPEnumMappingRule type="Constant">
<EventMappingRule
alarmFieldID="200" type="TeMIPEnumeration" alarmFieldName="Specific
Problem"/>
<Constant label="ConnectionDown"
type="Enum">552</Constant>
</TeMIPEnumMappingRule>
<AdditionalTextMappingRule>
<EventMappingRule alarmFieldID="7"
type="AdditionalText" alarmFieldName="Additional Text"/>
<MessageText>Connection
Down</MessageText>
</AdditionalTextMappingRule>
</EventMappingRules>
<TestCases>
</TestCases>
</EventMapping>
An event mapping rule is composed of four main parts:
 Global Event information. This information is used to define the name of the
incident being mapped. In case of SNMP Traps OID of the Trap is to be
provided. It is from within this section that will determine if the event is selected
or not and where it is defined as default event for mapping for this customization.
 Event Mapping Rules. This is the main part of the trap mapping. For each OSI
field a mapping definition is specified depending on its type of mapping. There
are three types of event mapping rules:
 Rules for mapping the Managed Object
 Rules for mapping the TeMIP Enumeration fields
 Rules for mapping the Additional Text
 Computed Variables. This part contains the set of Computed Variables used for
this trap.
74
 Test Cases. This part enables the user to define different test cases that will inject
SNMP traps with any given parameters giving the ability to validate the mapping
of the trap in particular.
4.5.1
Global Event Information
The single most important attribute of the SNMP trap definition is the eventOID. This
is the SNMP OID which is internally used by TeMIP Adapter component to process
the different phases of the event mapping such as the event identification and or event
resolution (see Chapter Event Mapping in User Guide).
The single most important attribute of the Management incident definition is the
eventName. This is the Event Name is internally used by TeMIP Adapter component
to process the different phases of the event mapping such as the event identification
and or event resolution (see Chapter Event Mapping in User Guide).
Important Note
Changing the OID value is the equivalent of defining a new event mapping for a new
SNMP trap.
Changing the Event Name value is the equivalent of defining a new event mapping
for a new Management incident. The EventName should be exactly the same as
defined in NNMi Incident configuration for management incidents processing
4.5.1.1
How to Select a Trap
Once an event mapping is defined in the customization XML file, it is then possible
to indicate whether this event is to be considered or not by TeMIP Adapter
component. This is the purpose of the admin attribute and it can take any of the
following values:
 Defined. This event will be used and an associated mapping will be built.
 Undefined. This event will be not used and kept for future usage.
 Discarded. This event will be not considered.
Once an event mapping rule is defined for a dedicated NNMi incident, it is possible
to update this attribute to Discarded and redeploying the customization to the Adapter
which means that the Adapter will not manage or map this SNMP trap in real time.
4.5.1.2
How to Set the Default Event Mapping
Another important capability of the customization is the ability to define a default
event mapping. This is achieved using the isDefaultMapping attribute and can be seen
in the example that follows for the OV_Default event:
Example 29
Setting a default Event mapping
<EventMapping
admin="Defined"
eventName="OV_Default"
eventType="NNM"
eventOID="1.3.6.1.4.1.11.2.17.1.*"
isDefaultMapping="True">
Defining a default event mapping is mandatory for a customization as it must contain
at least one default event mapping. The purpose of having a default event mapping is
for the situation where an Incident is received and there is no definition
corresponding to it. In this case the TeMIP Adapter will use the default event
mapping to process it.
75
For example, if a customization does not contain definition for an OID
1.3.6.1.4.1.11.2.17.1.99999 then the default definition will be used
1.3.6.1.4.1.11.2.17.1.*.
There are two important recommendations to consider:
 The default event mapping must be terminated with a ‘*’ character
 The default event mapping is used only if the received SNMP OID matches it.
Otherwise it is the default event mapping defined in the default customization that
will be used, that is the OV_Default mapping.
4.5.1.3
How to map multiple events using a single mapping
It is possible to define a rule that matches multiple event OIDs using the “.*” wild
card suffix.
<EventMapping
admin="Defined"
eventName="OV_Multi"
eventType="NNM"
eventOID="1.3.6.1.4.1.11.3.*"
isDefaultMapping="False">
Using the above method all events beginning with OID “1.3.6.1.4.11.3” will be
mapped.
4.5.2
The Event Mapping Rules
This section describes a major part of the event mapping rule where the rules are
defined that govern how the trap is to be mapped. The rules will define each OSI field
that will be built in order to create and generate an associated OSI Alarm.
As the purpose is to generate an OSI Alarm to be collected by TeMIP, the following
OSI fields are the minimum required and need to be defined in each event mapping:
 Managed Object
 Event Type
 Perceived Severity
 Probable Cause
Should an event mapping rule not contain definitions corresponding to all of these
fields then the AM will discard the event with following error “Incomplete OSI
Event”. However please note that there is no validation when the customization is
processed in TeMIP Adapter concerning the OSI field mapping.
There are five types of mapping that are supported when defining the mapping for the
OSI fields. The mapping can be based on:
 Direct assignment to a constant allowing a set value for one field
 Deduced from an NNMi Predefined variable
 Deduced from the content of the SNMP trap varbinds or incident attributes. It can
be based on the OID of the varbind or its index position in the trap or Incident
values or CIA postion or CIA name
 Deduced from a Mapping Table. This mainly allows for static simple translations
based on a given key and a range values. For example, this enables the translation
of an NNMi severity into an equivalent TeMIP severity.
76
 Deduced from the computation of a variable (Computed Variable). This variable
is either a Conditional expression or a Regular expression or a generic mapping
table or corresponds to an External java code. The definition and the usage of
such variable is detailed in next chapter 4.5.3 How to use the Computed
Variables.
The following sections will focus on each of these mapping types and show how
some of these mapping types can contain more mapping types. For example, a key of
a given mapping table could be a Constant or TrapVariable type.
4.5.2.1
How to Define a Direct Assignment Using a Constant
In some cases, the event mapping rule could correspond to a defined value only that
is a hard coded value. In this case, it is simple and recommended to use a Constant
mapping type.
The following example shows how to set a Specific Problem using a TeMIP
enumeration rule to the value 5:
Example 30
Setting the Specific problem
<TeMIPEnumMappingRule type="Constant">
<EventMappingRule alarmFieldID="200"
type="TeMIPEnumeration"
alarmFieldName="Specific Problem"/>
<Constant
label="OV_Connection_DownUp"
type="Enum">5</Constant>
</TeMIPEnumMappingRule>
It could also be used to set the Interface value to 4 in a Managed Object rule as shown
in the example below:
Example 31
Setting the Managed object
<ManagedObjectMappingRule>
<EventMappingRule
alarmFieldID="9"
type="ManagedObject"
alarmFieldName="Managed Object"/>
<ExtendedClassInstance>
<GlobalInstanceLookup>
<TrapVariable label="sourceNodeName"
type="Reference"></TrapVariable>
</GlobalInstanceLookup>
<ChildClasses value="INTERFACE ${myInterface}”>
<Resolver label="myInterface" inputType="constant"
inputValue="4"/>
</ChildClasses>
</ExtendedClassInstance>
</ManagedObjectMappingRule>
4.5.2.2
How to Use the Predefined Variables
The TeMIP Adapter is one component of the Advanced TeMIP NNMi Integration
and its purpose is to adapt or translate NNM information into a form that can be used
by TeMIP. For a complete list of all predefined variables, see section 4.2.1
The example below shows the XML definition for the NNM predefined variables:
Example 32
How to define the NNM Predefined variable
<NNMPredefinedVariables>
<!-- New Incidents variables -->
77
<NNMPredefinedVariable dataType="OctetString"
<NNMPredefinedVariable dataType="OctetString"
<NNMPredefinedVariable dataType="OctetString"
<NNMPredefinedVariable dataType="OctetString"
<NNMPredefinedVariable dataType="OctetString"
<!-- New CIA Variable -->
<NNMPredefinedVariable dataType="OctetString"
<NNMPredefinedVariable dataType="OctetString"
<NNMPredefinedVariable dataType="OctetString"
<NNMPredefinedVariable dataType="OctetString"
<NNMPredefinedVariable dataType="OctetString"
<!-- SPI Related CIA Variabel-->
<NNMPredefinedVariable dataType="OctetString"
<NNMPredefinedVariable dataType="OctetString"
<NNMPredefinedVariable dataType="OctetString"
<NNMPredefinedVariable dataType="OctetString"
<NNMPredefinedVariable dataType="OctetString"
label="cia.thresholdPreviousValue"/>
<NNMPredefinedVariable dataType="OctetString"
label="cia.thresholdCurrentValue"/>
<NNMPredefinedVariable dataType="OctetString"
label="cia.thresholdMeasuredValue"/>
<NNMPredefinedVariable dataType="OctetString"
label="cia.thresholdMeasurementTime"/>
<!-- Standard variables -->
<NNMPredefinedVariable dataType="OctetString"
<NNMPredefinedVariable dataType="OctetString"
<!-- Deprecated variables -->
<NNMPredefinedVariable dataType="OctetString"
<NNMPredefinedVariable dataType="OctetString"
<NNMPredefinedVariable dataType="OctetString"
<NNMPredefinedVariable dataType="OctetString"
<NNMPredefinedVariable dataType="OctetString"
</NNMPredefinedVariables>
label="sourceName"/>
label="category"/>
label="severity"/>
label="nature"/>
label="sourceNodeName"/>
label="cia.address"/>
label="cia.snmpoid"/>
label="cia.eventoid"/>
label="cia.remotemgr"/>
label="cia.remotetopoid"/>
label="cia.thresholdReason"/>
label="cia.thresholdParameter"/>
label="cia.thresholdLowerBound"/>
label="cia.thresholdUpperBound"/>
label="temipConfigurationName"/>
label="temipStationName"/>
label="openViewSourceName"/>
label="openViewSeverity"/>
label="openViewCategory"/>
label="openviewMessage"/>
label="openviewTrapdConfMessage"/>
It is not recommended to modify these variable definitions as described in the
previous chapter and it is possible to add a new one.
Using any previous variable in an event mapping rule is possible using the
TrapVariableReference mapping type as follows:
Example 33
How to use the NNM variable definition
<ManagedObjectMappingRule>
<EventMappingRule
alarmFieldID="9"
type="ManagedObject"
alarmFieldName="Managed Object"/>
<GlobalInstanceLookup>
<TrapVariable label="sourceNodeName"
type="Reference">
</TrapVariable>
</GlobalInstanceLookup>
</ManagedObjectMappingRule>
4.5.2.3
How to Use Custom Incident Attributes
Most of the Custom Incident Attibutes can be very useful and it may be beneficial to
leverage their content within an event mapping rule. In case of SNMP traps, the
received incidents contain trap varbinds within the CIA.
78
The CIA mapping type enables the user to take into account a specified varbind or
CIA based either on an OID or name or an indexed position within the CIA content
list.
The following example illustrates how to leverage the use of obtaining this content to
be used in the mapping. Taking an example of the trap OV_IF_Disconnected_Segs
definition where it is indicated that varbind (CIA) at index 7 contains the name of the
interface in error according to the MIB. The following mapping rule definition can be
then constructed:
Example 34
Using SNMP trap varbinds
<ManagedObjectMappingRule>
<EventMappingRule
alarmFieldID="9"
type="ManagedObject"
alarmFieldName="Managed Object"/>
<ExtendedClassInstance>
<GlobalInstanceLookup>
<TrapVariable label="sourceNodeName"
type="Reference"></TrapVariable>
</GlobalInstanceLookup>
<ChildClasses value="INTERFACE ${myInterface}">
<Resolver label="myInterface" inputType="variable"
inputValue="vb7"/>
</ChildClasses>
</ExtendedClassInstance>
</ManagedObjectMappingRule>
In a deprecated mode, ATNI supports the use of varbinds (CIA) index. However, it is
recommended to use the CIA name or CIA OID instead of Index.The following
example illustrates a sample Event Mapping rule that uses two Incidentlabelname
with a CIA name in the MO Mapping rule:
<ManagedObjectMappingRule>
<EventMappingRule type="ManagedObject"
alarmFieldName="MANAGED_OBJECT" alarmFieldID="9"/>
<ClassInstance type="TrapVariable" classIdentifier="2010"
className="NNMi_NODE">
<TrapVariable label="myLabel1" type="Definition">
<TrapVariableDefinition>
<IncidentLabelName>sourceNodeName</IncidentLabelName>
</TrapVariableDefinition>
</TrapVariable>
</ClassInstance>
<ClassInstance type="TrapVariable" classIdentifier="2"
className="INTERFACE">
<TrapVariable label="myLabel2" type="Definition">
<TrapVariableDefinition>
<IncidentLabelName>cia.address</IncidentLabelName>
</TrapVariableDefinition>
</TrapVariable>
</ClassInstance>
</ManagedObjectMappingRule>
4.5.2.4
How to Use the Mapping Table
In certain cases, it may be useful to define a table of corresponding values.
Considering that it highly likely that there are cases where there is the possibility for
79
mapping NNMi relevant value directly to TeMIP relevant value, for example alarm
severity.
This purpose of the MappingTableReference mapping type is to define a translation
table based on non computed values. However, the access key could be a static value
such as a Constant type, varbind or an NNM predefined variable.
A table can be named in order to be re-used by several event mappings within a
customization. The following example shows how the perceived severity can be
deduced using the default customization:
Example 35
How to define a Mapping Table
<MappingTable tableName="perceivedSeverity" osiField="4">
<Description>Mapping of NNMi severity into TeMIP
severity</Description>
<MappingRow mappingValue="1" key="CRITICAL"/>
<MappingRow mappingValue="2" key="MAJOR"/>
<MappingRow mappingValue="3" key="MINOR"/>
<MappingRow mappingValue="4" key="WARNING"
isDefaultMapping="True"/>
<MappingRow mappingValue="5" key="NORMAL"/>
</MappingTable>
In an event mapping, the following example shows how to use this table in specifying
the name of the table to be used and the input key to look up the corresponding value.
Note that the key is determined from an NNM predefined variable reference.
Example 36
How to use the Mapping Table definition
<TeMIPEnumMappingRule
type="MappingTableReference">
<EventMappingRule
alarmFieldID="4"
type="TeMIPEnumeration"
alarmFieldName="Perceived Severity"/>
<MappingTableReference
mappingTable="perceivedSeverity"
inputType="TrapVariable">
<TrapVariable
label="openViewSeverity"
type="Reference"/>
</MappingTableReference>
</TeMIPEnumMappingRule>
In the example above the input key is a referenced predefined variable but it could
easily be a Constant, ComputedVariable or TrapVariableDefinition mapping type.
Example 36(a): ComputedVariableUsage for MappingTableReference
<TeMIPEnumMappingRule type="MappingTableReference">
<EventMappingRule
alarmFieldID="4"
type="TeMIPEnumeration"
alarmFieldName="Perceived Severity"/>
<MappingTableReference
mappingTable="TCPConnStatePerceivedSeverity"
inputType="ComputedVariable">
<ComputedVariable label=”mySeverity"/>
</MappingTableReference>
</TeMIPEnumMappingRule>
80
<VariableDefinition
name="mySeverity"
type="external"
datatype="String">
<External className ="HandleOID">
<ArgNetworkEvent/>
<Arg inputValueType="string"
inputType="constant"
inputValue=".1.3.6.1.4.1.9.9.311.1.1.2.1.17"/>
</External>
</VariableDefinition>
Here the access Key of the MappingTable is determined by a ComputedVariable
whose value is in turn obtained from an external class (HandleOID).
4.5.2.5
How to Customize the Managed Object Rule
The Managed Object rule is one of the mandatory OSI field rules. Its customization
requires understanding on how the TeMIP Adapter processes this rule:
 A Managed Object rule is composed of one or several ClassInstance rules. A
ClassInstance corresponds to one level of a TeMIP entity containing its class and
instance.
 Other possibility to define the Managed Object rule is to use the
‘ExtendedClassInstance’ structure that allows specifying the
‘GlobalInstanceLookup’ part (that corresponds to the first level of the Managed
Object) and the ‘ChildClasses’ part as a String (with resolvers).
 The first level of the Managed Object rule is used to lookup in the NNMi database
the corresponding NNMi node instead of using the mapping.
 It is possible to use all mapping types when constructing the ClassInstance rule
such as Constant, TrapVariableReference, TrapVariableDefinition and the
MappingTable for each level of the ClassInstance.
 It is possible to use ComputedVariable type when constructing ClassInstance rule
for childlevel.
 It is possible to use any Computed Variables as resolvers in the definition of the
‘childClasses’ part of the ExtendedClassInstance.
A Managed Object can be constructed either by using Extended Class Instance or a
Set of Class Instances. The following tables list the datatypes that are supported at
the root level and child level of a Managed Object.
Extended Class Instance
Level
Description
Supported Datatypes
Root
Defined by using Global
Instance Lookup
Trap Variable and Constant
Child
Defined by using Resolvers
81
Set of Class Instances
Level
Supported Datatypes
Root
Trap Variable, Constant, and Mapping Table Reference
Child
Trap Variable, Constant, Mapping Table Reference, and Computed
Variables.
The following example illustrates a ClassInstance-based Managed Object rule that
mixes different mapping types in its definition. This leads to having a Managed
Object equal to:
NNMi_NODE sourceNode INTERFACE 5
In this example we presume that ‘sourceNode’ is the result of the first lookup level
and varbind indexed 7 contains the value 5:
Example 37
Customizing the Managed Object with ClassInstance pairs
<ManagedObjectMappingRule>
<EventMappingRule
alarmFieldID="9"
type="ManagedObject"
alarmFieldName="Managed Object"/>
<ClassInstance
classIdentifier="2010"
className="NNMi_NODE"
type="TrapVariable">
<TrapVariable
label="sourceNodeName"
type="Reference"/>
</ClassInstance>
<ClassInstance
classIdentifier="2"
className="INTERFACE"
type="TrapVariable">
<TrapVariable
label="interfaceName"
type="Definition">
<TrapVariableDefinition>
<IndexVB>7</IndexVB>
</TrapVariableDefinition>
</TrapVariable>
</ClassInstance>
</ManagedObjectMappingRule>
82
Example 37(a) ComputedVariable usage in ClassInstance
<ManagedObjectMappingRule>
<EventMappingRule
alarmFieldID="9"
type="ManagedObject"
alarmFieldName="Managed Object"/>
<ClassInstance
classIdentifier="2010"
className="NNMi_NODE"
type="TrapVariable">
<TrapVariable
label="sourceNodeName"
type="Reference"/>
</ClassInstance>
<ClassInstance
classIdentifier="2"
className="INTERFACE"
type="ComputedVariable">
<ComputedVariable
label=”findInterfaceName”>
</ClassInstance>
</ManagedObjectMappingRule>
In the above ManagedObject mapping, the instance of INTERFACE class is
determined by an external jar having “findInterfaceName” class.
Following is the same example but using an ExtendedClassInstance-based Managed
Object rule:
Example 38
Customizing the Managed Object with ExtendedClassInstance
<ManagedObjectMappingRule>
<EventMappingRule
alarmFieldID="9"
type="ManagedObject"
alarmFieldName="Managed Object"/>
<ExtendedClassInstance>
<GlobalInstanceLookup>
<TrapVariable label="sourceNodeName"
type="Reference"/>
</TrapVariable>
</GlobalInstanceLookup>
<ChildClasses value=”INTERFACE ${myInterface}”>
<Resolver label=” myInterface” inputType=”variable”
inputValue=”vb7”/>
</Resolver>
</ChildClasses>
</ExtendedClassInstance>
</ManagedObjectMappingRule>
The resolver definition is described in the special part dedicated to the Computed
Variable (Regexp type variable). The label defined in the value part must correspond
to a resolver label.
83
Example 38(a) Constant usage in GlobalInstanceLookup
<ManagedObjectMappingRule>
<EventMappingRule
alarmFieldID="9"
type="ManagedObject"
alarmFieldName="Managed Object"/>
<ExtendedClassInstance>
<GlobalInstanceLookup>
<Constant label="EMS"
type="String">colt90e.fc.hp.com</Constant>
</GlobalInstanceLookup>
<ChildClasses value=”INTERFACE ${myInterface}”>
<Resolver label=” myInterface” inputType=”variable”
inputValue=”vb7”/>
</Resolver>
</ChildClasses>
</ExtendedClassInstance>
</ManagedObjectMappingRule>
The above example shows how to use constant in GlobalInstanceLookup.
Important Note
ExtendedClassInstance-based ManagedObject rule is the recommended one as it is
more readable.
If any problem occurs (for instance if vb7 is not provided in the last example) during
the mapping of the Managed Object child classes, the following is done:
 The final Managed Object will contain the unresolved variables
NNMi_NODE .node.n1 INTERFACE ${myInterface}
 The Notification Identifier will be provided to avoid intempestive TeMIP
clearance (internal random value)
 The Additional Text will contain the following content:
“New targeting due to error in Managed Object
resolution [Original Text]: ...”
4.5.2.6
Special Identification Phase
The first level of the Managed Object rule should be used to specify the real source of
the event. When the TeMIP Adapter processes the first level it looks up the NNMi
database in order to retrieve the mapping associated to this source, that is the NNMi
node is question.
The retrieval of the real event source is dependent on what is defined in the
customization XML file. The Identification step addressed the case when using the
sourceNodeName, but also addresses SNMP complex cases such as Proxy
management (see Chapter 4.7 for further information on how to customize this).
 In the situation that it is impossible to retrieve a specific source, the source is
deduced from the internal content of the incident either from the value of attribute
sourceNodeName or sourceName.
Then, the lookup will be done based on this value. For example, if the NNMi
database contains the following information:
Node name: n1
84
TNTNNM_NODE_V1_Mapping: NNMi_NODE .node.n1
TNTCISCO_V1_Mapping: CISCO cisco.n1
If the same event occurs again on the source n1, the two mapping will be retrieved
and possibly depending on the sophistication of the customization rules, two events
will be generated with two different Managed Objects:
 The first Managed Object root being: NNMi_NODE .node.n1 INTERFACE 5
 The second Managed Object root being: CISCO CISCO.n1 INTERFACE 5
As described before the first level results from a lookup while the rest is calculated
from the mapping rules.
4.5.2.7
Targeting to the NNM_CONFIGURATION and NNM_STATION
Classes
In all the previous cases, the purpose of the Managed Object rule is to target the trap
to a TeMIP model corresponding to a managed SNMP device.
However, in some cases, it can be necessary to target traps to the following TeMIP
administration classes named NNM_CONFIGURATION and NNM_STATION. The
purpose of these classes is to manage the machine where both NNM and the Adapter
reside.
For example, when NNMi generates a management incident targeting the NNMi
station, the default customization has been designed to target his trap to a suitable
TeMIP Station as follows:
Example 39
Special NNM_CONFIGURATION class targeting
<ManagedObjectMappingRule>
<EventMappingRule
alarmFieldID="9"
type="ManagedObject"
alarmFieldName="Managed Object"/>
<ClassInstance
type="TrapVariable"
classIdentifier="1447"
className="NNM_CONFIGURATION">
<TrapVariable
label="temipConfigurationName"
type="Reference"/>
</ClassInstance>
<ClassInstance
type="TrapVariable"
classIdentifier="1"
className="NNM_STATION">
<TrapVariable
label="temipStationName"
type="Reference">
</ClassInstance>
</ManagedObjectMappingRule>
There is no need to specify the instance name of the NNM_CONFIGURATION or
the NNM_STATION. as the temipConfigurationName, and the temipStationName
predefined variables fill this purpose.
85
Important Note
Targeting on NNM_CONFIGURATION class or subclass is only possible using the
ClassInstance pairs. It is not supported using the ExtendedClassInstance.
4.5.2.8
How to Customize any TeMIP Enumeration Rule
All other fields except for the Managed Object and the Additional Text rules must be
defined as a TeMIPEnum rule which means the resulting mapping value is always an
Integer enumeration.
It is not possible to generate other value types such as a String, Set Of,…
The OSI mandatory fields need to be defined, that is, the Event Type, Perceived
Severity and Probable Cause however it is possible to add other rules corresponding
to other TeMIP enumerations. In the example below a new rule is added to define an
enumeration for the TeMIP Specific Problem:
Example 40
The TeMIP enumeration rule
<TeMIPEnumMappingRule type="Constant">
<EventMappingRule
alarmFieldID="200"
type="TeMIPEnumeration"
alarmFieldName="Specific Problem"/>
<Constant
label="OV_APA_Statistics"
type="Enum">245</Constant>
</TeMIPEnumMappingRule>
Any TeMIPEnum rule can be based on either a Constant or a MappingTable or a
TrapVariable or a Computed Variable.
When adding a new field in the Event mapping it must respect the following rules:
 The alarmFieldID is the ID of the TeMIP attribute of the Alarm Object (child of
the Operation Context global class).
 If not already defined in the TeMIP Alarm Object subclass, this new OSI field
must be created in TeMIP using the AH_FM (Alarm Object Customized Fields)
tool named /usr/opt/temip/bin/temip_ah_user_defined_attr
4.5.2.9
How to Customize the Additional Text Rule
The Additional Text is now a customizable OSI field. There are three different
possibilities of customization:
 Either the user wants the NNMi message as configured in NNMi incident
configuration. In that case, the XML Message type is ‘nnm’ (default if nothing is
mentioned). ATNI propagates the Message Text content of the incident as it is
defined in this file.
Also, all modification made to NNMi incident configuration will be automatically
taken into account without stopping TeMIP Adapter or redeploying the
customization.
Example 41
Customizing the Additional Text to be based on NNMi incident
configuration
<AdditionalTextMappingRule>
<EventMappingRule alarmFieldID="7" type="AdditionalText"
alarmFieldName="Additional Text"/>
<MessageText>CPU on $sourceNodeName utilization is too
86
high</MessageText>
</AdditionalTextMappingRule>
In that case, the Message Text (here, “CPU on $sourceNodeName utilization is
too high ”) is not used but this is what is generated by the ‘tnt_custom_gen’ tool.
In that case, the output of the Additional Text will be:
“CPU on tfriat7 utilization is too high”
 Or the user wants to define a message text that could contain free text, nnm
incident attributes and possible computed variables. In that case, the XML
Message type is ‘user’.
All modification made in the customization file are taken into account in real-time
using the NNMi AM script called tnt_nnm_am_load_custom.sh or using the
directive deploy.
Example 42
Customizing the Additional Text to be based on free text
containing NNMi incident variables and Computed Variables
<AdditionalTextMappingRule>
<EventMappingRule type=“AdditionalText”
alarmFieldName=“ADDITIONAL_TEXT” alarmFieldId=“7”/>
<MessageText type=”user”>This is a new message with
information vb3: $3 and computation: ${computation}>
<Resolver label=”computation” inputType=”variable”
inputValue=”compute”/>
</MessageText>
</AdditionalTextMappingRule>
…
<!—Later in local Computed Variables part -->
<ComputedVariables>
<!—Parsing of the varbind 4 -->
<VariableDefinition name=”compute” type=”regexp”
datatype=”String”>
<Regexp pattern=”(.*):.*” output=”${matcher1}”
inputType=”variable” inputValue=”vb4”/>
</VariableDefinition>
</ComputedVariables>
…
In that example, $3 is a NNM variable corresponding to the varbind at position
three and ${computation} is a computed variable. The definition of the variable
called “compute” can be done either locally to a trap (here in the example) or
globally for the customization. In that case, with vb3=”2” and
vb4=”problem=19:resolution=20”, the output of the Additional Text will be:
“This is a new message with information vb3: 2 and
computation problem=19”
 Or the user wants to deduce the Additional text from complex processing so it
needs to be based on a Computed Variable.
In that case, all modifications made in the customization file are taken into
account in real-time using the NNMi AM script called
tnt_nnm_am_load_custom.sh or using the directive deploy.
Example 43
Customizing the Additional Text to be based on a Computed
Variable
<AdditionalTextMappingRule>
<EventMappingRule type=“AdditionalText”
alarmFieldName=“ADDITIONAL_TEXT” alarmFieldId=“7”/>
<ComputedVariable label=”myAddText”>
87
</AdditionalTextMappingRule>
…
<!—Later in local Computed Variables part -->
<ComputedVariables>
<!—Parsing of the varbind 4 -->
<VariableDefinition name=”compute” type=”regexp”
datatype=”String”>
<Regexp pattern=”.*=(.*):.*=(.*)”
output=”${matcher1}/${matcher2}” inputType=”variable”
inputValue=”vb4”/>
</VariableDefinition>
</ComputedVariables>
…
In that example, the computed variable “myAddText” is defined in the
ComputedVariable part for the trap or globally to the customization.
In that case, with vb4=”problem=19:resolution=20”, the output of the Additional
Text will be:
“19/20”
For further details, refer to section 4.5.3.
4.5.3
How to use the Computed Variables
The Computed Variable is the capability for the user to define a variable that
performs some processing more and less complex such as extracting information
from a text (Regular expression), testing varbinds values to deduce a result
(Conditional expressions)… and to apply it for any trap mapping, any OSI field.
4.5.3.1
Definition and usage
The Computed Variable is a new feature that improves the capability of
customization based on a Constant, an incident attribute (wrapped variables deduced
from the trap such as the varbinds or the NNMi predefined information linked to the
incident) or a MappingTableReference (simple correspondence table).
A new definition is available within the customization file to declare and use a
computed variable within the Event Mapping (trap definition) as follows:
 Any computed variable has a name called “label” (string).
 A computed variable is either a “Regexp” variable or “Switch” variable or
“IfCondition” variable or “External” variable type depending on the context to
resolve.
 A variable can have Input information (if it is a “Switch” or “Regexp” type). The
Input information are materialized by the attribute”inputType” and “inputValue”
that respectively corresponds to the type of information provided as input of the
variable (constant or variable) and the value associated. Any “TrapVariable” type
and “ComputedVariable” are specified as “variable” and so can be used as input
of any other variable.
 A variable used by one other must be declared before it is used.
Example 44
Computed variable definition
<VariableDefinition name="myNotifId" type="regexp"
datatype="int">
<Regexp pattern="(.*)/.*" output="${matcher1}“
</Regexp>
</VariableDefinition>
88
The following example illustrates the usage of the previous defined variables in the
Notification Identifier OSI field:
Example 45
Computed variable usage
<TeMIPEnumMappingRule type=”ComputedVariable”>
<EventMappingRule type="TeMIPEnumeration"
alarmFieldName="NOTIFICATION_IDENTIFIER"
alarmFieldID="199"/>
<ComputedVariable label=“ myNotifId” inputType=”variable”
inputValue=“vb3”>
</TeMIPEnumMappingRule>
Scope of a computed variable
A computed variable is defined globally for an entire customization or locally for one
trap.
To make a Global Variable, the variable must be defined in the
GlobalComputedVariables part of the customization (located between the
NNMPredefinedVariables and the EntityModel parts) as follows:
Example 46
Global Computed variable definition
<!DOCTYPE Customization SYSTEM "../Customization.dtd">
<Customization identifier="V1" className="NNMi_NODE" …>
<Revisions>…</Revisions>
<AMDefinition …/>
<MIBModules>…</MIBModules>
<NNMPredefinedVariables>…</NNMPredefinedVariables>
<GlobalComputedVariables>
<!-- One global definition takes place here -->
<VariableDefinition name=”parsePC” type=”regexp”
datatype=”Int”>
<Regexp pattern=”(.*):.*” output=”${matcher1}”/>
</VariableDefinition>
</GlobalComputedVariables>
<EntityModel> … </EntityModel>
…
</Customization>
Such variable can be used by any trap definition (Event Mapping rule) for any TeMIP
OSI field of the customization. The interest of such variable is to avoid duplication of
same processing for different traps.
To define a variable locally, a new section is defined within the EventMapping called
ComputedVariables.
Example 47
Local Computed variable definition
<EventMapping eventName=”OV_Connection_Down”
eventOID=”.1.3.6.1.4.1.11.2.17.1.0.40000004” admin=”Defined”
eventType=”Snmp”>
<!-- List of TeMIP OSI fields -->
<EventMappingRules> … </EventMappingRules>
<!-- List of variables used -->
<ComputedVariables>
<!-- One local definition takes place here -->
<VariableDefinition name=”parsePC” type=”regexp”
datatype=”Int”>
<Regexp pattern=”(.*):.*” output=”${matcher1}”/>
</VariableDefinition>
89
</ComputedVariables>
<TestCases/>
</EventMapping>
Such variable can be used only within the specified trap for any previous OSI fields.
This is the DTD that forces to define firstly the TeMIP OSI fields and after the
Computed Variables used. In runtime behaviour, the variable will be computed
firstly, one after one, and then each TeMIP OSI field will be evaluated.
Rules related to computed variables
Usage
Dos’
 There is no limitation on the
number of computed
variables defined in a
customization (global to a
customization or local to a
trap).
Definition
Successive Usage and
Scope
Input Value
External Type
Computed Varaible
4.5.3.2

It is possible to traduce
complex processing by
defining ‘successive’
computed variables.

Ensure that all global
variables and local variables
have unique names.
Dont’s
Within a customization, it is
not possible to define a single
variable several times. (This
condition applies irrespective
of the scope i.e., global or
local).
Order of definition defines the scope
of the computed variable. When two
global variables are defined, the
second variable will not be in scope
while evaluating the first one)
Do not refer the Local
Computed Variable from a
global Computed variable
definition; because local
variable will not be in scope
while evaluating the global
variable.
Define an NNM Predefined Variable
with OID and Name, and use it in
any of OSI Field Definition for more
readability.
Do not use <OID> in the
input value, even though it is
valid.
Do not use $.<OID> in the
inputvalue
While creating the JAR File
manually, the external java library
name should be tnt_external_lib.jar,
How to use the Regular expression type variable (Regexp)
The Regular expression type variable allows defining for the user a variable that is
able to deduce a value based on pattern matching (extracting suitable information).
The Regular Expression type is based on a pattern that matches the input string
provided (either defined in the variable or in the trap definition). The output defined
in the variable respects the following rules:
 The output string corresponds to the string the user wants to retrieve.
90
 The JAVA Regexp pattern is used for the pattern: any information to capture is
marked using the special character ‘(…)’ such as (.*) that selects everything.
 Any capture is materialized by a predefined variable named ‘matcherx’ where ‘x’
corresponds to the position.
 Within the output string, it is possible to display any variables: the variables
substitution is performed using the following syntax ${<variable name>}.
 Any variable previously processed could be displayed in indicating its label
variable.
 The Input information is optional in the Variable definition. Indeed, it may be
possible to define it within the TeMIP OSI field definition (custom Event Map). If
the input information is defined at OSI field level and in the variable definition
then the OSI field has higher priority. This allows defining a default behavior for
the variable and a specific behavior for any OSI field depending on the context
(trap content).
 The inputType is the type of the input information (variable, constant) and the
inputValue is the value corresponding to the type. For constant, it is the direct
value, for variable it is the label associated to the computed variable or trap
variable (varbind, nnm predefined).
Limitation
 The character ‘$’ is not supported in any “capture” and “resolver”.
 Strange substitution may occur when pattern is based on multiple characters
such as ‘:’ or ‘#” and if the output does not mach the same number of
characters. For instance, if the pattern is “.*:(.*):.*” and input value is
“aaa:bbb:ccc:ddd”, output value will be ‘ccc’. The Java Regular expression
does not operate exactly like Unix one.
 Computed variable previously defined cannot be directly refered in output
string. It must be resolved through a resolver label
Example 48
Simple regular expression used for the Notification Identifier
field based on single varbind3
<TeMIPEnumMappingRule type=”ComputedVariable”>
<EventMappingRule type="TeMIPEnumeration"
alarmFieldName="NOTIFICATION_IDENTIFIER"
alarmFieldID="199"/>
<ComputedVariable label=“notifIdRegExp”
inputType=”variable” inputValue=“vb3”>
</TeMIPEnumMappingRule>
…
<VariableDefinition name="notifIdRegExp" type="regexp"
datatype="string">
<Regexp pattern=".*:(.*)" output="${matcher1}“></Regexp>
</VariableDefinition>
Example 49
Complex regular expression used for the Additional Text field
<AdditionalTextMappingRule>
<EventMappingRule type="AdditionalText"
alarmFieldName="ADDITIONAL_TEXT" alarmFieldID="7"/>
<ComputedVariable label=“addTextRegExp”>
</AdditionalTextMappingRule>
…
<VariableDefinition name="addTextRegExp" type="regexp"
91
datatype="string">
<Regexp pattern=".*:(.*):(.*):.*" output="MY TEXT:
${matcher1} MY SOURCE: ${matcher2} vb3=${data1}
myComputed=${data2}“ inputType=”variable” inputValue=”vb5”>
<Resolver label=”data1” inputType=”variable”
inputValue=“vb3"/>
<Resolver label=”data2” inputType=”variable”
inputValue=“computed1"/>
</Regexp>
</VariableDefinition>
The “Resolver” allows identifying the real variables to substitute in the output string.
It is “label” based. This means this is the label that is specified in the text that is
substituted at runtime by the associated information (variable or constant).
A “Resolver” is made of:
 A label: string information that is used for substitution in the target final string or
output
 A type: it is either “constant” or “variable”. In the “variable” scope, all
TrapVariable (Reference, Definition) and Computed Variables are included
 A value: for “constant” type, this is the direct value. For “variable” type, it
corresponds to the real name of the variable.
. In last example, the output contains “Pattern capture” variable, varbind variable and
previously built computed variable.
4.5.3.3
How to use the Conditional expression type variable
(IfCondition)
The Conditional expression type variable is the possibility for the user to define a
variable that performs tests on different information (varbinds and/or variables) and
to deduce a value from this condition.
The IfCondition type variable is based on classical “IF/THEN/ELSE” structure with
the following rules:
 There can have one or several clauses
 It is possible to use one operator at a time in a definition only.
 A Clause is defined with an operator and two operands. The operand is either a
TrapVariable or a ComputedVariable or a Constant.
 The following operators are available:
 Integer operators: equal, not-equal, greaterThan, lowerThan,
equalAndGreater, equalAndLower
 String operators: matches, not-matches. Both operators manage regular
expression as input. This can be done using two variables definitions.
 Unaired operator: isPresent. Although, it is possible to define several
“isPresent” clauses within one “Clause”. In that case, there is an ‘AND’
operator between all these operands.
 In the same way, the “Then” and optionally the “Else” Clauses are either based on
Constant or Variable.
 It is possible to define until two levels of encapsulations, mainly for managing the
isPresent operator in case of OR clause. For the other main operators NOOP and
AND, only one level is supported since:
 The NOOP operation including the isPresent is translated into an AND
operation
92
 The AND operation including the isPresent remains an AND operation with
new clause based on isPresent.
Hereunder is an illustration of the last points:
Example 50
Simple IfCondition expression used in the deduction of the
Perceived Severity OSI field
<TeMIPEnumMappingRule type=”ComputedVariable”>
<EventMappingRule type="TeMIPEnumeration"
alarmFieldName=“PERCEIVED_SEVERITY" alarmFieldID=“4"/>
<ComputedVariable label=“severityIf”/>
</TeMIPEnumMappingRule>
…
<VariableDefinition name=“severityIf" type=“ifCondition"
datatype="Int">
<IfCondition operator=“NOOP”>
<Clause operator=“equal”>
<Operand type=”variable” value=”vb4”/>
<Operand type=”constant” value=”0”/>
</Clause>
<Then outputType=”variable” outputValue=”vb5”/>
<Else outputType=”variable” outputValue=”vb4”/>
</IfCondition>
</VariableDefinition>
Example 51
IfCondition expression used in the deduction of the Perceived
Severity OSI field including the test of the presence of the
varbinds used
<ComputedVariable name=“severityIf" type=“ifCondition"
datatype="Int">
<IfCondition operator=“AND”>
<Clause operator=“isPresent”>
<Operand type=”variable” value=”vb4”/>
<Operand type=”variable” value=”vb6”/>
<IfClause operator=“OR”>
<Clause operator=“equal”>
<Operand type=”variable” value=”vb4”/>
<Operand type=”constant” value=”0”/>
</Clause>
<Clause operator=“equal”>
<Operand type=”variable” value=”vb4”/>
<Operand type=”constant” value=”1”/>
</Clause>
</IfClause>
<Then outputType=”variable” outputValue=”vb6”/>
<Else outputType=”constant” outputValue=”5”/>
</IfCondition>
</ComputedVariable>
The severity is deduced from the varbing at position four, the value is correct if it is
equal to 0 or to 1.
This processing is interpreted as:
IF ( isPresent(vb4) AND isPresent(vb6) AND ( (vb4=0) OR (vb4=1) )) THEN
use vb6
ELSE use value ‘5’
93
Limitation
It is not possible to have nested Condition Check as mentioned below
IF((vb1==1 AND vb2==2) OR (vb7<=”OSI” AND vb8 >=10))
4.5.3.4
How to use the Generic mapping table type variable (Switch)
The Generic mapping table type variable is the possibility to the user to define a
‘generic’ mapping table means the possibility to define any integer or string key in a
table where output for each case can be any constant or variable.
The Switch type variable is based on standard SWITCH structure with the following
rules:
 It is possible to define neither expression nor constant as input of the SWITCH: it
is a variable only (computed or trap variable).
 The Input part is optional. In the same way as for the Regular expression, the
‘input’ of the Switch can be specified either at the declaration or in the definition.
The declaration overloads the definition allowing several traps (means several
declarations/usages) to use the same variable with different inputs.
 It is mandatory to have a default Case in any definition
 The output of any case is either a Constant or a TrapVariable or a Computed
Variable type.
 The index is a string data such as ‘one or ‘1’. It is possible to specify several cases
but all index values need to be different. This allows mainly addressing NNM
Mibs load impact in trap that can be used as input of switch variable.
Example 52
Simple Switch variable used in the deduction of the Probable
Cause OSI field
<TeMIPEnumMappingRule type=“TrapVariable">
<EventMappingRule type="TeMIPEnumeration"
alarmFieldName=“PROBABLE_CAUSE" alarmFieldID=“3"/>
<ComputedVariable label=“pcSwitch”/>
</TeMIPEnumMappingRule>
…
<VariableDefinition name=“pcSwitch" type=“switch"
datatype="Int">
<Switch inputType=”variable” inputValue=”vb5”>
<Case index=“0” outputType=”variable”
outputValue=”vb6”/>
<Case index=“down” outputType=”variable”
outputValue=”vb6”/>
<DefaultCase outputType=”constant”
outputValue=”1000”/>
</Switch>
</VariableDefinition>
4.5.3.5
How to use the External type variable (External)
The External type variable allows defining for the user a variable where the
processing is developed in an external separate JAVA code. When processing is
complex and requires coding, the solution is to define an External variable in the
customization and to develop JAVA code associated.
Defining an External type variable in a customization must respect the following
rules:
 In fact, this is the complete full path of the JAVA class name the users needs to
indicate in the definition. It needs to correspond to the exact class present in the
external JAR library that contains the JAVA code.
94
Example 53
Link between the External variable definition and associated
JAR package (JAVA code)
The following external variable definition is set:
<VariableDefinition name=”pcExtFunct" type=”external"
datatype="Int">
<External className =”.com.ireland.galway.Add”>
…
</External>
<VariableDefinition>
Because associated JAR package contains following
information:
jar tvf myExternalPackage.jar
0 Wed Mar 28 16:50:26 BST 2007 com/
0 Wed Mar 28 16:50:26 BST 2007 com/ireland/
0 Wed Mar 28 16:50:26 BST 2007 com/ireland/galway/
972 Wed Mar 28 16:45:02 BST 2007
com/ireland/galway/Add.class
 There is no limitation regarding the number of arguments to define in the
customization associated to one External variable.
 The arguments are normalized with the three following information:
 the type of the parameter (int or string)
 the type or source of the parameter (constant, variable)
 finally the value of the parameter that corresponds to the final constant
(constant case) or variable label (variable case).
 If the user wants to have the entire trap content in the external processing, he
needs to use the ArgNetworkEvent attribute instead of the Arg one. It can have
only one ArgNetworkEvent per trap and he must define it in the first position.
 The output of an external computed variable is either an ‘int’ or a ‘string’
allowing to be mapped into any TeMIP OSI field supported by ATNI.
Example 54
External variable with three parameters (the trap, an integer
and a string)
<TeMIPEnumMappingRule type=“TrapVariable">
<EventMappingRule type="TeMIPEnumeration"
alarmFieldName=“PROBABLE_CAUSE" alarmFieldID=“3"/>
<ComputedVariable label=“pcExtFunct”/>
</TeMIPEnumMappingRule>
…
<VariableDefinition name=“pcExtFunct" type=“external"
datatype="Int">
<External className =”.com.france.nice.myProbableCause>
<ArgNetworkEvent/>
<Arg inputValueType=”string” inputType=”variable”
inputValue=”mycomputed1”/>
<Arg inputValueType=”integer” inputType=”constant”
inputValue=”10”/>
</External>
</VariableDefinition>
Once the customization XML file updated, the user needs to develop the JAVA code
that corresponds to this external variable.
95
Definition of the interface for any external variable (class)
Note
For more about computed variable API related information, refer the document
ATNIV6_Computed_Variable_API.pdf delivered as part of Customization Toolkit.
The API information is also available at "http://<NNMi Server Name>:7509/TNTadapter/Computed_variable_doc" after installing the Adapter in the NNM Server
Any external class must inherit from a JAVA class called ‘AbstractATNICommand’
that forces to define the following method:
ReturnedParam execute(List<Param> parametersList) throws
ATNICommandException
This is within this JAVA method the user integrates his own JAVA code.
The input parameters list contains the ‘Arg’ information specified in the
customization file. The Param class that corresponds to one argument offers the
following accessor methods to retrieve the runtime input information:
String getValueAsString(): To get the value as a String
int getValueAsInteger(): To get the value as a Integer
ValueType getValueType(): To get the type of the param
The ValueType class offers the following services:
String toString():
Int intValue():
To retrieve the name of the type (integer, string)
To retrieve the index of the parameter
If the ArgNetworkEvent attribute has been specified in the customization file, the
user can get the trap using the following accessor of the ‘AbstractATNICommand’
class:
NetworkEventFacade getNetworkEventFacade():
To retrieve the event
provided as parameter
The ReturnParam class only offers two constructors since an external method returns
a string or int value only:
ReturnParam(int value):
create one output parameter based on an integer
ReturnParam(String value): create one output parameter based on a string
To use all the classes or service provided by ATNI, the user needs to import a specific
development package called ‘.com.hp.atni.adapter.extensibility’.
Example 55
JAVA code example for Input Param manipulation
Package .com.france.nice;
import .com.hp.atni.adapter.extensibility.*;
import java.util.List;
class myProbableCause extends AbstractATNICommand {
ReturnParam execute(List<Param> parametersList) {
NetworkEventFacade event = null;
96
String param2 = null;
Int param1 = 0;
// Retrieve parameters
for (Param param : parametersList) {
If (param.getInputType() == “integer”) {
param1 = param.getValueAsInteger();
} else if (param.getInputType() == “string”) {
param2 = param.getValueAsString();
}
}
event = getNetworkEventFacade();
…
return new ReturnParam(param1 / param2); //based on
requirement return either param1 or param2
}
}
Services offered within any external function
Within the method, the user can log ERROR, INFO and WARNING messages
CLTracer.logInfoMessage : Add an INFO Message to TeMIP Adapter log
CLTracer.logErrorMessage : Add an ERROR Message to TeMIP Adapter log
CLTracer.logWarningMessage : Add an WARNING Message to TeMIP Adapter log
package com.hp.cms;
import com.hp.ov.temip.atni.adapter.extensibility.*;
import java.util.List;
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
import com.hp.ov.temip.atni.adapter.common.traces.*;
public class ComputeSeverity extends AbstractATNICommand {
static Log logger = LogFactory.getLog(ComputeSeverity.class);
public ReturnParam execute(List params) throws ATNICommandException {
NetworkEventFacade event = null;
String Severity = null;
String EventSource = null;
String AgentIPAddress = null;
String UUID = null;
String EventName = null;
Param AdminStatus = (Param)params.get(0);
Param FrontOperStatus = (Param)params.get(1);
int vb2 = AdminStatus.getValueAsInteger();
int vb3 = FrontOperStatus.getValueAsInteger();
event = getNetworkEventFacade();
Severity = event.getSeverityFromIncidentConfig();
EventSource = event.getEventSource();
AgentIPAddress = event.getAgentIPAddress();
EventName = event.getEventNameFromIncidentConfig();
UUID = event.getUuid();
CLTracer.logInfoMessage(logger,"ComputeSeverity",
"ComputeSeverity:Severity",Severity);
CLTracer.logInfoMessage(logger,"ComputeSeverity",
"ComputeSeverity:EventSource",EventSource);
CLTracer.logInfoMessage(logger,"ComputeSeverity",
"ComputeSeverity:AgentIPAddress",AgentIPAddress);
CLTracer.logInfoMessage(logger,"ComputeSeverity",
"ComputeSeverity:UUID",UUID);
97
CLTracer.logInfoMessage(logger,"ComputeSeverity",
"ComputeSeverity:EventName",EventName);
Enabling Logging using Log4j
Add the line shown below in (/var/opt/OV/TNT/adapter/http/webapps/TNTadapter/WEB-INF/classes/log4j.properties) to enable the logging from the
external Class (<ClassName>)
log4j.logger.com.hp.cms.<ClassName> =INFO,
Rlog4j.additivity.com.hp.cms.<ClassName>=false
 Adding a variable: this is the capacity to ‘create’ a new variable with its
associated value in order the Adapter processing can be based on afterwards.
Using this mechanism, the user may define one external variable and nevertheless
create several variables.
addVariable(String label, String value): Add a new variable called
‘label’ with the value ‘value’ in
the general event mapping
processing ready to be used
Limitation: if the variable already exists, it is not override.
When using the trap parameter, the NetworkEventFacade object provides all
following services about the trap:
 getEventType():
Provide the Trap OID based on enterprise OID.
 getEnterpriseOid():
Provide the Enterprise OID of the trap.
 getUuid():
Provide the Uuid (NNM Event Reference).
 getEventSource():
Provide the source of the trap that emits it.
 getEventNameFromIncidentConfig(): Provide the name of the Incident
defined in
NNMi Incident Configuration Database
 getSeverityFromIncidentConfig(): Provide the severity of the Incident defined
in NNMi Incident Configuration Database.
 getCategoryFromIncidentConfig():Provide the category of incident from the
NNMi Incident Configuration Database.
getMessageFromIncidentConfig() :Provide the message text of event defiend
NNMi incident Configuration Database.
 getGenericType():
Provide the generic type information of the trap
(6: non-generic, else (0-5) generic).
 getSpecificType()
Provide the specific type of the trap.
 getAgentHostName():
Provide the name of the agent that emits the trap.
 getAgentIPAddress():
Provide the IPAdress of the agent that emits the
trap.
 getRemoteSenderHostName(): Provide the remote agent (sender) of the trap
when this is a ‘remote’ trap.
 getRemoteSenderIPAddress(): Provide the IP Address of the remote agent
(sender) of the trap when this is a ‘remote’ trap.
98
 getNumVarbinds()
Provide the Number of varbinds present in the
trap.
 getVarbindByIndex():
Retrieve the varbind positioned at ‘index’.
 getVarbindByOid():
Retrieve the varbind having the OID equals to
param value
 getEventTime()
Provide the time when the trap has been emited
For more information on APIs, see the ATNIV6_Computed_Variable_API.pdf
Compiling an external class
Once the JAVA code is written, the user needs to compile it using the ‘Javac’
compiler (Version 1.5). This compilation step can be performed using command line
or via specific tool or development platform such as Ant, Eclipse...
As the compilation requires knowing the location where is stored the development
package named ‘.com.hp.atni.adapter.extensibility’, it is mandatory to perform
compilation on machine where the TNT Custom TK subset is installed. The
mandatory JAVA package required is stored under following location:
/opt/OV/TNT/customToolkit/lib/TNT-adapter-extensibility.jar
Example 56
External class Compilation simple command line
>ls com/france/nice/*
myProbableCause.java
>/usr/jdk1.5.0_11/bin/javac –classpath
.:/opt/OV/TNT/customToolkit/lib/TNT-adapterextensibility.jar com/france/nice/myProbableCause.java
>ls com/france/nice/*
myProbableCause.java
myProbableCause.class
Packaging aspect
Once the class file got, the user needs to package it into a JAR file. The name of the
JAR file is not important. If several .class files have been generated, they have to be
inserted in the same JAR package.
Example 57
Packaging the external JAVA classes into a JAR package
>jar cvf ./myExternalPackage.jar .
added manifest
adding: com/ (in = 0) (out = 0)(stored 0%)
adding: com/france (in = 0) (out = 0)(stored 0%)
adding: com/france/nice (in = 0) (out = 0)(stored 0%)
adding: com/france/nice/myProbableCause.class (in = 1910)
(out = 926)(deflated 46%)
Once the library got, the user needs to associate this external class package to the
ATNI Runtime kit. This is the role of the tool ‘tnt_custom_tool’ and in particular the
option ‘-e’:
Example 58
Creating an ATNI Runtime kit with an external class package
>ls
myExternalPackage.jar
CISCO_V1.xml
TNTFilters.xml
99
>/opt/OV/TNT/customToolkit/bin/tnt_custom_tool –e
./myExternalPackage.jar –c ./CISCO_V1.xml –f TNTFilters.xml
>jar tvf CISCO_V1.jar
0 Thu Jun 21 11:16:34
71 Thu Jun 21 11:16:34
621 Thu Jun 21 11:16:24
69531 Thu Jun 21 11:16:32
input/tnt_external_lib.jar
499960 Thu Jun 21 11:16:24
output/customization.xml
0 Thu Jun 21 11:16:22
MEST
MEST
MEST
MEST
2007 META-INF/
2007 META-INF/MANIFEST.MF
2007 input/TNTFilters.xml
2007
MEST 2007
MEST 2007 external/
After validation the tool ‘tnt_custom_tool’ generated the final ATNI Runtime kit that
contains the suitable files with ‘normalized’ naming (see Chapter 5 Generating a TNT
Runtime Kit). For the external library, it is automatically renamed into
‘tnt_external_lib.jar’ file (input directory).
Deployment aspect
The Customization deployment process takes in charge the deployment of this
package since it is included in the runtime kit. On Adapter side, this package will be
stored at the same location as the other customization files (customization.xml,
TNTFilters.xml):
/var/opt/OV/TNT/adapter/conf/customs/<class>.<director>
4.5.3.6
Example of Computed Variables usage
The purpose of this paragraph is to illustrate how different Computed Variables can
be used in order to solve one IP Domain trap mapping.
Context
The following example is based on the CISCO MIB that implements a
ciscoLS1010ChassisFailureNotification trap. This trap contains five varbinds that
represent a severity. Each severity corresponds to a TeMIP severity in one specific
table. The final Perceived Severity of the trap must result from the comparison of all
these severities, to keep the ‘more’ critical one (the highest severity).
Methodology
Based on such problem description, we identify three different processing that will
correspond to the future variables definitions:
 A processing that retrieves the TeMIP severity for each table: this processing
can be done by a SWITCH Computed Variable but five different variables
since there are five different values and translations.
 A processing that identifies which severity is the highest severity among all
the five severities: the IFCondition Computed Variable seems to do not map
the use case as there are a lot of conditions overlapping. The External
Computed Variable seems to be more appropriate.
Solution
The definition of the TeMIP OSI Perceived Severity field is:
Example 59
TeMIP OSI Perceived Severity definition
<EventMapping admin="Defined"
eventName="ciscoLS1010ChassisFailureNotification" eventType="Snmp"
eventOID=".1.3.6.1.4.1.9.5.11.2.0.1">
<EventMappingRules>
…
100
<TeMIPEnumMappingRule type="ComputedVariable">
<EventMappingRule alarmFieldID="4" type="TeMIPEnumeration"
alarmFieldName="Perceived Severity"/>
<ComputedVariable
label="ciscoLS1010ChassisTempStatusConvertionSeverity"/>
</TeMIPEnumMappingRule>
…
The first processing based on the varbind ‘1’ is a ‘simple’ correspondence table and
can be ‘traduced’ into a SWITCH Computed Variable as follows:
Example 60
The first SWITCH Computed Variable
<ComputedVariables>
<!— the first one table -->
<VariableDefinition name="ciscoLS1010ChassisP0StatusConvertion"
type="switch" datatype="Enum">
<Switch inputType="variable" inputValue="vb1">
<Case index="1" outputType="constant" outputValue="5"></Case>
<!-- Unknown-->
<Case index="2" outputType="constant" outputValue="6"></Case>
<!--ok-->
<Case index="3" outputType="constant" outputValue="3"></Case>
<!--Fault-->
<Case index="4" outputType="constant" outputValue="2"></Case>
<!--fanAlarm-->
<Case index="5" outputType="constant" outputValue="4"></Case>
<!--partialFault-->
<Case index="6" outputType="constant" outputValue="4"></Case>
<!--empty-->
<DefaultCase outputType="constant"
outputValue="6"></DefaultCase>
</Switch>
…
The result of such processing is a variable called
‘ciscoLS1010ChassisP0StatusConvertion’ that will contain a TeMIP severity.
Four other SWITCH Computed Variables can be defined with different index and
output value with the following names: ‘ciscoLS1010ChassisP1StatusConvertion’,
‘ciscoLS1010ChassisFanStatusConvertion’,
‘ciscoLS1010Chassis12VoltStatusConvertion’,
‘ciscoLS1010ChassisTempStatusConvertion’ as follows:
Example 61
The Four other SWITCH Computed Variables definitions
<ComputedVariables>
<!— other tables -->
<VariableDefinition name="ciscoLS1010ChassisP1StatusConvertion"
type="switch" datatype="Enum">
<Switch inputType="variable" inputValue="vb2">
<Case index="1" outputType="constant" outputValue="5"></Case>
<!-- Unknown-->
<Case index="2" outputType="constant" outputValue="6"></Case>
<!--ok-->
<Case index="3" outputType="constant" outputValue="3"></Case>
<!--Fault-->
<Case index="4" outputType="constant" outputValue="2"></Case>
<!--fanAlarm-->
<Case index="5" outputType="constant" outputValue="4"></Case>
<!--partialFault-->
<Case index="6" outputType="constant" outputValue="4"></Case>
<!--empty-->
<DefaultCase outputType="constant"
outputValue="6"></DefaultCase>
101
</Switch>
</VariableDefinition>
<VariableDefinition name="ciscoLS1010ChassisFanStatusConvertion"
type="switch" datatype="Enum">
<Switch inputType="variable" inputValue="vb3">
<Case index="1" outputType="constant" outputValue="5"></Case>
<!-- Unknown-->
<Case index="2" outputType="constant" outputValue="6"></Case>
<!--ok-->
<Case index="3" outputType="constant" outputValue="3"></Case>
<!--Fault-->
<Case index="4" outputType="constant" outputValue="2"></Case>
<!--fanAlarm-->
<Case index="5" outputType="constant" outputValue="4"></Case>
<!--partialFault-->
<Case index="6" outputType="constant" outputValue="4"></Case>
<!--empty-->
<DefaultCase outputType="constant"
outputValue="6"></DefaultCase>
</Switch>
</VariableDefinition>
<VariableDefinition
name="ciscoLS1010Chassis12VoltStatusConvertion" type="switch"
datatype="Enum">
<Switch inputType="variable" inputValue="vb4">
<Case index="1" outputType="constant" outputValue="6"></Case>
<!--ok--> <!-- Clear TeMIP Value -->
<Case index="2" outputType="constant" outputValue="1"></Case>
<!--outOfTolerance--> <!-- Critical TeMIP value-->
<Case index="3" outputType="constant" outputValue="5"></Case>
<!--Unknown--> <!--Indeterminate TeMIP Value-->
<DefaultCase outputType="constant"
outputValue="6"></DefaultCase>
</Switch>
</VariableDefinition>
<VariableDefinition name="ciscoLS1010ChassisTempStatusConvertion"
type="switch" datatype="Enum">
<Switch inputType="variable" inputValue="vb5">
<Case index="1" outputType="constant" outputValue="6"></Case><!-ok--> <!-- Clear TeMIP Value -->
<Case index="2" outputType="constant" outputValue="1"></Case><!-overTemperature--> <!-- Critical TeMIP value-->
<Case index="3" outputType="constant" outputValue="3"></Case><!-MinorWarning--> <!-- Minor TeMIP Value -->
<Case index="4" outputType="constant" outputValue="2"></Case><!-MajorWarning--> <!-- Major TeMIP Value -->
<Case index="5" outputType="constant" outputValue="1"></Case><!-CriticalWarning--> <!-- Critical TeMIP value-->
<DefaultCase outputType="constant"
outputValue="6"></DefaultCase>
</Switch>
</VariableDefinition>
Once all the five severities values obtained, it is necessary to create an External
Computed Variable that performs the complex processing of identifying the highest
critical severity.
102
Example 62
The EXTERNAL Computed Variable definition
<VariableDefinition name="compareExternalCV" type="external"
datatype="Int">
<External className="externalvariable.ComputeChildren">
<Arg inputValueType="integer" inputType="variable"
inputValue="ciscoLS1010ChassisP0StatusConvertion"/>
<Arg inputValueType="integer" inputType="variable"
inputValue="ciscoLS1010ChassisP1StatusConvertion"/>
<Arg inputValueType="integer" inputType="variable"
inputValue="ciscoLS1010ChassisFanStatusConvertion"/>
<Arg inputValueType="integer" inputType="variable"
inputValue="ciscoLS1010Chassis12VoltStatusConvertion"/>
<Arg inputValueType="integer" inputType="variable"
inputValue="ciscoLS1010ChassisTempStatusConvertion"/>
</External>
</VariableDefinition>
The five variables are used as input parameters of the External variable (parameters
of the ’Execute’ method of the class defined in the customization called
’compareExternalCV”).
The following part of code has been developed to find the highest severity:
Example 63
The JAVA code of the External
package externalvariable;
import .com.hp.atni.adapter.extensibility.*;
import java.util.List;
class ComputedChildren extends AbstractATNICommand {
private int m_tab[5];
/**
* Main method
*/
ReturnedParam execute(List<Param> parametersList) {
// Retrieve parameters
retrieveParameters(parametersList);
// Processing to deduce the highest severity
int highSeverity = researchTheHighestSeverity();
return new ReturnedParam(“highSeverity”, highSeverity);
}
/**
* Method that retrieves the input parameters
*/
void retrieveParameters(List<Param> params) {
m_tab[0] = params.get(0).getValueAsInteger();
m_tab[1] = params.get(1).getValueAsInteger();
m_tab[2] = params.get(2).getValueAsInteger();
m_tab[3] = params.get(3).getValueAsInteger();
m_tab[4] = params.get(4).getValueAsInteger();
}
/**
* Method that researches the highest severity
*/
int researchTheHighestSeverity() {
int result = 0;
103
int index = 0;
int max = 5;
boolean found = false;
while ( (!found) && (index < max) {
int otherIndex = 0;
boolean isTheHighest = true;
while ( (isTheHighest) && (otherIndex < max) ) {
if (index == otherIndex) {
// Eliminate this case
} else {
if (isFirstLower(tab[index], tab[otherIndex]) {
// If the first is lower severity than the
second, you do not keep it (exit case)
isTheHighest = false;
}
}
otherIndex++;
}
// Check result
if (isTheHighest) {
result = tab[index];
found = true;
}
index++;
}
}
/**
* Method that defined that one severity is lower than
* an other (TeMIP Severity based).
*/
boolean isFirstLower(int sev1, int sev2) {
boolean isLower = true;
if ( (sev1 != 5) && (sev1 != 0) && (sev2 != 5) && (sev2
!= 0) ) && (sev1 <= sev2) ) {
isLower = false;
} else if (sev2 == 5) {
isLower = false;
} else if ( (sev2 == 0) && (sev1 != 5) ) {
isLower = false;
}
}
Once the customization file updated, once the associated java class compiled and
packaged into a Jar file, the final Runtime kit is generated using the
’tnt_custom_tool’. For additional information of these steps, refer to the chapter
4.5.3.5 How to use the External type variable (External).
4.5.4
Test Case
Once an Event Mapping rule is defined, it is possible to validate this mapping directly
through the customization XML file in case of SNMP Traps by using the TestCase
definitions.
The test case definition enables the user to define a certain number of tests. Each test
case can contain parameters that mock varbind content of a trap. ATNI uses the
/opt/OV/bin/nnmsnmpnotify.ovpl to inject the event into the NNMi. The following
example below demonstrates the structure and usage of an nnmsnmpnotify.ovpl
command:
104
Example 64
The nnmsnmpnotify.ovpl command
history.vbe.cpqcorp.net>
ATNIV6_enduiat1:/opt/OV/bin>nnmsnmpnotify.ovpl
too few arguments, need at least 2
Usage: ./nnmsnmpnotify.ovpl [options] node trap-oid [variable type
value]...
Node can be defaulted with a null ("") string.
trap-oid can be defaulted with a null ("") string.
Use -A option for acknowledged notification (SNMPv2 Inform).
The -t and -r options are valid only when preceded by -A.
Options:
-A
For acknowledged notification
-d
dump ASN.1 packet trace
-v version
protocol version (1 or 2c)
-c community
community string
-p port
remote port
-t timeout
retransmission timeout (1/10th
seconds)
-r retries
maximum retransmission attempts
-T
print the OID in dotted decimal
format.
-a agent_addr
source (agent) for trap/notification
-e enterprise
enterprise oid for trap/notification
Valid variable types: integer integer32 unsigned32 octetstring
octetstringhex
octetstringoctal octetstringascii objectidentifier null ipaddress
counter
counter32 counter64 gauge gauge32 timeticks opaque opaquehex
opaqueoctal
Opaqueascii
Note
The test case feature is applicable ONLY for SNMP traps and is NOT applicable for
the NNMi management incidents.
Based on the format shown above it is possible to create a test case for the trap having
and oid of .1.3.6.1.4.1.11.2.17.1.0.58916865 as follows:
Example 65
Test Case definition
<TestCases>
<TestCase name="1">
<TestCaseDescription>Inject an OV_Node_Down event into
the PMD. Test Case 1</TestCaseDescription>
<VariableValue
oid=".1.3.6.1.4.1.11.2.17.1.0.58916865.0"
type="Integer" value="32"/>
<VariableValue
oid=".1.3.6.1.4.1.11.2.17.1.0.58916865.1"
type="OctetString" value="192.156.0.3"/>
</TestCase>
</TestCases>
The eventOID could be specified for the default event use case. In other cases, it is
not necessary to provide it as the OID of the Event mapping will be used.
105
The VariableValue definition corresponds to each varbind of the SNMP trap being
generated and must be composed of an OID, Type and Value. It is possible to provide
all information that is supported by the nnmsnmpnotify.ovpl tool.
Using the test case definition it is possible to create several test cases for one Event
Mapping by giving each test case a unique name or id.
The NNMi AM application contains a directive that enables the user to execute the
test case. The agent information is not defined in the customization to prevent not
having static data in the customization. This information will be provided by the user
the NNMi AM when calling the test case directive.
The example below shows how to use the test directive use the test case defined in
the Example 65 Test Case definition.
Example 66
Using the test directive
TeMIP> show NNM_CONFIGURATION icon_ns:.icon_nnm_conf NNM_STATION * all attr
NNM_CONFIGURATION icon_ns:.icon_nnm_conf NNM_STATION 16_188_159_168
On director: icon_ns:.temip.icon_director
AT Wed, Oct 4, 2006 10:38:49 AM All Attributes
StationName = 16_188_159_168
NNM Host Name = "icon"
TeMIP Adapter Port = 7509
TeMIP Adapter Security Mode = NONE
TeMIP Adapter Protocol = HTTP
NNM Dynamic Views Port = 80
NNM Dynamic Views Protocol = HTTP
Automatic Resynchronization = False
Advanced Configuration File =
"/var/opt/temip/TNT/stations/16_188_159_168.cfg"
Deployed Customizations = { (
custom_identifier = "NODE_V1",
global_class_name = "NODE",
director_name = ".icon_temip_director",
deployment_timeST = Fri, Sep 29, 2006 05:16:55 PM,
exclusive = False,
default = True ) }
Communication Failure With Station = False
Event Resynchronization Required = True
Topology Resynchronization Required = True
TeMIP> test mcc 0 nnmi_am Station=16_188_159_168, Agent ID =
icon.vbe.cpqcorp.net, Test ID = 1
MCC icon_ns:.temip.icon_director NNMi_AM
On director: icon_ns:.temip.icon_director
AT Fri, Aug 25, 2006 05:22:36 PM
Test successfully loaded.
In the above example, the Station and Agent ID are on the same machine.
4.5.5
How to discard NNMi Incidents that need not be sent to
TeMIP?
It is possible that a certain subset of NNM Incidents need not be sent to TeMIP. This
can be achieved in ATNI by one of the following two methods:
1) Using NNM Incident configuration: Configure the Incident you want to
discard as not “Enabled” in the Incident Configiuration of NNMi GUI.
This will prevent the incident generation in NNMi itself and so
106
incident doesn’t come to temip.Please note that it is mandatory to recreate & re-deploy the customization for this to take effect.
2) Manual update of customization.xml file: In the customization file
belonging to the custom under consideration, you can add a
EventMapping entry with admin attribute having a value of “Discarded”
For example:
<EventMapping admin="Discarded"
eventName="OV_Network_SubMskChg" eventType="Snmp"
eventOID="1.3.6.1.4.1.11.2.17.1.0.40000002">
</EventMapping>
Please note that temip_adapter process must be restarted after the manual
change.
4.6 TeMIP Similarity and Clearance
This section will focus on the ability of the customization to provide TeMIP
Similarity and TeMIP Clearance.
One of the purposes of the customization.xml file is to define the mapping for
specific SNMP Traps.
Defining one Event Mapping leads to generate a corresponding OSI Alarm on TeMIP
side. So generating 2 same SNMP traps leads to send 2 same OSI events (except
Event Time information that is trap one). The first one will be created as Alarm
Object and the second one will be considered as Similar to the first one and created
accordingly (Similar Alarm).
It is possible to provide TeMIP Clearance through the customization.xml file based
on the 2 algorithms implemented in the AHFM level:
 Either alarms are based on same ManagedObject, EventType, ProbableCause (and
possibly Specific Problem)
 Or both alarms are based on Managed Object and Notification ID.
4.6.1
Incident Definition Taking into Consideration TeMIP
Clearance
The following example illustrates how to customize 2 SNMP traps for instances
OV_APA_LinkDown and OV_APA_LinkUp in order that TeMIP Clearance could
take place. Below is an example showing the complete mapping for the
OV_APA_LinkDown trap:
107
Example 67
OV_APA_LinkDown event mapping
<EventMapping
admin="Defined"
eventName="OV_APA_IF_DOWN"
eventType="Snmp"
eventOID="1.3.6.1.4.1.11.2.17.1.0.58983012">
<EventMappingRules>
<ManagedObjectMappingRule>
<EventMappingRule
alarmFieldID="9"
type="ManagedObject"
alarmFieldName="Managed Object"/>
<ExtendedClassInstance>
<GlobalInstanceLookup>
<TrapVariable
label="sourceName"
type="Definition">
<TrapVariableDefinition>
<IndexVB>3</IndexVB>
</TrapVariableDefinition>
</TrapVariable>
</GlobalInstanceLookup>
<ChildClasses value="INTERFACE ${myInterface}">
<Resolver label="myInterface"
inputType="variable" inputValue="vb5"/>
</ChildClasses>
</ExtendedClassInstance>
</ManagedObjectMappingRule>
<TeMIPEnumMappingRule type="MappingTableReference">
<EventMappingRule
alarmFieldID="4"
type="TeMIPEnumeration"
alarmFieldName="Perceived Severity"/>
<MappingTableReference
mappingTable="perceivedSeverity"
inputType="TrapVariable">
<TrapVariable
label="openViewSeverity"
type="Reference"/>
</MappingTableReference>
</TeMIPEnumMappingRule>
<TeMIPEnumMappingRule type="MappingTableReference">
<EventMappingRule
alarmFieldID="1"
type="TeMIPEnumeration
alarmFieldName="Event Type"/>
<MappingTableReference
mappingTable="eventType"
inputType="TrapVariable">
<TrapVariable
label="openViewCategory"
type="Reference"/>
</MappingTableReference>
</TeMIPEnumMappingRule>
<TeMIPEnumMappingRule type="MappingTableReference">
<EventMappingRule
alarmFieldID="3"
type="TeMIPEnumeration"
alarmFieldName="Probable Cause"/>
<MappingTableReference
mappingTable="probableCause"
inputType="TrapVariable">
108
<TrapVariable
label="openViewCategory"
type="Reference"/>
</MappingTableReference>
</TeMIPEnumMappingRule>
<TeMIPEnumMappingRule type="Constant">
<EventMappingRule
alarmFieldID="200"
type="TeMIPEnumeration"
alarmFieldName="Specific Problem"/>
<Constant
label="OV_APA_Link_UpDown"
type="Enum">233</Constant>
</TeMIPEnumMappingRule>
<AdditionalTextMappingRule>
<EventMappingRule
alarmFieldID="7"
type="AdditionalText"
alarmFieldName="Additional Text"/>
<MessageText>OV_Link_Down: $1 down, route
distinguisher = $2, node id = $3, interface id = $4
</MessageText>
</AdditionalTextMappingRule>
</EventMappingRules>
</TestCases>
</EventMapping>
The OV_APA_LinkUp trap mapping definition is exactly the same except that:
 Global event information are different and reference OV_APA_Link_Up event
with suitable OID (1.3.6.1.4.1.11.2.17.1.0.58983002)
 Field Perceived Severity could be defined either depending on NNM one (same as
APA_Link_Down). The NNM Severity normal will be mapped into Clear severity
or could be done ‘hardcoded’ way as follows:
Example 68
Hard coding the Perceived Severity
<MappingTableReference
mappingTable="perceivedSeverity"
inputType="Constant">
<Constant
label="Clearance”
type="Enum">5</Constant>
</MappingTableReference>
The first way is recommended since it could be modify and taken into account in realtime using the NNMi Incident configuration detail.
In that example, the clearance is extended to the usage of the Specific Problem.
Carefully the customization tools do not check any semantic around the Specific
Problem. They are automatically generated for all the traps. Inserting a new id with
same label is not checked by the tools.
4.6.2
Incident Definition Using the Notification Identifier
Another way to define a TeMIP Clearance is to use the Notification Identifier and
Correlation Notification. Using the same previous Event mapping definitions, the
suitable modification will be:
OV_APA_Link_Down:
109
A new EnumRule for the Notification Identifier (AO attribute ID=5) is created and
references a Problem 255:
Example 69
Using the Notification Identifier
<TeMIPEnumMappingRule type="Constant">
<EventMappingRule
alarmFieldID="5"
type="TeMIPEnumeration"
alarmFieldName="Notification Identifier"/>
<Constant
label="OV_APA_Link_UpDown_Problem"
type="Enum">255</Constant>
</TeMIPEnumMappingRule>
OV_APA_Link_Up:
A new EnumRule for the Correlation Notification Identifier (AO attribute ID=6) is
created and references the Problem 255:
Example 70
Correlation Notification Identifier
<TeMIPEnumMappingRule type="Constant">
<EventMappingRule
alarmFieldID="6"
type="TeMIPEnumeration"
alarmFieldName="Correlation Notification
Identifier"/>
<Constant
label="OV_APA_Link_UpDown_Problem"
type="Enum">255</Constant>
</TeMIPEnumMappingRule>
At customization level, the OSI field Correlated Notification Identifier is defined as
an Enumeration (one problem). It will be translated into SETOF (enum) at AM level.
4.7 Specific Use Cases
The Event Mapping rules allow addressing and supporting complex SNMP use cases
such as:
 The Proxy management: capability to retrieve, to be based for the mapping on
another value than the associated source of the event. Unknown entity is a special
processing of the Proxy management.
 The management of the multiple indexes (SNMP table): ability to display suitable
table index even if defined with several columns
4.7.1
How to Support Proxy Management
In some Traps description, the source of the event is not one expected means not the
source associated to the event received but for instance it must be deduced from the
content of a varbind. The flexibility of the Event Mapping allows addressing such
facilities as follows:
Example 71
Using the trap varbind to determine the event source
<ManagedObjectMappingRule>
<EventMappingRule alarmFieldID="9"
type="ManagedObject"
alarmFieldName="Managed Object"/>
<ExtendedClassInstance>
110
<GlobalInstanceLookup>
<TrapVariable label="openViewSourceName"
type="Reference"></TrapVariable>
</GlobalInstanceLookup>
</ExtendedClassInstance>
</ManagedObjectMappingRule>
‘Agent information in varbinds’ use case
According to Trap definition (MIB), the real source of the problem reported is
defined in the varbind in position 3. The event source of the event will be set to the
machine name where the event is caught.
In that case, the usage of the TrapVariableDefinition is required:
Example 72
Using a TrapVariableDefinition to determine the source
<ManagedObjectMappingRule>
<EventMappingRule
alarmFieldID="9"
type="ManagedObject"
alarmFieldName="Managed Object"/>
<ExtendedClassInstance>
<GlobalInstanceLookup>
<TrapVariable
label="sourceName"
type="Definition">
<TrapVariableDefinition>
<IndexVB>3</IndexVB>
</TrapVariableDefinition>
</TrapVariable>
</GlobalInstanceLookup>
</ExtendedClassInstance>
</ManagedObjectMappingRule>
According to Trap definition (MIB), the real source of the problem reported is
defined in the varbind in position 3. It is not a NNM node but the name of a VPN.
Having creating a VPN customization that contains suitable TeMIP model and other
Event/Topology parts, it is possible to define a VpnDown Event Mapping as follows:
111
Example 73
Unknown Entity Case
<ManagedObjectMappingRule>
<EventMappingRule
alarmFieldID="9"
type="ManagedObject"
alarmFieldName="Managed Object"/>
<ExtendedClassInstance>
<GlobalInstanceLookup>
<TrapVariable
label="sourceName"
type="Definition">
<TrapVariableDefinition>
<IndexVB>3</IndexVB>
</TrapVariableDefinition>
</TrapVariable>
</GlobalInstanceLookup>
</ExtendedClassInstance>
</ManagedObjectMappingRule>
The event generated will have a Managed Object equal to VPN ‘red’ where ‘red’ is
the content of the varbind 3. On TeMIP side, such event will be considered as
targeted on ‘Unknown objects’. If the Self-Management of the VPN_AM has its
‘Default Managed Object Management’ attribute set to ‘Advanced’, the entity “VPN
red” will be automatically created and the event will be targeted on it.
Wildcard SnmpOID UseCase
SNMP agents may send variable attribute OIDs if it is from a table or index. The
problem is to map these attributes in custom if only the fix part of the attribute OID is
known. The variable SnmpOID supports the usage of Wildcard. As a result it returns
the required value from the incoming attributes (VariableBindings) of the trap.
Example 73(a)
<TeMIPEnumMappingRule
type="MappingTableReference">
<EventMappingRule
alarmFieldID="4"
type="TeMIPEnumeration"
alarmFieldName="Perceived Severity"/>
<MappingTableReference
mappingTable="TCPConnStatePerceivedSeverity"
inputType="TrapVariable">
<TrapVariable
label="cisco-EPM-Severity"
type="Definition">
<TrapVariableDefinition>
<SnmpOID>.1.3.6.1.4.1.9.9.336.1.5.1.1.3 .*</SnmpOID>
</TrapVariableDefinition>
</TrapVariable>
</MappingTableReference>
</TeMIPEnumMappingRule>
112
4.7.2
How to Support Multiple Indexes Naming
In SNMP, some instances names depend on several SNMP columns. For instance, a
tcpConnection is based on the tcpConnTable that has 4 indexes as follows:
tcpConnTable (local address, local port, remote address, remote port)
whose
root OID is: 1.1.1.1,
local address is 4 octets
local port is 1 octet
remote address is 4 octets
remote port is 1 octet
When an agent sent a status on a tcpConnection, it emits (for instance) the following
trap:
1.1.1.1.10.20.10.10.200.10.20.10.20.300
0
or
tcpConnTable. 10.20.10.10.200.10.20.10.20.300
0
In that case, to deduce the real value of the instance tcpConnection, we need to find in
the trap if a variable exists whose root Oid is ‘tcpConnTable’ and then the rest of the
Oid is identified as ‘instance part’. ATNI customization allows retrieving such kind
of instance using the RowIndex variable as follows:
Example 74
Multiple row indexes
<ManagedObjectMappingRule>
<EventMappingRule
alarmFieldID="9"
type="ManagedObject"
alarmFieldName="Managed Object"/>
<ClassInstance type="TrapVariable" classIdentifier="331"
className="CISCO">
<TrapVariable label="openViewSourceName"
type="Reference"/>
</ClassInstance>
<ClassInstance type="TrapVariable" classIdentifier="31"
className="TCP_CONNECTION">
<TrapVariable
label="tcpConnection"
type="RowIndex">
<TrapVariableRowIndex
label=”tcpConnTable”
index=”1.1.1.1” />
</TrapVariable>
</ClassInstance>
</ManagedObjectMappingRule>
Important Note
The TrapVariable definition (and in particular the RowIndex) is only supported with
the ClassInstance Pairs structure.
4.8 Customization Management Rules
After describing all the content of the Customization file, we approach some specific
rules regarding the customization deployment:
113
Rule 1
Class name and director must be unique on a TeMIP Adapter and it is the only way to
identify a custom.
If a customization is deployed several times from the same director, this is considered
as an update of the custom.
If a customization is deployed from different directors, this corresponds to have
different customs on the Adapter
Rule 2
On load the customization will set the custom Identifier as follow:
Custom identifier = <the name of the class>_<custom id>.
Rule 3
Class and custom id will be unique for one director. If a customization is deployed
with the same class and director but a different customization id it will be refused.
Rule 4
There is one and only one default customization per TeMIP director. Thus the adapter
can have more than default custom.
Rule 5
There is ONE global default customization for the adapter. This will be the first
default customization deployed.
Rule 6
A default customization can not be Exclusive. The reason is that the role of the
default customization is to enable mapping of all incidents that do not have a
specialized mapping defined in any particular customization. The default
customization is also responsible for the creation of a TeMIP Entity that is used to
target alarms where the source of the trap is unknown. Therefore, to ensure that the
default customization functions as designed it can not be exclusive.
Rule 7
Within the context of the Adapter there is the notion of a global default custom.
When no mapping rule can be found to process a Trap, the TeMIP Adapter will take
the global default customization to process the event mapping. There can be more
than one default customization but there is only one global customization which is
usually the first default customization deployed.
Rule 8
There is also the notion that each director has an associated default custom.
The Adapter can initialize with no customizations deployed. The first customization
deployed must be a default customization and in doing so becomes the global default
custom.
Rule 9
It is only possible to undeploy the global default if it is the very last customization
deployed, otherwise it is refused.
114
Rule 10
The global default customization is always the first default customization deployed
even if other default customs are deployed after it.
To change the "global" default customization you must deploy another default
customization and then undeploy the previous global default custom. The Adapter
will take the first default customization deployed to takes it place. A typical scenario
could be when the user wants to change the director machine from A to B. The user
must install the master on machine B and deploy a default customization before
uninstalling machine A.
Rule 11
It is not possible to change the flag of the global customization to false on an update
(deploy with the intention of updating a custom). The update will be refused.
4.8.1
Custom Deployment Use Case Example
Table 12
Custom deployment possible scenarios
#
Class
Id
TeMIP
director
Default
Valid
Result
Custom
Identifier
1
NODE
V1
HAITI
Yes
Yes
Deployed
NODE_V1
2
NODE
V2
HAITI
Yes or No
No
Refused
3
NODE
V1
HAITI
Yes
Yes
Update
to $1
NODE_V1
4
CISCO
V1
HAITI
Yes
Yes
Refused
CISCO_V1
5
CISCO
V1
HAITI
No
Yes
Deployed
CISCO_V1
6
NODE
V1
HORN
Yes
Yes
Deployed
NODE_V1
7
CISCO
V3
HORN
No
Yes
Deployed
CISCO_V3
Explanation
A default already
exist for this TeMIP
director
Since different
director
Note
If a default custom is deployed from TeMIP directors belonging to different name
spaces, the deployment does not fail.
4.9 Migrating to ATNI V6
4.9.1
How to Migrate from ATNI V540
For exact migration steps, refer to ATNI V6 Migration Guide.
4.9.2
How to Migrate from IST Customization
ATNI does not provide any tool allowing generating automatically the ATNI
customization XML file from the IST configuration files. Although, hereunder are
some recommendations and notes relevant to this specific processing:
115
 The ‘rich’ IST grammar is not fully supported by ATNI in particular the
conditional expression, the basic regular expression, the possibility to define
external functions
 All constant values could be directly mapped into ATNI Constant type
 All OID , wildcarded OID or position variable could be directly mapped into
ATNI TrapVariableDefinition type
 Some specific SWITCH cases could be mapped in ATNI using Mapping table (for
simple transformation)
 IST Managed Object rule is only Class based. This means that cfg file does not
specify any instance value. As it is linked to the SNMP MIB, the source of the
trap is automatically computed by IST_AM. For ATNI, we need to specify the
suitable Class and Instance for each TeMIP entity level.
4.10 Recommendation
ATNI offers some built-in capabilities such as managing all NNMi Management
Incidents . Be careful to do not modify all in a customization else ‘strange’ and
unexpected behavior may occur. The following list the main recommendation around
the customization file:
 Do not modify the ‘heart’ of the Default model means the set of TeMIP classes
such as INTERFACE, CHASSIS. A lot of NNMi incidents are mapped on such
TeMIP classes. If changed you need to redefine them to adapt the targeting.
 Do not change all the time the naming of the objects. Firstly, after such
modification you need to use the ‘Topology Resynchronization’ operation. Then
this operation may take a lot of time depending of the number of objects to
process.
 Define the Events rule depending on NNMi as soon as possible (severity mainly).
This allows you to ‘tune’ them (TeMIP correlation) in real-time since each NNMi
incident configuration modification is taken into account in real time.
 Do not overload ‘generic’ traps since the Default customization already manages
them whatever the real Topology objects.
 Be careful about the possible topology objects overlapping. The trouble shooting
of such scenarios may be very complex.
 Define a deployment plan of the IP topology domains to manage. Define which
customization will be deployed to manage which part of the network. Use TeMIP
distribution to load-balance the management of IP devices in case of very large IP
domain.
4.11 Limitations
ATNI offers a powerful, open and flexible toolkit to define how the SNMP traps are
mapped into the TeMIP world and which IP nodes are managed. Although, some
limitations exist:
 There is no possibility to define a ‘free OSI field’ whose result is a String. Only
Integer OSI field is possible (mainly for SpecificProblem and Notification
Identifier cases)
 There is no automatic propagation when attributes of the Topology changes. The
update of Topology may be taken into account in doing a resynchronization with
the ‘reapplyCustomization operation.
116
 For the deletion of node instance in TeMIP alone and to keep the node populated
in NNMi, you need to set all node objects in ‘To-Be-Deleted’ status and doing a
‘Simple Topology Resynchronization’.
 Some limitations exist concerning the Computed Variables usage and they are
largely described in the section 4.5.3 depending on the type of variable. Although,
one important rule to keep in mind is the order of the variables definitions:
“A variable can be based on other variable only if it is already defined”.
117
Chapter 5
Generating a TNT Runtime Kit
Once a customization file is created and possibly customized according to the users
SNMP equipment and incident mapping requirements, all necessary resources need to
be packaged into TNT runtime kit specific this equipment or service. The purpose of
this chapter is to present which tools to use in order to generate a runtime kit and to
describe their usage.
5.1 The Customization Package Tool
The following section will describe the tnt_custom_tool that is provided with the
TNT customization toolkit.
This tool will ensure that the runtime kit is valid by taking the responsibility in
validating the input files when building the kit. The validation check list that is
applied to each input resource such as the customization XML file and existence of
the topology filter file in the directory from which tnt_custom_tool is called.
Figure 19
118
Generating a Runtime kit using the tnt_custom_tool
Note
The Designer using this tool must be on the NNMi station.
5.1.1
The tnt_custom_tool Usage
SYNOPSIS
tnt_custom_tool [-h] [-d] [-t incidentConfigFileName]
[-e externalLibrary] -c customFileName
Table 13
The tnt_custom_tool usage
Options
Description
-v
Verbose mode to enable the traces facility.
-h
Displays help usage.
-d
Performs a diagnostic only. No runtime kit is generated.
-t incidentConfigFileName
Specifies the NNMi Incident Config file. As soon as an
Incident Config file has been used to define the provided
customization, then this same file must be provided here
so that those definitions are not lost.
If -t flag is given, variables NNMUSER and
NNMPASSWORD must be set in the environment.
5.1.2
-e externalLibrary
Specifies the external library file (JAR file containing the
external class used in the customization file).
-c customFileName
Specifies the customization XML file.
The tnt_custom_tool Input
On the command line the following inputs are mandatory:
 A valid customization XML file.
 Optional, NNMi Topology Filters file.
Important Note
The filter definition must follow the syntax and grammar described in the NNMi
Node Bean Service WSDL
 Optionally, an incident Configuration xml file.
 Optionally, an external library if the customization file refers to external
functions.
5.1.3
The Runtime Kit Validation Process
The purpose of this tool is to validate the customization files before generating the
runtime kit. There are mainly two different types of verification performed on the
customization XML file:
 Syntax checking (against the DTD)
 Rules checking
119
5.1.3.1
Syntax Checking
The input customization file is validated against the Customization DTD. This file is
stored under /opt/OV/TNT/customToolkit/include/Customization.dtd.
If the syntax of the input file is not matching the DTD, an error message is displayed
and the tool exits.
5.1.3.2
Rules Checking
The purpose of the rule checking is to validate and ensure the integrity of the
customization. If the rule checking fails for any one of the reasons outlined below, it
can prevent the deployment of an invalid customization. This ensures that an invalid
or non conforming customization will not be loaded and used by the NNMi AM or
the TeMIP Adapter.
Below is a list of the rules that are verified by the tool:
Customization
 The Identifier attribute must have a length less than 11 characters.
 The classIdentifier must be a valid integer greater than 0.
 The isExclusive attribute must not be at True if the isDefault attribute is at True
Revisions
 The date format must conform to YYYY-MM-DDThh:mm:ss.
AM Definition
 The Identifier must be a valid integer and must have length less than 11
characters..
 When the AM name is “nnmi_am” the Identifier must be equal to "1315"
MIB Modules
For each Module name defined in the MIB modules, the rootSnmpOID must be a
valid SNMP OID value. The oid should start with a dot “.”. The sequence of numbers
should also be separated by a dot “.”. The oid should match the following regular
expression "^([.]?)[0-9]+([.][0-9]+)*(([.][*])?)$").
NNM Predefined Variables
 The dataType element must contain a valid dataType.
 The label element must be unique and should be associated with a dataType.
Entity Model
 The class depth should be no greater than 10 levels.
 Within the same class level, the class identifier must be a unique integer greater
than 0.
 The snmpOID attribute must be a valid SNMP OID.
Deployment
 Each RetentionPolicy attribute must be a valid integer.
 For any DefaultEntities elements, each different Managing director indicated by
the ocManagingDirector attribute can only contain less than two different
120
Operation Contexts (the ocName attribute) each beginning with the same 9
characters. This check is not case sensitive.
 For any DefaultEntities elements, a given Operation Context (the ocName and
ocManagingDirector attributes) must always be associated to the same Domain
(the collectionDomainName and domainManagingDirector attributes). This check
is not case sensitive.
Mapping Table
 Each mapping table should have a proper tableName.
 Each tableName in mapping should be associated with a valid osiField attribute
value.
 One of the mapping rows should be defined as ‘isDefaultMapping’.
 Each key value should be associated with a unique mappingValue in the table
defined.
Event Mapping
 One and only one default mapping rule must exist. This indicated isDefault
attribute of the EventMapping element.
 The default mapping rule must have its associated OID finishing with a wildcard.
For example “.*”.
 The eventOID attribute must be a valid SNMP OID.
 The alarmFieldID attribute must be a valid integer.
 The provided Managed Object must be defined in the entity model. The managed
object also supports targeting the trap to the NNM_CONFIGURATION or the
NNM_STATION.
 The SnmpOID element must contain a valid SNMP OID.
 The Constant element must have a valid corresponding value
(Int|Float|RelativeTime|AbsTime|String|Enum).
 All mappingTable attributes of MappingTableReference must be a table defined
in MappingTables element.
 All classes defined as instanceless in the Entity Model must also be defined as
instanceless in the mapping rule using the class.
 The Managed Object OSI field can be based on ExtendedClassInstance structures
that allow defining child classes as String form. This children part must be
coherent with the Entity Model (Child Class names and instance or instanceless
specification). Of course, new ExtendedClassInstance structure needs to be
respected.
Auto Population
 A default naming rule must exist. This indicated by the isDefault attribute of the
naming rule.
 The referenced <NNMFilter> .xml file must exist in the runtime kit.
 For any EntityNamingRule element, each different Managing director (the
ocManagingDirector attribute), there must be two or less different Operation
Context names defined (the ocName attribute) each beginning with the same 9
characters. This check is not case sensitive.
 For any EntityNamingRule element, a given Operation Context (the ocName and
ocManagingDirector attributes) must always be associated to the same Domain
121
(the collectionDomainName and domainManagingDirector attributes). This check
is not case sensitive.
Computed Variables
 Any variable identified with its name could be defined only once either in Global
Computed Variable section or in a trap definition (Local Computed Variable
section). Two same variables could be defined in two separate traps definitions.
 Any variable used by any OSI field must be defined.
 Any variable definition must be coherent with the XML element it uses: ‘switch’
type with ‘Switch’ element, ‘ifCondition’ type with ‘IfCondition’ element,
‘regexp’ with ‘Regexp’ element and ‘external’ with ‘External’ element.
 The 2 variable types REGEXP (regular expression) and SWITCH requires Input
information that could be provided either in the variable definition or when using
the variable within the OSI field definition. It is mandatory to provide such
information in one or other part or both.
 This Input information (composed of an ‘inputType’ and an ‘inputValue’) need to
reference non-null information.
 For the SWITCH variable, each index (string value) of case needs to be unique.
 Any External function associated to an External Variable must be defined in the
external library (JAVA class file) associated to the customization file and
provided as input of the tool.
 Any variable can be used in other one from the moment it has been defined
previously.
5.1.4
The tnt_custom_tool Output
Once the input files are successfully validated, the tool will then generate a runtime
kit named:
<class name>_<customization identifier>.jar
In the case of the above naming the <class name> and the <customization identifier>
information is retrieved from the customization XML file.
5.1.4.1
Generation of the incidentConfig.xml
This section describes how the output incidentConfig.xml file that is packaged within
the runtime kit is generated. This inicdentConfig.xml will be append merged with the
existing incidentConfig.xml that resides on the machine where the tnt_custom_tool is
executed. The incident configuration file will be packaged with the runtime jar as
“TNTNNMiIncidentConf.xml” only if specified as input parameter.
Generation of incidentConfig.xml from NNMi Station
/opt/OV/bin/nnmconfigexport.ovpl -u <nnmi username> -p
<nnmi password> -c incident -f <location to store the
incidentConfig.xml file>
Updation of incidentConfig.xml from a MIB file
When a MIB module is used to generate the customization xml file, the incident
config of the NNMi station has to be updated with the new traps available in this MIB
module. Only after this updation, the traps are mapped according to the event
mapping rule in customization xml file.
122
/opt/OV/bin/nnmincidentcfg.ovpl -loadTraps <mib_file> disableAllTraps true|false -u <NNMiadminUsername> -p
<NNMiadminPassword >
Action Definitions
In the case that a incidentConfig.xml file is supplied as an input argument to the
tnt_custom_tool tool the action definitions are copied from the input file into the
generated TNTNNMiIncidentConf.xml file. Otherwise there is no
TNTNNMiIncidentConf.xml in input directory if no incidentConfig.xml file has been
given as input argument.
Important Note
The TNTNNMiIncidentConf.xml incident configuration is not automatically
uploaded to the NNMi Station when deployed. User should take care to compare and
update the same based on the existing Incident configuration available and MIBS
loaded in NNMi.
5.2 Generating a Runtime Kit Example
The following section will describe step by step how to generate a TNT runtime kit
using the TNT customization toolkit by using a specific example.
The objective of this example will be to create a runtime kit for a CISCO-STACKMIB module.
5.2.1
Preparing the Topology Filter File
The topology filter file is generated when we use tnt_custom_gen for the generation
of customization xml file. By default the generated topology filter file contains the
rule used by customization that will define the criteria for node selection of all nodes.
Example 75
Topology filter example
<arg0 xmlns:ns4="http://filter.sdk.nms.ov.hp.com/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-in
stance" xsi:type="ns4:expression">
<subFilters xsi:type="ns4:condition">
<name>name</name>
<operator>LIKE</operator>
<value>%%</value>
</subFilters>
</arg0>
5.2.2
Building the Runtime Kit
With the generated customization xml file, you can build the runtime kit using the
mandatory input resources:
 The customization XML file
The next step is from within the directory where these customization file and
topology filter file mentioned in customization xml file are located to execute the
tnt_custom_tool as follows:
Example 76
The tnt_custom_tool usage
/opt/OV/TNT/customToolkit/bin/tnt_custom_tool -c
123
CISCO_temip.xml
The generated kit is a CISCO_V1.jar. This kit is now ready to be deployed. To view
the contents of the kit is possible to extract the content of the kit with the command as
follows:
Example 77
jar
Generated kit extraction
-xvf CISCO_V1.jar
The kit should contain the following files and directories as listed below:
Example 78
0
69
974
29912
0
Wed
Wed
Wed
Wed
Wed
Generated kit content
Jul
Jul
Jul
Jul
Jul
06
06
06
06
06
15:20:34
15:20:34
15:20:24
15:20:24
15:20:24
CEST
CEST
CEST
CEST
CEST
2005
2005
2005
2005
2005
META-INF/
META-INF/MANIFEST.MF
input/CISCO_V1Filters.xml
output/customization.xml
external/
The output directory contains the customization.xml file, which is the validated
version of the input customization file CISCO_temip.xml.
124
Chapter 6
Deploying a TNT Runtime Kit
The purpose of this chapter is to present all the necessary information that will enable
the user to deploy their runtime kit successfully. This chapter will describe the
deployment tools used and their usage.
6.1 Introduction
Any administrator that intends to deploy, remove, or update a runtime kit must use
the deployment tools provided by ATNI. These tools should be executed on the
TeMIP director where the NNMi AM resides. The tools need additional
administration information such as the TeMIP director and a list of one or more
NNMi stations. The diagram below presents an overview of the deployment process:
Figure 20
The deployment process overview [ Venkt]
For more details on supported TeMIP platforms, see ATNI V6 Release Notes for more
information(
The deployment tools can be used
125
 To deploy a new ATNI runtime kit. This is done when installing and
configuring a new NNMi AM master or clone application. It will also load a
corresponding configuration to a local or remote TeMIP Adapter as appropriate.
 To update an already deployed runtime kit. This is usually used when the user
is required to change or tune an existing customization implemented by an NNMi
master or clone application. It will also update the corresponding configuration
used by a local or remote TeMIP Adapter
 To remove a currently deployed runtime kit. This is used to delete an existing
NNMi AM master or clone application. It also removes the corresponding
configuration loaded by the local or remote TeMIP Adapter
The three actions outlined above can be performed respectively by using the
following tools:
 tnt_rt_create_nnm_am_application.sh
 tnt_nnm_am_load_custom.sh
 tnt_rt_delete_nnm_am_application.sh
6.2 Deploying a New TNT Runtime Kit
As the TNT runtime kit is an Operating System independent package, the same
runtime kit package can be deployed to several different UNIX /Linux platforms. The
NNMi AM application is responsible for executing the deployment on the specific
Operating System.
 Extract: the runtime kit package
 Install: the kit OS dependant is installed on TeMIP
 Configure: the NNM AM configure the TeMIP Director
 Deploy: the customization to the required NNM Stations
 Launch: the Launch Generation Tool (launch definition file for TeMIP Client)
 Launch: the Launch Publication Tool (optional)
A new deployment of the runtime kit is performed by the
tnt_rt_create_nnm_am_application.sh script located under the
/usr/opt/temip/TNT/toolkit/bin directory.
Important Note
After the installation of any master and/or clone, do not restart the TeMIP Adapter or
the NNMi. After the custom deployment, the TeMIP adapter takes a while to create
CA columns for all the NNMi nodes.
When the deployment is done, both the TeMIP Adapter and NNMi should be up and
running.
6.2.1
The tnt_rt_create_nnm_am_application.sh Script
This script is used to create, install and configure automatically a new NNM AM
master or clone application and to load the corresponding configuration to the
associated TeMIP Adapter.
 The script first checks the prerequisites, and then it parses and checks all
parameters.
126
 It expands the RunTime kit, parses the required information by calling the
tnt_rt_kit_expansion.sh script (Application name, application ID, default
customization indicator), and exits in case of error.
 If it is a default customization (Master AM installation), then the Application
Name and ID are forced respectively to “NNMi_AM” and 1315.
 If it is not a default customization (clone AM installation), then check that a
Master AM has been previously installed on this TeMIP director.
 It creates the OS kit that will contain the new AM distribution with the RunTime
kit, calling the tnt_nnm_am_os_kit_creation.sh script. It exits if it fails.
 It installs the generated OS kit on the TeMIP platform, calling the
tnt_nnm_am_os_kit_installation.sh script. It exits if it fails.
 It activates the generated OS kit, calling the tnt_nnm_am_os_kit_activation.sh
script. It exits if it fails.
 It calls the tnt_nnm_am_load_custom.sh script in order to configure the AM and
the TeMIP Adapter to be ready to use the new custom.
6.2.2
The tnt_rt_create_nnm_am_application Prerequisites
The following prerequisites are required in order to execute the
tnt_rt_create_nnm_am_application.sh script successfully:






6.2.3
Only the root user can run this script
TeMIP should be started.
The TeMIP Adapter located on the NNMi station where the customization will
be deployed is also started
The NNMi AM master should already be installed and running before starting
the deployment process for NNMi AM clones.
The configuration of the NNM Station should be done before starting the
deployment process or during deployment in specifying the parameter ‘-stations’
A RunTime kit customization must have been generated by the ATNI
Customization toolkit, and the corresponding CustomID.jar file must be
available on the TeMIP platform.
The tnt_rt_create_nnm_am_application.sh Usage
The table below outlines the usage of the tnt_rt_create_nnm_am_application.sh
script:
Table 14
Parameter Name
The tnt_rt_create_nnm_am_application.sh usage
Possible Values
-help or –h
-customId
theCustomId
Mandatory
Description
NO
Display the tool usage only
YES
The customId is the
customization identifier
(runtime kit identifier). The
runtime kit file for this
customization is named
theCustomId.jar.
The complete name of the
input jar file is also supported :
-custom_id <theCustomId>.jar
-temip_dir
theTeMIPDir
YES
The root directory of the
TeMIP installation. For
127
Parameter Name
Possible Values
Mandatory
Description
example /usr/opt/TeMIP-V60I
-use_all_def_
TRUE|FALSE
NO
Indicates if the NNM AM Self
Management attribute “Use all
defined stations” must be set to
true or false, i.e. indicating if
the NNM AM should deploy
the customization to all
defined NNM_STATION or
only a subset of selected
stations.
stations
Default value: True
-stations
STATION1
STATION2 ....
STATIONn
NO
List of the stations to use
(hostname with domain). The
stations are separated by a
space character.
Deault value:
- adapter_port
Port number
NO

If \"use_all_def_stations\" is
True, it is intended to create
new stations provided the
stations are not available
already.

If \"use_all_def_stations\" is
False, it is intended to deploy
the custom. The station may
be either “New” or “Existing”
The Adpater Port number to
use at the STATION instance
creation.
Default value: 7509
-dft_entity
DefaultEntity
NO
Default entity to use for
targeting events.
If this parameter is given then
DefaultOC and DefaultDomain
are mandatory.
By default, the DefaultEntity
name is extracted from the
runtime kit, but it can be
overridden here.
If this argument is provided,
then –dft_oc and –dft_domain
become mandatory, and the
corresponding information in
the runtime kit is ignored
(default entity, OC, domain,
and associated managing
directors).
-dft_oc
128
DefaultOC
NO
Default operation context to
use for the collection of events
on the default entity.
Parameter Name
Possible Values
Mandatory
Description
If this parameter is given then
DefaultEntity and
DefaultDomain are mandatory.
By default, the DefaultOC
name is extracted from the
runtime kit, but it can be
overridden here.
If this argument is provided,
then –dft_entity and –
dft_domain become
mandatory, and the
corresponding information in
the runtime kit is ignored
(default entity, OC, domain,
and associated managing
directors).
-dft_domain
DefaultDomain
NO
Default domain associated to
the default operation context
used for the collection of
events on the default entity.
If this parameter is given then
DefaultOC and DefaultEntity
are mandatory.
By default, the DefaultDomain
name is extracted from the
runtime kit, but it can be
overridden here.
If this argument is provided,
then –dft_oc and –dft_entity
become mandatory, and the
corresponding information in
the runtime kit is ignored
(default entity, oc, domain, and
associated managing
directors).
-dft_oc_
OCManaging
managing_
Director
NO
Managing director of the
default OC.
By default this value is
provided in the RunTime kit,
but if the options –dft_entity, dft_oc, -dft_domain are used,
the runtime kit information is
ignored and the default
become the Local director,
except if it is overridden by
this option.
Director
-dft_domain_
Domain
managing_
Managing
Director
Director
NO
Managing director of the
default domain.
By default this value is
provided in the runtime kit, but
129
Parameter Name
Possible Values
Mandatory
Description
if the options –dft_entity, dft_oc, -dft_domain are used,
the runtime kit information is
ignored and the default
become the Local director,
except if it is overridden by
this option.
-correlation_entity
Correlation
NO
Name of the entity on which
the changed/clear correlation
events will be targeted:
Entity
<CLASS_NAME>
<CORR_ENTITY>_<CLASS
_NAME>
Where <CLASS_NAME> is
the global class name of the
NNM AM.
Default value:
tnt_3gpp_correlation.
-working_dir
WorkingDir
NO
The directory where the
runtime kit is located.
Default value: Local directory
-target_dir
targetDir
NO
The directory where the
expansion is done.
Default value:
<working_dir>/rt_kit_<theCus
tomId>
WARNING: The target
directory with all its content is
going to be erased!
-os_kit_dir
osKitDir
NO
The directory where the OS kit
is created.
Default value:
<working_dir>/os_kit_customI
d
6.2.4
A tnt_rt_create_nnm_am_application Example
In the example below, the command will install a new NNMi AM master that will
manage the NNMi_NODE global class. The script will deploy the configuration to
two NNM stations that are iat35.domain.com and iat45.domain.net.
Example 79
tnt_rt_create_nnm_am_application.sh script
/usr/opt/temip/TNT/toolkit/bin/tnt_rt_create_nnm_am_application.sh
-custom_id NNMi_NODE_V1 -working_dir /tmp/CTK_Test/ -temip_dir
/usr/opt/TeMIP-V60I -stations iat35.domain.com iat45.domain.net
The script will create a specific Unknown Entity based on the value provide in
customization.xml
130
The script will also create a specific correlation Entity base on the entity provided in
option -correlation_entity or default entity “NNMi_NODE
tnt_3gpp_correlation_NNMi_NODE” that will be used to targeting all correlation
3GPP notifications.
6.2.5
The tnt_rt_create_nnm_am_application Output
On successful completion of the tnt_rt_create_nnm_am_application script, the
following output is obtained.
In case of a successful installation of a new runtime kit, a new NNMi AM should be
running on the TeMIP platform and the TeMIP Adapters running on the
NNM_STATION should be configured with the new runtime kit.
It is possible to verify using the temip_inventory command that within the selected
TeMIP release the new kit is installed and configured. The example below
demonstrates how this can be achieved:
Example 80
Result of using the temip_inventory command
TNT.TNTcisco_stackV600I configured
HP OpenView TeMIP NNMi
Toolkit - cisco_stack (release V600I level 01 rev A)
It is also possible to confirm that the NNMi AM is running using the temip_show
command as shown below:
Example 81
Result of the temip_show command
temip
2222
AM
/usr/opt/temip/mmexe/temip_tnt_cisco_stack
Finally, it is possible to verify on the TeMIP command line that the customization is
properly deployed to the selected stations. Using the manage console to enter TeMIP
mode the command is as follows:
Example 82
List of deployed customizations
TeMIP> show nnm_conf * nnm_station 15_154_72_221 Deployed
Customizations
NNM_CONFIGURATION Stress_ns:.tfriat17_nnm_conf NNM_STATION
15_154_72_221
On director: Stress_ns:.temip.tfriat17_director
AT Wed Oct 7 15:57:47 2009 Status
Deployed Customizations = {
custom_identifier
global_class_name
director_name
".temip.tfriat17_director",
deployment_timeST
2009,
exclusive
default
(
= "CISCO_STACK_V1",
= "CISCO_STACK",
=
= Wed Sep 30 14:05:07
=
=
(
custom_identifier =
global_class_name =
director_name =
".temip.tfriat17_director",
deployment_timeST =
2009,
exclusive =
default =
True,
False ),
"NNMi_NODE_V1",
"NNMi_NODE",
Thu Sep 17 11:12:50
False,
True ) }
131
The Operation Context associated with the customization is automatically resumed
and the alarm collection is started directly. As shown above, the application is
designed to start automatically.
6.3 Updating an Already Deployed TNT
Runtime Kit
When updating an existing customization, two important main steps happen during
the configuration phase that need to be considered:


If the MSL data model is changed and the previous customization is removed
and a new customization Operating System kit is created and installed.
While if it is only a minor change to the runtime kit (for example, changing a trap
definition) then only the deployCustom directive is called. This means that only
the TeMIP Adapter configuration is updated.
An update can be performed by using the tnt_nnm_am_load_custom.sh script, which
is located under the /usr/opt/temip/TNT/toolkit/bin directory.
If the script is executed, it peforms the following:
 Extracts the runtime kit to use the resources stored within
 Compares these resources with the already deployed runtime kit. If the MSL data
model has changed the existing customization is removed and the new
customization is installed and configured.
 Configures the NNM Station.
 Deploys the customization to the TeMIP Adapter or adapters.
 Launches the Launch Generation Tool.
 Launches the Launch Publication Tool (optional).
6.3.1
The tnt_nnm_am_load_custom.sh Script
The purpose of the tnt_nnm_am_load_custom.sh script is to update an already
deployed customization. The list below gives a more detailed view of what happens
when the script is executed:
1. The script first checks the prerequisites (TeMIP must be running), and then it
parses and checks all parameters. If something is wrong, it displays an error and the
usage (see Errors management below).
2. If this tool is called during an installation (-install TRUE, i.e. this script is called
from the tnt_rt_create_nnm_am_application.sh script), the steps 3 to 10 are skipped
in order to optimize the processing.
3. It parses and extracts the required information from the runtime kit, calling the
tnt_rt_kit_expansion.sh script.
4. It checks that a previous customization was installed and backups it temporarily in
the /usr/opt/temip/TNT/theAppliName/previous_custom directory.
5. It prepares the customization by expanding the runtime JAR file in the
/usr/opt/temip/TNT/theAppliName directory.
6. If the application name is equal to the NNMi AM master it checks that the
customization has the default flag set to true otherwise it will exit with an error.
7. It verifies that the customization is valid on this director. In particular it checks
that the probable cause values stored in the customization exist in os_types.ms on this
132
TeMIP director. If this check fails the tool is not stopped but a warning message is
displayed with the list of unknown probable cause values.
8. It checks if the MSL has been changed in the customization. If it has changed it
uninstalls the current customization and launches the installation.
9. It determines if runtime kit file has changed. It checks if the customization.xml
file,incident configuration file or if the Topology filter file have been modified. If
this is the case it will call the deployCustom directive.
10. It creates and registers the Correlation Target Entity instance and sets the
corresponding NNMi AM Self Management attribute.
11. The role of the NNMi AM master (default customization), is to create and register
the default unknown entity, its Operation Context and domain for it and the member
in this domain.
12. It also creates the Operating Context and domain for any unknown TeMIP entities
in NNMi if other domain and Operation Contexts are given in the customization. This
information is provided in the customization and can be overridden by providing
input arguments of the configuration tool manually.
13. It sets the “Default Managed Object” and “Domain for Unknown Entities”
attributes of the NNMi AM Self Management.
14. It sets the “custom identifier” attribute of the NNMi AM Self Management to the
custom identifier provided.
15. It sets the “Global Class Name” attribute of the NNMi AM Self Management.
16. It configures the station list using the use_all_def_stations parameter and the
stations provided. It sets the “Use all defined stations” attribute the NNMi AM Self
Management and add the stations using the AddStation directive if needed (it calls the
tnt_configure_station.sh sub-script).
17. It calls the launch generation tool (it calls the tnt_launch_file_generation.sh sub
script).
18. Calls the deployCustom directive (it calls the tnt_adapter_deploy_custom.sh subscript).
19. Finally it will remove the previous customization.
6.3.2
The tnt_nnm_am_load_custom Prerequisites
In order to execute the tnt_nnm_am_load_custom.sh script successfully, the following
prerequisites are required:
 TeMIP, NNMi, and Adapter must be started and running.
 The NNM station or stations must be configured before starting the deployment
process.
 An NNMi AM master or clone application corresponding to the updated runtime
kit must be installed.
Note
To run this tool, a user does not require require root privileges. The access control
will be delegated TeMIP permissions for calling the deployCustom directive. This can
be managed by ACLOC permissions. This will allow hot deployments of customs
without root privileges.
Also, a user requires root priviliges for installation only if the MSL has changed the
kit.
133
6.3.3
The tnt_nnm_am_load_custom Usage
The following table outlines the tnt_nnm_am_load_custom.sh parameters and usage:
Table 15
Parameter Name
The tnt_nnm_am_load_custom.sh usage
Possible
Values
-help or –h
-customId
theCustomId
Mandatory
Description
NO
Display the tool usage only.
YES
The customId is the customization identifier
(runtime kit identifier). The runtime kit file
for this customization is named
theCustomId.jar.
The complete name of the input jar file is
also supported : -custom_id
<theCustomId>.jar
-appli_id
theAppliID
NO
The application identifier of the Master/clone
NNM AM application i.e. the MSL ID of the
TeMIP Application.
-appli_name
theAppliName
NO
The application name of the Master/clone
NNM_AM application to setup. The custom
runtime kit file has been placed in
/usr/opt/temip/TNT/theAppliName directory
during the installation.
-use_all_def_
stations
true/false
NO
Indicates if the attribute “Use all defined
stations” must be set to true or false. I.e. if
the AM should deploy the customization to
all defined NNM_STATION or only a subset
of selected stations.
-stations
Station1 …
stationN
NO
If the “Use all defined stations” attribute is
set to false, the user needs to provide a list of
NNM_STATIONs to use. It is a sub-list of
NNM_STATIONs defined using the NNM
AM master.
-dft_entity
DefaultEntity
NO
Default entity to use for targeting events.
If this parameter is given then DefaultOC
and DefaultDomain are mandatory.
By default, the DefaultEntity name is
extracted from the runtime kit, but it can be
overridden here.
If this argument is provided, then –dft_oc
and –dft_domain become mandatory, and
the corresponding information in the runtime
kit is ignored (default entity, OC, domain,
and associated managing directors)
-dft_oc
DefaultOC
NO
Default operation context to use for the
collection of events on the default entity
If this parameter is given then DefaultEntity
and DefaultDomain are mandatory.
By default, the DefaultOC name is extracted
from the runtime kit, but it can be overridden
134
Parameter Name
Possible
Values
Mandatory
Description
here.
If this argument is provided, then –dft_entity
and –dft_domain become mandatory, and the
corresponding information in the runtime kit
is ignored (default entity, OC, domain, and
associated managing directors).
-dft_domain
Default
Domain
NO
Default domain associated to the default
operation context used for the collection of
events on the default entity
If this parameter is given then DefaultOC
and DefaultEntity are mandatory.
By default, the DefaultDomain name is
extracted from the runtime kit, but it can be
overridden here.
If this argument is provided, then –dft_oc
and –dft_entity become mandatory, and the
corresponding information in the runtime kit
is ignored (default entity, OC, domain, and
associated managing directors)
-dft_oc_
managing_
director
OCManaging
Director
NO
-dft_domain_
managing_
director
Domain
Managing
Director
NO
-correlation_
entity
Correlation
Entity
NO
Managing director of the default OC
By default this value is provided in the
runtime kit, but if the options –dft_entity, dft_oc, -dft_domain are used, the runtime
kit information is ignored and the default
become the Local director, except if it is
overridden by this option.
Managing director of the default domain
By default this value is provided in the
runtime kit, but if the options –dft_entity, dft_oc, -dft_domain are used, the runtime
kit information is ignored and the default
become the Local director, except if it is
overridden by this option.
Name of the entity on which the
changed/clear correlation events will be
targeted:
<CLASS_NAME>
<CORR_ENTITY>_<CLASS_NAME>
where <CLASS_NAME> is the global class
name of the AM
Default value: tnt_3gpp_correlation
-install
true/false
NO
Hidden parameter (not displayed in usage). It
is used for optimization (True: install mode,
False: update mode).
Default value is FALSE.
-custom_flat_file
flatFile
NO
Hidden parameter(not displayed in usage) to
provide the already extracted information
135
Parameter Name
Possible
Values
Mandatory
Description
from the runtime kit into a flat file
6.3.4
A tnt_nnm_am_load_custom Example
In the example below the script updates the existing CustomId NODE_V1 that is
being managed by the NNMi_AM master application that has ID 1315.
Example 83
The tnt_nnm_am_load_custom.sh script
> tnt_nnm_am_load_custom.sh
-custom_id NNMi NODE_V1
-appli_name NNMi_AM -appli_id 1315
-stations honda2.domain.net rp02.domain.net
-correlation_entity .france.ATNI_correlation
It takes on input the TNT runtime kit NNMi_NODE_V1.jar. If needed it will create
the two NNM stations honda2.domain.net and rp02.domain.net and also configure the
AM to use these two defined NNM stations (NNM_STATION).
Also, it will create a specific Correlation Entity (NNMi_NODE
.france.ATNI_correlation_NNMi_NODE) that is used for targeting all correlation
3GPP notifications.
6.3.5
The tnt_nnm_am_load_custom Output
If the script executes successfully, the resulting output will be as follows:
 In the specific case of the NNM AM Master the default entity, domain and
operation context are created with the name given as arguments if specified.
Otherwise it uses the values specified in the customization XML file.
 The customization is populated with operation contexts and domains defined in
the customization XML file.
 The NNM_STATION instances corresponding to the –stations argument are
created.
 The NNMi AM self-management attributes “Custom Identifier”, “Global Class
Name”, “Target Correlation Entity”, “Default Managed Object”, “Domain for
Unknown Entities”, “Use all Configured Stations” and “Selected Stations” are set.
 The customization is deployed to all the defined stations.
To create an Operation Context, Domains, and the Default Entity, the
tnt_nnm_am_load_custom tool parses the naming rules of the customization XML
file
For each domain, the following FCL PM commands should be executed:
 Register the domain with option operation = plan (and with the managing director
if specified).
 Create the domain.
 Populate the domain with the Target Correlation Entity.
For each Operation Context, the following FCL PM commands should be executed:
 Register the operation context with option operation = plan (and with the
managing director if specified).
136
 Create the Operation context with the associated domain.
 Register the operation context with option operation = complete.
For the Default Entity, the following FCL PM commands should be executed:
 Register the entity with option operation = plan.
 Create the entity with NNM OBJECT ID , NNM UUID , NNM Name , NNM IP
Address and STATION NAME attributes set to “not_used”.
 Register the entity with option operation = complete.
 Populate the associated domain with the entity.
6.3.6
Tips when updating Event Mapping only (tuning)
When tuning a customization, in particular when updating event mapping for specific
traps (additional, managed object,…), it is not necessary to reload the customization
each time a modification is done.
 If the modification is performed in the NNMi Incident Configuration only
through GUI or tool. If incident configuration file is be manually
updated.and exported..
 If the modification is done in the customization file, it is recommended to just
update the customization file located under suitable location
(/var/opt/OV/TNT/adapter/conf/customs/<class>.<director> and to stop/restart the TeMIP Adapter.
When all the tuning is terminated, a new ATNI Runtime kit can be regenerated based
on the modified final customization file.
6.4 Removing a Deployed TNT Runtime Kit
The removal of a deployed TNT runtime kit is performed by using the
tnt_rt_delete_nnm_am_application.sh script which is located under the
/usr/opt/temip/TNT/toolkit/bin directory.
The purpose of this script is to remove a deployed customization and it does so in the
following steps:
 Firstly, it undeploys the customization from the TeMIP Adapter. It removes the
configuration corresponding to the customization form the local or remote TeMIP
Adapter.
 It then uninstalls the runtime kit. That is it removes the associated NNMi AM
from the TeMIP director.
6.4.1
The tnt_rt_delete_nnm_am_application.sh Script
This script is used to remove a deployed customization. The script first checks the
prerequisites and then parses and checks all parameters.
 It undeploys the customization from the given application name.
 It deletes the Operating System kit corresponding to the given NNMi AM
application name on TeMIP director.
 It deletes any classes created and updates the TeMIP dictionary. However, it does
not delete the class instances. It is recommended deleting the class instances
before executing the tool.
137
6.4.2
The tnt_rt_delete_nnm_am_application Prerequisites
In order to execute the tnt_rt_delete_nnm_am_application.sh script successfully, the
following prerequisites are required:
 Only the root user can run this script
 TeMIP, NNMi and Adapter must be started.
 The NNM station or stations must be configured before starting the deployment
process.
 The given NNMi AM application name should be installed on TeMIP
6.4.3
The tnt_rt_delete_nnm_am_application Usage
The table below outlines the usage and parameters for the
tnt_rt_delete_nnm_am_application.sh script:
Table 16
Parameter
Name
Possible
Values
The tnt_rt_delete_nnm_am_application.sh usage
Mandatory
Description
-help or –h
NO
Display the tool usage only
-is_default_
custom
YES/NO
Indicates if it is the default customization. In
such a case, the NNMi AM master is deleted
(appli_name parameter is not required),
otherwise, the application name provided is used.
The –is_default_custom and –appli_name
arguments are mutually exclusive.
-appli_name
theAppli
Name
YES/NO
The application name of the clone application to
uninstall.
This parameter is not required when the option –
is_default_custom is used, because in such a
case the application name is forced to
NNMi_AM (the master AM).
The–is_default_custom and –appli_name
arguments are mutually exclusive.
-temip_dir
6.4.4
TEMIP_DIR
YES
The directory where TeMIP is installed.
An tnt_rt_delete_nnm_am_application Example
Example 84
The tnt_rt_delete_nnm_am_application.sh script
> tnt_rt_delete_nnm_am_application.sh
-is_default_custom
-temip_dir /usr/opt/TeMIP-V60I
In the example above the tnt_rt_delete_nnm_am_application.sh script com will
remove the NNMi AM master from the TeMIP installed in /usr/opt/TeMIP-V601.
6.4.5
The tnt_rt_delete_nnm_am_application Output
The corresponding customizations on all Selected NNM_STATIONS are undeployed,
and the NNMi AM master/clone is removed.
138
Chapter 7
Configuring the NNM Views within
TeMIP Client
By default, after installation of the TeMIP NNMi Advanced Integration Plug-in (TNT
plug-in), there is no customization installed, it means there is no menu allowing to
start NNMi Views(Launch URL’s).
The following section describes the two ways to define these NNMi Views menu into
TeMIP Client.
7.1 Manual Configuration
The user defines manually the launch via the Add/Edit Launch dialog box. The user
can enter the definition of the launch and associate it to the correct classes using the
Classes Control Panel.
Follow these simple steps to integrate new menu item to integrate NNMi Views into
TeMIP Client:
1. Select in the main menu “Add/Edit…” and create a new launch
2. Enter the Launch Definition setting. The TNT plug-in has special plug-in callback
dedicated to launch NNMi View.
See 7.4 Interaction with TeMIP NNMi Advanced Integration Plug-in for more details
about the TNT Plug-in Callbacks available for NNMi View.
Table 17
NNM view with PathView on a Map Viewer
Launch Definition
Value
Launch Name
Launch Path View…
Command
%TEMIP_CLIENT_HOME%\TNT.tpi
Plug-in
MapViewer
Arguments
@LaunchContextualNNMView pathView
<TARGET_ENTITIES>
Enter the user Interface setting.
139
Table 18
Pop-up only a MB3 menu for the customized classes
User Interface
Value
Show in menu
Checked
Show in popup menu
Checked
Show in popup menu only for attached
classes
Checked
1. Associate your new launch to the customized class. Go to the main menu
“Tools - Option… – Tab General”
2. Click to “Classes Control Panel”
3. Select your customized class on the left class tree, and select the right tab
called “Launch Class”
4. Check the Launch in the “Launch Application Association” Combo box
5. Click on “Associate” button to save your configuration. Your launch is now
associated to the class. Click OK to return to the TeMIP Client application.
After such configuration, you can open a Map and select two TeMIP Entities
(customized class). The TeMIP Client displays a new entry in MB3 menu called
“Launch Path View…”. If you select this action, a NNMi View is launched.
7.2 Automatic Configuration
To ease the customization of the launch in the TeMIP Client, a tool named Launch
Generation Tool is available on the Unix platform.
7.2.1
The tnt_launch_generation.sh Script
This script is in charge of generating a TeMIP Client launch Definition File (.conf)
ready-to-use by the TeMIP Client for the list of customized classes defined in the
runtime kits. This tool will be called during the deployment of a customization.
It can be manually launched, or automatically called during the deployment of a
runtime kit (via the tnt_nnm_am_launch_custom.sh script). Started from a TeMIP
launch template file, it generates for the specified customization (global class) a
customized launch definition file ready to be used by the TeMIP Client. This file is
used by the TeMIP Client to have access to the NNMi Views for customized classes.
An administrator can customize the Launch Generation Tool template (ex: remove
some NNMi views) used as input for the Launch Generation Tool and generate a
launch definition file for the specified customization.
140
Figure 21
7.2.1.1
Overview of the Launch Generation Tool
Prerequisite
Only root user can run this script and TeMIP must be started.
A runtime kit customization must have been generated by the ATNI Custom Toolkit,
and the corresponding customization.xml file must be available on the TeMIP
platform.
7.2.1.2
Usage
tnt_launch_generation.sh –customXML <customXML>
[-template <template>]
[-stations <station1 station2 …. stationx>]
[-output_dir <output_dir>]
[-unix | -unix_format]
[-noContextual] [-onlyContextual] [-override]
[-help | h]
Table 19
The tnt_launch_generation.sh usage
Parameter Name
Possible Values
Mandatory
Description
-customXML
<customXML>
Customization.xml
Yes
The <customXML> is the customization
file path (with an absolute or relative
path).
This file must exist.
This parameter is mandatory.
141
Parameter Name
Possible Values
Mandatory
Description
-template
<template>
/usr/users/john/
MyTemplate.conf
No
The <template> is the file name (with an
absolute or relative path) of the template
that the user wants to use. This file must
exist.
By default: <template> file is
/usr/opt/temip/TNT/toolkit/LGT_Template
/
TeMIPTNT_Template_SetupLaunch.conf
-stations
<station1 station2
…. stationx>
13_2_5_89
No
The <station1 …stationx> is the list of
stations to use.
The given station instances must be
defined on the local TeMIP platform.
Default value: all TeMIP station instances
defined on the local NNM_CONF.
-outputDir
<outputDir>
/tmp
No
The <outputDir> directory where the
generated customized launch definition
file will be stored. The output directory
given as input must exist and have written
and execution permission set for the user.
The generated customized launch
definition file is named
“TeMIPTNT_<customId>_<director>_S
etupLaunch.conf”
If the generated customized launch
definition file already exists in the
<outputDir> and if the option -override
has not been given as parameter, an error
will be logged and the script will be
stopped.
Default value: Local directory
-unix
unix
No
Generates the launch definition file with
ASCII unix format. The format of
Windows and Unix text files differs
slightly. In Windows, lines end with both
the line feed and carriage return ASCII
characters, but Unix uses only a line feed.
By default, the launch definition is
generated with windows format.
-noContextual
noContextual
No
Enables to remove contextual views
launch blocks from launch definition file
generated (launch block which contains
the keyword
“@LaunchContextualNNMView” will be
not taken in account).
By default, the launch definition file is
generated with contextual views.
-onlyContextual
142
onlycontextual
No
Enables to keep only contextual views
launch blocks from the configuration file
template.
Parameter Name
Possible Values
Mandatory
Description
-override
Override
No
Enables to override the generated
customized launch definition file if
already exist.
-help or –h
help
No
Provides a Help Usage
7.2.1.3
Examples
Example 85
tnt_launch_generation.sh script help
> tnt_launch_generation.sh –help
This command displays script usage guidelines.
Example 86
Generate a launch definition file
> tnt_launch_generation.sh -customXML ./CISCOV1.xml -stations
55_2_24_101 55_2_24_102
In this example we are generating a launch definition file for the director itea01.This
command generates the file using the provided list of stations. The output file will be
stored in local directory with the following name
TeMIPTNT CISCOV1_itea01_SetupLaunch.conf and will be in a windows format.
Example 87
Generate a launch definition file without contextual views
> tnt_launch_generation.sh
-customXML ./CISCOV1.xml
-stations 55_2_24_101 55_2_24_102
–noContextual
-outputDir /tmp
–override
The command above generates and overrides a launch definition file without
contextual views using the local NNM_CONFIGURATION instance
itea01_nnm_conf along with the provided list of stations. The output file will be
/tmp/TeMIPTNT_CISCOV1_itea01_SetupLaunch.conf and will be in a Windows
format.
7.2.1.4
Output
In case of a successful generation, a customized launch definition file is generated in
the specified output directory (local by default) and is ready to be distributed and
used by TeMIP Client application.
The launch definition file generated is named
TeMIPTNT_<customId>_<director>_SetupLaunch.conf”
where:
<director> is the instance name of the NNM_CONF on the TeMIP director without
the ‘nnm_conf’ suffix.
<customId> is the customization identifier read from the customization.xml file.
143
7.2.2
7.2.2.1
The Launch Generation Tool Process
Default Launch Generation Template
The default Launch Generation Template enables to generate launches for the
following NNM Views:
Network Node Manager Consle: The NNMi Console View entry point. This is the
console view for the operator to do different operation and view all the details in
NNMi. A new menu item “Console (Network Overview)” is added to the launch
main menu. It allows to access to a sub-menu where a list of station/director can
be selected.
Contextual View which requires a selection (TeMIP Entity) to start the NNMi View.
This selection is used to identify the context to display (resolution of entity
between NNMi Node and TeMIP Entity). The Contextual Views are:
1. Neighbor View
2. Path View
A new menu item “NNMi IP Views” is added to the launch main menu. It allows
launching the specified contextual NNM View. If the selected TeMIP class is not
associated to this view, then the entry will be disabled. The contextual menu MB3 is
also updated with the menu entry if the class selected is associated to the view.
Not Contextual Views that do not require such argument. The Not Contextual Views
are:
1. Station View
2. Internet View
3. Network View
4. Node View
5. VLAN View
6. OSPF View
7. Overlapping Address Domain View
A new main menu item “NNMi IP Views” is added to the launch main menu. It allows
launching the specified NNMi View.
144
Figure 22
7.2.2.2
The launch menu integration of the NNM views
Launch Generation Rules
The Launch Generation Tool uses the list of attached stations to the TeMIP Director.
During deployment, the user can specify a list of NNM stations (attached to the local
TeMIP Director) to deploy the customization (all stations will be read from the
TeMIP Director if this parameter is not specified), the Launch Generation Tool will
instantiate the Launch Definition file for all the selected NNM Stations. Each View
defined in the Launch Definition Template will be duplicated and special keywords
resolved dynamically for all stations the user wants to deploy on.
In the following example, the Launch Definition Template has been customized and
only three NNM Views will be used in the TeMIP Client (Node View, Internet View
and Path View).
The administrator deploys the customization (customized TeMIP Class C1) to all
NNM stations associated to the TeMIP Director (Station A and Station B).
The Launch Generation Tool loops on all selected stations (A and B) and instantiates
each launch block (i.e. view) defined in the template in the generated Launch
Definition files. All these launches are only available on the customized class (C1).
145
Figure 23
The launch generation rules example
If the station is defined on several TeMIP Directors (ex: station A available on
Director D1 and Director D2), then the view will be defined several times displaying
the name of the director used.
Example:
IP Views
Internet View
55_3_24_109 (on director
.hadi_nnm_conf)
55_3_24_109 (on director
.playa_nnm_conf)
55_3_24_109 (on director
.hugo_nnm_conf)
The station named 55_3_24_109 is defined on 3 TeMIP Directors (hadi, playa, and
hugo).
Contextual Views (pathView, neighborView) do not require the station parameter but
depend on the user selection and the list of TeMIP Entities. The TeMIP NNMi
Advanced Integration plug-in (TNT plug-in) is in charge of resolving the
station/director to use. If the user deploys on several directors, the launch generation
tool will duplicate these views for all the directors. It is recommended for an
administrator to use toggle option to specify if the Launch Generation Tool will
generate all views, only contextual views, or only not contextual views. This option
can be used to tune the way the launch generation tool generates the launch definition
file for TeMIP Client and optimizes the menu organization.
For example, the administrator can choose to have one global file with only
contextual views and generate only not contextual views during deployment of new
customization.
146
Check all the available generation options for the Launch Generation Tool in the
section 7.2.1.2Usage
7.2.2.3
Customize the Launch Definition Template
By default a Launch Definition Template is provided after installation, but the
administrator can customize it according to his need (add new NNMi Views, remove
unused NNMi Views, customize the look and feel, etc…).
The administrator can do the same kind of customization than using the TeMIP Client
Add/Edit Launch Dialog Box.
The syntax is based on the TeMIP Client Configuration Files syntax. Template file
contains several “launch” blocks which have to be compliant with the launched
configuration file format. So, an administrator can easily use the TeMIP Client to
define his launch and cuts/pastes the generated text to this template. Check carefully
the syntax (numbered block, etc…).
Refer to the Appendix G – Launch Applications configuration File Format for more
details.
Each block defines a launch view which can be contextual or not contextual. Not
Contextual Views require the NNM station/ TeMIP Director. Contextual Views need
the selection (TeMIP Entities).
There are also several dynamic keywords that will be solved during the launch
generation process.
Table 20
Launch Definition Template - Supported Keywords
Keyword
Description
Example
<customId>
Customization Identifier (read from the
customization.xml file)
NNMi_NODE_V1
<station_name>
Name of the NNM Station used for deployment
10_188_16_7
<station_hostname>
Hostname of the NNM Station used for
deployment.
By Default, this keyword is used in the label of
the menu displayed in TeMIP Client
Hadi.vbe.cpqcorp.net
<director>
NNM_CONFIGURATION class instance on a
temip director.
By Default, this keyword is used in the label of
the menu displayed in TeMIP Client
.hadi_nnm_conf
<local_director>
Short name of the TeMIP Director hostname
Hadi
<entityClass>
Will be substitute by the list of customized Class
OID with the following syntax:
NBENTITYCLASS = <nb of classes>
ENTITYCLASS0 = <class OID>
ENTITYCLASS1 = <class OID>
----------
NBENTITYCLASS = 2
ENTITYCLASS0 = 2010
ENTITYCLASS1=
2010.201
---------ENTITYCLASS<nb-1> = <class OID>
147
Example:
ARGUMENTS = @LaunchNNMView homeBase <station_name>
<director>
SUBMENU = IP Dynamic Views\nNode View
NAME = <station_hostname> (on director <director>)
7.2.3
Distribution of the Generated Launch Definition File
The generated launch definition file needs to be deployed to each TeMIP Client in the
following directory:
%TEMIP_CLIENT_HOME%\ TeMIPClient_SystemLaunch.
An administrator can:
 Use its own tool to distribute the file to TeMIP Client PC.
 Use TeMIP Resource Server product to have an automatic update of TeMIP
Client PC.
7.2.3.1
Manual Distribution
An administrator can distribute the file using copy/paste, email, FTP, or any tool able
to share this file to multiple PCs. At the end, the Launch Definition Files generated
for this customization have to be installed on the PC in the directory
%TEMIP_CLIENT_HOME%\ TeMIPClient_SystemLaunch.
7.2.3.2
Automatic Update using TeMIP Resource Server
The Resource Server provides a way to centralize and dispatch all kinds of resource
files (including the Launch Definition file). It is a set of software components that
allows resources files (graphical or configuration files) to be stored on a central server
and a transparent sharing between clients.
The update of the Resource Server can be done by an administrator using a Resource
Server GUI or a publication script (command line).
Each TeMIP Client PC will need a synchronization windows service installed in
charge of updating the configuration files (new or modified) of the TeMIP Client
(Synchronization command). This service can be started daily, weekly, etc... to have
an automatic way to have up to date TeMIP Client configuration.
148
Figure 24
Publishing the Launch definition file using the TeMIP resource
server
Note
By default, a type exists in the resource server configuration file to synchronize the
TeMIP Client system configuration launches. See the Resource Server Setting in the
Resource_Server.conf file:
[KEYWORD CONFIG_TEMIPCLIENT_SYSTEM_LAUNCH]
Client File Extension = .conf
Client Path =
%TEMIP_CLIENT_HOME%\TeMIPClient_SystemLaunch
Please refer to the TeMIP Client Overview and the Resource Server Installation and
Configuration Guide for more details.
7.2.4
The tnt_launch_publication.sh Script
This script allows the user to add a publish operation of the TeMIP Resource Server
to redistribute the launch definition file automatically to all the TeMIP Clients
(installed with the synchronization Service).
It is called during the deployment of a customization after the Launch Generation
Tool.
Important
By default, no commands are defined to manage the publication. It is in charge
of an administrator to customize this publication script to fit his need.
149
7.2.4.1
Prerequisite
Only root user can run this script.
TeMIP must be started.
A Launch Definition File must have been generated by the Launch Generation Tool
and must be available on the TeMIP platform.
7.2.4.2
Usage
tnt_launch_publication.sh
[-h] [-help]
-launch_file <Launch Definition File>
Table 21
7.2.4.3
The tnt_launch_publication.sh usage
Parameter
Name
Possible Values
Mandatory
Description
-launch_file
Generated Launch
Definition file
(.conf)
Yes
Provides Launch
Definition File
(generated by the
Launch Generation
tool)
-help or -h
help
No
Provides a Help Usage
Examples
Example 88
Generate a launch definition file without contextual views
> tnt_launch_publication.sh
-launch_file TeMIPTNT_NODE_V1_horn_SetupLaunch.conf
This command displays and publishes the Launch Definition File named
TeMIPTNT_NODE_V1_horn_SetupLaunch.conf using the publication command
defined in the tnt_launch_publication script (resource server, FTP, copy, …).
7.2.4.4
Output
In case of a successful publication, the Launch Definition File is stored under the
Resource Server and available for update. All TeMIP Clients that will synchronize
with the Resource Server will get the new launch definition file.
7.2.4.5
Using the temip_resource_publish Tool
In this chapter, some examples are shown using the TeMIP Resource Server and the
temip_resource_publish command.
Example 89
Publish all the resources
> tnt temip_resource_publish –all
This is used to publish all the resources from all resource types specified into the
resource_server.conf file.
150
Example 90
Publish all the configuration resources
> temip_resource_publish -all -t "CONF"
The above example shows how to publish all Configuration files resources.
Example 91
Publish all the configuration resources with name beginning
with ‘TeMIPTNT_’
> temip_resource_publish -all -t "CONF" -r "TeMIPTNT_*"
This example shows how to publish all configuration resources with name beginning
with "TeMIPTNT_". To use a wildcard, you must specify the -all option.
Example 92
Publish the configuration resource file
> temip temip_resource_publish -t "CONF" –r
"TeMIPTNT_NNM_NODE_V1_hadi_SetupLaunch"
This last example explains how to publish the configuration resource file called
TeMIPTNT_NNM_NODE_V1_hadi_SetupLaunch.conf.
For more explanation about publication with TeMIP Resource Server, please read the
Resource Server Installation and configuration Guide.
7.3 How to Add a new NNMi View in TeMIP
Client?
Let’s take the case of adding HSRP View.
This is how the NNMi Views menu looks like by default.
Note that HSRP View is missing from the “NNMi IP Views” menu list.
151
Steps to add a new NNMi view:
1) Define the view correctly in %TEMIP_CLIENT_HOME%\TNTSystem.conf file.
[ Dynamic Views ]
Number of Views = 14
View0 = neighborView
View1 = internetView
View2 = stationView
View3 = networkView
View4 = vlanView
View5 = ospfView
View6 = hsrpView
View7 = dupipView
View8 = probDiagView
View9 = pathView
View10 = nodeView
View11 = segmentView
View12 = interfaceView
View13 = containerView
[ End Dynamic Views ]
[ hsrpView ]
ExternalWebBrowser = False
OpenInNew = False
URL=<NNM_PROTOCOL>://<NNM_HOST>:<NNM_PORT>/topology/hsrpView?extraInfo=DESKTOPID:<DESKTOP ID>;
HomePage = %TEMIP_CLIENT_HOME%\WebBrowser\pagestart.html
ErrorPage = %TEMIP_CLIENT_HOME%\WebBrowser\pageerror.html
StatusBar = False
AddressBar= False
ToolBar = False
AutoLoad = False
Title = IP Dynamic View
[ End hsrpView ]
2) Add the following to
%TEMIP_CLIENT_HOME%\TeMIPClient_SystemLaunch\TeMIPTNT_<customId>_<direct
or>_SetupLaunch.conf file.
[ LAUNCH10 ]
SHOW_IN_MB3MENU = False
ARGUMENTS = @LaunchNNMView hsrpView 16_17_10_136 steakld4_nnm_conf
SYNO_TAG = TEDISPLAY
SMALLBMP =
MULTIINSTANCE = True
MB3_ONLY_FOR_ENTITY = False
LARGEBMP =
SUBMENU = IP Dynamic Views\nBrandNewHSRP View
INITDIR =
COMMAND = %TEMIP_CLIENT_HOME%\TNT.tpi
WAIT = False
INVERT = False
SHOW_AS_ICON = False
SHOW_IN_MENU = True
NBENTITYCLASS = 0
NBATTRIBUT = 0
HIDE_VALUE = False
SHOW_IN_TOOLBAR = False
NAME = steakld4 (on director steakld4_nnm_conf)
NBPLUGIN = 0
AUTOSTART = False
SHOW = 1
MB3_ALSO_SUB_ENTITIES = False
SMALLICON =
152
SYNO_USE = False
[ End LAUNCH10 ]
Note: LAUNCH10 is used because LAUNCH0 to LAUNCH9 were already defined
in the file. In general if LAUNCH<n> is already present, the new entry will be
LAUNCH<n+1>
3) In the same file
(%TEMIP_CLIENT_HOME%\TeMIPClient_SystemLaunch\TeMIPTNT_NNM_NODE_V1_
steakld4_SetupLaunch.conf) increment the “NumberLaunch” under [ General ] by one.
BEFORE
[ General ]
NumberLaunch = 10
Version = 5.3
[ End General ]
AFTER
[ General ]
NumberLaunch = 11
Version = 5.3
[ End General ]
4) Restart the TeMIP Client.
After the above mentioned changes, we can see that the new view (BrandNewHSRP
View) has been added to the “NNMi IP Views” in TeMIP Client.
Refer to Section 7.2.3 for updating the template and automatically distributing the
changes using the TeMIP Resource Server.
153
7.4 Interaction with TeMIP NNMi Advanced
Integration Plug-in
The TNT plug-in is responsible for the interaction between NNM and TeMIP as
follows.
 TeMIP/NNMi Name resolution (both side).
 Manage NNMi Server configuration.
 Compute final URL to use to access to NNMi View.
 Drive the Web Browser Plug-in, launch External Default Web Browser.
 Dispatch operation from NNMi View to others Plug-in (Map Viewer, Alarm
Handling, Management View).
This plug-in manages a system configuration file (TNTSystem.conf) containing NNM
Views information and web browser customization to use.
Figure 25
Overview of the TNT Plug-in integration
NNM Views integration is based on the launch mechanism of TeMIP Client and uses
a powerful launch feature of the TNT plug-in called plug-in callbacks. This plug-in
provides several plug-in callbacks dedicated to display NNMi Views. These plug-in
callbacks can be easily customized by administrator to refine the menu look and feel
and select the list of available NNMi Views.
The TNT Plug-in is also responsible for the look and feel of the Web Window
containing the NNMi View. The TNT plug-in drives the display of these pages
requesting services from the TeMIP Web Browser Plug-in.
This Web Browser Plug-in is able to display any web pages in an internal window
(inside the TeMIP Client) or using the external default web browser (Internet
Explorer, Firefox, Netscape, Opera, etc …)
For more details about the Web Browser plug-in, please read the TeMIP Client
Overview and the TeMIP Client Integrating Application into TeMIP Desktop
documentations.
154
7.4.1
TNT Plug-in Callbacks
7.4.1.1
Not Contextual View
If you want to start a Not Contextual View, you can use the following TNT plug-in
callback:
@LaunchNNMView view_name station_name [tnt_server_name]
Where:
 view_name: the name of the NNMi View to be launched. This parameter is
mandatory.
 station_name: the name of the NNM station (i.e. myStation if its full station
name is ‘NNM_CONFIGURATION hadi_nnm_conf NNM_STATION
myStation’). This parameter is mandatory.
 tnt_server_name: the name of the TNT server associated to the NNM station (i.e
hadi_nnmm_conf if its full station name is ‘NNM_CONFIGURATION
hadi_nnm_conf NNM_STATION myStation’). This parameter is optional. If not
present the first station found with station_name will be used.
Table 22
Examples of Non Contextual View callback
NNMi Views / Menu
Plug-in callback Syntax
Node Manager
Home Base
@LaunchNNMView homebase station_name [tnt_server_name]
NNMi IP Views
Node View
@LaunchNNMView nodeView station_name [tnt_server_name]
NNMi IP Views
Network View
@LaunchNNMView networkView station_name [tnt_server_name]
NNMi IP Views
Station View
@LaunchNNMView stationView station_name [tnt_server_name]
NNMi IP Views
Internet View
@LaunchNNMView internetView station_name [tnt_server_name]
NNMi IP Views
VLAN View
@LaunchNNMView vlanView station_name [tnt_server_name]
NNMi IP Views
Dupip View
@LaunchNNMView dupipView station_name [tnt_server_name]
NNMi IP Views
OSPF View
7.4.1.2
Ex: @LaunchNNMView homeBase 16_188_157_228 hadi_nnm_conf
Ex: @LaunchNNMView nodeView 16_188_157_228 hadi_nnm_conf
Ex: @LaunchNNMView networkView 16_188_157_228 hadi_nnm_conf
Ex: @LaunchNNMView stationView 16_188_157_228 hadi_nnm_conf
Ex: @LaunchNNMView internetView 16_188_157_228 hadi_nnm_conf
Ex: @LaunchNNMView vlanView 16_188_157_228 hadi_nnm_conf
Ex: @LaunchNNMView dupipView 16_188_157_228 hadi_nnm_conf
@LaunchNNMView ospfView station_name [tnt_server_name]
Ex: @LaunchNNMView ospfView 16_188_157_228 hadi_nnm_conf
Contextual View
If you want to start a Contextual View, you can use the following TNT plug-in
callback:
@LaunchContextualNNMView view_name <SELECTED_ENTITIES>
Where:
 view_name: the name of the NNM View to be launched. This parameter is
mandatory.
155
 <SELECTED_ENTITIES>: the selected entities. This parameter is mandatory.
Please refer to the Integrating Application into TeMIP Desktop – TNT Plug-in to have
the available plug-in callbacks.
Table 23
Examples of the Contextual View callback
NNMi Views / Menu
Plug-in callback Syntax
NNMi IP Views 
Neighbor View
@LaunchContextualNNMView neighborView <SELECTED_ENTITIES>
NNMi IP Views 
Path View
@LaunchContextualNNMView pathView <TARGET_ENTITIES>
7.4.2
Look and Feel of NNMi Views
TNT Plug-in uses its system configuration file to define the look and feel to use for
displaying the NNMi Views. The System Configuration file is
%TEMIP_CLIENT_HOME%\TNTSystem.conf. It contains a list of supported NNMi
Views and for each view, the definition dedicated to drive the Web Browser Plug-in
(toolbar available or not, MB3 menu available or not, status bar visible or not,
editable address bar available or not, etc…).
Fore more detail on the TNT system configuration file, please refer to the Appendix
H.
Example 93
TNT system configuration file example
View1 = internetView
View2 = stationView
View3 = networkView
View4 = vlanView
View5 = ospfView
View6 = hsrpView
View7 = dupipView
View8 = probDiagView
View9 = pathView
View10 = nodeView
View11 = segmentView
View12 = interfaceView
View13 = containerView
View14 = nnmConsole
View15 = routersView
View16 = switchesView
View17 = nodesView
View18 = allIncidentsView
View19 = layer2NeighborView
View20 = layer3NeighborView
View21 = pathAnalyticView
View22 = nodeForm
View23 = nnmStatus
[ End Dynamic Views ]
[ neighborView ]
ExternalWebBrowser = False
OpenInNew = False
URL=<NNM_PROTOCOL>://<NNM_HOST>:<NNM_PORT>/
topology/neighborView?extraInfo=DESKTOPID:<DESKTOP_ID>;Station:
<NNM_STATION>;IPAddress:<NNM_IP_ADDRESS>&node=<NNM_NODE1>&maxHops=2&showEndNodes=false&viewInBrowser=true
HomePage = %TEMIP_CLIENT_HOME%\WebBrowser\pagestart.html
ErrorPage = %TEMIP_CLIENT_HOME%\WebBrowser\pageerror.html
156
StatusBar = False
AddressBar= False
Note
To add a new NNMi View, you can increment the list of supported views and add a
new launch block with the Web Browser definition to use for this new view. The
name of the view must exactly match the name of the view requested for the plug-in
callbacks (case sensitive).
157
Chapter 8
Troubleshooting
This chapter lists the common errors that can be encountered when using the Custom
Toolkit tools, and the appropriate corrective action to apply. These errors are
displayed at run-time in the window where the tools have been executed.
8.1 TNT Customization Toolkit
8.1.1
The tnt_custom_gen Tool
8.1.1.1
Verbose Mode
The tnt_custom_gen tool has a verbose mode to display details about the processing
steps, checking, etc …This mode is dedicated to troubleshoot issues. To activate
verbose mode, please refer to 3.1.1(tnt_custom_gen section).
8.1.1.2
Error Messages
Table 24
Error
Code
ERR1
Error messages for the tnt_custom_gen tool
Error Message
Reason
Corrective action
Error (ERR1) - MIB Module ... is not
loaded or noa a valid module
into/var/opt/OV/share/conf/snmpmib.bi
n repository or needs to be unloaded
and reloaded
The specified MIB module is not
loaded into the NNMi repository,
or needs to be re-loaded.
Load or re-load the
specified MIB module using
the tool
/opt/OV/bin/xnmloadmib
and use the correct MIB
Module name as input
If you want to specify AM
information, be sure to
supply the five arguments:
Error (ERR2) - Missing following
information in arguments:
-a AMName
-r AMId
ERR2
-c className
Some input information about the
AM definition is missing.
-i classId
-o classOID
Error (ERR3) - . identifier is not a
positive integer
158
-a AMName
-r AMId
-i classId
ERR3
-c className
-o classOID
The integer supplied as input
argument is not a valid integer
greater than 0.
Enter a valid integer for AM
or Global Class Identifier
arguments.
Error
Code
Error Message
Reason
Corrective action
ERR4
Error (ERR4) - Global Class OID is not
a valid OID
The specified OID is not correct.
Enter a valid OID composed
only of digits and points.
For example 1.12.35.4.
ERR5
Error (ERR5) - Cannot locate input file:
... (No such file or directory)
The specified Incident
Configuration file or Entity Model
file does not exist or is not present
at the specified location.
If the input file is not
present in the current
directory, be sure to specify
the full path.
ERR7
Error (ERR7) – Error parsing Entity
Model: xxx
A problem “xxx” has occurred
while parsing the Entity Model
Follow the message
instructions “xxx”
ERR8
Error (ERR8) – Error while writing the
customization : xxx
A problem “xxx” has occurred
while writing the customization
ERR9
Error (ERR9) – Missing input
information (EntityModel file or
Incidnent Configuration file or MIB
modules information)
The EntityModel, Incident
Configuration or MIB modules
information is missing
ERR11
Error (ERR11) - Entity Model check:
SNMP OID xxx is used several times
The SNMP OID xxx is used
several times
ERR13
Error (ERR13) - Entity Model check:
Class name xxx is used several times
(parent: yyy, level: zzz)
Class name xxx is used several
times (parent: yyy, level: zzz)
Check and correct the class
name xxx
ERR14
Error (ERR14) - Entity Model check:
Class with snmpOID xxx has empty
class name (parent: yyy, level: zzz)
Class with snmpOID xxx has
empty class name (parent: yyy,
level: zzz)
Enter a class name for
snmpOID xxx
ERR15
Error (ERR15) - Entity Model check:
Class xxx snmpOID is not valid
(parent: yyy, level: zzz)
Class xxx snmpOID is not valid
(parent: yyy, level: zzz)
Enter a valid class name for
snmpOID
ERR16
Error (ERR16) - Entity Model check:
Class xxx ID yyy is not valid (parent:
zzz, level:
The ID yyy is not a valid ID for
class XXX under parent ZZZ as it
may be negative or not a numeric
value
Enter a valid ID for class
xxx
ERR17
Error (ERR17) - Entity Model check:
The ID yyy of the class xxx has already
been used by another class
The ID yyy used for class xxx has
already been used for another
class
Enter a unique ID for class
xxx
ERR18
Error (ERR18) - xxx
Error in the Incident configuration
or the Incident string: xxx
Follow the message
instructions “xxx”
ERR19
Error (ERR19) – xxx
Error xxx
Follow the message
instructions “xxx”
159
8.1.2
8.1.2.1
The tnt_custom_tool Tool
Verbose Mode
The tnt_custom_tool tool has a verbose mode to display details about processing
steps, checking, etc…This mode is dedicated to troubleshot issues. To activate
verbose mode, please refer to 5.1.1 (tnt_custom_tool section).
8.1.2.2
Error Messages
Table 25
Error messages for the tnt_custom_tool tool
Error
Code
Error Message
Reason
Corrective action
ERR1
Error (ERR1) – Diagnose:
… is not conform to the
…/Customization.dtd
DTD
The customization file given as
input is not conform to the model
Read the previous error message
(coming from the unmarshal
function)
ERR2
Error (ERR2) – Diagnose:
classIdentifier is not a
positive integer
The “classIdentifier” attribute of
the “Customization” tag in the
customization file must be a
positive integer
Check and correct the value of the
“classIdentifier” attribute in the
customization
ERR3
Error (ERR3) – Diagnose:
Customization identifier
length is > 19
The “identifier” attribute length
of the “Customization” tag in the
customization exceeds 19
Reduce the size of the “identifier”
attribute of the “Customization”
tag in the customization
ERR4
Error (ERR4) – Diagnose:
... Revision date is invalid
Revision date must match the
following pattern:
YYYY-MM-DDThh:mm:ss
Check and correct the Revision
date in the customization
ERR5
Error (ERR5) – Diagnose:
Invalid nnm_am ID: xxx
instead of 1315
nnm_am ID must be set to 1315
Check and correct the value of the
“identifier” attribute of the
“AMDefinition” tag in the
customization
ERR6
Error (ERR6) – Diagnose:
AM ID is not a positive
integer
The AM ID must be a positive
integer
Check and correct the value of the
“identifier” attribute of the
“AMDefinition” tag in the
customization
ERR7
Error (ERR7) – Diagnose:
xxx module does not have
a valid OID
The “rootSnmpOID” attribute of
the MIBModule xxx is not a valid
SNMP OID
Check and correct the value in the
customization
ERR8
Error (ERR8) – Diagnose:
xxx SnmpOID is not a
valid OID
The “SnmpOID” tag set to xxx
into a “TrapVariableDefinition”
tag is not a valid SNMP OID
Check and correct the value in the
customization
160
Error
Code
Error Message
Reason
Corrective action
ERR9
Error (ERR9) – Diagnose:
xxx IndexVB is not an
integer
The “IndexVB“ tag set to xxx into
a “TrapVariableDefinition” tag is
not an integer
Check and correct the value in the
customization
ERR10
Error (ERR10) –
Diagnose: Invalid Global
Class OID
The “snmpOID” attribute of the
Global Class is not a valid SNMP
OID
Check and correct the value in the
customization
ERR11
Error (ERR11) –
Diagnose: Invalid
isGlobalClass attribute,
value must be True for
Global Class
The “isGlobalClass” attribute
must be set to True when defining
the Global Class
Check and correct the value in the
customization
ERR12
Error (ERR12) –
Diagnose: Depth of your
entity model must be less
than 10 levels
Entity Model depth exceeds 10
Check and correct the Entity
Model in the customization
ERR13
Error (ERR13) –
Diagnose: Invalid
isGlobalClass attribute,
value must be set to False
for Child Classes
The “isGlobalClass” attribute
must be set to False when
defining a Child Class
Check and correct the value in the
customization
ERR14
Error (ERR14) –
Diagnose: xxx OID is not
a valid OID
xxx OID is not a valid SNMP
OID
Check and correct the value in the
customization
ERR15
Error (ERR15) –
Diagnose: xxx ID set to
yyy is not valid : it must
be a positive integer
The “identifier” attribute set to
yyy for the class xxx is not a
positive integer
Check and correct the value in the
customization
ERR16
Error (ERR16) –
Diagnose: Class ID xxx
set for yyy is already used
The Class ID set to xxx for yyy is
already used
Choose another Class ID for yyy
ERR17
Error (ERR17) –
Diagnose: Retention
Policy Clear attribute set
to xxx is not an integer
value
The “clear” attribute value of the
“RetentionPolicy” tag is not an
integer
Check and correct the value
ERR18
Error (ERR18) –
Diagnose: Retention
Policy Major attribute set
to xxx is not an integer
value
The “major” attribute value of the
“RetentionPolicy” tag is not an
integer
Check and correct the value
ERR19
Error (ERR19) –
Diagnose: Retention
Policy Minor attribute set
to xxx is not an integer
value
The “minor” attribute value of the
“RetentionPolicy” tag is not an
integer
Check and correct the value
161
ERR20
Error (ERR20) –
Diagnose: Retention
Policy Critical attribute
set to xxx is not an integer
value
The “critical” attribute value of
the “RetentionPolicy” tag is not
an integer
Check and correct the value
ERR21
Error (ERR21) –
Diagnose: Retention
Policy Indeterminate
attribute set to xxx is not
an integer value
The “indeterminate” attribute
value of the “RetentionPolicy” tag
is not an integer
Check and correct the value
ERR22
Error (ERR22) –
Diagnose: Retention
Policy Clearance Delay
Detection attribute set to
xxx is not an integer value
The “clearancedetectiondelay”
attribute value of the
“RetentionPolicy” tag is not an
integer
Check and correct the value
ERR23
Error (ERR23) –
Diagnose: DefaultEntities
ocName (xxx) has same
first 9 characters as
Autopopulation following
ocNames on the same
director (yyy): zzz
OC names (xxx, zzz) on a director
cannot begin with the 9 first same
characters
Check and correct OC names
ERR24
Error (ERR24) –
Diagnose: defaultEntities
ocDefinition (xxx) is
associated to different
domainDefinition(s) than
its domainDefinition (yyy)
in Autopopulation: zzz
OC called xxx cannot be
associated to an other domain
than yyy
Check and correct the
“collectionDomainName”
attributes for the “ocName” xxx
ERR25
Error (ERR25) –
Diagnose: Default
Mapping in
MappingTable does not
exist
A mapping with a
“isDefaultMapping=”True””
attribute is missing in the
“MappingTables” tag
Check and correct the problem in
the customization
ERR26
Error (ERR26) –
Diagnose: More than one
Default Mapping in
MappingTable exists
Only one
“isDefaultMapping=”True””
attribute can be set in the
“MappingTables” tag
Check and correct the problem in
the customization
ERR27
Error (ERR27) –
Diagnose: Default
EventMapping does not
exist
No “isDefaultMapping=”True””
attribute is set for all the
“EventMapping” tags
Check and correct the problem in
the customization
ERR28
Error (ERR28) –
Diagnose: More than one
Default EventMapping
rule exists
Only one
“isDefaultMapping=”True””
attribute can be set in the
“EventMapping” tags
Check and correct the problem in
the customization
ERR29
Error (ERR29) –
Diagnose: xxx Default
Event does not have a
valid OID (no supported
wildcard on an OID)
Cannot set a wildcard OID in the
“eventOID” attribute of the
“EventMapping” tag
Check and correct the value in the
customization
162
ERR30
Error (ERR30) –
Diagnose: xxx Event does
not have a valid SnmpOID
Check the value of the
“eventOID” attribute xxx of the
“EventMapping” tag
Check and correct the value of the
SNMP OID xxx
ERR31
Error (ERR31) –
Diagnose: xxx
alarmFieldId attribute is
invalid : should be a
positive integer value
instead of yyy
The “alarmFieldId” attribute
associated to the
“alarmFieldName” xxx is set to
yyy which is not a positive
integer value
Check and correct the value of the
“alarmFieldId” attribute set to
yyy
ERR32
Error (ERR32) –
Diagnose: The
alarmFieldID attribute of
an
AdditionalTextMappingR
ule is not set to a positive
integer value
The “alarmFieldId” attribute of
an “AdditionalTextMappingRule”
tag is not a positive integer value
Check and correct the value in the
customization
ERR33
Error (ERR33) –
Diagnose: The
alarmFieldID attribute of
a MappingReferenceTable
of a
MappingReferenceTable
is not set to a positive
integer
The “alarmFieldId” attribute of
an “MappingReferenceTable” tag
in a “MappingReferenceTable” is
not a positive integer value
Check and correct the value in the
customization
ERR34
Error (ERR34) –
Diagnose: xxx OID set in
TestCase is not a valid
SNMP OID
The “oid” attribute set in
“TestCase” is not a valid SNMP
OID
Check and correct the value in the
customization
ERR35
Error (ERR35) –
Diagnose: xxx variable
OID set in TestCase is not
a valid SNMP OID
The “oid” attribute set in the
“Variablevalue” tag of
“TestCase” is not a valid SNMP
OID
Check and correct the value in the
customization
ERR36
Error (ERR36) –
Diagnose: No Default
Entity Naming Rule found
No attribute
“isDefaultRule=”True”” found
for the “EntityNamingRule”
Check and correct in the
customization
ERR37
Error (ERR37) –
Diagnose: Several Default
Entity Naming Rules are
defined. Only one default
rule is allowed.
Only one
“isDefaultRule=”True”” attribute
can be set in the
“EntityNamingRule” tag
Check and correct in the
customization
ERR38
Error (ERR38) –
Diagnose: OCs called xxx
all have the same first 9
characters in their name
on director yyy
OC names (xxx, zzz) on a director
cannot begin with the 9 first same
characters
Check and correct OC names
ERR39
Error (ERR39) Diagnose: The following
Operation Context xxx is
associated to several
collection domains: yyy ;
OC called xxx cannot be
associated to yyy and zzz
domains
Check and correct the
“collectionDomainName”
attributes for the “ocName” xxx
163
zzz
ERR40
Error (ERR40) –
Diagnose: Indicated NNM
Event Mapping File does
not exist
The NNM Event Mapping File
cannot be found
Check the NNM Event Mapping
File existence
ERR41
Error (ERR41) –
Diagnose: xxx is not
conform to the NNMi
Filter schema
The Filter file is not conform to
the schema described in the
NNMi Filter Schema
Get a valid Filter file
ERR42
Error (ERR42) –
Diagnose: NNM Filter …
not exists
The filter defined in the
customization (in
AutoPopulation/EntityNamingRul
e part) is not present in the
Topology Filters file.
Be sure that the Topology Filters
file specified in input contains the
filter specified in the
AutoPopulation/EntityNamingRul
e part of the customization. For
example, if the customization
contains:
<NNMFilter
name=”CISCO_V1Filter”/>
Then the Topology Filter file
”CISCO_V1Filter.xml” must
exists
ERR43
Error (ERR43) –
Diagnose: xxx is not a
valid Constant for type
yyy
A Constant can be an integer, a
float, a relativeTime, an absTime,
a string or an enumeration
Check and correct in the
customization
ERR44
Error (ERR44) –
Diagnose: xxx
TrapVariable SnmpOID is
not a valid SNMP OID
The “snmpOID” attribute of the
TrapVariable xxx is not a valid
SNMP OID
Check and correct in the
customization
ERR45
Error (ERR45) –
Diagnose: xxx
TrapVariable does not
have a valid index
The “index” attribute of the
TrapVariable xxx is not a valid
index
Check and correct the index value
for TrapVariable xxx in the
customization
ERR46
Error (ERR46) –
Diagnose: xxx
TrapVariable is a
Reference but has a
TrapVariableDefinition
TrapVariable xxx cannot be a
Reference and have a
TrapVariableDefinition
Check and correct in the
customization
ERR47
Error (ERR47) –
Diagnose: xxx
TrapVariable is a
Definition but does not
TrapVariable xxx is defined as a
Definition, but the tag
“TrapVariableDefinition” is
missing
Check and correct in the
customization
164
have a
TrapVariableDefinition
ERR48
Error (ERR48) –
Diagnose: Managed
Object "..." is not defined
in the Entity Model
The managed object specified in
one of the event mapping is not
defined in the Entity model.
Check that the “className”
attribute of each event mapping is
defined in the <EntityModel>
part.
ERR49
Error (ERR49) –
Diagnose: xxx is not a
valid MappingTable
No “MappingTable” tag found
when a <MappingTables> tag is
defined
Check and correct in the
customization
ERR50
Error (ERR50) – Kit:
Cannot create JAR file
ERR51
Error (ERR51) – Kit:
Cannot locate input file:
xxx
The specified input file cannot be
found.
If the input file is not present in
the current directory, be sure to
specify the full path.
ERR57
Error (ERR57) – Missing
input customization file
No customization file has been set
in argument.
Ensure that the path is correct if
the customization file is not in the
same location as the tool.
ERR59
Error (ERR59): xxx
Error when trying to make and
delete a directory into /tmp
This requires root privileges.
ERR60
Error (ERR60): Could not
create a directory into
/tmp
Error when trying to make and
delete a directory into /tmp
This requires root privileges.
ERR61
Error (ERR61): XML
Customization file doesn't
exist
The specified input customization
file cannot be found.
If the input file is not present in
the current directory, be sure to
specify the full path.
ERR62
Error (ERR62): NNM
Topology Filters file
doesn’t exist
The specified input Topology
Filters file cannot be found.
If the input file is not present in
the current directory, be sure to
specify the full path.
ERR63
Error (ERR63): xxxx
doesn’t exist
The specified input Incident
Configuration xxx file cannot be
found.
If the input file is not present in
the current directory, be sure to
specify the full path.
ERR65
Error (ERR65): Cannot
locate input file: xxx
The specified input file cannot be
found.
If the input file is not present in
the current directory, be sure to
specify the full path.
ERR70
Error (ERR70): Missing
EventMapping XML
element
No <EventMapping> tag in the
customization
Check and correct the
customization
ERR71
Error (ERR71): Missing
Customization XML
element
The Customization is invalid and
is missing mandatory element or
elements.
Correct the customization file and
rerun the diagnoses to ensure the
integrity of the customization.
Read the previous error message
on the window
165
ERR72
Error (ERR72): Diagnose
failed
Diagnose failed
Fix the listed problems.
ERR73
Error (ERR73) Diagnose: The osiField
<osifield name> of the
trap <trap name> uses a
undefined variable <var
name>
An trap uses an undefined
variable
Either define the variable or
change the mapping to do not use
this variable
ERR74
Error (ERR74) Diagnose: The osiField
<osifield name> of the
trap <trap name> uses a
variable <var name>
without specifying any
input information"
A Computed Variable is used in
one osi field but not input
information are provided in both
definition and usage
Add input information either in
the variable definition or in the
osi field
ERR75
Error (ERR75) Diagnose: The input
information of the
Computed Variable <var
name> is incomplete for
the trap <trap name>
Computed Variable defined for
one specific trap requires input
information that is incomplete
See Computed Variable definition
and usage and add a ‘inputType
and inputValue information
ERR76
Error (ERR76) Diagnose: The input
information of the Global
Computed Variable <var
name>
Computed Variable defined in
Global part of the custom requires
input information that is
incomplete
See Computed Variable definition
and usage and add a ‘inputType
and inputValue information
ERR77
Error (ERR77) Diagnose: The Computed
Variable <var name> is
defined several times in
Global part
Computed Variable is defined
several time in the Global part of
the custom
Remove redundancy
ERR78
Error (ERR78) Diagnose: The Computed
Variable <var name> is
defined several times in
the Local part for the trap
<trap name>
Computed Variable is defined
several time in both Global part
of the custom and locally for a
trap
Remove redundancy
ERR79
Error (ERR79) Diagnose: The Computed
Variable <var name> is
defined several times in
the Global part and for the
trap <trap name>
Computed Variable is defined
several time locally for one trap
definition
Remove redundancy
ERR80
Error (ERR80) Diagnose: same index
<index label> are defined
in the SWITCH
Computed Variable <var
name> for the trap <trap
name>
SWITCH Computed Variable
needs to define different index
labels
Change the index if required or
remove it if unused
166
ERR81
Error (ERR81) Diagnose: Impossibility to
find the class <class
name> associated to the
variable <var name> for
the trap <trap name>
External library is
not provided or one
provided does not contain
the suitable class name for
this local Computed
Variable
Use <-e> option with the tool to
indicate the external library
Check with “jar tvf *jar’ that the
involved class is present
ERR82
Error (ERR82) Diagnose: Impossibility to
find the class <class
name> associated to the
Global variable <var
name> External library is
not provided or one
provided does not contain
the suitable class name for
this Computed Variable
defined in the global part
of the custom
Use <-e> option with the tool to
indicate the external library
Check with “jar tvf *jar’ that the
involved class is present
ERR83
Error (ERR83) Diagnose: There is no
external function file
provided for the class
<class name> associated
to the variable <var
name> for the trap <trap
name>
External Computed
Variable(defined for a trap)
requires external jar library that is
not found
Assume tool use the ‘-e’ option
with suitable external jar file
ERR84
Error (ERR84) Diagnose: There is no
external function file
provided for the class
<class name> associated
to the Global variable
<var name>
External Computed Variable
(defined in the global part of the
custom) requires external jar
library that is not found
Assume tool use the ‘-e’ option
with suitable external jar file
ERR85
Error (ERR85) Diagnose: Incoherence
between the Entity Model
and the Managed Object
for the trap <trap name>”
Managed object expressed does
not match the Model defined in
the custom for the specific trap
(instanceless, bad child class
name,…)
Check trap Managed Object field
and Entity model and fix one or
other
ERR86
Error (ERR86) Diagnose: Inadequate type
for Managed Object field
for the trap <trap name>”
The Managed Object part is
incomplete and some parts are
missing
Check with DTD that all parts are
provided
ERR87
Error (ERR87) Diagnose: Inadequate type
of the Computed Variable
<var name> for the trap
<trap name>
Local Computed Variable of type
‘X’ needs to contains a ‘X’ XML
data such as type=”External” and
External XML element needs to
be defined
Update the computed variable
accordingly
167
ERR88
Error (ERR88) Diagnose: Inadequate type
of the Global Computed
Variable <var name>
Computed Variable of type ‘X’
defined in the global part of the
custom needs to contains a ‘X’
XML data such as
type=”External” and External
XML element needs to be defined
Update the computed variable
accordingly
ERR89
Error (ERR89) Diagnose: Inadequate type
of the Global Computed
Variable <var name>
Computed Variable of type ‘X’
defined in the global part of the
custom needs to contains a ‘X’
XML data such as
type=”External” and External
XML element needs to be defined
Update the computed variable
accordingly
ERR90
Error (ERR90) Diagnose: The event with
the name <EventName> is
defined several times in
EventMapping definition
The eventName has been found
several times in the Trap
definition
Update the Trap definition
accordingly
ERR91
Error (ERR91) Diagnose: The event with
the OID <eventOID> is
used several times in
Event Mapping definition
The eventOID has been used
several times
Update the Trap definition
accordingly
ERR92
Error (ERR92) Diagnose: The event
<eventName> has an OID
wildcarded <eventOID>
whereas it is not a default
mapping
Wildcarded OID is only allowed
for default mapping
Update the OID definition
accordingly
ERR93
Error (ERR93) Diagnose: The key
<keyValue> is used
several times in the
MappingTable named
<tableName>
Key value is unique un a table
Update the key value accordingly
ERR94
Error (ERR94) Diagnose: The event
<event name> does not
have all mandatory alarm
fields defined (Managed
Object, Perceived
Severity, Probable Cause,
Event Type), alarm field
<alarm field ID> is
missing"
There is a missing mandatory
alarm field in the trap definition
Add missing definition
There is a duplicate definition of
alarm field
Remove the duplicate definition
ERR95
168
Error (ERR95) Diagnose: Duplicate
definition of the Alarm
Field with ID <alarm field
ID> in the rule <event
tname>
ERR98
Error (ERR98) Diagnose: The
customization is defined
as Default, AM must be
named NNMi_AM the
current AM name is yyy
The custom is defined as default
so it should have AM name as
NNMi_AM and no other name
Modify the custom name or the
default flag to a proper value.
ERR99
Error (ERR99) Diagnose: The
customization is defined
as Default, AM ID must
be 1315, the current AM
ID is yyy
The custom is defined as default
but the AM ID provided is not
matching the default 1315
Modify the AM ID or the default
flag to the a proper value
ERR10
0
Error (ERR100) Diagnose: The Specific
Problem label xxx is
already used with the
value yyy whereas it is
now used with the value
zzz
The specific problem with same
name xxx is used in different
event mapping having different
values yyy and zzz which is
incorrect.
Modify the specific problem
value or specific problem name in
the customization to make the
Specific problem name and value
pair unique
ERR10
1
Error (ERR101) Diagnose: The Specific
Problem value xxx is
already used with the label
yyy whereas it is now
used with the label yyy
The specific problem value xxx is
used in different event mapping
having different names yyy and
zzz which is incorrect
Modify the specific problem
value or specific problem name in
the customization to make the
Specific problem name and value
pair unique
ERR11
1
Error (ERR111): In
EventMapping,
TeMIPEnumMappingRule
is of type
ComputedVariable but
ComputedVariable label
details are not available "
Incorrect label or computed
variable not defined before use in
the Event Mapping or TeMIP
Enum Mapping Rule
Define the computed variable in
the computed variable or use the
correct label in the Event
Mapping or TeMIP Enum
Mapping Rule
8.2 TNT Deployment Tools
8.2.1
8.2.1.1
The tnt_rt_create_nnm_am_application.sh Script
Description
If one of the prerequisites is not reached, the script exits.
If the check of the parameters fails, the script exits and displays the usage.
If one of the sub-scripts that are called fails, the script makes a file cleanup and exits
(files created by the script in working directory, target directory, or OS kit directory
are removed).
169
8.2.1.2
Error Messages
Here are the details of all reported errors:
Table 26
Error messages for the tnt_rt_create_nnm_am_application.sh
script
Error Message
Reason
Display
Usage
“Only root user can run this script”
If the user is not root
“TeMIP must be started to run this tool”
If TeMIP is not started
“Missing parameters.”
If the number of mandatory
parameters is not reached
X
“Invalid parameter [$1 $2]”,
If an argument is unknown
X
“Missing mandatory parameter"
If a mandatory argument is not
provided
X
“use_all def_stations parameter value can be
only true or false"
Invalid parameter value for –
use_all_def_stations (neither true or
false)
X
Invalid parameter value, directory does not
exist
Working Directory does not exist
X
Invalid parameter value, directory does not
exist
Target Directory does not exist
X
“The three optional parameters for default
entity/oc/domain have to be provided if one is
provided.”
The three optional parameters for
default entity/oc/domain have to be
provided if one is provided.
X
“Missing runtime kit file
[$WORKING_DIR/${CUSTOM_ID}.jar]”
RunTime kit file not found in
working directory
X
“script execution failed
The tnt_rt_kit_expansion.sh subscript fails
where $1 and $2 is the unknown parameter
and its value
[<script name> …parameters…]”
“script execution failed
[<script name> …parameters…]”
“script execution failed
[<script name> …parameters…]”
“script execution failed
[<script name> …parameters…]”
“script execution failed
[<script name> …parameters…]”
170
The tnt_nnm_am_os_kit_creation.sh
sub-script fails
The
tnt_nnm_am_os_kit_installation.sh
sub-script fails
The
tnt_nnm_am_os_kit_activation.sh
sub-script fails
The tnt_nnm_am_load_custom.sh
sub-script fails
8.2.2
8.2.2.1
8.2.2.2
The tnt_nnm_am_load_custom.sh Script
Description



If one of the prerequisites is not reached, the script exits.
If the check of the parameters fails, the script exits and displays the usage.
If one of the sub-scripts that are called fails, the script makes a cleanup and exits.
Error Messages
Here are the details of all reported errors:
Table 27
Error messages for the tnt_nnm_am_load_custom.sh script
Error Message
Reason
Display
Usage
“TeMIP must be started to run this tool”
If TeMIP is not started
“Invalid value for appli_id [$APPLI_ID]”, where
APPLI_ID is the –appli_id parameter provided
If the –appli_id argument is not a
valid integer
X
“Invalid parameter [$1 $2]”, where $1 and $2 are
the unknown parameters
If an argument is unknown
X
“Missing mandatory parameter value"
If a mandatory argument is not
provided
X
“Invalid flat file
[$CUSTOM_FLAT_FILE_FULL_PATH]”
The flat file name provided is not
found
“use_all def_stations parameter value can be
only true or false"
Invalid parameter value for –
use_all_def_stations (neither
true or false)
X
The three optional parameters for default
entity/oc/domain have to be provided if one is
provided.
The three optional parameters for
default entity/oc/domain have to
be provided if one is provided.
X
No runtime kit file NODE_V1.jar exists in the
working directory [XXX]
This is because the working
directory provided as a parameter
does not exist or it exists but does
not contain the runtime kit.
“Script execution failed [<script name>
…parameters…]”
The tnt_rt_kit_expansion.sh subscript fails
“Failed to set up Use All Configured Stations
attribute”
If the Use All Configured Stations
NNM AM Self Management
attribute cannot be set
"Failed to create station [$station]”, where
$station is the name of the station to create
If the creation of a station has
failed
“Error while deleting the custom application
[$APPLI_NAME]”, where the $APPLI_NAME
is the application name of the customization to
remove
If the remove of the
customization has failed (in case
of MSL data model has changed)
“Error while creating/installing the custom
application [$APPLI_NAME]”, where the
$APPLI_NAME is the application name of the
customization to install
If the installation of the
customization has failed (in case
of MSL data model has changed)
“Cannot expand runtime kit[$CUSTOM_ID]”,
If the expansion of the runtime kit
171
Error Message
Reason
where $CUSTOM_ID is the runtime kit file to
expand
file has failed (in case of update
mode)
“Cannot move backup customization"
If the backup of the previous
customization has failed
“Cannot deploy custom”
If the deployCustom directive has
failed
“Error during the launch generation tool”
If the launch generation tool has
failed
8.2.3
Display
Usage
The tnt_rt_delete_nnm_am_application.sh Script
8.2.3.1
Description
8.2.3.2
Error Messages
Table 28
The tnt_rt_delete_nnm_am_application.sh Error Messages
Error Message
Reason
“Only root user can run this script”
If the user is not root
“TeMIP must be started to run this
tool”
If TeMIP is not started
“Missing parameters.”
If the number of mandatory parameters
is not reached
X
“Invalid parameter [$1 $2]”, where $1
and $2 is the unknown parameter and
its value
If an argument is unknown
X
“Missing mandatory parameter"
If a mandatory argument is not provided
X
“Parameters are not correctly used.”
This is because the is_default_custom
and the appli_name are mutually
exclusive.
X
“script execution failed [<script name>
…parameters…]”
If tnt_adapters_undeploy_custom.sh
fails
“script execution failed [<script name>
…parameters…]”
If tnt_nnm_am_os_kit_uninstallation.sh
fails
8.2.4
8.2.4.1
Display
Usage
The TNT Launch Generation Tool
Error Messages
Table 29
Error messages for the Launch Generation Tool
Error Message
Reason
Display
Usage
tnt_launch_generation.sh: Error: Mandatory
parameter <customXML> has to be provided as
input argument
Missing customization file
X
172
Error Message
Reason
Display
Usage
tnt_launch_generation.sh: Error: Invalid parameter
Invalid input parameter
X
tnt_launch_generation.sh: Error: customization
XML file doesn't exist
Customization file not found
tnt_launch_generation.sh: Error: cannot read
customization XML file
Customization file cannot be
read or accessed
tnt_launch_generation.sh: Error: invalid directory
Output Directory is invalid
tnt_launch_generation.sh: Error: cannot write in
the directory
Output Directory is read only
tnt_launch_generation.sh: Error: cannot access to
the directory
Access denied on the Output
Directory
tnt_launch_generation.sh: Error: Template file
name contains an invalid character (\/:*?\"<>|)
Launch Definition Template
contains invalid characters
tnt_launch_generation.sh: Error: Template file
doesn't exist
Launch Definition Template
not found
tnt_launch_generation.sh: Error: Template file
XXX is not readable
Cannot read the Launch
Definition File
tnt_launch_generation.sh: Error: Cannot get local
director
Problem to identify the local
TeMIP Director
tnt_launch_generation.sh: Error: Cannot get any
station names on the local director.
Problem to list the stations
defined in the TeMIP Director
tnt_launch_generation.sh: Error: Cannot retrieve IP
address of the station
Problem to get IP address of
the station
tnt_launch_generation.sh: Error: Station XXX does
not exist
Station cannot be found
tnt_launch_generation.sh: Error: No write
permission on /tmp directory; please add write
permission on /tmp before re-launching the tool.
Problem to write in the
temporary directory
tnt_launch_generation.sh: Error occurs
customization file extraction
Cannot get mandatory data
from the customization file
(xml)
tnt_launch_generation.sh: Error: Cannot get the
custom identifier of the application
Cannot get the Custom
Identifier from the
customization file
tnt_launch_generation.sh: Error: customization
data are missing
Class Identifier, Class name or
custom Identifier are missing
in the customization file
tnt_launch_generation.sh: Error occurs, the launch
generation file already exists XXX. Please use
parameter –override to allow overriding it."
Launch Definition File already
exists and the option to
override the file is not set by
user
tnt_launch_generation.sh: Error occurs during
parsing of XXX. Check log file
/var/opt/temip/trace/nnm_am_toolkit.log for
details.
Error while parsing the Launch
Definition Template
173
8.2.5
The TNT Launch Publication Tool
8.2.5.1
Error Messages
Table 30
Error messages for the Launch Publication Tool
Error Message
Error Case
Display
Usage
tnt_launch_publication.sh: Error: Missing
parameters
Missing input parameters
X
tnt_launch_publication.sh: Error: Invalid
parameter
Invalid input parameters
X
tnt_launch_publication.sh: Error: Missing
mandatory parameter value
Missing mandatory parameters
(Launch Definition file)
X
8.3 TeMIP Client TeMIP NNMi Advanced
Integration Plug-in (TNT Plug-in)
This component will provide the standard tracing processing in the TeMIP Client
environment. A new trace mask is available to trace the TNT component.
Setting the following environment variables before the starting the TeMIP Client will
activate the traces.
TeMIPClient_TRACE = Trace mask
Where
 Trace mask (bit mask value) is the result of the “Bitwise” of the levels to activate
and of the modules to trace.
The Low Level byte (0x000000XX) indicates the trace levels to activate
Table 31
TeMIP Client Level Trace Mask
Hexadecimal Value
Definition
0x00000001
Errors and Problems
0x00000002
Exceptions
0x00000004
Informations (verbose mode)
0x00000008
Function entrance
The three High Level bytes (0xXXXXXX00) indicates the plug-in (.exe .dll .tpi) to
trace.
Table 32
TeMIP Client TNT Plug-in Trace Mask
Hexadecimal Value
Definition
Type
0x20000000
TeMIP NNM Advanced Integration Plug In
(TNT Plug-in)
TPI
Please refer to the TeMIP Client Installation and configuration Guide for more
details about troubleshooting the TNT Plug-in.
174
8.4 NNMi View Integration
8.4.1
How to Check the TeMIP TNT Plug-in is Installed and
Running
After starting the TeMIP client, the user can easily check if the TNT Plug-in has been
installed and started correctly.
The user can select the menu option named “Help” then “About…” It displays the
About Box with the list of loaded plug-in. The user should see the TNT plug-in and
the TNTCorbaAPI plug-in.
Figure 26
The TeMIP Client about dialog box
If these plug-ins are not listed, check the message console to see why the plug-ins
cannot be started.
Check if the TNT kit has been installed by clicking the ‘Versions…” button. A dialog
box displays the list of installed kit and the level of patch for each kit. The user
should see “TeMIP TNT Vx.x for Windows” (where x.x is the version of the plug-in).
175
Figure 27
8.4.2
TeMIP Client Patch and Versions dialog box
How to Check the Configuration in the TeMIP Client
After starting the TeMIP client, you can easily check your configuration.
1. Select the menu option named “Tools” then “Options…”. This will display a Tool
dialog box with several window tabs.
2. Select the tab named “TNT”. The current configuration can then be seen by
TeMIP Client (Director / Stations).
3. The configuration can then be refreshed by clicking the “Refresh” button.
176
Figure 28
TeMIP TNT Plug-in Options
Information displayed by the GUI can be also requested using the TAL or FCL
command:
Example 94
Show NNM_CONFIGURATION command
TeMIP > SHOW NNM_CONFIGURATION <myTNTServer> STATIONS * all char
Where:
 <myTNTServer> is the name of the NNM_CONFIGURATION instance (ex:
hadi_nnm-conf).
8.4.3
TNT Plug-in Can not Find the Director or Stations
At startup, the TeMIP Client TNT Plug-in loads the NNM Station configuration
defined in the TeMIP Director. The user can customize the list of TeMIP Directors to
use through an environment variable named TEMIP_TNT_SERVERS.

If TEMIP_TNT_SERVERS environment variable is empty or doesn’t exist, the
name of the connected TeMIP local director is used to identify the TeMIP director
by replacing “_director” by “_nnm_conf” (i.e. if the TeMIP director is
.temip.hadi_director the TNT server will be .hadi_nnm_conf).
 If TEMIP_TNT_SERVERS exists and is not empty, all contained TNT servers are
extracted by parsing the environment variable value with “,” separator.
177
If the user notices that the TeMIP Client has problem to find this instance by itself,
the user can easily force the name of the server to use with the following environment
variable.
Example 95
TeMIP_TNT_SERVERS environment variable
TEMIP_TNT_SERVERS=.hadi_nnm_conf , titan_nnm_conf
This example shows how to use the environment variable to define two TeMIP
directors: hadi and titan.
8.4.4
Can not Access the NNM Home Base
To communicate with the NNM Web servers, NNMi Views use port 80.
If you cannot start the NNM Home Base, check the port number of the NNM home
base. List the port usage using the following command:
netstat –an | grep 80
It should show a line with the state "LISTEN".
Note
Check the help usage of netstat for more details.
Figure 29
178
Home Base Port checking command
Appendix A
The Customization File
A.1 Customization DTD
The Customization file must respect the syntax specified in the DTD file
/opt/OV/TNT/customToolkit/include/Customization.dtd. Here is the content of this
file:
Document 1
The Customization.dtd file content
n="1.0" encoding="UTF-8"?>
<!-- Common dataTypes -->
<!ENTITY % type.duration "NMTOKEN">
<!ENTITY % type.string "CDATA">
<!ENTITY % type.strings "CDATA">
<!ENTITY % type.real "NMTOKEN">
<!ENTITY % type.int "NMTOKEN">
<!ENTITY % type.units "CDATA">
<!ENTITY % type.boolean "(True|False)">
<!ENTITY % type.dateTime "CDATA">
<!-- Enumeration -->
<!ENTITY % enum.datatype "(Int|Float|RelativeTime|AbsTime|String|Enum)">
<!ENTITY % enum.emr.type "(AdditionalText|TeMIPEnumeration|ManagedObject)">
<!ENTITY % enum.ci.type "(Constant|MappingTableReference|TrapVariable|Instanceless|ComputedVariable)">
<!ENTITY % enum.emr.enumType "(Constant|MappingTableReference|TrapVariable|ComputedVariable)">
<!ENTITY % enum.mappingInput "(Constant|TrapVariable|ComputedVariable)">
<!ENTITY % enum.trapvar.type "(Reference|Definition|RowIndex)">
<!ENTITY % enum.evm.admin "(Defined|Undefined|Discarded)">
<!ENTITY % enum.evm.eventType "(Snmp|NNM|MGMT)">
<!ENTITY % enum.snmpAttributeType "(Table|Scalar|OID)">
<!ENTITY % enum.snmp.dataType
"(Integer|IpAddress|OctetString|ObjectID|Integer32|Counter32|Gauge32|Unsigned32|TimeTicks|Opaque|Counter64|CiaDouble
<!ENTITY % enum.compvar.type "(regexp | ifCondition |switch | external)">
<!ENTITY % enum.ifoperator.type "(NOOP | AND | OR)">
<!ENTITY % enum.ifclauseoperator.type "(equal | notEqual | greaterThan | equalOrGreaterThan | lessThan | equalOrLess
<!ENTITY % enum.messageText.type "(nnm|user)">
<!ENTITY % enum.inputType "(variable | constant)">
<!ENTITY % enum.arg.valuetype "(integer | string)">
<!-Identifier type, allowing entities global or partial referencing or
definition. (NMTOKEN doesn't allow spaces) -->
<!ENTITY % type.localId "NMTOKEN">
<!-snmpOID supported pattern definition : ^([.]?)[0-9]+([.][0-9]+)*(([.][*])?)$
eventOID supported pattern definition : ^([.]?)[0-9]+([.][0-9]+)*(([.][*])?)$
-->
<!ENTITY % type.snmpOID "NMTOKEN">
<!ENTITY % type.eventOID "CDATA">
179
<!-- Customization.dtd : An XML DTD to encode Customization xml files. -->
<!-- Customization-->
<!ELEMENT Customization (Revisions, AMDefinition?, MIBModules, NNMPredefinedVariables, GlobalComputedVariables?,Enti
EventsMapping, AutoPopulation, NNMEventMappingFile?,TeMIPEnumDictionnary)>
<!ATTLIST Customization
identifier %type.localId; #REQUIRED
className %type.string; #REQUIRED
classIdentifier %type.localId; #REQUIRED
description %type.string; #IMPLIED
isDefault %type.boolean; "False"
isExclusive %type.boolean; "False">
<!-- Revisions -->
<!ELEMENT Revisions (Revision+)>
<!-- Revision-->
<!ELEMENT Revision (#PCDATA)>
<!ATTLIST Revision
date %type.dateTime; #REQUIRED
author %type.string; #REQUIRED
id %type.localId; #REQUIRED>
<!-- AMDefinition -->
<!ELEMENT AMDefinition EMPTY>
<!ATTLIST AMDefinition
name %type.string; #REQUIRED
identifier %type.localId; #REQUIRED>
<!-- MappingTables-->
<!ELEMENT MappingTables (MappingTable*)>
<!-- NNMPredefinedVariables -->
<!ELEMENT NNMPredefinedVariables (NNMPredefinedVariable*)>
<!-- NNMPredefinedVariable-->
<!ELEMENT NNMPredefinedVariable (TrapVariableDefinition?)>
<!ATTLIST NNMPredefinedVariable
dataType %enum.snmp.dataType; #REQUIRED
label %type.string; #REQUIRED>
<!-- TrapVariableRowIndex -->
<!ELEMENT TrapVariableRowIndex EMPTY>
<!ATTLIST TrapVariableRowIndex
label %type.string; #IMPLIED
index %type.eventOID; #REQUIRED>
<!-- TrapVariableDefinition -->
<!ELEMENT TrapVariableDefinition (IncidentLabelName | SnmpOID | IndexVB)>
<!-- IncidentLabelName -->
<!ELEMENT IncidentLabelName (#PCDATA)>
<!-- SnmpOID-->
<!ELEMENT SnmpOID (#PCDATA)>
<!-- IndexVB -->
<!ELEMENT IndexVB (#PCDATA)>
<!-- MIBModules -->
<!ELEMENT MIBModules (MIBModule*)>
180
<!-- MIBModule -->
<!ELEMENT MIBModule EMPTY>
<!ATTLIST MIBModule
name %type.string; #REQUIRED
description %type.string; #IMPLIED
rootSnmpOID %type.snmpOID; #REQUIRED>
<!-- EntityModel -->
<!ELEMENT EntityModel (ClassDefinition)>
<!-- ClassDefinition -->
<!ELEMENT ClassDefinition (ClassDefinition*)>
<!ATTLIST ClassDefinition
name %type.string; #REQUIRED
identifier %type.int; #REQUIRED
isInstanceless %type.boolean; "False"
isGlobalClass %type.boolean; "False"
snmpOID %type.snmpOID; #REQUIRED
snmpType %enum.snmpAttributeType; #REQUIRED>
<!-- EventsMapping-->
<!ELEMENT EventsMapping (EventMapping+)>
<!-- EventMapping -->
<!ELEMENT EventMapping (EventMappingRules?, ComputedVariables?, TestCases?)>
<!ATTLIST EventMapping
eventName %type.string; #REQUIRED
eventOID %type.eventOID; #REQUIRED
admin %enum.evm.admin; "Defined"
eventType %enum.evm.eventType; #REQUIRED
isDefaultMapping %type.boolean; "False">
<!--EventMappingRules -->
<!ELEMENT EventMappingRules (ManagedObjectMappingRule, TeMIPEnumMappingRule*, AdditionalTextMappingRule?)>
<!--EventMappingRule -->
<!ELEMENT EventMappingRule EMPTY>
<!ATTLIST EventMappingRule
type %enum.emr.type; #REQUIRED
alarmFieldName %type.string; #REQUIRED
alarmFieldID %type.int; #REQUIRED>
<!-- The AdditionalTextMappingRule Definition-->
<!ELEMENT AdditionalTextMappingRule (EventMappingRule, (MessageText
| ComputedVariable))>
<!-- MessageText -->
<!ELEMENT MessageText (#PCDATA | Resolver)*>
<!ATTLIST MessageText
type %enum.messageText.type; #IMPLIED>
<!-- The TeMIPEnumMappingRule Defintion. This corresponds to all other OSI fields other than the Managed Object and
<!ELEMENT TeMIPEnumMappingRule (EventMappingRule, (Constant | MappingTableReference | TrapVariable | ComputedVariabl
<!ATTLIST TeMIPEnumMappingRule
type %enum.emr.enumType; #REQUIRED
variableNameInput %type.string; #IMPLIED
default %type.int; #IMPLIED>
<!-- The Managed Object Definition-->
<!ELEMENT ManagedObjectMappingRule (EventMappingRule, (ClassInstance+ | ExtendedClassInstance))>
<!-- Extended Class Instance. Added for ATNI V5.4 in order simplfy the mapping for the Managed Object -->
<!ELEMENT ExtendedClassInstance (GlobalInstanceLookup, ChildClasses?)>
181
<!-- GlobalInstanceLookup Definition. This is also addded for ATNI V5.4 in order to define the global instance to lo
<!ELEMENT GlobalInstanceLookup (TrapVariable | Constant)>
<!ELEMENT ChildClasses (Resolver*)>
<!ATTLIST ChildClasses
value %type.string; #REQUIRED>
<!--MappingTable Definition-->
<!ELEMENT MappingTable (Description, MappingRow+)>
<!ATTLIST MappingTable
tableName ID #REQUIRED
osiField %type.string; #REQUIRED
label %type.string; #IMPLIED>
<!-- Description-->
<!ELEMENT Description (#PCDATA)>
<!--MappingRow-->
<!ELEMENT MappingRow EMPTY>
<!-- keyLabel -->
<!ATTLIST MappingRow
key %type.string; #REQUIRED
mappingValue %type.string; #REQUIRED
isDefaultMapping %type.boolean; "False">
<!-- MappingTable Reference -->
<!ELEMENT MappingTableReference (Constant | TrapVariable | ComputedVariable)>
<!ATTLIST MappingTableReference
mappingTable IDREF #REQUIRED
inputType %enum.mappingInput; #REQUIRED>
<!-- ClassInstance -->
<!ELEMENT ClassInstance (Constant | MappingTableReference | TrapVariable | ComputedVariable)?>
<!ATTLIST ClassInstance
type %enum.ci.type; #REQUIRED
className %type.string; #REQUIRED
classIdentifier %type.int; #REQUIRED
variableNameInput %type.string; #IMPLIED>
<!-- ComputedVariables Declaration / Usage -->
<!ELEMENT ComputedVariable EMPTY>
<!ATTLIST ComputedVariable
label %type.string; #REQUIRED
inputType %enum.inputType; #IMPLIED
inputValue %type.string; #IMPLIED
diagnose %type.boolean; "True">
<!-- ComputedVariables definition -->
<!ELEMENT ComputedVariables (VariableDefinition*)>
<!ELEMENT GlobalComputedVariables (VariableDefinition*)>
<!ELEMENT VariableDefinition (Regexp | IfCondition | Switch | External)>
<!ATTLIST VariableDefinition
name %type.string; #REQUIRED
description %type.string; #IMPLIED
type %enum.compvar.type; #REQUIRED
datatype %enum.datatype; #REQUIRED>
<!--Regular Expression Definition -->
<!ELEMENT Regexp (Resolver*)>
<!ATTLIST Regexp
pattern %type.string; #REQUIRED
182
inputType %enum.inputType; #IMPLIED
inputValue %type.string; #IMPLIED
output %type.string; #REQUIRED>
<!ELEMENT Resolver EMPTY>
<!ATTLIST Resolver
label %type.string; #REQUIRED
inputType %enum.inputType; #REQUIRED
inputValue %type.string; #REQUIRED>
<!-- The IF condition Definition -->
<!ELEMENT IfCondition (((Clause, IfClause) | Clause+), Then,Else?)>
<!ATTLIST IfCondition
operator %enum.ifoperator.type; #REQUIRED>
<!ELEMENT IfClause (Clause+)>
<!ATTLIST IfClause
operator %enum.ifoperator.type; #REQUIRED>
<!ELEMENT Clause (Operand*)>
<!ATTLIST Clause
operator %enum.ifclauseoperator.type; #REQUIRED>
<!ELEMENT Operand EMPTY>
<!ATTLIST Operand
type %enum.inputType; #REQUIRED
value %type.string; #REQUIRED>
<!ELEMENT Then EMPTY>
<!ATTLIST Then
outputType %enum.inputType; #REQUIRED
outputValue %type.string; #REQUIRED>
<!ELEMENT Else EMPTY>
<!ATTLIST Else
outputType %enum.inputType; #REQUIRED
outputValue %type.string; #REQUIRED>
<!-- Switch expression -->
<!ELEMENT Switch ((Case*), DefaultCase)>
<!ATTLIST Switch
inputType %enum.inputType; #IMPLIED
inputValue %type.string; #IMPLIED>
<!ELEMENT Case EMPTY>
<!ATTLIST Case
index %type.string; #REQUIRED
outputType %enum.inputType; #REQUIRED
outputValue %type.string; #REQUIRED>
<!ELEMENT DefaultCase EMPTY>
<!ATTLIST DefaultCase
outputType %enum.inputType; #REQUIRED
outputValue %type.string; #REQUIRED>
<!-- External Function Definition-->
<!ELEMENT External (ArgNetworkEvent?,Arg*)>
<!ATTLIST External
className %type.string; #REQUIRED>
<!-- The Argument Definition. These are the arguments that are passed to the external function -->
<!ELEMENT Arg EMPTY>
<!ATTLIST Arg
183
inputValueType %enum.arg.valuetype; #REQUIRED
inputType %enum.inputType; #REQUIRED
inputValue %type.string; #REQUIRED>
<!ELEMENT ArgNetworkEvent EMPTY>
<!-- TestCases -->
<!ELEMENT TestCases (TestCase*)>
<!-- TestCase -->
<!ELEMENT TestCase (TestCaseDescription?, VariableValue*)>
<!ATTLIST TestCase
name %type.string; #REQUIRED
eventOID %type.snmpOID; #IMPLIED>
<!-- TestCaseDescription -->
<!ELEMENT TestCaseDescription (#PCDATA)>
<!-- VariableValue-->
<!ELEMENT VariableValue EMPTY>
<!ATTLIST VariableValue
oid %type.snmpOID;#REQUIRED
type %enum.snmp.dataType;#REQUIRED
value %type.string; #REQUIRED>
<!-- Deployment -->
<!ELEMENT Deployment (RetentionPolicy, DefaultEntities)>
<!-- RetentionPolicy -->
<!ELEMENT RetentionPolicy EMPTY>
<!ATTLIST RetentionPolicy
critical %type.int; #IMPLIED
major %type.int; #IMPLIED
minor %type.int; #IMPLIED
warning %type.int; #IMPLIED
indeterminate %type.int; #IMPLIED
clear %type.int; #IMPLIED
clearanceDetectionDelay %type.int; #IMPLIED>
<!-- DefaultEntities -->
<!ELEMENT DefaultEntities EMPTY>
<!ATTLIST DefaultEntities
ocName %type.string; #IMPLIED
collectionDomainName %type.string; #IMPLIED
unknownEntityName %type.string; #IMPLIED
domainManagingDirector %type.string; #IMPLIED
ocManagingDirector %type.string; #IMPLIED>
<!-- AutoPopulation -->
<!ELEMENT AutoPopulation (NNMFilter, EntityNamingRules)>
<!-- NNMFilter -->
<!ELEMENT NNMFilter EMPTY>
<!ATTLIST NNMFilter
name %type.string; #REQUIRED>
<!-- EntityNamingRules -->
<!ELEMENT EntityNamingRules (EntityNamingRule*)>
<!-- EntityNamingRule -->
<!ELEMENT EntityNamingRule (NNMFilter)>
<!ATTLIST EntityNamingRule
tnsDirectory %type.string; #IMPLIED
184
ocName %type.string; #REQUIRED
entityNamePrefix %type.string; #IMPLIED
entityNameSuffix %type.string; #IMPLIED
collectionDomainName %type.string; #REQUIRED
domainManagingDirector %type.string; #IMPLIED
ocManagingDirector %type.string; #IMPLIED
isDefaultRule %type.boolean; "False">
<!-- Constant -->
<!ELEMENT Constant (#PCDATA)>
<!ATTLIST Constant
type %enum.datatype; #REQUIRED
label %type.string; #IMPLIED>
<!-- TrapVariable -->
<!ELEMENT TrapVariable (TrapVariableDefinition?, TrapVariableRowIndex?)>
<!ATTLIST TrapVariable
label %type.string; #REQUIRED
type %enum.trapvar.type; #REQUIRED>
<!-- NNMEventMappingFile -->
<!ELEMENT NNMEventMappingFile EMPTY>
<!ATTLIST NNMEventMappingFile
filename %type.string; #REQUIRED>
<!-- TeMIPEnumDictionnary -->
<!ELEMENT TeMIPEnumDictionnary EMPTY>
<!ATTLIST TeMIPEnumDictionnary
filename %type.string; #REQUIRED>
A.2 Customization File format
The Customization file has XML format, and contains several blocks of information
listed here after. The file conforms to the Customization DTD described in Chapter 4.
185
Figure 30
186
Overview of the Customization DTD using XML tags
Customization Properties
All data to define a customization:
 Custom Identifier (string): is the unique identifier for your customization.
 Global Class: Global class to customize.
 Global Class Name.
 Global Class Identifier.
 Exclusive: True / False: if a customization is exclusive, the TeMIP Adapter will
enforce the uniqueness of the mapping and if required will remove the previously
defined mapping (deletion topology event).
 Default: True / False: this flag indicates if the current customization is the default
one.
Revision Information
This information is useful for tracing and tracking purposes.
 List of revisions sorted by date/time.
 Date/Time.
 Author.
 Description.
AM Definition
This part defines the AM information (this must be unique):
 Application Identifier.
 Application Name.
MIB Modules
This part contains information about the MIB modules managed by this
customization. The information is usually retrieved from the MIB:
 Module name.
 Module rootSnmpOID.
 Module description.
Predefined Variables
This part contains the definition of the NNM predefined variables
(openViewSourceName, openViewSeverity, openViewCategory,
openViewTrapdConfMessage, temipConfigurationName and temipStationName):
 Datatype.
 Label.
 SNMP OID.
Global Computed Variables
This part contains the definition of the Computed variables whose the scope is the
entire customization file. This means that any variable defined in this part can ve used
in any trap definition of the customization file.
187
Entity Model
A customization corresponds to the implementation of one TeMIP global class so this
is mandatory information.
This defines:
 Global class customization.
 Any child classes.
The designer can define the entity model by either:
 Modifying the default equipment model.
 Merging the current model with MIB tree hierarchy.
Deployment Context
It defines information required during the deployment steps: Retention Policy,
Default Entities.
Policy retention (Warning, Minor, Major, Critical, Clear, Clearance detection Delay):
This policy impacts the processing of event message. The ‘event messages’ are kept
for a specific time (according to the severity for instance) instead of being directly
processed.
Default Entities: This definition sets the default entities name for
OPERATION_CONTEXT, DOMAIN and entity classes. It also sets the Managing
Director of these OPERATION_CONTEXT and DOMAIN entities.
Mapping Tables
This part contains mapping information between NNM values and TeMIP values.
Each mapping table block is defined by:
 Mapping Table name.
 OSI Field: Identifier of the alarm field on which the mapping applies.
 Description: A string explaining the role of the mapping table.
 Mapping rows: Containing both information:
 Mapping value: The TeMIP value.
 Key: The NNM value.
Events Mapping Rules
A rule is defined by:
 Trap Name. This corresponds to the name of the trap.
 SNMP Trap (v1) or notification (v2).
 NNM Event name.
 An OID.
 Managed Object Rule: This corresponds to a TeMIP entity with potential value of
instance deduced from either SNMP Trap varbind or pre-defined values. A MO
could be instanceless or instantiable.
 Event Type Rule: It can be a mapping to a constant, a variable, or a mapping
table.
 Probable Cause Rule: This corresponds to a direct assignment to a constant or to a
deduction from the NNM category.
188
 Severity Rule: this corresponds to a direct assignment to a TeMIP Severity
constant or to a deduction from the NNM severity or from the content of a SNMP
variable.
 Specific Problem Rule : the value is a name or other expression
 Additional Text Rule : the value is either the trap content or a free text using
SNMP Trap varbind/pre-defined values or trapd.conf information
 Notification ID Rule / Correlation ID Rule: the value is either a constant or
<SNMP Trap Varbind>. Correlation Notification ID is set only if the Severity is
clear, else the Correlation ID is used.
 Computed Variables: this is the specific part where local computed variables are
defined means that acts for the trap only.
 Test Cases: Information required emitting a specific event that permit to
troubleshoot the event and check if this rule works correctly.
 Default flag: the value is true or false and indicates if the current rule is the default
one.
Four types of mapping are supported for most of the OSI fields (exception for
Managed Object and Additional Text).
The mapping is based on:
Direct assignment to a Constant:
Ex: Severity = 2
Deduced from SNMP Variable value. This can imply a type casting at runtime. It
should be indicated during the design of the custom.
Ex: Severity = $2
Deduced from a Mapping Table. It means the table has been previously updated by
the designer with the correct value. A table can be named in order to be re-used by
several event mappings.
Ex: Severity = Mapping ( “x1Translation”, aSeverityVariable)
where x1Translation is the name of the mapping table.
Deduced from a variable defined locally or globally. Any variable can be either a
Conditional expression (IF/THEN/ELSE) or a Regular expression (Regexpr) or a
Generic Mapping Table (Switch) or an External code (External Java code).
Ex: Severity = IF (vb2>0) THEN vb2 ELSE 2
Auto-Configuration / Discovery Configuration
This part addresses the Topology auto-configuration and population aspects. It
defines the different ways to populate a NNM Topology object.
It is a set of rules defining:
 Naming Rules. Each rule identifies the naming convention:
 TNS Directory.
 The name of the domain in which the populated objects are automatically created
as member (automatic collection put in place).
 The Operation Context name that uses the previous domain name as the collection
domain.
 Entity Name (suffix and prefix).
 Domain managing director.
189
 OC Managing director.
 A default flag is present to indicate if the current rule is the default one.
 NNMi filters name that selects NNNi Topology objects that are in the scope of
this naming rule.
190
Appendix B
The Entity Model File
B.1 The Entity Model DTD
The Entity Model file must respect the syntax specified in the DTD file
/opt/OV/TNT/customToolkit/include/EntityModel.dtd.
Such DTD file only describes the Child Class hierarchy (the global class is not
included because it is specified by another option).
Here is the content of this file:
Document 2
the EntityModel.dtd file content
<?xml version="1.0" encoding="UTF-8"?>
<!-- Common dataTypes -->
<!ENTITY % type.string "CDATA">
<!ENTITY % type.boolean "(True|False)">
<!ENTITY % type.int "CDATA">
<!-- Enumeration -->
<!ENTITY % enum.snmpAttributeType "(Table|Scalar|OID)">
<!-snmpOID supported pattern definition : ^([.]?)[0-9]+([.][0-9]+)*(([.][*])?)$
-->
<!ENTITY % type.snmpOID "NMTOKEN">
<!-- EntityModel.dtd : An XML DTD to encode EntityModel xml files. -->
<!-- EntityModel -->
<!ELEMENT EntityModel (ClassDefinition*)>
<!-- ClassDefinition -->
<!ELEMENT ClassDefinition (ClassDefinition*)>
<!ATTLIST ClassDefinition
name %type.string; #REQUIRED
isInstanceless %type.boolean; "False"
snmpOID %type.snmpOID; #REQUIRED
snmpType %enum.snmpAttributeType; #REQUIRED
ID %type.int; #REQUIRED>
B.2 The Entity Model File Format
The Entity Model file has XML format, and contains one block of information listed
here after. The file conforms to the EntityModel DTD described in section above.
191
Figure 31
An overview of the Entity Model XML file
Entity Model
This section defines the child classes to create under the global class.
Each class is represented by a ClassDefinition element. ClassDefinition elements can
be added under each definition level creating a class hierarchy up to a maximum of
ten levels.
Each class is defined by the following attributes:
 name: the TeMIP name of the class
 snmpOID: the SNMP OID of the class
 snmpType: the SNMP type of the class, one of “Table”, “Scalar” or “OID”
 isInstanceLess. Classes are not instanceless when the snmpType=”Table”,
otherwise they are instanceless.
 ID: the TeMIP Class identifier
The designer can define the entity model by copying and modifying the default Entity
Model file, or by creating a new Entity Model file with a valid syntax.
192
B.3 The Entity Model Default File
Here is the content of the default Entity Model file, located in
/opt/OV/TNT/customToolkit/include/EntityModel.xml which is the default Entity
Model used if no Entity Model file is provided in the command line of the
tnt_custom_gen tool. Such file adds the standard SNMP child classes to the generated
TeMIP Entity Model.
Document 3 The default Entity Model file output
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE EntityModel SYSTEM
"/opt/OV/TNT/customToolkit/include/EntityModel.dtd">
<EntityModel>
<ClassDefinition snmpOID="1.3.6.1.2.1.1" name="SYSTEM" ID="1"
snmpType="OID" isInstanceless="Tr
ue">
</ClassDefinition>
<ClassDefinition snmpOID="1.3.6.1.2.1.2" name="INTERFACE" ID="2"
snmpType="OID">
</ClassDefinition>
<ClassDefinition snmpOID="1.3.6.1.2.1.4" name="IP" ID="4"
snmpType="OID" isInstanceless="True">
</ClassDefinition>
<ClassDefinition snmpOID="1.3.6.1.2.1.5" name="ICMP" ID="5"
snmpType="OID" isInstanceless="Tru
e">
</ClassDefinition>
<ClassDefinition snmpOID="1.3.6.1.2.1.6" name="TCP" ID="6"
snmpType="OID" isInstanceless="True"
>
</ClassDefinition>
<ClassDefinition snmpOID="1.3.6.1.2.1.7" name="UDP" ID="7"
snmpType="OID" isInstanceless="True"
>
</ClassDefinition>
<ClassDefinition snmpOID="1.3.6.1.2.1.8" name="EGP" ID="8"
snmpType="OID" isInstanceless="True"
>
</ClassDefinition>
<ClassDefinition snmpOID="1.3.6.1.2.1.11" name="SNMP" ID="11"
snmpType="OID" isInstanceless="Tr
ue">
</ClassDefinition>
<ClassDefinition snmpOID="1.3.6.1.4.1" name="ENTERPRISES" ID="16"
snmpType="OID" isInstanceless
="True">
</ClassDefinition>
<ClassDefinition snmpOID="1.3.12.2.1011.2.22.1.201" ID="201"
name="CHASSIS" snmpType="OID">
</ClassDefinition>
<ClassDefinition snmpOID="1.3.12.2.1011.2.22.1.202" ID="202"
name="RACK" snmpType="OID">
</ClassDefinition>
<ClassDefinition snmpOID="1.3.12.2.1011.2.22.1.203" ID="203"
name="SHELF" snmpType="OID">
</ClassDefinition>
<ClassDefinition snmpOID="1.3.12.2.1011.2.22.1.204" ID="204"
name="SLOT" snmpType="OID">
</ClassDefinition>
<ClassDefinition snmpOID="1.3.12.2.1011.2.22.1.205" ID="205"
name="CARD" snmpType="OID">
193
</ClassDefinition>
<ClassDefinition snmpOID="1.3.12.2.1011.2.22.1.206" ID="206"
name="PORT" snmpType="OID">
</ClassDefinition>
<ClassDefinition snmpOID="1.3.12.2.1011.2.22.1.207" ID="207"
name="FAN" snmpType="OID">
</ClassDefinition>
<ClassDefinition snmpOID="1.3.12.2.1011.2.22.1.208" ID="208"
name="POWER_SUPPLY" snmpType="OID"
>
</ClassDefinition>
</EntityModel>
The following figure outlines the TeMIP Entity Model for this default file (Please not
that these classes are instanceless. IP, ICMP, TCP, UDP, EGP, SNMP and
ENTERPRISES):
194
Figure 32
A representation of the default Entity Model
195
Appendix C
Launch Generation Tool
The default Launch Generation Tool Template is called
/usr/opt/temip/TNT/toolkit/LGT_Template/TeMIPTNT_Templa
te_SetupLaunch.conf
Syntax is based on the Configuration Files syntax. This template file contains
“launch” blocks which have to be compliant with the launched configuration file
format
Example 96 The default launch generation tool template
#LOCALE=.
###################################################################
##
## Configuration filename:
TeMIPTNT_NNMi_NODE_V1_PerfVol_SetupLaunch.conf
## User
: TeMIP
##
###################################################################
[ LAUNCH0 ]
SHOW_IN_MB3MENU = False
ARGUMENTS = @LaunchNNMView nnmStatus 15_154_72_122
PerfVol_nnm_conf
SYNO_TAG = TEDISPLAY
SMALLBMP =
MULTIINSTANCE = True
MB3_ONLY_FOR_ENTITY = False
LARGEBMP =
SUBMENU = NNMi IP Views\nNNMi platform status testing
INITDIR =
COMMAND = %TEMIP_CLIENT_HOME%\TNT.tpi
WAIT = False
INVERT = False
SHOW_AS_ICON = False
SHOW_IN_MENU = True
NBATTRIBUT = 0
HIDE_VALUE = False
SHOW_IN_TOOLBAR = False
NBENTITYCLASS = 0
NAME = tfriat12.ind.hp.com (on director PerfVol_nnm_conf)
NBPLUGIN = 0
AUTOSTART = False
SHOW = 1
MB3_ALSO_SUB_ENTITIES = False
SMALLICON =
SYNO_USE = False
[ End LAUNCH0 ]
[ LAUNCH1 ]
SHOW_IN_MB3MENU = False
ARGUMENTS = @LaunchNNMView nnmConsole 15_154_72_122
PerfVol_nnm_conf
SYNO_TAG = TEDISPLAY
SMALLBMP =
MULTIINSTANCE = True
196
MB3_ONLY_FOR_ENTITY = False
LARGEBMP =
SUBMENU = NNMi IP Views\nConsole (Network Overview)
INITDIR =
COMMAND = %TEMIP_CLIENT_HOME%\TNT.tpi
WAIT = False
INVERT = False
SHOW_AS_ICON = False
SHOW_IN_MENU = True
NBATTRIBUT = 0
HIDE_VALUE = False
SHOW_IN_TOOLBAR = False
NBENTITYCLASS = 0
NAME = tfriat12.ind.hp.com (on director PerfVol_nnm_conf)
NBPLUGIN = 0
AUTOSTART = False
SHOW = 1
MB3_ALSO_SUB_ENTITIES = False
SMALLICON =
SYNO_USE = False
[ End LAUNCH1 ]
[ LAUNCH2 ]
SHOW_IN_MB3MENU = False
ARGUMENTS = @LaunchNNMView routersView 15_154_72_122
PerfVol_nnm_conf
SYNO_TAG = TEDISPLAY
SMALLBMP =
MULTIINSTANCE = True
MB3_ONLY_FOR_ENTITY = False
LARGEBMP =
SUBMENU = NNMi IP Views\nRouters View
INITDIR =
COMMAND = %TEMIP_CLIENT_HOME%\TNT.tpi
WAIT = False
INVERT = False
SHOW_AS_ICON = False
SHOW_IN_MENU = True
NBENTITYCLASS = 0
NBATTRIBUT = 0
HIDE_VALUE = False
SHOW_IN_TOOLBAR = False
NAME = tfriat12.ind.hp.com (on director PerfVol_nnm_conf)
NBPLUGIN = 0
AUTOSTART = False
SHOW = 1
MB3_ALSO_SUB_ENTITIES = False
SMALLICON =
SYNO_USE = False
[ End LAUNCH2 ]
[ LAUNCH3 ]
SHOW_IN_MB3MENU = False
ARGUMENTS = @LaunchNNMView switchesView 15_154_72_122
PerfVol_nnm_conf
SYNO_TAG = TEDISPLAY
SMALLBMP =
MULTIINSTANCE = True
MB3_ONLY_FOR_ENTITY = False
LARGEBMP =
SUBMENU = NNMi IP Views\nSwitches View
INITDIR =
COMMAND = %TEMIP_CLIENT_HOME%\TNT.tpi
197
WAIT = False
INVERT = False
SHOW_AS_ICON = False
SHOW_IN_MENU = True
NBENTITYCLASS = 0
NBATTRIBUT = 0
HIDE_VALUE = False
SHOW_IN_TOOLBAR = False
NAME = tfriat12.ind.hp.com (on director PerfVol_nnm_conf)
NBPLUGIN = 0
AUTOSTART = False
SHOW = 1
MB3_ALSO_SUB_ENTITIES = False
SMALLICON =
SYNO_USE = False
[ End LAUNCH3 ]
[ LAUNCH4 ]
SHOW_IN_MB3MENU = False
ARGUMENTS = @LaunchNNMView nodesView 15_154_72_122
PerfVol_nnm_conf
SYNO_TAG = TEDISPLAY
SMALLBMP =
MULTIINSTANCE = True
MB3_ONLY_FOR_ENTITY = False
LARGEBMP =
SUBMENU = NNMi IP Views\nInventory Nodes View
INITDIR =
COMMAND = %TEMIP_CLIENT_HOME%\TNT.tpi
WAIT = False
INVERT = False
SHOW_AS_ICON = False
SHOW_IN_MENU = True
NBENTITYCLASS = 0
NBATTRIBUT = 0
HIDE_VALUE = False
SHOW_IN_TOOLBAR = False
NAME = tfriat12.ind.hp.com (on director PerfVol_nnm_conf)
NBPLUGIN = 0
AUTOSTART = False
SHOW = 1
MB3_ALSO_SUB_ENTITIES = False
SMALLICON =
SYNO_USE = False
[ End LAUNCH4 ]
[ LAUNCH5 ]
SHOW_IN_MB3MENU = False
ARGUMENTS = @LaunchNNMView pathAnalyticView 15_154_72_122
PerfVol_nnm_conf
SYNO_TAG = TEDISPLAY
SMALLBMP =
MULTIINSTANCE = True
MB3_ONLY_FOR_ENTITY = False
LARGEBMP =
SUBMENU = NNMi IP Views\nPath View
INITDIR =
COMMAND = %TEMIP_CLIENT_HOME%\TNT.tpi
WAIT = False
INVERT = False
SHOW_AS_ICON = False
SHOW_IN_MENU = True
NBENTITYCLASS = 0
198
NBATTRIBUT = 0
HIDE_VALUE = False
SHOW_IN_TOOLBAR = False
NAME = tfriat12.ind.hp.com (on director PerfVol_nnm_conf)
NBPLUGIN = 0
AUTOSTART = False
SHOW = 1
MB3_ALSO_SUB_ENTITIES = False
SMALLICON =
SYNO_USE = False
[ End LAUNCH5 ]
[ LAUNCH6 ]
SHOW_IN_MB3MENU = False
ARGUMENTS = @LaunchNNMView allIncidentsView 15_154_72_122
PerfVol_nnm_conf
SYNO_TAG = TEDISPLAY
SMALLBMP =
MULTIINSTANCE = True
MB3_ONLY_FOR_ENTITY = False
LARGEBMP =
SUBMENU = NNMi IP Views\nAll Incidents View
INITDIR =
COMMAND = %TEMIP_CLIENT_HOME%\TNT.tpi
WAIT = False
INVERT = False
SHOW_AS_ICON = False
SHOW_IN_MENU = True
NBENTITYCLASS = 0
NBATTRIBUT = 0
HIDE_VALUE = False
SHOW_IN_TOOLBAR = False
NAME = tfriat12.ind.hp.com (on director PerfVol_nnm_conf)
NBPLUGIN = 0
AUTOSTART = False
SHOW = 1
MB3_ALSO_SUB_ENTITIES = False
SMALLICON =
SYNO_USE = False
[ End LAUNCH6 ]
[ LAUNCH7 ]
SHOW_IN_MB3MENU = True
ARGUMENTS = @LaunchContextualNNMView layer2NeighborView
<TARGET_ENTITIES>
SYNO_TAG = TEDISPLAY
SMALLBMP =
MULTIINSTANCE = True
MB3_ONLY_FOR_ENTITY = True
LARGEBMP =
SUBMENU = NNMi IP Views
INITDIR =
COMMAND = %TEMIP_CLIENT_HOME%\TNT.tpi
WAIT = False
INVERT = False
SHOW_AS_ICON = False
SHOW_IN_MENU = False
NBATTRIBUT = 0
HIDE_VALUE = False
SHOW_IN_TOOLBAR = False
NBENTITYCLASS = 22
ENTITYCLASSID0 = 2010.1
ENTITYCLASSID1 = 2010.2
199
ENTITYCLASSID2 = 2010.4
ENTITYCLASSID3 = 2010.5
ENTITYCLASSID4 = 2010.6
ENTITYCLASSID5 = 2010.7
ENTITYCLASSID6 = 2010.8
ENTITYCLASSID7 = 2010.14
ENTITYCLASSID8 = 2010.15
ENTITYCLASSID9 = 2010.11
ENTITYCLASSID10 = 2010.17
ENTITYCLASSID11 = 2010.68
ENTITYCLASSID12 = 2010.16
ENTITYCLASSID13 = 2010.201
ENTITYCLASSID14 = 2010.202
ENTITYCLASSID15 = 2010.203
ENTITYCLASSID16 = 2010.204
ENTITYCLASSID17 = 2010.205
ENTITYCLASSID18 = 2010.206
ENTITYCLASSID19 = 2010.207
ENTITYCLASSID20 = 2010.208
ENTITYCLASSID21 = 2010
NAME = Layer2 Neighbor View
NBPLUGIN = 3
PLUGIN0 = MapViewer
PLUGIN1 = RealTimeAH
PLUGIN2 = HistoryAH
AUTOSTART = False
SHOW = 1
MB3_ALSO_SUB_ENTITIES = False
SMALLICON =
SYNO_USE = False
[ End LAUNCH7 ]
[ LAUNCH8 ]
SHOW_IN_MB3MENU = True
ARGUMENTS = @LaunchContextualNNMView layer3NeighborView
<TARGET_ENTITIES>
SYNO_TAG = TEDISPLAY
SMALLBMP =
MULTIINSTANCE = True
MB3_ONLY_FOR_ENTITY = True
LARGEBMP =
SUBMENU = NNMi IP Views
INITDIR =
COMMAND = %TEMIP_CLIENT_HOME%\TNT.tpi
WAIT = False
INVERT = False
SHOW_AS_ICON = False
SHOW_IN_MENU = False
NBATTRIBUT = 0
HIDE_VALUE = False
SHOW_IN_TOOLBAR = False
NBENTITYCLASS = 22
ENTITYCLASSID0 = 2010.1
ENTITYCLASSID1 = 2010.2
ENTITYCLASSID2 = 2010.4
ENTITYCLASSID3 = 2010.5
ENTITYCLASSID4 = 2010.6
ENTITYCLASSID5 = 2010.7
ENTITYCLASSID6 = 2010.8
ENTITYCLASSID7 = 2010.14
ENTITYCLASSID8 = 2010.15
ENTITYCLASSID9 = 2010.11
200
ENTITYCLASSID10 = 2010.17
ENTITYCLASSID11 = 2010.68
ENTITYCLASSID12 = 2010.16
ENTITYCLASSID13 = 2010.201
ENTITYCLASSID14 = 2010.202
ENTITYCLASSID15 = 2010.203
ENTITYCLASSID16 = 2010.204
ENTITYCLASSID17 = 2010.205
ENTITYCLASSID18 = 2010.206
ENTITYCLASSID19 = 2010.207
ENTITYCLASSID20 = 2010.208
ENTITYCLASSID21 = 2010
NAME = Layer3 Neighbor View
NBPLUGIN = 3
PLUGIN0 = MapViewer
PLUGIN1 = RealTimeAH
PLUGIN2 = HistoryAH
AUTOSTART = False
SHOW = 1
MB3_ALSO_SUB_ENTITIES = False
SMALLICON =
SYNO_USE = False
[ End LAUNCH8 ]
[ LAUNCH9 ]
SHOW_IN_MB3MENU = True
ARGUMENTS = @LaunchContextualNNMView nodeForm <TARGET_ENTITIES>
SYNO_TAG = TEDISPLAY
SMALLBMP =
MULTIINSTANCE = True
MB3_ONLY_FOR_ENTITY = True
LARGEBMP =
SUBMENU = NNMi IP Views
INITDIR =
COMMAND = %TEMIP_CLIENT_HOME%\TNT.tpi
WAIT = False
INVERT = False
SHOW_AS_ICON = False
SHOW_IN_MENU = False
NBATTRIBUT = 0
HIDE_VALUE = False
SHOW_IN_TOOLBAR = False
NBENTITYCLASS = 22
ENTITYCLASSID0 = 2010.1
ENTITYCLASSID1 = 2010.2
ENTITYCLASSID2 = 2010.4
ENTITYCLASSID3 = 2010.5
ENTITYCLASSID4 = 2010.6
ENTITYCLASSID5 = 2010.7
ENTITYCLASSID6 = 2010.8
ENTITYCLASSID7 = 2010.14
ENTITYCLASSID8 = 2010.15
ENTITYCLASSID9 = 2010.11
ENTITYCLASSID10 = 2010.17
ENTITYCLASSID11 = 2010.68
ENTITYCLASSID12 = 2010.16
ENTITYCLASSID13 = 2010.201
ENTITYCLASSID14 = 2010.202
ENTITYCLASSID15 = 2010.203
ENTITYCLASSID16 = 2010.204
ENTITYCLASSID17 = 2010.205
ENTITYCLASSID18 = 2010.206
201
ENTITYCLASSID19 = 2010.207
ENTITYCLASSID20 = 2010.208
ENTITYCLASSID21 = 2010
NAME = Node Form
NBPLUGIN = 3
PLUGIN0 = MapViewer
PLUGIN1 = RealTimeAH
PLUGIN2 = HistoryAH
AUTOSTART = False
SHOW = 1
MB3_ALSO_SUB_ENTITIES = False
SMALLICON =
SYNO_USE = False
[ End LAUNCH9 ]
[ General ]
NumberLaunch = 10
Version = 6.1
[ End General ]
202
Appendix D
Launch Applications Configuration
File Format
The Launched Applications configuration file will use the TeMIP Client
configuration file syntax.
A Launched Application description uses a configuration file section beginning with
the keyword “LAUNCH ##” and ending with the keyword “End LAUNCH ##”,
where “##” is the Launch number.
Between those two keywords is the Launched Application definition.
Following are all the keywords used to fully define a launch in a launch definition file
(“.conf”):
Table 33
Name
The launch definition file grammar
Description
NAME
Mandatory. The Launch Name. Used in the “Launch Application”
dialog and for the Launch menu (main menu and popup menu).
COMMAND
The launched application (.exe), plug-in (.tpi) or Dynamic Linked
Library (.dll).
NBPLUGIN
The number of selected plug-ins
PLUGIN##
##: Not Mandatory. The launch attached plug-in name. If the
argument is not present the Launch will be defined as a general
Launch. As for the LAUNCH keyword, the chars “##” represent a
number. To define attached plug-in see the sample below.
ARGUMENTS
The Launch command line. The command line can contain
common arguments.
INITDIR
The initial directory the launch starts in. If the argument is not
present, the initial directory will be the current directory.
MULTIINSTANCE
False: The Launch will not be multi-instance. (Default)
True: The Launch will be multi-instance.
AUTOSTART
False: the Launch will not be started automatically at start-up.
(Default)
True: the Launch will be started automatically at start-up.
SYNO-USE
The group of synonyms to be translated.
False: translation will not be performed. (Default)
True: translation will be performed.
SYNO_TAG
Synonym tag used.
203
Name
SHOW_IN_MENU
Description
False: The launch will not be displayed in the menu bar.
True: The launch will be displayed in the menu bar. (Default)
SHOW_IN_MB3MENU
False: The launch will not be displayed in the popup menu.
(Default)
True: The launch will be displayed in the popup menu.
MB3_ONLY_FOR_ENTITY
False: The launch will be displayed in the entire popup menu.
(Default)
True: The launch will be displayed in the popup menu only for the
classes attached to the launch.
SUBMENU
Name of the sub-menu the launch will be displayed in.
SHOW_IN_TOOLBAR
False: The launch will not be displayed in the toolbars.
True: The launch will be displayed in the toolbars. (Default)
SMALLBMP
LARGEBMP
The keywords SMALLBMP and LARGEBMP take the file name
and location of the icons used for display in the toolbar.
NBENTITYCLASS
The number of attached entities
ENTITYCLASSID
This keyword takes the class ID of the class attached to the launch.
Since class IDs are unique only at a specific level of the class
hierarchy, the all path of the class must be specified using class IDs
separated by the ‘.’ char.
The format is as follows:
ENTITYCLASSID = ClassId.ClassId
NBATTRIBUT
The number of attached arguments and attributes.
ATTRIBID
This keyword takes the attribute ID the launch is attached to. For
the same reason as the ENTITYCLASS keyword, the all class path
must be specified, plus the directive ID.
The format is as follows:
ATTRIBID = ClassId.ClassId,DirectiveId,AttributId
SHOW_AS_ICON
False: The launch will not be displayed as an icon button in the
Management View but as a text button.
True: The launch will be displayed as an icon button in the
Management View.
SMALLICON
204
The keywords SMALLICON takes the file name and location of the
icons used for display in the Management View
Appendix E
TNT Plug-in System Configuration
File Format
The following format will be used to store information for the TNT Plug-in. These
resources are stored per workspace:
 Version of configuration file
 Information per NNM Views (URL, web browser options, etc)
E.1 Versioning
Table 34
TNT configuration versioning
Resource
Description
Syntax
Version
Version of the TNT configuration file
[ General ]
Version = 6.1
[ End General ]
E.2 General Resources
Table 35
TNT configuration general resources
Resource
Description
Syntax
Refresh
Timer Value
Value of timer used in TNT
Property Page when refreshing
NNM Configuration in ms.
[General]
Refresh Timer Value = 500
[ End General]
Default Value : 500 ms
E.3 Alarm Object Custom Fields
Table 36
Alarm Object custom fields
Resource
Description
Syntax
Correlated Event Flag
Custom Correlated Event Flag
ID value
[ AO Custom Fields ]
If not defined or Null, default
value is 10012.
Parent Correlated Alarm
ID
Custom Correlated Alarm ID
value
If not defined or Null, default
value is 10002.
Correlated Event Flag = 10012
[ End AO Custom Fields ]
[ AO Custom Fields ]
Parent Correlated Alarm ID =
10002
[ End AO Custom Fields ]
205
E.4 NNMi Views Resources
We need to store the number of NNMi views defined in the file.
Table 37
Resources for the NNMi views
Resource
Description
Syntax
Number of
Views
Number of Views defined in the file
[ Dynamic Views ]
Number of Views = 24
[ End Dynamic Views ]
View
Name of the Views.
[ Dynamic Views ]
View0 = Name
Possible values:
206

neighborView

internetView

stationView

networkView

vlanView

ospfView

hsrpView

dupipView

probDiagView

pathView

nodeView

segmentView

interfaceView

containerView

nnmConsole

routersView

switchesView

nodesView

allIncidentView

layerNeighborView

layer3NeighbourView

pathAnalyticView

nodeForm

nnmStatus
[ End Dynamic Views ]
Where Name is the name of the
NNMi View (ex: nodeView,
neighborView …)
And for each view (the Dynamic NNM View neighborView has been used follow):
Table 38
NNMi Dynamic views
Resource
Description
Syntax
External
Web
Browser
Launch a external default browser or
use the internal plug-in Web
Browser
[ neighborView ]
ExternalWebBrowser = True |
False
[ End neighborView ]
By default: use internal Web
Browser plug-in.
OpenInNew
Open the Web Browser in a new
window.
[ neighborView ]
OpenInNew = True | False
[ End neighborView ]
By default: open in already opened
web browser if exist, otherwise open
a new one.
*** Internal Web Browser only ***
URL
Pattern of an URL to compute
replacing possible keyword:
<NNM_PROTOCOL>
[ neighborView ]
URL=
[ End neighborView ]
<NNM_HOST>
<NNM_PORT>
<NNM_STATION>
<NNM_IP_ADDRESS>
<NNM_NODE1>
<NNM_NODE2>
<UUID>
<TITLE>
…
<NNM_NODEn>
<DESKTOP_ID>: this keyword is
resolved by WebBrowser Plug-in.
HomePage
URL for the starting page (optional)
This specific web browser page will
be displayed when launching a Web
browser views before navigating. It
could be a page to wait a response
from the web server. It will not
affect the home page defined in
internet explorer (setting options)
[ neighborView ]
HomePage =
%TEMIP_CLIENT_HOME%\WebBo
rwser\pagestart.html
[ End neighborView ]
*** Internal Web Browser only ***
207
Resource
Description
2093B
Syntax
ErrorPage
2094B
186B
URL for the error navigation page
(optional)
2095B
[ neighborView ]
187B
1890B
ErrorPage =
189B
%TEMIP_CLIENT_HOME%\WebBr
owser\pageerror.html
This specific web browser page will
be displayed in case of navigation
error. By default, the web browser
will display the usual error page:
11004 - Host not found
18B
HU
U
[ End neighborView ]
1892B
*** Internal Web Browser only ***
189B
ContextualVie
w
Indicate if the View is contextual or
no
1893B
[ neighborView ]
1894B
1897B
ContextualView = True |
189B
False
Default value: False
1895B
[ End neighborView ]
189B
*** Internal Web Browser only ***
1896B
StatusBar
Display or hide the status bar
(optional).
190B
[ neighborView ]
190B
1904B
StatusBar = True | False
1905B
Default value: False.
[ End neighborView ]
1902B
1906B
*** Internal Web Browser only ***
1903B
AddressBar
Display or hide the address toolbar
(optional).
1907B
[ neighborView ]
1908B
19B
AddressBar = True | False
192B
Default value: False.
[ End neighborView ]
190B
193B
*** Internal Web Browser only ***
190B
MB3Menu
Display or hide the MB3 menu in
the web browser page (optional).
194B
[ neighborView ]
195B
198B
MB3Menu = True | False
19B
Default value: False.
[ End neighborView ]
196B
1920B
*** Internal Web Browser only ***
197B
208
Resource
Description
2093B
Syntax
Mb3MenuStyl
e
2094B
192B
Optional and active only if
MB3Menu=True.
2095B
[ neighborView ]
192B
1936B
MB3MenuStyle = 0x15
1937B
Define the style of the MB3Menu
and feature supported
[ End neighborView ]
1923B
1938B
Two formats are supported:
1924B
Hexa (i.e. 0xFF)
1925B
Number (i.e 15).
1926B
By default: all options are ignored.
1927B
Note: In case of invalid style format
(not hexa/number), all options are
enabled.
1928B
Available MB3 menu styles:
192B
0x00000001: Style for display
HTML MB3 menu,
1930B
0x00000002: Style for display
Launches menus in MB3 menu if
any,
193B
0x00000004: Style for display
Directives associated to the selected
TeMIP Entities in MB3 menu if any,
1932B
0x00000000: Style for display no
MB3 menu,
193B
0xFFFFFFFF: Style for display all
MB3 menus.
1934B
*** Internal Web Browser only ***
1935B
ToolBar
Display or hide the toolbar
(optional).
193B
[ neighborView ]
1940B
1943B
ToolBar = True | False
194B
Default value: False.
[ End neighborView ]
194B
1945B
*** Internal Web Browser only ***
1942B
209
Resource
Description
2093B
Syntax
ToolBarStyle
2094B
1946B
Optional and active only if
Toolbar=True
2095B
[ neighborView ]
1947B
1970B
ToolBarStyle = 0X00000200
197B
Define the style of the toolbar and
feature supported.
[ End neighborView ]
1948B
Two formats are supported:
194B
Hexa (i.e. 0xFF)
1950B
Number (i.e 15).
195B
By default: all options are ignored.
1952B
Note: In case of invalid style format
(not hexa/number), all options are
enabled.
1953B
Available Toolbar styles:
51B94
0x00000001: Style for display Back
button,
195B
0x00000002: Style for display
Forward button,
1956B
0x00000004: Style for display Stop
button,
1957B
0x00000008: Style for display
Refresh button,
1958B
0x00000010: Style for display Home
button,
195B
0x00000020: Style for display
Search button,
1960B
0x00000040: Style for display
Favorites button,
196B
0x00000080: Style for display Print
button,
1962B
0x00000100: Style for display Font
button,
1963B
0x00000200: Style for display
Animate control,
1964B
0x00000400: Style for display small
toolbar buttons,
1965B
0x00000800: Style for display text
associated with toolbar buttons,
196B
0x00000000: Style for display no
button,
1967B
0xFFFFFFFF: Style for display all
buttons and animate control.
1968B
*** Internal Web Browser only ***
196B
210
1972B
Resource
Description
2093B
Syntax
AutoLoad
2094B
2095B
When loading a workspace, this
Web Browser window will be
automatically reloaded (optional).
1973B
[ neighborView ]
1974B
197B
AutoLoad = True | False
1978B
[ End neighborView ]
197B
By default: Manual reloading using
a hyperlink.
1975B
*** Internal Web Browser only ***
1976B
IconFile
Icon file (.ico) to display in Web
Browser window (optional).
1980B
[ neighborView ]
198B
1983B
IconFile =
1984B
%TEMIP_CLIENT_HOME%\myIcon
HU
*** Internal Web Browser only ***
UH
.ico
1982B
[ End neighborView ]
1985B
Title
Display using a specific title for the
Web Browser window (optional).
1986B
[ neighborView ]
1987B
190B
Title = My WebBrowser Title
19B
[ End NeighborView ]
192B
Default value: “Internal Web
Browser”
198B
*** Internal Web Browser only ***
198B
211
Glossary
356B
Access Module (AM)
5193B
TeMIP is a total solution for the integrated management of telecommunication
networks. It is a suite of integrated software modules that enables network
administrators to monitor, control and test manageable network elements. TeMIP can
be applied to any network from small homogeneous local area networks to enterprise
wide, heterogeneous distributed network environments. TeMIP interfaces with
network elements, such as switches, multiplexers and repeaters, through Access
Modules (AMs). Multi-protocol support is provided by using different AMs,
depending on the protocol used by the network elements.
5194B
Customization
519B
The term customization encompasses the process and all various information which
are required in order to integrate a new device/service managed through NNM into
TeMIP.
5196B
The customization provides specific rules for the Event management and the
Topology management of this Managed Entity.
5197B
Event rules focus on which MIB traps are managed, which mapping is defined for
each of them,…
5198B
Topology rules focus on which entities are managed by this custom, how are they
named, populated…
519B
The Customization file has XML format.
520B
NNMi Filter
5201B
Extended Topology discovers different devices connected to your network
infrastructure, including routers, switches, computers, and even certain
subcomponents of these devices, like SNMP interfaces. Your managed environment
may be relatively small or quite large. By using Extended Topology Filters, you can
interact with subsets of your network, to more effectively and efficiently manage this
valuable resource. There are several ways of selecting an appropriate subset of your
devices:
520B
 Node or Interface Capabilities
5203B
 Products from a particular vendor
5204B
 DNS Node Names
520B
 Via Status level
5206B
 IP Addresses and Node Names
5207B
You can further limit your filter by combining several of the above.
5208B
Management Interface Base (MIB)
54B209
It is the SNMP Management Information Base. A logical database made up of the
configuration, status, and statistical information stored at a device. The various values
that can be retrieved from a MIB are called MIB variables. These variables are
defined in the MIB for a device. Each MIB variable is named by an Object Identifier
(OID), which usually has a name in the form of numbers separated by periods ("."),
5210B
212
like this: 1.3.6.1.xxxx.x.x.x.x... For example, the MIB-II has a variable that indicates
the number of interfaces (ports) in a router. It's called the "ifNumber", and its OID is
1.3.6.1.2.1.2.1.0
MIB-I and MIB-II
521B
MIB-I was the original standard MIB for SNMPv1. MIB-I contains a core set of
management variables that an SNMP agent must provide to an SNMP manager. This
set was later replaced and extended by MIB-II, which defines SNMPv2. These MIBs
include definitions related to the system, the interfaces, and the protocols used by the
SNMP agent. MIB-I and MIB-II are defined in the Internet Architecture Board
(formerly the Internet Activities Board) Request for Comments (RFC) 1156 and
1213, respectively.
521B
NNMi
5213B
The Network Node Manager is applications that helps a network administrator view
and manage the conditions in a computer network. NNM is part of the hp Software
suite of enterprise system management applications. Using the Network Node
Manager, an administrator can view the network in an easy-to-see graphical format.
NNM "discovers" the devices that are in the network and shows their relative location
and their status. When a device fails, NNM can analyze events associated with the
failure and help to recommend action. NNM also provides some predictive
information that helps identify potential failures before they occur.
5214B
OS Dependent Kit
521B
Runtime kit is a customization package OS independent that contains physically all
the information necessary to take this new equipment or service into account in each
level of the architecture. It is mainly composed of NNM Adapter part (Event and
Topology mapping and naming).
5216B
Runtime Kit
5217B
Runtime kit is a customization package OS independent that contains physically all
the information necessary to take this new equipment or service into account in each
level of the architecture. It is mainly composed of NNM Adapter part (Event and
Topology mapping/naming).
5218B
SNMP
5219B
SNMP stands for the Simple Network Management Protocol. At its heart, SNMP is a
set of rules that allows a computer to get statistics from another computer across the
Internet.
520B
TeMIP
521B
TeMIP stands for Telecommunications Management Information Platform TeMIP is
a platform that can handle multiple network management protocols in order to
manage telecommunications networks. Such networks rely partly on IP network
infrastructure, and TeMIP can provide IP network management capability, either
natively or through the integration of Network Node Manager.
52B
TeMIP Adapter
523B
The TeMIP Adapter is a component running on the NNM station. The NNM AM
contacts the TeMIP Adaptor to get the NNM information.
524B
TeMIP Director
52B
A machine in a distributed TeMIP configuration is known as a director. Any machine
that runs TeMIP can be called a director, but the term only really comes into its own
when a distributed configuration is considered. A director makes the services of the
526B
213
management modules (MMs) that it supports available to its peers. The director is
itself modeled as an entity and as such is manageable according to TeMIP principles.
Each Director Entity instance has a globally unique name. In a distributed
configuration, directors make service requests to, and receive events from, other
directors. Any one TeMIP system sees itself as the local director, potentially
interacting with multiple remote directors. Each remote director is also modeled as an
entity, and as such is manageable according to TeMIP principles. Indeed, the
existence of a Remote Director Entity instance is what makes a remote TeMIP
system, and more importantly, its services, available to the local director.
TeMIP Domain
527B
The Domain concept allows the grouping of managed objects. Domains are subsets of
the managed object configuration that can be based on: equipment type (all switches,
multiplexers, TCP/IP hosts...), geographical criteria (all objects within a region, site,
or subnet), personnel levels, or any other user-defined criteria. Domains can contain
or refer to other domains and can be hierarchical or overlapping. Individual managed
objects can be contained within multiple domains. Each domain is associated with
one Director. The grouping of entities within domains is mandatory for the use of
many applications (event collection, state collection, rules, and scheduler).
528B
TeMIP Managed Object
529B
A TeMIP entity is used to represent any physical or logical object that can be
managed by TeMIP. The entity class specifies the attributes and the operations
associated to this object. The entity instance stands for the actual managed object.
5230B
TeMIP Model (Entity)
5231B
The TeMIP Framework architecture is based upon the notion of a dynamic, extensible
network model. In TeMIP Framework, every manageable object in the network can
be described in terms of its own unique entity model. The total of all the entity
models is the TeMIP Framework management model. Unlike architectures in which
members of entity classes must be made to fit one of several preconceived models of
operation, TeMIP Framework architecture allows a model to be defined for an entity
that reflects its real nature. Based on the OSI approach, entities can be related in
several ways. Some entities are subordinate to others for name binding purposes,
these are called child entities. Some entities may be derived from others by the
mechanism of inheritance. Some entities may be functionally related. Each global
entity, and any child entity it contains, typically supports a number of management
operations, such as SHOW (for determining the value of one or more attributes, or
indicators of internal state); SET (for setting the value of attributes with changing
values); ENABLE (for putting the entity into service); and so on. These operations
are applied either to a set of the entity's attributes (SET, SHOW), or to the entity as a
whole (ENABLE). As well as being the targets of management operations on
themselves or their attributes, entities may generate asynchronous event reports.
523B
TeMIP NNM AM Clone
523B
TeMIP Access Module dedicated to collect NNMi information corresponding to a
specific Customization.
5234B
TeMIP NNM AM Master
523B
TeMIP Access Module dedicated to collect information from NNMi stations. It is in
charge of:
5236B
 Manages a default TeMIP model used to represent all entities discovered by
NNM (Global Class: NODE) without any customization
5237B
 Manages the configuration of the different NNM stations
5238B
214
Download PDF
Similar pages