CA Spectrum - 10.2 and 10.2.1 - ENU - Customizing - 20170403 PDF

CA Spectrum - 10.
2
and 10.2.1
Customizing
Date: 03-Apr-2017
CA Spectrum - 10.2 and 10.2.1
This Documentation, which includes embedded help systems and electronically distributed materials, (hereinafter referred to as
the Documentation) is for your informational purposes only and is subject to change or withdrawal by CA at any time. This
Documentation is proprietary information of CA and may not be copied, transferred, reproduced, disclosed, modified or
duplicated, in whole or in part, without the prior written consent of CA.
If you are a licensed user of the software product(s) addressed in the Documentation, you may print or otherwise make
available a reasonable number of copies of the Documentation for internal use by you and your employees in connection with
that software, provided that all CA copyright notices and legends are affixed to each reproduced copy.
The right to print or otherwise make available copies of the Documentation is limited to the period during which the applicable
license for such software remains in full force and effect. Should the license terminate for any reason, it is your responsibility to
certify in writing to CA that all copies and partial copies of the Documentation have been returned to CA or destroyed.
TO THE EXTENT PERMITTED BY APPLICABLE LAW, CA PROVIDES THIS DOCUMENTATION AS IS WITHOUT WARRANTY OF ANY
KIND, INCLUDING WITHOUT LIMITATION, ANY IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR
PURPOSE, OR NONINFRINGEMENT. IN NO EVENT WILL CA BE LIABLE TO YOU OR ANY THIRD PARTY FOR ANY LOSS OR DAMAGE,
DIRECT OR INDIRECT, FROM THE USE OF THIS DOCUMENTATION, INCLUDING WITHOUT LIMITATION, LOST PROFITS, LOST
INVESTMENT, BUSINESS INTERRUPTION, GOODWILL, OR LOST DATA, EVEN IF CA IS EXPRESSLY ADVISED IN ADVANCE OF THE
POSSIBILITY OF SUCH LOSS OR DAMAGE.
The use of any software product referenced in the Documentation is governed by the applicable license agreement and such
license agreement is not modified in any way by the terms of this notice.
The manufacturer of this Documentation is CA.
Provided with Restricted Rights. Use, duplication or disclosure by the United States Government is subject to the restrictions
set forth in FAR Sections 12.212, 52.227-14, and 52.227-19(c)(1) - (2) and DFARS Section 252.227-7014(b)(3), as applicable, or
their successors.
Copyright 2017 CA. All rights reserved. All trademarks, trade names, service marks, and logos referenced herein belong to
their respective companies.
03-Apr-2017 3/311
Table of Contents
Modeling Gateway Toolkit ......................................................................... 12

Modeling Gateway support for Wireless Devices ...................................................................................... 12
Modeling Gateway Prerequisites ............................................................................................................... 13
Import and Export Architecture .................................................................................................................. 14
Import Architecture .............................................................................................................................. 14
Export Architecture .............................................................................................................................. 15
Import Topology Data into CA Spectrum ................................................................................................... 16
Format the Data in an Input File .......................................................................................................... 17
XML Input Files .......................................................................................................................... 17
XML Input File Syntax ................................................................................................................ 19
Comma-Delimited Input Files ..................................................................................................... 31
Comma-Delimited Input File Syntax ........................................................................................... 32
Run the modelinggateway Tool for Import .......................................................................................... 32
Import a Single File .................................................................................................................... 32
Import Multiple Files ................................................................................................................... 33
ImportConfiguration Element ............................................................................................................... 34
Import Comma-Delimited Files ............................................................................................................ 34
View Import Information ...................................................................................................................... 35
View Modeling Gateway Results in OneClick ............................................................................ 35
Error Log .................................................................................................................................... 36
Export Topology Data from CA Spectrum ................................................................................................. 37
Configure Export Settings ................................................................................................................... 38
ExportConfiguration Element .............................................................................................................. 38
The modelinggateway Tool for Export ................................................................................................ 40
Export CA Spectrum Topology Data .......................................................................................... 41
Import Modeling Gateway XML file ............................................................................................ 42
Appendix A: Document Type Definition Elements ..................................................................................... 42
Association .......................................................................................................................................... 43
Connection .......................................................................................................................................... 43
Correlation ........................................................................................................................................... 44
Correlation_Domain ............................................................................................................................ 45
CustomerManager ............................................................................................................................... 45
Destroy ................................................................................................................................................ 46
Device ................................................................................................................................................. 47
EventModel ......................................................................................................................................... 50
GenericView ........................................................................................................................................ 51
Customizing 4
GenericView_Container ...................................................................................................................... 51
GlobalCollection .................................................................................................................................. 52
Syntax ........................................................................................................................................ 52
Import .................................................................................................................................................. 53
Left_Model ........................................................................................................................................... 54
List_Value ........................................................................................................................................... 54
Location ............................................................................................................................................... 55
Location_Container ............................................................................................................................. 55
Model_Attr ........................................................................................................................................... 57
Model 1 ............................................................................................................................................... 57
MonitorPolicy_Attr ............................................................................................................................... 58
Port ...................................................................................................................................................... 58
Right_Model ........................................................................................................................................ 60
RTM_Test ........................................................................................................................................... 60
Schedule ............................................................................................................................................. 61
SM_AttrMonitor ................................................................................................................................... 64
SM_Customer ..................................................................................................................................... 64
SM_CustomerGroup ........................................................................................................................... 66
SM_Guarantee .................................................................................................................................... 66
SM_LatencyMon ................................................................................................................................. 67
SM_Service ......................................................................................................................................... 68
SM_Service_Mgt ................................................................................................................................. 69
SM_ServiceMgr ................................................................................................................................... 70
SM_SLA .............................................................................................................................................. 70
SM_SLA_Mgr ...................................................................................................................................... 71
Topology ............................................................................................................................................. 71
Topology_Container ............................................................................................................................ 72
Update ................................................................................................................................................. 74
Appendix B: Document Type Definition File .............................................................................................. 75
Appendix C: XML Examples ...................................................................................................................... 90
Example 1 Importing into the Topology View ...................................................................................... 91
Example 2 Creating Connections ........................................................................................................ 92
Example 3 Updating and Destroying ................................................................................................... 93
Example 4 Creating, Updating, and Destroying .................................................................................. 94
Appendix D: .modelinggatewayresource.xml ............................................................................................ 98
Model Type Editor ................................................................................... 107

Introducing the Model Type Editor .......................................................................................................... 107
CA Spectrum Modeling Concepts ........................................................................................................... 108
CA Spectrum and Model Type Editor ................................................................................................ 108
Model Types and Attributes .............................................................................................................. 109
Customizing 5
Models ............................................................................................................................................... 111
Relations and Meta-Rules ................................................................................................................. 112
Model Type Inheritance ..................................................................................................................... 114
Attribute Descriptors ................................................................................................................. 114
Standard Hierarchy .................................................................................................................. 116
Specialized Hierarchy .............................................................................................................. 117
Model Type Precedence .......................................................................................................... 119
Attribute Collapsing .................................................................................................................. 122
Getting Started with the Model Type Editor ............................................................................................. 123
Using a Developer ID ........................................................................................................................ 124
Access Privileges With Developer ID ....................................................................................... 125
SpectroSERVER Database Protection ............................................................................................. 126
Considerations on Database Migration ............................................................................................. 127
About Starting the Model Type Editor ............................................................................................... 127
Start Model Type Editor from the Control Panel ...................................................................... 127
Start Model Type Editor from the Command Line .................................................................... 128
Overview of the User Interface .......................................................................................................... 128
Commit Changes to the SpectroSERVER Database ........................................................................ 129
Sorting and Filtering Lists .................................................................................................................. 130
Add and Remove Columns from Tables ........................................................................................... 131
Exit the Model Type Editor ................................................................................................................ 131
Creating and Modifying Model Types ...................................................................................................... 132
Creating and Modifying Model Types ................................................................................................ 132
Attributes of Model Types ........................................................................................................................ 132
Developer ID ..................................................................................................................................... 133
Model Type Name ............................................................................................................................. 133
Model Type ID (Handle) .................................................................................................................... 133
Base Model Types ............................................................................................................................ 134
Derived Model Types ........................................................................................................................ 134
Model Type Flags .............................................................................................................................. 134
Custom Attributes .............................................................................................................................. 136
Standard Attribute Descriptors ................................................................................................................ 137
Standard Attribute Descriptors .......................................................................................................... 137
Developer ID ..................................................................................................................................... 138
Attribute Name .................................................................................................................................. 138
Attribute ID (Handle) ......................................................................................................................... 138
Type .................................................................................................................................................. 139
Flags ................................................................................................................................................. 139
Group Name and Group ID ............................................................................................................... 141
Special Attribute Descriptors ................................................................................................................... 141
Special Attribute Descriptors ............................................................................................................. 141
Default Value ..................................................................................................................................... 142
Customizing 6
Extended Flags ................................................................................................................................. 142
OID Prefix and OID Reference .......................................................................................................... 144
Polling Group .................................................................................................................................... 145
Search for and Display Model Types ...................................................................................................... 146
Search for and Display Attributes ............................................................................................................ 146
Create a Model Type ............................................................................................................................... 147
Delete a Model Type ............................................................................................................................... 148
Working with Base Model Types ............................................................................................................. 150
How to Determine the Base Model Types for a New Model Type .................................................... 150
Add a Base Model Type to a Model Type ......................................................................................... 151
Remove a Base Model Type from a Model Type .............................................................................. 152
Import MIBs ............................................................................................................................................. 153
Using the Model Type Editor to import a MIB into a model type. ...................................................... 154
Set Model Type Flags ............................................................................................................................. 155
Working with Attributes ............................................................................................................................ 156
Add an Attribute to a Model Type ...................................................................................................... 156
Remove an Attribute from a Model Type .......................................................................................... 158
Edit an Attribute ................................................................................................................................. 159
Modify an Attribute's Default Value .......................................................................................... 159
Modify an Attribute's Descriptors ............................................................................................. 160
Working with Attribute Groups ................................................................................................................. 161
Working with Attribute Groups .......................................................................................................... 161
Creating an Attribute Group .............................................................................................................. 161
Modifying an Attribute Group ............................................................................................................ 162
Deleting an Attribute Group ............................................................................................................... 164
Working with Relations and Meta-Rules ................................................................................................. 164
About Working with Relations and Meta-Rules ................................................................................. 165
Search for and Display Relations ...................................................................................................... 165
Create Relations ...................................................................................................................... 167
Relation Meta - Rules ............................................................................................................... 168
Delete Relations ....................................................................................................................... 170
Delete Meta - Rules ................................................................................................................. 170
Importing and Exporting Model Types ..................................................................................................... 171
About Importing and Exporting Model Types .................................................................................... 171
Import Model Types Using the Model Type Editor ............................................................................ 171
Import Constraints .................................................................................................................... 172
Import Model Types ................................................................................................................. 172
Export Model Types Using the Model Type Editor ............................................................................ 173
Import and Export Model Types Using dbtool ................................................................................... 175
Send an Exported Catalog to a File or Printer .................................................................................. 175
Running Reports on Model Types and Relations .................................................................................... 175
Customizing 7
About Running Reports on Model Types and Relations ................................................................... 176
OneClick Customization .......................................................................... 177

Prerequisites for Customizing OneClick XML Files ................................................................................. 177
Extend Factory XML Files ....................................................................................................................... 177
Override Factory Files ............................................................................................................................. 178
Inherit Features in Factory XML Files ..................................................................................................... 178
Example Extending Factory XML File ..................................................................................................... 178
OneClick Directory Structure ................................................................................................................... 179
Existing OneClick Files ..................................................................................................................... 180
The console/config Directory .................................................................................................... 180
Save Customized XML Files .................................................................................................... 181
Preserve XML Customizations ................................................................................................. 182
Preserve Custom Images ......................................................................................................... 182
Customizing the OneClick Login Dialog .................................................................................................. 182
Custom Login Message .................................................................................................................... 183
Add a Custom Message to the OneClick Login Dialog ..................................................................... 183
Customizing the OneClick Console Menu ............................................................................................... 183
The custom-menu-config.xml File ..................................................................................................... 184
Add a New Menu ............................................................................................................................... 186
Add a New Menu Item ....................................................................................................................... 187
Add Toolbar Images ................................................................................................................. 188
Define a Keyboard Accelerator ................................................................................................ 189
Perform an Action .................................................................................................................... 189
Display the Status of a Launched Application or Script ........................................................... 201
Customizing OneClick Alarms ................................................................................................................. 202
Customizing OneClick Tables ................................................................................................................. 203
Modify Table Columns ...................................................................................................................... 203
Extend a Factory Default File Using IDREF ............................................................................. 203
Modify a Table Column ............................................................................................................ 204
Define How Cells Display in Table Columns ..................................................................................... 208
TextAreaCellRenderer ............................................................................................................. 209
ListAttributeRenderer ............................................................................................................... 209
ListAttributeOIDRenderer ......................................................................................................... 210
ActionButtonCellRenderer ........................................................................................................ 210
ActionButtonPanelCellRenderer .............................................................................................. 211
AttrToggleButtonCellRenderer ................................................................................................. 211
BoldAttributeTableCellRenderer .............................................................................................. 212
Make a Table Column Editable ......................................................................................................... 212
Customize the Alarm Table Acknowledge Field ....................................................................... 212
Customizing 8
Display Instanced Attribute Values in Separate Table Rows ............................................................ 214
Other Customizations in Tables ........................................................................................................ 215
Customize Alarm Table Row Colors ........................................................................................ 215
Set Up a Default Sort ............................................................................................................... 216
Customize the Port Name Column of the Interface Table ........................................................ 217
Sort Interfaces Table by ifIndex ............................................................................................... 218
Adding Support for Model Types or Model Classes ................................................................................ 220
Create a Registration ........................................................................................................................ 220
Register the Model Type or Model Class in custom-app-config.xml ........................................ 220
Define General OneClick Device Support Based on Model Class ........................................... 221
Define Specific OneClick Device Support Based on Model Type ............................................ 223
Define Model Appearance ........................................................................................................ 224
Configure Icons for OneClick Themes .............................................................................................. 225
Using the <theme-config> Element to Create Icon Appearance .............................................. 227
Design On-Page and Off-Page Reference Icons .............................................................................. 227
Use <on-page> and <off-page> Elements ............................................................................... 229
Define the Icon Shape .............................................................................................................. 230
Define Pipe Connection Location ............................................................................................. 233
Define Image Components ...................................................................................................... 234
Create an Icon Label ......................................................................................................................... 238
The default-iconlabel-config.xml File ........................................................................................ 239
Adjust Icon Label Background Width ....................................................................................... 241
Default Label Width Settings .................................................................................................... 241
Create Fixed Width Icon Labels ............................................................................................... 241
Define Text Components .................................................................................................................. 242
Define Selection Components ........................................................................................................... 242
Define Model Icon Tooltips ................................................................................................................ 245
Customizing a Model's Information View ................................................................................................. 247
Extend or Modify an Information View .............................................................................................. 249
Create an Information Configuration File .......................................................................................... 250
Define the Header .................................................................................................................... 251
Define the Subview .................................................................................................................. 252
Define a Subview Group .......................................................................................................... 261
Associate an Information Configuration File with a Model Class or Model Type .............................. 262
Creating a Model's Performance View .................................................................................................... 263
Create a New Performance View ...................................................................................................... 264
Create a Performance Data Configuration File ........................................................................ 265
Create a Performance View Configuration File ........................................................................ 267
Customize an Existing Performance View ........................................................................................ 269
Creating Custom Privileges ..................................................................................................................... 271
Define a Custom Privilege ................................................................................................................. 271
Restrict Access to Attribute Values in Model Subviews ........................................................... 274
Customizing 9
Group Privileges ....................................................................................................................... 274
Reference a Privilege When Defining a Menu Item, Column, or Subview ........................................ 275
XML Usage Common to All Customization Files ..................................................................................... 276
About Parameters ............................................................................................................................. 276
Acquire Data -- Render a Value ............................................................................................... 277
Customizing OneClick for CA Service Desk ............................................................................................ 289
TL1 Gateway ........................................................................................... 290

What Is TL1? ........................................................................................................................................... 290
What Is TL1 Gateway? ............................................................................................................................ 290
What Does TL1 Gateway Include? .......................................................................................................... 290
Installing TL1 Gateway ............................................................................................................................ 291
Prerequisites for TL1 Gateway .......................................................................................................... 291
Installation Options ............................................................................................................................ 293
Install on a Non-CA Spectrum Machine ............................................................................................ 293
Setting up Port Numbers ................................................................................................................... 294
Creating a TL1 Device Model ............................................................................................................ 295
Max Telnet Sessions and Max Logins Per Telnet Attribute Considerations ............................ 296
TL1 Devices with Autonomous Port ........................................................................................................ 299
Command on First Logon .................................................................................................................. 300
Pre Login Sequence .......................................................................................................................... 301
The TL1 AlarmMap .................................................................................................................................. 301
Format of the AlarmMap ................................................................................................................... 303
The tl1map Utility .............................................................................................................................. 304
AlarmMap Extraction ......................................................................................................................... 306
Importing an AlarmMap ..................................................................................................................... 306
Examples of tl1map Usage ............................................................................................................... 307
AlertMaps for TL1 .............................................................................................................................. 308
Managing TL1 Gateway Daemon ............................................................................................................ 309
TL1 Gateway Daemon ...................................................................................................................... 309
Start the TL1 Daemon on a CA Spectrum Server ............................................................................. 309
Start the TL1 Daemon on a Remote Server ...................................................................................... 310
Terminating the TL1 Daemon ........................................................................................................... 311
Customizing 10
Customizing
This section contains information about the following topics:
Modeling Gateway Toolkit (see page 12)
Model Type Editor (see page 107)
OneClick Customization (see page 177)
TL1 Gateway (see page 290)
03-Apr-2017 11/311
Modeling Gateway Toolkit

Modeling Gateway support for Wireless Devices (see page 12)
The CA Spectrum Modeling Gateway toolkit lets integrators import and export network topology data
into and out of CA Spectrum. The toolkit includes a Document Type Definition (DTD) that defines XML
elements and attributes. The toolkit also includes a resource file that defines CA Spectrum syntax and
what information to import or export.
For a topology import, using the DTD elements, you can create an XML file that describes devices,
ports, and connections on your network. This XML file can create new topology data in CA Spectrum,
update existing data, or can destroy data that is no longer correct. Additionally, the elements and
attributes that are used in the XML syntax can be expanded and customized to suit the needs of most
integrations.
The toolkit also lets you use comma-delimited ASCII text files to import Frame Relay or ATM
connections. You can also import this connection information using the XML functionality that was
mentioned previously.
Once the network topology data exists in CA Spectrum, you can manage these devices like any other
models that are created manually or by Discovery. You can view the results of the import, as well as
any diagnostic information about each import.
The Modeling Gateway toolkit also lets you export topology information and configuration settings
from CA Spectrum using an XML file. The information can then be imported into a specified
SpectroSERVER through the Modeling Gateway.
Populating CA Spectrum with dynamic network topology information on an ongoing basis was
previously a difficult task. Discovery and manual modeling are not suited to the constant updates
necessary in a changing environment. Modeling connectivity using Discovery can also be a challenge
with various physical infrastructures, such as those found in these environments:
Cable MSO (Multi-Service Operator)
ATM (Asynchronous Transfer Mode)
Frame Relay
Wireless Devices
Modeling Gateway support for Wireless Devices

From Spectrum r10.1, you can import and export topology data and configuration settings for
wireless devices from and to Spectrum. However, AccessPoint devices are not supported by the
Modeling Gateway Toolkit.
To discover and model AccessPoint devices, follow these steps:
03-Apr-2017 12/311
1. Import the relevant comma-delimited ASCII text/ XML file, using the Modeling Gateway
Toolkit.
2. Navigate to Explorer View > WLC Manager > Information Tab > Configuration sub-view >
Access Point Discovery: and then click Run.
All existing access points (APs) will be created under their corresponding WLC Device(s).
CA Spectrum Modeling Gateway is an effective solution for these problems.
Modeling Gateway Prerequisites

Before you use the CA Spectrum Modeling Gateway toolkit, make sure that you:
Have had significant exposure to CA Spectrum.
Read SpectroSERVER and CA Spectrum Databases Overview (https://docops.ca.com/display/CASP102

/SpectroSERVER+and+CA+Spectrum+Databases+Overview).
Have a working knowledge of XML.
Understand the concept of a Document Type Definition (DTD).
Have a detailed understanding of the network topology you are importing.
03-Apr-2017 13/311
Can use UNIX or Windows to navigate through the file system, copy and delete files, as well as,
create and edit text files.
Import and Export Architecture

Import Architecture (see page 14)
Export Architecture (see page 15)
Import Architecture
For an import, during the import integration process you take data from the third-party database and
create an input file. Depending on the content, this input file can be an XML file or a comma-
delimited ASCII file. The XML input file gives you the widest range of import options and is the main
focus of this section. The comma-delimited file lets you create connections for Frame Relay and ATM
circuits.
When creating an XML input file, work with the provided Document Type Definition (DTD) file and
the .modelinggatewayresource.xml file. The DTD defines the XML elements, attributes, and their
associated syntax rules. The .modelinggatewayresource.xml file shows which CA Spectrum model
types and attributes are available for use. This file relates the CA Spectrum model type names and
attribute names with the unique hexadecimal identifier that CA Spectrum uses for that model type or
attribute. The .modelinggatewayresource.xml file can be customized to suit the needs of your specific
integration.
Once you create the first input file, it can act as a template for multiple data sets representing the
same type of input. For example, you can create an XML file for importing devices and can use this
file repeatedly by substituting the device-specific topology data.
The modelinggateway tool is a command-line utility that reads the network topology information
from the input file and sends the data to the SpectroSERVER database. With the data from the XML
file, the import tool can create, destroy, and update connections, devices, and container models. The
tool can also be used to export data from CA Spectrum.
The CA Spectrum Modeling Gateway also provides mechanisms to verify the safety and accuracy of
each database import. For example, it can maintain an audit trail that includes a record of each
creation, deletion, association, and update made. You can view information about the import within
OneClick. CA Spectrum reports the error by generating an event when any type of critical failure
occurs during the import process. All errors and their possible causes are logged in an error log file.
You can also turn on a debug log which can help you locate the source of problems or inaccuracies.
The following illustration shows how the Modeling Gateway uses an XML file for importing data. The
data flows from the third-party database and is formatted in the XML file using the DTD and .
modelinggatewayresource.xml for syntax purposes. The import tool then interprets the XML file and
sends data into CA Spectrum through the CA Spectrum CORBA interface.
03-Apr-2017 14/311
Modeling Gateway uses an XML file for importing data
The following illustration shows how the Modeling Gateway uses a comma-delimited ASCII text file to
import Frame Relay and ATM connection information.
Modeling Gateway uses a comma-delimited ASCII text file to import Frame Relay and ATM connection
information
Export Architecture
For export, using the SpectroSERVER as a resource, Modeling Gateway can export topology and
configuration data into an XML file. This XML file can then be integrated with a third-party tool or
reimported into another SpectroSERVER. For example, the file can be reimported for a CA Spectrum
partition or landscape handle change.
Spectrum modelling gateway can export Global Collections and Services without any errors even if
they have any duplicate names, as the modelling gateway uses model handle to uniquely identify
them.
03-Apr-2017 15/311
Import Topology Data into CA Spectrum

You can import the third-party topology data into CA Spectrum using Modeling Gateway. Initially,
extract the topology data from the third-party database and format the data in an input file.
To import third-party topology data into CA Spectrum using Modeling Gateway, perform these tasks:
1. Extract Topology Data.

Extract the network topology data from the third-party database. Since each database system
is different, see the documentation for the database you are working with to complete this
step.
2. Format the Data in an Input File (see page 17).

To format the data for the import tool, create an XML or a comma-delimited input file.
3. (Optional) Move the modelinggateway Tool.
Note: To run the modelinggateway tool on another server, move the

modelinggateway tool and all of its support files to that server. For more
information, see Distributed SpectroSERVER Administration (https://docops.ca.com
/display/CASP102/Distributed+SpectroSERVER+Administration).
4. Run the modelinggateway Tool (see page 32).

Once the input file is created, use the import tool to send the data into CA Spectrum.
5. (Optional) Import Comma-delimited Files (see page 34).

You can import Frame Relay and ATM connection data from the OneClick interface without
the import tool.
6. View Import Information (see page 35)

Verify the progress and results of the import in OneClick.
Note: Do not use Modeling Gateway to migrate models from one version of CA
Spectrum to another. The methodology that is used to identify and model an entity
can differ between CA Spectrum versions. Therefore, do not use Modeling Gateway
to import any XML files that are exported from a different version of CA Spectrum.

Format the Data in an Input File (see page 17)
Run the modelinggateway Tool for Import (see page 32)
ImportConfiguration Element (see page 34)
Import Comma-Delimited Files (see page 34)
View Import Information (see page 35)
03-Apr-2017 16/311
Format the Data in an Input File

Two types of input files are used to import data using the Modeling Gateway: XML files and comma-
delimited files. XML input files can be used to create or destroy models and connections, and update
attribute values and connectivity information. The syntax in the DTD provided with the Modeling
Gateway defines the elements to be used in the XML input file. Comma-delimited files can only be
used to create ATM and Frame Relay connections. The following sections outline how to create each
of the types of input files.
XML Input Files

Contents
Hierarchical Views (see page 17)
Topology View (see page 17)
Location View (see page 17)
Models and Model Types (see page 18)
Modeling Methods (see page 19)
CA Spectrum Attributes (see page 19)
To understand the elements that create an XML input file, be familiar with the process CA Spectrum
uses to model a network infrastructure. The following section provides an overview of this process
and discusses how it applies to the XML elements used in an XML input file. If you are comfortable
with these concepts, you can skip this section and can go to XML Input File Syntax (see page 19):
Hierarchical Views
A view in CA Spectrum is a way to organize data so it can be displayed or manipulated. The
hierarchical views represent ways to structure your network data. When structuring your network
data in the XML file, you choose from elements that represent each of the hierarchical views. The
two types of hierarchical views are Topology and Location.
Topology View
The Topology view is really an abstraction of networking components. When working with this view,
you represent the physical or logical components of your network and group these components with
logical connectivity in mind. You can also choose to represent connections graphically using pipes
that show how devices are connected at the port or device level. In OneClick, this view appears as the
Universe topology.
Location View
The Location view organizes your network data by physical location. Using this view, you can depict
your network in terms of geography. You can start with your global offices. Then, go right to the
wiring closet on each floor of each building in each region where your offices are located. In OneClick,
this view appears as the World topology.
03-Apr-2017 17/311
Note: For more information about the topology views available in OneClick, see the
Modeling and Managing Your IT Infrastructure (https://docops.ca.com/display/CASP102
/Modeling+and+Managing+Your+IT+Infrastructure).
Models and Model Types

Numerous model types are predefined in CA Spectrum. When model types are instantiated in the CA
Spectrum interface to represent a specific network entity, they are referred to as models. The two
major categories of model types are:
Intelligent model types
Container model types
Intelligent model types can be instantiated to represent actual devices that operate on the network.
They have IP and MAC addresses, and CA Spectrum can communicate directly with these devices
using SNMP. Container model types are instantiated into models that are primarily used to group
models together.
Models can be grouped based on the type of hierarchical view being used. For example, you can use
the Topology view to create a LAN model that groups certain devices on a segment of your network.
Or, you can use the Location view to create a Room model that groups the devices together in one
room of your building.
A container model can contain other container models, intelligent models, or both, depending on the
specific model type. For example, a network container model could contain an intelligent model to
represent a router. The network container model could also contain a LAN container model to
represent a range of IP addresses. On the other hand, a Building model can only contain container
models; for example, a Floor, a Section, or a Room.
The elements in the DTD let you depict your network topology using any of the hierarchical views and
their respective container model types. You can also use any of the instantiable intelligent model
types. Intelligent model types are not dependent on the type of hierarchical view used.
Note: You can specify the model handle rather than the model type to identify a model, if
desired. When specifying a model handle, Modeling Gateway ignores any other model
identifiers, and it uses only the model handle to identify the model.
Not all model types that are defined in the CA Spectrum knowledge base can actually be
used to create a model in OneClick. Some are used as base model types from which other
model types are derived.
For more information, see SpectroSERVER and CA Spectrum Databases Overview (

https://docops.ca.com/display/CASP102/SpectroSERVER+and+CA+Spectrum+Databases+Overview).
03-Apr-2017 18/311
Modeling Methods
Two methods are used to model devices in CA Spectrum. The first method is to use the IP address or
the DNS name of the device. With this information, CA Spectrum contacts the device and creates a
model using the model type that best represents the functionality of the device.
The second method is to provide a model type for the device model creation. You still must provide
an IP address or a DNS name so CA Spectrum can communicate with the device. However, your
chosen model type or model handle is instantiated regardless of the CA Spectrum assessment of the
device functionality.
To create a nondevice model, like a container model, a model type and model name must
be provided for the import.
CA Spectrum Attributes
Each model type has a set of associated attributes. Each attribute describes the model type in some
way. The attributes in an instantiated model take on values that reflect the device that the model
represents and describe the current state of the model. For example, the model type Host_Sun has
the attribute IPAddress. If a model of the type Host_Sun is instantiated, the value of this attribute
reflects the IP address of the device that the model represents.
XML syntax also uses the term attribute. The XML attributes describe more information about an
element. In CA Spectrum Modeling Gateway XML syntax, some XML attributes are used to give value
to CA Spectrum attributes.
Note: Attributes that CA Spectrum defines are referred to as CA Spectrum attributes; the
generic XML attributes are referred to simply as attributes.
XML Input File Syntax

Use the syntax rules that are defined in the DTD file when you generate the XML file. The following
section provides an overview of the functionality of each of the DTD elements.
Note: The following explanations and examples do not cover all the attributes of each
element. For a complete reference on each element and its attributes, see Document Type
Definition Elements.

Root Element (see page 20)
Model-Oriented Elements (see page 20)
Task-Oriented Elements (see page 22)
03-Apr-2017 19/311
Task-Oriented Elements (see page 22)

New Topology Data (see page 22)
Represent the Same Device in Multiple Views (see page 25)
Create Connections Using Discovery (see page 25)
Create Connections Using the Connection Element (see page 26)
Create WA_Link Connections (see page 27)
Synchronize Information Between CA Spectrum and the Third-Party Database (see page 28)
Update Information (see page 29)
Destroy Information (see page 29)
The .modelinggatewayresource.xml File (see page 30)
Define Character Set Encoding (see page 31)
View CA Spectrum Character Set Encoding Information (see page 31)
Root Element
The elements that are defined in the DTD exist in a hierarchical structure that parallels the network
representation within CA Spectrum. The root element that must be used with each XML import file is
the Import element. XML syntax rules specify that the root element is the outermost element and
denotes the beginning and end of the XML file. Therefore, the Import element surrounds the rest of
the XML elements that are used in your document.
Model-Oriented Elements
The model-oriented elements define physical or logical components of your network. They are
container-type elements that are used to create models which define logical ways of grouping
network elements. Grouping is based on the type of CA Spectrum hierarchical view they are in. Each
of these container-type elements can exist in one of the specific hierarchical views.
Topology_Container
Location_Container
Device
Schedule
Port
Connection
GenericView_Container
03-Apr-2017 20/311
Topology_Container
The Topology_Container element creates a model that groups other models according to physical
or logical topology. The Topology_Container element creates container models, so use the
model_type attribute or a model handle to identify the specific container you want to use. An
enumeration of possible model_type values is in the DTD. A LAN is an example of a
Topology_Container model_type value. You specify the name of the Topology_Container using
the name attribute. The name and model_type attributes uniquely identify the created model. If
you specify a model handle, the name and model_type attributes are ignored.
Topology_Containers can contain other Topology_Container elements, devices, or connections.
The Topology_Container models are always placed in the OneClick Topology view.
Note: By default, the name and model_type attributes give values to the CA Spectrum
attributes Model_Name and Modeltype_Name. However, you can change which CA
Spectrum attribute the name attribute gives value to by editing the .
modelinggatewayresource.xml file. Whatever new CA Spectrum attribute is chosen (along
with the model type) is used to identify uniquely the container. This change lets two
containers have the same model name.
Location_Container
The Location_Container element groups other models according to physical or geographical
location. A Building and a Room are both examples of Location_Container element model type
values. The Location_Container element creates container models, so use the model_type
attribute or a model handle to identify the specific container you want to use. An enumeration of
possible model_type values is in the DTD. You specify the name of the Location_Container using
the name attribute. The name and model_type attributes uniquely identify the created model. If
you specify a model handle, the name and model_type attributes are ignored.
Note: By default, the name and model_type attributes give values to the CA Spectrum
attributes Model_Name and Modeltype_Name. However, you can change which CA
Spectrum attribute the name attribute gives value to by editing the .
modelinggatewayresource.xml file. Whatever new CA Spectrum attribute is chosen (along
with the model type) is used to identify uniquely the container. This change lets two
containers have the same model name.
Device
The Device element defines a device on the network. This element is used with other elements to
create, update, or destroy an instance of a device model in CA Spectrum. When working with an
SNMP device, provide a valid and unique IP address or DNS name to identify uniquely the device
using the ip_dnsname attribute. This unique identification lets CA Spectrum communicate with
the device and select the most appropriate model type, which is based on the device
functionality. Set the ip_dnsname to a valid string. If ip_dnsname is invalid or not contactable, the
device model creation can fail. If model_type is provided with an invalid or noncontactable
ip_dnsname, a device model is still created with the specified model type. However, the device
model is not activated to provide any valid network information or status. Possible model_type
values for devices are enumerated in the .modelinggatewayresource.xml file.
03-Apr-2017 21/311
Schedule
The Schedule element defines when a device model is put into maintenance mode. When a
device model is in maintenance mode, management traffic to the device and its components is
suspended. Suspending traffic prevents CA Spectrum from generating any events or alarms on the
device model while you are performing maintenance on the device.
Port
Ports are automatically created for a device when you create the device model. The Port element
lets you modify some CA Spectrum port attribute values, or specify a port-level connection. You
can specify different kinds of ports, including a Frame Relay or ATM circuit. To identify the port on
the device, provide the values for the identifier_name and identifier_value attributes. The
possible values for identifier_name are enumerated in the DTD. The identifier_value is the value
of the identifier that the identifier_name attribute chooses. A Port element must always be
specified as a child of a Device element.
Connection
The Connection element defines a physical or logical connection between two devices, including
WAN link connections, and therefore must contain two Device child elements. If a Port element is
specified in the Device element, the connection is resolved on the specified port for that device. If
the Device element does not specify a Port element, CA Spectrum Discovery tries to determine
the ports in the connection to be resolved.
To create a container model in a Generic view, use the GenericView_Container element. Both the
GenericView and GenericView_Container elements are used to create a customized view.
Therefore, as the integrator, you decide when or how to use this container.
Task-Oriented Elements
The rest of the elements that are defined in the DTD are task-oriented elements. These elements and
their attributes help define the type of action the input file generates. Using them, you can create
new topology information, update, overwrite, or delete existing topology information. An individual
input file can use zero or one of each of these elements, except for the Connection element. You can
use as many Connection elements as necessary.
Topology
Location
GenericView
Connection
Update
Destroy
New Topology Data

Contents
Create a Location View (see page 23)
Create a Topology View (see page 24)
03-Apr-2017 22/311
The task-oriented elements define what action you would like to take with your XML file. Use the
Topology and Location elements when you would like to create new network topology data in CA
Spectrum. These elements define the hierarchical view where you would like to create the data. You
can then use the corresponding model elements as child elements to create models for the network
entities. To customize a view for your specific integration needs, use the GenericView element.
Create a Location View

You can create your topology information in the Location view for viewing in the World topology in
OneClick. To create this information in the Location view, construct your XML file using the Location
element inside the Import root element. The Location element can contain Location_Container
elements to create a specific container model, or Device elements to create device models.
Example: Site Container in Location View
The following example creates a Site container in the Location view and a device within that
container.
<?xml version = "1.0" standalone = "no" ?>

<!DOCTYPE Import SYSTEM ".modelinggateway.dtd">
<Import>
<Location>
<Location_Container model_type = "Site" name = "My_Town" >
<Device ip_dnsname= "10.253.9.18"
community_string="public"/>
</Location_Container>
</Location>
</Import>
The Import element is the root element and is always contained in the input file.
The Location element indicates that you are creating models in the Location view.
The Location_Container element creates a container model. This model is a logical component rather
than a physical component of the network. Therefore, CA Spectrum cannot contact it and cannot
define the model type using an IP address or a DNS name. To indicate the type of container model to
create, provide a value for the model_type attribute and name attribute. Possible model_type
attribute values are listed in the DTD and in the following section: Location_Container. The name
attribute is required and must specify a unique name for the model.
Note: When you specify a model handle, the model handle is used to identify the container
model. Therefore the name and model_type attributes are ignored, if provided.
The Device element creates a model inside the Site Location_Container model. The ip_dnsname
attribute is a required attribute for the Device element. If a device can be contacted, CA Spectrum
uses the IP Address or the DNS name to find the device.
For a complete reference of these elements and their possible attributes, see Document Type
Definition Elements.
03-Apr-2017 23/311
Create a Topology View

You can import your network data into the Topology view for viewing in the Universe topology in
OneClick. To import into the Topology view, construct your XML file using the Topology element
inside the Import root element. The Topology element can contain:
Topology_Container elements to create a specific type of container model.
Device elements to create a specific type of device model.
Connection elements to create connections between two devices.
Using the hierarchy and syntax rules that are outlined in the DTD, you can accurately express the
physical and logical connectivity of your network.
Example: LAN Container in Topology View
This example creates a LAN container in the Topology view and a device within that container.

<Import>
<Topology>
<Topology_Container model_type = "Lan"
name = "Sample_LAN" Security_String = "public"
subnet_address= "10.253.9.0" subnet_mask = "255.255.255.0">
</Topology_Container>
</Topology>
</Import>
The Import element is the root element and is always contained in the input file.
The Topology element indicates that you are going to create models in the Topology view.
The Topology_Container element creates a container model. This model is a logical component
rather than a physical component of the network. Therefore, CA Spectrum cannot contact it and
cannot define the model type using an IP address or a DNS name. To indicate the type of container
model to create, provide a value for the model_type attribute and name attribute. The possible
model_type attribute values are listed in the DTD and in the following section: Topology_Container.
The name attribute is required and must specify a unique name for the model. The other attributes
that are specified are optional.
Note: When you specify a model handle, the model handle is used to identify the container
model. Therefore the name and model_type attributes is ignored, if provided.
03-Apr-2017 24/311
The Device element creates a model inside the LAN Topology_Container model. The ip_dnsname
attribute is a required attribute for the Device element. If CA Spectrum can contact the device, the IP
Address or the DNS name is used to find the device. When CA Spectrum locates the device, it
determines the appropriate model type to use to create the model.
Represent the Same Device in Multiple Views

You can create an XML file that represents a device in multiple views. To create this file, we
recommended that each Device element you use to create a model of this device has identical
attributes and attribute values. If they are not identical, the import tool attempts to merge the
attributes and values of these Device elements to create a set of consistent attributes and values.
Sometimes an attribute is specified in each of these Device elements, but different values are used. In
this case, the value for the last Device element that is listed in the XML file overrides all previous
values for that attribute in the other Device elements that are used to create a model of that device.
Remember that some attributes have default values. For example, the default value of the attribute
community_string is public. Therefore, when you specify a Device element attribute and value to
represent device A, we recommended that you specify it in any other Device element that represents
device A. Doing so _helps ensure that a default value for that attribute is not used to override the
previously specified value.
Example: Create a Device in Both the Topology and Location Views
In the following example, device 10.253.9.16 is created in the Topology and Location views. You can
see that the attributes and values that are used to describe the device is the same for both views.

<Import>

<Topology discover_connections="false" complete_topology="false">
<Device ip_dnsname="10.253.9.16" community_string="zippo" />
</Topology>

<Location complete_topology="true">
<Location_Container model_type="Site" name="Durham">
<Device ip_dnsname="10.253.9.16" community_string="zippo"/>
</Location>
</Import>
Create Connections Using Discovery

A CA Spectrum connection represents a physical or logical link between two devices. You can create
connections two different ways in the XML input file. The first method employs CA Spectrum
Discovery, using the discover_connections attribute of the Topology element. Discovery runs on the
newly created device models when the discover_connections attribute is set to true. Then, Discovery
establishes connectivity for these devices.
03-Apr-2017 25/311
Note: For more information about Discovery, see the Modeling and Managing Your IT
Infrastructure (https://docops.ca.com/display/CASP102
Example: Using Discovery to Create Connections

<Import>
<Topology >
<Topology_Container model_type = "Lan" name = "Sample_LAN"
discover_connections= "true"
Security_String = "public" subnet_address= "10.253.9.0"
subnet_mask = "255.255.255.0" >
community string="public"/>
</Topology>
</Import>
Create Connections Using the Connection Element

The second way to create connections is to use the Connection element, which connects devices that
are already created. Connections can be specified between two ports, between a device and a port,
or between two devices.
Specifying the connectivity between devices lets CA Spectrum isolate faults to the device, but
specifying port-level connections is preferred. The port-level connections are a finer grade of
connectivity, allowing CA Spectrum to resolve the connections and analyze faults at the port level. CA
Spectrum automatically attempts to determine the ports when you specify a connection between
two devices but you do not specify one or both ports that are used in the connection. If this process is
successful, CA Spectrum resolves the connection to the port level.
CA Spectrum generates an error indicating a connection failure when both of these conditions apply:
CA Spectrum is unable to determine both ports that are used in the connection.
At least one of these devices is a manageable device.
The error is written to the error log file.
If CA Spectrum can determine only one of the ports, then the connection is resolved only to the port
level on one side of the connection. The other side remains resolved to the device level.
If both devices are unmanageable devices, CA Spectrum establishes the connection at the device
level.
Example: Create a Connection between Existing Ports
The following example creates a connection between two existing ports, each port belonging to a
03-Apr-2017 26/311
The following example creates a connection between two existing ports, each port belonging to a
different device. The Connection element identifies both the Port and Device elements to be linked.
The connection is resolved at the port level for both devices because a Port element is specified
within each Device element.

<Import>
<Connection>
<Device ip_dnsname= "172.19.57.93">
<Port identifier_name = "frCircuitTableInstance"
identifier_value="4.161"/>
</Device>
<Device ip_dnsname = "192.168.125.161">
<Port identifier_name= "frCircuitTableInstance"
identifier_value= "2.861"/>
</Device>
</Connection>
</Import>
The previous example specifies a connection between the DLCI ports. Because the value of the
identifier_name attribute is frCircuitTableInstance, the port is identified using the OID instance value
from the frCircuitTable object in the MIB. The OID instance value is specified using the
identifier_value attribute.
The Connection element is contained within a Topology element or a Topology_Container element to

indicate the hierarchical placement of the devices. This case does not change the results of the input
file.
Important! Modeling Gateway does not report an error when you attempt to import an
XML file that contains multiple Connection elements using the same Port element. A single
port cannot have multiple connections. If the same port is specified in multiple Connection
elements, the last Connection element in the XML file overrides all the previous
Connection elements specifying that port.
Create WA_Link Connections

To create WA_Link connections, use the following syntax:
<Connection>
<Device ip_dnsname=10.253.9.18/>
<Device ip_dnsmame=10.253.9.100 model_type="WA_Link">
</Connection>
Modeling Gateway automatically creates a WA_Segment. The link is created between the segment
and the device or devices. To specify a connection between a second device and the link, add a
second connection tag to the import file.
03-Apr-2017 27/311
Synchronize Information Between CA Spectrum and the Third-Party Database

The Topology, Location, Topology_Container, and Location_Container elements have an attribute
named complete_topology. Setting the value of this attribute to true indicates that the XML file
defines all the models and connections that CA Spectrum must know about. When the XML file is
imported into CA Spectrum, any models in that CA Spectrum view that are not represented in the
XML file are sent to the Lost and Found. If there are subcontainers in the view, CA Spectrum refers to
the value of the complete_topology attribute that is set in the element specifying the subcontainer. If
the complete_topology attribute value is not specified in the subcontainer element, the value is
inherited from the parent element. Thus, if the parent element has a complete_topology setting of
true and the subcontainer element does not specify a setting for complete_topology, the
complete_topology value for the subcontainer is also true.
When CA Spectrum imports the XML file, models are sent to the Lost and Found under these
conditions:
The models exist either directly in the view you are importing into or in the subcontainer of that
view.
The models do not exist in the XML file.
This behavior is useful when synchronizing the data in your third-party database with the data in CA
Spectrum.
Example: Complete_Topology Set to True
In the following example, complete_topology is set to true within the Topology element. Except for
models that are specified in this input file, all existing models in the Topology view would be sent to
the Lost and Found. With this sample input file, only two models are specified:
The LAN Topology_Container
The device at IP address 10.253.9.18
If these models did not exist, they would be created. If they existed, CA Spectrum would update their
CA Spectrum attribute values using the attribute values in the input file. Any other model existing in
the Topology view (except for the VNM) would be sent to the Lost and Found.

<Import>
<Topology complete_topology="true">
<Topology_Container model_type = "Lan" name ="Sample_LAN"
Security_String = "public" subnet_address= "10.253.9.0"
subnet_mask = "255.255.255.0">
</Topology>
</Import>
03-Apr-2017 28/311
If the complete_topology attribute was used in the Topology_Container element instead of the
Topology element, CA Spectrum would remove only unspecified models from that
Topology_Container down through the hierarchy.
Update Information
To update CA Spectrum attribute and association information for existing models, use the Update
element. The Update element can enclose Container elements, Device elements, and Association
elements. The value of Port attributes is updated using the appropriate Device element.
Example: Update Attributes for Two Different Models and Create an Association
The following example shows an Update input file. In this case, two attributes for two separate
models are updated and an association is created between the two models.

<Import>
<Update>
<Topology_Container model_type="Lan" name="Sample"
model_name = "newLAN"/>
<Device ip_dnsname= "Test1" poll_interval= "1108"/>
<Association relation="0x10002">
<Left_Model> <Topology_Container name="Net"
model_type="Network" /></Left_Model>
<Right_Model> <Device ip_dnsname="172.24.94.94" /></Right_Model>
</Association>
</Update>
</Import>
The first updated attribute is the model_name attribute of the LAN container model. The model
name is changed from Sample to newLAN. Note the use of the following attributes: name and
model_name. Both of these attributes exist to change the CA Spectrum attribute Model_Name. To
identify the container model and then specify the new name of the container model using the
model_name attribute, use the name attribute with the current name as the value.
Next, the example changes the value of the poll interval for the device from Test1 to 1108. Assigning
a new value to the poll_interval attribute overwrites the old value.
This example also creates an association of relation 0x10002 between container model "Net" of the
Network model type and device model 172.24.94.94, as long as both models exist on the
SpectroSERVER.
Destroy Information
Use the Destroy element to delete container models, device models, connections, and associations.
When you destroy a device, all port and application models that are associated with the device are
also destroyed.
Example: Destroy a LAN Container, a Connection, and an Association
03-Apr-2017 29/311
In the following example, the LAN topology container named newLAN is destroyed. All models within
this container are sent to the Lost and Found, unless they are specified to be destroyed. This example
also destroys a connection between two devices, Test1 and Test2, which is specified at the port level.
If a Collects association exists between the container model "Net" of model type Network and device
172.24.94.94, it is destroyed.

<Import>
<Destroy>
<Topology_Container model_type="Lan" name="newLAN"/>
<Connection>
<Device ip_dnsname= "Test1">
<Port identifier_name= "ifIndex" identifier_value= "1"/>
</Device>
<Device ip_dnsname= "Test2">
<Port identifier_name="ipAddress"
identifier_value = "10.253.8.18"/>
</Device>
</Connection>
<Association relation="Collects">
<Left_Model> <Topology_Container name="Net"
model_type="Network" /></Left_Model>
<Right_Model> <Device ip_dnsname="172.24.94.94" /></Right_Model>
</Association>
</Destroy>
</Import>
Important! To destroy a model representing a device that has already been removed from
the network, use the IP address of the device rather than the DNS name when specifying
the ip_dnsname attribute of the Device in the Destroy element of an XML file. Once the
device has been removed from the network, the DNS entry for that device no longer exists.
And, the Modeling Gateway cannot identify the appropriate model to delete.
The .modelinggatewayresource.xml File

The Topology_Container, Location_Container, and Device elements have a model_type attribute that
must have a value equal to a valid CA Spectrum model type. CA Spectrum uniquely identifies model
types using a hexadecimal number. These hexadecimal values have been enumerated in the resource
file .modelinggatewayresource.xml. This file pairs a text value for the model type with the unique
hexadecimal identifier. The text values are then displayed in the DTD.
Many of the attributes that are defined in the DTD correspond to CA Spectrum attributes. CA
Spectrum attributes are uniquely identified in CA Spectrum using a hexadecimal number. The .
modelinggatewayresource.xml file does not use these hexadecimal values in the DTD or in the XML
file. Instead, the file pairs the hexadecimal identifiers of the CA Spectrum attributes with more
intuitive text-based names.
03-Apr-2017 30/311
Both the ModelType element and the Attribute element of the .modelinggatewayresource.xml file
can be customized.
Note: The .modelinggatewayresource.xml file is also used for exporting topology data from
CA Spectrum. For more information, see Export Topology Data from CA Spectrum (see page
37).
Define Character Set Encoding

The CA Spectrum XML input file is encoded with UTF-8 by default. To import special characters or
foreign languages, specify the appropriate character set encoding in the XML file header, as shown in
the following example.
Example: Set the Input File Character Encoding to Greek
The following example shows how you would modify the XML file to set the character encoding to
Greek:
<?xml version="1.0" encoding="ISO-8859-7" standalone="no"?>

View CA Spectrum Character Set Encoding Information

Determine the character set encoding that CA Spectrum uses from the OneClick Administration
Pages.
Follow these steps:
1. Click Administration in the OneClick home page.

The Administration Pages open.
2. Click Character Set in the panel on the left.

The Character Set Encoding page opens, displaying a list of encodings and their applicable
languages.
Comma-Delimited Input Files

The Modeling Gateway can specify ATM and Frame Relay connectivity in an XML input file. The
toolkit can also accept ATM and Frame Relay connectivity information from a comma-delimited ASCII
text file. This file can be used to import information about connections between:
Two ATM circuits
Two Frame Relay circuits
An ATM and a Frame Relay circuit
You can specify that a live pipe is created in OneClick to represent the connection. Multiple
connections can be specified in the same input file.
03-Apr-2017 31/311
Note: The device models that are involved in these connections must previously exist in CA
Spectrum.
Comma-Delimited Input File Syntax

The following example shows the format that is used in the comma-delimited input file:
<Device_IP>, <OID>, <Device_IP>, <OID>, <CircuitName>, <CircuitID>, <Pipe>
Device_IP
Specifies the IP address of each device that is involved in the connection. Required.
OID
Specifies the OID instance of frCircuitTable, atmVclTable, or atmVplTable to specify the circuit link
on the device.
CircuitName
(Optional) Specifies the name of the circuit involved.
CircuitID
(Optional) Specifies the ID of the circuit involved.
Pipe
(Optional) Has two possible values: CREATE_PIPE or NO_CREATE_PIPE. If the value is set to
CREATE_PIPE, live pipes are created between the connections specified. If the value is set to
NO_CREATE_PIPE, live pipes are not created between the connections specified. If no value is
specified for this parameter, a default value of CREATE_PIPE is assumed.
Example: Specified Connection between Frame Relay Circuits
The following example shows an input file that specifies the connection between two Frame Relay
circuits. A live pipe is created between these two ports.
172.19.57.93, 4.161, 192.168.125.161, 2.161, FR_Circuit_Name, Circuit_Id_123,

CREATE_PIPE
Run the modelinggateway Tool for Import

Import a Single File (see page 32)
Import Multiple Files (see page 33)
Import a Single File

To run the modelinggateway tool for importing a single file, use the following syntax.
Windows
03-Apr-2017 32/311
modelinggateway.bat -vnm vnm_name -i import_file [-o outputfile] [-debug debugfile]
Solaris/Linux
modelinggateway -vnm vnm_name -i import_file [-o outputfile] [-debug debugfile]
-vnm vnm_name
Specifies the SpectroSERVER host name.
- i import_file
Specifies the XML file name which contains the necessary input information (that is compiled with .
modelinggateway.dtd.)
Note: If you are importing from multiple files, specify the files names that are enclosed in
comma-separated {} brackets. For example, refer to the syntax sample for importing
multiple files.
-o outputfile
(Optional) Logs the error information to the file named in the outputfile parameter.
Note: If you don't specify the debug/output file names, the error information is logged to a
file named import_file.log;where, Import_file is the name of the XML file.In case of multiple
imports, the debug/output files are appended and you can see consolidated logs.
-debug debugfile
(Optional) Indicates that you would like to create a debugging output file during the import process.
When using the -debug option, you can provide your own debug file name for output. If you do not
supply a value for debugfile, the debug file name defaults to the import_file name suffixed with ".
debug."
Note: The -debug option requires disk space on the machine where Modeling Gateway is
run. For example, a large debugging output file can result when the number of models in
the import_file is large or when the device models have large interface densities.
Import Multiple Files

The modelinggateway tool now supports import from multiple XML files. You can now specify any
number of import files.
To run the modelinggateway tool for importing multiple files, use the following syntax:
03-Apr-2017 33/311
To run the modelinggateway tool for importing multiple files, use the following syntax:
modelinggateway -vnm vnm_name [-user SS user][-i{importfile1,importfile2...}]|[ -cmdb]

-e exportfile][-o outputfile] [-debug debugfile]
ImportConfiguration Element
To control certain aspects of how Modeling Gateway imports data, use the ImportConfiguration
element.
The ImportConfiguration element has the following syntax:
<ImportConfiguration
do_not_process_pre_existing_devices_under_container_node = "false"
import_to_primary_ss_only = "false"
max_device_creation_threads = "50"
/>
do_not_process_pre_existing_devices_under_container_node
Specifies whether CA Spectrum processes devices that are found under a container element
which previously exist in CA Spectrum.
Default: false
import_to_primary_ss_only
Specifies whether Modeling Gateway connects to the secondary SpectroSERVER when the
primary SpectroSERVER is down.
Default: false
max_device_creation_threads
Specifies how many device models can be created and activated simultaneously.
Note: Setting this value to an amount higher than 50 can result in too much SNMP traffic.
Default: 50
Import Comma-Delimited Files

The previous section described how to import input files using the modelinggateway import tool. You
can also import Frame Relay and ATM connection data from the OneClick interface.
Follow these steps:
1. Click the applicable VNM model in the OneClick Console.
2. Click the Information tab in the Component Detail panel.
3. Click Logical Connection Import to expand the section.
03-Apr-2017 34/311
4. Click Import, locate the comma-delimited file containing the data that you want to import into
CA Spectrum, and then click Open.
OneClick imports the data. The Import Results dialog appears, providing you with information
about the success of the import.
View Import Information

View Modeling Gateway Results in OneClick (see page 35)
Error Log (see page 36)
The CA Spectrum Modeling Gateway provides mechanisms to help ensure the safety and accuracy of
each database import. CA Spectrum Modeling Gateway maintains an audit trail that includes a record
of each creation, deletion, association, and update made. You can view data about the import within
OneClick and you can also track information about import problems in the error and debug logs.
View Modeling Gateway Results in OneClick

You can verify the results of the Modeling Gateway import from the VNM model, Information tab in
the OneClick Console.
Follow these steps:
1. Click the applicable VNM model in the OneClick Console.
2. Click the Information tab in the Component Detail panel.
3. Click Modeling Gateway to expand the section.
4. Review the table in the Modeling Gateway section for information about recent imports. The
table contains the following information:
Import File
Displays the name of the import file.
Log File
Displays the name of the log file.
Start Time
Indicates when the topology import process began.
End Time
Indicates when the topology import process completed.
Progress
The progress field shows the status of a topology import that has not yet finished. The
possible values for this field are:
Initializing
Identifying Models
Creating Models
03-Apr-2017 35/311
Creating Models
Activating Models
Mapping Connectivity
Placing Models
Creating Connections
Updating Models
Destroying Models
Complete
Disconnected
Errors
Displays the number of errors that are generated during the import process.
Models Created
Displays the number of models that are created during the import process.
Models Destroyed
Displays the number of models that are eliminated during the import process.
Models Updated
Displays the number of models that are updated during the import process.
Connections Created
Displays the number of connections that are created during the import process.
Connections Removed
Displays the number of connections that are removed during the import process.
5. Click the Max Records set link to modify the number of import files that are listed in the table.
6. Click any of the table column headers to sort the data as needed.
7. Enter text in the Filter field to restrict the import data to specific criteria.
8. Click Update to check the status of an import as it is processing.

The screen refreshes and displays the most recent import information available.
Error Log
All errors and their possible causes are logged in an error log file. By default, the import tool creates
an error log named <nameofimportfile>.log where <nameofimportfile> is the name of your import
file. You can also specify a particular name for your log file using the syntax that is specified in the
section on the import tool. When the import is complete, the log file appears in the SS-Tools
03-Apr-2017 36/311
section on the import tool. When the import is complete, the log file appears in the SS-Tools
directory. The log file records the number of successful creations, deletions, and updates of models
and connections. The log file also records each single failure that occurred during the importing
process.
Export Topology Data from CA Spectrum

Modeling Gateway supports exporting topology information and configuration settings from a
SpectroSERVER. The information is exported into an XML-formatted file, which can then be imported
into a specified SpectroSERVER using the Modeling Gateway.
The following types of information are exported by default:
Device elements, with configuration attributes.
Port elements, with configuration attributes.
Container elements, with configuration attributes.
Connections (resolved and unresolved, WA_Link connections).
Universe topology hierarchy.
Layout for each view in the Universe topology, including annotations and zoom information but
excluding background images.
User models and the entire user scheme such as user-related relations, attributes, and models
like LicenseRole, AccessGroup, PrivilegeRole, and UserGroup.
Discovery configurations.
Service Management schemes and attributes.
Static and dynamic global collections including all the models in each global collection, all dynamic
collection criteria, zoomed list, grouped list, and topology layout.
Important! Modeling Gateway partitions a SpectroSERVER database across two or more

SpectroSERVERs, or to change the landscape handle of a single SpectroSERVER database.
To configure behaviors and set up modeling for data that is not currently supported in the
export capabilities, some manual work is required after the exported data is imported.
Examples of types of data which are not exported includes, but is not limited to, Service
Performance Manager (SPM) tests, NCM configurations, and Events.
03-Apr-2017 37/311
Configure Export Settings

You can control what is exported by modifying the ExportConfiguration element in the .
modelinggatewayresource.xml file. By default, all topology and modeling information under the
Universe container is exported. You can modify the RootContainerToExport element to specify a
different root container from which to export. All the contents of the root container and each of its
subcontainers are exported.
Note: You do not need to use the DTD for exporting data; the DTD is used only for
importing data.
The attributes that are exported for devices, containers, and ports are defined in the following
elements respectively: DeviceExportAttributes, ContainerExportAttributes, and PortExportAttributes.
Add and subtract attributes from these elements as needed.
The SpectrumConfigurationExport element controls what types of CA Spectrum configuration data

are exported when the export_spectrum_settings flag in the ExportConfiguration element is set to
true.
For example, the following element controls the attributes that are exported for the LostFound
model:
<SpectrumConfigurationExport model_type="LostFound" >

<Automatic_Model_Destruction attribute_id="0x11de1" />
<Model_Destruction_Interval_Hours attribute_id="0x11de3" />
<Model_Destruction_Interval_Minutes attribute_id="0x11de4" />
</SpectrumConfigurationExport>
Important! The modeling information of the devices which are in the "LostFound" folder
are not exported.
ExportConfiguration Element
To control export behavior, use the ExportConfiguration element in the .modelinggatewayresource.
xml file.
The ExportConfiguration element has the following syntax:
<ExportConfiguration
export_devices = "true"
export_containers = "true"
03-Apr-2017 38/311
export_port_attributes = "true"
export_links = "true"
export_topology_layout = "true"
export_annotation = "true"
export_WA_Link_models = "true"
export_spectrum_settings = "true"
export_user_models = "true"
export_service_modeling = "true"
export_schedules = "true"
export_global_collections = "true"
export_discovery_configs = "true"
export_from_primary_ss_only = "false"
export_policy_manager = "true"
/>
export_devices
Exports device models.
export_containers
Exports container models.
export_port_attributes
Exports port attributes.
export_links
Exports device links.
export_topology_layout
Exports device and container models' x,y coordinates in the topology.
export_annotation
Exports the annotations and model group information.
export_WA_Link_models
Exports WA_Link models. If you decide not to export WA_Link models, they are treated as
transparent. Wide area links between two device models are exported as a direct link.
export_spectrum_settings
Exports CA Spectrum settings such as the settings for fault isolation, Discovery, and VNM control.
export_user_models
Exports user models, user licenses, user privileges, user preferences, and all other user-related
relations attributes and models.
export_servicemodeling
Exports service management schemes and attributes.
Note: For more information about Service Manager, see Service Manager (https://docops.ca.
com/display/CASP102/Service+Manager).
03-Apr-2017 39/311
export_schedules
Exports the schedules.
export_global_collections
Exports static and dynamic global collections including all the models in each global collection, all
dynamic collection criteria, zoomed list, grouped list, and topology layout.
export_discovery_configs
Exports the Discovery configurations.
export_from_primary_ss_only
Specifies whether Modeling Gateway connects to the secondary SpectroSERVER when the
primary SpectroSERVER is down.
export_policy_manager
Exports the Policy Manager policies. All related models, policies, rules, permissions, and
templates are included.
Example:
The following example exports everything except for port attribute information. This example also
tells Modeling Gateway not to connect to the secondary SpectroSERVER when the primary is down.
export_port_attributes = "false"
export_from_primary_ss_only = "true"
/>
The modelinggateway Tool for Export

Export CA Spectrum Topology Data (see page 41)
Import Modeling Gateway XML file (see page 42)
The Modeling Gateway command-line tool, modelinggateway, (modelinggateway.bat on Windows)

is located in the SS-Tools directory. Its syntax for export is:
Windows
03-Apr-2017 40/311
modelinggateway.bat -vnm vnm_name [-cmdb] -e export_file [-o outputfile] [-debug

debugfile]
Solaris/Linux
modelinggateway -vnm vnm_name [-cmdb] -e export_file [-o outputfile] [-debug

debugfile]
-vnm vnm_name
Specifies the name of the SpectroSERVER host.
-cmdb
(Optional) Exports the contents of your SpectroSERVER in a format that can be used when
integrating CA Spectrum with CA CMDB. For more information on implementing this integration,
contact CA Support.
-e export_file
Exports CA Spectrum topology data.
-o outputfile
(Optional) Logs the error information to the file named in the outputfile parameter. If this option
is not used, the error information is logged to a file named export_file.log. Export_file is the name
of the XML file.
-debug debugfile
(Optional) Indicates that you would like to create a debugging output file during the export
process. When using the -debug option, you can provide your own debug file name for output. If
you do not supply a value for debugfile, the debug file name defaults to the export_file name
suffixed with .debug.
Note: The -debug option requires disk space on the machine where Modeling Gateway is run. The
number of models in the export_file affects the size of the debugging output file: the greater the
number of models in the database, the larger the debug file produced.
Note: To run the modelinggateway tool on another server, move the modelinggateway
tool and all of its support files to that server. For more information, see the Distributed
SpectroSERVER Administration (https://docops.ca.com/display/CASP102
/Distributed+SpectroSERVER+Administration).
Export CA Spectrum Topology Data

Export CA Spectrum topology data using the modelinggateway tool.
Follow these steps:
To export CA Spectrum topology data, use the -e flag. For example, running the following command
exports the data from the SpectroSERVER on NOC1_Spectrum into a Modeling Gateway formatted
xml file named NOC1_data.xml:
modelinggateway -vnm NOC1_Spectrum -e NOC1_data.xml
03-Apr-2017 41/311
Import Modeling Gateway XML file

You can import the data from a Modeling Gateway formatted XML file into CA Spectrum.
Follow these steps:
To import from a Modeling Gateway formatted XML file, use the -i flag. For example, running the
following command imports the data from NOC1_data.xml into the SpectroSERVER at
NOC2_Spectrum.
modelinggateway -vnm NOC2_Spectrum -i NOC1_data.xml
Appendix A: Document Type Definition Elements

This section describes the functionality of each element that is defined in the Document Type
Definition (DTD). This section also provides context for each one. This section does not describe the
XML syntax that is used in the DTD. For syntax information, see an XML reference.

Association (see page 43)
Connection (see page 43)
Correlation (see page 44)
Correlation_Domain (see page 45)
CustomerManager (see page 45)
Destroy (see page 46)
Device (see page 47)
EventModel (see page 50)
GenericView (see page 51)
GenericView_Container (see page 51)
GlobalCollection (see page 52)
Import (see page 53)
Left_Model (see page 54)
List_Value (see page 54)
Location (see page 55)
Location_Container (see page 55)
Model_Attr (see page 57)
Model 1 (see page 57)
MonitorPolicy_Attr (see page 58)
Port (see page 58)
Right_Model (see page 60)
RTM_Test (see page 60)
Schedule (see page 61)
SM_AttrMonitor (see page 64)
SM_Customer (see page 64)
SM_CustomerGroup (see page 66)
03-Apr-2017 42/311
SM_CustomerGroup (see page 66)

SM_Guarantee (see page 66)
SM_LatencyMon (see page 67)
SM_Service (see page 68)
SM_Service_Mgt (see page 69)
SM_ServiceMgr (see page 70)
SM_SLA (see page 70)
SM_SLA_Mgr (see page 71)
Topology (see page 71)
Topology_Container (see page 72)
Update (see page 74)
Association
Syntax
Parent Elements:
Update
Destroy
Child Elements:
Left_Model
Right_Model
Rules: The Association element must contain one Left_Model element and one Right_Model
element.
Usage
The Association element creates or destroys associations between models.
If the Association element is used as a child of the Destroy element, the association that is specified is
destroyed. If the Association element is used as a child of the Update element, the association that is
specified is created.
Attributes
relation
Specifies the name or handle of the CA Spectrum relation between the Left_Model and
Right_Model in this association.
Connection
Syntax
03-Apr-2017 43/311
Parent Elements:
Topology
Topology_Container
Update
Destroy
Child Elements: Device
Rules: The Connection element must contain two device elements.
Usage
The Connection element specifies a connection between two devices. The Connection element must
always contain two device elements and each of these Device elements can contain zero or one Port
element. If a port or ports are specified, the connection is resolved at the port level. If a port or ports
are not specified, Discovery is triggered to find the port or ports for the connection.
If the Connection element is used as a child of the Destroy element, the connection that is specified is
destroyed. If the connection is used in any other context, the connection is created.
Attributes
create_pipe
Indicates whether a graphical representation of the specified connection is shown in OneClick.
Default: True
Correlation
Syntax
Parent Element: Import
Child Element: Correlation_Domain
Rule: The Correlation element can contain any number of child elements.
Usage
The Correlation element represents a Correlation Manager model and is used with the CA Spectrum
Service Manager. See Service Manager (https://docops.ca.com/display/CASP102/Service+Manager) for
usage details.
Attributes
None.
03-Apr-2017 44/311
Correlation_Domain
Syntax
Parent Element: Correlation
Child Elements:
Device
Port
Model_Attr
Rule: The Correlation_Domain element can contain any number of child elements.
Usage
The Correlation_Domain element is used with the CA Spectrum Service Manager. See Service
Manager (https://docops.ca.com/display/CASP102/Service+Manager) for usage details.
Attributes
See Service Manager (https://docops.ca.com/display/CASP102/Service+Manager) for attribute definitions.
Attribute Data Type Default Value Possible Values

name Character N/A N/A
(required)
CustomerManager
Syntax
Parent Element: SM_Service_Mgt
Child Elements:
SM_Customer
SM_CustomerGroup
Rule: The CustomerManager element can contain any number of these child elements.
Usage
The CustomerManager element is used with the CA Spectrum Service Manager. See Service Manager (
https://docops.ca.com/display/CASP102/Service+Manager) for usage details.
Attributes
03-Apr-2017 45/311
Attributes
Note: See Service Manager (https://docops.ca.com/display/CASP102/Service+Manager) for

attribute definitions.

(required)
containment_relation Character Groups_Customers N/A
model_type Character CustomerManager N/A
Destroy
Syntax
Child Elements:
Topology_Container
Location_Container
Device
Model
Connection
EventModel
SM_Service
SM_AttrMonitor
SM_LatencyMon
SM_ConnectMon
SM_SLA
SM_Guarantee
SM_Customer
03-Apr-2017 46/311
Association
Rule: The Destroy element can contain as many of each of these child elements as necessary.
Usage
Use the Destroy element to remove container models, device models, connections, and associations.
You cannot nest elements in the Destroy element to express hierarchies or destroy hierarchies. The
only hierarchy that is allowed in the Destroy element is the Connection-Device-Port hierarchy, which
specifies at the port level the connection to destroy. You could destroy a container model without
destroying the device models or other container models that are contained inside it. In this case, the
remaining models are placed in the CA Spectrum Lost and Found.
Attributes
The Destroy element does not have any attributes.
Device
Syntax
Parent Elements:
Topology
Location
Topology_Container
Left_Model
Right_Model
Location_Container
GenericView
Connection
Update
Destroy
SM_Service
SM_AttrMonitor
Child Elements:
Port
03-Apr-2017 47/311
Schedule
Rules:
Port: If a Device element is contained within a Connection element, only one port element is
allowed. If a Device element in contained within an Update element to update ports, more than
one port element is allowed. The ports are ignored when a Device element is contained in a View,
a Container, or a Destroy element.
Schedule: The Device element can contain one Schedule element.
Usage
To create, destroy, or update a device model, use the Device element. The Device element lets you
define the device model using ether an IP address or a DNS name.
Note: If community_string and agent_port attributes are not provided during the device
creation, CA Spectrum creates the device using the predefined SNMP credentials. These
credentials are configured in the Modeling and Protocol Options section of the
AutoDiscovery Control subview in the VNM model Information tab in OneClick.
Attributes
ip_dnsname
Specifies the IP address or DNS name of the device. If the device does not support SNMP
communication, you can use a unique string here with model_type specified.
secdomain_ipname
(Optional) Specifies the IP address of a host running an SDConnector in the secure domain where
the device is located.
Default: 0.0.0.0
model_handle
(Optional) Specifies the model_handle to identify an existing device model.
Note: If you provide a model_handle, the value of ip_dnsname is ignored.
model_type
(Optional) The CA Spectrum model type that is used to model your device. This device model can
be any intelligent model type that is defined in the .modelinggatewayresource.xml file.
Note: If you have provided a valid IP address or DNS name, you do not need to specify a
value here.
community_string
03-Apr-2017 48/311
community_string
(Optional) The community string of the device.
Note: If community_string is not included, CA Spectrum uses the first SNMP Community
Strings value to create the device. These values are specified in the VNM model
Information tab, AutoDiscovery Control subview, Modeling and Protocol Options subview
in OneClick.
agent_port
(Optional) Controls the port number that is used when communicating with the SNMP agent of a
device.
Note: If agent_port is not included, CA Spectrum uses the first SNMP Ports value to create
the device. These values are specified in the VNM model Information tab, AutoDiscovery
Control subview, Modeling and Protocol Options subview in OneClick.
is_managed
(Optional) Puts the device model in maintenance mode, when set to true.
Default: True
poll_interval
(Optional) Specifies the time interval, in seconds, that the SpectroSERVER reads all attributes of
the device model that are flagged as POLLED.
log_ration
(Optional) Specifies the number of SpectroSERVER polls of a device that occur before logging the
poll results in the database.
poll_status
(Optional) Lets you disable the SpectroSERVER polls of a device by setting the polling status to
false.
model_name
(Optional) Specifies the name of the model.
DeviceType
(Optional) Specifies the device type of the model.
Note: See the Certification (https://docops.ca.com/display/CASP102/Certification) for more

information about device types.
reconfig
(Optional) Specifies whether Modeling Gateway sends an action to the SpectroSERVER to

reconfigure the device model.
03-Apr-2017 49/311
discover_connections
(Optional) Runs Discovery on any newly created device models to map automatically the model
connectivity, when set to true.
EventModel
Syntax
Parent Element:
Topology_Container
Left_Model
Right_Model
Child Element: None
Rule: N/A
Usage
To import the EventModel models for use with a Southbound Gateway integration, use the
EventModel element. For more information about Southbound Gateway, see the Southbound
Gateway Toolkit (https://docops.ca.com/display/CASP102/Southbound+Gateway+Toolkit).
Attributes
model_name
Specifies the unique name of the model that is instantiated or identified.
unique_id
Specifies the identifier that is used to define uniquely the event source that this EventModel
model represents. For more information, see the Southbound Gateway Toolkit (https://docops.ca.
com/display/CASP102/Southbound+Gateway+Toolkit).
model_handle
(Optional) Specifies the model_handle to identify an existing device model.
Security_String
(Optional) Specifies the security string for the EventModel.
Default: public
manager_name
(Optional) Specifies the name of the third-party application that is using the Southbound Gateway.
Note: Use the default value for any application that is not listed here.
Default: 0
1
NetMentor
03-Apr-2017 50/311
2
SSM
3
Omni2000
GenericView
Syntax
Child Elements:
Device
Rule: The GenericView element can contain any number of these child elements.
Usage
To create a customized hierarchical view other than the Topology view and Location view, use the
GenericView element. You can modify this element to meet the needs of your integration.
Attributes
containment_relation
Specifies a relation handle that defines which CA Spectrum relation defines the containment
relationship within this view.
Limits: Must be a CA Spectrum containment relation.
model_type
Specifies a model type that represents the top container model that is defined for this view. This
model_type must be specified with its model handle in the .modelinggatewayresource.xml file.
name
Specifies the unique name of the instantiated container model highest in the GenericView
hierarchy.
complete_topology
(Optional) Destroys any unspecified, existing container and device model in the GenericView view
when set to true. Also, destroys these models in the subcontainers of that view.
Syntax
Parent Element: GenericView
03-Apr-2017 51/311
Child Elements:
Device
Rule: The GenericView_Container element can contain any number of child elements.
Usage
To create a container model in the Generic view, use the GenericView_Container element. Both the
GenericView and GenericView_Container elements are used to create a customized view. Therefore,
as the integrator, you decide when or how to use this container.
Attributes
name
Specifies the name of the model that is instantiated or identified. The model_type and the name
attribute are required to identify uniquely the GenericView_Container. By default, this attribute is
used to set the value of the CA Spectrum model name attribute (attr id 0x1006e). However, this
attribute can be changed to any other attribute in the .modelinggatewayresource.xml file. You
can change the .modelinggatewayresource.xml so that the name maps to a different attribute. In
this case, that new attribute (along with the model type) is used to identify the container. This
behavior lets two containers have the same model name.
model_type
Specifies the CA Spectrum model type that is used to create the model. This model_type must be
specified with its model handle in the .modelinggatewayresource.xml file. The model_type and
the name attribute are required to identify uniquely the GenericView_Container.
(Optional) The name of the CA Spectrum relation that exists between the Generic_Container and
the models within the container. If no value for this attribute is specified, the containment
relationship of the parent model is inherited.
GlobalCollection
Syntax
Child Elements:
Device
Topology_Container
Location_Container
Usage
Represents a GlobalCollection model.
03-Apr-2017 52/311
Represents a GlobalCollection model.
Attributes
name
Specifies a name for this global collection.
Specifies a relation handle that defines which CA Spectrum relation defines the containment
relationship within this view.
Default: "GlobalCollect"
collectionDescription
(Optional) Describes the global collection.
Security_String
(Optional) Specifies the security string for the global collection.
Import
Syntax
Parent Element: None
Child Elements:
Topology
Location
GenericView
Update
Destroy
SM_Service_Mgt
Correlation
GlobalCollection
Rule: The Import element can contain one of each of these child elements.
Usage
The Import element is the root element, and it must be included in each input file.
Attributes
03-Apr-2017 53/311
model_activation_time
Specifies the maximum number of minutes that are allowed for each device model activation.
Data Type: Character
Default: 5 minutes
Left_Model
Syntax
Parent Element: Association
Child Elements:
Device
Port
Topology_Container
Location_Container
EventModel
Model
Rules: The Left_Model element can contain only one child element.
Usage
The Left_Model element defines the left side model in an association.
Attributes
None.
List_Value
Syntax
Parent Element: Model_Attr
Child Element: None
Rule: N/A
Usage
To specify a CA Spectrum list attribute value, use the List_Value element.
Attributes
03-Apr-2017 54/311
Attributes
None.
Location
Syntax
Child Elements:
Location_Container
Device
Rule: The Location element can contain any number of child elements.
Usage
To specify that you would like to create models in the Location view (World topology) of OneClick,
use the Location element.
Attributes
complete_topology
(Optional) When set to true, any unspecified, existing containers and device models in the
Location view, or any subcontainers, are destroyed during the import.
Default: False
Data Type: Boolean
Location_Container
Syntax
Parent Elements:
Location
Location_Container
Left_Model
Right_Model
GlobalCollection
Child Elements:
Location_Container
03-Apr-2017 55/311
Device
Rule: The Location_Container element can contain any number of child elements.
Usage
To create or specify a Location_Container model that is used to group models and other location
containers in the Location view, use the Location_Container element.
Attributes
name
The name of the model that is instantiated or identified. The model_type and the name attribute
are required to identify uniquely the Location_Container.
By default, this attribute is used to set the value of the CA Spectrum model name attribute (attr id
0x1006e). However, this attribute can be changed to any other attribute in the .
modelinggatewayresource.xml file. You can change the .modelinggatewayresource.xml so that
the name maps to a different attribute. In this case, that new attribute (along with the model
type) is used to identify the container. This behavior lets two containers have the same model
name.
model_type
Indicates the type of model you want to create. The model_type and the name attribute are
required to identify uniquely the Location_Container. Possible values include:
Country
Region
Site
Building
Floor
Section
Room
model_handle
(Optional) Can be used to identify models. If you provide a model_handle, the values of name and
model_type are ignored.
Security_String
(Optional) Defines the requirements for access to a model by CA Spectrum users. Each security
string consists of one or more Security Community entries and is assigned to models.
model_name
(Optional) To change the name of the model, use the name and the model_name attributes. The
name attribute specifies the old name and the model_name attribute specifies the new name.
model_modify_author
(Optional) Writes data to the CA Spectrum attribute mdl_modfy_athr.
03-Apr-2017 56/311
complete_topology
(Optional) When set to true, any unspecified, existing containers and device models in the
Location view, or any subcontainers, are destroyed during the import.
Default: False
Model_Attr
Syntax
Parent Element: Correlation_Domain
Child Element: List_Value
Rule: The Model_Attr element can contain any number of child elements.
Usage
To specify CA Spectrum attributes whose values contain multiple lines of text or a list of values, use
the Model_Attr element.
Attributes
attr_id
Indicates the CA Spectrum attribute ID of the attribute you are specifying.
Data Type: Character
Model 1
Syntax
Parent Elements:
Left_Model
Right_Model
Child Elements: None
Usage
To represent any CA Spectrum model, use the Model element.
Attributes
name
Specifies a name for this model.
model_type
Specifies the model type of this model.
model_handle
03-Apr-2017 57/311
model_handle
(Optional) Specifies a model_handle for this model. If a model_handle value is specified, the
name and model_type values are ignored.
MonitorPolicy_Attr
Syntax
Parent Element:
SM_Service
SM_AttrMonitor
Child Element: None
Rule: N/A
Usage
The MonitorPolicy_Attr element is used with the CA Spectrum Service Manager. See Service Manager
(https://docops.ca.com/display/CASP102/Service+Manager) for usage details.
Attributes
None.
Port
Syntax
Parent Elements:
Device
Left_Model
Right_Model
Correlation_Domain
SM_Service
SM_AttrMonitor
Child Element: None
Rule: N/A
Usage
03-Apr-2017 58/311
The Port element is used to specify connections at the port level or to update port attributes. When
updating, the parent Device element is contained within an Update element. When specifying a
connection, the parent device element is contained within a Connection element.
Attributes
identifier_name
Works with the identifier_value attribute to identify uniquely the port. The identifier_name can
be any one of the MIB OID names that are listed in the Possible Values column. The portID value
can be used to identify a port by its Component_OID attribute (0x1006a). If the Port element
represents a Frame Relay virtual circuit, use frCircuitTableInstance. If the Port element represents
an ATM virtual channel or path link, use atmVclTableInstance.
The portID value can be used to identify a port by its Component_OID attribute (0x1006a). If the
Port element represents a Frame Relay virtual circuit, use frCircuitTableInstance.If the Port
element represents an ATM virtual channel or path link, use atmVclTableInstance. Possible values
include:
ifIndex
ipAddress
ifPhysAddress
ifName
ifAlias
model_name
portDescription
portID
frCircuitTableInstance
atmVclTableInstance
atmVplTableInstance
identifier_value
Specifies the value of the identifier_name selection.
model_handle
(Optional) Specifies the model_handle to identify an existing model.
Note: If you provide a model_handle, the values for identifier_name and identifier_value are
ignored.
ip_dnsname
(Optional) Specifies the IP address or DNS name of the port model. If the port model does not
support SNMP communication, you can use a unique string here with model_type specified.
model_name
(Optional) Specifies the name of the model you are updating.
03-Apr-2017 59/311
circuit_id
(Optional) Identifies the circuit that is involved in an ATM or Frame Relay connection by ID.
circuit_name
(Optional) Identifies the circuit that is involved in an ATM or Frame Relay connection by name.
log_ratio
(Optional) Specifies the number of port model polls that occur before logging the poll results in
the database.
poll_interval
(Optional) Specifies the time interval, in seconds, that the SpectroSERVER reads all attributes of
the port model that is flagged as POLLED.
poll_status
(Optional) Lets an administrator disable port model polls by setting polling status to False.
Right_Model
Syntax
Parent Element: Association
Child Elements:
Device
Port
Topology_Container
Location_Container
EventModel
Model
Rules: The Right_Model element can contain only one child element.
Usage
The Right_Model element defines the right side model in an association.
Attributes
None.
RTM_Test
Syntax
03-Apr-2017 60/311
Syntax
Parent Elements:
SM_Service
SM_AttrMonitor
Child Element: None
Rule: N/A
Usage
The RTM_Test element is used with the CA Spectrum Service Manager. See the Service Manager (
https://docops.ca.com/display/CASP102/Service+Manager) section for usage details.
Attributes
See the Service Manager (https://docops.ca.com/display/CASP102/Service+Manager) section for attribute

definitions.

(required)
model_type Character RTM_Test N/A
Schedule
Syntax
Parent Elements: Device
Child Element: None
Usage
To create a maintenance mode schedule for a particular device model, use the Schedule element.
Attributes
name
Specifies the name of the schedule.
SCHED_Recurrence
Specifies how often the device model is put into maintenance mode.
1
Always (24x7)
03-Apr-2017 61/311
2
Daily
3
Weekly
4
Monthly
5
Yearly
Default: 1
SCHED_Start_Hour
(Optional) Specifies the hour that the device goes into maintenance mode.
Limits: 0-23
SCHED_Start_Minute
(Optional) Specifies the minute the device goes into maintenance mode.
Limits: 0-59
SCHED_Start_DoW
(Optional) Specifies the day of the week the device goes into maintenance mode.
0
Sunday
1
Monday
2
Tuesday
3
Wednesday
4
Thursday
5
Friday
6
Saturday
SCHED_Start_DoM
(Optional) Specifies the day of the month the device goes into maintenance mode.
Limits: 1-31
SCHED_Start_Month
(Optional) Specifies the month that the device goes into maintenance mode.
03-Apr-2017 62/311
0
January
1
February
2
March
3
April
4
May
5
June
6
July
7
August
8
September
9
October
10
November
11
December
SCHED_Duration
(Optional) Specifies the length of time the device is in maintenance mode, which is defined in
seconds.
Default: 0
SCHED_Recurrence_Multiplier
(Optional) Specifies the number of recurrence units (days, weeks, months, years) that determine
the length of time between the start of each scheduled maintenance mode.
Default: 1
SCHED_Daily_Repeat_Limit
(Optional) Specifies the number of consecutive days to repeat the scheduled maintenance
(specified by SCHED_Start_Hour and SCHED_Start_Minute) during each recurrence period. This
attribute is only applicable to a weekly, monthly, or yearly recurrence.
03-Apr-2017 63/311
SM_AttrMonitor
Syntax
Parent Element: SM_Service
Child Element: None
Rules: N/A
Usage
The SM_AttrMonitor element is used with the CA Spectrum Service Manager. See the Service
Manager (https://docops.ca.com/display/CASP102/Service+Manager) section for usage details.
Attributes

definitions.

(required)
containment_relation Character N/A SLMMonitors
SLMWatchesContainer
AttrToWatch Character N/A N/A
MonitorPolicy_ID Character N/A N/A
is_managed Boolean N/A True
False
Generate_Service_Alarms Boolean N/A True
False
model_type Character SM_AttrMonitor N/A
SM_Customer
Syntax
Parent Elements:
SM_CustomerGroup
CustomerManager
Child Element: None
Rule: N/A
Usage
03-Apr-2017 64/311
Usage
The SM_Customer element is used with the CA Spectrum Service Manager. See the Service Manager (
Attributes

definitions.

(required)
containment_relation Character N/A SlmAgreesTo
SlmUses
Security_String Character N/A N/A
CustomerID Character N/A N/A
Criticality Character N/A N/A
CustomerField4 Character N/A N/A
Contact_Name Character N/A N/A
Contact_Title Character N/A N/A
Contact_Location Character N/A N/A
Email_Address Character N/A N/A
Phone_Number Character N/A N/A
Mobile_Phone_Number Character N/A N/A
Pager_Number Character N/A N/A
Fax_Number Character N/A N/A
User_Defined_1 Character N/A N/A
Secondary_Contact_Name Character N/A N/A
Secondary_Contact_Location Character N/A N/A
Secondary_Email_Address Character N/A N/A
Secondary_Phone_Number Character N/A N/A
Secondary_Mobile_Phone_ Character N/A N/A
Number
Secondary_Pager_Number Character N/A N/A
03-Apr-2017 65/311

Secondary_Fax_Number Character N/A N/A
Secondary_User_Defined_1 Character N/A N/A
model_type Character SM_Customer N/A
SM_CustomerGroup
Syntax
Parent Elements:
CustomerManager
SM_CustomerGroup
Child Elements:
SM_CustomerGroup
SM_Customer
Rule: The SM_CustomerGroup element can contain any number of these child elements.
Usage
The SM_CustomerGroup element is used with the CA Spectrum Service Manager. See the Service
Attributes

definitions.

name Character NA N/A
(required)
containment_relation Character Groups_Customer N/A
model_type Character SM_CustomerGroup N/A
SM_Guarantee
Syntax
03-Apr-2017 66/311
Parent Element: SM_SLA
Child Element: None
Rule: N/A
Usage
The SM_Guarantee element is used with the CA Spectrum Service Manager. See the Service Manager
(https://docops.ca.com/display/CASP102/Service+Manager) section for usage details.
Attributes

definitions.

(required)
containment_relation Character SlmIsMeasuredBy N/A
False
DegradedTimeViolationLevel Character N/A N/A
DegradedTimeWarningLevel Character N/A N/A
DownTimeViolationLevel Character N/A N/A
DownTimeWarningLevel Character N/A N/A
LorTimeViolationLevel Character N/A N/A
LorTimeWarningLevel Character N/A N/A
model_type Character SM_Guarantee N/A
SM_LatencyMon
Syntax
Parent Elements:
SM_Guarantee
SM_AttrMonitor
SM_Service
Child Elements:
Topology_Container
MonitorPolicy_Attr
03-Apr-2017 67/311
MonitorPolicy_Attr
Rule: The SM_LatencyMon element can contain any number of these child elements.
Usage
The SM_LatencyMon element is used with the CA Spectrum Service Manager. See the Service
Attributes

definitions.

(required)
containment_relation Character N/A SlmMonitors
SlmWatchesContainer
False
DefaultMaxRTT Character N/A N/A
DefaultMeasureInterval Character N/A N/A
mode_type Character SM_LatencyMon N/A
SM_Service
Syntax
Parent Elements:
SM_Service
SM_ServiceMgr
Child Elements:
SM_Service
SM_AttrMonitor
Rule: The SM_Service element can contain any number of these child elements.
Usage
The SM_Service element is used with the CA Spectrum Service Manager. See the Service Manager (
Attributes
03-Apr-2017 68/311
Attributes

definitions.

(required)
Criticality Character N/A N/A
containment_relation Character N/A SlmMonitors
SlmWatchesContainer
AttrToWatch Character N/A N/A
MonitorPolicy_ID Character N/A N/A
False
Generate_Service_Alarms Boolean N/A True
False
model_type Character SM_Service N/A
SM_Service_Mgt
Syntax
Child Elements:
SM_ServiceMgr
CustomerManager
SM_SLA_Mgr
Rule: Only a single instance of each of these child elements can exist in SM_Service_Mgt.
Usage
The SM_Service_Mgt element is used with the CA Spectrum Service Manager. See the Service
Attributes

definitions.
03-Apr-2017 69/311

name Character Service Management N/A
(required)
containment_relation Character N/A
model_type Character N/A
SM_ServiceMgr
Syntax
Child Element: SM_Service
Rule: The SM_ServiceMgr element can contain any number of this child element.
Usage
The SM_ServiceMgr element is used with the CA Spectrum Service Manager. See the Service Manager
(https://docops.ca.com/display/CASP102/Service+Manager) section for usage details.
Attributes

definitions.

containment_relation Character SlmContains N/A
model_type Character SM_ServiceMgr N/A
SM_SLA
Syntax
Parent Element: SM_SLA_Mgr
Child Element: SM_Guarantee
Rule: The SM_SLA element can contain any number of this child element.
Usage
The SM_SLA element is used with the CA Spectrum Service Manager. See the Service Manager (
03-Apr-2017 70/311
Attributes

definitions.

(required)
False
model_type Character SM_SLA N/A
SM_SLA_Mgr
Syntax
Child Element: SM_SLA
Rule: The SM_SLA_Mgr element can contain any number of this child element.
Usage
The SM_SLA_Mgr element is used with the CA Spectrum Service Manager. See the Service Manager (
Attributes

definitions.

name Character N/A
model_type Character SM_ServiceMgr N/A
Topology
Syntax
Child Elements:
03-Apr-2017 71/311
Child Elements:
Topology_Container
Device
Connection
Rule: The Topology element can contain any number of these child elements.
Usage
To create models in the OneClick Topology view (Universe topology), use the Topology element.
Attributes
complete_topology
Destroys any unspecified, existing container and device model in the Topology view during the
import when set to true. Also, destroys any subcontainers of that view.
Default: False
When set to true, Discovery runs on any newly created device models to map automatically the
connectivity of the model.
Default: False
Topology_Container
Syntax
Parent Elements:
Topology
Topology_Container
SM_Service
SM_AttrMonitor
Child Elements:
Topology_Container
Device
EventModel
Connection
Rule: The Topology_Container element can contain any number of these child elements.
Usage
03-Apr-2017 72/311
Usage
To create or specify a Topology_Container model that is used to group models and other topology
containers in the Topology view, use the Topology_Container element. Possible model types are
listed in the following table in the model_type section.
Attributes
model_type
Indicates the type of model you want to create. The model_type and the name attribute are
required to identify uniquely the Topology_Container.
Network
LAN
IPClassA
IPClassB
IPClassC
LAN_802_3
LAN_803_5
EventAdmin
ATM_Network
model_handle
(Optional) Can be used to identify existing models. If you provide a model_handle, the
values of model_type and model_name are ignored.
Security_String
(Optional) Specifies the assigned CA Spectrum security level for the model.
subnet_address
(Optional) Specifies the subnet address of the device.
subnet_mask
(Optional) Specifies the mask that determines what subnet the device IP address belongs to.
model_name
(Optional) Specifies a model name for the container model.
trapIPAddress
(Optional) For the EventAdmin models only.
03-Apr-2017 73/311
x_coordinate
(Optional) Specifies the x coordinate of the model in the topology.
y_coordinate
(Optional) Specifies the y coordinate of the model in the topology.
complete_topology
(Optional) When set to True, any unspecified, existing container and device model in this
Topology_Container and, any subcontainers, are destroyed during the import.
Default: False
(Optional) Specifies whether CA Spectrum discovers and models devices that are connected to
this model.
Update
Syntax
Child Elements:
Topology_Container
Location_Container
Connection
Device
Model
EventModel
SM_Service
SM_AttrMonitor
SM_LatencyMon
SM_ConnectMon
SM_SLA
SM_Guarantee
SM_Customer
Association
03-Apr-2017 74/311
Association
Rule: The Update element can contain any number these child elements.
Usage
To update attributes for any device, container, or port subelements, use the Update element.
Note: The hierarchical specifications are not allowed when using this element, except for
using the Port element within the Device element.
Attributes
None.
Appendix B: Document Type Definition File

This section contains the Document Type Definition (DTD), which defines XML elements and
attributes for import.
Note: The following code might not be the latest version of this file. For the latest version
of the DTD, use the actual file that shipped with your Modeling Gateway toolkit. The file is
located in the SS-Tools directory and is named .modelinggateway.dtd.










<!ELEMENT Import ( ( Topology |
Location |
GenericView |
Update |
Destroy |
SM_Service_Mgt |
Correlation |
GlobalCollection )*) >
<!ATTLIST Import model_activation_time CDATA "5">


03-Apr-2017 75/311








<!ELEMENT Topology ((Topology_Container | Device | Connection)*) >

<!ATTLIST Topology
complete_topology (false | true) #IMPLIED
discover_connections (false | true) #IMPLIED>
















<!ELEMENT Topology_Container ((Topology_Container |
Device |
EventModel |
Connection )*) >
<!ATTLIST Topology_Container
name CDATA #REQUIRED
model_type ( Network |
Lan |
IPClassA |
IPClassB |
IPClassC |
LAN_802_3 |
LAN_803_5 |
EventAdmin |
ATM_Network ) #REQUIRED
model_handle CDATA #IMPLIED
Security_String CDATA #IMPLIED
subnet_address CDATA #IMPLIED
subnet_mask CDATA #IMPLIED
model_name CDATA #IMPLIED
trapIPAddress CDATA #IMPLIED
x_coordinate CDATA #IMPLIED
y_coordinate CDATA #IMPLIED
complete_topology (false | true) #IMPLIED
discover_connections (false | true) #IMPLIED >
03-Apr-2017 76/311








<!ELEMENT Location ( (Location_Container | Device )* ) >
<!ATTLIST Location
complete_topology (false | true) #IMPLIED>












<!ELEMENT Location_Container ( ( Location_Container | Device )* )>
<!ATTLIST Location_Container
model_type ( Country |
Region |
Site |
Building |
Floor |
Section |
Room ) #REQUIRED
model_modify_author CDATA #IMPLIED
complete_topology (false | true) #IMPLIED >
















03-Apr-2017 77/311






















<!ELEMENT Device ( Port* | Schedule ) >
<!ATTLIST Device
ip_dnsname CDATA #REQUIRED
secdomain_ipname CDATA #IMPLIED
model_type CDATA #IMPLIED
community_string CDATA #IMPLIED
agent_port CDATA #IMPLIED
poll_interval CDATA #IMPLIED
log_ratio CDATA #IMPLIED
DeviceType CDATA #IMPLIED
x_coordinate CDATA #IMPLIED
y_coordinate CDATA #IMPLIED
is_managed (true | false) #IMPLIED
reconfig (true | false) #IMPLIED
poll_status (true | false) #IMPLIED
discover_connections (false | true) #IMPLIED >










<!ELEMENT Port ( Port* ) >
<!ATTLIST Port
identifier_name ( portDescription |
model_name |
03-Apr-2017 78/311
ifIndex |
ipAddress |
ifPhysAddress |
ifName |
ifAlias |
portID |
frCircuitTableInstance |
atmVclTableInstance |
atmVplTableInstance ) #REQUIRED
identifier_value CDATA #REQUIRED
ip_dnsname CDATA #IMPLIED
model_type CDATA #IMPLIED
circuit_id CDATA #IMPLIED
circuit_name CDATA #IMPLIED
log_ratio CDATA #IMPLIED
poll_interval CDATA #IMPLIED
poll_status (false | true) #IMPLIED >


































03-Apr-2017 79/311






















<!ELEMENT Schedule ( #PCDATA) >
<!ATTLIST Schedule
SCHED_Recurrence ( 1 | 2 | 3 |
4 | 5 | 6 ) #REQUIRED
SCHED_Daily_Repeat_Limit CDATA #REQUIRED
SCHED_Duration CDATA #REQUIRED
SCHED_Recurrence_Multiplier CDATA #REQUIRED
SCHED_Start_DoM CDATA #REQUIRED
SCHED_Start_DoW CDATA #REQUIRED
SCHED_Start_Hour CDATA #REQUIRED
SCHED_Start_Minute CDATA #REQUIRED
SCHED_Start_Month CDATA #REQUIRED
SCHED_Start_Day CDATA #REQUIRED
SCHED_DayBitMask CDATA #REQUIRED
SCHED_Start_Year CDATA #REQUIRED
SCHED_Start_MoY CDATA #REQUIRED
SCHED_Description CDATA #REQUIRED
>





<!ELEMENT EventModel ( #PCDATA ) >
<!ATTLIST EventModel
model_name CDATA #REQUIRED
unique_id CDATA #REQUIRED
Security_String CDATA "public"
manager_name CDATA "0">

03-Apr-2017 80/311













<!ELEMENT Connection (Device, Device)>
<!ATTLIST Connection create_pipe (true | false) "true" >










<!ELEMENT Update ( ( Topology_Container |
Location_Container |
GenericView_Container |
Connection |
Device |
EventModel |
SM_Service |
SM_AttrMonitor |
SM_LatencyMon |
SM_ConnectMon |
SM_SLA |
SM_Guarantee |
SM_Customer |
Association
)* ) >







<!ELEMENT Destroy ( ( Topology_Container |
GenericView_Container |
Device |
Connection |
EventModel |
SM_Service |
03-Apr-2017 81/311
SM_AttrMonitor |
SM_LatencyMon |
SM_ConnectMon |
SM_SLA |
SM_Guarantee |
SM_Customer |
Association
)* ) >








<!ELEMENT Association ((Left_Model | Right_Model)*) >
<!ATTLIST Association relation CDATA #REQUIRED >








<!ELEMENT Left_Model (Device |
Port |
Topology_Container |
EventModel |
Model
) >








<!ELEMENT Right_Model (Device |
Port |
EventModel |
Model
) >




03-Apr-2017 82/311






<!ELEMENT Model ( #PCDATA ) >
<!ATTLIST Model
model_type CDATA #REQUIRED
model_handle CDATA #IMPLIED >









<!ELEMENT GenericView ((GenericView_Container | Device )*) >
<!ATTLIST GenericView
containment_relation CDATA #REQUIRED
complete_topology (false | true) #IMPLIED >











<!ELEMENT GenericView_Container ( GenericView_Container |
Device
)*>
<!ATTLIST GenericView_Container
containment_relation CDATA #IMPLIED >









<!ELEMENT Model_Attr ( #PCDATA | List_Value )* >
03-Apr-2017 83/311
<!ATTLIST Model_Attr
attr_id CDATA #REQUIRED >






<!ELEMENT List_Value ( #PCDATA ) >



<!ELEMENT CustomerManager ( SM_Customer |
SM_CustomerGroup
)*>
<!ATTLIST CustomerManager
name CDATA #IMPLIED
containment_relation ( Groups_Customers ) #IMPLIED
model_type ( CustomerManager ) #IMPLIED
>
<!ELEMENT SM_ServiceMgr ( SM_Service )*>
<!ATTLIST SM_ServiceMgr
name CDATA #IMPLIED
containment_relation ( SlmContains ) #IMPLIED
model_type ( SM_ServiceMgr ) #IMPLIED
>
<!ELEMENT SM_SLA_Mgr ( SM_SLA )*>
<!ATTLIST SM_SLA_Mgr
name CDATA #IMPLIED
containment_relation ( SlmContainsSLAs ) #IMPLIED
model_type ( SM_SLA_Mgr ) #IMPLIED
>
<!ELEMENT SM_Service_Mgt ( CustomerManager |
SM_ServiceMgr |
SM_SLA_Mgr
)*>
<!ATTLIST SM_Service_Mgt
name CDATA #IMPLIED
containment_relation ( SlmHasServiceComponent ) #IMPLIED
model_type ( SM_Service_Mgt ) #IMPLIED
>







<!ELEMENT Correlation ( Correlation_Domain )*>




03-Apr-2017 84/311
<!ELEMENT Correlation_Domain ( Device |

Port |
Model_Attr |
)*>
<!ATTLIST Correlation_Domain
>
<!ELEMENT RTM_Test ( #PCDATA) >
<!ATTLIST RTM_Test
model_type ( RTM_Test ) #IMPLIED
>
<!ELEMENT SM_Service ( SM_Service |
SM_AttrMonitor |
SM_LatencyMon |
SM_ConnectMon |
Device |
Port |
RTM_Test |
MonitorPolicy_Attr |
Schedule
)*>





























03-Apr-2017 85/311


















<!ATTLIST SM_Service
containment_relation ( SlmMonitors |
SlmWatchesContainer |
MaintenenceScheduledBy ) #IMPLIED
Criticality ( 10 | 15 | 20 | 25 | 30 ) #IMPLIED
AttrToWatch CDATA #IMPLIED

MonitorPolicy_ID CDATA #IMPLIED
Generate_Service_Alarms (true | false) #IMPLIED
model_type ( SM_Service ) #IMPLIED
>
<!ELEMENT SM_AttrMonitor ( SM_Service |
SM_AttrMonitor |
SM_LatencyMon |
SM_ConnectMon |
Device |
Port |
RTM_Test |
MonitorPolicy_Attr |
)*>












03-Apr-2017 86/311






































<!ATTLIST SM_AttrMonitor
SlmWatchesContainer ) #IMPLIED
AttrToWatch CDATA #IMPLIED
MonitorPolicy_ID CDATA #IMPLIED
Generate_Service_Alarms (true | false) #IMPLIED
model_type ( SM_AttrMonitor ) #IMPLIED
>
<!ELEMENT MonitorPolicy_Attr ( #PCDATA ) >
<!ELEMENT SM_SLA ( SM_Service |
SM_Guarantee |
Schedule
03-Apr-2017 87/311
)*>









<!ATTLIST SM_SLA
containment_relation ( SlmHasGuarantee |
SlmGuarantees |
SlaPeriod ) #IMPLIED
SLA_Control ( 0 | 1 ) #IMPLIED
SLA_ExpirationDate CDATA #IMPLIED
SLA_Notes CDATA #IMPLIED
SLA_Description CDATA #IMPLIED
model_type ( SM_SLA ) #IMPLIED
>
<!ELEMENT SM_Guarantee ( SM_Service |
SM_AttrMonitor |
SM_LatencyMon |
SM_ConnectMon |
Schedule
)*>





















<!ATTLIST SM_Guarantee
containment_relation ( SlmIsMeasuredBy |
03-Apr-2017 88/311
SlmSchedulesGuarantee ) #IMPLIED
GuaranteeControl ( 0 | 1 ) #IMPLIED
GuaranteeType ( 0 | 1 | 2 | 3 ) #REQUIRED
ServiceHealthType ( 1 | 2 ) #IMPLIED
WarningThreshold CDATA #IMPLIED
WarningThresholdPercent CDATA #IMPLIED
ViolationThreshold CDATA #IMPLIED
ViolationThresholdPercent CDATA #IMPLIED
GuaranteeNotes CDATA #IMPLIED
GuaranteeDescription CDATA #IMPLIED
model_type ( SM_Guarantee ) #IMPLIED
MOT_Threshold CDATA #IMPLIED
MTTR_Threshold CDATA #IMPLIED
MTBF_Threshold CDATA #IMPLIED
>
<!ELEMENT SM_LatencyMon ( Topology_Container |
MonitorPolicy_Attr )*>
<!ATTLIST SM_LatencyMon
SlmWatchesContainer ) #IMPLIED
is_managed ( true | false ) #IMPLIED
DefaultMaxRTT CDATA #IMPLIED
DefaultMeasureInterval CDATA #IMPLIED
model_type ( SM_LatencyMon ) #IMPLIED
>
<!ELEMENT SM_CustomerGroup ( SM_CustomerGroup |
SM_Customer
)*>
<!ATTLIST SM_CustomerGroup
containment_relation ( Groups_Customers ) #IMPLIED
model_type ( SM_CustomerGroup ) #IMPLIED
>
<!ELEMENT SM_Customer ( SM_Service |
SM_SLA |
)*>












<!ATTLIST SM_Customer
containment_relation ( SlmAgreesTo |
03-Apr-2017 89/311
SlmUses ) #IMPLIED
CustomerID CDATA #IMPLIED
Criticality CDATA #IMPLIED
CustomerField4 CDATA #IMPLIED
Contact_Name CDATA #IMPLIED
Contact_Title CDATA #IMPLIED
Contact_Location CDATA #IMPLIED
Email_Address CDATA #IMPLIED
Phone_Number CDATA #IMPLIED
Mobile_Phone_Number CDATA #IMPLIED
Pager_Number CDATA #IMPLIED
Fax_Number CDATA #IMPLIED
User_Defined_1 CDATA #IMPLIED
Secondary_Contact_Name CDATA #IMPLIED
Secondary_Contact_Title CDATA #IMPLIED
Secondary_Contact_Location CDATA #IMPLIED
Secondary_Email_Address CDATA #IMPLIED
Secondary_Phone_Number CDATA #IMPLIED
Secondary_Mobile_Phone_Number CDATA #IMPLIED
Secondary_Pager_Number CDATA #IMPLIED
Secondary_Fax_Number CDATA #IMPLIED
Secondary_User_Defined_1 CDATA #IMPLIED
model_type ( SM_Customer ) #IMPLIED
>




<!ELEMENT GlobalCollection (( Device |
Location_Container )*) >
<!ATTLIST GlobalCollection
containment_relation CDATA "GlobalCollect"
collectionDescription CDATA #IMPLIED
Security_String CDATA #IMPLIED >
Appendix C: XML Examples

This section contains the following XML examples to help you work with the DTD:
Example 1 Importing into the Topology View (see page 91)
03-Apr-2017 90/311
Example 1 Importing into the Topology View (see page 91)

Example 2 Creating Connections (see page 92)
Example 3 Updating and Destroying (see page 93)
Example 4 Creating, Updating, and Destroying (see page 94)
Note: The element names in each example are highlighted in bold. Making the names bold
makes the examples easier to read; it is not intended to imply formatting necessary for the
XML input file.
Example 1 Importing into the Topology View

This example shows a basic input file that imports information into the CA Spectrum Topology view.
This file creates a Network container model in the Topology view. In the Network container, a LAN
container model is created. Within the LAN container two devices are created. The DNS name
deadlock identifies one device, and the IP address identifies the other device.
The complete_topology attribute of the Topology element is set to False. In this case, CA Spectrum
respects other models that previously exist in the Topology view. Consequently, this file only looks to
create models for entries that are listed in the XML file that are not already modeled. The models
that are created are placed in the Topology hierarchy as specified in the file. Models that previously
exist in the Topology hierarchy are not rediscovered but are moved to the container specified in the
file.
Note: When complete_topology is set to false, existing models that are in the container but
not listed in the import file are not sent to the Lost and Found. These models are sent to
Lost and Found when complete_topology is set to true.
<?xml version="1.0" standalone="no"?>

<Import>



<Topology complete_topology="false">
<Device ip_dnsname="10.253.9.17" model_type="GnSNMPDev"
<Device ip_dnsname="nmcss52-5" />
<Topology_Container model_type="Network" name="My Network"
Security_String="public" subnet_address="10.253.0.0"
subnet_mask="255.255.0.0">
<Topology_Container model_type="Lan" name="Lan1"
03-Apr-2017 91/311
subnet_mask="255.255.255.0">
<Device ip_dnsname="deadlock" />
<Device ip_dnsname="10.253.9.18" poll_interval="333" />
</Topology>
</Import>
Example 2 Creating Connections

The following example shows the creation of a connection between two ATM circuits and the
creation of a connection between two Frame Relay circuits. The example also shows a connection
between a FrameRelay DLCI port and an ATM VCL port.

<Import>
<Topology complete_topology="false">
<Connection create_pipe="false">
<Device ip_dnsname="10.253.32.225">
<Port identifier_name="atmVclTableInstance"
identifier_value="5.0.5"
circuit_name="ATM Link1"
circuit_id = "ATM 5017" />
</Device>
circuit_name="ATM Link1"
circuit_id = "ATM 5017" />
</Device>
</Connection>
<Connection>
<Port identifier_name="frCircuitTableInstance"
</Device>
<Device ip_dnsname="nmcss52-5">
<Port identifier_name="frCircuitTableInstance
</Device>
</Connection>




<Connection>
<Port identifier_name="frCircuitTableInstance"
</Device>
03-Apr-2017 92/311
identifier_value="5.0.17"/>
</Device>
</Connection>
<Connection>
<Port identifier_name="ifIndex" identifier_value="3"/>
</Device>
<Port identifier_name="ifPhysAddress"
identifier_value="0:4:27:C:91:C0"/>
</Device>
</Connection>
<Topology>
</Import>
Example 3 Updating and Destroying

This example illustrates the use of the Update and the Destroy elements.
The Update element contains a Location_Container element. This example updates the model name
by using the name and model_name attributes of the Location_Container element. The name
attribute is set equal to the current name and identifies the model to be updated. The model_name
attribute updates the value of the name attribute to Peace2.
The Update element also contains a Device element and Port element. The attributes identifer_name
and identifier_value are used to identify the port to be updated. The other attributes that are
specified are those attributes whose values are updated. The port model name is changed to port 2
and the poll_status is changed to False.
The Destroy element eliminates the device model deadlock. Any connections or ports that are
associated with deadlock are automatically destroyed. The Building container model Durham is also
eliminated. Any models that are contained within the Durham building container are sent to the Lost
and Found.
The Destroy element also removes the connection between the specified port on device nmcss52-5
and the specified port on nmcss52-3.

<Import>



<Update>




<Location_Container model_type="Building" name="Peace"
model_name="Peace2"/>

03-Apr-2017 93/311



<Port identifier_name="ifIndex" identifier_value="2"
model_name="port 2" poll_status="false" />
</Device>
</Update>



<Destroy>
<Device ip_dnsname="deadlock"/>
<Location_Container model_type="Building" name="Durham" />
<Connection>
<Port identifier_name="ifIndex"
identifier_value="1"/>
</Device>
identifier_value="10.253.8.18"/>
</Device>
</Connection>
</Destroy>
</Import>
Example 4 Creating, Updating, and Destroying

The following XML file illustrates most of the functionality of the elements that are contained within
the DTD. This file creates data in both the Topology and Location views, creates connections, updates
attributes, and destroys models and connections.
The first section of the XML file creates models and connections between these models in the
Topology view. The section begins with the Topology element, <Topology...>. The container and
device models are created first and then connections are established. This section ends when the
Topology element closes, </Topology>.
After the Topology element is closed, there is a section where another connection is created. This
section illustrates that you can create connections without nesting the Connection element within
the Topology element.
The next section of the file begins with the Location element, <Location...>. This section
demonstrates creating a container and device models in the Location view. This section ends when
the Location element closes, </Location>.
The next section begins with the Update element, <Update>. In this section, attribute values of a
container, a device, and a port are modified. You cannot know the current attribute values of each of
the elements that are represented by looking at the XML file. Therefore, it is not easy to discern
which elements are being updated. In general, each element contains an attribute that uniquely
identifies the model or port to be updated. The rest of the attributes are specified to update their
values. For example, the first element is the Location_Container element. The name attribute
uniquely identifies the model. The model_type attribute is specified to update its value, perhaps from
Region to Building. The only hierarchy that can be defined in the Update element is the Device/Port
03-Apr-2017 94/311
Region to Building. The only hierarchy that can be defined in the Update element is the Device/Port
hierarchy that specifies the port you would like to update. This section ends when the Update
element closes, </Update>.
The last section of this file uses the Destroy element. The Destroy element eliminates:
The device at 10.253.9.19
The container model Durham
The connection between the specified ports on device nmcss52-5 and the device at 10.253.9.17

<Import>



<Topology discover_connections="false" complete_topology="false">
<Device ip_dnsname="10.253.9.109" model_type="GnSNMPDev"
community_string="public" is_managed="false"/>
<Device ip_dnsname="10.253.9.17"
poll_interval="333" log_ratio="11"/>
<Device ip_dnsname="10.253.9.19" community_string="public"/>
<Device ip_dnsname="nmcss52-5" />
<Topology_Container model_type="Network" name="My Network"
subnet_mask="255.255.0.0" complete_topology="true">
<Topology_Container model_type="Lan"
name="MyLan" Security_String="public"
subnet_address="10.253.9.0"
subnet_mask="255.255.255.0">
community_string="public"
poll_interval="333"
log_ratio="5"/>
<Topology_Container model_type="IPClassC" name="my_net"
subnet_address="172.19.57.0">
<Device model_type="Pingable"
ip_dnsname="172.19.57.91"/>
<Device model_type="Fanout" ip_dnsname="1.2.3.4"/>
<Topology_Container model_type="Lan" name="lan2"
subnet_mask="255.255.255.0" complete_topology="true">
community_string="public"
poll_interval="333" log_ratio="11"/>
<Device ip_dnsname="10.253.32.101"/>
03-Apr-2017 95/311
model_type="GnSNMPDev"/>
<Device ip_dnsname="172.19.57.92" />
<Device ip_dnsname="10.253.32.225" model_type="M46_04"/>
<Connection>
<Port identifier_name= "frCircuitTableInstance"
</Device>
<Port identifier_name ="frCircuitTableInstance"
</Device>
</Connection>
<Connection create_pipe="false">
<Port identifier_name ="atmVclTableInstance"
identifier_value="3.1.52"/>
</Device>
<Port identifier_name ="atmVclTableInstance"
circuit_name="ATM 68"
circuit_id ="ATM ID 68"/>
</Device>
</Connection>
<Connection>
</Device>
</Device>
</Connection>
</Topology>
<Connection>
<Port identifier_name="ifPhysAddress"
identifier_value="0:E0:63:7C:19:61"/>
</Device>
</Device>
</Connection>



<Location complete_topology="true">
03-Apr-2017 96/311
<Location_Container model_type="Country" name="USA"

Security_String="whatever">
<Location_Container model_type="Region"
name="New Hampshire"
complete_topology="false">
<Location_Container model_type="Site"
name="Durham"
<Device ip_dnsname = "10.253.32.10"/>
<Device ip_dnsname = "172.19.57.93" />
<Location_Container model_type="Building" name="Durham"
Security_String="public">
<Location_Container model_type="Room" name="my_room"
Security_String="hahaha">
<Device ip_dnsname = "10.253.9.18"/>
Security_String="aprisma">
<Location_Container model_type="Room" name= "Lab 1">
</Location>



<Update>
model_modify_author="ltang"/>
<Device ip_dnsname="172.19.57.93" poll_interval="101"
model_name="haha" />




<Port identifier_name="ifIndex" identifier_value="2"
model_name="port 2" poll_interval="1103"
poll_status="false" log_ratio="12"/>
</Device>
<Topology_Container model_type="Lan" name="lan2"
Security_String="top secret"/>
</Update>


03-Apr-2017 97/311


<Destroy>
<Location_Container model_type="Building" name="Durham"/>
<Connection>
</Device>
</Device>
</Connection>
</Destroy>
</Import>
Appendix D: .modelinggatewayresource.xml
This section contains a copy of the .modelinggatewayresource.xml file. However, this copy might not
be the latest version of this file. For the latest version, use the actual file that shipped with your
Modeling Gateway Toolkit.

<TopologyImportExportResourceFile>




<Attributes
circuit_id = "0xc4042f"
circuit_name = "0xc40430"
community_string = "0x10024"
agent_port = "0x10023"
DeviceType = "0x23000e"
is_managed = "0x1295d"
log_ratio = "0x10072"
manager_name = "0x3dc0009"
model_modify_author = "0x11025"
model_name = "0x1006e"
name = "0x1006e"
poll_interval = "0x10071"
poll_status = "0x1154f"
TryCount = "0x110c5"
Security_String = "0x10009"
subnet_address = "0x1027f"
subnet_mask = "0x110b8"
subnet_list = "0x11953"
TimeOut = "0x110c4"
trapIPAddress = "0x3dc0007"
unique_id = "0x3dc0004"
03-Apr-2017 98/311
Value_When_Orange = "0x1000d"
Value_When_Red = "0x1000e"
Value_When_Yellow = "0x1000c"
LatestErrorStatus = "456008c"
Response_Time = "456008c"
AttrToWatch = "0x12a43"
MonitorPolicy = "0x12a3e"
MonitorPolicy_ID = "0x12a51"
Generate_Service_Alarms = "0x12a66"
Special_Cause_List = "0x12b47"
Cause_List_Control = "0x12d50"
Contact_Status = "0x10004"
Port_Status = "0x10f1b"
RM_Condition = "0x12a40"
Service_Health = "0x12a40"
Criticality = "0x1290c"
Condition = "0x1000a"
Condition_Value = "0x1000b"
AccumulationMethod = "0x4500007"
GuaranteeControl = "0x4500022"
GuaranteeNotes = "0x4500021"
GuaranteeDescription = "0x12a4b"
GuaranteeType = "0x4500018"
ServiceHealthType = "0x4500019"
ViolationThreshold = "0x450001e"
ViolationThresholdPercent = "0x4500024"
WarningThreshold = "0x450001d"
WarningThresholdPercent = "0x4500023"
SCHED_Daily_Repeat_Limit = "0x1299a"
SCHED_Duration = "0x12993"
SCHED_Recurrence_Multiplier = "0x1299b"
SCHED_Recurrence = "0x12994"
SCHED_Start_DoM = "0x12991"
SCHED_Start_DoW = "0x12990"
SCHED_Start_Hour = "0x1298f"
SCHED_Start_Minute = "0x1298e"
SCHED_Start_Month = "0x12992"
SCHED_Start_Day = "0x129e4"
SCHED_DayBitMask = "0x129da"
SCHED_Start_Year = "0x129e3"
SCHED_Start_MoY = "0x12b48"
SCHED_Description = "0x12bbc"
SLA_Control = "0x4500015"
SLA_Notes = "0x4500017"
SLA_ExpirationDate = "0x4500025"
SLA_Description = "0x12a4b"
DefaultMaxRTT = "0x4500001"
DefaultMeasureInterval = "0x4500002"
CustomerID = "0x12a44"
CustomerField4 = "0x12a39"
CustomerField5 = "0x12a3a"
CustomerField6 = "0x12a3b"
03-Apr-2017 99/311
CustomerField7 = "0x12a3c"
Contact_Name = "0x12a20"
Contact_Title = "0x12a21"
Contact_Location = "0x12a22"
Email_Address = "0x12a27"
Phone_Number = "0x12a23"
Mobile_Phone_Number = "0x12a24"
Pager_Number = "0x12a25"
Fax_Number = "0x12a26"
User_Defined_1 = "0x12a28"
User_Defined_2 = "0x12a29"
User_Defined_3 = "0x12a2a"
User_Defined_4 = "0x12a2b"
Secondary_Contact_Name = "0x12a2c"
Secondary_Contact_Title = "0x12a2d"
Secondary_Contact_Location = "0x12a2e"
Secondary_Email_Address = "0x12a33"
Secondary_Phone_Number = "0x12a2f"
Secondary_Mobile_Phone_Number = "0x12a30"
Secondary_Pager_Number = "0x12a31"
Secondary_Fax_Number = "0x12a32"
Secondary_User_Defined_1 = "0x12a34"
MOT_Threhold = "0x450002c"
MTBF_Threshold = "0x4500032"
MTTR_Thresshold = "0x450002f"
Policy_Name_List = "0x12a4a"
collectionDescription = "0x12a67"
/>




<ModelTypes
Universe = "0x10091"
Network = "0x1002e"
Lan = "0x1002d"
IPClassA = "0x103d5"
IPClassB = "0x103d6"
IPClassC = "0x103d7"
LAN_802_3 = "0x1003c"
LAN_802_5 = "0x1003d"
ATM_NETWORK = "0xaa000f"
EventAdmin = "0x3dc0000"
GlobalCollection = "0x10474"
World = "0x10040"
Country = "0x10041"
Region = "0x10042"
Site = "0x10043"
Sector = "0x10044"
Building = "0x10045"
03-Apr-2017 100/311
Section = "0x10046"
Floor = "0x10047"
Room = "0x10048"
Top_Org = "0x102cf"
Enterprise = "0x102d0"
Subsidiary = "0x102d1"
Division = "0x102d2"
Department = "0x102d3"
Org_Section = "0x102d4"
Work_Group = "0x102d5"
Org_Owns = "0x102da"
Schedule = "0x10456"
GnSNMPDev = "0x3d0002"
Fanout = "0x100ae"
Pingable = "0x10290"
WA_Link = "0x102e2"
Unplaced = "0x103d8"
RTM_Test = "0x4560000"
SM_Service = "0x1046f"
SM_AttrMonitor = "0x1046e"
SM_LatencyMon = "0x4500001"
SM_SLA = "0x4500002"
SM_Guarantee = "0x4500003"
SM_Customer = "0x1046c"
SM_CustomerGroup = "0x10477"
SM_ConnectMon = "0x4500000"
SM_ServiceMgr = "0x4500006"
CustomerManager = "0x10478"
SM_Service_Mgt = "0x4500007"
SM_SLA_Mgr = "0x4500008"
Correlation_Domain = "0x10467"
Correlation_Manager = "0x10469"
/>
<Relations
Collects = "0x10002"
MaintenenceScheduledBy = "0x10034"
SlmAgreesTo = "0x4500000"
SlmGuarantees = "0x4500001"
SlmHasGuarantee = "0x4500002"
SlmIsMeasuredBy = "0x4500003"
SlmMonitors = "0x4500004"
SlmOwns = "0x4500005"
SlmUses = "0x4500006"
SlmWatchesContainer = "0x4500007"
SlmContains = "0x4500008"
SlaPeriod = "0x4500009"
SlmSchedulesGuarantee = "0x450000c"
SlmHasServiceComponent = "0x450000a"
SlmContainsSLAs = "0x450000b"
Groups_Customers = "0x1003e"
GlobalCollect = "0x1003b"
/>

03-Apr-2017 101/311




<ImportConfiguration
do_not_process_pre_existing_devices_under_container_node = "false"
import_to_primary_ss_only = "false"
max_device_creation_threads = "50"
/>











































03-Apr-2017 102/311
export_port_attributes = "true"
export_from_primary_ss_only = "false"
/>






<RootContainerToExport model_type="Universe" model_name=""/>







<DeviceExportAttributes>
<name/>
<model_type attribute_id="0x10000"/>
<community_string/>
<agent_port/>
<poll_interval/>
<is_managed/>
<poll_status/>
<Security_String/>
<TimeOut/>
<TryCount/>
<Criticality/>
<Value_When_Orange/>
<Value_When_Red/>
<Value_When_Yellow/>
<Redundancy_Admin_Status attribute_id="0x11d2c" />
<Auto_Reconfigure_Interfaces attribute_id="0x11dd4" />
<Discover_Connection_After_Linkup_Trap attribute_id="0x11d25" />
<Device_Discovery_After_Reconfiguration attribute_id="0x11d27" />
<Generate_Redundancy_Alarms attribute_id="0x11dd6" />
<Create_Sub_Interfaces attribute_id="0x11f3c" />
<Topology_Relocate_Model attribute_id="0x11a80" />
<Disable_Trap_Events attribute_id="0x11cd0" />
<Enable_Spectrum_Management attribute_id="0x1295d" />
03-Apr-2017 103/311
<Hibernate_Device attribute_id="0x12aca" />

<Enable_Event_Creation attribute_id="0x129f8" />
<Redundancy_Admin_Status attribute_id="0x11d2c" />
<DeviceCPUUtilization_Threshold attribute_id="0x12ab9" />
<DeviceCPUUtilization_Reset attribute_id="0x12abb" />
<DeviceCPUUtilization_Duration attribute_id="0x12bce" />
<DeviceMemoryUtilization_Threshold attribute_id="0x12aba" />
<DeviceMemoryUtilization_Reset attribute_id="0x12abc" />
<DeviceMemoryUtilization_Duration attribute_id="0x12bcf" />
</DeviceExportAttributes>







<ContainerExportAttributes>
<name/>
<Security_String/>
<subnet_address/>
<subnet_mask/>
<subnet_list/>
<Value_When_Orange/>
<Value_When_Red/>
<Value_When_Yellow/>
<SelectMP_port attribute_id="0x118e4" />
</ContainerExportAttributes>












<PortExportAttributes export_changed_attribute_only="true" >
<poll_interval/>
<poll_status/>
<ok_to_poll attribute_id="0x11dd8" />
<PollPortStatus attribute_id="0x1280a" />
<LockConnection attribute_id="0x129f1" />
<TimeOut/>
<TryCount/>
<is_managed/>
<Enable_Event_Creation/>
<Criticality/>
<Alarm_On_Link_Down_Trap attribute_id="0x11fc2" />
03-Apr-2017 104/311
<Assert_Link_Down_Alarm attribute_id="0x12957" />

<Utilization_Threshold attribute_id="0x1294b" />
<Utilization_Reset attribute_id="0x1294f" />
<Utilization_Threshold_Violation_Duration attribute_id="0x12be4" />
<Inbound_Utilization_Threshold attribute_id="0x12d9f" />
<Inbound_Utilization_Reset attribute_id="0x12da0" />
<Inbound_Utilization_Threshold_Violation_Duration attribute_id="0x12da2" />
<Outbound_Utilization_Threshold attribute_id="0x12da3" />
<Outbound_Utilization_Reset attribute_id="0x12da4" />
<Outbound_Utilization_Threshold_Violation_Duration attribute_id="0x12da6" />
<Total_Packet_Rate_Threshold attribute_id="0x12da7" />
<Total_Packet_Rate_Reset attribute_id="0x12da8" />
<Total_Packet_Rate_Threshold_Violation_Duration attribute_id="0x12be3" />
<Error_Rate_Threshold attribute_id="0x1294d" />
<Error_Rate_Threshold_Reset attribute_id="0x12951" />
<Error_Rate_Threshold_Violation_Duration attribute_id="0x12be5" />
<Discarded_Threshold attribute_id="0x1294e" />
<Discarded_Threshold_Reset attribute_id="0x12952" />
<Discarded_Threshold_Violation_Duration attribute_id="0x12be2" />
</PortExportAttributes>
<SpectrumConfigurationExport model_type="VNM">
<Minimum_Disk_Space attribute_id="0x119d2" />
<Security_String/>
<Unmanaged_Trap_Handling attribute_id="0x11cce" />
<Trap_Storm_Rate attribute_id="0x122db" />
<Trap_Storm_Length attribute_id="0x122da" />
<Auto_Connects attribute_id="0x11f99"/>
<Device_Thresholds attribute_id="0x12acd" />
<Use_Full_Qualified_Host_Name attribute_id="0x12984" />
<Allow_Non_Admin_SNMP_Community_Edit attribute_id="0x12042" />
<Edit_Notes_By_Read_Only_User attribute_id="0x12043" />
<Set_isManaged_By_Read_Only_User attribute_id="0x129f3" />
<Consolidate_Users_In_Group attribute_id="0x12a1d" />
<Copy_Users_When_Copying_Group attribute_id="0x12a5e" />
<VLAN_Configuration attribute_id="0x129ad" />
<Log_When_Device_Cannot_Be_Contacted attribute_id="0x12943" />
<SpectrumConfigurationExport model_type="TopologyWrkSpc">
<Create_WA_Link_Model attribute_id="0x25e0033" />
<Create_LAN_IP_Subnet_Model attribute_id="0x25e000d" />
<Create_Physical_Addresses attribute_id="0x25e000c" />
<Create_Fanout_Models attribute_id="0x25e002e" />
<Run_ATM_Discovery attribute_id="0x25e002d" />
<IP_Route_Tables attribute_id="0x25e0006" />
<Source_Addr_Tables attribute_id="0x25e0025" />
<Spanning_Tree_Tables attribute_id="0x25e0026" />
<Proprietary_Disc_Tables attribute_id="0x25e002b" />
<ARP_Tables attribute_id="0x25e003a" />
<Traffic_Resolution attribute_id="0x25e002f" />
<Unmanaged_SNMP_Disc attribute_id="0x25e0034" />
<New_Device_In_Maint_Mode attribute_id="0x25e0035" />
<SpectrumConfigurationExport model_type="LostFound" >
03-Apr-2017 105/311
<Automatic_Model_Destruction attribute_id="0x11de1" />

<Model_Destruction_Interval_Hours attribute_id="0x11de3" />
<Model_Destruction_Interval_Minutes attribute_id="0x11de4" />
<SpectrumConfigurationExport model_type="FaultIsolation">
<ICMP_Support_Enabled attribute_id="0x11d98" />
<ICMP_Timeout attribute_id="0x11dab" />
<ICMP_TryCount attribute_id="0x11dac" />
<Lost_Device_TryCount attribute_id="0x12a0a" />
<Contact_Lost_Model_Destruction attribute_id="0x11fa8" />
<Destruction_Delay attribute_id="0x11fa9" />
<Destruction_Event_Generation attribute_id="0x11faa" />
<Router_Redundancy_Retry_Count attribute_id="0x12a09" />
<Port_Fault_Correlation attribute_id="0x129e6" />
<Unresolved_Fault_Alarm_Disposition attribute_id="0x129f4" />
<WA_Link_Fault_Isolation_Mode attribute_id="0x12adc" />
<SpectrumConfigurationExport model_type="LivePipes" >
<Live_Pipe_Enabled attribute_id="0x11df9" />
<Alarm_Linked_Port attribute_id="0x11fbd" />
<Suppress_Linked_Port_Alarms attribute_id="0x11fbe" />
<Port_Always_Down_Alarm_Suppression attribute_id="0x129fb" />
<SpectrumConfigurationExport model_type="AlarmMgmt" >
<Generate_Alarm_Event attribute_id="0x11f5f" />
<Add_Event_To_Alarms attribute_id="0x11f5c" />
<Use_Old_Alarm_Event attribute_id="0x11f5d" />
<Alarm_Update_by_Read_Only attribute_id="0x11f5e" />
<Alarm_Ageout_Time attribute_id="0x129ea" />
<Disable_Initial_Alarms attribute_id="0x11f5a" />
<Disable_Suppressed_Alarms attribute_id="0x11f5b" />
<Disable_Maint_Alarms attribute_id="0x11f59" />
<Alarm_Clear_By_Read_Only attribute_id="0x11fb2" />
<Ageout_Residual_Alarm_Only attribute_id="0x129ec" />
<SpectrumConfigurationExport model_type="PolicyManager" >
<Policy_Distribution_Mode attribute_id="0x4ad0007" />
<SpectrumConfigurationExport model_type="GlobalConfig" >
<SNMPv3Profiles attribute_id="0x12bd4" />
<HibernationCommSuccessTries attribute_id="0x12acb" />
</TopologyImportExportResourceFile>
03-Apr-2017 106/311
Model Type Editor
Introducing the Model Type Editor

This section introduces the Model Type Editor application and the database objects that you can
create using it, namely, model types, attributes, relations, and meta-rules.
The section also discusses model type inheritance, which is an important concept to understand
before creating and modifying model types.
Important! Before using the Model Type Editor, read Certification (https://docops.ca.com
/display/CASP102/Certification). The Certification space provides information on the
GnSNMPDev management module. You can use GnSNMPDev to represent a SNMP-
compliant network device that lacks a corresponding CA Spectrum management module.
You can also use GnSNMPDev as a toolkit to create new management modules that include
new, supporting device model types and application model types.

CA Spectrum Modeling Concepts (see page 108)
Getting Started with the Model Type Editor (see page 123)
Creating and Modifying Model Types (see page 132)
Attributes of Model Types (see page 132)
Standard Attribute Descriptors (see page 137)
Special Attribute Descriptors (see page 141)
Search for and Display Model Types (see page 146)
Search for and Display Attributes (see page 146)
Create a Model Type (see page 147)
Delete a Model Type (see page 148)
Working with Base Model Types (see page 150)
Import MIBs (see page 153)
Set Model Type Flags (see page 155)
Working with Attributes (see page 156)
Working with Attribute Groups (see page 161)
Working with Relations and Meta-Rules (see page 164)
Importing and Exporting Model Types (see page 171)
Running Reports on Model Types and Relations (see page 175)
03-Apr-2017 107/311
CA Spectrum Modeling Concepts

Contents
CA Spectrum and Model Type Editor (see page 108)
Model Types and Attributes (see page 109)
Models (see page 111)
Relations and Meta-Rules (see page 112)
Model Type Inheritance (see page 114)
Attribute Descriptors (see page 114)
Standard Hierarchy (see page 116)
Specialized Hierarchy (see page 117)
Model Type Precedence (see page 119)
Attribute Collapsing (see page 122)
CA Spectrum and Model Type Editor

CA Spectrum is an integrated management system that runs on the Solaris, Linux, and Windows
platforms. The CA Spectrum design is based on a client/server model. The server, called the
SpectroSERVER, includes the CA Spectrum knowledge base, which gets and stores all network
information. The client is the CA Spectrum user interface, called OneClick, which provides a graphical
representation of the network environment.
The SpectroSERVER provides intelligence and contains models of the actual network devices and their
relationships -- models that continuously collect data about the entities they represent and
collectively provide a comprehensive management perspective of the network. Through polling, the
CA Spectrum database gains extensive information about network devices, their relationships, and
their performance.
The OneClick client application provides a multi-dimensional picture of the SpectroSERVER database.
Users can retrieve and view the information maintained in the SpectroSERVER database, and they
can invoke the SpectroSERVER to control objects on the network. Network information can be
presented from various perspectives, including topological or geographical views.
CA Spectrum deploys model types, models, attributes, relations, and meta-rules to monitor network
infrastructure. Model types are the templates used to create models, and models are specific
instances of a model type. (The terms "model type" and "template" are used interchangeably in CA
Spectrum documentation.) Attributes are the characteristics of a specific model type, and relations
and meta-rules define how model types interact with each other. While models and associations are
defined using OneClick, the Model Type Editor lets you define model types, rules, relations, and
attributes.
The Model Type Editor is the Java-based application that you use to create, modify, and delete
modeling catalog objects. Because it is a thick-client application that accesses the SpectroSERVER
database, you must run it from the SpectroSERVER platform.
03-Apr-2017 108/311
Model Types and Attributes

A model type is a template that is used to create models, and it is defined by a specific set of
attributes. In turn, attributes are the database variables that collectively characterize the real-world
object represented by the model type. Model types range from simple with few attributes and
relationships to very complex with many attributes and relationships.
Complex model types are often derived by inheriting attributes from several, simpler model types.
The resulting combination constitutes a hierarchy of model types. Parent model types (model types
from which one or more other model types have been derived) are called base model types. Child
model types (model types that have been derived from one or more other types) are called derived
model types. The following illustration shows a sample model type hierarchy that illustrates model
type derivation.
Model Types and Attributes
In the illustration, Device is a base model type for three model types: PC Card, Hub, and Bridge. As
such, all three derived model types inherit the attributes of Device.
In turn, PC Card, Hub, and Bridge are each used as a base model type for another model type,
respectively, SNMP PC Card, SNMP MMAC, and SNMP Bridge. All of these derived model types inherit
the attributes of their immediate parent model type, and by extension, the attributes of the Device
model type. In addition, they also inherit the attributes of a model type named SNMP Protocol.
In the Model Type Editor, you can identify a model type's position in the model type hierarchy using
the Hierarchy tab. The tab shows the following for the current model type:
The base (parent) model types from which the current model type is derived
The derived (child) model types that are derived from the current model type
03-Apr-2017 109/311
spec--mte--hierarchytab_SCR
The Model Type Editor also provides an Attribute tab that shows the attributes of a model type and
their default values.
03-Apr-2017 110/311
spec--mte--attributestab_SCR
There are various rationales for attributes. Certain attributes, such as the name of a router or its IP
address, are necessary in order to uniquely identify a resulting model within the CA Spectrum
database. Other attributes relate a model to the SNMP object identifiers (OIDs) supported by the
model. Still others support CA Spectrum functionality. For example, Discovery_Precedence is used by
the Discovery program; Value_When_Red is used for alarm roll-up, and Polling_Interval is used to
determine how often CA Spectrum polls the given device for information.
Models
A model is an instantiation of a model type by the SpectroSERVER. All models instantiated from the
same model type have the same set of attributes and CA Spectrum intelligence. However, the values
for the attributes are unique to each model except in the case of Shared attributes (that is, attributes
for which the Shared flag is set).
As a simple example, the following illustration shows three models derived from a model type named
Building, which has three attributes: Modeltype_Name, Model_Name, and Floors. Because each
model is instantiated from the same model type, each model has the same value for
Modeltype_Name (a Shared attribute). However, the values for Model_Name and Floors vary.
03-Apr-2017 111/311
spec--mte--buildingdiagram_OTH
Note: A network administrator can add, edit, and delete models using OneClick. For more
information, see Modeling and Managing Your IT Infrastructure (https://docops.ca.com/display
/CASP102/Modeling+and+Managing+Your+IT+Infrastructure).
Relations and Meta-Rules

A relation is a database construct that defines a specific type of relationship between model types.
The following are examples of relations:
Contains
Collects
Executes
HASPART
Is_Adjacent_to
Monitors
Pings_Through
03-Apr-2017 112/311
Pings_Through
Schedules
Each relation is defined by one or, more typically, several rules called meta-rules. The meta-rules for
a relation apply the relation to specific model types, thereby defining how the model types can
interact with one another. As an example, the following are several of the meta-rules defined for the
Contains relation:
Building Contains Floor
Building Contains Room
Building Contains Section
Country Contains Building
Country Contains Region
Country Contains Site
Each meta-rule must have exactly one antecedent model type (the left-hand entry) and exactly one
predicate model type (the right-hand entry). Any model type can be an antecedent or a predicate for
any number of meta-rules.
OneClick uses the meta-rules for model types to establish the rules for interaction between specific
models instantiated from the model types. In CA Spectrum terms, instantiation of a meta-rule
between two models produces an association between the models, and each model can react to the
knowledge that it is associated with the other model. For example, consider the following meta-rule:
Country Contains Building
This might result in the following association between two specific models:
France contains Corporation001
There are two types of relations:
One-To-Many
A relation of this type defines how a single model of one model type relates to multiple models of
another model type. For example, Contains is a one-to-many type of relation. As such, it can have
one or more meta-rules that define one-to-many relationships between models. For example, it
includes a "Country contains Building" meta-rule, which specifies that a single model of the
Country model type can contain multiple models of the Building model type.
Many-To-Many
A relation of this type defines how multiple models of one model type relate to multiple models
of another model type. For example, Is_Adjacent_to is a many-to-many type of relation. As such,
it can have one or more meta-rules that define many-to-many relationships between models. For
example, it includes a "Device Is_Adjacent_to Device" meta-rule, which specifies that multiple
models of the Device model type can be adjacent to multiple models of the Device model type.
03-Apr-2017 113/311
The Model Type Editor provides a Relation tab that shows the meta-rules defined for a specific
relation.
spec--mte--metarules_SCR
Most relations in the modeling catalog that comes with the basic CA Spectrum package have meta-
rules that specify the model types to which the relations can be applied.
Model Type Inheritance

When you derive new model types from existing model types, the specifics of model type and
attribute inheritance are important to understand because the functionality of each model type
depends on its inheritance.
This section provides information on important concepts related to inheritance, namely, attribute
descriptors, standard versus specialized hierarchies, model type precedence, and attribute collapsing.
Attribute Descriptors
Attribute descriptors are the characteristics that define the attribute, for example, its type (boolean,
integer, text string, and so on) and default value.
An attribute has two types of descriptors:
03-Apr-2017 114/311
Standard descriptors: The values of these attribute descriptors are inherited by all model types
derived directly or indirectly from the base model type in which the attribute was first created
(referred to as the originating model type).
You can only modify the values of standard descriptors in the originating model type; you cannot
modify their values in derived model types.
Name, Attribute ID, and the Shared flag are three examples of standard descriptors.
Descriptors that can be specialized: Like standard attribute descriptors, the values of these
descriptors are inherited by all model types derived directly or indirectly from the base model
type in which the attribute was first created. However, unlike standard descriptors, you can
modify the values of these descriptors at any level in the model type hierarchy. This process is
called specialization.
When you modify a descriptor value in a derived model type, the new value overrides the
inherited value for that derived model type and any of its own derived (child) model types. Other
model types that are derived from the same base model type -- and that are unspecialized with
respect to the same attribute descriptor -- continue to inherit their descriptor values; this is also
the case for any of their derived (child) model types.
Important! The complete list of descriptors that you can specialize includes -- notably,
Default Value -- as well as the Extended Flags (Memory, Database, Polled, and Logged), OID
Prefix, OID Reference, and Polling Group, as identified in the following image.
03-Apr-2017 115/311
spec--mte--attributedescriptors_SCR
Standard Hierarchy
The following illustration shows a model type hierarchy whose attributes and their default values are
inherited through a standard hierarchical sequence.
03-Apr-2017 116/311
spec--mte--standardhierarchy_OTH
In the illustration, Model Type A is derived from Base Model Type, and, as a result, Model Type A
inherits attribute X and its default value of 1 from Base Model Type. In a similar manner, Model Type
B is derived from Model Type A, and, as a result, Model Type B inherits attribute X and its default
value of 1 from Model Type A.
This hierarchical relationship of inheritance is applied to all other model types derived from Model
Type A, Model Type B, or any of their descendants. Moreover, the relationship is maintained by the
database so that any change made to the value of the Default Value attribute descriptor in the
originating model type is immediately applied to all derived model types that inherit the descriptor
value.
As a simple example, assume you add a Technical_Assistance text string attribute to Base Model Type
with a telephone number as the default value. Model Type A, Model Type B, and all other model
types that derive from them would all inherit the Technical_Assistance attribute and, therefore, the
value of the Default Value attribute descriptor (the telephone number). If you then changed the
telephone number, all of the model types derived directly or indirectly from Base Model Type would
immediately inherit the new telephone number.
Specialized Hierarchy
In contrast to the standard hierarchy, the following illustration shows a model type hierarchy where
one derived model type inherits its default value but another does not.
03-Apr-2017 117/311
spec--mte--specializedhierarchy_OTH
In this illustration, the default value for attribute X (or, more specifically, the value of the Default
Value attribute descriptor for attribute X) in Model Type A is specified, not inherited. In other words,
the value inherited from Base Model Type is overridden and no longer used. As mentioned previously
in this section, this process is called specialization.
When you override a descriptor value that is inherited, you break the relationship to the base
(parent) model type for that attribute descriptor only. The inheritance relationship with respect to
the values of all other attribute descriptors is not affected. Furthermore, model types that are
derived from specialized model types behave exactly as if they were derived from unspecialized
model types. In the illustration, Model Type B inherits its default value for attribute X from Model
Type A just as it would if Model Type A were not specialized. If you were to change the default value
of attribute x in Model Type A, the default value of the same attribute in Model Type B would
immediately change as well. Because the inheritance relationship is in effect, this would be the case
even if you derived Model Type B before you made the change.
In reality, the attribute hierarchy often consists of a combination of inherited and specialized values,
particularly when multiple model types are derived from a common base model type. Moreover,
while specialization is most typical with respect to the Default Value attribute descriptor, it is possible
for any other descriptor that can be specialized. The following diagram illustrates a model type
hierarchy that uses both inheritance and specialization for an attribute (attribute X).
03-Apr-2017 118/311
spec--mte--specializedierarchy2_OTH
Note in the figure that Model Type C is specialized by introducing new attribute Y. Therefore, this
attribute is inherited by derived Model Type D.
Model Type Precedence

The process of inheriting attributes from base model types means that a derived model type can
inherit the same attribute from two or more inheritance paths that have a common originating model
type. To avoid ambiguity in this situation, the base model types are ranked according to the order in
which they are added as base model types for a derived model type, and this model type ranking
determines the inheritance path to use when a derived model type can inherit an attribute from
multiple paths. More specifically, the derived model type inherits the attribute from the base model
type with the lowest ranking.
When you first derive a model type from a base model type, that base model type is given a ranking
of 1. If you then add a second base model type to the derived model type, that second base model
type is given a ranking of 2. Subsequent base model types are assigned rankings in a similar manner.
As an example, consider the following model type derivation workflow:
03-Apr-2017 119/311
As an example, consider the following model type derivation workflow:
1. You derive model type A and model type B from a common base model type.
spec--mte--precedence_diagram1_OTH
The base model type defines attribute X, which is inherited by both derived model types. The
base model type is assigned a ranking of 1 with respect to both derived model types.
2. You derive model type C from model type A.
Model type C inherits attribute X from model type A, which, in turn, inherits the attribute
from the base model type. Because model type C was created based on model type A, model
type A is assigned a base model type ranking of 1 with respect to derived model type C.
3. You add model type B as a base model type of model type C.
03-Apr-2017 120/311
Model type B is assigned a base model type ranking of 2 with respect to derived model type C.
Because model type A has a lower ranking as a base model type, model type C inherits
attribute X from model type A, not from model type B.
In the Model Type Editor, the base model types for a given model type are listed in ranked
order, so you can identify the order of precedence for attribute inheritance.
03-Apr-2017 121/311
spec--mte--tabhierarchyrankings_OTH
Note: You can change a base model type's ranking by removing it and then re-adding it as a
base model type in a specific location in the list.
Attribute Collapsing
To maintain an attribute hierarchy that is as simple as possible, the Model Type Editor includes a
feature that eliminates unnecessary specialization. That is, if you modify the Default Value descriptor
(or any other descriptor that can be specialized) in a derived model type so that its value matches the
value in the corresponding descriptor in the base model type from which it immediately inherits the
attribute (that is, from an immediate parent model type), the database discards the modification and
instead inherits the descriptor value from the base model type. This process is called "attribute
collapsing;" its goal is to simplify a specialized hierarchy as much as possible by removing unnecessary
customizations.
Once the descriptor value reverts to the inherited value, if you subsequently change the descriptor
value in the base model type, the derived model type also receives the change (which is normal
inheritance behavior).
03-Apr-2017 122/311
You can identify the model type from which the current model type obtains its default value in the
Value Defined In field in the Component Detail panel, as shown in the following image.
Attribute Collapsing
Note: Attribute collapsing does not take place for default values if the attribute is Shared
(that is, the Shared flag is set).
Getting Started with the Model Type Editor

Contents
Using a Developer ID (see page 124)
Access Privileges With Developer ID (see page 125)
SpectroSERVER Database Protection (see page 126)
Considerations on Database Migration (see page 127)
About Starting the Model Type Editor (see page 127)
Start Model Type Editor from the Control Panel (see page 127)
Start Model Type Editor from the Command Line (see page 128)
Overview of the User Interface (see page 128)
Commit Changes to the SpectroSERVER Database (see page 129)
Sorting and Filtering Lists (see page 130)
Add and Remove Columns from Tables (see page 131)
Exit the Model Type Editor (see page 131)
03-Apr-2017 123/311
Before using the Model Type Editor, we recommend that you also read Certification (https://docops.ca.
com/display/CASP102/Certification). The section provides information about the GnSNMPDev
management module provided with CA Spectrum. You can use GnSNMPDev to represent an SNMP-
compliant network device that does not have a corresponding CA Spectrum management module.
You can also customize GnSNMPDev to extend its support, or you can use it as a toolkit to create new
management modules that include new, supporting device model types and application model types.
Using a Developer ID
CA Spectrum uses developer IDs to help ensure that objects such as model types that are created by
users and application integrators have unique identifiers and, therefore, can be distributed to other
users without conflict.
There are two types of developer IDs:
Registered developer IDs

This is a unique, CA-assigned developer ID that protects a developer's model types, attributes,
relations, and meta-rules from being edited by other users.
The default developer ID

This is the developer ID applied when the current user is not registered with CA as a CA Spectrum
developer; the code designation is DF, with a Developer ID value of 0xffff.
Whenever you create a model type, attribute, or relation, the Model Type Editor uses the developer
ID that is currently active (loaded in the database) to create the ID or handle for the new object. This
ID is either your unique, registered developer ID or the default ID.
The Model Type Editor also uses developer IDs to determine the access privileges of users with
respect to creating, modifying, and destroying modeling catalog objects (model types, attributes,
relations, and meta-rules).
Any developer can use the Model Type Editor as the default developer. However, the modeling
catalog objects created using the default developer ID are not protected.
To obtain a developer ID from CA, contact CA Spectrum Support (http://www.ca.com/support).
To be issued a developer ID, you must have purchased the Level 1 toolkit.
Note: For more information about the toolkit, see Spectrum Integrator (https://docops.ca.com
/display/CASP102/Spectrum+Integrator).
You can activate your developer ID by loading the developer information file that contains the ID into
the SpectroSERVER database. This is a one-time operation after you have initialized the database.
However, if you reinitialize the database, you must reload the information.
Note: Activate your developer ID using SSdbload with the -d option. For more information,
03-Apr-2017 124/311
Note: Activate your developer ID using SSdbload with the -d option. For more information,
see the discussion about loading developer information in Database Management (
https://docops.ca.com/display/CASP102/Database+Management).
Access Privileges With Developer ID

Your developer ID determines your access privileges with respect to model types, attributes,
relations, and meta-rules.
If you work in the Model Type Editor using the default developer ID, you can:
View, create, modify, delete, and export model types and attributes that were created with the
default developer ID. This includes modifying the derivation of model types by adding and
removing base model types.
View model types that were created by other registered developers.
Create, modify and delete relations and meta-rules that were created with the default developer
ID.
Export model types, attributes, relations, and meta-rules that were created with the default
developer ID.
Import model types, attributes, relations, and meta-rules from another compatible database.
Import a Management Information Base (MIB) text file.
If you work in the Model Type Editor using a registered developer ID, you can:
View, create, modify, or delete model types and attributes that were created with your registered
developer ID. This includes modifying the derivation of model types by adding and removing base
model types.
Create, modify, and delete relations and meta-rules that were created with your registered
developer ID.
Export model types, attributes, relations, and meta-rules that were created with your registered
developer ID.
Import model types, attributes, relations, and meta-rules from another compatible database.
Import a MIB text file.
Important! We recommend all users register with CA as a CA Spectrum developer to obtain

a registered developer ID.
03-Apr-2017 125/311
A registered developer can export model types, attributes, relations, and meta-rules that were
created using a registered developer ID. This not only removes ID conflicts, but also protects the
objects from accidental or deliberate modification. As indicated previously, if you use the default
developer ID, you can export only the model types, attributes, relations, and meta-rules that were
created with the default developer ID. It is probable that the IDs (handles) of these objects will
conflict with those on another system to which you might want to export the objects. In addition, the
exchange of such objects between systems using the default developer ID means that the objects are
susceptible to modification or corruption on the receiving system.
SpectroSERVER Database Protection

When a program or process such as the Model Type Editor accesses the SpectroSERVER database, a
soft lock file named .VNMDB.LOCK is created. The lock file is a safety feature that protects the
database by restricting access to one CA-developed application or process at a time. Because non-CA
applications or tools may not check for this lock, exercise care when using these applications to
prevent concurrent access to the SpectroSERVER database; this can result in corruption of the
database.
While lock files are removed automatically during normal shutdown of a CA Spectrum application, an
abnormal shutdown can leave behind a lock file erroneously. In rare situations like this, you can
manually remove the database lock. For information about how to do this, see Database
Management (https://docops.ca.com/display/CASP102/Database+Management).
Use of the Model Type Editor involves several risks to the SpectroSERVER database, such as the
accidental destruction of necessary model types, the inappropriate setting of attribute flags, and the
creation of more than one database with different model type derivations. For this reason, it is
recommended that you adopt the following strategies to help preserve the database:
Avoid editing the database that you use to model your network until absolutely necessary. First
test your model type changes using a test database.
Restrict the use of the Model Type Editor to individuals who are familiar with the long-term plans
for your model type derivation scheme. This can help to prevent unnecessary modifications to the
database.
Do not permit editing across multiple databases by more than one user using the same developer
ID. This practice creates conflicts between the IDs of modeling catalog objects, which can only be
corrected by manually recreating the affected objects. If two separate databases are being used,
verify that the database files are being modified with different developer IDs.
Use the database management utilities provided with CA Spectrum namely SSdbload and
SSdbsave to initialize and copy the database. You may get unpredictable results if you use
another method.
Note: For information about using these utilities, see Database Management .
03-Apr-2017 126/311
Considerations on Database Migration

It is recommended that you record all changes that you make with the Model Type Editor because
some changes are not migrated when the database is updated to a later version of CA Spectrum.
Specifically, if you change attributes (for example, flag settings), the model type hierarchy, or
relations and associated meta-rules in the model types supplied by CA or another developer (vendor),
most likely the changes will not be migrated when the database is upgraded, and you will need to
reapply them manually.
To preserve the default values of attributes, you can enable the Preserve Value attribute descriptor
flag on the relevant attributes. This flag prevents changed default values from being overwritten by
subsequent database updates. However, be aware that enabling this flag may prevent you from
receiving intended changes pertaining to the same attributes.
About Starting the Model Type Editor

To start the Model Type Editor for the first time, obtain a registered developer ID. You can activate
the ID by loading the information into the SpectroSERVER database.
Note: For more information, see Database Management (https://docops.ca.com/display

/CASP102/Database+Management) .
Important! Only one application or process can access the SpectroSERVER database at a
time. As a result, after you start the Model Type Editor, all other CA Spectrum applications,
including the SpectroSERVER, are denied access. While CA-developed applications
automatically deny access to other CA applications as needed, be aware that some third-
party applications do not. Database corruption can result.
In rare situations, the SpectroSERVER database is not closed properly by a process, for example,
during a power failure. In these situations, the database lock erroneously remains in effect and
prevents you from starting the Model Type Editor. To use the Model Type Editor, you must have read
and write permissions to the files in the <$SPECROOT>\SS directory.
Note: For information about removing a database lock, see the Database Management (
https://docops.ca.com/display/CASP102/Database+Management).
Start Model Type Editor from the Control Panel

You can start the Model Type Editor from the Control Panel.
Follow these steps:
03-Apr-2017 127/311
Follow these steps:
1. Stop the SpectroSERVER if it is running.
2. Verify that no other programs that can access the SpectroSERVER database are running.
3. Open the CA Spectrum Control Panel and click Configure, Model Type Editor.
The Model Type Editor opens. The Root model type is set as the current model type. The Root
model type is the model type at the highest point in the model type hierarchy.
Start Model Type Editor from the Command Line

You can also start the Model Type Editor from the command line.
Follow these steps:
1. Stop the SpectroSERVER if it is running.
2. Verify that no other programs that can access the SpectroSERVER database are running.
3. Log in to a shell environment if you are running on Unix or Linux, or open a command prompt
if you are running on Windows.
4. Change to the directory that contains the SpectroSERVER database that you want to modify
using the Model Type Editor.
Note: The executable file for the Model Type Editor is installed in <$SPECROOT>/SS-
Tools, but it must be called from the directory that contains the SpectroSERVER
database that you want to modify. Typically, this directory is CA Spectrum/SS. The
directory should contain the database files, which consist of paired *.db and *.ix
files, miscellaneous files, and supporting subdirectories.
5. Enter the following command:
../SS-Tools/mte
The Model Type Editor opens. The Root model type is set as the current model type. The Root
model type is the model type at the highest point in the model type hierarchy.
Overview of the User Interface

The following image identifies the main work areas, or panels, in the Model Type Editor user
interface.
03-Apr-2017 128/311
spec--mte--ui_SCR
Use the Navigation panel on the left to search for and select a model type, attribute, or relation.
Information about a selected object appears in the Contents panel on the right. Use the Contents
panel to modify the object, delete the object, or create related objects (for example, to derive a new
model type from the current model type).
When you work with attributes, a Component Detail panel lets you view and modify the descriptor
values of the current attribute.
Commit Changes to the SpectroSERVER Database

While you work in the Model Type Editor, you work with a temporary cache of database objects
called the working catalog. The Model Type Editor adds only the database objects that are required
for your activities to the working catalog.
03-Apr-2017 129/311
The Model Type Editor automatically saves any changes that you make to model types, attributes,
relations, and meta-rules to the working catalog. You can add them to the permanent catalog in the
SpectroSERVER database on demand, or you can add them when you exit the application. You are
prompted to add them when you exit the application to avoid losing your work.
You can commit changes to the SpectroSERVER database on demand.
Follow these steps:
1. Click File, Commit to Database.

A confirmation dialog opens.
2. Click OK.
Your changes are saved in the permanent catalog in the SpectroSERVER database. As a result,
subsequent calls to the database for the affected objects retrieve the updated versions of
those objects.
Sorting and Filtering Lists

To make it easier to work with large lists of modeling catalog objects (for example, model types or
attributes), you can sort the lists in tables in ascending or descending order by clicking any column
header. You can also sort lists using multiple column headers. For example, the following image
shows a list of attributes first sorted in ascending order by Type and then sorted in ascending order
by Attribute Name, as indicated by the icons in the column headers.
spec--mte--sortedattributes_SCR
You can also use the Filter and Search text boxes provided on the various tabs in the Model Type
Editor to display only the catalog objects whose names or IDs include a specific character string
regardless of case (uppercase or lowercase). In the Filter text boxes, this limits the list of already
displayed names. In the Search text box for attributes, this narrows the search criteria applied against
the working catalog.
Keep in mind the following as you filter and search for modeling catalog objects:
To filter lists by ID (for example, model type ID), the ID column must be displayed in the table.
The Search text box for attributes always searches using both the attribute name and attribute ID
as criteria.
In most cases, a filter or search criterion remains in effect until you clear it by deleting the
03-Apr-2017 130/311
In most cases, a filter or search criterion remains in effect until you clear it by deleting the
character string. There are a few actions that automatically clear a filter, for example, when you
add a new attribute to a model type.
Add and Remove Columns from Tables

You can modify the information that is displayed in any table in the Model Type Editor by adding and
removing columns from the table.
Follow these steps:
1. Right-click the table heading.

The Table Preferences dialog opens.
2. Click the Columns tab, and select the columns you want to display.
3. (Optional) Change the table sorting and font using the controls on the Sort and Font tabs.
4. Click OK.
Exit the Model Type Editor

When you close the Model Type Editor, you are prompted to save any changes that you have made
to the working catalog. Saving them propagates the changes to the SpectroSERVER database.
Note: For information about the difference between the working catalog and the
permanent catalog, see Commit Changes to the SpectroSERVER Database (see page ).
Follow these steps:
1. Click File, Exit.

2. Click OK.
If you have made changes to the working catalog that is stored in cache, you are prompted to
save the changes to the permanent catalog in the SpectroSERVER database.
3. Do one of the following:
To save the changes to the permanent catalog, click Yes.
To discard the changes, click No.
The changes are saved, if appropriate, and the Model Type Editor is closed.
03-Apr-2017 131/311
Creating and Modifying Model Types

Creating and Modifying Model Types
This section provides information about how to do the following:
Extend and customize the default modeling catalog provided with CA Spectrum by creating and
modifying model types.
lmport MIBs.
Create and manage attribute groups.

Attribute groups make it easier to work with logically related attributes in the Model Type Editor.
Attributes of Model Types

Contents
Developer ID (see page 133)
Model Type Name (see page 133)
Model Type ID (Handle) (see page 133)
Base Model Types (see page 134)
Derived Model Types (see page 134)
Model Type Flags (see page 134)
Custom Attributes (see page 136)
A model type is defined by the following attributes and classes of attributes:
Developer ID
Model type name
Model type ID (handle)
Base model types
Derived model types
Flags
Custom attributes
03-Apr-2017 132/311
Developer ID
The developer ID that was active when the attribute was created. This can be a registered ID
obtained from CA or the default ID. Once a developer ID is assigned to an attribute, it cannot be
changed.
After you create an attribute, the access privileges of users for modifying, deleting, and exporting it
are determined based on whether the active developer ID matches the developer ID associated with
the attribute.
Model Type Name

A descriptive identifier that typically describes the model type's function. Model type names should
be a maximum of 128 characters and should only consist of letters, numbers, underscore (_)
characters, and dashes (-). Spaces, punctuation, or other symbols should not be used.
Note: A model type name does not need to be unique across the modeling catalog, but you
should help ensure it is unique across the model types created under a given developer ID.
CA Spectrum differentiates model types using both the model type name and the
developer ID component in the model type ID.
While you can rename a model type, be aware that this affects the AlertMap file that is specific to the
model type because the file is located in the following directory:
SS/CsVendor/<developer name>/<model type name>
If you rename a model type, you will need to manually create a new directory based on the new
model type name and then move the AlertMap file.
Also be aware that it is possible -- although unusual and discouraged -- that an inference handler
depends on the name of a model type rather than its model type ID (handle).
Model Type ID (Handle)

A unique ID that is assigned to the model type when the model type is created. The ID is generated
by ORing together the value of the active developer ID and a counter value in the range from 0x0001
and 0xFFFF, as shown in the following illustration.
03-Apr-2017 133/311
spec--mte--modeltypeID_OTH
Once a model type ID is assigned to a model type, it cannot be modified. Additionally, if the model
type is deleted, the ID is not reused.
Base Model Types

A ranked list of parent model types from which the current model type directly inherits attributes and
SpectroSERVER intelligence.
Because a model type can inherit the same attribute from two or more inheritance paths that have a
common originating model type, the ranking of the base model types is used to determine the
inheritance path.
You cannot remove attributes inherited from a base model type, and you have limited capabilities to
edit them. To remove an inherited attribute, or to have full editing capabilities, you must use the
same developer ID that was active when the model type was created, and you must make the change
in the originating model type. The originating model type is the model type in which the attribute was
created.
Derived Model Types

An alphabetically sorted list of child model types that are directly derived from the current model
type. That is, the derived model types inherit attributes and SpectroSERVER intelligence from the
current model type -- and by extension -- from the base model types of the current model type.
Model Type Flags

There are several model type flags that control basic characteristics of a model type.
03-Apr-2017 134/311
You can only modify flag settings for a model type if you are using the developer ID that
was active when the model type was created.
The following describes each model type flag:
Visible
If enabled (checked), the model type is exposed in the output when you run a report on the
modeling catalog using the reports database utility provided with CA Spectrum. If disabled (not
checked), the model type is only exposed in the output if the model type was creating using the
developer ID that is currently loaded in the database. The default value is enabled.
Note: The Visible flag does not affect what a user can view in the Model Type Editor or in
OneClick, nor does it affect the operation of the SpectroSERVER. However, future releases
of CA Spectrum may respect the flag and stops access to model types and models when
the flag is disabled. For more information about the reports utility, see Database
Management (https://docops.ca.com/display/CASP102/Database+Management).
Instantiable
If enabled (checked), models of the model type can be created in the SpectroSERVER database by
users and inference handlers. If disabled (not checked), models of the model type cannot be
created, and the model type is not available in OneClick when creating a model by model type.
The default value is disabled.
Changing the condition of the Instantiable flag for a model type does not affect existing models of
that type. For example, if you were to disable the flag after creating models A and B, models A
and B would be unaffected. However, you could not create additional models after disabling the
flag.
Derivable
If enabled (checked), the model type can be used as a base model type from which other model
types can be derived. If disabled (not checked), the model type cannot be used as a base model
type. The default value is enabled.
CA Spectrum checks the Derivable flag only as new model types are being created. In other
words, if you derive several model types from model type A and then disable the Derivable flag
for model type A, the newly derived model types are unaffected, but you are no longer able to
derive additional model types from model type A.
No Destroy
If enabled (checked), models of the model type cannot be deleted from the SpectroSERVER
database by users and inference handlers. If disabled (not checked), models of the model type
can be deleted. The default value is disabled.
Note: You can only enable this flag if you also enable the Instantiable flag.
03-Apr-2017 135/311
Unique
If enabled (checked), only one model of the model type can exist in the SpectroSERVER database.
If disabled (not checked), additional models of the model type can exist. The default value is
disabled.
CA Spectrum checks the Unique flag only as models are being created. If you create several
models of a model type and then disable the Unique flag, the previously created models are
unaffected, but you are no longer able to create additional models of the model type.
Required
If enabled (checked), the SpectroSERVER creates a model of the model type at server startup if a
model does not already exist. If disabled (not checked), a model of the model type is created only
if requested by a user, inference handler, or application. The default value is disabled.
Custom Attributes
In addition to the model type attributes described earlier in this section (such as model type ID), a
model type has many other attributes that are inherited from base (parent) model types or that
originate in the model type itself. You can view this list of attributes on the Attributes tab in the
Contents panel, as shown in the following image.
03-Apr-2017 136/311
spec--mte--attributestab_SCR
You can click the Attribute Name column header to sort the attribute list alphabetically in ascending
or descending order.
The Originating Model Type column displays the model type in which each attribute was created.
You can click the Originating Model Type column header to sort the list alphabetically in ascending or
descending order. This lets you group together and, therefore, identify all of the attributes in the
current model type that originate in the model type itself or in a base (parent) model type.
The values for the attribute descriptors of the selected attribute are displayed in the Component
Detail panel.
Standard Attribute Descriptors

Standard Attribute Descriptors
03-Apr-2017 137/311
As discussed earlier in this section, every attribute is described by a set of characteristics called
attribute descriptors. The following are attribute descriptors that you can only modify in the
originating model type (the model type in which the attribute was defined):
Standard Attribute Descriptors (see page 137)
Developer ID (see page 138)
Attribute Name (see page 138)
Attribute ID (Handle) (see page 138)
Type (see page 139)
Flags (see page 139)
Group Name and Group ID (see page 141)
Developer ID
The developer ID that was active when the attribute was created. This can be a registered ID
obtained from CA or the default ID. Once a developer ID is assigned to an attribute, it cannot be
changed.
After you create an attribute, the access privileges of users for modifying, deleting, and exporting it
are determined based on whether the active developer ID matches the developer ID associated with
the attribute.
Attribute Name
An attribute name is a descriptive identifier. Attribute names should be a maximum of 128 characters
and should only consist of letters, numbers, underscore (_) characters, and dashes (-). Spaces,
punctuation, or other symbols should not be used.
Note: An attribute name does not need to be unique across the modeling catalog, but it
should be unique across the attributes in the model type that were created using the same
developer ID. In other words, within a single model type, two attributes can have the same
name if they were created using different developer IDs.
Attribute ID (Handle)
A unique ID that is assigned to the attribute when the attribute is created. The ID is generated by
ORing together the value of the active developer ID and a unique sequence number (counter value),
as shown in the following illustration.
03-Apr-2017 138/311
spec--mte--attributeID_handle_OTH
Once an attribute ID is assigned to an attribute, it cannot be modified. Additionally, if the attribute is

deleted, the ID is not reused.
Type
The attribute type defines the kind of data that the value of the attribute can hold. If the attribute
represents a managed object that is defined in the MIB, you should set the type to correspond to the
type defined in the MIB.
If an attribute requires a list of values, you must select the List check box.
Note: After you create an attribute, you cannot change its type or whether it stores a single
value or a list of values. You must delete the attribute and create a new one of the desired
type. There are two exceptions to this. First, you can change the type from Octet String to
Text String, and vice versa. Second, if the type is numeric (Integer, Counter, Enumeration,
Gauge, or Time Ticks), you can change from one of these numeric types to another.
Flags
Flags -- also referred to as descriptor flags -- inform the SpectroSERVER of the characteristics of the
attribute, for example, who can access the attribute's value. The following describes each flag.
External
Indicates the attribute value is maintained outside of the SpectroSERVER and that update of the
value is done either at a polling interval or upon user request.
03-Apr-2017 139/311
Note: If you set this flag, you must supply an OID prefix, which specifies the location of the
managed variable in the MIB. Also note that if you set this flag, you cannot set the Shared
flag.
Readable
Informs the SpectroSERVER that a client or other application can read the attribute value from
the SpectroSERVER database.
If you set the External flag, you should set this flag in accordance with the MIB definition of the
Readable variable for the attribute. Otherwise, you can set this flag as desired.
Writable
Informs the SpectroSERVER that a client or other application can write the attribute value to the
SpectroSERVER database.
If you set the External flag, you should set this flag in accordance with the MIB definition of the
Writable variable for the attribute. Otherwise, you can set this flag as desired.
Shared
Declares that only one value exists for the attribute and that all models of the given model type
share the same value. The value is not duplicated for each model in memory or in the database.
Note: You can only set this flag if you also set the Database flag or the Memory flag. Also,
if you set the External flag or the Polled flag, you cannot set this flag.
Guaranteed
Guarantees that the attribute will continue to exist and can be used in future model type
derivations. Once set, this flag cannot be disabled except by the developer who created the
attribute.
Note: Setting this flag only guarantees the presence of the attribute, not its value or
values.
If this flag is disabled, any Model Type Editor user can enable (set) or disable the Extended flags of
the attribute. If this flag is enabled, users having developer IDs other than the one used to create
the attribute can only set the Extended flags; they cannot disable them. The user having the
developer ID used to create the attribute can set or disable the Extended flags at any time.
Global
Indicates that the attribute's value will be kept consistent across duplicate models in all
landscapes in a distributed SpectroSERVER (DSS) environment.
Global attributes are only maintained for models of the User and UserGroup model types. These
are duplicate model types, that is, across a distributed environment, multiple models of these
types effectively represent the same user or user group. As such, a change to a model in one
landscape should be propagated to all corresponding, duplicate models in all other landscapes.
Note: You can only set this flag if you also set the Memory flag or the Database flag.
03-Apr-2017 140/311
Preserve Value
Indicates that imported files will not overwrite the attribute's default value currently stored in the
database.
If you customize the default values of one or more model types to meet specific requirements,
and then you set this flag, your customizations (the specialized default values) will remain in place
when the model types are updated by subsequent versions of CA Spectrum.
If you are the owner of the attribute (that is, the attribute was created using the developer ID that is
currently active), you can modify all of the flags described in this section in the originating model type
regardless of whether you are the owner of the associated model type.
If you are not the owner of the attribute, or if the attribute is inherited, you cannot modify these
flags. However, you can modify the attribute's extended flags.
Group Name and Group ID

A group is a logical collection of related attributes in a model type. Groups make working with related
attributes easier because they let you to define and use a user-defined sorting mechanism in the
Model Type Editor. You can create groups, assign attributes to them, and then add the Group Name
or Group ID as a column header in the table of attributes on the Attributes tab in the Contents panel.
This lets you to then click the column header to quickly group together and view together all of the
attributes within a group.
Group Name specifies the name of the group to which the attribute is assigned, and Group ID
specifies the ID of that group.
Like for any standard descriptor, you can change the group to which an attribute is assigned if you are
modifying the model type in which the attribute was created, and if you are using the developer ID
that was used when the attribute was created (that is, you own the attribute).
By default, an attribute has a Group ID value of 0x00000000, which indicates the attribute is not
assigned to a group. If you assign an attribute to a group, and you subsequently decide it should not
be assigned to a group, you must reassign the attribute to the Root group. You cannot restore a
Group ID value of 0x00000000 in the Model Type Editor.
Note: If you set an attribute's Group Name to the name of another developer's attribute
group, and that developer's attribute group is not distributed with the next version of CA
Spectrum, the attribute's Group Name value is reset to <no group>, and its Group ID value
is reset to 0x00000000 to indicate it is not assigned to a group.
Special Attribute Descriptors

Special Attribute Descriptors
03-Apr-2017 141/311
attribute descriptors. The following are attribute descriptors that you can specialize; you can modify
them at any level of the inheritance hierarchy:
Special Attribute Descriptors (see page 141)
Default Value (see page 142)
Extended Flags (see page 142)
OID Prefix and OID Reference (see page 144)
Polling Group (see page 145)
Default Value
The initial value or values for the attribute. An attribute can inherit its default value from a base
model type or specify its own default value (a process called specialization). In the latter case, all
model types derived from the specialized model type inherit the changed attribute value.
Note: While you can specify a default value for an attribute using this attribute descriptor
of a model type, the actual value or values of the attribute are often different in models.
This is definitely the case for external attributes (attributes for which the External flag is
enabled), since these attributes maintain their values by polling devices at specified
intervals or making updates upon user request.
Extended Flags
Extended flags -- also referred to as extended descriptor flags -- inform the SpectroSERVER of
additional characteristics of the attribute, for example, whether the attribute should be polled.
You enable and disable an attribute's extended flags using the Model Type Editor, but the flags are
used by the SpectroSERVER.
If an attribute's Guaranteed flag is disabled, any Model Type Editor user can enable or disable the
extended flags. If the Guaranteed flag is enabled, users having developer IDs other than the one used
to create the attribute can only enable the Extended flags; they cannot disable them. The user having
the developer ID used to create the attribute can enable or disable the extended flags at any time.
The following list describes each extended flag.
Memory
Stores a copy of the attribute's value in memory. When the SpectroSERVER is restarted, the value
is reset to the default value; the value in memory is not preserved.
Note: You must set either this flag or the Database flag if you set either the Shared flag or
the Global flag.
Database
03-Apr-2017 142/311
Database
Stores a copy of the attribute's value in the database so that it is preserved across SpectroSERVER
restarts.
Note: You must set either this flag or the Memory flag if you set either the Shared flag or
the Global flag.
Polled
Informs the SpectroSERVER that the attribute should be polled at the polling interval in order to
update its value. This is only meaningful if the External flag is also set. If the Memory flag is also
set for the attribute, the value retrieved by the poll is also stored in memory.
Note: You cannot set this flag if you set the Shared flag.
If you set this flag, you should assign the attribute to an appropriate polling group; all attributes
of a polling group are polled together. If you set both this flag and the Logged flag, you must
group the attribute with other attributes that also have both the Polled and Logged flags set.
Logged
Causes the value of the attribute to be recorded in the Distributed Data Manager (DDM)
database. If you enable this flag, you should assign the attribute to an appropriate polling group;
all attributes of a polling group are logged together. If you enable both this flag and the Polled
flag, you must group the attribute with other attributes that also have both the Polled and Logged
flags enabled.
Note: Logging occurs at a user-specified interval stored in the Poll_Log_Ratio attribute. By

default, this attribute is set to 0 for device model types, which effectively disabled CA
Spectrum's native logging method. If you require the logging of device, attribute, and port
statistics, it is recommended that you use [assign the value for sslog in your book] instead
of the native method, the latter of which writes the information to the Distributed Data
Manager (DDM) database. [assign the value for sslog in your book] is a CA Spectrum
command-line application that lets you to log statistics directly to ASCII files, which
reduces the load on the DDM database and eliminates the need to export the data. Of
equal importance, [assign the value for sslog in your book] gives you greater control over
what data to log and how frequently to log it. For more information, see the [assign the
value for sslog in your book] User (https://docops.ca.com/display/CASP102/SSLogger)section.
External attributes that are set to be polled and logged may return "noSuchName" errors when a
management module is based on a more current firmware version than the managed device
supports. To reduce unnecessary network traffic, CA Spectrum automatically suspends normal polling
and logging for attributes that return this error, and moves the attribute to the unsupported polling
attribute group.
Once an attribute has been moved to the unsupported polling attribute group, CA Spectrum
generates an event (0x10970). By default, this event is not logged and does not generate an alarm.
However, you can change this event processing using the Event Configuration application in OneClick.
CA Spectrum attempts to read the attribute at the interval specified by the
03-Apr-2017 143/311
CA Spectrum attempts to read the attribute at the interval specified by the

unsupported_attr_poll_interval. By default, the value of the unsupported_attr_poll_interval is 12
hours. This value can be changed by manually adding the parameter and the desired interval (in
seconds) to CA Spectrum's .vnmrc file.
When an attribute that had previously been reporting a "noSuchName" error reports a successful
poll, CA Spectrum generates an event (0x10971). By default, this event is not logged and does not
clear an alarm. However, you can also change this event processing using the Event Configuration
application.
Thus, the unsupported_attr_poll_interval lets normal polling and logging for an attribute to resume
automatically without requiring a SpectroSERVER restart or the destruction and recreation of the
models that have the attribute.
Note: For more information about the unsupported_attr_poll_interval, see the Distributed
SpectroSERVER Administration (https://docops.ca.com/display/CSP/Administrating) section. For
more information about the Event Configuration application, see the Event Configuration
User (https://docops.ca.com/display/CASP102/Event+Configuration)section.
OID Prefix and OID Reference

The OID Prefix descriptor and OID Reference descriptor apply only to attributes that have the
External flag enabled, that is, attributes that represent managed variables within tables in a MIB.
The OID Prefix specifies the column within the MIB table that contains the variable. You must use
dotted-decimal notation when entering the OID prefix.
The OID Reference (instance ID) specifies the name of an attribute whose value serves as an index
used to define the instance of the variable within the column.
The OID prefix is concatenated with the OID reference to define a complete object identifier (OID) for
the variable being monitored. As an example, the following image shows the resulting OID formed
using the following:
An OID Prefix set to the OID for EnetPortColls
An OID Reference set to the ID of an internal attribute, defining the instance ID.
03-Apr-2017 144/311
spec--mte--OIDPrefix_OID Reference_OTH
Note: A managed variable does not always require an OID reference. You can enter a
complete OID with instance ID in the OID Prefix field.
Polling Group
The polling group to which the attribute belongs. All of the attributes in a group are polled together
and logged together. The SpectroSERVER polls groups of pollable attributes by polling group, one at a
time beginning with the group with the lowest number.
Specify a number between 0 (zero) and 255 inclusive. If you do not specify a value for a new or
existing attribute, the attribute is automatically given a value of 0.
When attributes are polled but not logged (that is, the Polled flag is enabled, but the Logged flag is
disabled), the only limit to the number of attributes within a polling group is the transmission length
limits imposed by the following:
The transmission protocol (Ethernet, FDDI, and so on)
The management protocol (CA proprietary, SNMP, and so on)
03-Apr-2017 145/311
Search for and Display Model Types

You can search for a model type in the working catalog by name or ID.
Follow these steps:
1. In the Navigation panel, click the Model Types tab.

The names of all of the model types in the modeling catalog are listed.
2. In the list, select the name of the model type that you want to examine.
To locate and select a specific model type, you can take the following steps:
Enter a text string in the Filter text box to filter the list to include only the model types
whose names or IDs contain the string. To filter the list by ID, the ID column must be
displayed in the table.
Click the Model Type bar at the top of the list to change the alphabetical sorting from
ascending to descending or vice versa.
The selected model type becomes the current model type, and information about it is
displayed in the Contents panel.
3. To navigate to a base (parent) or derived (child) model type of the current model type, take
the following steps:
a. Click the Hierarchy tab in the Contents panel.
b. Double-click a base or derived model type to make it the current model type.
Note: You can filter the list of base or derived model types using the Filter
text boxes.
c. Repeat the preceding step as many times as needed to navigate to the desired model
type in the model type hierarchy.
Search for and Display Attributes

You can search for an attribute in the working catalog by name or ID.
Follow these steps:
1. In the Navigation panel, click the Attributes tab.
2.
03-Apr-2017 146/311
2. In the Search text box, enter a text string to examine against the attribute names and IDs.
(You do not need to display the ID column in the table to search by ID.)
The attributes with names or IDs that include the string that you entered are displayed in the
list. In addition, the originating model type for each attribute is displayed. The originating
model type is the model type where the attribute was created. Use this model type to modify
all of the descriptors for an attribute.
3. Select the name of the attribute that you want to examine from the list.
The corresponding originating model type is made the current model type in the Contents
panel, and information about the attribute you selected is displayed in the Component Detail
panel.
Create a Model Type

When you want to represent a new device or some other entity that is not currently defined as a
model type in the CA Spectrum database, you must create a model type.
Follow these steps:
1. Determine the attributes that are required for the new model type.
2. Identify the base model types from which the new model type can inherit its attributes or
inherit as many of them as possible.
3. Set the existing model type that has most of the attributes that you need for the new model
type as the current model type.
This is the model type from which you will directly derive the new model type.
4. Click (Derive a new Model Type).
Note: If you are not able to click the button, verify that the current model type has
its Derivable flag set. You cannot derive a model type from the model type unless
this is the case.
The Create Derived Model Type dialog opens.
5. For Name, enter the name of the new model type.

The name should be a maximum of 128 characters and should only consist of letters,
numbers, underscore characters (_), or dash characters (-).
03-Apr-2017 147/311
Important! A model type name is not required to be unique across the modeling catalog.
However, we recommend using unique names across the model types that were created
under the currently active developer ID. CA Spectrum differentiates model types using both
the model type name and the developer ID component in the model type ID. In addition,
reusing a model type name is not recommended.
1. Click OK.
The new model type is created and is set as the current model type.
If you click the Attributes tab, you can examine its attributes, which are those inherited from
the base model type that you selected in step 1.
2. If the new model type requires additional attributes that can be inherited from other base
model types, add those model types as base model types.
3. If the new model type requires additional attributes that cannot be inherited from other base
model types, add those attributes directly to the new model type.
4. Set the model type flags for the new model type as appropriate.
For example, if the new model type is a final model type (that is, it is meant to be instantiated
and used by models represented in OneClick), set the Instantiable flag.
5. Restart the OneClick web server.

You can now create a model of this new model type in the OneClick console.
Delete a Model Type

Deleting a model type involves deleting all models of that model type, removing all derived model
types for the model type, and finally removing all base model types for the model type. In effect, this
completely removes all dependencies on the model type from the model type hierarchy so that the
model type can safely be destroyed in the database.
Follow these steps:
1. In OneClick, use the Locater tab to find all of the models of the model type you intend to
delete, and delete the models.
Note: For more information, see Modeling and Managing Your IT Infrastructure (
https://docops.ca.com/display/CASP102/Modeling+and+Managing+Your+IT+Infrastructure).
2. Shut down OneClick and the SpectroSERVER, and start the Model Type Editor.
3. Set to current the model type that you want to delete.
4.
03-Apr-2017 148/311
4. Examine the hierarchy of the model type in order to identify the consequences of deleting it.
For example, check whether any attributes that originate in the model type are critical to any
derived model types that inherit them. Then resolve any predictable problems with
inheritance factors.
5. Remove all derived model types from the model type that you want to delete:
a. Make the first derived model type the current model type instead.
The model type you want to delete is now displayed in the list of base model types for
the new current model type.
b. In the list of base model types, select the model type that you want to delete, and click
(Remove selected base Model Type).
Note: The tooltip displayed when you hover over the button indicates
whether this action will result in only the removal of the selected model
type as a base model type or also the deletion of the current model type. If
the current model type has no derived model types, it will also be deleted
when you remove the last of its base model types because this means it is
no longer a part of the model type hierarchy.
c. Click Yes.
d. Repeat the preceding three steps as many times as needed until the model type that
you want to delete is no longer being used as base model type for any model types.
6. Remove all base model types from the model type that you want to delete:
a. Set current the model type that you want to delete.
b. In the list of base model types, select the first model type, and click (Remove
selected base Model Type).
Note: As previously mentioned, if the current model type has no derived

model types, it will also be deleted when you remove the last of its base
model types.
c. Click Yes.
d. Repeat the preceding two steps until the model type that you want to delete no longer
03-Apr-2017 149/311
d. Repeat the preceding two steps until the model type that you want to delete no longer
has any base model types.
Note: Removing the last base model type will also delete the model type
that you want to delete. You can only remove the last base model type from
the current model type when the current model type has no derived model
types.
Working with Base Model Types

Contents
How to Determine the Base Model Types for a New Model Type (see page 150)
Add a Base Model Type to a Model Type (see page 151)
Remove a Base Model Type from a Model Type (see page 152)
If a model type requires additional attributes above and beyond those inherited from the model type
from which it is first derived, you can add additional base model types. This can add attributes and
inference handlers to the model type.
While the addition of attributes typically does not cause any problem, you may add inference
handlers that lock attributes, which may make old inference handlers fail. Also, be aware that if a
model type has two or more base model types that share a common ancestor model type, the model
type has more than one way to inherit attributes and intelligence originating in that common
ancestor. As described in Model Type Precedence (see page 119), CA Spectrum resolves this type of
situation by assigning rankings to base model types. The base model type with the lower ranking
(that is, the base model type that is higher in the list of base model types) is the base model type
from which the derived model type inherits the shared attribute.
Note: You can change a base model type's ranking by removing the base model type and re-
adding it in a specific location in the ranked list of base model types.
How to Determine the Base Model Types for a New Model

Type
To identify the model types that you want to use as base model types, use the Hierarchy tab to
navigate up and down through the model type hierarchy to specific model types, and then use the
Attributes tab to examine their attributes. Continue this process until you have identified the
following:
The existing model type that contains most of the attributes needed for the new model type. You
should derive the new model type directly from this model type.
The other model types that can provide some or all of the other attributes needed for the new
03-Apr-2017 150/311
The other model types that can provide some or all of the other attributes needed for the new
model type.
As you identify the base model types for the new model type, keep the following guidelines in mind:
You can only use derivable model types as base model types, that is, model types that have the
Derivable flag set.
Use as few base model types as possible in order to keep the hierarchy simple.
Avoid adding base model types that do not contribute significantly to the model type being
created. And avoid base model types that contain a significant number of unnecessary attributes.
Because you cannot remove inherited attributes, ignoring this guideline can quickly add an
excessive number of attributes, wasting storage space and perhaps affecting performance.
You might want to add one or more base model types that provide access to specialized MIB
attributes and intelligence. We recommend creating a set of MIB-specific model types, each one
containing the intelligence and attributes related to a specific MIB. Create a new model type
based on GnSNMPMibDerPt and give it a name that identifies associated MIB. Then import the
MIB into the model type. This approach lets you add the MIB-specific model type as a base model
type to multiple model types. The associated attribute IDs remain the same across all derived
model types.
Important! For new device model types, the GnSNMPDev model type is often the best
starting point. This model type contains the basic attributes and intelligence that are
typically required for integration with core CA Spectrum functionality. For new application
model types, select from several possible starting points, such as GnSNMPMibDerPt and
GnSNMPAppDerPt. For more information, see the Certification (https://docops.ca.com/display
/CASP102/Certification).
Add a Base Model Type to a Model Type

You can add a base model type to an existing model type.
Follow these steps:
1. Set current the model type for which you want to add a base model type.
2. Do one of the following:
To give the new base model type the highest ranking of all of the listed base model types
(that is, place the base model type last in the list), proceed to the next step.
To give the new base model type a lower ranking (that is, place the base model type
higher in the list), select the base model type directly beneath the location where you
want to insert the new base model type. This step adds the new base model type in that
location.
03-Apr-2017 151/311
Note: When a derived model type can inherit the same attribute from two or more
inheritance paths that have a common originating model type, the derived model
type inherits the attribute from the base model type with the lowest ranking.
3. Under Base Model Types, click (Add a base Model Type).

The Select New Base Model Type dialog opens.
4. Select the model type to add as a base model type.
Note: To rapidly locate and select a specific model type, enter a text string in the
Filter text box to filter the list.
5. Click OK.
The selected model type is added as a base model type of the current model type.
Remove a Base Model Type from a Model Type

Removing a base model type from a model type is the way in which you remove inherited attributes,
inherited meta-rules, or intelligence from the model type. Essentially, this removes the hierarchical
relationship between the model type and the base model type in which the undesirable attributes
originate (referred to as the originating model type).
You can remove base model types from the current model type if the current model type was
creating using the developer ID that is currently active.
You cannot remove the last base model type from the current model type if the current model type
has derived model types. In order to break such a connection, you must first navigate to the derived
model types and use the following procedure to remove the model type of interest as a base model
type with respect to the derived model types. You can then navigate back to the model type of
interest and remove its last remaining base model type.
Note: Inference handlers are code segments that define the behavior and intelligence of a
model type. Problems can occur if you remove a base model type from a derived model
type, and the derived model type has associated inference handlers that refer to attributes
that used to be inherited from the removed base model type. This sort of dependency can
be difficult to detect. Also be aware that removing a base model type also may remove
inference handlers that were inherited from that base model type. This may cause
anomalies if the removed inference handlers performed some vital function for the model
type or for other model types derived from it.
You can remove a base model type from a model type.
03-Apr-2017 152/311
Follow these steps:
1. Set current the model type for which you want to remove a base model type.
2. Click the Hierarchy tab, and under Base Model Types, select the model type that you want to
remove, and click (Remove selected base Model Type).
Note: The tooltip for the button indicates whether this action only removes the
selected model type as a base model type or also deletes the current model type. If
the current model type has no derived model types, it is also deleted when you
remove the last of its base model types because it is no longer a part of the model
type hierarchy.
The selected model type is removed as a base model type.
Import MIBs
CA Spectrum manages devices according to the requirements and values that are specified in their
MIB documents. A MIB (Management Information Base) is a database that resides on a network
device and represents that device as a hierarchical collection of objects. A MIB object represents an
individual element of information, such as the uptime of a device. MIBs themselves are text files with
special syntax. A device MIB defines all of the objects that can be managed on the associated device.
The MIB organizes this information in a tree structure with branches that organize the managed
objects into logical groups.
You can use the Model Type Editor to import both SMIv1 and SMIv2 MIBs. However, when you
import a SMIv2 MIB, the Model Type Editor maps the MIB data type to the corresponding data type
that is defined in SMIv1. The Model Type Editor also supports most standard text conventions and
associated enumerations that can be used in a MIB.
When you create a model type, you typically want to add base model types that provide access to
specialized MIB attributes and intelligence. We recommend creating a set of MIB-specific model
types, each one containing the intelligence and attributes of a specific MIB. Create a model type from
GnSNMPMibDerPt and assign it a name that identifies the associated MIB. Then import the MIB into
the model type. This approach lets you add the MIB-specific model type as a base model type to
multiple model types and keep the associated attribute IDs consistent across all derived model types.
Note: You can only import a MIB into a model type that was created by the currently active
developer ID. This rule prevents you from importing the MIB into a model type that you
cannot subsequently export.
03-Apr-2017 153/311
Using the Model Type Editor to import a MIB into a model

type.
Follow these steps:
1. Select the model type from which you plan to derive a model type for the MIB import.
Typically, the starting point is some developer-specific (vendor-specific) model type that is
derived from the Manufacturer model type, as illustrated in the following figure:
spec--mte--importmibs_OTH
However, it can also be a model type that was derived from EntityTypes, MMDeveloper, or
another model type in the modeling catalog. Another alternative is GnSNMPMibDerPt, which
was designed specifically for importing MIBs into the CA Spectrum database. That model type
already contains many needed attributes and relations. Regardless of your selection, you can
create device model types at appropriate places in the model type hierarchy later for each
device receiving the attributes of the MIB.
Note: For more information about designing a new model type, see Certification (
https://docops.ca.com/display/CASP102/Certification).
2. Click the Hierarchy tab, and create a model type into which to import the MIB information:
a. Click (Derive a new Model Type).
b. Enter a model type name.

The name cannot exceed 128 characters and can only consist of letters, numbers,
underscore characters (_), or dash characters (-).
03-Apr-2017 154/311
Important! A model type name is not required to be unique across the

modeling catalog. However, supply a name that is unique across the model
types that were created under the currently active developer ID. CA
Spectrum differentiates model types using both the model type name and
the developer ID component in the model type ID.
c. Click OK.
The derived model type is created and is set as the current model type.
3. Click File, Import MIB.

The MIB Import dialog opens.
Note: Sometimes a single file contains multiple MIBs that are delineated with
BEGIN and END statements. Include only a single MIB in the file that you import.
4. Click Browse, navigate to the MIB file to import, select the file, and click Open.
5. Click OK to begin the import.

When the import is complete, the MIB Import Complete dialog is displayed to inform you of
the number of attributes and attribute groups that were created.
If issues are encountered during the import process, a warning is displayed to inform you that
the import was successful but issues were encountered. If the import process fails, an error is
displayed.
6. Click OK to close the dialog.
Important! When you create a model type, typically you also add support for traps, events,
and alarms. You can use the MIB Tools utility in OneClick to add trap support and perform
initial event configuration. For more information, see Certification (https://docops.ca.com
/display/CASP102/Certification). You can then fully configure the events and alarms using the
Event Configuration application in OneClick, as described in Event Configuration (
https://docops.ca.com/display/CASP102/Event+Configuration). For more information about
creating a management module (including creating model types), see Certification (
https://docops.ca.com/display/CASP102/Certification).
Set Model Type Flags

To set and change the flags for a model type, you must be using the developer ID that was active
when the model type was created.
Follow these steps:
03-Apr-2017 155/311
Follow these steps:
1. Select the model type whose model type flags you want to set.
2. Click the Flags tab and click (Edit) in the top, left corner.
The Edit Flags dialog opens.
3. Select (enable) and clear (disable) the flags as desired.
4. Click OK.
Working with Attributes

Contents
Add an Attribute to a Model Type (see page 156)
Remove an Attribute from a Model Type (see page 158)
Edit an Attribute (see page 159)
Modify an Attribute's Default Value (see page 159)
Modify an Attribute's Descriptors (see page 160)
You can add or remove attributes from a model type directly and indirectly:
To add or remove attributes indirectly, add or remove base model types, as described in Working
with Base Model Types (see page 150).
To add or remove attributes directly, create or delete the attributes from the model type itself, as
described in the topics in this section.
Add an Attribute to a Model Type

Typically, you will add attributes to model types that you own, that is, types that were created using
the currently active developer ID. Because you own the model types, you can subsequently export
them and their attributes.
While you can also add attributes to model types that you do not own, you cannot export these
model types or their attributes. Typically, exporting model types that you do not own is only required
for storing information in the related models when no available attribute is suitable.
Important! We recommend recording all changes that you make with the Model Type
Editor. Some changes are not migrated when the database is updated to a later version of
CA Spectrum Specifically, if you modify attributes (such as flag settings), the model type
hierarchy, or relations and the associated meta-rules in the model types supplied by CA or
another vendor, the changes are typically not migrated on database upgrade. You will have
to reapply these changes manually. For more information, see Migrate Changes to a New
Version of CA Spectrum.
03-Apr-2017 156/311
Follow these steps:
1. Select the model type to which you want to add an attribute.
2. Click the Attributes tab and click (Add a new Attribute).

The Create an Attribute dialog opens.
spec--mte--createattributedialog--SCR
3. Enter values for the attribute's descriptors.
Note: An attribute name does not need to be unique across the modeling catalog,
but you should enter a name that is unique across the attributes in the model type
that were created using the same developer ID. In other words, within a single
model type, two attributes can have the same name if they were created using
03-Apr-2017 157/311
model type, two attributes can have the same name if they were created using
different developer IDs. In addition, while it is allowed, reusing an attribute name is
not recommended.
4. Click OK.
The attribute is created and added to the working catalog, and it is displayed in the list of
attributes on the Attributes tab.
Remove an Attribute from a Model Type

You can remove an attribute from the model type in which it was created (referred to as the
originating model type) if you own the model type, that is, the model type was creating using the
developer ID that is currently active.
When you a remove an attribute from a model type, it is also removed from all derived model types
that inherit it.
To remove an attribute from a model type
1. Verify the attribute to be removed is not critical to a derived model type.
Note: If necessary, you can provide an alternate path via a different base model
type, or you can recreate the attribute at the derived model type level.
2. Select the model type for which you want to remove an attribute.
3. Click the Attributes tab, select the attribute you want to remove, and click (Delete
selected Attribute).
4. Click Yes.
The attribute is deleted from the working catalog.
03-Apr-2017 158/311
Edit an Attribute
Typically, you will want to modify the attributes of the model types that you own, that is, that were
created using the developer ID that is currently active. Because you own the model types, you can
subsequently export them and their attributes.
While you can also modify the attributes of model types that you do not own, you cannot export
these model types or the changes to their attributes.
You can edit an attribute by doing the following:
Changing its default value. See Modifying an Attribute's Default Value.
Changing its other descriptor values. See Modifying an Attribute's Descriptors.
However, before editing an attribute's characteristics, you should verify that derived model types
that inherit the attribute will not be adversely affected by the changes.
Modify an Attribute's Default Value

An attribute can inherit its default value from a base model type or specify its own value (a process
called specialization). In the latter case, all model types derived from the specialized model type
inherit the changed attribute value.
To modify the default value of an attribute
1. Set current the model type that has the attribute with the default value you want to change.
2. Click the Hierarchy tab, note any derived model types, and verify that they will not be
adversely affected by the change you want to make.
3. Click the Attributes tab, select the attribute from the displayed list, and click (Edit).
The Edit an Attribute dialog opens.
4. Do one of the following to change the default value:
If the attribute requires a single value, modify the value as desired.
03-Apr-2017 159/311
4.
If the attribute requires a list of values, click Edit, and modify the values as desired in the
Edit List Values dialog. To add a value, click (Add), enter an appropriate Object ID
index value (typically, an SNMP object identifier) and enter the value to associate with
that index entry.
The Object ID value is optional, and, if you specify the first one, the Model Type Editor
uses that Object ID to generate a default, modifiable Object ID for each subsequent value
that you add.
To delete a value, click (Delete).
Note: If the Default Value field does not have scroll bars, you can enter a value that
fits in the provided area. If there are scroll bars, the field automatically enlarges as
needed, and the only limitation is the impact on system performance.
5. Click OK twice.
Modify an Attribute's Descriptors

You can modify two types of attribute descriptors:
Standard attribute descriptors

When you modify one of these descriptors in a base model type, all derived (child) model types
inherit the change.
Attribute descriptors you can specialize

When you modify one of these descriptors in a base model type, derived model types that have
been specialized (specify their own values) do not inherit the change, but derived model types
that have not been specialized do inherit the change.
If you are the owner of the attribute (that is, the attribute was created using the developer ID that is
currently active), you can modify all of an attribute's descriptors in the originating model type
regardless of whether you are the owner of the model type.
If you are not the owner of the attribute, or if the attribute is inherited, you can specialize a subset of
the attribute descriptors. That is, you can modify the values of some of the descriptors at any level of
the inheritance hierarchy; you are not limited to modifying the values in the originating model type.
To edit the descriptors of an attribute
1. Set current the model type that has the attribute with the descriptor values you want to
change.
2. Click the Hierarchy tab, note any derived model types, and verify that the model types will not
be adversely affected by the changes you want to make.
03-Apr-2017 3. 160/311
3. Click the Attributes tab, select the attribute from the displayed list, and click (Edit
selected Attribute).
4. Modify the attribute descriptors as needed.
Note: All changes that you make to flag settings are subject to the relationships
described in Flags (see page 139).
5. Click OK.
Working with Attribute Groups

Contents
Working with Attribute Groups (see page 161)
Creating an Attribute Group (see page 161)
Modifying an Attribute Group (see page 162)
Deleting an Attribute Group (see page 164)
Working with Attribute Groups

An attribute group is a logical collection of related attributes in a model type. Groups make working
with related attributes easier in the Model Type Editor because they allow you to define and use a
user-defined sorting mechanism. You can create groups, assign attributes to them, and then add the
Group Name or Group ID as a column header in the table of attributes on the Attributes tab in the
Contents panel. This lets you then click the column header to quickly group together and view
together all of the attributes within a group.
Creating an Attribute Group

You can create attribute groups.
Note: When you add an attribute group, you add it to a specific model type, and the group
is inherited by derived model types in the same way that other attributes of a model type
are inherited. Like for other attributes, if you add an attribute group to a model type that
you do not own (its developer ID does not match the one that is currently active), you will
not be able to export the group.
To Create an Attribute Group
03-Apr-2017 161/311
To Create an Attribute Group
1. Set current the model type in which you want to create the attribute group.
2. Click the Attributes tab, and double-click any attribute that was created using the developer
ID that is current active.
3. Under Group, click Edit beside the value for Group ID.
The Select Group dialog opens displaying a table view and a tree view of all of the attribute
groups inherited from base model types or originating in the current model type.
The Model Type column displays the originating model type for each group (that is, the model
type in which the group was created).
4. Specify whether the new attribute group has a parent group:
If you do not want the attribute group to have a parent group, do nothing. This is the
default behavior.
If you want the attribute group to have a parent group, select the group using either of
the following methods:
Click the Table View tab, and use the table to select the desired parent group.
To help you find the group, for Filter, you can enter a text string to filter the list to
include only the groups whose names include the string. You can also click any column
heading to change the sort order from ascending to descending and vice versa.
Click the Tree View tab, and navigate the hierarchical tree of parent groups and child
groups to select the desired parent group.
5. Click (Add).
The Create Group dialog opens.
6. Enter a name for Group Name
Note: Do not enter a name that is being used by another attribute group created
using the same developer ID. In addition, use a maximum of 128 characters, and
use only numbers, letters, and underscore characters (_).
7. Click OK.
The new attribute group is created.
Modifying an Attribute Group

You can modify the name or parent group of an attribute group in the originating model type, that is,
in the model type in which the group was created. You cannot modify the name or parent group of
an inherited attribute group.
03-Apr-2017 162/311
In addition, to modify an attribute group, you must be the owner of the model type in which the
group was created. In other words, the active developer ID is the one that was used to create the
model type.
To modify an attribute group
1. Set current the model type in which the attribute group was created.
ID that is currently active.
The Select Group dialog opens. The dialog displays a table view and a tree view of all of the
attribute groups inherited from base model types or originating in the current model type.
4. Select the attribute group to modify using either of the following methods:
Click the Table View tab, and use the table to select the desired group.
To help you find the group, for Filter, you can enter a text string to filter the list to include
only the groups whose names include the string. You can also click any column heading to
change the sort order from ascending to descending and vice versa.
Click the Tree View tab, and navigate the hierarchical tree of parent groups and child
groups to select the desired group.
5. Click (Edit).
The Edit Group dialog opens.
6. If you want to change the group name, enter a new name for Group Name.
Note: Do not enter a name that is being used by another attribute group created
under the same developer ID. In addition, use a maximum of 128 characters, and
use only numbers, letters, and underscore characters (_).
7. If you want to change the group's parent group, do the following:
a. Click Edit beside the value for Parent Group ID.
b. In the Select Parent Group dialog, select a new parent attribute group using the Table
View tab or the Tree View tab, and click OK.
8. Click OK.
Your changes are saved and the Edit Group dialog closes.
03-Apr-2017 163/311
Deleting an Attribute Group

You can delete an attribute group if the following two conditions are met:
The group has no assigned attributes. If this is not the case, you can delete the group after you
have reassigned the attributes.
The group has no subgroups. If this is not the case, you can delete the group after you have
reassigned or deleted the subgroups.
To delete an attribute group
1. Set current the model type in which the attribute group was created.
ID that is currently active.
The Select Group dialog opens. The dialog displays a table view and a tree view of all of the
attribute groups inherited from base model types or originating in the current model type.
4. Select the attribute group to delete and click (Delete).

5. Click Yes.
The attribute group is deleted.
Working with Relations and Meta-Rules

Contents
About Working with Relations and Meta-Rules (see page 165)
Search for and Display Relations (see page 165)
Create Relations (see page 167)
Relation Meta - Rules (see page 168)
About Creating Meta-Rules for General Model Types (see page 169)
Create Meta - Rules (see page 169)
Delete Relations (see page 170)
Delete Meta - Rules (see page 170)
03-Apr-2017 164/311
About Working with Relations and Meta-Rules

The modeling catalog provided with the basic CA Spectrum package contains a number of predefined
relations, many of which have associated meta-rules. These relations provide a framework that can
replicate most relationships in a network. However, you can create additional relations as needed for
your network design.
If you add a new relation, you must also do the following:
Create meta-rules in <met> that implement the new relation for specific model types.
Add intelligence to the model types so that models of those types react appropriately when they
are associated based on the new meta-rules. You must implement the intelligence
programmatically using the CORBA API.
As an example, assume that you create the following meta-rule:
User Sends_mail_to User
When the meta-rule is instantiated (for example, when one User model sends mail to a second
User model), the first model may need to react to the fact that it (the user that it represents) has
sent mail, and the second model may need to react to the fact that it has received mail. In this
case, you must add intelligence to the User model type to implement these reactions.
Note: For information about using the CORBA API, see the Development API Reference (https://docops.
ca.com/display/CASP102/Development+API+Reference) section .
Search for and Display Relations

You can search for a relation by filtering the list of all relations in the modeling catalog to include only
those that contain the text string you specify. By default, the Model Type Editor examines the
supplied string against the names of the relations. However, if you display the Relation ID column in
the Navigation panel, it will also examine the string against the relation IDs (handles).
Follow these steps:
1. In the Navigation panel, click the Relations tab.

The names of all of the relations in the modeling catalog are listed.
2. In the list, select the name of the relation that you want to examine.
To locate and select a specific relation, you can take the following steps:
Enter a text string in the Filter text box in order to filter the list to include only the
relations whose names or IDs contain the string. To filter the list by ID, the ID column must
be displayed in the table.
Click the Relation bar at the top of the list to change the alphabetical sorting from
ascending to descending or vice versa.
03-Apr-2017 165/311
The selected relation becomes the current relation. The following information about the
relation is displayed in the Contents panel:
Developer ID
Specifies the developer ID that was active when the relation was created.
Relation Name
Specifies the name of the relation.
Relation ID
Specifies the ID (handle) that is assigned to the relation.
A handle is never reused even if you delete a relation.
Relation Type
Specifies the type of relation, either One-to-Many or Many-to-Many.
Meta-Rules
Specifies the list of meta-rules that apply the relation to specific model types, thereby
defining how the model types can interact with one another.
3. To filter the list of meta-rules to include only those for a specific model type, enter the full or
partial name of the model type in the Filter text box:
03-Apr-2017 166/311
spec--mte--metarules_SCR
Create Relations
You can create relations.
To create a relation
1. Click the Relations tab and click (Create Relation) in the Navigation panel.
The Create Relation dialog opens.
2. Enter a name for the relation.

The name should be a maximum length of 31 characters and should include alphanumeric
characters and underscores but not spaces or punctuation.
Important! The relation name does not need to be unique across the modeling
catalog, but you should enter a name that is unique across the relations created
under a given developer ID. In addition, while it is allowed, reusing a relation name
is not recommended.
3. Select the type of relation to create:
03-Apr-2017 167/311
3.
One-to-Many
Relations of this type relate one model type to many model types.
Many-to-Many
Relations of this type relate many model types to many model types.
Note: Once you create the relation, you cannot change the relation type. To specify
a different relation type, you must delete the relation and create a new one.
4. Click OK.
The relation is created and assigned a relation ID, and its information is displayed in the
Contents panel.
Note: A handle is never reused even if you delete the relation.
5. Create one or more meta-rules that use the relation.
6. Add intelligence to the relevant model types so that models of those types react appropriately
when they are associated based on the new meta-rules. You must implement the intelligence
programmatically using the CORBA API.
Note: For information on using the CORBA API, see the Development API Reference (
https://docops.ca.com/display/CASP102/Development+API+Reference) section.
Relation Meta - Rules

Each relation normally has one or more meta-rules, each of which applies the relation to specific
model types. Many of the model types in the core database have relations that are supplied without
meta-rules; these function as "placeholders" for which you can supply customized meta-rules that
are appropriate for your network design.
When a new model type is derived from one that is specified as a member of a meta-rule in
a relation, the meta-rule automatically applies to the derived model type. For example, the
modeling catalog provided with the basic CA Spectrum package has a relation called
Contains and two model types named Room and Device. One of the meta-rules for the
Contains relation is the following:
Room Contains Device
The modeling catalog also contains a Workstation model type that is derived from Device. As a result,
03-Apr-2017 168/311
The modeling catalog also contains a Workstation model type that is derived from Device. As a result,
the "Room Contains Device" also applies to the Workstation model type in the form of "Room
Contains Workstation." You do not have to explicitly create a meta-rule that includes the Workstation
model type.
About Creating Meta-Rules for General Model Types

Whenever possible, create meta-rules for general model types (model types near the top of the
model type hierarchy) in order to maximize their application and reduce the need for more specific
meta-rules. The more general the model type that contains the meta-rules, the more derived model
types it has, and, therefore, the more model types inherit its meta-rules.
As an example, the Device model type is a general model type that is used in the following meta-rule
for the Is_Adjacent_to relation:
Device Is_Adjacent_to Device
Consequently, any model type derived from Device or one of its descendants can be adjacent to any
other model type derived from Device or one of its descendants.
Create Meta - Rules

You can create a meta-rule without restriction if you own the corresponding relation, that is, the
relation was created using the developer ID that is currently active.
If the relation was created using a different developer ID, you can still create a meta-rule for it if at
least one of the model types used in the rule was created using the developer ID that is currently
active.
To create a meta-rule
1. Search for and display the relation for which to create the meta-rule.
The relation is displayed in the Contents panel.
2. On the Relation tab in the Contents panel, click (Create a new Meta-Rule).
The Create Meta Rule dialog opens.
3. In the list of model types on the left, select the antecedent (left) model type to include in the
meta-rule.
Note: To help you locate and select a specific model type, you can enter a text string in the
corresponding Filter text box in order to filter the list accordingly.
4. In the list of model types on the right, select the predicate (right) model type to include in the
meta-rule, and click OK.
The new meta-rule is added to the list of meta-rules for the current relation; it is inserted into
the list alphabetically according to the antecedent model type.
03-Apr-2017 169/311
Note: You now need to add intelligence to the model types so that models of those
types react appropriately when they are associated based on the new meta-rule.
You must implement the intelligence programmatically using the CORBA API. For
more information, see the Development API Reference (https://docops.ca.com/display
/CASP102/Development+API+Reference)section .
Delete Relations
You can delete a relation if the following two conditions are met:
The relation was created using the developer ID that is currently active.
The relation does not have any associated meta-rules. If this is not the case, first delete the meta-
rules.
To delete a relation
1. Search for and display the relation to delete.
2. On the Relations tab in the Navigation panel, select the relation, and click (Delete
selected relation).
3. Click Yes.
The relation is deleted.
Delete Meta - Rules

You can delete a meta-rule without restriction if you own the corresponding relation, that is, the
relation was created using the developer ID that is currently active.
If the relation was created using a different developer ID, you can still delete the meta-rule if at least
one of the model types used in the rule was created using the developer ID that is currently active.
To delete a meta-rule
1. Search for and display the relation that contains the meta-rule to delete.
2. On the Relation tab in the Contents panel, select the meta-rule and click (Delete
selected meta-rule).
3. Click Yes.
The meta-rule is deleted.
03-Apr-2017 170/311
Importing and Exporting Model Types

Contents
About Importing and Exporting Model Types (see page 171)
Import Model Types Using the Model Type Editor (see page 171)
Import Constraints (see page 172)
Import Model Types (see page 172)
Export Model Types Using the Model Type Editor (see page 173)
Import and Export Model Types Using dbtool (see page 175)
Send an Exported Catalog to a File or Printer (see page 175)
About Importing and Exporting Model Types

As your network grows, you may need to add new management modules and model types to your
database to support additional types of devices. Moreover, you may want to add these new model
types to your database without installing a completely new database, so you can keep intact all of the
model types you have already created or modified. CA Spectrum provides two database utilities that
lets you to import and export model types:
Import and export commands in the Model Type Editor: These commands let you import and
export model types from the working catalog for the current session. Because the commands do
not operate on the permanent catalog in the SpectroSERVER database, you can make an explicit
decision after an import as to whether to commit or discard the changes. Since you can only
import or export one catalog file at a time, use these commands when you have only one or a few
files to process.
A command-line utility named dbtool: This command-line utility program lets you import and
export model types from the permanent catalog in the SpectroSERVER database. Because you can
specify multiple files as command-line arguments, use this utility to batch process a set of files.
In both cases, the transfer vehicle is a binary export file that has a .e extension. These files are
referred to as catalogs.
Import Model Types Using the Model Type Editor

You can use the Model Type Editor to import model types, attributes, relations, and meta-rules into
the SpectroSERVER database. The modeling catalog objects must be defined in a catalog file (.e file)
that was created using the export feature in the Model Type Editor or the dbtool command-line
utility.
03-Apr-2017 171/311
Import Constraints
Important! You can only import modeling catalog objects that are stored in a compatible
CA Spectrum database (a database that is running the same version of CA Spectrum as the
destination database). For information about updating a CA Spectrum database, see the
Installation section.
New model types are imported into the modeling catalog according to the following constraints:
If the catalog file to import contains a model type that does not exist in the destination database,
the model type is imported according to the rest of the constraints described in this section.
All of the base model types for a new model type must already exist in the destination database.
If they do not, you must import them before importing the new model type. Typically, the "core
catalog" contains these prerequisite model types, and documentation accompanying any new
catalog informs you of any such dependencies.
If a base model type for a new model type does not exist, the import process is terminated. In this
situation, you can identify the missing model type in the CA Spectrum Control Panel. You must
then import a catalog file that contains the missing base model type, and then reinitiate the
import process that was terminated.
If the catalog file to import contains a model type that already exists in the destination database,
the existing version is modified to match the version to import, for example:
The model type's derivation is updated
New attributes are added
Existing attributes are updated
Attributes in the existing model type that have the same developer ID as the existing model
type are deleted if they originate in the existing model type but are not included in the
version being imported
If an error occurs due to an inability to write to the destination database or due to insufficient
memory or system resources, the import process is terminated, and you are notified with an
appropriate error message. Because this situation can leave the database in an incomplete or
corrupted state, you should always back up the database before beginning an import operation.
Import Model Types

When you import model types using the Model Type Editor, the model types and associated catalog
objects are imported into the working catalog. This lets you perform the import and then make an
explicit decision as to whether to discard the changes or permanently commit them to the
SpectroSERVER database.
To import the contents of a catalog
1. Back up the SpectroSERVER database into which you are importing a catalog.
03-Apr-2017 172/311
1.
Note: For information about how to back up the database using the database
utilities provided with CA Spectrum, see the Database Management (https://docops.
ca.com/display/CASP102/Database+Management) section.
2. Select File, Import Model Types.

The Open dialog opens.
3. Navigate to the catalog file (.e file) you want to import, select the file, and click Open.
The modeling catalog information in the selected file is imported into the working catalog for
the current session. At this point, you can manually commit the changes to the permanent
catalog in the SpectroSERVER database , or you can do so when you are prompted when you
exit the application. Alternatively, you can exit the application without committing the
changes to discard them.
Export Model Types Using the Model Type Editor

You can use the Model Type Editor to export a specific list of model types from the SpectroSERVER
database to a catalog file. A catalog file is a .e file, and it is sometimes referred to as a CA Spectrum
database export file.
When you are exporting model types and associated catalog objects, bear the following in mind:
The export feature in the Model Type Editor exports the working catalog that is stored in
memory. As a result, the resulting export file includes any changes you have made to model types
and associated objects during the current session even if you have not yet committed those
changes to the SpectroSERVER database.
To export the permanent catalog only, you can commit the changes and use the export feature in
the Model Type Editor, or you can use the dbtool command-line utility instead.
The .e file produced by the export process contains the following information:
The attribute descriptors that originated in the model type being exported.
The attribute descriptors that have been specialized (for example, by specifying a default
value to override an inherited one).
The relations and associated meta-rules in which the model type and/or any ancestor model
types participate as an antecedent or a predicate.
You can only export the model types, attributes, and relations (including their associated meta-
rules) that were created using the active developer ID.
To export one or more model types to a catalog file
1. Identify the model types to export.

Typically, the list of model types to export should include any base model types that are
required by the model types being exported and that do not exist in the destination database.
However, in general practice, dependencies normally are limited to certain commonly-used
03-Apr-2017 173/311
1.
However, in general practice, dependencies normally are limited to certain commonly-used

base model types that are contained in one or more "core" catalogs that are included as part
of the basic CA Spectrum system. These core catalogs are a part of every installation, as
shown in the following illustration.
spec--mte--roothierachy--OTH
2. Select File, Export Model Types.

The Model Type Export dialog opens.
By default, all unmodified model types that were created using the active developer ID are
initially displayed in the Model Types column on the left.
In addition, all model types that were created using the active developer ID and that have
been modified during the current session are initially displayed in the Model Types to Export
column on the right. Modified model types are those you have changed regardless of whether
the changes are currently in the working catalog or committed to the database. Note that
once you export a model type, it is no longer identified as modified because you have saved it
to a catalog, in this case, to a CA Spectrum database export file.
3. Move the model types that you want to export to the Model Types to Export list.
To search for the model types to export, in the Filter text box, you can enter a text string to
filter the list to include only the model types with names that contain or match the string. The
filter is not case-sensitive.
To move all of the model types available for export to the Model Types to Export list, click
. To move a single model type to the list, double-click the model type name, or select
the model type and click .
Similarly, you can remove model types from the export list by double-clicking them or using
the corresponding left-arrow buttons.
4. Click Browse, and in the Save dialog, navigate to the folder in which to save the catalog file.
Important! By default, the Save dialog opens to the CA Spectrum database

(modeling catalog) directory. However, it is recommended that you save exported
catalog files in a directory outside of the CA Spectrum installation area in order to
prevent the loss of the files during a CA Spectrum update process.
5. Enter a name for the file (you do not need to include the .e extension) or select an existing .e
file to overwrite, and click Save.
6. In the Model Type Export dialog, click OK.
03-Apr-2017 174/311
6. In the Model Type Export dialog, click OK.

The model types are exported to the specified catalog file.
Import and Export Model Types Using dbtool

The CA Spectrum command-line utility program named dbtool can import or export model types
from the permanent modeling catalog in the SpectroSERVER database. The dbtool utility lets you
specify multiple files as command-line arguments. Therefore, it is a better tool to use than the import
and export features of the Model Type Editor for batch processing a set of files.
When you use dbtool, you can export only the model types that you "own," that is, types that were
created using the currently active developer ID. If a model type is not owned, an error message
describes the relevant model types, and the export process is terminated.
Run the dbtool utility from the directory that contains the SpectroSERVER database that is used in the
import or export. In addition, while the import or export is underway, no other program or process
(for example, a VNM or the Model Type Editor) can access the database. Keep in mind that while CA-
developed applications automatically lock out other CA-developed applications, third-party
applications may not. The competition can result in database corruption.
Note: For more information about running dbtool, see the Database Management (
https://docops.ca.com/display/CASP102/Database+Management) section. This section also
contains information about how to back up the database using the CA Spectrum database
utilities. Perform the backup before you perform an import.
Send an Exported Catalog to a File or Printer

CA Spectrum includes a command-line utility program named dbtool that you can use to send or
"dump" the contents of a catalog file (.e file) to a file or printer. You can use this tool to store or print
the contents of a catalog file that was created using the export feature of the Model Type Editor or
using dbtool itself.
Before running dbtool, you must shut down the SpectroSERVER and any other program that accesses
the SpectroSERVER database.
Note: For information about running the dbtool utility, see the Database Management (
https://docops.ca.com/display/CASP102/Database+Management) section.
Running Reports on Model Types and Relations

Contents
About Running Reports on Model Types and Relations (see page 176)
03-Apr-2017 175/311
About Running Reports on Model Types and Relations (see page 176)
About Running Reports on Model Types and Relations

CA Spectrum includes a command-line utility program named reports that you can use to display,
print, or export (to a file) information about the model types and relations in the modeling catalog.
You must run the reports utility from the directory that contains the SpectroSERVER database that
contains the data you want to access. While the report is being generated, no other program or
process (for example, a VNM or the Model Type Editor) can access the database.
Note: For information about running the reports utility, see Database Management (
https://docops.ca.com/display/CASP102/Database+Management) section.
03-Apr-2017 176/311
OneClick Customization
Contents
Prerequisites for Customizing OneClick XML Files (see page 177)
Extend Factory XML Files (see page 177)
Override Factory Files (see page 178)
Inherit Features in Factory XML Files (see page 178)
Example Extending Factory XML File (see page 178)
OneClick provides a flexible platform for administrators to modify aspects of the application to meet
specific requirements. For example, you can modify OneClick behavior to support the unique
structure of a site, an enterprise and network environment, work processes, and software
deployments. Make your modifications using the OneClick UI or by coding the changes in the XML
files that are provided for that purpose.
Important! Do not add customizations to the files in their default location (<$SPECROOT>
/tomcat/webapps/spectrum/WEB-INF/console/config/). The customizations in that
directory are ignored. In addition, these files are overwritten when you perform CA
Spectrum and OneClick upgrades.
Prerequisites for Customizing OneClick XML Files

Before you attempt to customize OneClick files, be aware of the following requirements:
You must be able to create and modify files on the OneClick server.
You must be familiar with the fundamentals of XML coding as well as the CA Spectrum and
OneClick directory structure.
You must know the following:
The file whose functionality you want to extend with your modifications.
The directory in the <$SPECROOT>/custom directory structure in which to create your custom
file.
Extend Factory XML Files

You can extend default XML files to accomplish OneClick customizations without overriding the entire
factory default file. Customized XML files are not removed during a CA Spectrum/OneClick software
upgrade or reinstallation.
03-Apr-2017 177/311
To extend the default OneClick XML configuration files, create a file with the same name as the
default file in the appropriate custom directory. Use the XML idref attribute in the new file to refer to
the default OneClick file of the same name. Code the new functionality in this file. When OneClick
parses the XML files, the changes in the new file are added to the existing factory file referenced
using idref.
By extending factory files, you are able to take advantage of new features and functionality available
in software updates to the factory XML code while preserving your customizations.
Although you can still override a factory XML file by creating a copy of it in the <$SPECROOT>/custom
directory and making your changes in the copy, using the IDREF XML attribute provides the ability to
inherit and extend the factory file, while maintaining customizations in streamlined files.
Override Factory Files

Override a factory configuration file by copying the original file to the appropriate custom directory,
and then adding new XML code or modifying the existing XML code. OneClick reads the files in the
custom directory first. If the file exists in the custom directory and does not contain an idref
statement referencing the original factory file, OneClick does not read the original factory file, and
the new file overrides the original factory file.
Inherit Features in Factory XML Files

Using idref to extend XML files has applications beyond extending the factory file with the same
name. You can use this technique to inherit or reuse features in any file of the same type. For
example, you can create your own model types that have a customized details view defined in view-
mymtypedetails-config.xml. This model type can also inherit the default device views configured in
view-devicedetails-config using idref. The new custom file extends the functionality of the default file
while also inheriting the views in the default file.
Example Extending Factory XML File

The example in the following figure extends the functionality of the factory default <$SPECROOT>
/tomcat/webapps/spectrum/WEB-INF/topo/
config/view-devicedetails-config.xml file by adding the code for the new subviews in <$SPECROOT>
/custom/topo/config/view-devicedetails-config.xml. The default factory file view-devicedetails-config
is specified in an "idref" statement.
03-Apr-2017 178/311

OneClick Directory Structure (see page 179)
Customizing the OneClick Login Dialog (see page 182)
Customizing the OneClick Console Menu (see page 183)
Customizing OneClick Alarms (see page 202)
Customizing OneClick Tables (see page 203)
Adding Support for Model Types or Model Classes (see page 220)
Customizing a Model's Information View (see page 247)
Creating a Model's Performance View (see page 263)
Creating Custom Privileges (see page 271)
XML Usage Common to All Customization Files (see page 276)
Customizing OneClick for CA Service Desk (see page 289)
OneClick Directory Structure

Contents
Existing OneClick Files (see page 180)
The console/config Directory (see page 180)
The topo/config Directory (see page 181)
The common/config Directory (see page 181)
The alarm/config Directory (see page 181)
Save Customized XML Files (see page 181)
Preserve XML Customizations (see page 182)
Preserve Custom Images (see page 182)
This section explains the directory structure of the XML files used to create the OneClick interface.
You must be familiar with the structure to find the files necessary for customization and to
implement customization in directories that are not overwritten when you upgrade or reinstall CA
Spectrum.
03-Apr-2017 179/311
Existing OneClick Files

The OneClick user interface is installed with a default layout, panel, menu, toolbar, and submenu
content. The files that reside on the OneClick server controls all of these features. These files and
their locations are identified in this section.
The console/config Directory

The files in the <$SPECROOT>/tomcat/webapps/spectrum/WEB-INF/console/config directory support
menus, topology views, privileges for user interface elements, branding elements, and other aspects
of the OneClick user interface. The files that are located in this directory are placeholder files that
resemble templates for customizations to OneClick functionality. The files and their functions are
described as follows:
custom-app-config.xml
General OneClick registrations, and topology support for CA Spectrum model types, including
icons and views.
custom-branding-config.xml
Customizes the following UI branding elements of OneClick:
Application brand name
Application suite name
Image to display in the splash screen
Image to display as the logo button in the lower-left corner
Name of the root node in the tree in the Navigation panel
About dialog
Note: For information about the XML elements to specify these branding elements, see
the comments in the file that is named custom-branding-config.xml in <$SPECROOT>
/tomcat/webapps/spectrum/WEB-INF/console/config/.
custom-menu-config.xml
OneClick menus and toolbars.
custom-privileges.xml
Registers custom privileges that are applied to the menu items, columns, and subviews.
To customize the OneClick user interface, copy these files to the <$SPECROOT>/custom/console
/config directory and then edit them.
03-Apr-2017 180/311
Check the <$SPECROOT>/custom/console/config directory before copying files there. Some actions,
such as creating custom searches in the Explorer, automatically create a copy of the custom-app-
config.xml if one does not exist. If the config files already exist in the <$SPECROOT>/custom/console
/config directory, add your customizations to those existing files.
The topo/config Directory

The files in this directory create the components of the OneClick topology views. These components
include icons, subviews, and tables that display data.
All of the table files are named after the functionality that they display. For example, the file that
builds the interface table for each model type is table-common-ifconfig-config.xml.
The common/config Directory

The files in this directory create various topology elements that can be used by all of the other files
that create the OneClick interface. This includes colors, columns for tables, and tables.
The alarm/config Directory

The files in this directory create the OneClick alarm views and contents, including the Alarms table
and the Alarm Details information tab.
Save Customized XML Files

OneClick customization files must be placed in specific custom directories so that OneClick finds
and reads the customized code and associates it with the correct default factory file. The following
lists the custom directories for the OneClick component categories.
Alarms
<$SPECROOT>/custom/alarm/config/
Common
<$SPECROOT>/custom/common/config/
Important! Do not copy the <$SPECROOT>/custom/common/config/custom-jnlp-config.

xml file to another computer when you migrate and upgrade CA Spectrum. This file can
contain memory settings that are not compatible with the computer where you are
copying the custom directories.
Console components
<$SPECROOT>/custom/console/config/
03-Apr-2017 181/311
Event format and probable cause files

<$SPECROOT>/custom/Events/
Images
<$SPECROOT>/custom/images/
Background images
<$SPECROOT>/custom/images/Background/
Stored SSL certificates

<$SPECROOT>/custom/keystore/
Report Manager
<$SPECROOT>/custom/repmgr/config/
Topologies
<$SPECROOT>/custom/topo/config/
Preserve XML Customizations

OneClick does not delete or overwrite files in the custom directory during an upgrade of CA Spectrum
or OneClick.
Customized OneClick XML files may be overwritten in the following situation:
Uninstalling SpectroSERVER
Reinstalling the same version of SpectroSERVER if you have installed OneClick under the CA
Spectrum installation directory.
In this case, you should save off the customized files to an area unaffected by the uninstall
process, and re-insert them once you have reinstalled SpectroSERVER.
Note: For more information on upgrades and installation of CA Spectrum and OneClick, see
the Install CA Spectrum (https://docops.ca.com/display/CASP102/Install+CA+Spectrum) section.
Preserve Custom Images

You must place all image files that you create or customize in the <$SPECROOT>/custom/images
directory. Otherwise, all new or customized images are deleted or overwritten during an upgrade or
reinstallation of CA Spectrum or OneClick.
Customizing the OneClick Login Dialog

Contents
Custom Login Message (see page 183)
Add a Custom Message to the OneClick Login Dialog (see page 183)
03-Apr-2017 182/311
Custom Login Message

Custom messages can be added to the Login dialog for the OneClick Console. You can use this
message to inform OneClick users about your usage policies, legal rights, consequences of
unauthorized usage, or other important information they must know before they log in. The custom
message appears in the Login dialog for the OneClick Console only.
Add a Custom Message to the OneClick Login Dialog

To inform OneClick users about usage policies, legal rights, or other important information needed
before logging in, you can add a custom message to the OneClick Login dialog.
To add a custom message to the OneClick Login dialog
1. Open the <$SPECROOT>/tomcat/webapps/spectrum/oneclick.jnlp file with WordPad.
2. Add the following argument into the <application-desc> section:
<argument>-loginTitle Message_Text</argument>
For example, you can replace the Message_Text variable with your own message, as follows:
<argument>-loginTitle For authorized company use only. Unauthorized users will

be punished to the fullest extent of the law.</argument>
3. Click File, Save.

Your custom message is added to the OneClick Login dialog.
SPEC--Customized OneClick Login dialog
Customizing the OneClick Console Menu

Contents
The custom-menu-config.xml File (see page 184)
Add a New Menu (see page 186)
03-Apr-2017 183/311
Add a New Menu (see page 186)

Add a New Menu Item (see page 187)
Add Toolbar Images (see page 188)
Define a Keyboard Accelerator (see page 189)
Perform an Action (see page 189)
Contextually Apply the Action (see page 190)
Limit the Availability of Menu Items (see page 192)
Launch a Browser (see page 194)
Important Information About Specifying URLs (see page 195)
Specify a Username (see page 197)
Launch an Application From OneClick (see page 197)
Launch a Web Server Script (see page 199)
Pass Table Values to a Script (see page 200)
Display the Status of a Launched Application or Script (see page 201)
This section describes how to add new menus and new menu items to the OneClick console. You can
use new menu items to launch URLs, third-party applications, and scripts, and to pass parameters to
them.
The custom-menu-config.xml File

The <$SPECROOT>/tomcat/webapps/spectrum/WEB-INF/console/config/custom-menu-config.xml
file contains examples on how to add custom menus and custom menu items to your OneClick
console as shown in the images. You need to copy this file in to the <$SPECROOT>/custom/console
/config/ directory if the file is not already in this directory.
The following image shows the Connections menu and its two new menu items: Ping Local and
Launch Diagnostics:
SPEC--menu_connections
The following image shows that a new menu item called Launch My Web Page, which has been
added to the existing Tools menu. This menu item has been created to launch a specified web page.
03-Apr-2017 184/311
SPEC--launch_web_page
You create OneClick menus and menu items using the <menu> and <item> XML elements. The
<menu> element can enclose one or more <item> elements that define the commands that are
available on the menu. The <item> element can enclose several other elements that define how the
menu item appears and behaves. See the following table for information about these elements.
Element Parent Description

Element
<menu> <root> Defines the menu. The name attribute is used to define the name of the menu.
<separator <menu> Used just before an <item> element to define a separator line as shown in the
> first figure in this section.
<item> <menu> Defines an item on a specific menu. The name attribute is used to define the
name of the item.
<privilege <item> Associates a privilege to the menu item. If the user is not given this privilege, the
> menu item is not displayed for that user.
<toolbar- <item> Specifies the image to display for the menu item and its associated toolbar
image> button when the functionality is available to the user.
<toolbar- <item> Specifies the toolbar image that is displayed when a user places the cursor over
image- the toolbar button.
rollover>
<toolbar- <item> Specifies the toolbar image that is displayed when the functionality is disabled
image- (not available to the user). A typical representation for this state is an image that
disabled> is 80percent grayed out.
<accelerat <item> Defines a keyboard sequence that executes the menu item.
or>
<action> <item> Defines the action that takes place when the user clicks the menu item.
<hot-key> <item>
03-Apr-2017 185/311

Element
Underlines the first instance of the indicated letter and enables the user to
activate the menu item using this letter as a keyboard shortcut.
The subsequent sections of this chapter describe how to use the <menu> element to create a new
menu and how to use the <item> element and its child elements to add menu items to a new or
existing menu.
Add a New Menu

The <menu> element is used to create a OneClick console menu.
To add a new menu
1. Open the existing <$SPECROOT>/custom/console/config/custom-menu-config.xml file.
2. If the file does not exist, copy the file <$SPECROOT>/tomcat/webapps/spectrum/WEB-INF

/console/config/
custom-menu-config.xml into the <$SPECROOT>/custom/console/config directory, and then
open it.
The <root> element is the root element for this file. Define all new menus inside the <root>
element.
3. Use the <menu> element to create new menus. This element has a single attribute, name,
which defines the name of the menu.
Note: Some of the examples in the custom-menu-config.xml file show a fully

qualified menu name that references a Java class created by OneClick engineers.
For example, com.aprisma.spectrum.app.swing.window.menu.Tool is used as the
value for the name attribute in the <menu> element that defines the Tools menu.
You don't have to use a fully qualified name to create a new menu or to refer to an
existing menu. Simply use the exact text that you would like to appear as the menu
name on the toolbar.
4. Add items to the new menu by specifying them using the <item> element and its available
child elements. If you do not specify menu items for a menu, the menu is not visible in the
OneClick console.
5. Save the changes that you have made to custom-menu-config.xml.
6. To view and test the new menus, restart the OneClick console.
Example: Creating a New Menu
The following lines of XML create the Connections menu shown in The custom-menu-config.xml File.
03-Apr-2017 186/311
<menu name="Connections">
<item name="Ping Local">
.
.
.
</item>
<item name="Launch Diagnostics">
.
.
.
</item>
</menu>
Add a New Menu Item

To add an item to an existing OneClick console menu or to a new menu that you created, you must
create a new <item> element inside the <menu> element that you are customizing. The <item>
element uses the <name> attribute to specify the name of the menu item.
Note: The new menu item is also added automatically to the right-click menu.
To add a new menu item
1. Open <$SPECROOT>/custom/console/config/custom-menu-config.xml.
2. Find the <menu> element that you created in Add a New Menu that defines the menu to
which you want to add items. If the <menu> item does not yet exist, add it using the name
attribute to define either an existing or a new menu.
Note: Some of the examples in custom-menu-config.xml show a fully qualified

menu name that references a Java class created by OneClick engineers. For
example, com.aprisma.spectrum.app.swing.window.menu.Tool is used as the value
for the name attribute in the <menu> element that defines the Tools menu. You do
not have to use a fully qualified name to create a new menu or to refer to an
existing menu. For example, you can use <menu name=Tools> to refer to the
Tools menu.
3. Use the <item> element to create each new menu item. This element has one attribute,
name, which defines the name of the menu item.
4. The <item> element has a series of child elements that enable you to define how the item
behaves. These elements are listed in the table in the custom-menu-config.xml File, and they
are further defined in the rest of this chapter. Use these elements to define the behavior of
the menu item you have added.
03-Apr-2017 187/311
6. To view the new menu items, restart the OneClick Console.
Example: Creating New Menu Items
The following example adds a menu item that is called Ping Local to a menu called Connections.
<menu name="Connections">
<item name="Ping Local">
<accelerator modifiers="2">VK_I</accelerator>
<action>
<filter>
<has-attribute>AttributeID.NETWORK_ADDRESS</has-attribute>
</filter>
<context>com.aprisma.spectrum.app.topo.client.render.ModelContext </context>
<context>com.aprisma.spectrum.app.alarm.client.group.AlarmContext</context>
<launch-application>
<platform>
<os-name>Windows 9x</os-name>
<command>command.com /c start "Local ping {0}" cmd.exe /c
"ping.exe {0} && pause"</command>
</platform>
<platform>
<os-name>Windows</os-name>
<command>cmd.exe /c start "Local ping {0}" cmd.exe /c "ping.exe
{0} && pause"</command>
</platform>
<platform>
<command>/usr/dt/bin/dtterm -e ping -s {0}</command>
</platform>
<param>
<attribute>AttributeID.NETWORK_ADDRESS</attribute>
</param>
</launch-application>
</action>
</item>
</menu>
Add Toolbar Images

To have a toolbar image available for each of the three toolbar image states, you must specify them
in your menu item definition. The elements for toolbar states are:
<toolbar-image>
<toolbar-image-rollover>
<toolbar-image-disabled>
You can use the following image formats for OneClick toolbar images: .png, .gif, .jpg, and .jpeg.
03-Apr-2017 188/311
The recommended toolbar image size is 24 x 24 pixels. Store custom images in the <$SPECROOT>
/custom/images directory. When you reference an image that is placed in this directory, specify the
path from the images directory, for example, images/myimage.png.
The following line of code specifies a toolbar image using the relative path to the image file.
<toolbar-image>images/hints.gif</toolbar-image>
For a listing of all of the elements that are used in defining OneClick menu items, see the table in
Contextually Apply the Action.
Define a Keyboard Accelerator

The <accelerator> element specifies a combination of keyboard input that executes a corresponding
menu item.
Specify the code for the accelerator key using the capitalized letter on the keyboard, which is
preceded by VK_.
The modifiers attribute indicates the modifier key combinations as an integer where:
1 = Shift
2 = Ctrl
3 = Ctrl+Shift
8 = Alt
9 = Alt+Shift
10 = Ctrl+Alt
You are not required to specify a keyboard accelerator for a customized menu item.
<accelerator modifiers="2">VK_L</accelerator>
In the preceding example, the specified action of the menu item is performed if the 'L' key is pressed
while holding down the Control key (Ctrl+L).
Perform an Action
The <action> element specifies the action that is performed when the menu item is selected. You can
use the child elements that are shown in the table in Contextually Apply the Action to specify a
particular action.
The <context> element specifies the context in which the menu item is active so that the action can
be executed. This applies to both the standard and the right-click menu.
03-Apr-2017 189/311
Contextually Apply the Action

Actions do not always apply in all situations, such as an action that is applicable only when the user
selects a model. Therefore, you can specify one of the following contexts for your actions:
ModelContext
Indicates that the action should be available when the user selects a model. The format for this
context is as follows:
<context>com.aprisma.spectrum.app.topo.client.render.ModelContext</context>
AlarmContext
Indicates that the action should be available when the user selects an alarm. The format for this
<context>com.aprisma.spectrum.app.alarm.client.group.AlarmContext</context>
TableContext
Indicates that the action should be available when the user selects any table. The format for this
<context>com.aprisma.spectrum.app.util.table.TableContext</context>
If no tablename is specified, context is limited to any table. However, you can also limit context to
a single table using the following format:
<table-name>TableName</table-name>
You can specify one or a combination of contexts. If no specified context matches the current
window context, the menu item is disabled. If no contexts are specified, the menu item is displayed in
all contexts.
The following table describes the elements that are used to implement an action.

Element
<contex <action Limits the context in which the menu item is enabled and can perform the action.
t> >
<table- <action Used with <context>, specifies the tablename when limiting the action to a single
name> > table. Works with TableContext only.
<colum <param Used with <context> and <command>, specifies which values in a table column to
n- > pass into a script from a selected row in the table. Works with TableContext only.
name>
<filter> <action Limits the availability of menu items.
>
<filter> Specifies the attribute on which to filter.
03-Apr-2017 190/311

Element
<has-
attribut
e>
<and>, <filter> Creates an expression that can be used with a filter.
<or>,
<value>
,
<equals
>
<launch <action Launches a browser.
- >
browser
>
<launch <action Launches a browser and, if single sign-on is enabled in OneClick, includes a single
-sso- > sign-on token associated with the current session in the URL. This token can be
browser used to reauthenticate the session across integrated web applications instead of
> prompting the user repeatedly for a username and password.
Note: For information about how to set up single sign-on in OneClick using CA
SiteMinder or CA Embedded Entitlements Manager (https://docops.ca.com/display
/CASP102/CA+Embedded+Entitlements+Manager+and+CA+Spectrum), see the Integration
section for that application.
<url> <launch Specifies the URL to launch in the browser.
-
browser
>
<launch <action Launches an application.
- >
applicat
ion>
<launch <action Launches a script available on the web server.
-web- >
server-
script>
<display <launch Displays the output from the launched script.
- -
output> applicat
ion>,
<launch
-web-
server-
script>
<display <launch Displays the exit status of a launched script.
-exit- -
status> applicat
ion>,
03-Apr-2017 191/311

Element
<launch
-web-
server-
script>
<comm <launch Specifies the application or script that the menu item launches.
and> -
applicat
ion>,
<launch
-web-
server-
script>,
<platfor
m>
<run- <launch Runs a script on web browser for selected multiple alarms.
for- -web-
multiple server-
- script> Note: Applicable for alarms only.
alarms>
<platfor <launch Used with <os-name>, specifies the application to launch based on the operating
m> - system of the OneClick client.
applicat
ion>
<validat <launch Used with the <command> element, specifies that the menu item should only be
e> - added to the menu if the command exists on the OneClick client and has execute
applicat permissions. If either condition is found to be false during OneClick startup, the
ion> menu item is not added to the menu.
If the <validate> element is not used, the menu item is always added to the menu,
but its state is determined by the value of other elements.
<os- <platfor Used with <platform>, specifies the application to be launched specific to the
name> m> operating system of the OneClick client.
<param <url>, Specifies a parameter that is passed to a browser, executable, or script.
> <comm
and>
<attribu <param Specifies an attribute used as a parameter.
te> >
Limit the Availability of Menu Items

The <filter> element specifies a filter that further restricts the enabled state of the menu item. You
can filter on any attribute of the selected context.
<filter>
</filter>
03-Apr-2017 192/311
In the preceding example, the action needs the IP address of the alarmed model. Therefore, it should
only be enabled if the alarmed model has the Network_Address (ID 0x12d7f) attribute.
You can specify complex attribute filters with any combination of nested and and or filters.
Example: Nesting Filters
The following example enables the item if the selected model has the Network_Address attribute and
the Condition (ID 0x1000a) attribute is RED.
<filter>
<and>
<equals>
<attribute id="AttributeID.CONDITION">
<value>3</value> 
</attribute>
</equals>
</and>
</filter>
The file <$SPECROOT>/tomcat/webapps/spectrum/WEB-INF/common/schema/

attribute-filter.xsd contains the complete syntax for attribute filters.
The following table defines commonly used attributes where an attribute ID is expected.
Constant Attribute
AttributeID.NETWORK_ADDRESS Network Address (ID 0x12d7f)
AttributeID.MTYPE_ID Model Type Handle (ID 0x129ab)
AttributeID.MTYPE_NAME Model Type Name (ID 0x10000)
AttributeID.MODEL_OBJECT Model Handle (ID 0x11f53)
AttributeID.MODEL_NAME Model Name (ID 0x1006e)
AttributeID.MODEL_CLASS Model Class (ID 0x11ee8)
AttributeID.CONDITION Condition (ID 0x1000a)
AttributeID.DOMAIN_ID Landscape Handle (ID 0x129ac)
AttributeID.DOMAIN_NAME Landscape Name (ID 0x11d42)
AttributeID.MAC_ADDRESS MAC Address (ID 0x110df)
AttributeID.DEVICE_TYPE Device Type (ID 0x23000e)
You can use the constants defined in the following table for alarm attributes:
Constant Alarm Attribute

AlarmAttrID.ACKNOWLEDGED Acknowledged (ID 0x11f4d)
AlarmAttrID.ALARM_FILTER_MH Alarm Filter (ID 0x12a56)
AlarmAttrID.ALARM_ID Full Alarm ID (ID 0x11f9c)
AlarmAttrID.INT_ALARM_ID Integer Alarm ID (ID 0x4820067)
03-Apr-2017 193/311
Constant Alarm Attribute

AlarmAttrID.ALARM_SOURCE Alarm Source (ID 0x11fc4)
AlarmAttrID.ALARM_STATUS Alarm Status (ID 0x11f4f)
AlarmAttrID.CAUSE_CODE Cause Code (ID 0x11f50)
AlarmAttrID.CAUSE_LIST Cause List (ID 0x12a05)
AlarmAttrID.CAUSE_TITLE Cause Title (ID 0x4820020)
AlarmAttrID.CREATION_DATE Creation Date (ID 0x11f4e)
AlarmAttrID.CLEARED_BY_USER_NAME Cleared By User Name (ID 0x11f51)
AlarmAttrID.IMPACT_SEVERITY Impact Severity (ID 0x1290d)
AlarmAttrID.OCCURRENCES Occurrences (ID 0x11fc5)
AlarmAttrID.ORIGINATING_EVENT Originating Event (ID 0x1296e)
AlarmAttrID.PERSISTENT Persistent (ID 0x12942)
AlarmAttrID.PRIMARY_ALARM Primary Alarm (ID 0x11f54
AlarmAttrID.SEVERITY Severity (ID 0x11f56)
AlarmAttrID.TROUBLESHOOTER Troubleshooter (ID 0x11f57)
AlarmAttrID.TROUBLE_TICKET_ID Trouble Ticket ID (ID 0x12022)
AlarmAttrID.USER_CLEARABLE User Clearable (ID 0x11f9b)
If you need to use an attribute other than one of the attributes listed in the 2 preceding tables,
specify the attribute using its hexadecimal attribute ID.
Launch a Browser
The <launch-browser> element lets you launch a specified URL in a browser and pass parameters to
the URL. These parameters can be hard-coded values or values from model attributes.
Example: <launch-browser> Code
The following example launches the default browser on the client machine. The <url> element
specifies the URL pattern. You can specify parameters to substitute in the URL pattern by enclosing
the parameter number (starting at 0) in curly braces {}. You then specify <param> elements for each
parameter.
<launch-browser>
<url>http://{0}</url>
<param>
</param>
</launch-browser>
CA Spectrum processes the <param> elements in order so the first one corresponds to the 0th
parameter in the URL pattern. A <param> element has a specific syntax. The most commonly used is
the <attribute> element. This element substitutes the value of the specified attribute for the selected
context. In the preceding example, the value of the Network Address attribute is substituted in the
URL pattern. For more complex parameters, see the definition of <param-type> in the file.
03-Apr-2017 194/311
<$SPECROOT>/tomcat/webapps/spectrum/WEB-INF/common/schema/basic-config.xsd
Important Information About Specifying URLs

Provide the following information when specifying URLs.
Use Standard Characters
Whenever a URL is specified in XML customization code for OneClick, the URL formatting must
adhere to the standards published in the Internet Engineering Task Force (IETF) RFC 1738. Use of non-
standard characters in URLs results in unreliable browser performance including the browser not
locating the specified web page.
URL Encoding of Spaces and Commas
If you are using spaces or commas, or other "reserved" or "unsafe" characters in URLs (see the tables
later in this section), convert them to their ASCII equivalent value with the proper URL encoding. URL
encoding of a character consists of a "%" symbol, followed by the two-digit hexadecimal
representation (case-insensitive) of the ISO-Latin code point for the character. Examples for "space"
and "comma" are:
For spaces, use %20
For commas, use %2C
Note: Some browsers may encounter problems processing URLs even when using this
encoding.
Use of Ampersands
If you are using an ampersand in a URL or in XML customization code, you must convert it to &amp.
Use CDATA in XML
You can place URLs inside a CDATA section so that they are not parsed. This avoids possible problems
with URLs and the XML parser.
Be sure to follow the requirements for CDATA, including:
A CDATA section cannot contain the string "]]>", therefore, nested CDATA sections are not
allowed.
Also ensure there are no spaces or line breaks inside the "]]>" string.
URL Unsafe Characters
Some characters can be misunderstood within URLs for various reasons. These characters should also
always be encoded. Unsafe characters and their hexadecimal encoding are provided in the following
table.
03-Apr-2017 195/311
Character Code Points (Hex)
Space 20
Quotation marks (") 22
'Less Than' symbol ("<") 3C
'Greater Than' symbol (">") 3E
Pound' character ("#") 23
Percent symbol ("%") 25
Left Curly Brace ("{") 7B
Right Curly Brace ("}") 7D
Vertical Bar/Pipe ("|") 7C
Backslash ("\") 5C
Caret ("^") 5E
Tilde ("~") 7E
Left Square Bracket ("[") 5B
Right Square Bracket ("]") 5D
Grave Accent ("`") 60
URL Reserved Characters
URLs use some characters for special use in defining their syntax. When these characters are not used
in their special role inside a URL, they need to be encoded. These characters and their hexadecimal
encoding are provided in the following table.
Character Code Points (Hex)

Dollar ("$") 24
Ampersand ("&") 26
Plus ("+") 2B
Comma (",") 2C
Forward slash/Virgule ("/") 2F
Colon (":") 3A
Semi-colon (";") 3B
Equals ("=") 3D
Question mark ("?") 3F
'At' symbol ("@") 40
03-Apr-2017 196/311
Specify a Username
You can pass the OneClick username of the current user to an application, Web browser, or
executable requiring a username. Use the following expression to specify the logged-in username of
the user:
<param>
<expression>
com.aprisma.spectrum.app.util.context.DefaultApplicationContext.getGlobal
Parameter(com.aprisma.spectrum.app.util.context.ApplicationContext.
USER_PARAMETER_NAME)
</expression>
</param>
Example: Pass Username to Browser
The following example launches a browser to a specified URL and passes the username to the
browser.
<launch-browser>
<url> http://acme.com?user={0}</url>
<param>
<expression> com.aprisma.spectrum.app.util.context.DefaultApplicationContext.
getGlobalParameter(com.aprisma.spectrum.app.util.context.ApplicationContext.
USER_PARAMETER_NAME)
</expression>
</param>
</launch-browser>
Launch an Application From OneClick

The <launch-application> element enables you to launch a specified command or executable.
Example 1: <launch-application>
The following example launches an application called myapp on the client machine and passes in the
IP address of the selected model. As with the <launch-browser> action, you can substitute any
number of parameters.
<command>myapp {0}</command>
<param>
</param>
The <command> element specifies the command or executable to execute. You can provide the path
to the command or executable in one of two ways:
03-Apr-2017 197/311
You can specify the path on each client via an environment variable. To do this in the Solaris
environment, use the PATH environment variable. To create an environment variable in the
Windows environment, select My Computer,Properties,Advanced, and then select the
Environment Variables button.
You can specify an absolute path to the command or executable. If you do this, keep in mind that
the path must be the same on each OneClick client. Path statements in the Windows
environment should use a double backslash instead of a single backslash, for example:
C:\\Windows\\system32\\cmd.exe
Note: You can use the <validate> element to verify that the command or executable exists
on the OneClick client and has execute permissions. If either of these conditions is found to
be false during OneClick startup, the associated menu item is not added to the OneClick
menu. (If the <validate> element is not used, the menu item is always added to the menu,
but its state is determined by the value of other elements.)
If you use the <validate> element, you must specify an absolute path in the <command> element, as
shown in the following example:
<command>c:\\windows\\system32\\notepad.exe</command>
<validate/>
The <command> element must conform to the following syntax rules:
The command arguments are delimited by only spaces. If you would like to have a space within
an argument, you must either place quotes around the argument or use the escape character '\'
prior to the internal space(s).
If you would like to embed quotes within an argument, you must place the escape character '\'
prior to the quote.
If any of your command arguments contain commas, CA Spectrum automatically places the
argument within quotes. This is important to know in case that you are going to parse an
argument that is a numeric value that contains commas.
CA Spectrum replaces arguments that return null or have a string length of zero with empty
quotes ( ).
Example 2: <launch-application>
The following example uses the <platform> element to specify different commands for different
platforms. The <os-name> element specifies the operating system name and the <command>
element specifies the command to execute on that operating system. The <os-name> element is
optional. If you do not specify the <os-name>, the associated command is the default such that if no
other platforms match, the default command is executed.
03-Apr-2017 198/311
<platform>
<os-name>Windows</os-name>
<command>cmd.exe /c start "ping {0}" cmd /c "ping.exe {0}
&&pause"</command>
</platform>
<platform>
<os-name>SunOS</os-name>
<command>>/usr/dt/bin/dtterm -e ping {0}</command>
</platform>
<param>
</param>
At runtime, CA Spectrum compares the specified OS names to the OS name returned by the os.
name Java property. CA Spectrum uses a best-match algorithm so only a prefix of the OS name need
be specified. You may specify any of the following OS names:
SunOS for the Solaris platform
Windows for all Windows platforms
Windows 9x for Windows 95/98
Windows 2000 for Windows 2000
Windows XP for Windows XP
Windows Vista for Windows Vista and Windows Server 2008 R2
Linux for the Linux platform
Mac for the Macintosh platform
If no specified platforms match, the associated menu item is disabled.
Launch a Web Server Script

The <launch-web-server-script> element launches a script on the web server machine. The
<command> element specifies the script to execute. As with the <launch-browser> action, any
number of parameters can be substituted. Since the script resides on the web server, which is
restricted to either a Windows or Solaris machine, you do not use a <platform> element to denote
the platform on which the script is running.
Note: This action can only be used to launch a script; it cannot be used to launch a user
interface.
03-Apr-2017 199/311
Example: <launch-web-server-script> Code
The following example launches myscript on the web server, passing it the model name and model
type name of the selected model. Note that the path that is shown in the <command> element is a
path for a Windows web server.
<launch-web-server-script>
<command>c:/scripts/myscript {0} {1}</command>
<param>
<attribute>AttributeID.MODEL_NAME</attribute>
</param>
<param>
<attribute>AttributeID.MTYPE_NAME</attribute>
</param>
</launch-web-server-script>
Use the <platform> tag with the <launch-web-server-script> as described in Launch an Application
From OneClick.
Pass Table Values to a Script

Used with the <context> and <command> elements, the <column-name> element lets you add menu
items in OneClick that execute a command using data from a selected row in a table. With this
feature, CA Spectrum eliminates the need to look up attributes separately to build the logic. Instead,
you can build the logic from selected column headings within a table and can pass the values from
any row in the table to the script. This ability to pass values directly from a table is helpful when you
need to use the data in an external script. For example, you can build an interface between CA
Spectrum and an issue-tracking system. Then, you can create a menu item that creates trouble
tickets from table data in OneClick.
Note: The <column-name> element works with TableContext only in the <context>
element.
Example: <command> and <column-name> Commands
The following example passes values from three columns (Condition, Status, and Type) to the
"NewTicket" command. The <command> element specifies the command pattern. You specify
parameters to substitute in the command by enclosing the parameter number (starting at 0) in curly
braces {}. You then specify <param> elements for each column that passes values to the command.
<command>$SCRIPT_PATH/NewTicket.exe {0} {1} {2} {3}</command>
<param>
<column-name>Condition</column-name>
</param>
<param>
<column-name>Status</column-name>
</param>
03-Apr-2017 200/311
<param>
<column-name>Type</column-name>
</param>
CA Spectrum processes the <param> elements in order so the first one corresponds to the 0th
parameter in the command pattern. By default, CA Spectrum passes the raw value to the command.
To preserve the formatting information from the table, use the <formatted/> option, as follows:
<param>
<column-name>Condition
<formatted/>
</column-name>
</param>
Note: The formatted option attempts to render the specified column as seen in the table.
However, CA Spectrum cannot pass images as arguments to commands and, therefore,
passes the raw value only.
Display the Status of a Launched Application or Script

Use the <display-exit-status> and <display-output> elements with <launch-web-server-script> and
<launch-application> to display the exit status and the output from the script or application.
By default <display-exit-status> displays Success if the exit code is 0 and Failed with error code #
otherwise. You can change the default behavior by specifying <status> child tags that map an exit
code to a custom message to display.
Example: <display-exit-status> Code
Examine the following example using <display-exit-status>:
<display-exit-status>
<status code="1">Could not open file</status>
<status code="2">Bad parameter</status>
<status code="3">Could not connect to the server</status>
<status default="true">Unknown error code {0}</status>
</display-exit-status>
This example maps status codes 1, 2, and 3 to specific message strings. The last status code specifies
default=true, mapping all other error codes except 0, which by default maps to Success. If exit
code 0 does not indicate success, you can override it with a <status> tag. The {0} in the message
string substitutes the exit code.
By default, <display-output> displays both the standard output and standard error output from the
process. You can display only the standard output by specifying:
<display-output stdout="t"/>
or only the standard error output by specifying:
03-Apr-2017 201/311
<display-output stderr="t"/>
Note: The <display-exit-status> and <display-output> elements can only be used for
command line applications or scripts and not GUI applications. OneClick waits for the script
to complete before being available to the user again.
Customizing OneClick Alarms

You can create custom alarm attributes and add them to the Alarm table and Information views.
Adding customized alarm attributes that display in OneClick is a multi-step process that requires
using the Model Type Editor and the Alarm Preferences dialog, in addition to modifying the Alarm
table and the Alarm Information view to display the custom alarm attributes.
To create and view custom alarm attributes
1. Create the custom alarm attributes by adding them to the GlobalAlarm model type using the
Model Type Editor. The attribute group ID value must be set to equal 11f4c.
Note: For information on how to add custom alarm attributes to the GlobalAlarm
model type see Model Type Editor (see page 107). The section provides complete
instructions on accessing and using the Model Type Editor.
2. Add a column to the Alarm table that displays the new customized alarm attribute by
customizing the alarm-table-config.xml file. Modify Table Columns provides an example
showing how to add a column to a table configuration file.
3. Add a field to the Alarm Details view configuration that displays the alarm attribute in the
alarms Information tab by customizing the view-alarmdetails-config.xml file. Extend or
Modify an Information View provides information and examples on how to add a subview to
an existing information view.
You can also apply a custom privilege to the new alarm attribute by customizing the custom-
privileges.xml file. Doing this limits which users or user groups or specific privileges are
required to view the customized alarms. The name of the privilege must use the following
syntax:
alarm-write-<attribute ID in hex>
The following example adds the new privilege to the Alarm Management group.
<alarm-write-ffff0000 type="write">
<group scope="alarm-manager">alarm-mgmt</group>
<label>New Alarm Attr</label>
</alarm-write-ffff0000>
03-Apr-2017 202/311
4. Save and close the XML files you edited.
5. You must restart the OneClick server in order to apply the new privilege.
6. You must restart the OneClick Console to view the changes made to the Alarms table and
Alarm Information view.
Customizing OneClick Tables

Contents
Modify Table Columns (see page 203)

Define How Cells Display in Table Columns (see page 208)
Make a Table Column Editable (see page 212)
This section discusses some of the ways that you can modify existing tables found in the OneClick
Console. A list of the table elements available in OneClick and their descriptions are presented in
Example: Defining a Table Column. Specific examples for modifying table columns are presented in
the sections listed below.
Modify Table Columns

If you want to display additional attributes in a OneClick console table, you can do so by making
modifications to the XML using a customization file. The modifications need to be made in a separate
XML file in the appropriate directory under <$SPECROOT>/custom/.
Extend a Factory Default File Using IDREF

OneClick requires that you write your customization code in a new file located in the <$SPECROOT>
/custom/topo/config directory that uses the same name as the factory default file that builds the
table you are modifying. Use the IDREF attribute to reference the factory file and extend it with the
new customization file. See Create Customizations for details on creating customization files in
OneClick.
Example: Referencing a Column File from a Table Configuration File
The following example shows a portion of an XML file used to define a table. Rather than defining
each column in the same file that defines the entire table, the example uses separate files to define
the first two columns in the table. The example uses the idref attribute with each <column> element
to link to the file that defines the column.
<table id="table-licenses-config"
xmlns="http://www.aprisma.com"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.aprisma.com
../../common/schema/table-config.xsd">
<swing-row-template>
<enumerated-color idref="alternatingrow-color-config"/>
</swing-row-template>
03-Apr-2017 203/311
<swing-table-template>
<show-vertical-lines>true</show-vertical-lines>
<show-horizontal-lines>false</show-horizontal-lines>
</swing-table-template>
<swing-header-row-template>
<static-color idref="row-header-color-config"/>
</swing-header-row-template>
<column-list>
<column idref="column-servicestate-config"/>
<column idref="column-modelname-config">
<default-width>300</default-width>
</column>
</column-list>
.
.
</table>
The first column is defined in the column-servicestate-config.xml file. The beginning portion of this
file is shown below. Note the id attribute used with the <column> element to define this file as
column-servicestate-config.
<column id="column-servicestate-config"
Modify a Table Column

The following steps describe the general process for modifying table columns in OneClick. Specific
examples are provided in the following sections.
To modify a table column
1. Identify the default factory XML file that builds the table that you want to modify.
Many of the table files used to display data in the OneClick console are located in
<$SPECROOT>/tomcat/webapps/spectrum/WEB-INF/topo/config. All of the table files are
named for the functionality that they display. For example, the table used to display interface
information for each model is called table-common-ifconfig-config.xml.
2. Create the file in which to add your modifications.

In this example the default file is <$SPECROOT>/tomcat/webapps/spectrum/WEB-INF/topo/
configtable-common-ifconfig-config.xml. Create a file with the same name in the
<$SPECROOT>/custom/topo/config directory. If a file with that name already exists in this
directory, that is an indication that previous customizations have been made to this table. In
this case, add your customized code to the existing file.
3. Open the file in a text editor in order to make the appropriate modifications.
4. Use idref to reference the table configuration you are extending with this new column
configuration (see Step 1).
5.
03-Apr-2017 204/311
5. Construct a new column using the XML elements defined in Example: Defining a Table
Column. The example that follows this procedure shows how some of these elements are
used to define a column.
6. Find the <column-list> element in the XML file. The <column-list> element contains all of the
<column> elements used to define each column in the table.
7. Define a <column> element within the <column-list> element. The columns display in the
order they appear within the <column-list> element.
8. Insert the <name> element to define the title of the column.
9. Insert a <content> and an <attribute> element to define the contents you want to display in
the column.
10. (Optional) Use the <default-width> element to define the default width of the column.
11. Save and close the modified file, and restart the OneClick console to view the changes.
Example: Defining a Table Column
<column-list>
<column>
<name>Interface</name>
<content>
<attribute>0x100c4</attribute>
</content>
</column>
.
.
.
</column-list>
The following table describes the elements used for modifying a table.

Element
<table> Not This is the root element, and encloses all child elements used to create a table.
applicab
le
<swing- <table> Used to define the appearance of the table.
table-
templat
e>
<show- <swing- Defines whether to show vertical lines in the table, values are true or false.
vertical- table-
lines> templat
e>
Defines whether to show horizontal lines in the table, values are true or false.
03-Apr-2017 205/311

Element
<show- <swing-
horizont table-
al- templat
lines> e>
<line- <swing- Defines the color of the lines used to create the table. The default value is light-
color> table- background_color. Other values can be found in the <$SPECROOT>/tomcat
templat /webapps/spectrum/WEB-INF/console/common/config/
e> common-color-config.xml file.
<show- <swing- Defines whether the table will be shown with dashed lines connecting tree nodes,
tree- table- values are true or false.
lines> templat
e>
<preferr <swing- Defines (in pixels) the default width of the table.
ed- table-
width> templat
e>
<preferr <swing- Defines (in pixels) the default height of the table.
ed- table-
height> templat
e>
<swing- <table> Used to define the appearance of the header row of the table.
header-
row-
templat
e>
<static- <swing- Specifies the color for the header row. Use value idref=row-header-color-config for
color> header- consistency.
row-
templat
e>
<swing- <table> Used to define the appearance for the body rows in the table.
row-
templat
e>
<enume <swing- Used to specify different colors for each row of the table, the default value used is
rated- row- alternating row-color-config.
color> templat
e>
<static- <swing- Used to specify a single color used for all of the rows in the table.
color> row-
templat
e>
<colum <table> Used to define the list of columns to be used in the table
n-list>
<colum <colum Used to define a column in the column list.
n> n-list>
03-Apr-2017 206/311

Element
<name> <colum The name of the column. The text used here will appear in the table header for this
n> column.
<editabl <colum Defines whether the value in the table can be edited. If this value is set to true, a
e> n> set link appears next to the value.
<conten <colum Defines the value placed in the column. This is the value used for sorting and
t> n> filtering. See "Rendering a value" for information on what child elements can be
specified. The final displayed text can be further manipulated by defining a <swing-
cell-template> tag. See Define How Cells Display in Table Columns for information
on <swing-cell-template>.
<render <conten Specifies the renderer to be used for the content of the column. See Customize the
er> t> Port Name Column of the Interface Table for more information.
<dynam <conten Enables you to specify a renderer depending on model class or model type. See
ic- t> About <dynamic-renderer> for detailed instructions on usage.
rendere
r>
<expres <conten Used to define an expression to produce a value for the column. See XML Usage
sion> t> Common to All Customization Files for more information
<messa <conten Used for specifying a plain text value for the column.
ge> t>
<select> <conten Used to select a value for the column based on certain criteria. See XML Usage
t> Common to All Customization Files for more information.
<attribu <conten Used to specify an attribute ID. The value of the attribute will be placed in the
te> t> column.
<swing- <colum Used to define how the cell in the column is displayed. See Define How Cells
cell- n> Display in Table Columns for detailed information on using this element.
templat
e>
<image <swing- Used to display an image in a cell.
> cell-
templat
e>
<attribu <image The attribute used to determine the image selection.
te> >
<select> <image Used to define the image that is selected. See XML Usage Common to All
> Customization Files for more information.
<text> <swing- Used to display a string of text in a cell.
cell-
templat
e>
<render <text> The renderer used to manipulate the text. See Customize the Port Name Column of
er> the Interface Table for an example. See Manipulate Attribute Output Using
Renderers for detailed information on OneClick renderers.
<param <render Specifies any parameters to be used by the renderer. See About Parameters for
> er> detailed information.
03-Apr-2017 207/311

Element
<render <swing- The class to use for rendering something other than an image or text.
er- cell-
class> templat
e>
<editabl <colum Allows the user to edit the value in a column. See Make a Table Column Editable for
e> n> more information.
<hidden <colum Use this element to hide the column by default. The user must add the column to
-by- n> the table using the preferences dialog.
default>
<default <colum The default width of the column in pixels.
-width> n>
<default <colum Used in conjunction with the <sort-column-list> element to determine how the
-sort> n-list> table is sorted by default.
<sort- <default A list of columns that will be sorted on (maximum of three).
column- -sort>
list>
<sort- <sort- The column to be sorted on. Columns will be sorted in the order that they are
column column- listed.
> list>
<name> <sort- The name of the column to sort on. This must match the name defined for the
column column.
>
<directi <sort- The direction of the sort, values can be ascending or descending.
on> column
>
Define How Cells Display in Table Columns

The <swing-cell-template> defines the final presentation of content within the cell of a table column.
Use this element in conjunction with the <content> element to specify how the content is presented
to users. This element gives the developer flexibility in processing raw OneClick data using buttons,
scrollable lists, wrapping text, and other techniques.
If you do not specify <swing-cell-template> in a column cell definition, the raw output from the
<content> element is displayed without refinement. The elements you can use in defining <swing-cell-
template> are described in the following table.

Element
<image <swing- Defines an image displayed in the cell.
> cell-
template
>
<text>
03-Apr-2017 208/311

Element
<swing- Defines the text to display in a cell. If no child elements are specified, then the
cell- text from the <content> element is displayed.
template
>
<render <swing- Specifies a Java class to use for the final presentation of data in a cell. See Use
er- cell- Renderers to Present Data in Column Cells for the renderers available to use with
class> template this element.
>
The following Java classes are available to use with <renderer-class> to render or manipulate and
format raw data for display in table column cells.
TextAreaCellRenderer
Use this renderer to display text that wraps at the cell width.
Classname: com.aprisma.spectrum.app.swing.table.render.TextAreaCellRenderer
Supported Parameters: None
Example: Displaying Wrapping Text in a Cell
The following example creates a cell that displays text and allows it to wrap at a defined width,
displaying in multiple lines of fixed width. This technique is used in the Notes field on the devices
Information tab. Text entered by operators in this field wraps at a predetermined column width.
<swing-cell-template>
<text/>
<renderer-class>
com.aprisma.spectrum.app.swing.table.render.TextAreaCellRenderer
</renderer-class>
</swing-cell-template>
ListAttributeRenderer
Displays the values from a list-type attribute in a scrollable list.
Classname: com.aprisma.spectrum.app.swing.table.render.ListAttributeRenderer
Supported Parameters:
<attrID> - Required parameter. ID of the CA Spectrum attribute displayed in the cell.
<maxRowsToDisplay> - Integer; specifies the maximum number of viewable list entries, scrolling
is turned on after this maximum is exceeded.
<order> - True or false; if true, the users can modify the list order if the column is editable.
<add> - True or false; if true, users can add new entries to the list if the column is editable.
<remove> - True or false; if true, users can remove entries from the list if the column is editable.
03-Apr-2017 209/311
<remove> - True or false; if true, users can remove entries from the list if the column is editable.
<valuePrompt> - The text displayed when prompting the user to add a new value to the list. If not
specified, a default prompt is used.
Example: Displaying a Scrollable List in a Cell
The following example defines the maximum number of rows displayed in the cell as four; if there are
more than four rows, the list becomes scrollable.
<renderer-class>
com.aprisma.spectrum.app.swing.table.render.ListAttributeRenderer
<param name="maxRowsToDisplay">4</param>
<param name="attrID">0x25e0039</param>
<param name="add">true</param>
<param name="remove">true</param>
<param name="valuePrompt">SNMP Port</param>
</renderer-class>
ListAttributeOIDRenderer
Displays the OIDs from a list-type attribute in a scrollable list.
Classname: com.aprisma.spectrum.app.swing.table.render.ListAttributeOIDRenderer
Supported Parameters: See ListAttributeRenderer.
<oidPrompt> - The text displayed when prompting the user to add a new OID to the list. If not
specified, a default prompt is used.
ActionButtonCellRenderer
Displays a button in the cell that sends an action to the model when clicked.
Classname: com.aprisma.spectrum.app.topo.client.render.ActionButtonPanelCellRenderer
<actionID> - Required parameter; the CA Spectrum attribute ID for the action the button sends.
<text> - Required parameter; the text displayed on the button.
<toolTipText> - The text displayed in a tooltip for the button.
<prompt> - The text displayed when prompting the user to confirm a button click. If not specified,
no prompt is displayed.
<confirmSuccess> - True or false; if true, a message is displayed if the action was successful.
Example: Displaying an Action Button in a Cell
03-Apr-2017 210/311
<renderer-class>
com.aprisma.spectrum.app.topo.client.render.ActionButtonCellRenderer
<param name="actionID">0x0001011f</param>
<param name="text">Reevaluate Model Names</param>
<param name="toolTipText">
Reevaluates all model names based on the model naming order of VNM
</param>
<param name="confirmSuccess">true</param>
</renderer-class>
ActionButtonPanelCellRenderer
Displays one or more buttons that each send an action to the model. All parameters are specified as a
semi-colon separated list, one per button.
Classname: com.aprisma.spectrum.app.topo.client.render.ActionButtonPanelCellRenderer
Supported Parameters: See ActionButtonCellRenderer.
Example: Displaying Multiple Action Buttons in a Cell
The following example defines two buttons, Reconfigure Model and Discover Connections. The
parameters with a value for each button separate each value with a semi-colon (;).
<renderer-class>
com.aprisma.spectrum.app.topo.client.render.ActionButtonPanelCellRenderer
<param name="actionID">0x1000e;0x25e0022</param>
<param name="text">Reconfigure Model;Discover Connections</param>
<param name="confirmSuccess">true;true</param>
</renderer-class>
AttrToggleButtonCellRenderer
Displays a button with text that can be one of two values based on two specified values of an
attribute. When the button is clicked, the opposite value is written to the attribute.
Classname: com.aprisma.spectrum.app.topo.client.render.AttrToggleButtonCellRenderer
<attrID> - Required parameter. ID of the CA Spectrum attribute that the button toggles the value
of.
<firstValueMapping> - Required parameter. Specifies the first attribute value and the text to
display when the attribute equals this value, separated by a semi-colon.
<secondValueMapping> - Required parameter. Specifies the second attribute value and the text
to display when the attribute equals this value, separated by a semi-colon.
<promptOnFirstValue> - Specifies the text used to prompt the user for confirmation when the
03-Apr-2017 211/311
<promptOnFirstValue> - Specifies the text used to prompt the user for confirmation when the
button is clicked and the attribute equals the first value. If not specified, no prompt is displayed.
<promptOnSecondValue> - Specifies the text used to prompt the user for confirmation when the
button is clicked and the attribute equals the second value. If not specified, no prompt is
displayed.
<disableOnFirstValue> - True or false; if true, the button is disabled when the attribute equals the
first value.
<disableOnSecondValue> - True or false; if true, the button is disabled when the attribute equals
the second value.
Example: Displaying a Toggle Action Button in a Cell
<renderer-class>
com.aprisma.spectrum.app.topo.client.render.AttrToggleButtonCellRenderer
<param name="attrID">0x11b6e</param>
<param name="firstValueMapping">true;Start</param>
<param name="secondValueMapping">false;Stop</param>
<param name="promptOnSecondValue">Are you sure you want to stop?</param>
</renderer-class>
BoldAttributeTableCellRenderer
Displays the cell text in bold.
Classname: com.aprisma.spectrum.app.swing.table.render.BoldAttributeTableCellRenderer
Example: Displaying Bold Text in a Cell
<text/>
<renderer-class>
com.aprisma.spectrum.app.swing.table.render.BoldAttributeTableCellRenderer
</renderer-class>
Make a Table Column Editable

In some cases, you can allow the user to edit the value found in a particular table cell in the column.
The Acknowledged column in the Alarms table and the Admin Status column in the Interface
Configuration table are examples of columns that allow users to edit.
Customize the Alarm Table Acknowledge Field

Some organizations may prefer to see text displayed in the Acknowledged column (yes or no)
instead of the default check mark or blank space. This section describes how to make the
Acknowledged column in the Alarms table editable by extending the factory XML file.
03-Apr-2017 212/311
The following figure shows the default Acknowledged field in the Alarms table and the Acknowledged
field after customizing it to make it editable.
SPEC--Customized Alarms tab: Acknowledged column
Check to see if the file <$SPECROOT>/custom/alarm/config/alarm-table-config.xml already exists. It

exists in this directory if previous customization have been made to this file. If the file does not exist,
create it.
To create an editable Acknowledged column
1. Open the file and add the following XML
<table idref="alarm-table-config">
<column-list>
<column idref="column-alarmacknowledge-config">
<editable/>
</column>
</column-list>
</table>
2. Save and close the alarm-table-config.xml file.
3. Restart the OneClick client for the changes to take effect.

This code overrides the "column-alarmacknowledge-config" entry in the factory alarm-table-
config.xml file.
03-Apr-2017 213/311
Display Instanced Attribute Values in Separate Table Rows

If you add a new table column for attributes with instanced values (such as, PortName and
BoardToPortMap), adding ObjectIDValueListRenderer and the <refID> to your XML file helps ensure
the data displays correctly. Using this renderer without the <refID> value, CA Spectrum displays all
values returned for the selected OID value list attribute in every row.
SPEC--Table column with instanced attribute before rendering values into separate rows
When the <refID> value is added to the XML file, CA Spectrum displays the attribute values correctly,
rendering only the particular value from the list that applies to a given row.
SPEC--Table column with instanced attribute after rendering values into separate rows
The supported parameters include the following:
<attrID> - Required parameter. ID of the CA Spectrum attribute displayed in the cell.
<refID> - Required parameter. Reference ID for the CA Spectrum attribute that is used for
indexing the attribute values.
Example: Displaying a Single OID Value in Each Row of a Column
The following example shows the contents of the column-portname-config.xml file used to create a
custom table column for the Port Name attribute.
<?xml version="1.0" encoding="UTF-8"?>

<column id="column-portname-config"
xmlns ="http://www.aprisma.com"
03-Apr-2017 214/311
../../common/schema/column-config.xsd">
<name>Port Name</name>
<content>
<renderer>
<param name="attrID">0x11c0056</param>
<param name="refID">0x1297f</param>
com.aprisma.spectrum.app.util.render.ObjectIDValueListRenderer
</renderer>
</content>
</column>
Other Customizations in Tables

Contents
Customize Alarm Table Row Colors (see page 215)
Set Up a Default Sort (see page 216)
Customize the Port Name Column of the Interface Table (see page 217)
Sort Interfaces Table by ifIndex (see page 218)
Customize Alarm Table Row Colors

You can customize the background color displayed in each row of the Alarms table. By default, each
row in the Alarms table takes on the background color associated with the alarm listed in the row.
Customize the Alarms table to display in alternating gray and white rows by changing the swing-row-
template definition from enumerated-severity-color-config to alternatingrow-color-config.
To customize the Alarm table colors
1. Create an alarm-table-config.xml file (if one does not already exist) in the <$SPECROOT>
/custom/alarm/config directory.
2. Use the idref attribute to reference the factory file being extended: alarm-table-config.xml.
3. Define <enumerated-color> to reference alternatingrow-color-config.
4. Save and close the file.
5. Close and restart the OneClick Console to view the changes.
Example: Modifying the Alarm Table Row Color
<table idref="alarm-table-config">
</table>
03-Apr-2017 215/311
Set Up a Default Sort

You can create a default sort criteria for a table using the <default-sort> element and its child
elements. You can sort on a maximum of three columns. CA Spectrum sorts the columns in the order
in which they are listed in <sort-column-list>.
To set up a default sort
1. Identify the appropriate XML file that is used to build the table. All of the table files that are
used to display data in the OneClick console are located in the <$SPECROOT>/tomcat/webapps
/spectrum/WEB-INF/topo/config directory. All of the table files are named after the
functionality that they display. For example, the table used to display interface information
for each model is called table-common-ifconfig-config.xml.
2. Determine if this file exists in the <$SPECROOT>/custom/topo/config directory. It exists in this

directory if previous customizations were made to this file. If it is not there, copy the factory
table file into the <$SPECROOT>/custom/topo/config directory.
3. Open the file in a text editor in order to make the appropriate modifications.
4. Find the closing tag for the column-list element, </column-list>.
5. Insert the XML to create the default sort after the </column-list> using the <default-sort>
element.
6. Save and close the XML file.
7. Restart the OneClick client for your changes to take effect.
Example: Using <default-sort>
<table>
<column-list>
.
.
.
</column-list>
<default-sort>
<sort-column-list>
<sort-column>
<name>Name_of_first_column_to_sort</name>
<direction>ascending</direction>
</sort-column>
<sort-column>
<name>Name_of_second_column_to_sort</name>
</sort-column>
<sort-column>
<name>Name_of_third_column_to_sort</name>
</sort-column>
</sort-column-list>
</default-sort>
03-Apr-2017 216/311
Note: Include the specific text for the contents of each <name> element based on the
column list entries.
Customize the Port Name Column of the Interface Table

You can change the tree column in the interface table to display something other than model name
which is the default attribute displayed. This type of customization requires you to override the
factory content-iftree-config.xml file.
To customize the port name column
1. Determine if the file <$SPECROOT>/custom/topo/config/content-iftree-config.xml exists. It

already exists in this directory if previous customizations have been made to this file. If the file
does not exist, create this file in the specified directory by copying it from <$SPECROOT>
/tomcat/webapps/spectrum/WEB-INF/topo/config and pasting it into <$SPECROOT>/custom
/topo/config.
2. Find the following code in the content-iftree-config.xml file that creates the column
containing the model name attribute:
<content id="content-iftree-config"

<expression>
(((String)value()).length() == 0 ||
((String)value()).equals("GnPort")) ?
attr(0x1006a).toString(): value()
</expression>
</content>
Note: The contents of the <expression> element are specific to the use of the
Model_Name attribute and should be removed when specifying other attributes.
3. Customize the attribute displayed in the Port Name column by changing the
<attribute><value></attribute> element to contain the attribute you want to display. To
display a different attribute, change <value> to the desired attribute ID. You can specify the
integer ID (for example, 0x129e0) or a predefined constant. The table beneath this procedure
lists the predefined Port Attributes and their integer IDs.
To display the port description, edit the file as follows:
<content id="content-iftree-config"
03-Apr-2017 217/311
<attribute>AttributeID.PORT_DESCRIPTION</attribute>
</content>
4. Save and close <$SPECROOT>/custom/topo/config/content-iftree-config.xml.
5. Close and restart the OneClick client to see the changes take effect.
Predefined Port Attribute Value Constant Integer ID

AttributeID.PORT_DESCRIPTION 0x129e0 (ifDescr)
AttributeID.PORT_TYPE 0x129ed (ifType)
AttributeID.COMPONENT_OID 0x1006a
Sort Interfaces Table by ifIndex

CA Spectrum sorts the interfaces in the Interfaces table by the first column, which is the interface
model name. CA Spectrum sorts this field alphabetically based on the textual values.
To sort the interfaces table numerically by ifIndex value
1. Edit the definition of the interfaces table content definition file acquire the ifIndex data. Check
the <$SPECROOT>/custom/topo/config directory to see if the content-iftree-config.xml file
exists. The file exists in this directory if previous customizations have been made to it.
2. If the file is not in this custom directory, create it by copying it from <$SPECROOT>/tomcat
/webapps/spectrum/WEB-INF/topo/config and pasting it into the <$SPECROOT>/custom/topo
/config directory.
3. Open the file and find the line that reads:
4. Change this line to read:
<attribute>0x1006a</attribute>
Note: The 0x1006a attribute is Component_OID (which is rolled from ifIndex).The

contents of the <expression> element are specific to the use of the Model_Name
attribute and should be removed when specifying other attributes.
5. Save your changes to the content-iftree-config.xml file.

In the following steps, you edit the interface table column definition file to relabel the Model
Name column to be the Index column, as it will display the interface index value instead of the
model name.
6. Open the <$SPECROOT>/custom/topo/config directory and check to see if the column-iftree-
03-Apr-2017 218/311
6. Open the <$SPECROOT>/custom/topo/config directory and check to see if the column-iftree-

config.xml file already exists there. If it does not, go to the <$SPECROOT>/tomcat/webapps
/spectrum/WEB-INF/topo/config directory and find the column-iftree-config.xml file. Copy it
and paste it into the <$SPECROOT>/custom/topo/config directory.
7. Find the line that reads:
<name>com.aprisma.spectrum.app.util.render.ModelNameColumn</name>
<name>Index</name>
9. Save your changes to the column-iftree-config.xml file.

In the following steps, you edit the interface table configuration file to change the name
element value from the model naming java class to the text Index.
10. Open the <$SPECROOT>/custom/topo/config directory and check to see if the interfaces-
table-config.xml file already exists there. If it does not, go to the <$SPECROOT>/tomcat
/webapps/spectrum/WEB-INF/topo/config/ directory and find the interfaces-table-config.xml
file. Copy it and paste it into the <$SPECROOT>/custom/topo/config directory.
11. Find the line that reads:
<name>com.aprisma.spectrum.app.util.render.ModelNameColumn</name>
<name>Index</name>
13. Save your changes to the interfaces-table-config.xml file.
14. Close all of the text files and restart the OneClick console in order for the changes to take
effect.
If you would like to retain the interface model name in the table, implement the following additional
instructions:
1. Open the <$SPECROOT>/custom/topo/config/interfaces-table-config.xml file.
2. Find the following entry within the <column-list> element:
<column idref="column-iftree-config">
</column>
3. Add the following three lines to the end of this entry.
<column idref="column-ifmodelname-config">
</column>
4. Save your changes and close the XML file.
03-Apr-2017 219/311
5. Close and restart the OneClick console in order for the changes to take effect.
Adding Support for Model Types or Model Classes

Contents
Create a Registration (see page 220)

Register the Model Type or Model Class in custom-app-config.xml (see page 220)
Define General OneClick Device Support Based on Model Class (see page 221)
Define Specific OneClick Device Support Based on Model Type (see page 223)
Define Model Appearance (see page 224)
Configure Icons for OneClick Themes (see page 225)
Using the <theme-config> Element to Create Icon Appearance (see page 227)
Design On-Page and Off-Page Reference Icons (see page 227)
Use <on-page> and <off-page> Elements (see page 229)
Define the Icon Shape (see page 230)
Define Pipe Connection Location (see page 233)
Define Image Components (see page 234)
Create an Icon Label (see page 238)
The default-iconlabel-config.xml File (see page 239)
Adjust Icon Label Background Width (see page 241)
Default Label Width Settings (see page 241)
Create Fixed Width Icon Labels (see page 241)
Define Text Components (see page 242)
Define Selection Components (see page 242)
Define Model Icon Tooltips (see page 245)
This section describes how to add or extend OneClick support for a CA Spectrum model type or
model class. For example, you may want to add specific OneClick support for a management module
that you have created with the Generic SNMP Toolkit in CA Spectrum.
Create a Registration
If you have created a new model type or model class, you can use the XML elements described in this
chapter to configure the associated model appearance, available information, and views within the
OneClick interface.
Register the Model Type or Model Class in custom-app-config.xml

OneClick registration for new model types and model classes is performed within the custom-app-
config.xml file. Doing so enables one to configure OneClick support on a per model type and/or
model class basis. There are two methods for registration:
Contents registry
Component details registry
03-Apr-2017 220/311
Component details registry
Both of these registrations work in conjunction with each other to provide effective OneClick support
for CA Spectrum models. The component details registry acts as an extension of the contents registry
in order to define general and specific OneClick device support.
Because most models of a given model class will share the same OneClick device support, typically
you define a contents registry for the model class to define this general support. However, for a given
model class, you might want to expose different information in the Component Details panel based
on model type. To accomplish this, you define a component details registry for the applicable model
type. As a result, the model receives its general, shared content from the contents registry, and it
receives its more specific component details content from the component details registry.
Consider the example illustrated in the following figure. There are two routers of model class 4
(switch-router). They both receive their general information from the contents registry that has been
registered with model class 4. However, the model of type 0xffe00000 receives its component details
content from the component details registry. Because the model of type 0xffe00001 does not have a
component details registry, it receives all of its configuration content from the contents registry.
SPEC--register_model
Define General OneClick Device Support Based on Model Class

The contents registry (denoted by the <oi> element) is primarily used to define the general, shared
configuration for a model class or a group of model types. By default, CA Spectrum defines this
general behavior for most model classes. Therefore, if you set the appropriate model class for your
custom model type, it automatically inherits this generic content.
If the default configuration meets most of your requirements, but you want to modify the
information in the Component Detail panel, you should only create a component details registry for
the applicable model type.
03-Apr-2017 221/311
However, if you create a new model class, or you want to define a specific model appearance for a
model type, you need to create a contents registry entry using the XML elements described in the
following table.

Element
<app- ot The root element for the custom-app-config.xml file.
config> applicab
le
<conten <app- Used to associate a single or group of model classes and/or model types to
ts- config> configuration files that define model appearance and tooltip content.
registry (Optional) You can use the scope attribute to specify the location of the
> configuration xml files you are using (when you are not using the default locations
of console, topo, or common). The scope attribute has to match the directory name
where the existing configuration xml files reside, as follows:
<$SPECROOT>/tomcat/webapps/spectrum/
WEB-INF/<scope>/config
For example, <contents-registry scope=devman> specifies the devman/config
directory, which contains the configuration xml files for device management views
and subviews.
<model- <conten Registers a model class for this contents registry.
class> ts-
registry
>
<model- <conten Registers a model type for this contents registry.
type> ts- Model types should only be registered for a contents registry if you need a unique
registry topology icon or tooltip. If you only want to configure component detail content for
> a model type, use the <component-details-
registry> instead of the <contents-registry>.
<is- <conten Registers a parent model type and all of its derived model types for this contents
derived- ts- registry.
from> registry Model types should only be registered for a contents registry if you need a unique
> topology icon or tooltip. If you want to configure only component detail content for
a model type, use the <component-details-
registry> instead of the <contents-registry>.
<icon- <conten The icon registration ID that identifies the icon configuration to use. The icon
reg-id> ts- configuration defines the appearance of the icon in OneClick.
registry
>
<tooltip <conten The XML that defines the tooltip content for topology icons.
- ts-
config> registry
>
<table- <conten Specifies the XML that configures the columns available on the List tab in the
config> ts- Contents panel.
registry
>
Specifies the XML that defines the content of the model's Information tab.
03-Apr-2017 222/311

Element
<inform <conten
ation- ts-
config> registry
>
<perfor <conten Specifies the XML that defines the contents of the model's Performance tab, where
mance- ts- one or more graphs can be defined to show the values of model attributes over
config> registry time. The contents of these graphs are real time; the data is only available for the
> current OneClick client session.
<interfa <conten Specifies the XML that configures the table on the Interfaces tab.
ce- ts-
table- registry
config> >
Define Specific OneClick Device Support Based on Model Type

As mentioned earlier in this chapter, the contents registry defines the general OneClick device
support. If you want to define specific device support on a per model type basis in the OneClick
client, you should define a component details registry (denoted by the <component-details-registry>
element). The component details registry defines the contents for the views within the Component
Detail panel.

Element
<app- Not The root element for the custom-app-config.xml file.
config> applicab
le
<compo <app- Used to associate a single or group of model classes and/or model types to
nent- config> configuration files that define the content in the Component Detail panel.
details The same child elements of <component-details-registry> are supported within
registry <contents-registry>. However, since <component-details-registry> is an extension
> of <contents-registry>, all elements that are not defined are inherited from
<contents-registry>. If both are registered for the same model type or model class,
<component-details-registry> takes precedence over <contents-registry>.
<model- <conten Registers a model class for this component details registry.
class> ts-
registry
>
<model- <conten Registers a model type for this component details registry.
type> ts-
registry
>
<is- <conten Registers a parent model type and all of its derived model types for this contents
derived- ts- registry.
from> registry
>
Specifies the XML that defines the content of the model's Information tab.
03-Apr-2017 223/311

Element
<inform <conten
ation- ts-
config> registry
>
<perfor <conten Specifies the XML that defines the contents of the model's Performance tab, where
mance- ts- one or more graphs can be defined to show the values of model attributes over
config> registry time. The contents of these graphs are real time; the data is only available for the
> current OneClick client session.
<interfa <conten Specifies the XML that configures the table on the Interfaces tab.
ce- ts-
table- registry
config> >
Define Model Appearance

You can define the model appearance as it will look within the OneClick client through XML
configuration (for example, topology, Component Detail header, navigation hierarchy, and so on).
This is accomplished using the contents registry on a per model class and/or model type basis.
Within the contents registry entry, you need to specify an icon registration ID (<icon-reg-id>). As
shown in the following figure, this ID maps to theme configuration entries (<theme-config>) that
define the XML files used to construct the model appearance for a specific theme. By default,
OneClick includes three icon themes: OneClick, Utility, and Classic.
SPEC--model_appearance
03-Apr-2017 224/311
In the preceding XML example, the contents registry for model class 7 specifies the <icon-reg-id> as
mydevice-icon-config. For this ID, a theme configuration is created for each of the three themes
included with OneClick: OneClick, Utility, and Classic. Within the theme configurations, the XML files
that construct the icons are specified.
The following procedure outlines the process to define a models appearance in the OneClick user
interface using each of these elements.
To define a models appearance in the OneClick user interface
1. If it does not already exist, create a file named <$SPECROOT>/custom/console/config/custom-

app-config.xml by copying <$SPECROOT>/tomcat/webapps/spectrum/WEB-INF/console
/config/
custom-app-config.xml.
If the file already exists, it already contains customized changes to the factory default file, and
you should make your additional changes in it.
2. Open the file with a text editor.
3. Create a contents registry entry for the applicable model types and/or model classes.
<contents-registry>
...
<model-type>0xffff0000</model-type>
<model-class>2</model-class>
...
</contents-registry>
4. Within the contents registry, specify an icon registration ID. This ID will map to theme
configuration entries.
5. For each desired theme, create a <theme-config> entry. These entries will be identified using
the registration ID from the previous step.
6. Design the appearance of the icon for each theme as described in Design On-Page and Off-
Page Reference Icons.
7. Define the tooltips for the icons as described in Define Model Icon Tooltips.
8. Once you have created support for a models appearance, you may want to customize the
views and information available in the models Component Detail panel.
9. Save and close the <$SPECROOT>/custom/console/config/custom-app-config.xml file.
Configure Icons for OneClick Themes

By default, OneClick includes three icon themes:
OneClick (default theme)
03-Apr-2017 225/311
Utility
Classic
The default OneClick theme is the most robust and, therefore, is the recommended theme for use.
The elements that you can use to create a theme configuration are described in the following table:

Element
<theme <app- Defines the theme configuration for a specific icon registration ID.
- config>
config>
<icon- <theme The icon registration ID that maps the theme configuration to the contents registry
reg-id> - for one or more model types and/or model classes.
config>
<enume <theme Specifies that an enumerated cell icon image should be used for the model
rated- - hierarchy tree. The idref attribute of this element defines the id of the chosen
cellicon config> cellicon. Predefined icons exist in the <$SPECROOT>/tomcat/webapps/spectrum
> /WEB-INF/topo/config directory and follow the naming pattern *-color-config.xml.
<dynam <theme Specifies that a dynamic cell icon image should be used for the model hierarchy
ic- - tree. The idref attribute of this element defines the id of the chosen cellicon.
cellicon config> Predefined icons exist in the <$SPECROOT>/tomcat/webapps/spectrum/WEB-INF
> /console/topo/config directory and follow the naming pattern *-color-config.xml.
<static- <theme Specifies that a static cell icon image should be used for the model hierarchy tree.
cellicon - The idref attribute of this element defines the id of the chosen cellicon. Predefined
> config> icons exist in the <$SPECROOT>/tomcat/webapps/spectrum/WEB-INF/console/topo
/config directory and follow the naming pattern *-color-config.xml.
<theme <theme The name of the theme to which this configuration is applied. OneClick, Classic, or
> - Utility should be specified to configure the existing themes. Specifying a new name
config> generates a new theme.
<on- <theme The icon configuration for the standard icon for the designated theme.
page> -
config>
<off- <theme The icon configuration for the referenced icon for the designated theme.
page> -
config>
The <on-page> and <off-page> elements specify the XML files used to construct the standard version
and off-page reference version of the icon as they would appear within the Topology.
The image used within the Navigation panel hierarchy is defined by one of the following three <*-
cellicon> elements:
<enumerate-cellicon>
<dynamic-cellicon>
<static-cellicon>
03-Apr-2017 226/311
Using the <theme-config> Element to Create Icon Appearance

The following example shows how the theme configuration for the icon registration ID mydevice-icon-
config is defined using the <theme-config> element. Notice that the icons appearance is defined for
each of the OneClick themes: Utility, Classic, and OneClick.
Example: <theme-config> Code
<theme-config>
<icon-reg-id>mydevice-icon-config</icon-reg-id>
<theme>Utility</theme>
<on-page idref="mydeviceutil-iconbase-config"/>
<off-page idref="mydeviceutil-oprbase-config"/>
<enumerated-cellicon idref="component-cellicon-config"/>
</theme-config>
<theme-config>
<theme>Classic</theme>
<on-page idref="mydeviceclassic-iconbase-config"/>
<off-page idref="mydeviceclassic-oprbase-config"/>
</theme-config>
<theme-config>
<theme>OneClick</theme>
<on-page idref="mydeviceoc-iconbase-config"/>
<off-page idref="mydeviceoc-oprbase-config"/>
</theme-config>
Design On-Page and Off-Page Reference Icons

A model can have two different appearances within the OneClick topology:
On-page
Off-page
The on-page representation is the standard appearance of the model and, therefore, the more
important appearance. The off-page representation is used when the model is drawn in a topology as
a reference to a model that exists in a different topological view. That is, when the model is
connected to another model that resides in a different topology.
If the model supports connections (links) within the OneClick topology, you should specify an off-
page reference icon (image) in addition to an on-page version.
You specify the on-page and off-page icons within the theme configuration using the <on-page> and
<off-page> elements. These elements specify the XML that constructs the corresponding model icon.
The following table defines the elements that can be used within the XML files referenced by the <on-
page> and <off-page> elements.
03-Apr-2017 227/311

Element
<icon- Not This is the root element for the icon configuration file.
config> applicab
le
<static- <icon- A single color foreground/background or image. You can use the idref attribute to
cellicon config> refer to another file that defines the image or color. Predefined icons exist in the <$
> SPECROOT>/tomcat/webapps/spectrum/WEB-INF/console/topo/config directory
and follow the naming pattern *-color-config.xml.
<dynam <icon- More than one color or image. You can use the idref attribute to refer to another
ic- config> file that defines the image or color. Predefined icons exist in the <$SPECROOT>/tom
cellicon cat/webapps/spectrum/WEB-INF/console/topo/config directory and follow the
> naming pattern *-color-config.xml.
<enume <icon- Displays an image or color based on the value of an attribute.
rated- config> You can use the idref attribute to refer to another file that defines the image or
cellicon color. Predefined icons exist in the <$SPECROOT>/tomcat/webapps/spectrum/WEB-
> INF/console/topo/config directory and follow the naming pattern *-color-config.
xml.
<shape> <icon- See Define the Icon Shape.
config>
<stroke <icon- The type of line used to create the shape. The following values can be used:
> config> - Bump1: Bump stroke of width 1.
- Bump2: Bump stroke of width 2.
- Dash1x1x1: Dashed Stroke of width of 1, and repeats dash of length 1 followed by
a blank of length 1.
- DashDot: Dashed Stroke of width of 1, and repeats dash of length 3 followed by a
blank of length 1 followed by a dot of length 1 followed by a blank of length 1.
- DashDotDot: Dashed Stroke of width of 1, and repeats dash of length 3 followed
by a blank of length 1 followed by a dot of length 1 followed by a blank of length 1
followed by a dot of length 1 followed by a blank of length 1.
- DashedSeparator: Dashed Stroke used for display a separator lines for the CA
Spectrum look and feel.
- PenStroke Ditch1: Ditch stroke with a width of 1.
- Ditch2: Ditch stroke with a width of 2.
- Ditch4: Ditch stroke with a width of 4.
- Hole1: Hole stroke of width 1.
03-Apr-2017 228/311

Element
- Hole2: Hole stroke of width 2.
- Invisible: Invisible Pen Stroke.
- Ridge2: Ridge stroke with a width of 2.
- Ridge4: Ridge stroke with a width of 4.
- Solid1: Solid Pen Stroke with a width of 1.
- StepBump1: Step Bump with a width of 1.
- StepBump2: Step Bump with a width of 2.
- StepHole2: Step Hole with a width of 2.
<pipe- <icon- See Define Pipe Connection Location.
connect config>
ion>
<compo <icon- This element encloses the image, label, and text components that define the icon.
nents> config> The different components are layered on top of each other, and the index value for
each of these components determines the drawing order. The lowest number (1)
will be drawn first. See Define Image Components, Define Text Components, and
Define Selection Components.
Use <on-page> and <off-page> Elements

If you create an icon configuration file called mydevice-utility-iconbase-config.xml that defines the on-
page reference for your icon in the Utility theme, you must define the <on-page> reference element
in the appropriate theme configuration as in the following example.
Example: <on-page> and <off-page> Code
<theme-config >
<theme>Utility</theme>
<on-page idref="mydevice-utility-iconbase-config"/>
<off-page idref="mydevice-utility-oprbase-config"/>
</theme-config>
Example: Icon Configuration File
This example shows an icon configuration file using the XML elements described in the table in
Design On-Page and Off-Page Reference Icons.

<icon-config id="mydevice-utility-iconbase-config">
<static-color idref="default-iconbase-color-config"/>
<shape-rectangle >
<x>0</x>
<y>0</y>
<width>139</width>
<height>84</height>
</shape-rectangle>
03-Apr-2017 229/311
<stroke>Invisible</stroke>

<pipe-connection>
<x>73</x>
<y>36</y>
</pipe-connection>
<components>

<image-component index="2">
<x>0</x>
<y>0</y>
<width>139</width>
<height>84</height>
<image idref="oneclick-orgservice-iconbase-image-config"/>
</image-component>
</components>
</icon-config>
Define the Icon Shape

The base shape of the icon defines the area for the icon that the user clicks on to activate the model.
The base shapes for a OneClick icon are the following:
Rectangle
Rounded Rectangle
Ellipse
Polygon
Line
Define each of these shapes using the <icon-config> element.
Rectangle
Elements used to specify a rectangle in OneClick are defined in the following table.
Element Parent Element Description

<shape-rectangle> <icon-config> Defines a rectangle.
<x> <shape-rectangle> The upper left X coordinate of the rectangle.
<y> <shape-rectangle> The upper left Y coordinate of the rectangle.
<width> <shape-rectangle> The width of the rectangle.
<height> <shape-rectangle> The height of the rectangle.
Example: Rectangle Code
03-Apr-2017 230/311
Example: Rectangle Code
<shape-rectangle>
<x>26</x>
<y>24</y>
<width>45</width>
<height>14</height>
</shape-rectangle>
Rounded Rectangle
Elements used to specify a rounded rectangle in OneClick are defined in the following table.

<shape-roundrectangle> <icon-config> Defines a rounded rectangle.
<x> <shape-roundrectangle> The upper left X coordinate.
<y> <shape-roundrectangle> The upper left Y coordinate.
<width> <shape-roundrectangle> The width.
<height> <shape-roundrectangle> The height.
<arcwidth> <shape-roundrectangle> The width of the arc that defines the corners.
<archeight> <shape-roundrectangle> The height of the arc that defines the corners.
Example: Rounded Rectangle Code
<shape-roundrectangle>
<x>0</x>
<y>0</y>
<width>89</width>
<height>68</height>
<arcwidth>12</arcwidth>
<archeight>12</archeight>
</shape-roundrectangle>
Ellipse
Elements used to specify an ellipse in OneClick are defined in the following table.

<shape-ellipse> <icon-config> Creates an ellipse.
<x> <shape-ellipse> The upper left X coordinate of the ellipse.
<y> <shape-ellipse> The upper left Y coordinate of the ellipse.
<width> <shape-ellipse> The width of the ellipse.
<height> <shape-ellipse> The height of the ellipse.
Example: Ellipse Code
<shape-ellipse>
03-Apr-2017 231/311
<x>26</x>
<y>24</y>
<width>45</width>
<height>14</height>
</shape-ellipse>
Polygon
Elements used to specify a polygon in OneClick are defined in the following table.

Element
<shape- <icon- Defines a polygon.
polygon config>
>
<point> <shape- A point defining an edge of the polygon. The x attribute of this element defines the
polygon x coordinate position of the point. The y attribute of this element defines the y
> coordinate position of the point.
Example: Polygon Code
<shape-polygon>
<point x="0" y="28" />
<point x="10" y="10" />
<point x="28" y="0" />
<point x="116" y="0" />
<point x="134" y="10" />
<point x="144" y="28" />
<point x="144" y="65" />
<point x="134" y="80" />
<point x="116" y="92" />
<point x="28" y="92" />
<point x="10" y="80" />
<point x="0" y="65" />
</shape-polygon>
Line
Elements used to specify a line in OneClick are defined in the following table.

<shape-line> <icon-config> Defines a line.
<x1> <shape-line> X coordinate for the start of the line.
<y1> <shape-line> Y coordinate for the start of the line.
<x2> <shape-line> X coordinate for the end of the line.
<y2> <shape-line> Y coordinate for the end of the line.
Example: Line Code
03-Apr-2017 232/311
<shape-line>
<x1>5</x1>
<y1>5</y1>
<x2>40</x2>
<y2>40</y2>
</shape-line>
Create an Icon Shape

The icon shape defines the area of the icon the user can click in and select the device. The following
example defines the rounded-rectangle icon shape shown in the image that follows the example.
Example: Icon Shape Code
<icon-config id="device-iconbase-config">
<static-color idref="device-iconbase-color-config"/>
<shape-roundrectangle >
<x>0</x>
<y>0</y>
<width>89</width>
<height>68</height>
<arcwidth>12</arcwidth>
<archeight>12</archeight>
</shape-roundrectangle>
SPEC--create_icon_shape
X and Y Coordinates
The x and y coordinates define the upper left-hand corner of the image. As the value of x increases,
the upper left-hand corner of the image moves from the left to the right. As the value of y increases,
the upper left-hand corner of the image moves from the top to the bottom. The image in the
preceding section shows the upper left corner of the icon shape at 0,0, defined in Example: Icon
Shape Code.
Define Pipe Connection Location

The pipe location defines where pipes get connected to the icon. Elements used to define pipe
connection locations are listed in the following table.
03-Apr-2017 233/311

<pipe-connection> <icon-config> Defines the pipe location on an icon.
<x> <pipe-connection> The x coordinate for the pipe location.
<y> <pipe-connection> The y coordinate for the pipe location.
Example: <pipe-connect> Code
<pipe-connection>
<x>73</x>
<y>36</y>
</pipe-connection>
Define Image Components

Image components enable you to add static or dynamic images to a model based on the model
attributes. Image components are defined in the table after the following example.
Example: <image-component> Code
The following example defines an image component in an icon configuration file:
<x>0</x>
<y>0</y>
<width>139</width>
<height>84</height>
</image-component>
The <image> element references the image definition file shown in Example: Image Definition File.
This generates the image component shown in the following figure, showing the model in the
CRITICAL (3) state.
SPEC--def_img_cmp
The following table describes the elements used for defining image components.
03-Apr-2017 234/311

Element
<compo <icon- Defines all components for the icon.
nents> config>
<image- <compo Defines the image component. The index attribute of this element defines the
compon nents> order that the image is drawn relative to the other image, text, and selection
ent> components defined for this icon. Each index value must be unique, for example
you cannot have two <*-component> elements with an index value of 1 in the
same file. If you do, only the first <*-component> element is used. Index values
must begin at 1.
<x> <image- The x coordinate of the upper left corner of image.
compon
ent>
<y> <image- The y coordinate of the upper left corner of image.
compon
ent>
<width> <image- The width of the image in pixels. There are no size restrictions on the image,
compon however, it is recommended that you use a size relative to the other images used
ent> in OneClick.
<height <image- The height of the image in pixels. There are no size restrictions on the image,
> compon however, it is recommended that you use a size relative to the other images used
ent> in OneClick.
<image <image- The image to be rendered.
> compon The idref attribute references the XML file that builds the image. It is put in a
ent> separate file for organizational purposes only.
Images should be in png file format and should be placed in the <$SPECROOT>/tom
cat/webapps/spectrum/images directory.
<shape- <image- Shape component to be drawn with image.
*> compon
ent>
<enume <image- Colors used for the shape.
rated- compon
color> ent>
<static- <image- Color used for the shape.
color> compon
ent>
<selecti <image- Indicates whether this is to be shown only when the user selects the image
on- compon component.
compon ent>
ent>
Example: Image Definition File
The following XML code defines the image used for <image-component index =2> in Example: Icon
Configuration File. The example uses the <select>, <case>, and <expression> elements to
conditionally select an image based on the value of the condition attribute. The example uses the
<yield> to define which image should be used when a condition is met. Note that the image is in PNG
file format. Images used for customization purposes should be stored in the <$SPECROOT>/tomcat
03-Apr-2017 235/311
file format. Images used for customization purposes should be stored in the <$SPECROOT>/tomcat
/webapps/spectrum/images directory. Express the path to an image placed in this directory from the
images directory, as images/myimage.png.

<image id="oneclick-orgservice-iconbase-image-config">
<select>
<case>
<expression>
attrInt(AttributeID.CONDITION) == 0

</expression>
<yield>
images/oneclick_org_service_green.png
</yield>
</case>
<case>
<expression>
</expression>
<yield>
images/oneclick_org_service_yellow.png
</yield>
</case>
<case>
<expression>
</expression>
<yield>
images/oneclick_org_service_orange.png
</yield>
</case>
<case>
<expression>
</expression>
<yield>
images/oneclick_org_service_red.png
</yield>
</case>
<case>
<expression>
</expression>
<yield>
images/oneclick_org_service_brown.png
</yield>
</case>
<case>
<expression>
</expression>
<yield>
03-Apr-2017 236/311
images/oneclick_org_service_grey.png
</yield>
</case>
<case>
<expression>
</expression>
<yield>
images/oneclick_org_service_blue.png
</yield>
</case>
<default>
images/oneclick_org_service_blue.png
</default>
</select>
</image>
Example: Icon Configuration File
This icon configuration example generates the image that follows it. The example assumes that the
condition of the model is CRITICAL (3).

<icon-config id="oneclick-orgservice-iconbase-config">
<static-color idref="oneclick-default-iconbase-color-config"/>
<shape-rectangle >
<x>0</x>
<y>0</y>
<width>139</width>
<height>84</height>
</shape-rectangle>

<pipe-connection>
<x>73</x>
<y>36</y>
</pipe-connection>
<components>

<label-component idref="default-iconlabel-config" index="1">
<x>0</x>
<y>77</y>
<column-list>
<field-column>
<column idref="column-modelname-config"/>
<column idref="column-devicetype-config"/>
</field-column>
</column-list>
</label-component>
03-Apr-2017 237/311

<x>0</x>
<y>0</y>
<width>139</width>
<height>84</height>
</image-component>
</components>
</icon-config>
SPEC--def_img_cmp2
Create an Icon Label

OneClick model or device type icons have labels to identify them to OneClick operators. Use the
<label-component> elements listed in the table in the default-iconlabel-config.xml file to add labels
to the icons you create. The following figure shows how some of the elements can be used in defining
an icon label.
SPEC--create_icon_labl
03-Apr-2017 238/311
The default-iconlabel-config.xml File

The file <$SPECROOT>/SPECTRUM/tomcat/webapp/spectrum/WEB-INF/topo/config/default-
iconlabel-config.xml contains examples and more information on using the <label-component>
element and its attributes to create icon labels.
Example: <label-component> Code

<label-component idref="default-iconlabel-config" index="1">
<x>0</x>
<y>67</y>
<column-list>
<field-column>
<column idref="column-devicetype-config"/>
</field-column>
</column-list>
</label-component>
This example defines the model label by extending the functionality of the default-iconlabel-config.
xml file. This example creates a label that displays two fields of text defined in the two column
statements. The column statements create two rows in the label for the content defined by the
column configuration files they reference. This label displays the model name and device type in the
icon label. The code does not specify a minimum or maximum column width for the label (see the
following table), so it has a fixed width of 95 pixels, the default condition.

Element
<compo <icon- Defines all components for the icon.
nents> config>
<label- <compo Defines a label component.
compon nent> The index attribute defines the order that the label is drawn in with respect to
ent> other image, text, and label components defined for the same icon. Each index
value must be unique. If you have two
<*-components> with the same index value - only the second one is drawn.
Index values begin at 1.
<x> <label- Defines the x coordinate of the upper left corner of the label relative to the icon
compon image component.
ent>
<y> <label- Defines the y coordinate of the upper left corner of the label relative to the icon
compon image component.
ent>
<column <label- Constructs a list of columns used to create the labels. Only one column is
-list> compon supported.
ent>
<field- <colum Constructs a column of information
column> n-list>
03-Apr-2017 239/311

Element
<column <field- Defines the data for the <field-column>. The idref attribute allows you to associate
> column another XML file with the <column> that defines the data for the column. The data
> for the <column> does not have to reside in another file.
<max- <label- Defines the maximum width of the label background. The label background
backgro compon expands and contracts in width based on the longest column value.
und- ent>
width>
<min- <label- Defines the minimum width of the label background.
backgro compon
und- ent>
width>
<default- <label- Defines transparency value for label background when the icon is not selected. 0 -
transpar compon 255; 0=completely transparent, 255=completely opaque.
ency> ent>
<selecte <label- Defines transparency value for label background when the icon is selected. 0 - 255;
d- compon 0=completely transparent, 255=completely opaque.
transpar ent>
ency>
<show- <label- Indicate whether or not to show the labels background.
backgro compon
und> ent>
<enumer <label- Defines the label background color.
ated- compon <enumerated-color> uses expressions and enumerations to determine the color.
color> ent>
<static- <label- Defines the label background color.
color> compon <static-color> uses a specific color.
ent>
<vertical <label- Specifies the spacing between rows of text in pixels.
- compon
spacing> ent>
<border- <label- Defines the border height above the first column and below the last column in
spacing> compon pixels.
ent>
<backgr <label- True or False. If true, a one-pixel wide line is used to outline the label border.
ound- compon
border> ent>
<enumer <backgr Defines the color of <background-border>. For details, see <enumerated-color> in
ated- ound- this table.
color> border>
<static- <backgr Defines the color of <background-border>.
color> ound-
border>
<label- Defines the line that displays at the bottom of the label when the icon is selected.
compon
ent>
03-Apr-2017 240/311

Element
<backgr
ound-
highlight
>
<enumer <backgr Defines label background color when the icon is selected. For details, see
ated- ound- <enumerated-color> in this table.
color> highligh
t>
<static- <backgr Defines the color of <background-highlight>, the label background that displays
color> ound- when the icon is selected.
highligh
t>
<field- <label- Defines the values displayed in the icon label.
value> compon
ent>
<enumer <field- Defines the color of text of the icon label.
ated- value>
color>
<static- <field- Defines the color of text of the icon label.
color> value>
<font> <field- Defines the font used for the icon label text.
value>
Adjust Icon Label Background Width

The icon label background widens and narrows according to the length of the longest text entry in
the label, up to the maximum width specified in <max-background-width>, and down to the
minimum width specified in <min-background-width>. If the label background is not wide enough to
accommodate the length of the label text, increase the <max-background-width> value.
Default Label Width Settings

When you create an icon label using label-component, the default label size is fixed at 95 pixels. Both
<max-background-width> and <min-background-width> have a default value of 95. This creates a
label background with a fixed width of 95. If you do not specify either of these elements, they assume
the default value.
Create Fixed Width Icon Labels

To create an icon label that has a fixed width, set <max-background-width> and <min-background-
width> to the same value that provides enough line space for the icon label text. The following image
shows an icon label with a fixed width of 200.
03-Apr-2017 241/311
SPEC--create_FW_ico_lbl
Define Text Components

Refer to versions of this manual for release 8.0 or earlier on the CA Spectrum support and
documentation web site:
Define Selection Components

In order to make the icon standout when selected, you may want to specify images that will appear
only during selection. You do this via the <selection-component> element. In the example below
there are two components added that are defined as Selection Components (image component #2
and #4). If the user selected the component, these image components would become visible.
Otherwise, they remain invisible. The following figure shows the two selection components:
SPEC--def_sel_cmp
03-Apr-2017 242/311

<icon-config id="oneclick-orgservice-iconbase-config">
<static-color idref="oneclick-default-iconbase-color-config"/>
<shape-rectangle >
<x>0</x>
<y>0</y>
<width>139</width>
<height>84</height>
</shape-rectangle>

<pipe-connection>
<x>73</x>
<y>36</y>
</pipe-connection>
<components>

<x>0</x>
<y>75</y>
<width>94</width>
<height>40</height>
<image>
<select>
<default>
com/aprisma/spectrum/app/topo/images/
icon_text_background.png
</default>
</select>
</image>
</image-component>
<x>0</x>
<y>75</y>
<width>94</width>
<height>40</height>
<selection-component>true</selection-component>
<image>
<select>
<default>
com/aprisma/spectrum/app/topo/images
icon_selected_text_background.png
</default>
</select>
</image>
</image-component>

<x>0</x>
<y>0</y>
<width>139</width>
<height>84</height>
</image-component>

<x>8</x>
<y>0</y>
<width>131</width>
<height>72</height>
<selection-component>true</selection-component>
<image>
<select>
<default>
com/aprisma/spectrum/app/topo/images/
oneclick_selected_container.png
</default>
</select>
</image>
</image-component>

<text-component idref="oneclick-default-textfield-config"index="5">
<x>5</x>
<y>97</y>
<width>85</width>
<height>13</height>
<horizontal_alignment>left</horizontal_alignment>
<text>
<attribute>0x1006e</attribute>
</text>
</text-component>

<text-component idref="oneclick-default-textfield-config" index="6">
<x>5</x>
<width>85</width>
<height>12</height>
<horizontal_alignment>left</horizontal_alignment>
<text>
<attribute>AttributeID.DEVICE_TYPE</attribute>
<expression>
( value() == null || ((String)value()).length() ==
0 ) ? attr(AttributeID.MTYPE_NAME ) : value()
</expression>
03-Apr-2017 244/311
</text>
</text-component>

<x>0</x>
<y>54</y>
<width>19</width>
<height>19</height>
<image idref="oneclick-rollup-triangle-image-config"/>
</image-component>
</components>
</icon-config>
Define Model Icon Tooltips

You can configure the content of a tooltip that displays when a OneClick user moves the cursor over
the model icon. In the contents registry of the custom-app-config.xml file, the <tooltip-config>
element specifies the file that defines the tooltip. The custom tooltip file, mydevice-tooltip-config.xml
must be placed into the $SPECROOT/custom/topo/config folder.
A tooltip configuration for models of model class 2, 5, 11, and 12 is registered to use the tooltip that
is defined within the mydevice-tooltip-config.xml file. Verify the following example:
<contents-registry>
<reg-id>device-icon-config</reg-id>
<tooltip-config>mydevice-tooltip-config</tooltip-config>
The following example shows the contents of a tooltip file. Each element is explained in the table
with examples.

<tooltip-config id="mydevice-tooltip-config"
xsi:schemaLocation="http://www.aprisma.com../../common/schema/column-config.xsd">
<format><![CDATA[
<html><table>
<tr>
<td><b>{0}</b></td>
<td>{1}</td>
</tr>
<tr>
<td><b>{2}</b></td>
<td>{3}</td>
</tr>
03-Apr-2017 245/311
<tr>
<td><b>{4}</b></td>
<td>{5}</td>
</tr>
</table></html>
</format>
<param>
<localize>com.aprisma.spectrum.app.util.render.ModelNameColumn</localize>
</param>
<param>
<renderer>com.aprisma.spectrum.app.util.render.NullRenderer
</renderer>
</param>
<param>
<localize>
com.aprisma.spectrum.app.util.render.NetworkAddressColumn
</localize>
</param>
<param>
</renderer>
</param>
<param>
<localize>
com.aprisma.spectrum.app.util.render.MACAddressColumn
</localize>
</param>
<param>
<attribute>AttributeID.MAC_ADDRESS</attribute>
</renderer>
</param>
</device-tooltip-config>
Note: The numbers that are used in the curly brackets reference the parameters that are
defined by the following <param> elements. {0} references the first parameter, {1}
references the second parameter and so on.

Element
<tooltip Not The root element for the file that defines the tooltip. The id attribute for this
- applicab element must be set equal to the value used for the <tooltip-config> element in the
config> le <content-registry> found in the custom-app-config.xml file.
DO <tooltip Use this to define how the data will be displayed in the tooltip. In the above
NOT - example, an HTML table is used. The number in the curly brackets, e.g. {3},
USE config> references the corresponding parameter, for example, the third parameter defined
in the file.
03-Apr-2017 246/311
<param <tooltip Use this to define the value to be displayed.

> -
config>
<localiz <param Converts the string specified in the parameter to a localized value. Use this if you
e> > are using a parameter value obtained from a OneClick XML file that shipped with
CA Spectrum and begins with com.aprisma.spectrum.
<render <param See Customize the Port Name Column of the Interface Table.
er> >
<attribu <param Use this to identify the attribute you want to be displayed.
te> >
<messa <param Use this for specifying a plain text value for a parameter.
ge> >
Customizing a Model's Information View

Contents
Extend or Modify an Information View (see page 249)
Create an Information Configuration File (see page 250)
Define the Header (see page 251)
Define the Subview (see page 252)
Add a Field Subview (see page 253)
Add Field Subviews Using IDREF (see page 255)
Add a Table Subview (see page 255)
Add an Application Subview (see page 257)
Add a Related Model Subview (see page 258)
Add a Related Models Table Subview (see page 259)
Define a Subview Group (see page 261)
Associate an Information Configuration File with a Model Class or Model Type (see page 262)
Each model displayed in OneClick has an Information view as shown in the following figure. You
access this view using the Information tab in the Component Detail panel.
03-Apr-2017 247/311
SPEC--custom_model_inf_view
Information views are constructed from separate XML files called Information Configuration files. The
primary file is the <$SPECROOT>/tomcat/webapps/
spectrum/WEB-INF/topo/config/topo-app-config.xml file. In this file, for each model type, the
<contents-registry> element specifies the <information-config> elements that link an Information
Configuration file to the model type.
The <contents-registry> in the following example is found in topo-app-config.xml. It links the 0x2100c
(Rtr_Cisco) model type with view-devicedetails-config.xml, which specifies the format for the
Information view.
<contents-registry>
<reg-id>router-icon-config</reg-id>
<tooltip-config>device-tooltip-config</tooltip-config>
<information-config>view-devicedetails-config</information-config>
<performance-config>performance-data-rtrcisco-config</performance-config>

<model-type>0x21000c</model-type>

</contents-registry
Note: Several model classes and model types may be specified within the contents or
component details registries. Information views can be reused in one or more <contents-
registry> elements.
03-Apr-2017 248/311
This section describes how to add and edit information displayed in the Information view for a
particular model type or model class.
Extend or Modify an Information View

You can modify or create an Information view to display information available in a device MIB that CA
Spectrum and OneClick do not support by default. You can decide whether to add this parameter to
one of the existing subviews in the Information view for that device type, or to create a new subview.
When you create or modify an Information view, you must create a new Information Configuration
file in the <$SPECROOT>/custom/console/config/ directory. This file must have the same name as the
factory default Information Configuration file that you need to modify. You then associate the
Information Configuration file with the appropriate model type using the <$SPECROOT>/custom
/console/config/custom-app.config.xml file.
Note: You must create the file <$SPECROOT>/custom/console/config/custom-app-config.

xml and add your customization code to it. See OneClick Customization (http://wiki-dev.ca.
com/display/CSP/OneClick+Customization).
.
Follow these steps:
1. If you are modifying or extending an existing Information view for an existing model type or
model class, identify the current Information view configuration file that is used to create the
Information view.
a. Open the <$SPECROOT>/tomcat/webapps/spectrum/WEB-INF/topo/config/topo-app-

config.xml file and find the <contents-registry> element for the appropriate model
type or model class. (For an example, see the XML code example at the start of this
chapter.)
Note: OneClick uses the hierarchy that model_type definitions override the
same definition found in a model_class.
b. Find the <information-config> element within the <contents-registry> element, and

note the name of the Information Configuration file that is described by this element.
All of the existing Information Configuration files are located in the <$SPECROOT>
/tomcat/webapps/spectrum/WEB-INF/topo/config directory.
2. To extend an existing information configuration, take the following steps:
a.
03-Apr-2017 249/311
2.
a. Create a new file in the <$SPECROOT>/custom/topo/config directory with the same

name as the Information Configuration file determined in the next step. Use idref to
extend the existing factory file with the contents of this new file.
b. Open the file using a text editor and use the XML syntax outlined in Create an
Information Configuration File (see page 250) to build the file.
c. Continue to step 4.
3. To modify an existing information configuration:
a. Copy the Information configuration file identified in step 1 from <$SPECROOT>/tomcat

/webapps/spectrum/WEB-INF/topo/config directory into the <$SPECROOT>/custom
/topo/config directory.
b. Open the file using a text editor and use the XML syntax outlined in Create an
Information Configuration File (see page 250) to modify the file.
c. Continue to step 4.
4. Save and close the file.
5. Associate the new Information Configuration file with the appropriate model types or model
classes. Follow the instructions in Associate an Information Configuration File with a Model
Class or Model Type (see page 262).
Create an Information Configuration File

The XML that defines the Information Configuration is split up into two major sections: the header
definition and the subview definition. Each define that portion of the models information tab as
shown in the following figure.
03-Apr-2017 250/311
SPEC--create_info_config_file
The XML elements used to build the header and subview in the Information view are listed in the
following table.

Element
[set the Not This is the root element for the Information Configuration file. The ID
view applicable attribute for this element defines the value that should be used for the
variable for <information-config> element in the custom-app-config.xml file.
your book]
<view- [set the Defines the header portion of the view.
header> view
variable for
your book]
<subviews> [set the Defines the available subviews.
view
variable for
your book]
Define the Header

The Information tab header is identified by the <view-header> element. The header specifies the
models graphical depiction and textual information as shown in the image in Create an Information
Configuration File.
Example: Code for Information Tab Header
03-Apr-2017 251/311
<view-header>
<show-icon>true</show-icon>
<show-labels>false</show-labels>
<field-column>
<column idref="column-modeltype-config"/>
</field-column>
</view-header>

Element
<view- [set the Defines the header portion of the view.
header> view
variable
for your
book]
<show- <view- Indicates whether or not to show the icon. Values: true or false.
icon> header>
<show- <view- Indicates whether or not to show field labels
labels> header> Values: true or false
<field- <view- Constructs a column of information.
column header>
>
<colum <field- Defines the data for the field column. The idref attribute enables you to
n> column> associate another XML file, which will define the data for the column. The data
for the column does not have to be in another file, it is done for organizational
purposes only.
Define the Subview

The subview section defines one or more subviews that display in the Information tab as shown in
the image in Create an Information Configuration File. You can define one or more subviews using
the <subviews> element and the child elements shown in the following table. As shown in the
Example: Subview Definition, all subview definitions are enclosed within one <subviews> element.

<subviews> [set the view variable for Encloses all of the elements which define each
your book] type of subview.
<field-subview> <subviews> Defines a field subview.
<table-subview> <subviews> Defines a table subview.
<application-subview> <subviews> Defines an application subview.
<related-model- <subviews> Defines a related model subview.
subview>
<related-model-table- <subviews> Defines a related model table subview.
subview>
<subview-group> <subviews> Groups subviews together under one subview.
Example: Subview Definition
03-Apr-2017 252/311
Example: Subview Definition
<subviews>
<field-subview>
.
.
.
</field-subview>
<application-subview>
.
.
.
</application-subview>
<table-subview>
.
.
.
</table-subview>
</subviews>
Add a Field Subview

Field subviews are used to display a list of non-list attributes available on the selected device model.
The following is an example of XML syntax used to create a field subview.
Example: Field Subview
<field-subview>
<title>General Information</title>
<privilege>
<name>GeneralInfo</name>
</privilege>
<field-column>
<column idref="column-condition-config"/>
<column idref="column-contactstatus-config"/>
<column idref="column-networkaddress-config"/>
<column idref="column-ismanaged-config">
<editable/>
</column>
<column idref="column-securitystring-config">
<editable verifier=
"com.aprisma.spectrum.app.swing.widget.SecStringInputVerifier"/>
</column>
</field-column>
<field-column>
<column idref="column-modelcreationdate-config"/>
<column idref="column-modeltypename-config"/>
<column idref="column-modelclass-config"/>
<column idref="column-lastsuccessfulpoll-config"/>
<column idref="column-landscape-config"/>
<column idref="column-modelnotes-config">
<editable/>
</column>
03-Apr-2017 253/311
</field-column>
</field-subview>
This code generates a subview similar to the one shown in the following figure.
SPEC--field_subview
You can use the elements shown in the following table to create a field subview.

Element
<field- <subvie Defines a field subview.
subview ws> If you set the expanded attribute of this element to true, the subview will be
> expanded by default.
The idref attribute enables you to associate an XML file that defines the data for
this subview. The data for the subview does not have to be in another file, it is
done for organizational purposes only.
<title> <field- The title of the subview. In our example above, the title is General Information.
subview
>
<display <field- Enables the author to specify whether the subview should be displayed via an
-if> subview expression.
>
<display <field- Enables the author to specify that the defined view only be added if the specified
-if-app- subview application is installed.
installed >
>
<privileg <field- Associates a privilege to the subview. If the user is not given this privilege, the
e> subview subview will not be displayed for that user.
>
<show- <field- Indicates whether or not to show field labels. Values: true or false.
labels> subview
>
<field- <field- Constructs a column of information.
column subview
> >
<colum <field- Defines the data for the field column. The idref attribute enables you to associate
n> column another XML file, which will define the data for the column. The data for the
> column does not have to be in another file, it is done for organizational purposes
only.
<editabl <colum Specifies if the column is editable.
e> n>
03-Apr-2017 254/311
Add Field Subviews Using IDREF

The example in this section shows how to extend the factory default
view-devicedetails-config.xml file with a customized field subview using the IDREF attribute. The code
shown is in the file
<$SPECROOT>/custom/topo/config/view-devicedetails-config.xml, the same name as the file it
extends, but in the /custom directory.
Example: Field Subview using IDREF
<view idref="view-devicedetails-config">
<subviews>
<field-subview >
<title>My Subview</title>
<field-column>
<column idref="column-networkaddress-config">
<editable/>
</column>
</field-column>
</field-subview>
</subviews>
</view>
This example creates a field subview titled My Subview that displays information defined by the file
column-networkaddress-config.xml.
The line <view idref="view-devicedetails-config"> adds the field subview My Subview to the factory
default view-devicedetails-config.xml file.
Add a Table Subview

A table subview enables you to display a group of list attributes available from the selected model.
These list attributes are displayed in table format. The following is an example of XML syntax used to
create a table subview.
Example: Table Subview
<table-subview>
<title>Interface Configuration Table</title>
<privilege>
<name>InterfaceConfigurationTable</name>
</privilege>
<column-list>
<column>
<name>Interface</name>
<content><attribute>0x100c4</attribute>
</content>
03-Apr-2017 255/311
</column>
<column>
<name>Type</name>
<content>
<renderer>
<param name="attrID">0x100c6</param>
com.aprisma.spectrum.app.util.render.EnumeratedAttrRenderer
</renderer>
</content>
</column>
<column>
<name>IF Speed</name>
<content>
<attribute>0x100c8</attribute> 
<renderer>com.aprisma.spectrum.app.topo.client.
interfaces.render.IfSpeedRenderer
</renderer>
</content>
</column>
<column>
<name>Physical Address</name>
<content>
</content>
</column>
</column-list>
</table-subview>
The code in this example generates a subview similar to the one shown in the following image.
SPEC--interface_config_table
You can use the elements shown in the following table to create a table subview.

Element
<subvie
ws>
03-Apr-2017 256/311

Element
<table- Adds a table subview.
subview If you set the expanded attribute of this element to true, the subview will be
> expanded by default.
<title> <table- The title for the table.
subview
>
<privile <table- Associates a privilege to the subview. If the user is not given this privilege, the
ge> subview subview will not be displayed for that user.
>
Note: All of the elements that can be used to modify a table can be used to create the
table for the table subview.
Add an Application Subview

An application subview enables you to display attributes affiliated with an application model type
related to the selected model type by a specified criteria. The example below uses CA Spectrums
PossPrimApp (0x230000) relation.
Example: Application Subview
<application-subview>
<title>SNMP2 IP Routing Table</title>
<model-type>0x230010</model-type>
<subviews>
<table-subview idref="table-ip2-ip-routingtable-config"/>
</subviews>
</application-subview>
The attribute used within the <model-type> element defines the model type to which the subview
pertains. In the example above, the value 0x230010 is used. This attribute value corresponds to the
SNMP2_Agent Application model type. This means that this particular table definition applies only to
the SNMP2_Agent application. If the current device does not implement this application, this table
will not be visible.

Element
<applica <subvie
tion- ws>
subview
>
03-Apr-2017 257/311

Element
Creates an application subview.
If you set the expanded attribute of this element to true, the subview will be
expanded by default.
<title> <applica The title of the subview.
tion-
subview
>
<model- <applica The model type to which the subviews will pertain.
type> tion-
subview
>
<subvie <applica Enables you to add a prebuilt table-subview or field- subview to the detail
ws> tion- components that reside within the application subview. Values: table-subview and
subview /or field-subview.
>
<criteria <applica The search criteria used to find the related models.
> tion-
subview
>
<privileg <applica Associates a privilege to the subview. If the user is not given this privilege, the
e> tion- subview will not be displayed for that user.
subview
>
Add a Related Model Subview

A related model subview enables the user to display the attributes of models related to the current,
selected model via a search criteria, for example, models that are related by a specific association.
The user can then display attributes of the found models in field or table format. Add a Related
Models Table Subview shows how you can display the attributes in table format.
You can use the elements in the following table to create related model subview.

Element
<related- <subview If you set the expanded attribute of this element to true, the subview will be
model- s> expanded by default.
subview> The idref attribute enables you to associate an XML file that defines the data for
<title> <related- The title of the subview.
model-
subview>
The model type to which the subviews will pertain.
03-Apr-2017 258/311

Element
<model- <related-
type> model-
subview>
<subview <related- Enables you to add a prebuilt table-subview or field- subview to the detail
s> model- components that reside within the subview. Values: table-subview and/or field-
subview> subview.
<criteria> <related- The search criteria used to find the related models.
model-
subview>
<privilege <related- Associates a privilege to the subview. If the user is not given this privilege, the
> model- subview will not be displayed for that user.
subview>
Add a Related Models Table Subview

You can use the <related-models-table-subview> to display a table of models that are associated with
the current selected model based on a specified search criteria.
You can use the elements in the following table to create a related model table subview.

Element
<related- <subviews> If you set the expanded attribute of this element to true, the subview will be
model- expanded by default.
table- The idref attribute enables you to associate an XML file that defines the data
subview> for this subview. The data for the subview does not have to be in another
file, it is done for organizational purposes only.
<title> <related- The title of the subview.
model-
table-
subview>
<privilege> <related- Associates a privilege to the subview. If the user is not given this privilege,
model- the subview will not be displayed for that user.
table-
subview>
<table> <related- This elements and its sub-elements define the table. See the table in Modify
model- a Table Column for a list of sub-elements.
table-
subview>
<criteria> <related- The search criteria used to find the related models.
model-
table-
subview>
In the example that follows, the <subviews> element is used to place a view within a view allowing
multiple views to be nested within each other. Each column in the table represents the value of an
attribute for each of the models that have passed the search criteria.
03-Apr-2017 259/311
attribute for each of the models that have passed the search criteria.
Example: Related-Model-Table Subview (demo-details-config.xml)
<subviews>
<related-models-table-subview>
<title>Demo Table Title</title>
<criteria>demo-search-criteria</criteria>
<table>demo-table-config</table>
</related-models-table-subview>
</subviews>
Example: Referenced Criteria XML (demo-search-criteria.xml)
<search-criteria id="demo-search-criteria"
../../common/schema/search-criteria-config.xsd">
<child-models>
<relation>Collects</relation>
</child-models>
</search-criteria>
Example: Referenced Table XML (demo-table-config.xml)
<?xml version="1.0" encoding="utf-8"?>

<table id="demo-table-config"
<column-list>
<column>
<name>Model Name</name>
<content>
</content>
</column>
<column>
<name>Condition</name>
<content>
<attribute>AttributeID.CONDITION</attribute>
</content>
</column>
</column-list>
</table>
03-Apr-2017 260/311
Define a Subview Group

You can group together one or more subviews under a single collapsible group using the <subview-
group> element.
<subview-group>
<title>Subview Group Title</title>
<display-if>
<expression>
attrInt(AttributeID.MTYPE_HANDLE) == 0x3cc0002
</expression>
</display-if>
<subviews>
<table-subview idref="example-table1-config">
<title>Example Sub View #1</title>
</table-subview>
<table-subview idref="example-table2-config">
<title>Example Sub View #2</title>
</table-subview>
</subviews>
</subview-group>
This example generates a subview group similar to the one shown in the following figure.
SPEC--define_subview
Use the elements shown in the following table to create a subview group.

Element
<subvie <subvie
w- ws>
group>
03-Apr-2017 261/311

Element
If you set the expanded attribute of this element to true, the subview will be
expanded by default.
<title> <subvie The title of the subview group. In the example above, this is Subview Group Title.
w-
group>
<privile <subvie Associates a privilege to the subview group. If the user is not given this privilege,
ge> w- the subview group will not be displayed for that user.
group>
<display <subvie Adds an expression that will determine whether or not the group will be visible.
-if> w-
group>
<subvie <subvie Adds any type of subview (besides group) to this subview group.
ws> w-
group>
Associate an Information Configuration File with a Model

Class or Model Type
Once you have created the Information view with an Information Configuration file, you must follow
the instructions below to associate the Information Configuration file with the model type or model
class.
To associate an Information Configuration File with a Model
1. If it does not already exist there, copy the <$SPECROOT>/tomcat/webapps/spectrum/WEB-INF

/console/config/custom-app-config.xml to the <$SPECROOT>/custom/console/config
directory.
2. Open this file with a text editor.
3. Add the following block of XML code to link the appropriate model type(s) or model class(es)
to the Information Configuration file. Use the XML elements shown to define the information
appropriate to your model type or model class.
<contents-registry>
<icon-reg-id>your-icon-registration</icon-reg-id>
<tooltip-config>your-tooltip-config</tooltip-config>
<information-config>your-information-config-file<
/information- config>
<model-class>your-model-class</model-class>
4. Save and close the custom-app-config.xml file.
03-Apr-2017 262/311
Creating a Model's Performance View

Contents
Create a New Performance View (see page 264)
Create a Performance Data Configuration File (see page 265)
Create a Performance View Configuration File (see page 267)
Customize an Existing Performance View (see page 269)
By default, some model types are configured to have a Performance view that shows changes in
attributes, such as CPU utilization or memory, over time. In OneClick, you access this device view by
clicking the Performance tab in the Component Detail panel.
SPEC--perf_view
A Performance view is composed of two XML files:
A performance data configuration file

This XML file specifies the data that can be displayed in any of the graphs within the Performance
tab. Typically, this data includes attributes of the associated model type.
03-Apr-2017 263/311
A performance view configuration file

This XML file defines the appearance of each graph available within the Performance tab. Each
graph can display any of the lines defined within the performance data configuration file.
If the data or the format of one of the default Performance views does not meet your requirements,
you can customize it for a particular model type or model class. For example, if you have added
support in CA Spectrum for additional MIBs that are supported by a device, you might want to
customize the view to graph some of the data that is available in the MIB. You can also create your
own custom Performance views.
If a Performance view is not configured for the model currently selected in OneClick, the
Performance tab is disabled.
Create a New Performance View

When you create a Performance view for a model type or model class from scratch, you should place
the configuration files that define the view in the <$SPECROOT>/custom/topo/config directory. This
helps to ensure they are not overwritten during an upgrade of CA Spectrum.
You associate the views performance data configuration file with each applicable model type or
model class in a file named custom-app-config.xml. While you can use either the <contents-registry>
element or the <component-details-registry> element to do this, a best practice is to use the
<component-details-registry> element because it configures only the Component Detail panel for the
given model type or model class. For a description of the different registries available, see Chapter 5:
Add Support for Model Types or Model Classes.
To create a new Performance view
1. In the <$SPECROOT>/custom/topo/config directory, create the performance data

configuration file that specifies the data to be graphed in the view.
2. In the <$SPECROOT>/custom/topo/config directory, create a performance view configuration

file that defines the appearance of each graph in the view.
3. In custom-app-config.xml, associate the performance data configuration file with the

appropriate model types or model classes:
a. If it does not already exist there, copy <$SPECROOT>/tomcat/webapps/spectrum/WEB-

INF/console/config/
custom-app-config.xml to the <$SPECROOT>/custom/console/config directory.
Note: Ensure to copy the file to the specified location. Do not modify the
default custom-app-config.xml file that is provided with CA Spectrum
because it is overwritten when you upgrade to a newer version.
b.
03-Apr-2017 264/311
b. In custom-app-config.xml, add a block of XML code similar to the following example

using a text editor. This code links the appropriate model types and model classes to
the performance configuration data file.
The following XML code example associates a model type whose ID is 0x3250004 to a
performance data configuration file named <$SPECROOT>/custom/topo/config/
performance-data-ciscovoiceapp-config.xml.
<component-details-registry>
<performance-config>performance-data-ciscovoiceapp-config<
/performance-config>

</component-details-registry>
Note: You can specify several model classes and model types within the
contents or component details registries. You can also reuse Performance
views in one or more <contents-registry> elements.
c. Save and close the custom-app-config.xml file.
Create a Performance Data Configuration File

The performance data configuration file specifies the data that can be displayed in any of the graphs
within the Performance tab. A recommended naming convention for this XML file is performance-
<descriptor>-data-config.xml.
Use the XML elements described in the following table to create a performance data configuration
file.

Element
perform Not Represents the top-level parent element.
ance- applicab You specify multiple graphs for a Performance view using multiple instances of the
config le <graph> element in the performance view configuration file.
display perform Specifies the XML file that defines the view for presenting the graph data.
ance- This name must exactly match the simple file name of the actual performance view
config configuration file.
line perform Defines a line in the graph.
ance-
config
name line Specifies the label (name) for the line defined by the <line> parent element as it
will be seen in the graph. The value for name needs to match its corresponding line
definition in the performance graph view configuration file.
If you are graphing a list attribute, you can also specify an attr-id attribute for the
name element. This specifies an attribute ID whose value is appended to the name
03-Apr-2017 265/311

Element
of each instance in the list. If not specified, the instance number is appended to the
name of each list instance.
In the following example, attribute 0x12ac6 represents the list of labels for the
multiple lines defined by <list-content>.
<line>
<name attr-id="0x12ac6">
Memory Utilization
</name>
<list-content>
<attribute>0x12ac6</attribute>
</list-content>
</line>
content line Specifies scalar data to graph as a single line defined by the <line> parent element,
for example:
<content>
<attribute>0x2100cc</attribute>
</content>
list- line Specifies list data to graph as multiple lines defined by the <line> parent element.
content In the following example, the attribute 0x12ac6 is an integer list attribute that
represents memory utilization. There will be a separate line graphed for each
instance in the list.
<line>
<name attr-id="0x12ac6">
Memory Utilization
</name>
<list-content>
<attribute>0x12ac6</attribute>
</list-content>
</line>
attribut content, Specifies the ID of the attribute to graph as the line defined by the <line> parent
e list- element.
content
expressi content, Used to define an expression to produce a value for the column, for example:
on list- (attrInt( 0xd054c ) + attrInt( 0xd054d ))/8
content
applicat line You can also graph data from related application models. Within the <applications>
ions element, use the <model-type> element to specify the model type handle of the
related application model. If the model in context has an application model related
to it of this type, the data is retrieved from that application model.
<applications>
<model-type>0xc40043</model-type>
</applications>
model- applicat The model type handle of the application model from which the data is retrieved. If
type ions no application models of this type are related to the model in context, the line is
not shown.
The following example specifies the data to display in a 2-line performance graph that shows the
change in both active and total VoIP calls over time for a Cisco device.
03-Apr-2017 266/311
<performance-config id="performance-data-ciscovoiceapp-config">
<display>performance-ciscovoiceapp-config</display>
<line>
<name>Active VoIP Calls</name>
<content>
<attribute>0x325012b</attribute>
</content>
</line>
<line>
<name>Total VoIP Calls</name>
<content>
<attribute>0x3250129</attribute> 
</content>
</line>
</performance-config>
Note: For additional, more complex examples of performance data configuration files, see
the supporting files for the Performance views included with CA Spectrum. You can find
these files by navigating to the <$SPECROOT>/tomcat/webapps/spectrum/WEB-INF
directory and searching for files named perf*.
Create a Performance View Configuration File

The performance view configuration file defines the appearance of each graph available within the
Performance tab. A recommended naming convention for this XML file is performance-<descriptor>-
view-config.xml.
Use the XML elements described in the following table to create a performance view configuration
file.

Element
perform Not Represents the top-level parent element.
ance- applicab
view le
graph perform Within the performance view configuration file, you can configure multiple graphs.
ance- Each graph is denoted by this <graph> element. The id attribute of this element is
view used as the graph title and displayed in the pulldown menu on the view (which is
used for switching between multiple graphs for a single model).
<graph id="CPU Utilization">
<y-axis-label>Utilization</y-axis-label>
<y-axis-units>%</y-axis-units>
<line>
<name>CPU Utilization</name>
</line>
</graph>
graph Specifies the label for the Y axis.
03-Apr-2017 267/311

Element
y-axis-
label
y-axis- graph Specifies the units for the Y axis, for example, % or Bits per Second.
units
line graph Defines a line in the graph, for example:
<line color="#ffff00">
Use the color attribute to specify the hexadecimal RGB value of the color to use.
name line Specifies the label (name) for the line defined by the <line> parent element.
This value must match the value for the same line in the performance data
configuration file that defines the views data.
If you are graphing a list attribute, you may also specify an attr-id attribute for the
name element. This represents the attribute id of which the value is appended to
the name of each instance in the list. If not specified, the instance number is
appended to name of each list instance.
display- line Specifies the line should be displayed in the graph only if the expression defined in
if the <expression> child element evaluates to TRUE.
expressi display- Used to define an expression to define a complex condition for whether or not to
on if graph the line.
For more information, see Chapter 9: XML Usage Common to All Customization
Files.
fill line If this element is included, the area below the line is filled in with color.
The following example specifies the format for a 2-line performance graph that shows the change in
both active and total VoIP calls over time for a Cisco device.
Note: This is the format for the example graph whose data is defined in Create a
Performance Data Configuration File.
<performance-view id="performance-ciscovoiceapp-config">
<graph id="VoIP Calls Title">
<y-axis-label>Calls</y-axis-label>
<y-axis-units>unit</y-axis-units>
<line>
<name>Active VoIP Calls</name>
</line>
<line>
<name>Total VoIP Calls</name>
</line>
</graph>
</performance-view>
03-Apr-2017 268/311
Note: For additional, more complex examples of performance view configuration files, see
the supporting files for the Performance views included with CA Spectrum. You can find
these files by navigating to the <$SPECROOT>/tomcat/webapps/spectrum/WEB-INF
directory and searching for files named perf*.
Customize an Existing Performance View

In general, you customize an existing Performance view by overriding the default configuration files
for the view with versions that contain your customizations.
To customize an existing Performance view
1. Identify the default configuration files that define the Performance view you want to
customize:
a. Open <$SPECROOT>/tomcat/webapps/spectrum/WEB-INF/topo/config/
topo-app-config.xml and find the <contents-registry> or <component-details-registry>
element for the appropriate model type or model class.
Note: If your model qualifies for both a model type and a model class
registration, the model type registration takes precedence and is applied.
Also, even though you can define the Performance view configuration in
both the contents registry and the component details registry, the
component details registry takes precedence. The contents registry is
primarily for model appearance and typically is applied to only the model
class.
b. Find the <performance-config> element within the <contents-registry> or <component-

details-registry> element, and note the name of the specified performance data
configuration file.
Note: All of the default performance configuration files -- both the data
configuration files and the view configuration files -- are located in the
<$SPECROOT>/tomcat/webapps/spectrum/WEB-INF/*/config directories.
c. Open the
<$SPECROOT>/tomcat/webapps/spectrum/WEB-INF/topo/config directory, and then
open the performance data configuration file you identified in the previous step.
d. Find the <display> element within the <performance-config> element, and note the
name of the specified performance view configuration file.
2. Copy over one or both of the performance configuration files that you identified in step 1 to
03-Apr-2017 269/311
2. Copy over one or both of the performance configuration files that you identified in step 1 to
the <$SPECROOT>/custom/topo/config directory. You only need to copy over a file if it
requires customizations.
Note: To override the factory default performance configuration files, the copied
files (that will contain your customizations) must have the same names as the
original, default files.
3. If necessary, modify the copied performance data configuration file per your requirements,
and then save and close the file.
4. If necessary, modify the copied performance view configuration file per your requirements,
and then save and close the file.
5. If necessary, in custom-app-config.xml, change the model types or model classes that are
associated with the performance data configuration file:
a. If it does not already exist there, copy <$SPECROOT>/tomcat/webapps/spectrum/WEB-

INF/console/config/
custom-app-config.xml to the <$SPECROOT>/custom/console/config directory.
Note: Make sure to copy the file to the specified location. Do not modify the
default custom-app-config.xml file that is provided with CA Spectrum
because it is overwritten when you upgrade to a newer version.
b. In custom-app-config.xml, add a block of XML code similar to the following example

using a text editor. This code links the appropriate model types and model classes to
the performance configuration data file.
The following XML code example associates a model type whose ID is 0x3250004 to a
performance data configuration file named <$SPECROOT>/custom/topo/config/
performance-data-ciscovoiceapp-config.xml.
<component-details-registry>
<performance-config>performance-data-ciscovoiceapp-config<
/performance-config>

</component-details-registry>
Note: You can specify several model classes and model types within the
contents or component details registries. You can also reuse Performance
views in one or more <contents-registry> elements.
The <component-details-registry> element within custom-app-config.xml overrides the
03-Apr-2017 270/311
The <component-details-registry> element within custom-app-config.xml overrides the

equivalent registration for the model type or model class within an *-app-config.xml
file. These registrations are used in the factory XML files in <$SPECROOT>/tomcat
/webapps/spectrum/WEB-INF/*/config/
*-app-config.xml.
c. Save and close the custom-app-config.xml file.
Creating Custom Privileges

Contents
Define a Custom Privilege (see page 271)
Restrict Access to Attribute Values in Model Subviews (see page 274)
Group Privileges (see page 274)
Reference a Privilege When Defining a Menu Item, Column, or Subview (see page 275)
This section describes how to restrict access to menu items, attributes, and subviews using privileges.
Define a Custom Privilege

Define each new privilege in the custom-privileges.xml file. This file registers custom privileges that
can be applied to the following components:
Menu items
Columns
Subviews
If an administrator has not assigned the corresponding privilege to a user, that user cannot access the
menu item, column, or subview.
Follow these steps:
1. Copy <$SPECROOT>/tomcat/webapps/spectrum/WEB-INF/console/config/
custom-privileges.xml to the <$SPECROOT>/custom/console/config directory.
2. Open this file with a text editor.
Note: Define all new privileges inside the <privileges> element, which is the root
element for the file.
3. Create the privilege. Use the elements shown in the table that follows this procedure.
03-Apr-2017 271/311
4. Save and close the custom-privileges.xml file.
5. Restart the Tomcat web server, and then restart OneClick so that changes to the custom-
privileges.xml file are available in OneClick.
6. You can now use the privilege to do the following:
Create a custom menu item, column, or subview that is accessible to only users who have
the privilege. For more information, see Reference a Privilege When Defining a Menu
Item, Column, or Subview (see page 275).
Create a search that is accessible only to users who have the privilege.
Note: For more information, see OneClick Administration (https://docops.ca.com

/display/CASP102/OneClick+Administration).
You can use the elements in the following table to create a privilege:

Element
<privileges Not The root element for the custom-privileges.xml file.
> applicab
le
<your_privil <privile Defines the privilege. You create an element for each new privilege. The type
ege_name> ges> attribute for this element defines the default role to which you assign the
or privilege. Possible values for the type attribute are read or write.
<your_g If you are grouping privileges, place all defined privileges for that group within
roup_na the element that defines your group.
me>
<label> <your_p The name of the privilege, which will be shown on the privilege list.
rivilege
_name>
<desc> <your_p The description of the privilege.
rivilege
_name>
<model- <privile For more information, see Restrict Access to Attribute Values in Model Subviews
view-attr> ges> (see page 274).
<model- <privile For more information, see Restrict Access to Attribute Values in Model Subviews
write-attr> ges> (see page 274).
[set the <your_p The new privilege appears in one of the existing groups if you use the [set the
product rivilege product group or family] element. The scope attribute defines group scope.
group or _name> The following list includes existing groups and their scope values:
family] <group scope=alarm> alarm-manager </group>
<group scope=topo>tools</group>
03-Apr-2017 272/311

Element
<group scope=topo>model-tab</group>
<group scope=topo>model-view-group</group>
<group scope=topo>model-write-group</group>
For more information see Group Privileges (see page 274).
Example: Create a Privilege
Note: When you create a privilege, you are creating a new XML element. In the example
above, the <launch-app> element creates the launch-app privilege. The type attribute
defines the default role to which the privilege is assigned. Two values are possible: read
and write. A privilege with the read type is assigned to the OperatorRO role, and a
privilege with the write type is assigned to the OperatorRW role.
The following example defines the launch-app privilege, as shown in the image:
<privileges>
<launch-app type="write">
<label>Launch Apps</label>
<desc>Ability to launch application from the tools menu.</desc>
</launch-app>
</privileges>
SPEC--component_detail
03-Apr-2017 273/311
Restrict Access to Attribute Values in Model Subviews

You can restrict a users access to certain attributes using the <model-view-attr> and <model-write-
attr> elements, where attr is equal to the attribute ID of the attribute you want to restrict. These
elements are used in the custom-privileges.xml file and regulate the attributes that show up in the
OneClick Privilege lists Model Management>View Attributes folder and the Model
Management>Model Write folder.
The <model-view-attr> element enables you to create a privilege that determines whether or not a
user can see an attribute. For example, if you added the following XML to the custom-privileges.xml
file, you will create a privilege called Community Name. This privilege restricts view access to
attribute 10024, community name. This privilege will appear in the Model Management > View
Attributes folder as specified with the [set the product group or family] element. If the user does not
have this privilege in any access group, they will not be able to see the community name attribute.
<model-view-10024 type="read">
<label>Community Name</label>
<group scope="topo">model-view-group</group>
</model-view-10024>
The <model-write-attr> element enables you to create a privilege that determines whether or not a
user can edit an attribute. For example, if you added the following XML to the custom-privileges.xml
file, you will create a privilege called Community Name. This privilege restricts write access to
attribute 10024, community name. This privilege will appear in the Model Management > Model
Write folder as specified with the [set the product group or family] element. If the user does not have
this privilege in any access group, they will not be able to edit the community name attribute.
<model-write-10024 type="write">
<label>Community Name</label>
<group scope="topo">model-write-group</group>
</model-write-10024>
Group Privileges
If you want to group privileges together, you can create groups in the custom-privileges.xml file. To
specify a group, nest the element that defines the privilege (<your_privilege_name>) between the
element that defines the group (<your_group_name>). The groups <label> element defines the
name that represents the group in the privileges tree (see the image later in this section).

<privileges> Not applicable This is the root element for the custom-privileges.xml file.
<your_group_n <privileges> This element defines the group. You create a new element for each
ame> group you define.
<label> <your_group_n The name of the group, which will be shown on the privilege list.
ame>
Note: In order for changes made to the custom-privileges.xml file to be available in

OneClick, you must restart the Tomcat web server and then restart OneClick.
03-Apr-2017 274/311
In the following example, the <my-tools> element creates a group in which privileges can be nested.
The value defined for the groups <label> is My-Tools Folder. This will create a My-Tools Folder
group in the privileges list as shown in the image that follows. The <launch-app> and <launch-web>
privileges will appear in this group.
<privilege>
<my-tools>
<label>My-Tools Folder</label>
<launch-app type="read">
<label>Launch Apps</label>
<desc>Ability to launch Applications.</desc>
</launch-app>
<launch-web type="read">
<label>Launch Web</label>
<desc>Ability to launch Web URLS.</desc>
</launch-web>
</my-tools>
</privilege>
SPEC--grp_prvileges
Reference a Privilege When Defining a Menu Item, Column,

or Subview
When you create a menu item, column, or subview, you can use the <privilege> element to reference
a custom privilege. Custom privileges are defined in the custom-privileges.xml file. For example, if
you have defined the "launch-app" privilege in the custom-privileges.xml file, you can use the
following XML when you define a menu item, column, or subview:
03-Apr-2017 275/311
<privilege>
<name>launch-app</name>
</privilege>
This XML associates the "launch-app" privilege with the menu item, column, or subview. The user
must have an associated role that grants the launch-app privilege in order for the menu item,
column, or subview to be displayed. If granted, the menu item is always enabled.
Note: For more information, see OneClick Administration (https://docops.ca.com/display

/CASP102/OneClick+Administration).
XML Usage Common to All Customization Files

Contents
About Parameters (see page 276)
Acquire Data -- Render a Value (see page 277)
Use a Select Case (see page 277)
Manipulate Attribute Output Using Renderers (see page 278)
About <dynamic-renderer> (see page 283)
About Expressions (see page 284)
Reference XML Files (see page 287)
Reference Images (see page 287)
Verify User Input Using Verifiers (see page 287)
This section explains common XML elements and strategies that can be used across customization
files.
About Parameters
You can use the <param> element in a number of different instances to reference parameter values
within a OneClick XML file. Here are several common cases where you will likely use the <param>
element.
If you need to pass a parameter to a web page, use the <param> element as a child element of
the <url> element. See Launch a Browser for an example.
If you need to pass a parameter to an application, use the <param> element as a child element of
the <launch-application> element. See Launch an Application From OneClick for an example.
If you need to pass a parameter to a command, use the <param> element as a child element of
the <command> element. See Launch a Browser, Launch an Application From OneClick, and
Launch a Web Server Script.
03-Apr-2017 276/311
If you need to format a series of values, use the <param> element in conjunction with standard
HTML formatting elements. See Define Model Icon Tooltips for an example.
If you need to manipulate the value of an attribute, you may need to use the <param> element
when accessing one of the renderers.
See Acquire Data Render a Value for information on what you can specify using the <param> tag.
Acquire Data -- Render a Value

Acquiring data from OneClick about a model type parameter that you then act on is a fundamental
process in customizing the OneClick interface. A set of elements provide the ability to acquire or
render data from OneClick. These elements or tags are used in acquiring data to display in a table
column, a field-subview column, a <param> element for a menu item, and the <render> element in a
<dynamic-renderer>, and are shown in the following table.
Element Description
<attribute> Used to specify a CA Spectrum attribute
<select> Used to specify something based on the value of another attribute, parameter, etc.
Used to select a value based on certain criteria being met. Very generally, <select> this
<if>condition1, <select> that <if> condition2.
<expression Used to define an arithmetic expression.
>
<renderer> Used to define or access any number of renderers that process raw data and refine into
a specific format for presentation to the user.
<dynamic- Specifies a renderer based on the value of an attribute criteria filter.
renderer>
<message> Used for specifying a plain text value for the column.
You can use any number and combination of these elements chained together, with the output from
one element serving as the input to the next element in the chain. The <attribute> tag must be first in
a chain of elements because it yields an attribute value and does not accept input. The <message>
tag must be first in a chain of elements used to render a value. because it does not accept input.
Use a Select Case

If you want to conditionally display something in the OneClick interface, you may use the <select>
and the <case> elements to create a decision structure similar to those used in many programming
languages. Use the <select> and <case> elements as follows:
<select>
<case>
<expression>the expression to evaluate</expression>
<yield>what to yield if the expression is true</yield>
</case>
<case>
<expression>the expression to evaluate</expression>
<yield>what to yield if the expression is true</yield>
</case>
03-Apr-2017 277/311
.
.
.
<default>what to yield if no matches are found</default>
</select>
Example: Image Definition File shows an example of the <select> and <case> elements used to select
the image to be displayed on a OneClick device model icon depending on the models condition.
Manipulate Attribute Output Using Renderers

There are several built-in attribute renderers that you can use to manipulate how the attributes you
have specified in a OneClick table are displayed. You use the <renderer> element to access one of
these renderers. The text of the element must be a fully-qualified Java class name; each allowable
Java class name is explained below.
Note: You will need some background in programming to fully understand the renderer
concepts presented below.
You can pass parameters to a renderer using the <param> element. The text of the <param> element
is the parameter value. A <param> element must have a name attribute that specifies the name of
the parameter.
Example
The following example specifies the BooleanRenderer with parameter trueTag set to No and
parameter falseTag set to Yes. Each renderer has a set of parameters, and each renderer is defined
differently.
<renderer>
<param name="trueTag">Enabled</param>
<param name="falseTag">Disabled</param>
com.aprisma.spectrum.app.util.render.BooleanRenderer
</renderer>
Boolean Renderer
The class name for the boolean renderer is com.aprisma.spectrum.app.util.render.BooleanRenderer.

This renderer outputs an enumerated String for an input Boolean value. By default, "Yes" is rendered
for TRUE and No is rendered for FALSE, but other elements or text may be specified via the
following parameters:
trueTag - the tag or text to render for TRUE
falseTag - the tag or text to render for FALSE
The following example reverses the TRUE/FALSE output:
<renderer>
<param name="trueTag">No</param>
03-Apr-2017 278/311
<param name="falseTag">Yes</param>
com.aprisma.spectrum.app.util.render.BooleanRenderer
</renderer>
If the input value is TRUE, No is rendered and if FALSE, Yes is rendered.
Commented Text Renderer
The class name for the commented text renderer is com.aprisma.spectrum.app.util.render.

CommentedTextRenderer. This renderer strips off the HTML-commented prefix that is added by
some renderers (for example, DateRenderer). It searches for the first occurrence of the ending
character sequence of an HTML comment, such as , and returns the rest of the
string.
Date Renderer
The class name for the date renderer is com.aprisma.spectrum.app.util.render.DateRenderer. This

renderer outputs a date and time using Javas DateFormat. If the input to the renderer is a long
integer (for example, of type java.lang.Long), it is assumed to represent the date and time in
milliseconds. If the input is any other numeric type, it is assumed to be an integer representing the
date and time in seconds. Otherwise, the only other valid input type is java.util.Date. The output
string is prefixed by the numeric date and time value enclosed in HTML comments (). An example output would be:
Jul 14, 2004 8:41:09 AM EDT
You use the numeric value prefix in the comments tag for sorting. Without the prefix, CA Spectrum
would sort on the formatted date and time string, and this would not work correctly. Therefore, you
should only use the DateRenderer in the <content> element section of a column. To strip off the
prefix for display, use the CommentedTextRenderer in the <swing-cell-template> section. For
example:
<content>
<attribute>0x11620</attribute>
<! -- an attribute that contains an integer date/time in seconds >
<renderer>
com.aprisma.spectrum.app.util.render.DateRenderer
</renderer>
</content>
<text>
<renderer>
com.aprisma.spectrum.app.util.render.CommentedTextRenderer
</renderer>
</text>
Enumerated Attribute Renderer
Classname: com.aprisma.spectrum.app.util.render.EnumeratedAttrRenderer.
03-Apr-2017 279/311
This renderer outputs an enumerated String for an attribute value. The renderer obtains the
enumerations from the CA Spectrum database. You must specify the attribute ID via the attrID
parameter. This renderer is most commonly preceded by an <attribute> element with the same
attribute ID as the attrID parameter. The following sample XML renders the enumerated value for
the Model_Class attribute (ID 0x11ee8):
<attribute>0x11ee8</attribute>
<renderer>
<param name="attrID">0x11ee8</param>
com.aprisma.spectrum.app.util.render.EnumeratedAttrRenderer
</renderer>
List Renderer
The classname for the list renderer is com.aprisma.spectrum.app.util.render.ListRenderer. This

renderer outputs the components of a Java Collection or an array of any type as a comma-separated
string.
Null Renderer
Classname: com.aprisma.spectrum.app.util.render.NullRenderer.
This renderer outputs a null input value as an empty string.
Object ID Renderer
This renderer outputs an object identifier (OID). The expected input value is type CsObjectID.
Classname: com.aprisma.spectrum.app.util.render.ObjectIDRenderer.
Supported parameters:
term -- an integer value that specifies the index of a particular term of the OID to render
startTerm -- an integer value that specifies the index of the first term of the OID to render
endTerm -- an integer value that specifies the index of the last term of the OID to render
The term indices start at 1. If you specify the startTerm without the endTerm, then the portion of the
OID from the startTerm to the last term of the OID is rendered. If you specify the endTerm without
the startTerm, then the portion of the OID from the first term to the endTerm is rendered.
The ObjectIDRenderer is most commonly used to render the row instance of a MIB table. You obtain
the row instance via the getRowId() method in an <expression> element. You can then pass the result
to the ObjectIDRenderer. For example, the following column renders the first term of the row
instance:
<column>
<name>com.aprisma.spectrum.app.topo.client.ifIndex</name>
<content>
<expression>getRowId()</expression>
<renderer>
03-Apr-2017 280/311
<param name="term">1</param>
com.aprisma.spectrum.app.util.render.ObjectIDRenderer
</renderer>
</content>
</column>
The following example renders terms 5 through 8:
<column>
<name>com.aprisma.spectrum.app.topo.client.NetworkAddr</name>
<content>
<expression>getRowId()</expression>
<renderer>
<param name="startTerm">5</param>
<param name="endTerm">8</param>
</renderer>
</content>
</column>
The following example combines an expression with the ObjectID renderer to enable you to display
the last term of an OID value in a table:
<column>
<name>com.aprisma.spectrum.app.topo.client.ifIndex</name>
<content>
<expression>
((com.aprisma.spectrum.global.CsObjectID)value()).get_sub_oid(
((com.aprisma.spectrum.global.CsObjectID)value()).get_term_count(),
((com.aprisma.spectrum.global.CsObjectID)value()).get_term_count())
</expression>
<renderer>
<param name="term">1</param>
</renderer>
</content>
</column>
Round Number Renderer
The classname for this renderer is com.aprisma.spectrum.app.util.render.RoundNumberRenderer.

This renderer outputs a number rounded to the nearest 100th (or 2 decimal places).
System Up Time Renderer
This renderer outputs a numeric time value represented in one hundredths of a second. The time
representation is used in MIB objects such as sysUpTime. The output is expressed in days, hours, and
minutes (for example, 30 days 1 hr 55 min).
Classname: com.aprisma.spectrum.app.util.render.SysUpTimeRenderer
Byte Renderer
This renderer outputs an integer value in byte units (byte, KB, MB, GB, or TB).
03-Apr-2017 281/311
This renderer outputs an integer value in byte units (byte, KB, MB, GB, or TB).
Classname: com.aprisma.spectrum.app.util.render.ByteRenderer
Inet Address Renderer
This renders a MIB object of type InetAddress as defined in RFC-3291.
Classname: com.aprisma.spectrum.app.util.render.InetAddressRenderer
addressAttrID - the ID of the InetAddress attribute
type - the InetAddressType as defined in RFC-3291
typeAttrID - the ID of an attribute used to obtain the InetAddressType
List Instance Renderer
Renders the value of a specific instance of a list-type attribute.
Classname: com.aprisma.spectrum.app.util.render.ListInstanceRenderer
oid -- the OID of the instance to render
index -- the index of the instance to render
You must specify either the oid or index parameter.
Simple Integer Renderer
Renders an integer value without using comma grouping; 123456 instead of 123,456. Use this to
substitute an integer value in a URL used in a menu item where commas are not acceptable input.
Classname: com.aprisma.spectrum.app.util.render.SimpleIntegerRenderer
Type Prepended Inet Address Renderer
Renders a MIB object of type InetAddress as defined in RFC-4293 with the type added to the
beginning of the address.
Classname: com.aprisma.spectrum.app.util.render.TypePrependedInetAddressRenderer
Supported parameter:
addressAttrID - the ID of the InetAddress attribute
03-Apr-2017 282/311
About <dynamic-renderer>
Use the <dynamic-renderer> element to specify a renderer that depends on the value of an attribute
criteria such as <model_class>, <model-type>, or other attribute criteria. You select an attribute ID as
the key and specify one or more <dynamic-renderer> elements in the custom-app-config.xml file.
Each <dynamic-renderer> element defines a criteria and the renderer to use if the criteria is satisfied.
The structure to use with <dynamic-renderer> is as follows:
<dynamic-renderer>
<attribute><KEY_ATTRIBUTE_ID></attribute>
CRITERIA
<render>
.
.
.
</render>
<default/>
</dynamic-renderer>
The following table describes the elements you can use with <dynamic-renderer>.
Element Usage and Description

<attribu Specifies the <KEY_ATTRIBUTE_ID> used to bind or tie together a set of dynamic-renderers.
te>
CRITERI Defines an attribute filter criteria used to determine which renderer is used based on the
A filter output.
<render Defines what to render.
>
<default Specifies the dynamic-renderer to use as the default when none of the other dynamic-
> renderer criteria are met.
Attribute Filter Criteria and <dynamic-renderer>
It is common to use <model-class> and <model-type> for attribute filter criteria. You can use any
attribute and any set of complex attribute filters with any combination of nested and and or
filters. The file <$SPECROOT>/tomcat/webapps/spectrum/WEB-INF/common/schema/attributefilter.
xsd contains the complete syntax for attribute filters.
Specify a Default <dynamic-renderer>
You define the default dynamic renderer for use when none of the conditions for using the <dynamic-
renderer> specified in the CRITERIA statement are met. You can specify only one default dynamic-
renderer per dynamic renderer set. Do not specify a filter criteria for the default.
Example: Using Attribute Filtering Criteria with <dynamic-renderer>
This example creates a column that displays an attribute based on the value of the model_type
attribute. The attribute displayed for the model_type filter criteria conditions are shown in the
following table.
03-Apr-2017 283/311
Attribute to display... if model_type is...

<attribute> 0xffff0000 <model-type> 0x12
<attribute> 0xffff0001 <model-type> 0x34 and 0x56
<attribute> 0xffff0002 for all other model types (default)
You must select one of the attributes specified in your filter criteria to be the key. This example uses
0xffff0002. Add the following <dynamic-renderer> elements to the custom-app-config.xml file:
<dynamic-renderer>
<attribute>0xffff0002</attribute>
<render>
</render>
</dynamic-renderer>
<dynamic-renderer>
<or>
</or>
<render>
</render>
</dynamic-renderer>
<dynamic-renderer>
<render>
</render>
<default/>
</dynamic-renderer>
Example: Use a Key Attribute ID with <content>
This example creates a column specifying the <dynamic-renderer> element with the key attribute ID
defined in the <content> element.
<column>
<name>My Column</name>
<content>
<dynamic-renderer>0xffff0002</dynamic-renderer>
</content>
</column>
About Expressions
When you are customizing the OneClick interface, there are several places where you may want to
use an expression to display a calculated value. For example, you may want to display a calculated
value in a table or subview. The section below explains how to use expressions to manipulate
attribute information.
03-Apr-2017 284/311
Note: Expressions are created using standard Java expressions. You must be familiar with
Java code in order to implement the following instructions that create expressions in the
OneClick XML files. If you are not familiar with Java code, you should refer to a Java
reference before attempting to create expressions when customizing OneClick files.
Manipulate Attribute Information
The most common use of an expression is to manipulate attribute information. The attribute
information available is dependent upon the OneClick context in which you are using the expression.
You can use the methods listed in the following table in the context of an expression to retrieve
attribute information:
java.lang.Object attr ( int attrID )

boolean attrBoolean ( int attrID )
byte attrByte (int attrID)
char attrChar ( int attrID )
double attrDouble ( int attrID )
float attrFloat ( int attrID )
int attrInt ( int attrID )
long attrLong ( int attrID )
short attrShort( int attrID )
The following example shows a column configuration that displays the contact person for a device. In
this example, an expression displays the attribute 0x23000c (AttributeID.CONTACT_PERSON) if the
attribute 0x10b5a (AttributeID.SYS_CONTACT) is null or has no value.
Example: Specifying a Contact for a Device Using an Expression
<column id="column-contact-config"
<name>Contact Person</name>
<content>
<expression>
( attr( AttributeID.SYS_CONTACT ) == null ||
((String)attr(AttributeID.SYS_CONTACT)).length() == 0) ?
attr( AttributeID.CONTACT_PERSON ) : value()
</expression>
</content>
</column>
03-Apr-2017 285/311
Another way to accomplish the same result is to use the attribute renderer to retrieve the
SYS_CONTACT attribute value. You can then access the value returned using an expression that uses
the value() method.
Example: Using Attribute Renderer to Retrieve Attribute Value
<column id="column-contact-config"
<name>Contact Person</name>
<content>
<attribute>AttributeID.SYS_CONTACT</attribute>
<expression>
(value() == null || ((String)value()).length() == 0) ?
attr( AttributeID.CONTACT_PERSON ) : value()
</expression>
</content>
</column>
The two examples shown above produce the same value for the column.
Append Suffix to Values
Use an expression to append a suffix to values to increase readability of information displayed in

tables.
Example
This example appends a % character to a value so that the value displays in a table as <value>%.
<expression>value().toString() + "%"</expression>
You can use this method to append a % character to a percentage of disk space used value, so
that the value displays in a table as <percentage of disk spaced used>%, or 64%.
Precautions for Using Expressions
The following list describes major exceptions to the rules for standard Java code that are used to
create OneClick expressions.
Comparison Operator
You cannot use the comparison operator, &&, due to restrictions on XML formatting. In place of
&& you must use &&.
Less Than, Greater Than Operators

You cannot use the less than (<) or greater than (>) operators. Instead, you must use < and >
respectively.
03-Apr-2017 286/311
Subtraction Expressions
OneClick processes subtraction expressions using non-standard associativity. Subtraction is done
using a right-to-left associativity instead of the standard left-to-right associativity.
OneClick processes subtraction as follows:
A - B - C = A - (B - C)
compared with standard subtraction expression processing:
A - B - C = (A - B) - C
Reference XML Files

As you are customizing OneClick XML files, you may find it necessary to split a single XML file into two
or more XML files for the following reasons:
Some XML files are so complex that they become unreadable. In this case breaking the XML file
down into two or more files assists you in keeping your code organized and making it readable
and editable in the future.
You may want to reuse certain sections of XML code. Putting this XML code in a separate file
allows you to reference it from multiple files instead of copying and pasting it into new files, or
new sections of the same file.
Use the standard XML id and idref attributes to label and reference the split up code.
Note: For information on XML standards, including id and idref, see .
Reference Images
You may need to reference image files from within your XML. When you reference image files in
either the factory <$SPECROOT>/tomcat/webapps/spectrum/images directory or the custom
<$SPECROOT>/custom/images directory, express the path starting from the images directory, for
example, images/myimage.png. See Example: Icon Configuration File for an example.
You must place all image files that you add or customize in the <$SPECROOT>/custom/images
directory. Otherwise, all new or customized images you add will be deleted or overwritten during a
CA Spectrum or OneClick upgrade or reinstallation.
Verify User Input Using Verifiers

You can verify user input by specifying a verifier class along with the <editable> element before
committing the change. If the input is invalid, an error message is displayed. The verifiers available
are described in the following section.
Specify the <verifier> element inside the <editable> element. Inside the <verifier>, you specify a
verifier Java class and optional parameters to pass to the verifier class.
Example: Using Verifiers
This verifies the input value is from 0-100, inclusive.
03-Apr-2017 287/311
<editable>
<verifier>
<class>
com.aprisma.spectrum.app.swing.widget.IntegerContainedInRangeInputVerifier
</class>
<param name="lowValue">0</param>
<param name="upperValue">100</param>
</verifier>
</editable>
OneClick Input Verifiers
IntegerContainedInRangeInputVerifier
Description: Verifies the input is an integer value within a specified range.
Class:com.aprisma.spectrum.app.swing.widget.IntegerContainedInRangeInputVerifier
Parameters:
lowValue - the lower bound of the range
upperValue - the upper bound of the range
AttrIDInputVerifier
Description: Verifies the user input is a valid attribute.
Class: com.aprisma.spectrum.app.swing.widget.AttrIDInputVerifier
DoubleInputVerifier
Description: Verifies the user input is a valid real number.
Class: com.aprisma.spectrum.app.swing.widget.DoubleInputVerifier
IPAddressInputVerifier
Description: Verifies the user input is a valid IP address.
Class: com.aprisma.spectrum.app.swing.widget.IPAddressInputVerifier
IntegerInputVerifier
Description: Verifies the user input is a valid integer.
Class: com.aprisma.spectrum.app.swing.widget.IntegerInputVerifier
LongInputVerifier
Description: Verifies the user input is a valid long integer.
Class: com.aprisma.spectrum.app.swing.widget.LongInputVerifier
03-Apr-2017 288/311
MACAddressInputVerifier
Description: Verifies the user input is a valid MAC address.
Class: com.aprisma.spectrum.app.swing.widget.MACAddressInputVerifier
NonEmptyStringInputVerifier
Description: Verifies the user input is a non-empty string.
Class: com.aprisma.spectrum.app.swing.widget.NonEmptyStringInputVerifier
UnsignedIntInputVerifier
Description: Default verifier for all integer attributes; verifies the user input is an unsigned integer.
Class: com.aprisma.spectrum.app.swing.widget.UnsignedIntInputVerifier
Customizing OneClick for CA Service Desk

For a CA Spectrum and CA Service Desk integration, you can modify the behavior of finding and
creating Service Desk assets from OneClick. This customization is done by changing the attribute
mapping between CA Spectrum models and Service Desk assets. Customizing asset reporting lets you
prioritize the information used to identify a device and determine which information to record within
Service Desk. How information is recorded in Service Desk can enhance the users efficiency and
reporting capabilities to best suit your organization.
Note: For more information about customizing asset reporting for CA Service Desk, see CA
Service Desk and CA Spectrum (https://docops.ca.com/display/CASP102
/CA+Service+Desk+and+CA+Spectrum).
03-Apr-2017 289/311
TL1 Gateway
Contents
What Is TL1? (see page 290)
What Is TL1 Gateway? (see page 290)
What Does TL1 Gateway Include? (see page 290)
What Is TL1?
Transaction Language 1 (TL1), occasionally referred to as MML (Man Machine Language), is a widely
used protocol in telecommunications management. The TL1 protocol can be used to manage most
telecom network elements in North America.
Unlike SNMP, TL1 is a human-machine interface that contains human-readable strings. Also, unlike
SNMP, TL1 includes no concept of a MIB. TL1 was originally specified by Bellcore in 1986 and is now
maintained by Ericsson.
What Is TL1 Gateway?

The TL1 Gateway for CA Spectrum translates TL1 events and alarms originating from a TL1 device into
CA Spectrum events and alarms. The gateway acts as a mediator between TL1 devices and CA
Spectrum.
Each TL1 device is represented by a corresponding device model within CA Spectrum. As a result, you
can launch the Enterprise Alarm Manager application for a particular model so that you can check for
certain alarm conditions and initiate corrective action. TL1 Gateway also supports TL1 devices that
are accessible through proxy devices, also known as Gateway Network Element (GNE) devices.
TL1 Gateway implements the full range of TL1 Condition Types as specified by Telcordia. Telcordia
has been acquired by Ericsson. Multiple websites provide lists of current network element and
transport surveillance messages.
What Does TL1 Gateway Include?

TL1 Gateway for CA Spectrum provides the following components:
TL1-specific inference handlers that plug into a SpectroSERVER.
A daemon (TL1d) that handles communication between the TL1 devices and the SpectroSERVER.
A model type (Gen_TL1_Dev) for generic TL1 devices.
A utility (tl1map) to manage TL1 AlarmMaps.
03-Apr-2017 290/311

Installing TL1 Gateway (see page 291)
TL1 Devices with Autonomous Port (see page 299)
The TL1 AlarmMap (see page 301)
Managing TL1 Gateway Daemon (see page 309)
Installing TL1 Gateway

Contents
Prerequisites for TL1 Gateway (see page 291)
Installation Options (see page 293)
Install on a Non-CA Spectrum Machine (see page 293)
Setting up Port Numbers (see page 294)
Prerequisites for TL1 Gateway

TL1 Gateway is designed such that it can either be run on the same machine CA Spectrum is running
on, or on a separate machine. Diagrams illustrating both installation models are provided on the
subsequent pages. Running TL1 Gateway on a separate machine is recommended if any of the
following conditions apply:
The CA Spectrum machine hosts a SpectroSERVER that has a high workload.
The CA Spectrum machine is short on resources like CPU and RAM.
The CA Spectrum machine is also used by applications other than CA Spectrum.
A high volume of TL1 traffic has to be processed.
Note: TL1 Gateway does not support IPv6.
The following diagram shows an example of a TL1 Gateway installed on CA Spectrum host:
03-Apr-2017 291/311
SPEC--TL1_Gateway_Installed_on_CA_Spectrum_Host
The following diagram shows an example of a TL1 Gateway installed on a remote host:
SPEC--TL1_Gateway_Installed_on_a_Remote_Host
03-Apr-2017 292/311
Installation Options
If your configuration requires TL1 Gateway to be run on the same machine CA Spectrum is running
on, then the gateway has already been installed during the major CA Spectrum installation. In this
case, all required TL1 Gateway components can be found in a subdirectory called TL1Apps, which is
located in your top-level CA Spectrum directory. The TL1 Apps directory contains the following files:
TL1d -- the gateway daemon
tl1map -- the AlarmMap utility
Install on a Non-CA Spectrum Machine

In some cases, where a certain level of performance is needed, it is preferable to install the TL1
daemon component on a separate server that is dedicated to TL1 message processing. The
instructions vary slightly depending on the platform you are using. In either case, you must find and
run the self-extracting installer file on the CA Spectrum application DVD.
The installer launches a series of dialogs that prompt you to supply the following information:
confirmation of the license agreement
the extraction key
installation target area
Note: Regardless of the platform on which CA Spectrum is running (Solaris or Windows),

the TL1 daemon component can be installed and operated. For example, you can run CA
Spectrum on a Solaris server, while the TL1 daemon is hosted by a Windows server. Such a
heterogeneous TL1 Gateway configuration is fully supported.
Follow these steps on Windows:
1. Navigate to the TL1GW folder on the CA Spectrum application DVD.
2. Run the tl1inst.exe program.
3. Copy the resulting files (listed below) to the proper locations on the NT machine:
TL1d.exe
tl1map.exe
orb.dll
orb_p.dll
03-Apr-2017 293/311
orb_p.dll
Copy the executables TL1d.exe and tl1map.exe to the preferred locations. Copy the DLL files
to the system area that is used for third-party DLL files.
Follow these steps on Solaris:
1. Navigate to the TL1GW directory on the CA Spectrum DVD.
2. Run the tl1inst.bin program.
3. Copy the following resulting files to the proper locations on the Solaris server:
TL1d
tl1map
liborb.so
Copy the executables TL1d and tl1map to the preferred locations. Copy the shared library
liborb.so to the preferred system area for third-party libraries: /usr/lib.
Note: If you are using a location other than /usr/lib, update the environment
variable LD_LIBRARY_PATH to include that location.
Setting up Port Numbers

When you create a TL1 device model, specify the two port numbers that are described below. Before,
you assign any port numbers, first check the local system administration or security policies.
TL1 Gateway Port

Used for communication between the TL1 daemon (TL1d) and the SpectroSERVER. At model
creation, a default port number of 64222 is supplied. When choosing a different port number, we
urge you not to use Port 65535. Ask a system administrator to find a port number in the dynamic
/private range 49152 to 65534.
The TL1 Gateway port number can be specified as a command line argument when launching
TL1d; otherwise, the default of 64222 is assumed.
TL1 Device Port

Used for communication between the physical TL1 device and the TL1 daemon. Check with the
network administrator for the port number to use; it depends on device configuration. It is likely
to be a port number specified in the IANA standard document. Check the Registered Port
Numbers section. Likely candidates are: 2361, 3081, 3082 and 3083. IANA port assignments are
available on the Internet.
Supply the TL1 port number in the model creation dialog.
03-Apr-2017 294/311
Creating a TL1 Device Model

Contents
Max Telnet Sessions and Max Logins Per Telnet Attribute Considerations (see page 296)
Max Telnet Sessions (see page 297)
Max Logins Per Telnet (see page 297)
Important Processing Information for Max Telnet Sessions and Max Logins Per Telnet (see
page 297)
The TL1 Device models are used to check for alarm conditions and initiate corrective action through
Enterprise Alarm Manager. The TL1 devices must be modeled manually as they cannot be modeled
through Spectrum Discovery. For more information about Discovery, see Modeling and Managing
Your IT Infrastructure Administrator (https://wiki.ca.com/display/CSP
Follow these steps:
1. From any OneClick Topology tab view, select the Model by Type toolbar icon.
2. Select the 'All Model Types' tab and enter TL1 into the Filter field.
3. Select Gen_TL1_Dev to model a generic TL1 device and click OK.
4. Complete the following fields to configure the TL1 device model:
Model Name
Specifies a unique name for this model.
TL1 Gateway Address

Specifies the IP address of the server that hosts the TL1 daemon (TL1d).
TL1 Gateway Port

Specifies the port number for communication between the TL1 daemon and CA Spectrum.
Default: 64222
TL1 Device Address

Specifies the IP address of the TL1 device.
Note: Sometimes, this address is the IP address of a dedicated TL1 device that acts
as a proxy for all the other TL1 devices in the network.
TL1 Device Port

Specifies the port number where the TL1 device agent is listening (also known as the
craft port).
03-Apr-2017 295/311
Max Telnet Sessions

Specifies the total number of Telnet sessions TL1 Gateway can make to Gateway Network
Element (GNE).
Default: 1
Max Logins Per Telnet

Specifies the number of logins that are permitted to be active simultaneously per telnet
session. This field value depends on the GNE.
TID
Specifies the Target ID for the TL1 device. This parameter is part of the TL1 addressing
concept, and is required to uniquely identify a device. The TID is a predefined
alphanumeric string. Obtain it from the local Network Administrator.
User Name
Specifies the user ID for the maintenance user, as configured in the TL1 device.
Password
Specifies the password for the maintenance user.
Security String
Prevents selected users from viewing this model.
Poll Interval (sec)

Specifies the frequency at which the device is polled for status updates. Change the value
as needed, to increase or decrease the polling interval.
Default: 60 (300 for some model types)
Note: If you increase the time between polling intervals, less bandwidth is required
for traffic management. However, you receive device status updates less
frequently.We recommend using the default polling interval for critical devices and
using 600 seconds for less important devices.
Log Ratio
Defines how many times CA Spectrum polls devices for updates before logging the results.
Default: 10 (CA Spectrum logs the polling results after it polls the device every tenth time).
Note: No entries or adjustments to the defaults are required for the remaining
fields. For more information about field settings, see CA Spectrum Administrator (
https://wiki.ca.com/display/CSP/OneClick+Administration).
5. Click OK.
A TL1 device model icon is displayed.
Max Telnet Sessions and Max Logins Per Telnet Attribute Considerations
03-Apr-2017 296/311
Max Telnet Sessions

The Max Telnet Sessions field enables you to specify the total number of telnet sessions that TL1
Gateway can make to Gateway Network Element (GNE). Default is 1.
TL1 devices exist in a ring or group. The Gateway Network Element acts as a go between the rest of
the network and the TL1 devices within the ring. Therefore, CA Spectrum makes a telnet connection
to the GNE.
This varies with hardware maximum device specifications. CA Spectrum can use as many sessions as
the Max Telnet Sessions value has been set to allow. You can specify Max Telnet Sessions to one less
than the hardware maximum to leave one available for the Network Administrator, but it is not
required.
For any given ring, the number of telnet sessions that are used is the highest Max Telnet Sessions
value among all the Gen_TL1_Dev models that are associated with that ring. So, if you have ten
devices that are modeled for a single ring, if all the Max Telnet Sessions values are 1, then the TL1
daemon (TL1d) uses at most one telnet session when communicating with all the devices on that ring.
If nine of the models have a Max Telnet Sessions value of 1 and one of the models has a Max Telnet
Sessions value of 4, then the TL1d can use up to four concurrent telnet sessions when communicating
with ANY of the devices on that ring.
The recommended usage for Max Telnet Sessions is to set it to the desired value on the
Gen_TL1_Dev model which represents the TL1 proxy device, and to leave the value at its default for
other Gen_TL1_Dev models. That way, if you want to change the value, you only have to change it on
one model.
Max Logins Per Telnet

The Max Logins Per Telnet field enables you to enter the number of logins that are permitted to be
active simultaneously per telnet session. This depends on the GNE. Some authorize one active login
at a time, others allocate more.
As with Max Telnet Session, when two or more devices from the same ring are modeled, the TL1
deamon (TL1d) uses the highest Max Logins Per Telnet value among all the Gen_TL1-Dev models that
are associated with that ring.
The recommended usage for Max Logins Per Telnet is to set it to the desired value on the
Gen_TL1_Dev model which represents the TL1 proxy device, and to leave the value at its default for
other Gen_TL1_Dev models. That way, if you want to change the value, you only have to change it on
one model.
Important Processing Information for Max Telnet Sessions and Max Logins Per Telnet
It is important to understand the difference between having a value for Max Logins Per Telnet of 1
versus a value greater than 1.
When Max Logins Per Telnet Equals 1
03-Apr-2017 297/311
When Max Logins Per Telnet equals one, the telnet connections are time-shared. Therefore, polls
cannot occur simultaneously, but instead are carried out in sequence. The maximum number of
devices manageable is dependent primarily on the polling interval and the value of Max Telnet
Sessions. Congestion and slow device response can adversely affect CA Spectrum's management of
the devices.
When Max Logins Per Telnet Is Greater Than 1
When Max Logins Per Telnet is greater than one, polls can occur simultaneously. The maximum
number of devices manageable is a hard limit of Max Telnet Sessions multiplied with Max Logins Per
Telnet. Therefore, congestion and slow device response has less impact on the ability of CA Spectrum
to properly manage the devices.
The TL1 daemon (TL1d) communicates with TL1 devices over shared telnet sessions. That is, if you
have say, ten TL1 devices on a single TL1 ring, TL1 Gateway can send ping requests to and can receive
messages from all ten devices over a single telnet connection.
The TL1 daemon (TL1d) can also have several concurrent telnet sessions open to the same TL1 ring.
So, TL1 Gateway could be using three telnet sessions open simultaneously to communicate with ten
TL1 devices on a single ring.
Congestion Considerations
Because communication is shared over the connections, congestion can occur. The amount of
congestion is determined through:
Number of concurrent telnet sessions available to TL1 Gateway for use to the TL1 ring in question
Number of TL1 devices on the ring that are managed in CA Spectrum
Polling interval of the TL1 models
Frequency of alerts sent to TL1 Gateway from the TL1 devices
Time delay in the TL1 devices responding to commands from TL1 Gateway
If congestion over the telnet session is bad enough, ping requests that the SpectroSERVER sends does
not return in time, and the TL1 models will sporadically go into a contact lost state.
If the network congestion is caused by too many alerts from the TL1 devices, a solution might be to
specify an autonomous port for the devices.
If Max Logins Per Telnet equals one, the following two solutions are available:
Increase the polling interval of the TL1 models -- the devices are polled less often causing less
congestion, resulting in better performance.
Increase the telnet sessions to TL1 devices ratio, by either increasing the number of concurrent
telnet sessions the TL1d can use, or by decreasing the number of TL1 devices on the ring.
Upgrade Considerations
Of particular importance to customers who are upgrading:
03-Apr-2017 298/311
Of particular importance to customers who are upgrading:
Due to the overhead caused by the new functionality, we have increased the default value for the
DCM Timeout attribute (0x110c4) from 3000 to 5000. However, if the customer is upgrading, this
change is not made because the Timeout attribute has the 'Preserve Value' flag set.
If the DMC timeout value is left at 3000, the ping requests sent by the SpectroSERVER will
probably time out sporadically. After upgrading, customers change the Timeout value for all
Gen_TL1_Dev models that they have currently modeled to be 2000 milliseconds higher than their
current value. Likewise, they must also increase the Gen_TL1_Dev model type default value for
Timeout by 2000 milliseconds.
TL1 Devices with Autonomous Port

Some TL1 devices support command ports only and have a port dedicated to autonomous messages.
TL1 Gateway supports this option.
To use it, highlight the TL1 device icon and select the Information tab in the Component Detail view.
The TL1 Autonomous Port can be set in the TL1 Device Information section.
03-Apr-2017 299/311
SPEC--TL_AutonomousPort
Command on First Logon

The value that appears in the Command on First Logon field is issued to the device the first time you
log into that device. In the image shown below, the ALW-MSG-ALL command enables the device to
send alerts to the TL1 Gateway. Note that some devices do not send alerts automatically. The
gateway can then relay the alerts to CA Spectrum as it receives them.
03-Apr-2017 300/311
You can customize the Command on First Logon for any command that requires customization. CA
Spectrum automatically replaces the <TID> and <CTAG> values. The <TID> value uses the TID value
that you specified in the Create Model Type dialog. The <CTAG> value is automatically generated by
the TL1 Gateway for proper communication.
The following image shows an example of the Command on First Logon field in the TL1 Device
Information subview.
Note: The TL1 Device port and TL1 Autonomous port can be same.
SPEC--command_first_logon
Pre Login Sequence

Before logging into a TL1 device, the TL1 daemon can send a few characters to the device to wake up
the telnet session. These characters are stored in the Pre Login Sequence attribute. The default is a
single newline character.
For some cases, multiple newlines may be more appropriate. To change the Pre Login Sequence,
highlight the TL1 device icon and select the Information tab in the Component Detail view. The Pre
Login Sequence can be set in the TL1 Device Information section.
The TL1 AlarmMap

Contents
Format of the AlarmMap (see page 303)
The tl1map Utility (see page 304)
AlarmMap Extraction (see page 306)
Importing an AlarmMap (see page 306)
Examples of tl1map Usage (see page 307)
AlertMaps for TL1 (see page 308)
The TL1 Gateway AlarmMap is an internal mapping of TL1 events and alarms to CA Spectrum alerts.
The AlarmMap is used by the TL1 daemon to determine whether an incoming TL1 event or alarm is
discarded or be converted to an alert code and forwarded to CA Spectrum. Thus the AlarmMap
functions as a filter to discard unnecessary TL1 events or alarms.
03-Apr-2017 301/311
Another mapping file is also required to support the AlarmMap. The alert code that is specified in the
TL1 AlarmMap is processed by a corresponding AlertMap file on the SpectroSERVER. If the AlertMap
file is missing, TL1 alerts are not properly mapped to events. For more information, see AlertMaps for
TL1 (see page 308).
An AlarmMap usually includes a default entry, which is used for any TL1 events or alarms that lack a
specific mapping. That is, all unmapped TL1 events/alarms result in the same CA Spectrum alert that
is specified in the default entry.
TL1 alarms are displayed in the following image:
SPEC--TL1_Alarms
TL1 details per alarms are displayed in the following image:
03-Apr-2017 302/311
SPEC--TL1_Alarm_Details
Format of the AlarmMap

The AlarmMap is a sequence of records, each comprising the following five comma-separated fields:
<type>,<condition>,<alert-code>,<clr-alert-code>,<process>
<type>
A text string specifying the entry type as either ALM (for alarm) or EVT (for event).
<condition>
A text string identifying a TL1 condition type (TL1 alarms) as specified in the Telcordia standards
document GR-833-CORE. If this string is blank, or empty, the record serves as the default entry for
the AlarmMap. If the string ends in a hyphen (e.g., OGCCS-), all conditions that start with that
string are mapped by this entry. It resembles a wildcard.
<alert-code>
A hexadecimal literal with a leading 0x that specifies the alert code to be used by CA Spectrum
for this TL1 event/alarm.
03-Apr-2017 303/311
<clr-alert-code>
A hexadecimal literal with a leading 0x that specifies the code that CA Spectrum uses to clear
the TL1 event/alarm.
<process>
Is a boolean value (TRUE or FALSE) that specifies whether the event/alarm is processed. If TRUE,
an alert is generated for CA Spectrum. If FALSE, the incoming TL1 event/alarm is discarded and
nothing is forwarded to CA Spectrum.
The following is an example of an AlarmMap:
ALM, ,0x3d50001 ,0x3d50002 ,TRUE <------ DEFAULT
ALM,LINETERM ,0x3d500f3 ,0x3d500f4 ,TRUE
ALM,ECOI ,0x3d501b9 ,0x3d501ba ,TRUE
ALM,SLOR ,0x3d501c9 ,0x3d501ca ,TRUE
EVT,NTYDGSP ,0x3d5009d ,0x3d5009e ,TRUE
The commas can be surrounded by spaces. Everything after the <process> field and a space is
treated as comment for better readability.
The contents of the AlarmMap are critical to the performance of TL1 Gateway. Configure the
AlarmMap such that only those TL1 alarms in which you are interested are processed. In other words,
verify that the <process> value is set to FALSE for all TL1 alarms that you do not want to generate a
CA Spectrum alert.
If an unwanted TL1 event/alarm does not appear in the map, it is still processed through
the default mapping, assuming that the map has a default entry. To prevent this extra
processing, you can take one of the following steps:
Include all unwanted TL1 events/alarms in the map with their <process> values set to
FALSE.
Remove the default entry.
The tl1map Utility

TL1 Gateway includes a command-line tool that is called tl1map that lets you inspect the AlarmMap
and perform either of the following two operations:
Extract an AlarmMap from either a TL1 device model or from the TL1 device model type
(Gen_TL1_Dev).
Import an AlarmMap in the form of a text file either to a TL1 device model or to the Gen_TL1_Dev
model type.
The tl1map tool is located in your top-level CA Spectrum directory's TL1Apps subdirectory. You can
run tl1map either from the shell command line or from within scripts (if you need to perform more
complicated AlarmMap manipulations). In either case, tl1map is a SpectroSERVER client, so
SpectroSERVER must be up and running.
03-Apr-2017 304/311
Note: The tl1map utility is dedicated to models/model types of the Gen_TL1_Dev hierarchy
only. It is not intended to be used with any other models/model types and could cause
potential data corruption if not used properly.
Syntax
.tl1map {load | dump} -f mfile {-t | -m} handle [host]
dump
Extracts the internal AlarmMap in text format and saves it to the file specified by the -f option, in
text format.
load
Processes the input file that is specified by the -f option and writes an AlarmMap to the
corresponding attribute.
-f mfile
Indicates that the next entry will provide the name of a particular map file (mfile). In load mode,
the supplied input file is expected to have AlarmMap syntax, and it is converted into an internal
TL1 AlarmMap object. When in dump mode, the contents of the already existing, internal
AlarmMap is extracted, formatted, and written to the specified mfile. This file is then suitable for
visual inspection and processing by a text editor, so it can be changed, and re-imported using the
load option.
-t
Specifies that the handle provided is the model type handle of the TL1 device model type.
-m
Specifies that the handle provided will the model handle of a TL1 device model.
handle
Specifies the handle of either the TL1 device model type (if the -t flag is used) or the TL1 device
model (if the -m flag is used).
Limits: Hexadecimal format
host
The name of the CA Spectrum host. This is only needed when accessing a remote host, or if the
Unix hostname command reports a mixed-case name, while the true host name was advertised
in lower-case format. In any case, tl1map should be run on the local host.
Note: The -f, -t, and -m -f options can appear in any order.
03-Apr-2017 305/311
AlarmMap Extraction
If tl1map is invoked with the dump option, it will read the current AlarmMap attribute value from
either a model (-m option), or a model-type (-t option), convert it into a human-readable format, and
write it to the file specified by the -f option. That file will also contain an informational header, which
includes things like model name, model type name, model handle, model type handle, host name,
and the current time stamp (based on the machine where the utility was invoked). The header is
formatted as a comment, so it will not affect any subsequent import operation using this machine-
generated file.
Typically, you would examine this AlarmMap file with a text editor, make any desired modifications,
and then import the file again by invoking tl1map with the load option.
Note: The entries in the output file are in no particular order. If you want to compare two
different AlarmMaps, you need to do the following:
Strip off the comment header.
Sort the files.
Perform the actual comparison.
Importing an AlarmMap
To import an AlarmMap under any of the following scenarios, use the tl1map utility with the load
option:
Creating an initial AlarmMap based on documents from a TL1 device vendor or on TL1 standards
documents.
Extracting a previously stored AlarmMap, applying some changes, and importing the changed
version again.
Extracting the AlarmMap from one model/model type, and importing it to another model/model
type (possibly on another host)
When importing an initial AlarmMap from a file, you have to make sure that the file conforms with
the format specifications for AlarmMap files.
The tl1map utility displays limited diagnostic messages if it encounters illegal entries in the AlarmMap
file. If there were any errors, no data is written to the model/model type attribute.
03-Apr-2017 306/311
Examples of tl1map Usage

The following examples illustrate how the tl1map utility might be used to perform various specific
tasks. Note that the examples use /dev/stdin and /dev/stdout. Since these are not available on NT,
you would therefore use intermediate files instead of Unix-style pipes.
To import an AlarmMap to model 0x146007
tl1map load -f custom.amap -m 0x146007
To export the AlarmMap to a file
Exporting the AlarmMap to a file enables it to be modified. The modified file can be reloaded
/imported.
tl1map dump -f exp.amap -t 0x4010000
...then, after you edit and save exp.amap ...
tl1map load -f exp.amap -t 0x4010000
To copy the AlarmMap from one model to another
tl1map dump -m0x1503fcc -f/dev/stdout |

tl1map load -m0x1504003 -f/dev/stdin
To delete the LINETERM entry from the AlarmMap
tl1map dump -m0x1504003 -f/dev/stdout |

sed '/LINETERM/d' |
tl1map load -m0x1504003 -f/dev/stdin
To copy a model-based map from one host to a model type-based map on another host:
tl1map dump -m0x1504003 -f/dev/stdout hosta |

tl1map load -t0x25040cc -f/dev/stdin hostb
The following example shows a shell script that could be used to implement a simple AlarmMap
editor:
#! /bin/ksh
#
# A simple AlarmMap editor
#
# Syntax: tl1edit { -m | -f } handle [ host ]
#
# Your favorite text editor

if [[ -z $EDITOR ]]; then
EDITOR=vi
fi
03-Apr-2017 307/311
# Generate a unique, temp file name

MF=`date '+%Y%m%d%H%M%S.almap'`
# Dump the AlarmMap to that temp file

tl1map dump -f $MF $*
# Make a backup copy

cp $MF $MF.orig
# Invoke your favorite editor on that file

$EDITOR $MF
# If there are no changes, remove temp mapfiles & exit

diff $MF $MF.orig > /dev/null && rm -rf $MF $MF.orig && exit
# If there were changes, load them into the attribute

tl1map load -f $MF $*
AlertMaps for TL1

The TL1 AlarmMap converts a TL1 autonomous message into an alert (not an event) that is processed
by CA Spectrum. CA Spectrum handles these alerts similarly to SNMP traps. Configure the AlertMap
with the alert code that is specified in the TL1 Alarm Map.
Note: The alert code that is specified in the AlertMap is a decimal number rather than an
SNMP trap OID.
Each alert from the TL1 Gateway offers the following standard, unchangeable varbinds:
Varbind 1: AID
Varbind 2: Severity
Varbind 3: Condition
Varbind 4: Alarm Message
Varbind 5: Alert Code (as specified in the TL1 AlarmMap)
The AlertMap must map these alert variables to event variables, one for one.
A supported entry in the AlertMap resembles the following syntax:
64352257 0x3d5f001 1(1,0) 2(2,0) 3(3,0) 4(4,0) 5(5,0)
The previously mentioned entry maps alert code 64352257 (0x3d5f001 in decimal) to event code
0x3d5f001, and copies each of the five alert variables to the event.
03-Apr-2017 308/311
For more information about the AlertMap, EventDisp, CsEvFormat, and CsPCause files, see Event
Configuration (https://wiki.ca.com/display/CSP/Event+Configuration).
Managing TL1 Gateway Daemon

Contents
TL1 Gateway Daemon (see page 309)
Start the TL1 Daemon on a CA Spectrum Server (see page 309)
Start the TL1 Daemon on a Remote Server (see page 310)
Terminating the TL1 Daemon (see page 311)
TL1 Gateway Daemon

A TL1 Gateway daemon (TL1d) must be up and running in order to translate alarms from the modeled
TL1 device into CA Spectrum events and alarms. The daemon is located in your top-level CA Spectrum
directory's TL1Apps subdirectory. It has the following syntax:
TL1d [-p gw-port]
-p gw-port
Specifies that a TL1 Gateway port (gw-port) other than the one specified at model creation will be
designated for communication between the daemon and SpectroSERVER.
Default: 64222
Note: CA recommends that you not use the value 65535, as it is likely to conflict with
other applications.
Start the TL1 Daemon on a CA Spectrum Server

Start the TL1 daemon to start handling alarms from TL1 devices.
This procedure varies only slightly (see Step 3) for the Solaris and Windows platforms.
Follow these steps:
1. Launch a command shell window.
2. Navigate to the TL1Apps subdirectory in your top-level CA Spectrum directory.
3. Enter one of the following commands:
TL1d ( or ./TL1d on Solaris)
or, if you want to use a different gateway port...
03-Apr-2017 309/311
3.
TL1d ( or ./TL1d on Solaris) -p <your-gw-port number>
As soon as you see @(#) followed by the actual port number, the daemon is running. You
can minimize the command shell window.
Start the TL1 Daemon on a Remote Server

This procedure is described separately for NT and Solaris below. In either case, you need to know the
IP address of the server that hosts the CORBA osagent in your environment. This server is most likely
the same computer where CA Spectrum is running.
Take a few steps to start the TL1 Daemon on a remote server on Windows.
Follow these steps:
2. Navigate to the directory where your TL1d.exe file resides.
TL1d
Or, to use a different gateway port, enter the following command:
TL1d -p <your-gw-port number>
Take a few steps to start the TL1 Daemon on a remote server on Solaris.
Follow these steps:
2. Navigate to the directory where your TL1d file resides.
./TL1d
Or, to use a different gateway port, enter the following command:
./TL1d -p <your-gw-port number>
03-Apr-2017 310/311
Terminating the TL1 Daemon

The specific command or procedure for gracefully terminating the TL1 daemon depends on the
platform the daemon is running on.
On Solaris, use either the kill command or Control-C.
On NT, bring up the Task Manager, select the TL1d process, and then terminate it.
03-Apr-2017 311/311

CA Spectrum - 10.2 and 10.2.1 - ENU - Customizing - 20170403 PDF

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

CA Spectrum - 10.2 and 10.2.1 - ENU - Customizing - 20170403 PDF

Hochgeladen von

Copyright:

Verfügbare Formate

CA Spectrum - 10.

The manufacturer of this Documentation is CA.

Modeling Gateway Toolkit ......................................................................... 12

Model Type Editor ................................................................................... 107

OneClick Customization .......................................................................... 177

TL1 Gateway ........................................................................................... 290

Modeling Gateway Toolkit

Cable MSO (Multi-Service Operator)

ATM (Asynchronous Transfer Mode)

Modeling Gateway support for Wireless Devices

To discover and model AccessPoint devices, follow these steps:

CA Spectrum Modeling Gateway is an effective solution for these problems.

Modeling Gateway Prerequisites

Have had significant exposure to CA Spectrum.

Read SpectroSERVER and CA Spectrum Databases Overview (https://docops.ca.com/display/CASP102

Have a working knowledge of XML.

Understand the concept of a Document Type Definition (DTD).

Have a detailed understanding of the network topology you are importing.

Import and Export Architecture

Modeling Gateway uses an XML file for importing data

Import Topology Data into CA Spectrum

1. Extract Topology Data.

2. Format the Data in an Input File (see page 17).

3. (Optional) Move the modelinggateway Tool.

Note: To run the modelinggateway tool on another server, move the

4. Run the modelinggateway Tool (see page 32).

5. (Optional) Import Comma-delimited Files (see page 34).

6. View Import Information (see page 35)

This section contains information about the following topics:

Format the Data in an Input File

XML Input Files

Models and Model Types

Intelligent model types

Container model types

For more information, see SpectroSERVER and CA Spectrum Databases Overview (

XML Input File Syntax

This section contains information about the following topics:

Task-Oriented Elements (see page 22)

Task-Oriented Elements (see page 22)

New Topology Data

Create a Location View

Example: Site Container in Location View

<?xml version = "1.0" standalone = "no" ?>

Create a Topology View

Topology_Container elements to create a specific type of container model.

Device elements to create a specific type of device model.

Connection elements to create connections between two devices.

Example: LAN Container in Topology View

<?xml version = "1.0" standalone = "no" ?>

Represent the Same Device in Multiple Views

Example: Create a Device in Both the Topology and Location Views

<?xml version = "1.0" standalone = "no" ?>

Create Connections Using Discovery

Example: Using Discovery to Create Connections

<?xml version = "1.0" standalone = "no" ?>

Create Connections Using the Connection Element

At least one of these devices is a manageable device.

The error is written to the error log file.

Example: Create a Connection between Existing Ports

<?xml version = "1.0" standalone = "no" ?>

The Connection element is contained within a Topology element or a Topology_Container element to

Create WA_Link Connections

Synchronize Information Between CA Spectrum and the Third-Party Database