|
|
This section contains reference information about each of the Cisco Info Center Info Gateways. Each section contains all of the information you need about the Cisco Info Gateway mappings and Writer attributes.
This chapter contains the following sections:
The Cisco Info Server Reader is created and controlled by the START READER command. See the "START READER" section in Appendix H for details on this command.
The Cisco Info Server Writer allows for the replication of alerts between Cisco Info Servers. When a route is established between an Cisco Info Server Reader and an Cisco Info Server Writer, alerts are forwarded to the destination Cisco Info Server. Changes in the Cisco Info Server that is written to are not reflected in the Cisco Info Server being read.
Mappings for use with the Cisco Info Server Writer must follow this syntax:
(' <dest_fieldname>' = ('@<src_fieldname>' | integer) [ON INSERT ONLY]
[CONVERT TO type]
[, 'dest_fieldname' = ('@<src_fieldname>' | integer) [ON INSERT ONLY]
[CONVERT TO type]]...); where <mappingname> is the name of the mapping to be created, <dest_fieldname> is the integer value for the field to be written to in destination Cisco Info Server., and <src_fieldname> must be the name of a field in the Cisco Info Server alerts.status table.
The optional ON INSERT ONLY controls the updating of the field during the life of the alert; when omitted, the field is updated for any change in the state of the alert. When included, the field is set only when the alert is created.
The optional CONVERT TO type allows the mapping to define a forced conversion for situations where a source field may not match the type of the destination field. The type value can be INTEGER, STRING, or DATE to force the source field to be converted to an integer, string, or date type.
 |
Note The ordering of the fields in the mapping must exactly match that of the fields in the Cisco Info Server table being written to. Otherwise, values are written to the incorrect fields. |
This is an example mapping file:
CREATE MAPPING SERVER_MAP('Identifier' = '@Identifier' ON INSERT ONLY,'Serial' = 0 ON INSERT ONLY,'Node' = '@Node' ON INSERT ONLY,'NodeAlias' = '@NodeAlias' ON INSERT ONLY,'Manager' = '@Manager' ON INSERT ONLY,'Agent' = '@Agent' ON INSERT ONLY,'AlertGroup' = '@AlertGroup' ON INSERT ONLY,'AlertKey' = '@AlertKey' ON INSERT ONLY,'Severity' = '@Severity','Summary' = '@Summary' ON INSERT ONLY,'StateChange' = '@StateChange','FirstOccurrence' = '@FirstOccurrence' ON INSERT ONLY,'LastOccurrence' = '@LastOccurrence','InternalLast' = '@InternalLast','Poll' = '@Poll' ON INSERT ONLY,'Type' = '@Type' ON INSERT ONLY,'Tally' = '@Tally' ON INSERT ONLY,'Class' = '@Class' ON INSERT ONLY,'Grade' = '@Grade' ON INSERT ONLY,'Location' = '@Location' ON INSERT ONLY,'OwnerUID' = '@OwnerUID','Acknowledged' = '@Acknowledged','ServerName' = SRC_SERVER ON INSERT ONLY,'ServerSerial' = '@ServerSerial' ON INSERT ONLY);
The creation of a Cisco Info Server Writer requires the attributes described in Table 6-1.
| Attribute Name | Description |
|---|---|
| Type of Writer; must have a mandatory value of |
| Revision of Writer; must have a mandatory value of 1. |
| Name of mapping for Writer to use. |
| Name of Cisco Info Server to write alerts to. |
| Optional: Should deletes be forwarded. The default is YES/TRUE. When set to NO/FALSE, no deletes are propagated to the destination Cisco Info Server. |
| Optional: Name of the counterpart Reader in a bidirectional Cisco Info Gateway configuration. The Reader must be running for the command to function. |
| Optional: The default is 1 (on). When the Cisco Info Server is unavailable, store and forward stores all events until the Cisco Info Server is available, then it forwards the alerts to the Cisco Info Server. |
| Optional: The number of consecutive errors to forward to the Cisco Info Server. When more than one consecutive error exists in the store and forward file, the Writer checks this figure to see how many of them to forward to the Cisco Info Server. The default is: |
| Optional: Defines a filter to use in the event this Writer becomes the master Writer during a resynchronization. |
START WRITER CUSTOMER_WRITE(TYPE = OBJECT_SERVER,
REVISION = 1,
SERVER = DENCO,
MAP = SERVER_MAP,
STORE_AND_FORWARD = 1);
This section describes the integration of Cisco Info Center and Clarify through the Clarify gateway. It is assumed that the reader has administrative experience with Cisco Info Center, as well as a basic understanding of the Clarify FrontOffice client GUI. It contains the following sections:
Clarify FrontOffice is a helpdesk-type Client/Server application. The Clarify Info Gateway is designed primarily to interface with a Clarify helpdesk application named ClearSpport.
Clarify helpdesk tickets are called case objects, or cases. Cases can be passed between Clarify applications when required, for example, a helpdesk call requires escalation to engineering or results in a new part being shipped to the customer. This allows Clarify case objects to be passed in a seamless manner between different departments in an organization.
This chapter contains the following main sections that will help you to implement the Clarify gateway.
You should read the following sections before you attempt to install the gateway.
You should read the following sections before you attempt to configure the gateway.
For more information about how to use Clarify, refer to the Clarify documentation.
The Clarify gateway is compatible with:
The Clarify gateway is supported on the following platforms:
Note that current versions of Clarify do not support Oracle 8.
Clarify is an application designed to support a range of different business functions related to customer support. It comprises three main applications:
ClearQuality is a change management system. It can be used to record customer change or enhancement requests in product development and support organizations. In Clarify terms, the central element of ClearQuality is the change request.
ClearLogistics is used to manage the logistics of customer support and service organizations. This includes managing and forecasting parts, repairs and inventory. In Clarify terms, the central element of ClearLogistics is the part request.
ClearSupport is a call handling system. It can be used to record, track, review and cost customer calls to technical support organizations. In Clarify terms, the central element of ClearSupport is the case.
Each of these applications is related and managed through the same desktop. They all store and manage data using a central database. For more information about them refer to the Clarify documentation. The Clarify gateway is designed to integrate with the ClearSupport application. It can be implemented as either a unidirectional or a bidirectional gateway.
In a unidirectional implementation, alerts from Cisco Info Center are passed through the gateway to form Clarify cases. Those cases can subsequently be updated or closed by another Cisco Info Center alert, but any changes made to the cases in Clarify are not fed back to Cisco Info Center.
In a bidirectional implementation, alerts from Cisco Info Center are passed through the gateway to form Clarify cases. Any subsequent changes to those alerts or cases is reflected in the other application. Therefore, changes to alerts in Cisco Info Center are reflected in related Clarify cases and changes to Clarify cases are reflected in related alerts.
This section describes the operation of the Clarify gateway. The gateway manages four types of event between Clarify and the Info Server.
These Clarify event types are:
The codes pmo, pmc, pmu, pmj, associated with each of the event types, are used by the gateway to recognize the type of event being generated. The following section describes the functionality of the components s and how they work together to maintain Cisco Info Center alerts and Clarify cases.
The gateway passes information between the Clarify reader and writer modules and the Info Server. New alerts are passed through the gateway to form Clarify cases. The gateway also feeds back the Clarify case ID of new cases to the Info Server so that alerts can be linked with associated cases.
Whenever an alert is updated or deleted in the Info Server, the changes are mapped through the gateway to modify the appropriate Clarify case. Likewise, if the alert journal is updated in the Info Server, the changes are mapped through the gateway and reflected in the log notes of the associated Clarify case.
If the gateway is bidirectional, changes to any case that was originally generated by Cisco Info Center are passed through the gateway and reflected in the associated alert.
|
Note If an alert is deleted in the Cisco Info Center, the associated case is closed in Clarify but is not deleted, as in the normal Clarify operation. |
The Clarify writer module manages the insertion of Cisco Info Center alerts into Clarify as cases. There are two key functions that the Clarify writer module performs:
The writer in the gateway configuration file contains three contact fields in the open map section (first name, last name, and phone). In Clarify, a contact is the person or entity that reports a problem. The details of every valid contact are stored in a contacts table in the Clarify RDBMS. It is possible to use a serial number, which is associated within a part, as an alternative to a contact.
|
Note To create a case you need at least one contact or serial number. |
When an alert is passed through the gateway, it passes the contact details from the writer to the application code in the Clarify writer module. The application code uses the contact details and the HLAPI (High Level Application Programming Interface) to query the RDBMS.
The query issued by the Clarify writer module checks the contact details table to confirm that the contact details stored in the writer are valid. If they are, the contact ID of that contact is returned to the Clarify writer module where it is associated with the case being created.
The application code takes the alert data that has been mapped through the gateway, adds the contact ID as a Clarify identifier key and then creates a case. The case is then passed into Clarify.
When Clarify receives a new case, it returns the case ID to the Clarify writer module which passes it back through the gateway to be cached in the Info Server. This enables Cisco Info Center to synchronize alerts with their associated cases.
The Clarify POMS (Persistent Object Management Store) is an object management system. It is used by the Clarify application to manage the objects contained within the RDBMS (Relational DataBase Management System).
The Clarify RDBMS is a Sybase, Oracle or Microsoft SQL database. It is used to store information required to manage and operate the Clarify suite of applications including contact details. It also stores cases, change requests and part requests. All the objects stored in the Clarify RDBMS are managed by the Clarify POMS. You should only change or access objects in the RDBMS through the POMS or through applications which use the POMS. If you attempt to change objects in the RDBMS directly, you could seriously damage the integrity of the database.
The Clarify rules manager is a server-based process that tracks a series of business rules that have been entered into the Clarify database. The rules manager looks for changes in the Clarify RDBMS and forwards any events that meet the requirements in the business rules to the Clarify notify server. If a task has not been performed by a specified time, an escalation occurs and the rules manager executes an action to notify Clarify users, for example, by email.
The rules manager must be running for the bidirectional implementation of the Clarify gateway to work.
The Echo Server is a simple communications module that receives case details from the Rules Manager through nco_tcp_echo, then forwards any new details to the Clarify Reader Module. The Echo Server is a gateway module, it can be located on the same host as the gateway or the same host as Clarify. The Echo Server must be running for the bidirectional implementation of the Clarify gateway to work.
The Clarify reader module receives case details from the Echo Server and manages the reflection of the modified Clarify cases into Cisco Info Center alerts in the alerts.status table.
Bidirectional operation is dependent on properly configured Clarify Business Rules and the Echo Server, as well as a running Clarify RuleManager, which executes Clarify Business Rules. Clarify Business Rules are functionally similar to Cisco Info Center Info Server automations.
The basic gateway architecture and flow of communications is detailed below. Note that nco_gate will automatically start or stop the nco_crwmodule.
Refer to the "Clarify Gateway Start Up Sequence" section for a description of how to start the gateway.
The process flow of communications from Cisco Info Center to Clarify is as follows:
nco_objserv > nco_gate > nco_crwmodule (WRITER) > Clarify API > Clarify
The process flow of communications from Clarify to Cisco Info Center is as follows):
Clarify > Rule Manager > nco_tcp_echo > nco_echo_server > nco_crwmodule (READER) > nco_gate > nco_objserv
The following section defines the individual information processes.
This process manages Clarify's equivalent to Info Server automations, and runs on the Clarify server host. The rule manager executes business rules when defined Clarify events occur, such as creating a case, logging a phone log or updating case severity. The rule manager invokes nco_tcp_echo in order to send information back to the Cisco Info Center gateway.
This small binary is installed on the Clarify server host, and is called by the rule manager whenever Cisco Info Center-relevant business rules are fired. This binary takes text input given to it by the rule manager and passes it on to the nco_echo_server over a TCP socket. By default, nco_tcp_echo connects to the nco_echo_server on TCP port 6003.
This binary acts as a listener for information being sent from nco_tcp_echo (on the Clarify server host). By default, nco_echo_server connects to the nco_crwmodule reader on TCP port 6002. This is the port number you need to specify on the TCP_PORT line in the CLARIF_GATE.conf configuration file. nco_echo_server writes to $OMNIHOME/log/echo_server.log.
This is the writer component of the nco_crwmodule. This process writes inserts, adds journal entries, updates and deletes to the Clarify application through the Clarify API (which uses the Clarify POMS to protect the referential integrity of the underlying Clarify database). The writer module receives data from nco_gate following an IDUC update from the Info Server.
This is the reader component of the nco_crwmodule. This process handles the information forwarded by nco_echo_server and feeds it to nco_gate for inclusion into an SQL statement (pmo, pmj, pmu, pmc). nco_crwmodule (Reader) writes to $OMNIHOME/log/CLARIF_GATE_CRW6_READ.log.
This is the gateway binary. Clarify information is fed into the nco_gate process and added into the SQL templates loaded into the gateway upon startup. nco_gate then performs the necessary SQL operations on the Info Server. nco_gate writes to $OMNIHOME/log/CLARIF_GATE.log.
This is the Cisco Info Center Info Server.
The Clarify Gateway requires specific configuration during the installation procedure. This section describes the steps involved to help you achieve a clean installation.
The following tables show the files installed by the Cisco Info Center installation program when you install the Info Gateway component.
Table 6-2 shows the location of the gateway executable, SQL, and configuration files.
:
| Function | Destination Directory |
|---|---|
Gateway binary | |
Gateway reader or writer module | |
Gateway echo server | |
Example SQL templates for gateway feedback | |
Example Clarify gateway configuration file | |
Table 6-3 shows the location of the SQL and data files for the Clarify Gateway.
| Function | Destination Directory |
|---|---|
Example | |
Example conversions table | |
Table 6-4 shows the location of the Clarify Server host directory.
| Function | Destination Directory |
|---|---|
TCP echo binary | |
To install the Clarify Gateway, complete these steps:
$OMNIHOME/etc/CLARIF_GATE.conf to suit your environment. If you are unsure about any of the entries please refer to"Example Configuration File".
Step 2 Ensure that you have created interfaces files on the Info Server and gateway hosts for NCOMS and CLARIF_GATE using $OMNIHOME/bin/nco_xigen.
Step 3 Ensure that you can ping the Clarify Server host from the gateway host.
Step 4 Ensure that you can ping the gateway host from the Clarify Server host.
|
Note For the gateway to connect to Clarify, you need to install the appropriate database client software on the gateway host. |
Ensure that you have an entry for the target Clarify Database in the Oracle tnsnames.ora file. Note that you do not need to have the Oracle client software installed on the gateway host and the tnsnames.ora file is all that is required. This file is found in /var/opt/oracle/tnsnames.ora.
If Clarify is installed on a Sybase database, you can use the embedded Sybase communications layer used by Cisco Info Center. To do this, complete these steps:
Step 2 Enter the following command to start the Info Server INFOSERVER.
Step 3 Enter the following command to start the echo server.
$OMNIHOME/bin/solaris2/nco_echo_server &Step 4 Start the gateway in debug mode.
$OMNIHOME/bin/nco_gate -name CLARIF_GATE -debug & It is essential that the nco_echo_server is running before you start nco_gate. If the nco_echo_server is not running, the nco_gate process will exit reporting the following error to CLARIF_GATE.log:
Error: 16248/10/0: Error in srv_select() - file descriptor 17 is no longer active
This error indicates that a module has failed. Check the log files to see which one.
Your gateway is now connected and running.
The following processes should be running:
/opt/Omnibus/bin/solaris2/nco_crwmoduleversion.database DEBUG CLARIF_GATE_%s_WRITE /opt/Omnibus/bin/solaris2/nco_gate -name CLARIF_GATE -debug /opt/Omnibus/bin/solaris2/nco_crwmoduleversion.database DEBUG CLARIF_GATE_%s_READ
where version is the version of Clarify currently running and database is the type of database.
Step 5 If the gateway exits unexpectedly, inspect the three gateway logfiles in $OMNIHOME/log. Contact Technical Support if you are not sure what the error message means. The most useful of the logfiles is the WRITER logfile:
$OMNIHOME/log/CLARIF_GATE_CRW6_WRITE.log
This is the gateway interface into Clarify.
Step 6 If any problems are encountered, run the gateway in debug mode then check the following files:
CLARIF_GATE_version_WRITE.logCLARIF_GATE.logCLARIF_GATE_version_READ.log
where version is the version of Clarify currently running and CLARIF_GATE is the name of the gateway.
If the following error appears (or anything else with a schema revision variance), then the target Clarify database data dictionary (database schema definition) is a different revision to the one that the gateway (a Clarify API client) is expecting.
#0) Database 'CLARIFY' has schema revision 48. Application was expecting revision 46. (0x700014)
Step 7 If this situation occurs, check that you have the correct SERVICE_RELEASE setting in $OMNIHOME/etc/CLARIF_GATE.conf on the gateway host.
|
Note The Clarify database schema changes to revision 48 in SR3 for Clarify v6.0, so ensure the SERVICE_RELEASE = 3 if CFO98_SR3 is installed on the Clarify server. |
To run the Clarify Gateway, enter the following command:
$OMNIHOME/bin/nco_gate -name CLARIF_GATE & where CLARIF_GATE is the name of the gateway server.
Assuming that all command lines are running correctly, you are now ready to start configuring the gateway. Refer to the "How to Set Up a Unidirectional Clarify Gateway" section and the "Unidirectional Configuration Guide" section for full configuration details.
When the Clarify Gateway is started, the following initiation sequence takes place:
1. The gateway is started.
2. The gateway uses the writer attributes, USER, PASSWORD, and DATABASE to contact the Clarify writer module, which opens a connection to Clarify.
If the gateway received a database ID from Clarify, the gateway is now logged on and ready to generate cases.
When an alert is passed through the gateway, the following case generation sequence takes place:
1. An alert is read from the Info Server.
2. The alert is mapped into open case attributes and passed to the Clarify writer module.
3. The Clarify writer module uses the case attributes to create a case. It uses the contact or serial number attributes in the CLARIFY_OPEN_MAP part of the configuration file to create a Clarify RDBMS contact query. It then sends the case and the query to Clarify.
4. The Clarify RDBMS resolves the contact query. If the contact exists, Clarify returns the contact object ID to the Clarify writer module. If the contact does not exist, Clarify returns a failed message to the Clarify writer module.
5. If the Clarify writer module receives a failed message from Clarify, the case is ignored. A default message is then returned to the feedback field and the writer module where it waits for the next case. If the Clarify writer module receives an object ID from Clarify, it is stored to be used when alerts are passed from the gateway into Clarify.
6. Clarify receives the new case and generates a case ID.
7. Clarify stores the new case and returns the case ID to the Clarify writer module.
8. The Clarify writer module passes the case ID to the gateway.
9. The gateway reads the case ID and adds it to the associated alert in the feedback field of the Info Server.
The Info Server now holds the alert and Clarify holds its associated case. The alert and the case are related by the common case ID. The serial and ID are both stored in a gateway cache.
When an alert is changed in the Info Server, the following case modification sequence takes place:
1. An alert is read from the Info Server.
2. The alert is mapped into case attributes according to its alert type and passed to the Clarify writer module.
3. The Clarify writer module uses the case attributes to create a case update request. It then sends the request into Clarify.
4. Clarify receives the case update request and updates the case.
The change that was made to the alert in the Info Server is now reflected in the associated Clarify case.
In the bidirectional implementation of the Clarify gateway, when a case (that was originally generated from an alert) is modified in Clarify, the following sequence of events takes place:
1. All case modifications that occur in Clarify are recorded in a table, called timebomb, in the Clarify RDBMS.
2. The rules manager constantly monitors the changes to the timebomb table.
3. When a change occurs, the rules manager removes the case information from the table and checks the business rule sets.
4. If the modification of the case meets the business rule for create a case, close a case, change a case field, or append a note, the case information is sent to nco_tcp_echo, which forwards details to the echo server.
5. The Clarify reader module listens for case details from the echo server then parses the case details using the SQL action templates loaded into the gateway upon start up.
6. The gateway forwards the details to the associated alert in the Info Server.
The change that was made to the Clarify case is now reflected in the associated Cisco Info Center alert.
This section describes how to configure Cisco Info Center and Clarify to create Clarify cases from Cisco Info Center alerts. When you have completed the configuration described in this section, you should have a working unidirectional implementation of the gateway. You will also have completed the first stage of the implementation of a bidirectional gateway. For example scenarios refer to the "Unidirectional Configuration Guide" section.
To configure case generation, you need to:
1. Create the gateway configuration file.
2. Create a gateway user.
Each of these steps is described in the following sections.
The Clarify gateway configuration file comprises seven components:
Refer to the scenarios detailed in the "Unidirectional Configuration Guide" section and the "Example Configuration File" section. The Info Server reader and the Info Server route are standard gateway components. The other components are gateway-specific.
|
Note By default, all Cisco Info Center-specific case attributes start with x_nco_. Clarify guarantees that attributes that begin x_ will never be used in the core system, so by using this convention, you can be sure that their attributes will not conflict with default attributes. The Clarify gateway extends this convention to x_nco_ to identify Cisco Info Center attributes. If you create new attributes for use in the gateway, you should use this convention. |
Mappings in the Clarify gateway configuration file must use the following syntax:
CREATE MAPPING mappingname ( `ClarifyFieldname' = '@fieldname' [ CONVERT TO DATE | CONVERT TO INTEGER ], ... , [ ClarifyFieldname = 'string'], ... , [ ClarifyFieldname = variablename], ... ) ;
where:
alerts.status table
'title' = 'Cisco Info Center Alert Case',
PROBLEM_NUMBER or JOURNAL_TEXT. When used, the current contents of these variables are substituted in the assigned fields. PROBLEM_NUMBER is propagated with the Clarify case ID of the alert. It can only be used in update, close maps and journals. JOURNAL_TEXT holds the journal text and can only be used in a journal map.
The optional CONVERT TO DATE allows the mapping to define a forced conversion to a date type field. Also, CONVERT TO INTEGER allows the mapping to define a forced conversion for long integer field types.
A field can be made up of many values, for example:
`title' = `Case + @Serial + created + by + @UID + at + @FirstOccurence^'
Note the ^ symbol at the end of the string. This symbol means convert this token to date.
When the alert values are mapped to the Clarify case, the details are stored in the Clarify RDBMS. However, you can also enter additional mappings to the open map and update map components of the configuration file to create relations with the other tables in the Clarify RDBMS.
The format for adding a relation to the configuration file is:
'RELATIONS' = 'casefieldname', 'TARGET' = 'targetclarifytable', 'keyfield' = 'value',
where:
A straight relation can be created to search for another Clarify user. All alerts that are sent from the gateway are distributed to a Clarify user. This user is specified in the writer attributes section of the configuration file as the USER attribute and this user must be created in Clarify. Therefore all the cases from the gateway would appear in the queue for that user. You can use the relation so that the case appears in the queue for another user. For example, enter the following in the configuration file:
'RELATIONS' = 'case_currq2queue', 'TARGET' = 'queue', 'title' = 'jsmith',
In the example above, for every case that is sent from the gateway, the case_currq2queue field is related to a target table, queue. It searches for the key field called title which contains the Clarify user jsmith, in the queue table. The object ID from the user jsmith is then used to update the case table and the case appears in the queue for the user jsmith. If more than one user of that name is found, only the first one is used. Therefore it is important to ensure that the key field is unique.
To update the other fields in the target table, you can add more fields and values below the key field. For example, if you add the line 'description' = '@Summary', the description field for the user jsmith in the queue table is updated by the Summary field:
'RELATIONS' = 'case_currq2queue', 'TARGET' = 'queue', 'title' = 'jsmith', 'description' = '@Summary',
If the user jsmith does not exist in the table, the user is created with a new object ID. This object ID is used to update the case table. A new queue is then available for the new user. If you have additional fields below the key field, these are added to the queue table.
The complete list of available relations is shown in the "Example Configuration File" section.
The ACTION field can be set when you want specific timebomb objects to be created and therefore a specific business rule to fire. It must be used in conjunction with a relation being set in either the open or update map.
For example:
'RELATIONS' = 'case2curr2queue', 'TARGET' = 'queue', 'ACTION' = 'Dispatch', 'title' = 'Working Queue'
This relation will move the case to the queue called Working Queue. Once the action Dispatch is set, the business rule will fire. Table 6-5 shows the complete list of available actions:
| Action | Description |
|---|---|
| An action to receive and accept ownership. |
| A telephone message has been logged. |
| An action has been dispatched to a field engineer. |
| A means of requesting another user to take ownership of a task by placing a reference to the task in the queue. |
| Forces the case to another user's default |
| An action on a part request which transfers inventory in one inventory location to another. |
| To connect or form relationships between specific objects in the Clarify system. |
| To change an action. |
| An interruption to the system. |
| An email has been received and logged. |
| To remove a link. |
| A means of retrieving a task and placing it into your default |
| The status has been closed. |
| The status has been fixed. |
| The status has failed. |
| A type of subcase that permits the user to route, track and assign administrative tasks as a subcase. |
| Allows the user to log and track various types of demand for part exchanges and new orders. |
| The type of logistics action being performed. |
| The status has been reopened. |
| The time between the creation of a case and the subsequent response to the problem. |
| A means of requiring another user to take ownership of a task by placing it in that user's |
| The status has been changed. |
| The task has been closed. |
The Clarify open map defines the values that will be assigned to Clarify case fields when a new alert is read from the Info Server. When a new case is opened, the Clarify case ID does not exist, so the PROBLEM_NUMBER cannot be assigned to a Clarify case field. The following shows an example mapping:
CREATE MAPPING CLARIFY_OPEN_MAP ( 'contact_first_name' = 'Gateway', 'contact_last_name' = 'NCOMS', 'contact_phone' = '1234567890', 'title' = '@Node', 'case_history' = '@Summary', 'alt_phone_num' = '@Serial', 'msg_wait_count' = '@Serial' CONVERT TO INTEGER, 'topics_title' = '@Manager', 'creation_time' = '@LastOccurrence' CONVERT TO DATE );
In your open map you must have a field in Clarify set with the at least one of the following values:
@Serial @ServerName @ServerSerial
The two which are recommended are @ServerName and @ServerSerial. This field must match a field in the Clarify Close Map, for example:
`alt_phone_num' = `@ServerSerial + @ServerName'
The `alt_phone_num' field must match the Clarify Close Map (see the "Create Clarify Close Map" section).
The reason for this matching requirement is that when a gateway starts, its serial and case ID cache is not populated.
Therefore any close case events cannot be forwarded to Clarify without this field being set.
The Clarify update map defines the values that will be assigned to Clarify case fields when an alert is updated in the Info Server. The variable PROBLEM_NUMBER is populated with the case ID that was assigned to the case when it was created. This variable ensures that the alert is used by the Clarify writer module to update the correct case. The following shows an example mapping:
CREATE MAPPING CLARIFY_UPDATE_MAP ( 'PROBLEM_NUMBER' = PROBLEM_NUMBER, 'title' = 'This+case+has+had+its+title+updated', 'creation_time' = '@LastOccurrence' CONVERT TO DATE );
The Clarify close map is used when a case is deleted from the Info Server to close the associated Clarify case.
The following shows an example mapping:
CREATE MAPPING CLARIFY_CLOSE_MAP ( 'PROBLEM_NUMBER' = PROBLEM_NUMBER, `alt_phone_num' = `@ServerSerial + @ServerName' );
Note that the example `alt_phone_num' = `@ServerSerial + @ServerName' matches the Clarify Open Map map example (see the "Create Clarify Open Map" section).
The Clarify journal map is used to update the case history of a case when the associated alert journal is updated. The variable PROBLEM_NUMBER is populated with the case ID to ensure that the journal is added to the correct case. The JOURNAL_ENTRY variable is used to assign the new journal entry. The following shows an example mapping:
CREATE MAPPING CLARIFY_JOURNAL_MAP ( 'PROBLEM_NUMBER' = PROBLEM_NUMBER, 'title' = 'Journal', 'case_history' = JOURNAL_TEXT );
This section describes the writer attributes that are required to establish a connection between the gateway and Clarify. Some of the attributes are only required to enable Clarify cases to modify Cisco Info Center alerts, these attributes are described in the "How to Set Up a Bidirectional Clarify Gateway" section.
Table 6-6 describes the Clarify Gateway Writer attributes.
| Attribute Name | Mandatory | Description |
|---|---|---|
| Yes | Identifies the type of writer, must be set to a value of |
| Yes | Revision of writer. For this release, this must be set to a value of |
| Yes | Name of the open map. |
| Yes | Name of the update map. |
| Yes | Name of the close map. |
| Yes | Name of the journal map. |
| Yes | Name of the host server on which Clarify is running. |
| Yes | The name of the user to be used to login to Clarify. |
| Yes | The password used to login to Clarify (if one is required). Can be specified as a null. |
| Yes | The name of the Clarify database to use. |
| Yes | Name of the Info Server to which the gateway feedback mechanism writes the Clarify case ID. |
| Yes | Name of the field in the feedback Info Server alert to which the Clarify case ID is written. |
| Yes | Must have a value of |
| No | Format of date required. Defaults to |
| No | Used in bidirectional implementations. See "How to Set Up a Bidirectional Clarify Gateway". |
| Yes | Name of the conversions table in the Info Server that holds the data values of required conversions between Clarify and Cisco Info Center fields. |
| No | Used in bidirectional implementations. Refer to "How to Set Up a Bidirectional Clarify Gateway". |
| No | Used in bidirectional implementations. Refer to "How to Set Up a Bidirectional Clarify Gateway". |
| No | Used in bidirectional implementations. Refer to "How to Set Up a Bidirectional Clarify Gateway". |
| No | Used in bidirectional implementations. Refer to "How to Set Up a Bidirectional Clarify Gateway". |
| Yes | Used to select the supported Clarify database. This can be either: |
| No | Used to select the Clarify version number. This can be either |
| No | Used to specify the machine where the Echo Server is running. |
| No | Used to specify the writer port for the Echo Server. |
| No | This is the Clarify Service Release number. |
Before you run the gateway, you must create a Clarify user for the gateway. This user name must also be specified in the Clarify writer attributes section of the configuration file as the USER attribute. Refer to the Clarify documentation for more information about setting up users.
This configuration guide uses only the unidirectional architecture. The three scenarios detailed are designed to provide comprehensive examples of a typical unidirectional configuration process. It is recommended that you read these scenarios. Refer to the "Bidirectional Configuration Guide" section for Scenarios 4, 5, and 6.
Left unfiltered, the gateway will create a Clarify case from every alert passed using IDUC. An example gateway filter is shown below:
CREATE FILTER clarify AS 'ClarifyFlag = 1'; START READER SERVER_READER CONNECT TO NCOMS USING FILTER clarify;
In this scenario you will create a desktop tool that sets ClarifyFlag = 1 for selected alerts. This demonstrates how Cisco Info Center operators can create Clarify cases from Cisco Info Center alerts using the Desktop GUI.
To build the tool using the Cisco Info Center GUI:
Step 2 Select the Configuration tab.
Step 3 Select the subeventlist menu from the Menus list.
Step 4 In the Menu Items box below enter Open Case as the Title, and add the following to the Command window:
$OMNIHOME/scripts/clarify.sh @Serial
|
Note Disable Redirect Output and Redirect Errors to avoid a confirmation box appearing each time the tool is run. |
Step 5 Click Update and then Apply.
The script you need to run is shown below. Be sure to make the necessary changes to the password and ensure that it is made executable.
#!/bin/sh## Simple script to nco_sql into Netcool/OMNIbus# and set ClarifyFlag = 1.## Micromuse Plc, London.#OMNIHOME=/opt/OmnibusSERVER=NCOMSUSER=rootPASSWORD=root$OMNIHOME/bin/nco_sql -server $SERVER -user $USER -password $PASSWORD <<EOFupdate alerts.status set ClarifyFlag = 1 where Serial = $1;goEOF
|
Note Note that you can also put this script directly in the Command window. |
Step 6 To load the new tool into the desktop GUI, select Resync from the File menu (on the main event list menu).
The tool will then be available from the sub event list menu bar.
Step 7 To use the tool, highlight a Cisco Info Center alert, and select Tools and then Open Case from the menu bar.
This will execute the clarify.sh script and set ClarifyFlag =1 for that alert.
A Clarify case is created for this alert upon IDUC update.
Step 8 It is recommended that a Cisco Info Center Monitor Box for active Clarify cases is created at this point. This can be an event list filter of ClarifyFlag = 1. To create this filter, select Filters Edit from the sub event list and build a filter with the following attributes:
Name: Active Clarify Cases Condition: ClarifyFlag = 1
Step 9 Select Apply, then Close. This filter will then appear in the main event list window. Click View to launch the sub event list GUI.
Step 10 Send a few Cisco Info Center alerts to Clarify using the tool.
The Clarify API will feed back the Clarify case ID to the relevant field of the Info Center alert through the nco_crwmodule writer module.
If the gateway returns no value (reporting `Message = default' to the writer log), then there is no Clarify contact matching which is being sent by the gateway.
Step 11 Ensure that the gateway is attempting to create a case for a valid Clarify contact, otherwise no case will be created.
Step 12 You can either hard code the three required contact fields in the gateway configuration file or have the Info Server pass the field details across as @FirstName, @LastName, and @ContactNo.
Below is a hard coded example:
'contact_first_name' = 'netcool','contact_last_name' = 'omnibus','contact_phone' = '0123456789',
This configuration will only ever create cases for the Clarify contact `netcool omnibus'.
Below is a dynamic example:
'contact_first_name' = '@FirstName','contact_last_name' = '@LastName', 'contact_phone' = '@ContactName',
Step 13 If the gateway has been unable to create a case using the contact details provided, check that you have either hard coded the contact details correctly in the gateway configuration file, or are passing valid contact details from the Info Server.
You can also add the following entry in the CLARIFY_OPEN_MAP:
'RELATIONS' = 'respsvrty2gbst_elm','TARGET' = 'gbst_elm','title' = '@Severity'
This ensures that Cisco Info Center alert severity is mapped onto the equivalent Clarify Severity. For this to work correctly, you must install the conversions.clarify table. If this table is absent or incorrectly configured, Clarify cases will default to severity "Medium".
You should now be able to create Clarify cases from the Cisco Info Center desktop GUI. The case ID for each corresponding case should be fed back into the relevant field for the source Cisco Info Center alert.
In this scenario you will pass Cisco Info Center alert journal entries across the gateway to populate the case history of corresponding Clarify cases.
This operation is handled automatically by the Clarify API through the gateway writer. No further configuration is necessary. All entries made to a Cisco Info Center journal will be sent across to Clarify only after the case is created.
To pass a journal across, double-click a Cisco Info Center alert with a corresponding Clarify case and add a journal entry. This will be sent to Clarify on the next IDUC update.
Check the corresponding Clarify case history to confirm a successful entry.
If the clock time on the Cisco Info Center desktop making the journal entry is significantly different from that of the Info Server host, the journal entry made by the user may be timestamped too far behind, or too far in the future, to be picked up by the gateway. Since the gateway only picks up journal entries made since the last IDUC, it is possible that entries outside this window will be ignored. To avoid this problem, do one of the following:
Chrono entry in the `create table journal' entry in NCOMS.sql from time to timestamp. When set to timestamp, the Info Server will set all journal timestamps locally.
In this scenario you will delete a Clarify case by deleting its corresponding Cisco Info Center alert. As with journal updates, this operation is handled by the Clarify API, so no further configuration is necessary.
To demonstrate this, select a Cisco Info Center alert and delete it from the event list.
Note that deleting events can be automated using an Info Server automation such as the Generic Clear and Delete Clear automations.
This section describes how to configure Cisco Info Center and Clarify so that changes made to Clarify cases are reflected in Cisco Info Center. When you have completed the configuration described in this section, you should have a working bidirectional implementation of the gateway. Before you configure the applications, as described in this section, you should already have created a unidirectional gateway (refer to the "How to Set Up a Unidirectional Clarify Gateway").
To configure the alert modification, you need to:
1. Create Clarify business rules.
2. Configure the Action SQL.
When you have configured the business rules and the Action SQL files, you are ready to run the bidirectional Clarify gateway. Before you run the gateway, however, you should ensure that the Rules Manager and the Echo Server are running.
Each of the configuration steps is described in the following sections. Also refer to the scenarios detailed in the "Bidirectional Configuration Guide" section.
Business rules are created in Clarify to define the criteria for sending notifications to users. These business rules are also defined to send notifications to the Clarify gateway.
Business rules have to be defined for sending case information back to the Clarify reader module. All business rules can take the form of a message or a command line. The business rules that are created for the Clarify bidirectional gateway implementation use the command line notification type.
You may wish to create several business rules to suit your requirements, however, you need to create a minimum of four business rules for the type of modification to the case.
For each business rule, you need to add a command line for sending case information to the gateway.
To add the command line, you need to set up a business rule in Policies and Customers (user type), create an action within the business rule, then add a message. The command line option is added as the text message. Refer to the Clarify documentation for more information on setting up Clarify business rules.
The command line for the Clarify gateway business rules uses the nco_tcp_echo utility, which forwards the case details to the Echo Server.
The nco_tcp_echo command has the following format:
nco_tcp_echo -hostname string -writer_port numericwhere string is the name of the host machine where the Echo Server is running and numeric is the port number used to write to the Echo Server.
The command line also includes one of the following codes, which are used by the gateway to recognize the type of event:
pmo for create a case
pmc for close a case
pmu for update a case
pmj for add a case journal
pmj_NT
For each business rule command line, the following attributes are mandatory and in this order:
Current Date-Time.
The rest of the command line is completed with optional attributes for the type of information to be included in the case.
The following example shows a business rule command line:
./nco_tcp_echo -hostname darkstar -writer_port 6002 "pmu [Object ID] [Originator] [Create Date-Time] Phone=^[Current Owner Phone]^Contact=^[Contact First Name] [Contact Last Name]"From this command line, an event that is passed to the Clarify reader module would have the following format:
pmu 216 sa 10/10/96 10/12/96 Phone=0181 202 020 Contact=John Smith
The event format is then mapped, using the Action SQL, into a format that is readable by the Info Server.
An example business rule that works with the supplied pmj Action SQL template is shown below:
Start on Event: Log Note Conditions: None Message Type: Command Line Message text: ./nco_tcp_echo -hostname <gateway host> "pmj [Object ID] [Originator] [Event Date-Time] Notes added to Clarify Case by user: [Logger]\n[Addl Actlog Info]^\n** (Forwarded by Netcool/OMNIbus Gateway) **^\nCase Severity now: [Severity]"
Once it is clear that the command line testing is correct (see below for notes on setting up business rules using the Clarify GUI) this rule should be installed. This rule will ensure that the notes added to the case history through Log Note are propagated back to the Cisco Info Center alert journal.
The above example assumes that nco_tcp_echo is installed in the rules manager directory on the Clarify host. You should supply the complete path to nco_tcp_echo for your business rules.
The use of \n in the message above indicates a new line in the Cisco Info Center alert journal. This produces the following journal entry when a user logs a note to a Clarify case. Note that the Clarify UID is added:
Root : 02/10/99 20:45:08
Notes added to Clarify by user netcool:
Hello and welcome to the Clarify Gateway!
** (Forwarded by Netcool/OMNIbus Gateway) **
Case Severity now: Medium
Examine this example closely and relate it to the pmj SQL template in $OMNIHOME/gates. If you need to add or modify a business rule for pmj, ensure that you maintain a legal syntax. Assuming you now have this working, try adjusting it to suit your own requirements. Output from the CLARIF_GATE_CRW6_READ.log and the Info Server NCOMS.log will reveal any problems.
Note that the pmo, pmc, and pmu SQL templates can all be configured and tested in exactly the same manner.
To add business rules in Clarify:
Step 2 Select File and then License from the menu bar. Check the license box and click OK.
This grabs a license for the Clarify client (note that the client may be configured to grab a license automatically on startup).
Step 3 Select Apps and then Policies and Customers.
Step 4 Select Setup and then Business Rules.
This should display a list of existing business rules.
Step 5 Click New to add a new business rule.
The following example shows a sample business rule:
Name: Update Journal
Rule Set: Netcool
Description: Update Netcool Journal on Log Note
Rule Status: Active
Object Type: Case
Start on Event: Log Note
Step 6 Click Conditions.
Step 7 Click New.
Step 8 Give the action a title (for example, journal update) and click Message.
Step 9 Type the command line:
Message/Command: PATH_TO_NCO_TCP_ECHO/nco_tcp_echo -hostname <gateway host> "pmj [Object ID] [Originator] [Event Date-Time]"Note that the four parameters in quotations are mandatory and may be followed by any other Clarify information requests.
Step 10 Click Done.
Step 11 Click Save/Done.
Step 12 Click Done.
Step 13 Click Add.
Your business rule is now active.
When a modification is made to a Clarify case, the changes are reflected in the Info Server.
To determine what actions take place in the Info Server, you need to edit the action SQL files. These files are Info Server SQL-based, therefore you have all of the language facilities available to you. You must create an action SQL file for each of the event types.
The following SQL statement updates the Severity field:
update alerts.status set Severity = $(clarifyfield:Severity);
In this example, the $ represents an expansion statement and information enclosed within the parentheses must be resolved. The clarifyfield statement specifies the Clarify field. The Severity statement specifies that severity conversions must be used and applied. The colon (:) is a statement separator.
The gateway makes extensive use of certain data fields that are kept in cache storage. This ensures the unique identification of Cisco Info Center alerts at all times.
The cache fields that are always available are:
Serial ServerSerial ServerName
The open action SQL file determines what action should be taken at the Info Server when a Clarify case is opened. The following example updates the Info Server:
# Example Clarify Action SQL for the Cisco Info Center Gateway Server # # The Clarify Problem Open Action SQL File. This is executed in addition to # the problem ticket feedback. # update alerts.status set Acknowledged = 1 where Serial = $(Serial)
The close action SQL file determines what action should be taken at the Info Server when a Clarify case is closed.
The following example performs an Info Server delete.
# Example Clarify Action SQL for the Cisco Info Center Gateway Server # # Clarify Problem Close (Deletion) Action SQL. # delete from alerts.status where Serial = $(Serial);
The update action SQL file determines what action should be taken at the Info Server when a Clarify case is updated.
The following example updates the Info Server and sets a data field. The Agent field is resolved to Clarify field number 2.
# Example Clarify Action SQL for the Cisco Info Center Gateway Server # # Clarify Problem Update Action SQL. # update alerts.status set Agent = '$(2)', Severity = 0 where Serial = $(Serial);
The journal action SQL file determines what action should be taken at the Info Server when a journal is amended.
# Example Clarify Action SQL for the Cisco Info Center Gateway Server
#
# Clarify Problem Journal Action SQL.
#
insert into journal values ('$(Serial):0:$(1)', $(Serial), 0 , $(1), '$(5)','','','','','','','','','','','','','','','');
This configuration guide uses only the bidirectional architecture. The three scenarios detailed are designed to provide comprehensive examples of a typical bidirectional configuration process. It is recommended that you read these scenarios. Refer to the "Unidirectional Configuration Guide" section for Scenarios 1, 2, and 3.
In this scenario you will propagate Clarify journal updates back to the corresponding Cisco Info Center alert.
At this stage you should already have a functional unidirectional gateway. However, the SQL templates used by the gateway to perform bidirectional operations on the Info Server are already installed in $OMNIHOME/gates and will have been loaded into the gateway upon startup. To update Cisco Info Center journals, the gateway uses the pmj $OMNIHOME/gates/journal_action.clarify.sql template.
It should now be possible to test the system using nco_tcp_echo from the command line on the Clarify Server Host (refer to the "Clarify Gateway Architecture" for a description of each of the gateway components).
Send a test from the command line as follows:
./nco_tcp_echo -hostname inca2 "tcp_echo test" This sends the text message tcp_echo test to the default port (6003) on the gateway host inca2, which is being listened on by the nco_echo_server. This is effectively how business rules work. They send updates from nco_tcp_echo on the Clarify Server to the nco_echo_server, which then passes them into the gateway (on port 6002), which then in turn updates the Info Server.
The nco_echo_server server.log should report:
nco_echo_server: Accepting writer connection. nco_echo_server: Connection from <Clarify Server host> accepted
This report is confirmation that this part of the process is functional.
If there is a problem, check the following:
nco_tcp_echo correct (try the defaults to begin with)?
Assuming nco_echo_server can hear nco_tcp_echo, you can now try a bogus update from the command line. On the gateway host, run a tail -f on the CLARIF_GATE_CRW6_READ.log logfile to display the current status.
Run the following from the command line on the Clarify host:
nco_tcp_echo -hostname <hostname> "pmj <CaseID> netcool DATE TIME <message1>^ <message2>^ <message3>"Note that each message represents the value of the field.
Choose the caseID from an existing Cisco Info Center alert with a corresponding Clarify case. For example:
Make sure you use the ^ characters as these are required by the pmj SQL template example supplied. The SQL template for this example is installed in:
$OMNIHOME/gates/journal_update.clarify.sql.
You should see the alert parsed as follows in CLARIF_GATE_CRW6_READ.log:
mbuf = [pmj 229 netcool 10/03/1999 08:30:21 hello^ and welcome^ to the Clarify Gateway] Getting event type, case number, event creator, eventtime eventuser = netcool eventusrseq = 229 eventtype = pmj eventtime = 10/03/1999 08:30:21 EVENT ===== $1 = [hello] $2 = [ and welcome] $3 = [ to the Clarify Gateway] Sending event Feb 10 20:17:36 1999:[DEBUG]: Write GPC Module Component: Bytes to write 260. Sent event
Assuming there are no errors in $OMNIHOME/log/NCOMS.log, you should now have the journal entry in the corresponding Cisco Info Center alert journal.
Note the use of the ^ character in the above scenario. This has the effect of breaking the message up into tokens ($) ready for the SQL statement used by pmj. The assignment of these tokens is as follows in the above example:
echo_server_value = SQL statement:
eventtime = $1
$1 = $1
$2 = $2
$3 = $3
If the nco_echo_server to SQL statement mapping is incorrect, the journal insert will fail. Refer to the Info Server logfile for error messages.
This is very similar to the pmj journal update, but it uses the supplied pmu SQL template to update Cisco Info Center severity from Clarify severity. This can be used as an additional action fired by a given condition. For example, an operator logs a note, then fires pmj and pmu to update the journal along with severity.
First, ensure that you have the following clarify.conversions table in your Info Server.
# more /opt/Omnibus/db/NCOMS.conversions.clarify.dat use database conversions; insert into clarify values ( 'Severity0','Severity','0','Clear' ); insert into clarify values ( 'Severity1','Severity','1','No Rush' ); insert into clarify values ( 'Severity2','Severity','2','Low' ); insert into clarify values ( 'Severity3','Severity','3','Medium' ); insert into clarify values ( 'Severity4','Severity','4','High' ); insert into clarify values ( 'Severity5','Severity','5','Urgent' ); set recovery_sequence for clarify to 0; -- DO NOT CHANGE OR REMOVE THIS LINE !
The conversions table is used to convert Clarify severity to Cisco Info Center severity and Cisco Info Center severity to Clarify severity. The Clarify Severity is in the right hand column. The listing above uses the default Clarify 6.0 severities.
The supplied pmu SQL template is as follows:
# # Example Clarify Action SQL for the Netcool/OMNIbus Gateway Server # # Clarify Problem Update Action SQL. # update alerts.status set Severity = $(1:Severity) where Serial = $(Serial);
The $(1:Severity) entry instructs the gateway to grab token1 from the pmu message and perform a severity conversion according to the conversions.clarify table.
As with the journal updates, it is now possible to test this from the command line. Using the example above, the following statement would update a corresponding Cisco Info Center alert to severity 5 (Critical) in the event list.
./nco_tcp_echo -hostname inca2 "pmu 306 netcool 02/12/99 13:42:31 Urgent^"
This will appear as follows in the reader module logfile:
mbuf = [pmu 306 netcool 02/12/99 13:42:31 Urgent^ ] Getting event type, case number, event creator, eventtime eventuser = netcool eventusrseq = 306 eventtype = pmu eventtime = 02/12/99 13:42:31 EVENT ===== $1 = [Urgent] Sending event
In the CLARIF_GATE.log file the gateway resolves the conversion serial number and performs the SQL update on the Info Server. The corresponding Cisco Info Center alert will now show up as red (Critical):
Feb 12 13:51:32 1999: CLARIF_GATE :Debug: Clarify Writer: Read GPC Module Component: Bytes to read 209. Feb 12 13:51:32 1999: CLARIF_GATE :Debug: Urgent^ Feb 12 13:51:32 1999: CLARIF_GATE :Debug: pmu | netcool Feb 12 13:51:32 1999: CLARIF_GATE :Debug: Update = update alerts.status set Severity = $(1:Severity) where Serial = $(Serial); Feb 12 13:51:32 1999: CLARIF_GATE :Debug: Prob_num = 306 Feb 12 13:51:32 1999: CLARIF_GATE :Debug: Item wasn't null Feb 12 13:51:32 1999: CLARIF_GATE :Debug: Clarify Writer: FEEDBACK Command: [update alerts.status set Severity = 5 where Serial = 2466;]
Detailed below is an example of a business rule:
Start on Event: Log Note Type: Command Line: Message: ./nco_tcp_echo -hostname <gateway host> "pmu [Object ID] [Originator] [Current Date-Time] [Severity]^"
Since you can use multiple actions in Clarify from a single condition, you can associate this update with other actions, for example:
Condition: Log note Actions: Update journal (pmj), Update severity (pmu)
If you now change the severity of a Clarify case, log a Log note and select Save. The corresponding Cisco Info Center alert will receive a journal update along with an update of severity.
This is very similar to the pmu severity update above, but uses the supplied pmc SQL template to delete corresponding Cisco Info Center alerts upon case close. Assuming you have installed the distribution from the supplied tar file, the SQL template is already loaded into the gateway ($OMNIHOME/gates/close_action.clarify.sql). You need to add the business rule in Clarify.
The supplied pmc SQL template is as follows:
# Example Clarify Action SQL for the Netcool/OMNIbus Gateway Server # Clarify Problem Close (Deletion) Action SQL. # delete from alerts.status where Serial = $(Serial);
To delete the corresponding Cisco Info Center alert on case close, add the following business rule in Clarify:
Start on Event: Close Task Type: Command Line: Message: ./nco_tcp_echo -hostname <gateway host> "pmc [Object ID] [Originator] [Current Date-Time] "
This will pass the case ID to the pmc template in the gateway, and the corresponding Cisco Info Center alert will be deleted.
Test the Clarify to Cisco Info Center communications first with nco_tcp_echo from the command line. If you run a tail -f on the READ module logfile and CLARIF_GATE you can see the progress of the update as it travels through the gateway. The sequence of flow is:
Rule Manager > nco_tcp_echo > nco_crwmodule READER > nco_gate > Info Server.
The READ module log will inform you if you have tokenized the update properly, and the gateway will inform you if it has suffered any problems parsing or consolidating the SQL statement. Incorrect SQL will also be reported to the Info Server logfile. The logfile examples used in this document show you what the logs will display when the gateway is operating in the correct manner.
|
Note Since the SQL templates are only loaded into the gateway upon gateway initialization, you need to restart the gateway after making changes to the template syntax. |
Once there is bidirectional communications up and running, take the gateway out of debug mode and put it under PA along with other local Cisco Info Center components, such as Info Server or probes.
The configuration detailed in this document is designed to provide a framework for further development. The gateway is capable of performing complex operations on Clarify over the API.
This section describes the command line options for the nco_tcp_echo command and the Echo Server (nco_echo_server).
The nco_tcp_echo command has the following format:
nco_tcp_echo -hostname string -writer_port numeric -help
| Option | Parameter | Description |
|---|---|---|
hostname | string | The name of the host machine where the Echo Server is running. |
writer_port | numeric | The port number to write to the Echo Server. |
help |
| Displays help on the command line options. |
The nco_echo_server command has the following format:
nco_echo_server -messagelog string -reader_port numeric -writer_port numeric
| Option | Parameter | Description |
|---|---|---|
| string | The name of a file to which all output messages are written. |
| numeric | The port number used by nco_tcp_echo. |
| numeric | The port number for the gateway. This is specified in the writer module attributes (TCP_PORT). |
|
| Displays help on the command line options. |
This section shows a complete Clarify configuration file, clarify.conf.
# Example Clarify configuration for the Cisco Ijfo Gateway Server
#
# Ident: $Id: clarify.conf 1.6 1997/08/28 15:44:04 adam Release $
#
# Start up the reader - connect to the Object Server CLARIFY
#
# This example uses no filtering.
#
START READER SERVER_READER CONNECT TO NCOMS;
#
# Create a mapping from the Info Server's fields into Clarify fields
#
CREATE MAPPING CLARIFY_OPEN_MAP
(
#
# The next three fields are important. They will link the case to
# a contact within Clarify. Either use them or the following 'serial_no'
# field.
#
'contact_first_name' = '@Node',
'contact_last_name' = '@Manager',
'contact_phone' = '68564',
#
# The 'serial_no' refers to the serial number associated with the
# part, which has a contact associated with it.
#
'serial_no' = '@Serial',
#
# All of the next fields are optional, for more fields look in the
# Clarify Database and Data Dictionary Guide.
#
'title' = '@Severity + @LastOccurrence^ + @Node',
'modify_stmp' = '@LastOccurrence' CONVERT TO DATE,
#
# Note that the alt_phone_num has been set here for reference later by the
# close map.
#
'alt_phone_num' = '@ServerSerial + @ServerName + Gateway',
'topics_title' = '@Manager',
'creation_time' = '@LastOccurrence' CONVERT TO DATE,
#
# All of the fields starting 'x_nco_' cannot be used unless they have
# been put into the Clarify database
#
# 'x_nco_node' = '@Node',
# 'x_nco_nodealias' = '@NodeAlias',
# 'x_nco_manager' = '@Manager',
# 'x_nco_agent' = '@Agent',
# 'x_nco_alertgroup' = '@AlertGroup',
# 'x_nco_alertkey' = '@Alertkey',
# 'x_nco_severity' = '@Severity' CONVERT TO INTEGER,
# 'x_nco_sort' = '@Severity' CONVERT TO INTEGER,
# 'x_nco_zero' = '@Severity' CONVERT TO INTEGER
# 'x_nco_summary' = '@Summary',
# 'x_nco_statechange' = '@StateChange' CONVERT TO DATE,
# 'x_nco_first_occur' = '@FirstOccurrence' CONVERT TO DATE,
# 'x_nco_last_occur' = '@LastOccurrence' CONVERT TO DATE,
# 'x_nco_internallast' = '@InternalLast' CONVERT TO DATE,
# 'x_nco_poll' = '@Poll',
# 'x_nco_type' = '@Type',
# 'x_nco_tally' = '@Tally',
# 'x_nco_class' = '@Class',
# 'x_nco_grade' = '@Grade',
# 'x_nco_location' = '@Location',
# 'x_nco_owneruid' = '@OwnerUID',
# 'x_nco_ownergid' = '@OwnerGID',
# 'x_nco_acknowledged' = '@Acknowledged',
# 'x_nco_flash' = '@Flash',
# 'x_nco_servername' = '@ServerName',
# 'x_nco_serverserial' = '@ServerSerial'
#
# For information about setting RELATIONS and ACTIONS check the
# documentation and the Clarify Database and Data Dictionary Guide.
#
# THESE ARE EXAMPLE RELATIONS
#
'RELATIONS' = 'case_prevq2queue',
'TARGET' = 'queue',
'title' = 'The + New + Gateway + Queue',
'RELATIONS' = 'act_entry2case',
'SOURCE' = 'act_entry',
'act_code' = '68564',
#
# In order to Dispatch a case to a queue automatically, the next
# relation and action are required.
#
'RELATIONS' = 'case_currq2queue',
'TARGET' = 'queue',
'ACTION' = 'Dispatch',
'title' = 'The + old + Gateway + queue',
'RELATIONS' = 'case_notes2case',
'SOURCE' = 'notes_log',
'creation_time' = '@LastOccurrence' CONVERT TO DATE,
'description' = 'Alert + acknowledged',
'RELATIONS' = 'case_soln2workaround',
'TARGET' = 'workaround',
'objid' = '268435457',
'RELATIONS' = 'respprty2gbst_elm',
'TARGET' = 'gbst_elm',
'title' = '@Priority',
'RELATIONS' = 'respsvrty2gbst_elm',
'TARGET' = 'gbst_elm',
'title' = '@Severity',
'RELATIONS' = 'case_wip2wipbin',
'TARGET' = 'wipbin',
'title' = 'Omnibus',
'RELATIONS' = 'case_logic2prog_logic',
'TARGET' = 'prog_logic',
'creation_time' = '@LastOccurrence' CONVERT TO DATE,
'RELATIONS' = 'case_owner2user',
'TARGET' = 'user',
'login_name' = 'netcool',
'RELATIONS' = 'case_originator2user',
'TARGET' = 'user',
'login_name' = 'netcool',
'RELATIONS' = 'case_empl2employee',
'TARGET' = 'employee',
'first_name' = '@Node',
'RELATIONS' = 'calltype2gbst_elm',
'TARGET' = 'gbst_elm',
'title' = 'Reopen Part Request',
'RELATIONS' = 'respprty2gbst_elm',
'TARGET' = 'gbst_elm',
'title' = 'Reopen Part Request',
'RELATIONS' = 'respsvrty2gbst_elm',
'TARGET' = 'gbst_elm',
'title' = 'Reopen Part Request',
'RELATIONS' = 'case_prod2site_part',
'TARGET' = 'site_part',
'serial_no' = '68564',
'RELATIONS' = 'case_reporter2site',
'TARGET' = 'site',
'name' = 'Main + Office',
'RELATIONS' = 'case_reporter2contact',
'TARGET' = 'contact',
'first_name' = '@Node',
'RELATIONS' = 'entitlement2contract',
'TARGET' = 'contract',
'type' = 'netcool',
'RELATIONS' = 'casests2gbst_elm',
'TARGET' = 'gbst_elm',
'title' = 'Reopen Part Request',
'RELATIONS' = 'case_rip2ripbin',
'TARGET' = 'ripbin',
'title' = 'RIPbin',
'RELATIONS' = 'covrd_ppi2site_part',
'TARGET' = 'site_part',
'serial_no' = '68564',
'RELATIONS' = 'case_view2monitor',
'TARGET' = 'monitor',
'title' = 'netcool',
'RELATIONS' = 'case_distr2site',
'TARGET' = 'site',
'name' = 'Main + Office',
'RELATIONS' = 'case2keyphrase',
'TARGET' = 'keyphrase',
'objid' = '1',
'RELATIONS' = 'case2address',
'TARGET' = 'address',
'address' = '111 + Main + Street',
'RELATIONS' = 'case_node2site_part',
'TARGET' = 'site_part',
'objid' = '@Serial',
'RELATIONS' = 'de_product2site_part',
'TARGET' = 'site_part',
'objid' = '@Serial',
'RELATIONS' = 'case_prt2part_info',
'TARGET' = 'mod_level',
'mod_level' = 'Active',
'RELATIONS' = 'de_prt2part_info',
'TARGET' = 'mod_level',
'mod_level' = 'Active',
'RELATIONS' = 'alt_contact2contact',
'TARGET' = 'contact',
'first_name' = '@Node',
'RELATIONS' = 'case2part_event',
'TARGET' = 'part_event',
'rpt_event_gid' = '3767464',
'RELATIONS' = 'task2opportunity',
'TARGET' = 'opportunity',
'id' = '7777',
'RELATIONS' = 'case2life_cycle',
'TARGET' = 'life_cycle',
'appl_id' = 'Amazed',
'RELATIONS' = 'case_victim2case',
'TARGET' = 'case',
'id_number' = '393',
'RELATIONS' = 'entitle2contr_itm',
'TARGET' = 'contr_itm',
'quantity' = '12'
);
CREATE MAPPING CLARIFY_UPDATE_MAP
(
#
# The PROBLEM_NUMBER field is essential
#
'PROBLEM_NUMBER'= PROBLEM_NUMBER,
'title' = '@Summary + opened + by + @Manager + updated + at +
@LastOccurrence',
'modify_stmp' = '@LastOccurrence' CONVERT TO DATE,
#
# You can also change relations in the update map.
#
'RELATIONS' = 'case_reporter2site',
'TARGET' = 'site',
'site_id' = '7',
'RELATIONS' = 'respprty2gbst_elm',
'TARGET' = 'gbst_elm',
'title' = '@Priority',
'RELATIONS' = 'respsvrty2gbst_elm',
'TARGET' = 'gbst_elm',
'title' = '@Severity'
);
CREATE MAPPING CLARIFY_CLOSE_MAP
(
#
# The PROBLEM_NUMBER field should be set and whatever field
# was set in the OPEN_MAP to save the ServerSerial/ServerName or
# Serial values.
#
# 'PROBLEM_NUMBER' = PROBLEM_NUMBER,
'alt_phone_num' = '@ServerSerial + @ServerName + Gateway',
'RESOLUTION' = 'Resolution + Given'
);
CREATE MAPPING CLARIFY_JOURNAL_MAP
(
#
# The PROBLEM_NUMBER and JOURNAL_TEXT fields are essential
#
'PROBLEM_NUMBER' = PROBLEM_NUMBER,
'JOURNAL_TEXT' = 'JOURNAL_TEXT + @UID '
);
#
# Start up the writer
#
START WRITER CLARIFY_WRITE
(
TYPE = CLARIFY,
REVISION = 1,
CLARIFY_VERSION = 6,
DATABASE_TYPE = 'sybase',
DATE_FORMAT = '%d/%m/%Y %H:%M:%S',
#
# These maps have been defined above
#
OPEN_MAP = CLARIFY_OPEN_MAP,
UPDATE_MAP = CLARIFY_UPDATE_MAP,
CLOSE_MAP = CLARIFY_CLOSE_MAP,
JOURNAL_MAP = CLARIFY_JOURNAL_MAP,
#
# Information for logging into Clarify
#
CLARIFY_SERVER = 'MARIO',
DATABASE = 'clarify6',
USER = 'sa',
PASSWORD = 'sasasa',
#
# The READER_USER and READER_PASSWORD are for NT Bidirectional
# purposes only.
#
# READER_USER = 'Peter',
# READER_PASSWORD = 'Piper',
#
# Information for the bidirectional side
#
FEEDBACK_SERVER = 'NCOMS',
FEEDBACK_FIELD = 'Location',
COUNTERPART = SERVER_READER,
#
# The IP_ADDRESS and TCP_PORT are required for the nco_echo_server
# connection.
#
IP_ADDRESS = '127.0.0.1',
TCP_PORT = '6002',
CONVERSIONS_TABLE = 'conversions.clarify',
#
# The sql files are used by the bidirectional side of the gateway.
# They determine what actions the Gateway will perform with the
# incoming Clarify event.
#
OPEN_ACTION_SQL = '/opt/Omnibus/gates/open_action.clarify.sql',
UPDATE_ACTION_SQL = '/opt/Omnibus/gates/update_action.clarify.sql',
CLOSE_ACTION_SQL = '/opt/Omnibus/gates/close_action.clarify.sql',
JOURNAL_ACTION_SQL = '/opt/Omnibus/gates/journal_action.clarify.sql',
#
# CLOSE_PROBLEMS will determine whether the corresponding case is closed when
# a netcool event is deleted.
#
CLOSE_PROBLEMS = TRUE,
#
# DEFAULT_CODE is the message that is returned when a case fails to be created.
# The default message is 'default'.
#
DEFAULT_CODE = 'Failed + to + create + case'
);
#
# Add a route from the reader to the writer so the info gets passed
#
ADD ROUTE FROM SERVER_READER TO CLARIFY_WRITE;
#
# End of file
#
|
Note For details on how to create gateway conversions for alphabetic and numeric values refer to the "Creating the Clarify Gateway Configuration" section. |
The Remedy ARS (Action Request System) allows alerts to become help desk trouble tickets in Remedy ARS. When a route is established between a Cisco Info Server Reader and an ARS Writer, new alerts become trouble tickets in the AR system and the trouble tickets are updated, according to the mapping, throughout the life-span of the alert.
The Remedy ARS Writer is compatible with the Remedy ARS 2.x and above versions of Remedy ARS.
Before using the ARS Writer, it is necessary to import a schema into the running Remedy ARS. This schema then acts as the schema where new alerts become trouble tickets. It is possible to configure the Cisco Info Gateway to write into any schema by modifying the standard mapping, but for simplicity, it is easiest to allow it to write into the supplied schema and use Remedy ARS's active link and filter facilities to despatch the new trouble tickets to the help desk.
The Remedy ARS supports the importing of schemas and a pre-configured schema is supplied in the $OMNIHOME/gates/alerts.schema file. Use this file with the import schema in the ARS Administration tool. This creates a new schema called "Omnibus 3.3" in the ARS.
Having a separate user enables the gateway to track changes made to trouble tickets that it created. Using its own login the gateway can determine whether a change made to a ticket that it created was made by the gateway itself, or by a third party. This enables the gateway to determine what changes need to be passed back from the Remedy system to the original alert.
To make the configuration of the Remedy gateway more simple, the gateway is supplied with an example schema and associated filters. The schema is stored in:
$OMNIHOME/gates/remedy/omnibus.schema
Import the example schema and filters into the Remedy server. The filters provide part of the Remedy-to-Cisco Info Center feedback, which passes through the notification server. These filters which are attached to the imported schema, reference the user Omnibus, and generate update and close notifications for changes to trouble tickets created by the gateway itself.
|
Note The gateway assumes that the notification server is running on the same machine as the Remedy server. |
Once you have imported your schema, you can modify the filters through the Modify Filter window of the Remedy administration tool. You may also need to modify the action SQL files, as described in the "Action SQL Files" section.
An example of the notification message format is:
[<TYPE>][$Last-modified-by$] <attr_1>=<value_1> ... <attr_n>=<value_n>
where TYPE is either M for Modification (Update), or C for Close event.
The attribute value pairs are named values that can be referenced in the action SQL files as specific values you want to be updated in the alert within the Info Server. For example:
Node = $Node
where Node contains the value of the $Node field within the Remedy schema. This means that when you refer to $(Node) in the action SQL files you get the correct value.
You could use Name = $Node and reference to the Node value in the action SQL files as $(Name). As shown in the examples below, either the name or the value can be string quoted to ensure that the complete value is extracted for either the name or the value. This is because a space is a delimiter character. If a space appears in the value, you will need use string quotes. For example:
First="$FirstOccurance$"
This ensures that the complete date is the value of the name First.
The example update filter is:
[M][$Last-modified-by$] "Node" = "$Node$" Serial =$Serial$ First="$FirstOccurance$" Tally= $Tally$ Static="hello \"\\\\" Last=$Last-modified-by$ User=$OwnerUID$ Agent="$Agent$" User=$USER$
The example close filter is:
[C][$Last-modified-by$] Node ="$Node$" Serial= $Serial$ First="$FirstOccurance$" Last=$Last-modified-by$
There are two action SQL files. They define how the gateway should handle a closed or updated Remedy alert. Any changes you make to the default filters may need to be reflected in these files. An example update action SQL file is shown below:
# # Example Remedy Action SQL for the Gateway Server # # Remedy Problem Update Action SQL. # update alerts.status set NodeAlias='$(Last)',Agent='$(Agent)' where Serial = $(Serial);
An example close action SQL file is shown below:
# # Example Remedy Action SQL for the Gateway Server # # Remedy Problem Close (Deletion) Action SQL. # delete from alerts.status where Serial = '$(Serial)';
Mappings for use with the Remedy ARS Writer must use this syntax:
CREATE MAPPING <mappingname> ( <ARSFieldId> = '@<fieldname>' [ON INSERT ONLY] [CONVERT TO type] [ , <ARSFieldId> = '@<fieldname>' [ON INSERT ONLY] [CONVERT TO type]]... ) ;
where:
The optional ON INSERT ONLY controls the updating of the field during the life of the alert; when omitted, the field is updated for any change in the state of the alert. When included, the field is only set when the alert is created.
Note, you cannot use ON INSERT ONLY with the following fields:
When you use ON INSERT ONLY with these fields, the Cisco Info Gateway does not work.
The optional CONVERT TO type allows the mapping to define a forced conversion for situations where a source field may not match the type of the destination field. type can be INTEGER, STRING, or DATE to force the source field to be converted to an integer, string, or date type.
The Writer must pass across serial and severity fields to ARS to function correctly.
The default mapping as supplied in the $OMNIHOME/gates/ars.conf file is designed for the supplied schema in $OMNIHOME/gates/ars.schema.
CREATE MAPPING ARS_MAP(536870914 = '@Identifier' ON INSERT ONLY,536870913 = '@Serial' ON INSERT ONLY,536870944 = '@Node' ON INSERT ONLY,536870915 = '@NodeAlias' ON INSERT ONLY,536870932 = '@Manager' ON INSERT ONLY,536870939 = '@Agent' ON INSERT ONLY,536870918 = '@AlertGroup' ON INSERT ONLY,536870931 = '@AlertKey' ON INSERT ONLY,7 = '@Severity',536870916 = '@Summary' ON INSERT ONLY,536870946 = '@StateChange',536870912 = '@FirstOccurrence' ON INSERT ONLY,536870917 = '@LastOccurrence',536870935 = '@InternalLast',536870938 = '@Poll' ON INSERT ONLY,536870941 = '@Type' ON INSERT ONLY,536870940 = '@Tally',536870945 = '@Class' ON INSERT ONLY,536870942 = '@Grade' ON INSERT ONLY,536870934 = '@Location' ON INSERT ONLY,536870933 = '@Acknowledged');
The integer value is the Remedy ARS field identifier. Most fields are written to specially defined records within the schema, with the exception of Severity (written to the ARS core field Status) and Summary (written to the ARS core field Short Description). The Severity, InternalLast, StateChange, Tally, and Acknowledged fields are updated in the trouble ticket as the alert is updated.
The string value must currently be set to @fieldname values which refer to fields in the alerts.status table.
The creation of a Writer for Remedy ARS requires the attributes described in Table 6-9.
| Attribute Name | Description |
|---|---|
| Type of Writer; must have a mandatory value of ARS. |
| Revision of Writer; must have a mandatory value of 1. |
| Map file for the Writer to use. |
| Name of server where the Remedy ARS is running. |
| Name of schema in Remedy ARS where the Writer should generate trouble tickets using the specified map file. |
| Name of Remedy ARS user to be used to submit and update alerts to the ARS system. |
| Password of user specified in the |
| ID number of the Journal field in the ARS schema. |
| Set to TRUE, activates the feedback mechanism (requires |
| Name of Cisco Info Server where the feedback mechanism should write the trouble ticket number. |
| Name of field in |
The feedback mechanism allows for the trouble ticket number to be written back into the alert's entry in the Cisco Info Server. This allows for better coordination between users of Cisco Info Center and the Remedy ARS system.
The example configuration contains the following configuration for an ARS Writer:
START WRITER ARS_WRITER(TYPE = ARS,REVISION = 1,MAP = ARS_MAP,SERVER = 'orac',SCHEMA = 'Omnibus 3.3',USER = 'Demo',PASSWORD = '',FEEDBACK = TRUE,FEEDBACK_SERVER = NCOMS,FEEDBACK_FIELD = 'Location');
This example creates a Writer, using the map on page 39, which logs into the Remedy ARS, as a user called Demo with no password, to create alerts. When alerts are created, the feedback settings indicate that the trouble ticket number allocated is written to an Cisco Info Server named NCOMS and into a field in the alerts.status table named Location.
When using a filter with an Cisco Info Gateway, existing alerts that are excluded by the Cisco Info Gateway do not have a trouble ticket. When the alert changes and is no longer excluded by the filter, the Cisco Info Gateway creates a new trouble ticket.
The flat file Writer allows alerts to be written into a flat file. You can configure the format of the file using the Writer attributes.
Mappings for use with the flat file Writer must be in the following format:
CREATE MAPPING<mappingname> ( '' = '@<fieldname>'[ON INSERT ONLY],[ , ''= '@<fieldname>'[ON INSERT ONLY]]... ) ;
Where <mappingname> is the name of the mapping to be created.
<fieldname> must be the name of a field in the Cisco Info Server alerts.status table.
The optional ON INSERT ONLY controls the updating of the field during the life of the alert; when omitted, the field is updated for any change in the state of the alert. When included, the field is only set when the alert is created.
CREATE MAPPING SERVER_MAP('Identifier' = '@Identifier', ON INSERT ONLY,'Node' ='@Node', ON INSERT ONLY,'NodeAlias' = '@NodeAlias', ON INSERT ONLY,'Manager' = '@Manager', ON INSERT ONLY,'Agent' = '@Agent' ON INSERT ONLY,'AlertGroup' = '@AlertGroup' ON INSERT ONLY,'AlertKey' = '@AlertKey' ON INSERT ONLY,'Severity' = '@Severity' ON INSERT ONLY,'Summary' = '@Summary' ON INSERT ONLY,'StateChange' = '@StateChange' ON INSERT ONLY,'FirstOccurrence' = '@FirstOccurrence ON INSERT ONLY,'LastOccurrence' = '@LastOccurrence ON INSERT ONLY,'InternalLast' = '@InternalLast' ON INSERT ONLY,'Poll' = '@Poll' ON INSERT ONLY,'Type' = '@Type' ON INSERT ONLY,'Tally' = '@Tally' ON INSERT ONLY,'Class' = '@Class' ON INSERT ONLY,'Grade' = '@Grade' ON INSERT ONLY,'Location' = '@Location' ON INSERT ONLY,'OwnerUID' = '@OwnerUID' ON INSERT ONLY,'Acknowledged' = '@Acknowledged' ON INSERT ONLY,'ServerSerial' = '@ServerSerial' ON INSERT ONLY,);
The creation of a Writer for Flat File requires the attributes described in Table 6-10.
| Attribute Name | Description |
|---|---|
| Type of Writer; must have a mandatory value of FILE. |
| The name of the file to write to. |
| The version number of the Writer. Should be 1. |
| Should the file be truncated on startup, or should the Writer continue to append to the end of the file. The default is: |
| Synchronous write. The default is: |
| File permissions. The default is: |
| The name of the mapping to use. |
| When the field is a string, the value of this attribute is prepended to the field before it is written to the file. The default is: ". |
| When the field is a string, the value of this attribute is append to the field before it is written to the file. The default is: ". |
| The value of this attribute is inserted between the fields written to the file. The default is: |. |
| The value of this attribute is prepended to each insert alert written to the file. The default is: ' |
| The value of this attribute is appended to each insert alert written to the file. The default is: ' |
| The value of this attribute is prepended to each update alert written to the file. The default is: ' |
| The value of this attribute is appended to each update alert written to the file. The default is: |
| The value of this attribute is prepended to each delete alert written to the file. The default is: |
| The value of this attribute is appended to each delete alert written to the file. The default is: |
| The format to use for any date fields written to the file. The default is: |
START WRITER REMOTE_WRITER(TYPE = FILE,REVISION = 1,FILE = '/opt/Omnibus/log/gates.outTRUNCATE = TRUE,SYNC = FALSE,MODE = 0644MAP = SERVER_MAP,START_STRING = '"',END_STRING = '"',SEPERATOR = '|'INSERT_HEADER = '\nStart of insert line\n',INSERT_TRAILER = '\nStart of insert line\n',UPDATE_HEADER = '\nStart of update line\n',UPDATE_TRAILER = '\nStart of update line\n',DELETE_HEADER = '\nStart of delete line\n',DELETE_TRAILER = '\nStart of delete line\n',DATE_FORMAT = '%C');
The Informix Writer creates a single table of all transactions that have occurred within the alerts selected by a Cisco Info Server Reader. When a route is created between a Cisco Info Server Reader and an Informix Writer, for each change made to any record in the Cisco Info Server, a new record is created in the Informix database in a specified table. This can also include an action type (insert, update, or delete) and an action time. Reporting tools can be applied on the destination table to produce an audit trail.
The Informix Writer is compatible with the following versions of Informix:
Before running the Informix Writer, you must create tables in the Informix database for the alerts to be written into. A script (infoinstall) has been provided to do this automatically. Note, you must run the Cisco Info Gateway and the script as a user who is a member of the informix user group, otherwise the Cisco Info Gateway is denied access to the Informix database.
To run the script, specify:
host% $OMNIHOME/gates/infoinstallThe script executes Informix SQL statements to create and configure the necessary tables using a default template (INFORMIX.SQL). As the script is executed, you are prompted to specify names for the status, journal and details tables.
Mappings for use with the Informix Writer must be in the following format:
CREATE MAPPING<mappingname> ( <InformixFieldName> = [ '@<fieldname>' | <special_value>][CONVERT TO type][ , <InformixFieldName> = [ '@<fieldname>' | <special_value>]
[CONVERT TO type]]... ) ;
where
is the name of the mapping to be created
The keywords are:
| The type of action occurring on the alert. Values are I for Insert, U for Update, D for Delete. |
| The time the action occurred. See "Time Handling Between the Cisco Info Gateway and Informix" section for details about time and date handling within the Cisco Info Gateway. |
The optional CONVERT TO type allows the mapping to define a forced conversion for situations where a source field may not match the type of the destination field. The type value can be INTEGER, STRING, or DATE to force the source field to be converted to an integer, string, or date type. This is particularly relevant when adding extra time fields in the Cisco Info Server to map to Informix. See the "Time Handling Between the Cisco Info Gateway and Informix" section for more information.
|
Note The ordering of the fields in the mapping must exactly match the ordering of the fields in the Informix table being written to. When this is not the case, values are written to incorrect fields. |
The default mapping as supplied in the $OMNIHOME/gates/informix.conf file is designed for the supplied database/table created by the $OMNIHOME/gates/infoinstall script. The following example shows the default mapping:
CREATE MAPPING Informix_MAP('ActionTime' = ACTION_TIME,'ActionCode' = ACTION_CODE,'Identifier' = '@Identifier','Serial' = '@Serial','Node' = '@Node','NodeAlias' = '@NodeAlias','Manager' = '@Manager','Agent' = '@Agent','AlertGroup' = '@AlertGroup','AlertKey' = '@AlertKey','Severity' = '@Severity','Summary' = '@Summary','StateChange' = '@StateChange' CONVERT TO DATE,'FirstOccurrence' = '@FirstOccurrence' CONVERT TO DATE,'LastOccurrence' = '@LastOccurrence' CONVERT TO DATE,'InternalLast' = '@InternalLast' CONVERT TO DATE,'Poll' = '@Poll','Type' = '@Type','Tally' = '@Tally','Class' = '@Class','Grade' = '@Grade','Location' = '@Location','OwnerUID' = '@OwnerUID','Acknowledged' = '@Acknowledged','ServerName' = '@ServerName');
Note the use of CONVERT TO DATE; this usage is mandatory for these fields.
The creation of a Writer for an Informix database requires the attributes described in Table 6-12.
| Attribute Name | Description |
|---|---|
| Type of Writer; must have a mandatory value of |
| Revision of Writer; must have a mandatory value of 1. |
| Name of mapping for Writer to use. |
| Optional: Should deletes be forwarded. The default is YES/TRUE. When set to NO/FALSE, no |
| Optional: Should inserts be forwarded. The default is YES/TRUE. When set to NO/FALSE, no ACTION_CODE I (inserts) appear in the Informix table. |
| Optional: Should updates be forwarded. The default is YES/TRUE. When set to NO/FALSE, no |
| Name of the status table. The default is: |
| Name of the journal table. The default is: |
| Name of the details table. The default is: |
| Name of the database table. The default is: |
| Specifies whether to use transactions or not. The default is: |
| The name of the Informix server. |
| Enables store and forward mode. Can be set to |
| Specifies the file to store alerts in when the gateway is in store mode. The default file is |
The following example shows a possible configuration for an Informix Writer:
START WRITER Informix_WRITE(TYPE = Informix,REVISION = 1,MAP = Informix_MAP,FORWARD_DELETES = TRUE,FORWARD_UPDATES = FALSE,FORWARD_INSERTS = FALSE,STATUS_TABLE = 'status',JOURNAL_TABLE = 'journal',DETAILS_TABLE = 'details',DATABASE = 'alerts'HAS_TRANSACTIONS = FALSE,INFORMIX_SERVER = 'DB_SERVER1'STORE_AND_FORWARD = FALSE, STORE_FILE = $OMNIHOME/var/<server>_<writer>.store);
This example creates a Writer which forwards deleted alerts to the Informix server DB_SERVER1 using the map defined in Informix_MAP.
The host running the Cisco Info Gateway must be able to connect to either a local or a remote Informix server. If the server is not local to the host running the Cisco Info Gateway, you must add the necessary definitions to:
Ask your Informix administrator to do this for you.
Date/time fields are stored as an integer within the Cisco Info Center Cisco Info Server. This means that when a date/time field is to be mapped, it must be followed by the CONVERT TO DATE modifier.
CONVERT TO DATE forces the value to be internally printed in a format specified by the Writer attribute DATE_FORMAT. This string is then sent to Informix where it is assumed the destination field is a datetime type field; when this is true, the string is then converted into Informix's internal datetime format. When the destination field is a string field, a string representation of the date is inserted. When the destination field is an integer, the entire insert for the alert fails.
The DATE_FORMAT defaults to: %B %d, %Y %I:%M:%S%p. Details of this format are available by examining the manual page for the strftime call (man strftime). The default format is appropriate for english (C) locales but is inappropriate for other locales and must be overridden to the appropriate format for that locale.
The Socket Writer forwards alerts to a remote TCP socket. Any process listening to that socket receives the alerts.
Mappings for use with the Socket Writer must be in the following format:
CREATE MAPPING<mappingname> ( '' = '@<fieldname>'[ON INSERT ONLY],[,'='@<fieldname>'[ON INSERT ONLY]]... );
where <mappingname> is the name of the mapping to be created and <fieldname> is the name of a field in the Cisco Info Server alerts.status table.
The optional ON INSERT ONLY controls the updating of the field during the life of the alert; when omitted, the field is updated for any change in the state of the alert. When included, the field is only set when the alert is created.
CREATE MAPPING SERVER_MAP('Identifier' = '@Identifier', ON INSERT ONLY,'Serial' = '@Serial', ON INSERT ONLY,'Node' = '@Node', ON INSERT ONLY,'NodeAlias' = '@NodeAlias', ON INSERT ONLY,'Manager' = '@Manager', ON INSERT ONLY,'Agent' = '@Agent' ON INSERT ONLY,'AlertGroup' = '@AlertGroup' ON INSERT ONLY,'AlertKey' = '@AlertKey' ON INSERT ONLY,'Severity' = '@Severity' ON INSERT ONLY,'Summary' = '@Summary' ON INSERT ONLY,'StateChange' = '@StateChange' ON INSERT ONLY,'FirstOccurrence' = '@FirstOccurrence ON INSERT ONLY,'LastOccurrence' = '@LastOccurence ON INSERT ONLY,'InternalLast' = '@InternalLast' ON INSERT ONLY,'Poll' = '@Poll' ON INSERT ONLY,'Type' = '@Type' ON INSERT ONLY,'Tally' = '@Tally' ON INSERT ONLY,'Class' = '@Class' ON INSERT ONLY,'Grade' = '@Grade' ON INSERT ONLY,'Location' = '@Location' ON INSERT ONLY,'OwnerUID' = '@OwnerUID' ON INSERT ONLY,'Acknowledged' = '@Acknowledged' ON INSERT ONLY,'ServerSerial' = '@ServerSerial' ON INSERT ONLY,);
The creation of a Socket Writer requires the attributes described in Table 6-12.
| Attribute Name | Description |
|---|---|
| Type of Writer; must have a mandatory value of |
| The version number of the Writer. Should be: |
| The name of the host to send data to. |
| The TCP port number. |
| The name of the mapping to use. |
| When the field is a string, the value of this attribute is prepended to the field before it is written to the socket. The default is: ". |
| When the field is a string, the value of this attribute is append to the field before it is written to the socket. The default is: ". |
| The value of this attribute is inserted between the fields written to the socket. The default is: |. |
| The value of this attribute is prepended to each insert alert written to the socket. The default is: |
| The value of this attribute is appended to each insert alert written to the socket. The default is: |
| The value of this attribute is prepended to each update alert written to the socket. The default is: |
| The value of this attribute is appended to each update alert written to the socket. The default is: |
| The value of this attribute is prepended to each delete alert written to the socket. The default is: |
| The value of this attribute is appended to each delete alert written to the socket. The default is: |
| The format to use for any date fields written to the socket. The default is: |
| Enables store and forward mode. Can be set to |
| Specifies the file to store alerts in when the gateway is in store mode. The default file is |
START WRITER REMOTE_WRITER(TYPE = FILE,REVISION = 1,HOST = 'hostname',PORT = 4242MAP = SERVER_MAP,START_STRING = '"',END_STRING = '"',SEPERATOR = '|'INSERT_HEADER = '\nStart of insert line\n',INSERT_TRAILER = '\nStart of insert line\n',UPDATE_HEADER = '\nStart of update line\n',UPDATE_TRAILER = '\nStart of update line\n',DELETE_HEADER = '\nStart of delete line\n',DELETE_TRAILER = '\nStart of delete line\n',DATE_FORMAT = '%C'STORE_AND_FORWARD = TRUE, STORE_FILE = $OMNIHOME/var/<server>_<writer>.store);
The Sybase Writer creates a single table of all transactions that have occurred within the alerts selected by a Cisco Info Server Reader. When a route is created between a Cisco Info Server Reader and a Sybase Writer, for each change made to any record in the Cisco Info Server, a new record is created in the Sybase database, in a specified table. This can also include an action type (insert, update, or delete) and an action time. Using this "audit trail", reporting tools can be applied to the table to produce additional data.
The Sybase Writer is compatible with the following versions of Sybase:
Before running the Sybase Writer, you must create tables in the Sybase database for the alerts to be written into. A script (sybinstall) has been provided to do this automatically. To run the script, specify:
host% $OMNIHOME/gates/sybinstallThe script executes Sybase SQL statements to create and configure the necessary tables using a default template (SYBASE.SQL). As the script is executed, you are prompted to specify names for the status, journal, and details tables.
When you run the script, Sybase may produce a message similar to the following:
Warning: Row size could exceed row size limit, which is 1962 bytes.
This message is informational only.
Mappings for use with the Sybase Writer must follow this format:
CREATE MAPPING<mappingname> ( <SybaseFieldName> = [ '@<fieldname>' | <special_value>][CONVERT TO type] [ , <SybaseFieldName> = [ '@<fieldname>' | <special_value>][CONVERT TO type]]... );
where
| The type of action occurring on the alert. Values are I for Insert, U for Update, D for Delete. |
| The time the action occurred. See the "Time Handling Between the Cisco Info Gateway and Sybase" section for details on time and date handling within the Cisco Info Gateway. |
The optional CONVERT TO type allows the mapping to define a forced conversion for situations where a source field may not match the type of the destination field. type can be INTEGER, STRING, or DATE to force the source field to be converted to an integer, string, or date type. This is particularly relevant when adding extra time fields in the Cisco Info Server to map to Sybase. See the "Time Handling Between the Cisco Info Gateway and Sybase" section for more information.
|
Note The ordering of the fields in the mapping must exactly match the ordering of the fields in the Sybase table being written to. When this is not the case, values are written to incorrect fields. |
The default mapping as supplied in the $OMNIHOME/gates/sybase.conf file is designed for the supplied database/table created by the $OMNIHOME/gates/sybinstall script.
CREATE MAPPING SYBASE_MAP('ActionTime' = ACTION_TIME,'ActionCode' = ACTION_CODE,'Identifier' = '@Identifier','Serial' = '@Serial','Node' = '@Node','NodeAlias' = '@NodeAlias','Manager' = '@Manager','Agent' = '@Agent','AlertGroup' = '@AlertGroup','AlertKey' = '@AlertKey','Severity' = '@Severity','Summary' = '@Summary','StateChange' = '@StateChange' CONVERT TO DATE,'FirstOccurrence' = '@FirstOccurrence' CONVERT TO DATE,'LastOccurrence' = '@LastOccurrence' CONVERT TO DATE,'InternalLast' = '@InternalLast' CONVERT TO DATE,'Poll' = '@Poll','Type' = '@Type','Tally' = '@Tally','Class' = '@Class','Grade' = '@Grade','Location' = '@Location','OwnerUID' = '@OwnerUID','Acknowledged' = '@Acknowledged','ServerName' = '@ServerName');
Note the use of CONVERT TO DATE; this usage is mandatory for these fields.
The creation of a Writer for Sybase system requires the attributes described in Table 6-15.
| Attribute Name | Description |
|---|---|
| Type of Writer; must have a mandatory value of |
| Revision of Writer; must have a mandatory value of |
| Name of mapping for Writer to use. |
| Name of Sybase server to write alerts to. |
| Name of user to log into the Sybase system as. |
| Password of user being used to log into Sybase. |
| Optional: should deletes be forwarded. The default is |
| Optional: should inserts be forwarded. The default is |
| Optional: should updates be forwarded. The default is |
| Optional: format for dates to be written to Sybase. See Section, "Time Handling Between the Cisco Info Gateway and Sybase". |
| Name of the status table. The default is: |
| Name of the journal table. The default is: |
| Name of the details table. The default is: |
| Name of the database table. The default is: |
|
|
|
|
The example configuration contains the following configuration for a Sybase Writer:
START WRITER Sybase_WRITE(TYPE = Sybase,REVISION = 1,MAP = Sybase_MAP,USERNAME = 'sybase_user1'PASSWORD = 'password12'FORWARD_DELETES = TRUE,FORWARD_UPDATES = FALSE,FORWARD_INSERTS = FALSE,STATUS_TABLE = 'status',JOURNAL_TABLE = 'journal',DETAILS_TABLE = 'details',DATABASE = 'alerts'SERVER = 'DB_SERVER1');
This example creates a Writer which forwards deleted alerts to the Sybase server DB_SERVER1 using the map defined in Sybase_MAP.
In order for the Cisco Info Gateway to communicate with Sybase, you must add the Sybase server to the configuration of the servers editor (nco_xigen). The server must have a unique name and port number. See the Cisco Info Center Administrator Reference guide for more information about nco_xigen.
Date/time fields are stored as an integer within the Cisco Info Server. This means that when a date/time field is to be mapped, it must be followed by the CONVERT TO DATE modifier.
CONVERT TO DATE forces the value to be internally printed in a format specified by the Writer attribute DATE_FORMAT. This string is then sent to Sybase where it is assumed the destination field is a datetime type field; when this is true, the string is then converted into Sybase's internal datetime format. When the destination field is a string field, a string representation of the date is inserted. When the destination field is an integer, the entire insert for the alert fails.
The DATE_FORMAT defaults to: %B %d, %Y %I:%M:%S%p. Details of this format are available by examining the manual page for the strftime call (man strftime). The default format is appropriate for english (C) locales but is inappropriate for other locales and must be overridden to the appropriate format for that locale.
The SNMP Writer allows alerts in the system to be forwarded as SNMP traps. This allows Cisco Info Center to generate traps which are forwarded to another management platform such as SunNet Manager or HP Network Node Manager.
The SNMP Writer forwards SNMP version 1 traps.
Before using the Cisco Info Gateway, it is essential that the target management platform is configured to receive the Cisco Info Center traps. Traps from the SNMP forwarder, by default, arrive with an OID value of 1.3.6.1.4.1.1279, a generic-trap value of 6 and specific-trap value of 1. These values can be overridden when the Writer is started.
Mappings for use with the SNMP (forwarder) Writer must use the following syntax:
(
<varbindint> = '@<fieldname>'
[,<varbindint> = '@<fieldname>' [ ON INSERT ONLY ] ]...
) ;
where:
CREATE MAPPING SNMP_MAP(0 = '@Summary',1 = '@Severity',2 = '@Location',3 = '@Node',4 = '@AlertGroup');
The creation of a Writer for the SNMP trap forwarder requires the attributes described in Table 6-15.
| Attribute Name | Description |
|---|---|
| Type of Writer; must have a mandatory value of SNMP. |
| Revision of Writer; must have a mandatory value of |
| Map file for the Writer to use. |
| Name of machine to forward SNMP traps to. |
| Optional: community string from SNMP traps. When not specified, defaults to |
| Optional: integer value for number of retries to attempt to send the SNMP trap. The default is: |
| Optional: integer value for the timeout for each attempt to send the SNMP traps. The default is: |
| Optional: port address for snmpd on the Cisco Info Gateway system. The default is: |
| Optional: Object Identifier for traps. The default is: |
| Optional: integer value for the generic-trap field in SNMP traps forwarded. The default is: |
| Optional: integer value for the specific-trap field in SNMP traps forwarded. The default is: |
| Optional: allows the Writer to forward alert updates as well as new alerts. The default is: |
| Enables host lookup. The default is |
START WRITER SNMP_WRITER(TYPE = SNMP,REVISION = 1,INFO GATEWAY= 'penelope',MAP = SNMP_MAP);
The SNMP Writer only forwards new (inserted) alerts unless the attribute FORWARD_UPDATES is set to TRUE. This in effect reduplicates alerts (as opposed to the Cisco Info Servers deduplication mechanism).
The SNMP Writer never forwards deletions of alerts.
The ServiceView Writer forwards alerts into the ServiceView system. The Writer, given a host and a port, takes alerts and updates and sends them, in a simple hash delimited format, to the ServiceView system.
Mappings for use with the ServiceView Writer must use the following syntax:
(
'' = '@<fieldname>'
[ , ''= '@<fieldname>' ]...
) ;
where <mappingname> is the name of the mapping to be created and <fieldname> is the name of a field in the Cisco Info Server alerts.status table.
Note that the target name is a null string. ServiceView does not have fields that can be mapped. When an alert is forwarded, the order of the mapping is used to determine the order the data is written.
CREATE MAPPING SV_MAP('' = '@Summary','' = '@Severity','' = '@Location','' = '@Node','' = '@AlertGroup');
The creation of a Writer for ServiceView requires the attributes described in Table 6-17.
| Attribute Name | Description |
|---|---|
| Type of Writer; must have a mandatory value of |
| Revision of Writer; must have a value of |
| Map file for the Writer to use. |
| Name of host to forward alerts to. |
| Optional: port to send alerts to on named host. The default is: |
START WRITER SV_WRITER(TYPE = SERVICE_VIEW,REVISION = 1,HOST = 'penelope',MAP = SV_MAP);
When an alert appears in the Cisco Info Center system, all fields referred to in the mapping are forwarded, and are preceded by the tag NEWALERT.
For example, consider the following mapping:
CREATE MAPPING SV_MAP('' = '@Serial','' = '@Node','' = '@Severity',);
When a new alert appears, for example, with a Serial of 2040, Node set to cortez, and Severity of 5, ServiceView receives (where 
is a symbol for the new line character):
NEWALERT#2040#cortez#5#ø
When an update occurs on this alert, ServiceView receives an update. Updates are preceded with the tag ALERTUPDATE. In the example, where an update of Severity changed to 4, the ServiceView would be sent:
ALERTUPDATE#2040#cortez#4#ø
Deletions of alerts are not sent to ServiceView.
The Oracle Writer creates a single table of all transactions that have occurred within the alerts selected by an Cisco Info Server Reader. When a route is created between a Cisco Info Server Reader and an Oracle Writer, for each change made to any record in the Cisco Info Server, a new record is created in the Oracle database, in a specified table. This can also include an action type (insert, update, or delete) and an action time. Using this "audit trail", reporting tools can be applied to the table to produce additional data.
The Oracle Writer is compatible with Oracle versions 7.3 and above.
Before running the Oracle Writer, you must create tables in the Oracle database for the alerts to be written to. A script (orainstall) has been provided to do this automatically. To run the script, specify:
host% $OMNIHOME/gates/orainstallThe script executes Oracle SQL statements to create and configure the necessary tables using a default template (ORACLE.SQL). As the script is executed, you are prompted to specify names for the status, journal, and details tables.
Mappings for use with the Oracle Writer must use the following syntax:
CREATE MAPPING<mappingname> ( <OracleFieldName> = [ '@<fieldname>' | <special_value> ] [CONVERT TO type ][ , <OracleFieldName> = [ '@<fieldname>' | <special_value> ][ CONVERT TO type ]]... );
where:
<mappingname> is the name of the mapping to be created.
<OracleFieldName> is the field name for the field to be written to in the Oracle database.
<fieldname> must be the name of a field in the Cisco Info Server alerts.status table.
<special_value> may be one of a predefined set of keywords which map the field to a specific internal value.
Table 6-18 describes the keywords for the <special_value> attribute:
| The type of action occurring on the alert. Values are |
| The time the action occurred. |
The optional CONVERT TO type allows the mapping to define a forced conversion for situations where a source field may not match the type of the destination field. type can be INTEGER, STRING, or DATE to force the source field to be converted to an integer, string or date type. This is particularly relevant when adding extra time fields in the Cisco Info Server to map to Oracle.
|
Note The ordering of the fields in the mapping must exactly match the ordering of the fields in the Oracle table being written to. When this is not the case, values are written to incorrect fields. |
The default mapping as supplied in the $OMNIHOME/gates/oracle.conf file is designed for the supplied database/table created by the $OMNIHOME/gates/orainstall script.
CREATE MAPPING ORACLE_MAP('ActionTime' = ACTION_TIME,'ActionCode' = ACTION_CODE,'Identifier' = '@Identifier','Serial' = '@Serial','Node' = '@Node','NodeAlias' = '@NodeAlias','Manager' = '@Manager','Agent' = '@Agent','AlertGroup' = '@AlertGroup','AlertKey' = '@AlertKey','Severity' = '@Severity','Summary' = '@Summary','StateChange' = '@StateChange' CONVERT TO DATE,'FirstOccurrence' = '@FirstOccurrence' CONVERT TO DATE,'LastOccurrence' = '@LastOccurrence' CONVERT TO DATE,'InternalLast' = '@InternalLast' CONVERT TO DATE,'Poll' = '@Poll','Type' = '@Type','Tally' = '@Tally','Class' = '@Class','Grade' = '@Grade','Location' = '@Location','OwnerUID' = '@OwnerUID','Acknowledged' = '@Acknowledged','ServerName' = '@ServerName');
Note the use of CONVERT TO DATE; this usage is mandatory for these fields.
The creation of a Writer for Oracle requires the attributes described in Table 6-19.
| Attribute Name | Description |
|---|---|
| Type of Writer; must have a mandatory value of |
| Revision of Writer; must have a mandatory value of |
| Name of mapping for Writer to use. |
| Name of Oracle server to write alerts to. |
| Name of user to log into the Oracle system as. |
| Password of user being used to log into Oracle. |
| Optional: should deletes be forwarded. The default is |
| Optional: should inserts be forwarded. The default is |
| Optional: should updates be forwarded. The default is |
| Optional: format for dates to be written to Oracle. See Section, "Time Handling Between the Cisco Info Gateway and Sybase". |
| Name of the status table. The default is: |
| Name of the journal table. The default is: |
| Name of the details table. The default is: |
| Enables store and forward mode. Can be set to |
| Specifies the file to store alerts in when the gateway is in store mode. The default file is |
The example configuration contains the following configuration for an Oracle Writer:
START WRITER ORACLE_WRITE(TYPE = Oracle,REVISION = 1,MAP = Oracle_MAP,USERNAME = 'oracle_user1'PASSWORD = 'password12'FORWARD_DELETES = TRUE,FORWARD_UPDATES = FALSE,FORWARD_INSERTS = FALSE,STATUS_TABLE = 'status',JOURNAL_TABLE = 'journal',DETAILS_TABLE = 'details',SERVER = 'DB_SERVER1'STORE_AND_FORWARD = FALSE, STORE_FILE = $OMNIHOME/var/<server>_<writer>.store);
This example creates a Writer which forwards deleted alerts to the Oracle server DB_SERVER1 using the map defined in Oracle_MAP.
In order for the Cisco Info Gateway to communicate with Oracle, you must add the Oracle server to the configuration of the servers editor (nco_xigen). The server must have a unique name and port number. See the Cisco Info Center Administrator Reference guide for more information about nco_xigen.
Date/time fields are stored as an integer within the Cisco Info Server. This means that when a date/time field is to be mapped, it must be followed by the CONVERT TO DATE modifier.
CONVERT TO DATE forces the value to be internally printed in a format specified by the Writer attribute DATE_FORMAT. This string is then sent to Oracle where it is assumed the destination field is a datetime type field; when this is true, the string is then converted into Oracle's internal datetime format. When the destination field is a string field, a string representation of the date is inserted. When the destination field is an integer, the entire insert for the alert fails.
The DATE_FORMAT defaults to: %B %d, %Y %I:%M:%S%p. Details of this format are available by examining the manual page for the strftime call (man strftime). The default format is appropriate for English (C) locales but is inappropriate for other locales and must be overridden to the appropriate format for that locale.
The Peregrine Cisco Info Gateway is a fully functional implementation of a Cisco Info Center bidirectional Cisco Info Gateway. Alerts are forwarded from the Cisco Info Server through the Cisco Info Gateway to form ServiceCenter Problem Management tickets. Both systems work together to create and update alerts and tickets. Any change made to a Cisco Info Center alert or a ServiceCenter Problem Management ticket is reflected in its associated alert or ticket.
The Peregrine ServiceCenter Cisco Info Gateway is compatible with Peregrine ServiceCenter 2.0.
The Cisco Info Gateway for Peregrine manages three types of events, each of which performs a different ticket function:
The PMO event type creates a ServiceCenter ticket and forwards it to the ServiceCenter Problem Management System. The Problem Management System issues a response to the Cisco Info Server to confirm the ticket has been created.
The PMU event type updates a ticket when a change is made to an associated event in the Cisco Info Server. This ensures tickets and alerts are synchronized.
The PMC event type closes a ticket when the associated event is resolved.
When a ticket is created using PMO, the Cisco Info Gateway stores the serial number of the alert. When the Problem Management system responds, indicating the ticket has been created, the Cisco Info Gateway stores the number of the ticket. By storing the serial number of the alert and the Problem Management Problem ID together, the Cisco Info Gateway can track associated alerts and tickets. Figure 6-1 shows the relationship between the components of the Cisco Info Gateway and ServiceCenter.
Figure 6-1 shows the components of the Cisco Info Gateway and Peregrine ServiceCenter used to create and manage tickets and alerts. These components are described in the following sections.
The Cisco Info Gateway uses a standard Reader and route which are defined in the Cisco Info Gateway configuration file. The Writer defines four different mappings, one for each event type (PMO, PMU, PMC), and one for ServiceCenter journal entries. You must create an Cisco Info Gateway configuration file that contains these components. See Section, "Creating the Cisco Info Gateway Configuration File", for more information.
The OS-SC (Cisco Info Server to ServiceCenter) and SC-OS (ServiceCenter to Cisco Info Server) routes define the interaction between the Cisco Info Gateway and ServiceCenter. They work in conjunction to track tickets and alerts. To do this, they use the serial to Problem Management Problem ID cache to match alerts routed from the Cisco Info Server with tickets routed from ServiceCenter.
For the Cisco Info Gateway to map events to ServiceCenter correctly, you must define field conversions between the Cisco Info Gateway and ServiceCenter. See the "Creating the Info Gateway Conversions Table for ServiceCenter" section for more information.
ServiceCenter can feedback events through the Cisco Info Gateway into the Cisco Info Server. You must define how the Cisco Info Gateway should act when it receives an event using SQL. See "Editing the Cisco Info Gateway Action SQL Files" section for more information.
The OS-SC and SC-OS routes also launch Read/Write modules (outside the Cisco Info Gateway) which read and write tickets and alerts to and from ServiceCenter. They do this by creating a TCP/IP connection to SCAuto.
Both of these modules produce a log file to record the information transferred through Cisco Info Gateway, as described in Section, "R/W Modules".
SCAuto is the interface through which the Cisco Info Gateway connects to ServiceCenter using a TCP/IP connection. You must ensure you have SCAuto installed and licensed.
Event In and Event Out queue events passed to and from SCAuto and Event Services. You can look at the events currently in the queues.
Event Services manages events received from the Cisco Info Gateway and sent from the Problem Management System. You must register the event types used by the Cisco Info Gateway so that ServiceCenter can interpret and process the events it receives and so it can feed back tickets to the Cisco Info Gateway. You also must create mappings so ServiceCenter can map events into tickets and tickets into events.
See the "Registering ServiceCenter Event Types" section and the "Create ServiceCenter Mappings" section for more information.
The ServiceCenter Problem Management System is used to manage tickets. You must Configure ServiceCenter subroutines so ServiceCenter can feed back events into the Cisco Info Gateway. See Section, "Problem Update Mapping Output Fields", for more information.
By default, the ServiceCenter Cisco Info Gateway uses the equipment record category. This is defined in the Cisco Info Gateway mapping by the static variable equipment.
When the Cisco Info Gateway is started, an internal sequence number is used to determine at what point in the ServiceCenter database the Reader module should start processing events. Between shutdowns of the Cisco Info Gateway, this sequence number is stored in an external file. When the Cisco Info Gateway is restarted, all events starting at this sequence number are processed. The sequence number is not configurable and is documented in the log files.
The R/W modules both produce a log file which records the operation of the Cisco Info Gateway. These log files are stored in the file:
$OMNIHOME/bin/arch/nco_prwmodule_<PID>.logwhere <PID> is the UNIX process identifier for either the Reader or Writer module.
Table 6-20 shows the format of the log files.
| Field name | Description |
evtype | Event type being performed on this record. Can be |
evtime | The event time set and controlled by the ServiceCenter event manager. |
evsysseq | Internal sequence number maintained by the Cisco Info Gateway. |
evusrseq | User sequence number used by the Cisco Info Gateway to determine whether the event was generated by ServiceCenter, or is a return event from the Cisco Info Gateway. |
evuser | The username used to read or write Cisco Info Center and ServiceCenter records. |
evpswd | Application password for the event, when one is required. |
evsepchar | Character used to separate ServiceCenter record fields. |
evfields | Complete ServiceCenter record. Fields are delimited by the separator character. |
The ServiceCenter configuration must be performed by a user with Administration privileges.
Before you run the Cisco Info Gateway, you should create an operator named Omnibus. This operator is used in the configuration and allows you to track events that are generated by the Cisco Info Gateway.
Before you can run the Cisco Info Gateway, you must configure the Cisco Info Gateway and Peregrine ServiceCenter. You must complete the following six steps:
1. Create the Cisco Info Gateway configuration file.
2. Create the Cisco Info Gateway conversions table.
3. Edit the Cisco Info Gateway action SQL files.
4. Register ServiceCenter event types.
5. Create ServiceCenter mappings.
6. Configure ServiceCenter format control subroutines.
Each of these steps is described in the following sections.
The Peregrine ServiceCenter Cisco Info Gateway configuration file is similar to those for other Info Gateways. The main difference is the Cisco Info Gateway contains four different mappings, one for each type of event or ticket, and one to update ServiceCenter journals.
The Cisco Info Gateway Writer attributes and mappings are described in the following sections.
Table 6-21 shows the required ServiceCenter Writer attributes.
| Attribute Name | Mandatory | Description |
|---|---|---|
| Yes | Identifies the type of Writer, must be set to a value of |
| Yes | Revision of Writer, with this release must be set to a value of |
| Yes | Name of the open mapping attribute configuration. |
| Yes | Name of the update mapping attribute configuration. |
| Yes | Name of the close mapping attribute configuration. |
| Yes | Name of the journal mapping attribute configuration. |
| Yes | Name of the host server where the ServiceCenter SCAUTO server is running. |
| Yes | Name of the user to be used when sending and retrieving events. |
| Yes | Password to access the application when one is required. Can be specified as a null. |
| Yes | Name of the Cisco Info Server where the Cisco Info Gateway feedback mechanism writes the ServiceCenter problem record. |
| Yes | Name of the field in the feed back Cisco Info Server where the ServiceCenter problem management problem ID should be written. |
| Yes | The field index of the returned ServiceCenter PMO response event where the problem management problem ID can be found. |
| No | Character used to separate fields in a ServiceCenter event record. The default is the ^ character. |
| Yes | Must have a value of |
| No | Format of date required. Defaults to |
| Yes | Name of the counterpart Reader in the bidirectional Cisco Info Gateway configuration. |
| Yes | Name of the conversions table in the Cisco Info Server that holds the data values of required conversions between ServiceCenter and Cisco Info Center fields. |
| No | Name of the file containing the open action SQL to be performed at the Cisco Info Server. When no attribute is supplied, no action is taken. |
| No | Name of the file containing the update action SQL to be performed at the Cisco Info Server. When no attribute is supplied, no action is taken. |
| No | Name of the file containing the close action SQL to be performed at the Cisco Info Server. When no attribute is supplied, no action is taken. |
| No | This turns off forwarding of the |
The following example shows a configuration file complete with Cisco Info Gateway commands and Writer attributes:
## Start up the reader - connect to the Cisco Info Server SCNCOMS## This example does not use filtering#START READER SERVER_READER CONNECT TO SCNCOMS;## Start up the writer#START WRITER PEREGRINE_WRITER(
TYPE = PEREGRINE,
REVISION = 1,
OPEN_MAP = PEREGRINE_OPEN_MAP,
UPDATE_MAP = PEREGRINE_UPDATE_MAP,
CLOSE_MAP = PEREGRINE_CLOSE_MAP,JOURNAL_MAP = PEREGRINE_JOURNAL_MAPSCAUTO_SERVER = `jfksys1.scauto1',
USER = 'Omnibus',
APPLICATION_PASSWORD = '',
FEEBDACK_SERVER = 'SCNCOMS',
FEEDBACK_FIELD = 'Location',PROBNUM_FIELD_INDEX = 2,SEPARATOR_CHAR = '^',
CLOSE_PROBLEMS = 'TRUE',
DATE_FORMAT = '%m/%d/%y %T',COUNTERPART = SERVER_READER,
CONVERSIONS_TABLE = 'conversions.peregrine',
OPEN_ACTION_SQL = '/dev/peregrine/open_action.sql',
UPDATE_ACTION_SQL = '/dev/peregrine/open_action.sql',
CLOSE_ACTION_SQL = '/dev/peregrine/open_action.sql'
);## Add a route from the reader to the writer so the data is passed#ADD ROUTE FROM SERVER_READER TO PEREGRINE_WRITER## End of file#
Mapping techniques define how the format of Cisco Info Server and ServiceCenter data should be changed so it is written in the correct format and to the correct field in the receiving application.
The ServiceCenter Cisco Info Gateway allows individual mapping configurations to be specified for the following functions:
Mapping configurations for use with the ServiceCenter Writer must use the following syntax:
CREATE MAPPING <mappingname>
(
<FieldId> = '<@fieldname>' [ CONVERT TO DATE ], ... ,
[ <FieldId> = '<fieldname>'], ... ,
[ <FieldId> = <variablename>], ...
) ;
where:
This can be either PROBLEM_NUMBER or JOURNAL_TEXT. When used, the current contents of these variables are substituted in the assigned fields. PROBLEM_NUMBER holds the ServiceCenter problem Problem Management Problem ID. It can only be used in update and close maps. JOURNAL_TEXT holds the journal text and can only be used in a journal map.
The optional CONVERT TO DATE allows the mapping to define a forced conversion to a date type field.
The position of Cisco Info Center and ServiceCenter field mappings is important, as the Cisco Info Gateway forwards events to ServiceCenter as a single string. Therefore, you must ensure the Cisco Info Gateway mapping fields are in the same order as the ServiceCenter mapping fields. As each record is processed, the corresponding field values are substituted. For example, the following assignment specifies the third ServiceCenter field must be substituted with the value of Cisco Info Center field ServerSerial:
3= '@ServerSerial'
As the mapping is positional, the sequencing of fields is effected by their placement. When you do not wish to use a particular ServiceCenter field, you must supply a separator character(s) to move to the next field.
For certain functions, you do not want values to be substituted. For example, when closing a ServiceCenter record you may only want to substitute certain values and leave the other fields with the value they previously contained. In this case you must assign a null value to the ServiceCenter record.
The ServiceCenter Cisco Info Gateway supports the use of static variables. This is a technique for supplying certain values that must not be changed by Cisco Info Center. The following assignment shows that ServiceCenter field number 10 has a value of equipment. This is a ServiceCenter record category that should not be changed, as it is only applicable to ServiceCenter. This value remains the same for the lifetime of the record.
10= 'equipment',
The following sections describe mapping techniques for each of the create, update, close, and journal mapping functions.
The following mapping configuration is an example of data that is substituted when a record is opened. In this example, the tenth ServiceCenter field has been assigned the static variable, equipment, which indicates the Cisco Info Gateway uses the equipment ServiceCenter record category. All other fields are created and assigned Cisco Info Server values.
CREATE MAPPING PEREGRINE_OPEN_MAP(1 = '@Identifier',2 = '@Server',3 = '@ServerSerial',4 = '@Node',5 = '@Manager',6 = '@Agent',7 = '@AlertGroup',8 = '@AlertKey',9 = '@Severity',10 = 'equipment',11 = '@StateChange' CONVERT TO DATE,12 = '@FirstOccurrence' CONVERT TO DATE,13 = '@LastOccurrence' CONVERT TO DATE,14 = '@InternalLast' CONVERT TO DATE,15 = '@Poll',16 = '@Type',17 = '@Tally',18 = '@Class',19 = '@Grade',20 = '@Location',21 = '@OwnerUID',22 = '@OwnerUID',23 = '@Acknowledged',24 = '@NodeAlias');
The following mapping configuration is an example of data that is substituted when a record is updated. In this example, the third ServiceCenter field has been assigned the Cisco Info Gateway variable, PROBLEM_NUMBER. The tenth ServiceCenter field has been assigned the static variable equipment. All other fields are substituted with new Cisco Info Server values.
CREATE MAPPING PEREGRINE_UPDATE_MAP(1 = '@Identifier',2 = '@Server',3 = PROBLEM_NUMBER,4 = '@Node',5 = '@Manager',6 = '@Agent',7 = '@AlertGroup',8 = '@AlertKey',9 = '@Severity',10 = 'equipment',11 = '@StateChange' CONVERT TO DATE,12 = '@FirstOccurrence' CONVERT TO DATE,13 = '@LastOccurrence' CONVERT TO DATE,14 = '@InternalLast' CONVERT TO DATE,15 = '@Poll',16 = '@Type',17 = '@Tally',18 = '@Class',19 = '@Grade',20 = '@Location',21 = '@OwnerUID',22 = '@OwnerUID',23 = '@Acknowledged',24 = '@Servername',25 = '@ServerSerial');
The following mapping configuration is an example of data that is substituted when a record is closed. In this example, only the Cisco Info Center field @Serial is substituted. ServiceCenter field number three has been assigned the Cisco Info Gateway variable, PROBLEM_NUMBER. All other fields have a null value; they are not substituted with any new values.
CREATE MAPPING PEREGRINE_CLOSE_MAP(1 = '',
2 = '@Serial',
3 = PROBLEM_NUMBER,
4 = '',
5 = '',
6 = '',
7 = '',
8 = '',
9 = '',
10 = '',
11 = '',
12 = '',
13 = '',
14 = '',
15 = '',
16 = '',
17 = '',
18 = '',
19 = '',
20 = '',
21 = '',
22 = '',
23 = '',
24 = '',
25 = '',
22 = '',
23 = '',
24 = ''
);
The journal map facility allows you to maintain a textual history of an event with the Cisco Info Center journal information.
The create journal map command allows you to specify which Cisco Info Server fields must be populated in which ServiceCenter fields when updating journal information.
CREATE MAPPING PEREGRINE_JOURNAL_MAP(1 = '',
2 = '@Serial',
3 = PROBLEM_NUMBER,
4 = '',
5 = JOURNAL_TEXT,
6 = '',
7 = '',
8 = '',
9 = '',
10 = '',
11 = '',
12 = '',
13 = '',
14 = '',
15 = '',
16 = '',
17 = '',
18 = '',
19 = '',
20 = '',
21 = '',
22 = '',
23 = '',
24 = '',
25 = '',
22 = '',
23 = '',
24 = '');
The conversion table facility allows you to specify certain data conversions to take place between particular ServiceCenter and Cisco Info Server fields. For example, ServiceCenter users require a status field to be alphabetic and to have a particular value. Cisco Info Center may hold these as numeric values.
Note, the Cisco Info Server SQL definition file must be updated to include the conversions database. See Section, "Changing the SQL Definition File", for further information.
All conversions must be supplied before the Cisco Info Gateway can be operational.
A graphical user interface utility has been provided to define the conversions. To run the utility, specify the command:
nco_gwconvThe Peregrine Conversion window is displayed, as shown in Figure 6-2.
The Info Gateway Conversion window Title bar contains the server name and table name being used. The work area displays any existing conversions. Conversion details are displayed in three columns. The first column contains the Cisco Info Server table column name. The second column contains the values associated with the column. The third column contains the converted value.
To add a new conversion:
Step 2 Click in the Column field then specify the Cisco Info Server column name.
Step 3 Specify the Cisco Info Server value in the OS Value field.
Step 4 Specify the conversion value in the Conversion field.
Step 5 Click on the Apply button, then click on the Close button.
To update an existing conversion:
Step 2 Update the values as required.
Step 3 Click on the Apply button, then click on the Close button.
To delete a conversion:
Step 2 Click on the Delete button. You can undo the delete by clicking on the Undo button.
Step 3 Click on the Apply button, then click on the Close button.
The conversion table is Cisco Info Server SQL based. This means you can make full use of the Cisco Info Server SQL. The conversion expects information to be supplied in columns, enclosed in parenthesis, where the columns indicate:
column 1 = key field name column 2 = column name column 3 = Cisco Info Server value column 4 = conversion value
In the following example, the numeric value of the Cisco Info Server Severity field, either (0, 1, 2, 3, 4, or 5) is converted to ServiceCenter textual values, either (Clear, Indeterminate, Low, Routine, High, or Critical). User name values are also converted. They can be specified by using the SQL input script, nco_sql.
use database conversions;goinsert into peregrine values ('Severity0','Severity','0','Clear');insert into peregrine values ('Severity1','Severity','1','Indeterminate');insert into peregrine values ('Severity2','Severity','2','Low');insert into peregrine values ('Severity3','Severity','3','Routine');insert into peregrine values ('Severity4','Severity','4','High');insert into peregrine values ('Severity5','Severity','5','Critical');goinsert into peregrine values ('OwnerUID0','OwnerUID','0','Root');insert into peregrine values ('OwnerUID65534','OwnerUID','65534','Nobody');go
You must make additions to the Cisco Info Center SQL definition file to create the conversions database and table. The following example shows the SQL statements required. Restart the Cisco Info Server to apply any SQL changes you make:
create database conversions;use database conversions;create table peregrine (KeyField char(255),Colname char(255),OSValue char(255),Conversion char(255),unique (KeyField),permanent);
The Cisco Info Gateway action SQL files determine what actions should take place at the Cisco Info Server when there is new or changed ServiceCenter information. The files are Cisco Info Server SQL based, therefore, you have all of the language facilities available to you. You must specify action SQL for each of the event types, open, update, and close.
When the SQL is being processed, data fields are expanded, conversions are resolved, and Cisco Info Server fields are populated. The following example updates the Severity field:
update alerts.status set Severity = $(23:Severity);
In the previous statement, the data usage is resolved as follows:
1. The $ symbol signifies an expansion statement and information enclosed within the parentheses must be resolved.
2. The 23 statement specifies that ServiceCenter field number 23 is being used.
3. The Severity statement specifies that severity conversions must be used and applied. The colon is a statement separator.
4. The Cisco Info Server field is updated with the resolved value.
The Cisco Info Gateway makes extensive use of certain data fields that are kept in cache storage. One of the reasons this mechanism is provided is to ensure unique identification of Cisco Info Center alerts at all times. They may or may not be used in ServiceCenter records. These fields can be used in the SQL at any time and increase performance. The cache fields that are always available are:
The open action SQL file determines what action should be taken at the Cisco Info Server when a problem ticket is opened.
The following example updates the Cisco Info Server and sets three data fields. All three fields are resolved, with Severity populated with ServiceCenter field number 23 and applied conversions. The Agent field is equivalent to ServiceCenter field number 9.
## The Peregrine Cisco Info Gateway Problem Open Action SQL file#update alerts.status set Severity = $(23:Severity), Agent = '$(9)'where Serial = $(Serial);
The update action SQL file determines what action should be taken at the Cisco Info Server when a problem ticket is updated.
The following example updates the Cisco Info Server and sets two data fields. The Agent field is resolved to a concatenation of ServiceCenter fields numbers 4 and 9.
## The Peregrine Cisco Info Gateway Problem Update Action SQL file#update alerts.status set Agent = '$(4) $(9)' where Serial = $(Serial);
The close action SQL file determines what action should be taken at the Cisco Info Server when a problem ticket is closed.
The following example performs both an Cisco Info Server delete and update. The delete statement removes the associated event for the problem ticket.
The update statement updates any associated events on the same node as ServiceCenter field five with a severity of 1 (clear).
## The Peregrine Cisco Info Gateway Problem Close (Deletion) Action SQL file#delete from alerts.status where Serial = $(Serial);update alerts.status set Severity = 1 where Node = '$(5)';
Two ServiceCenter applications are used to pass events and tickets between ServiceCenter Event Services and ServiceCenter Problem Management:
The axces.apm application processes PMO, PMU, and PMC events passed into ServiceCenter from the Cisco Info Gateway. The axces.write application feeds back Problem Management Problem IDs of PMO events to the Cisco Info Gateway.
You must register four event types that use these two applications allowing ServiceCenter to interpret the events it receives from the Cisco Info Gateway, and then feed back the Problem Management Problem IDs of PMO events. The event types you must create are shown in Table 6-21. By default, these event types exist when you install ServiceCenter. This section is provided as a reference to the defaults required by the Cisco Info Gateway.
| Event Type | Mapping | Application | Description |
|---|---|---|---|
PMO | Default problem open | axces.apm | Processes new PMO events received from the Cisco Info Gateway. |
PMO | Default problem open | axces.write | Feeds back Problem IDs of PMO events to the Cisco Info Gateway. |
PMU | Default problem update | axces.apm | Processes PMU events received from the Cisco Info Gateway. |
PMC | Default problem close | axces.apm | Processes PMC events received from the Cisco Info Gateway. |
Event types are created from the Event Registration window. To access this window, select the Utilities->Event Services->Administration->Register option, then click on the Application tab.
The following two sections provide examples on how to register event types using axces.apm and axces.write.
The axces.apm application processes an input PMO event when the execute condition resolves to true. Figure 6-3 shows the axces.apm application view of the Event Registration window. This example contains all of the required parameters. See Table 6-23 for a description of the parameters.
The fields used in this example are described in Table 6-23.
The PMO input event registration should already be defined within the ServiceCenter system. When problem IDs are not fed back to the Cisco Info Server it is usually because the boolean1 parameter in axces.apm has been set to False.
The axces.write application writes an output event when the execute condition resolves to true. It is this registration that enables the axces.apm application to write a PMO output event. Figure 6-4 shows the axces.write application view of the Event Registration window. This example has all of the required parameters. See Table 6-24 for a description of the parameters.
The fields in the above figure are described in Table 6-24.
| Parameter Name | Parameter Value | Description |
|---|---|---|
record | $axces | Represents the record to be written, in this case $axces. |
name | pmo | pmo as this is the name of registration type. |
string1 | ^ | Defines the record field separator. |
query | evuser in $axces | Uses the value held in the evuser field of the input PMO event to create the output event. |
prompt | nullsub (evusrseq in $axces, evsysseq in $axces) | This parameter defines the value for the evusrseq of the output event. In this case, the nullsub function uses the evusrseq of the input event when one exists, if not, the evsysseq is used. Note: The Cisco Info Gateway uses the evusrseq field to track returned output events as responses to its input events. This means that if the input event has an evusrseq, it must be copied to the output event evusrseq field. |
For both the input and output PMO registrations, the event map is provided in the Event Registration - Basics window. The map definitions can then be found in the Event Maps utility within Event Services. This enables you to identify which field of the constructed ServiceCenter record is the relevant field in the problem record.
The fields of events passed between ServiceCenter and the Cisco Info Gateway must be mapped to each other so the applications can interpret the information they receive from one another. The mappings for the Cisco Info Gateway are described in Section, "Creating the Cisco Info Gateway Configuration File". You also must create mappings within ServiceCenter.
You must create mappings for each field passed into and out of ServiceCenter for PMO, PMU, and PMC events. However, when you are using the default equipment problem category, you should use the default maps: problem open, problem update, and problem close. Each mapping contains input and output type fields. The following sections contain examples of the fields you must configure for each type of mapping, when you are not using the default equipment category.
Table 6-25 shows the fields you would use to create an input map for PMO events for the default problem category equipment. Note that the fields are in the same order as the PMO fields in the Cisco Info Gateway PMO mapping.
| Sequence | Position | File Name | Field Name |
|---|---|---|---|
1 | 1 | problem | logical.name |
1 | 2 | problem | network.name |
1 | 3 | problem | reference.no |
1 | 4 | problem | cause.code |
1 | 5 | problem | $ax.field.name |
1 | 6 | problem | action,2 |
1 | 7 | problem | action,3 |
1 | 8 | problem | network.address |
1 | 9 | problem | type |
1 | 10 | problem | category |
1 | 11 | problem | domain |
1 | 12 | problem | objid |
1 | 13 | problem | version |
1 | 14 | problem | model |
1 | 15 | problem | serial.no. |
1 | 16 | problem | vendor |
1 | 17 | problem | location |
1 | 18 | problem | contact.name |
1 | 19 | problem | contact.phone |
1 | 20 | problem | resolution |
1 | 21 | problem | assignee.name |
1 | 22 | problem | priority.code |
1 | 23 | problem | failing.component |
1 | 24 | problem | system |
Table 6-26 shows the fields you would use to create an output map for PMU events for the default problem category equipment.
| Sequence | Position | File Name | Field Name |
|---|---|---|---|
1 | 1 | none | assignee.email |
1 | 2 | none | number |
1 | 3 | none | category |
1 | 4 | none | open.time |
1 | 5 | none | opened.by |
1 | 6 | none | actor |
1 | 7 | none | priority.code |
1 | 8 | none | severity.code |
1 | 9 | none | assignment |
1 | 10 | none | referred.to |
1 | 11 | none | alert.time |
1 | 12 | none | status |
1 | 13 | none | vendor |
1 | 14 | none | reference.no |
1 | 15 | none | contact.time |
1 | 16 | none | backup.start |
1 | 17 | none | cause.code |
1 | 18 | none | logical.name |
1 | 19 | none | group |
1 | 20 | none | job.name |
1 | 21 | none | location |
1 | 22 | none | version |
1 | 23 | none | type |
1 | 24 | none | abend.code |
1 | 25 | none | model |
1 | 26 | none | action |
1 | 27 | none | key.words |
1 | 28 | none | reference.no |
1 | 29 | none | id |
1 | 30 | none | downtime.start |
1 | 31 | none | assignee.name |
1 | 32 | none | contact.name |
1 | 33 | none | caller.id |
1 | 34 | none | contact.phone |
1 | 35 | none | network.name |
1 | 36 | none | open.group |
1 | 37 | none | resolution |
1 | 38 | none | update.action |
Table 6-27 shows the fields you use to create an input map for PMU events for the default problem category equipment. Note, the fields are in the same order as the PMU fields in the Cisco Info Gateway PMU mapping.
| Sequence | Position | File Name | Field Name |
|---|---|---|---|
1 | 1 | problem | logical.name |
1 | 2 | problem | network.name |
1 | 3 | problem | number |
1 | 4 | problem | cause.code |
1 | 5 | problem | update.action |
1 | 6 | problem | action,2 |
1 | 7 | problem | action,3 |
1 | 8 | problem | network.address |
1 | 9 | problem | key.words |
1 | 10 | problem | category |
1 | 11 | problem | domain |
1 | 12 | problem | objid |
1 | 13 | problem | version |
1 | 14 | problem | model |
1 | 15 | problem | serial.no. |
1 | 16 | problem | vendor |
1 | 17 | problem | location |
1 | 18 | problem | contact.name |
1 | 19 | problem | contact.phone |
1 | 20 | problem | reference.no |
1 | 21 | problem | assignee.name |
1 | 22 | problem | priority.code |
1 | 23 | problem | failing.component |
1 | 24 | problem | system |
Table 6-28 shows the fields you use to create an output map for PMU events for the default problem category equipment.
| Sequence | Position | File Name | Field Name |
|---|---|---|---|
1 | 1 | none | assignee.email |
1 | 2 | none | number |
1 | 3 | none | category |
1 | 4 | none | open.time |
1 | 5 | none | opened.by |
1 | 6 | none | actor |
1 | 7 | none | priority.code |
1 | 8 | none | severity.code |
1 | 9 | none | assignment |
1 | 10 | none | referred.to |
1 | 11 | none | alert.time |
1 | 12 | none | status |
1 | 13 | none | vendor |
1 | 14 | none | reference.no |
1 | 15 | none | contact.time |
1 | 16 | none | backup.start |
1 | 17 | none | cause.code |
1 | 18 | none | logical.name |
1 | 19 | none | group |
1 | 20 | none | job.name |
1 | 21 | none | location |
1 | 22 | none | version |
1 | 23 | none | type |
1 | 24 | none | abend.code |
1 | 25 | none | model |
1 | 26 | none | action |
1 | 27 | none | key.words |
1 | 28 | none | reference.no |
1 | 29 | none | id |
1 | 30 | none | downtime.start |
1 | 31 | none | assignee.name |
1 | 32 | none | contact.name |
1 | 33 | none | caller.id |
1 | 34 | none | contact.phone |
1 | 35 | none | network.name |
1 | 36 | none | open.group |
1 | 37 | none | update.action |
Table 6-29 shows the fields you use to create an input map for PMC events for the default problem category equipment. Note, the fields are in the same order as the PMC fields in the Cisco Info Gateway PMC mapping.
| Sequence | Position | File Name | Field Name |
|---|---|---|---|
1 | 1 | problem | logical.name |
1 | 2 | problem | network.name |
1 | 3 | problem | number |
1 | 4 | problem | resolution.code |
1 | 5 | problem | resolution |
1 | 6 | problem | resolution,2 |
1 | 7 | problem | resolution,3 |
1 | 8 | problem | network.address |
1 | 9 | problem | key.words |
1 | 10 | problem | category |
1 | 11 | problem | domain |
1 | 12 | problem | objid |
1 | 13 | problem | version |
1 | 14 | problem | model |
1 | 15 | problem | serial.no. |
1 | 16 | problem | vendor |
1 | 17 | problem | location |
1 | 18 | problem | contact.name |
1 | 19 | problem | contact.phone |
1 | 20 | problem | reference.no |
1 | 21 | problem | assignee.name |
1 | 22 | problem | priority.code |
1 | 23 | problem | failing.component |
1 | 24 | problem | system |
Table 6-30 shows the fields you use to create an output map for PMC events for the default problem category equipment.
.
| Sequence | Position | File Name | Field Name |
|---|---|---|---|
1 | 1 | none | assignee.email |
1 | 2 | none | number |
1 | 3 | none | category |
1 | 4 | none | close.time |
1 | 5 | none | closed.by |
1 | 6 | none | actor |
1 | 7 | none | priority.code |
1 | 8 | none | severity.code |
1 | 9 | none | assignment |
1 | 10 | none | referred.to |
1 | 11 | none | alert.time |
1 | 12 | none | status |
1 | 13 | none | vendor |
1 | 14 | none | reference.no |
1 | 15 | none | contact.time |
1 | 16 | none | backup.start |
1 | 17 | none | cause.code |
1 | 18 | none | logical.name |
1 | 19 | none | group |
1 | 20 | none | job.name |
1 | 21 | none | location |
1 | 22 | none | version |
1 | 23 | none | type |
1 | 24 | none | abend.code |
1 | 25 | none | model |
1 | 26 | none | resolution |
1 | 27 | none | key.words |
1 | 28 | none | reference.no |
1 | 29 | none | id |
1 | 30 | none | downtime.start |
1 | 31 | none | assignee.name |
1 | 32 | none | contact.name |
1 | 33 | none | caller.id |
1 | 34 | none | contact.phone |
1 | 35 | none | network.name |
1 | 36 | none | open.group |
1 | 37 | none | action |
1 | 38 | none | update.action |
When problems are updated and closed by ServiceCenter operators, a record must be written to the Event Out queue. The record contains information as defined in the ServiceCenter output event map. The Format Control utilities generate these events for the Cisco Info Gateway. This is achieved by defining format control subroutines which execute the correct application and pass it the necessary parameters. In addition, problem management can have different problem categories. The subroutines must be defined for each problem category when they are to be used in the Cisco Info Gateway.
The Format Control subroutines must only be configured for problem management update and close. They need not be defined for problem open. The examples used here use a problem management category of equipment.
To configure Format Control, you must create an axces.write subroutine for the problem categories update and close. The configuration must be completed on the Format Control Maintenance - Subroutines window. The window view must be in Long View mode to complete the details. To access this window:
1. Select the Utilities->Tools->Format Control menu option.
2. Specify either problem.equipment.update or problem.equipment.close in the name field, then press Return. This example assumes you are using the default equipment category. The Format Control Maintenance window is displayed.
3. Select the Options menu's Subroutines option. The Format Control Maintenance - Subroutines window is displayed.
4. Select the Options menu's Show Expanded Form option.The subroutine entry fields are displayed.
5. Specify the field values as described in the following two sections.
The format control update configuration defines what event must occur when a ServiceCenter problem ticket is updated.
Figure 6-5 shows the Long View of the Format Control Maintenance Subroutines window. This example has all of the parameters required for a problem category of equipment.
Table 6-31 describes the fields shown in this example.
| Field Name | Description |
|---|---|
Application Name | This must have a value of axces.write for all instances of the Cisco Info Gateway. |
Names: record | This identifies the record to be written. $file specifies the complete problem record. |
Names: name | The name of the registration type. For update it must have a value of pmu. |
Names: prompt | Specifies the user sequence ID. In this example, str(number in $file) indicates the following: 1. The str function formats the contents of the specified field into a string. 2. The number statement is the name of the field when to obtain the value. 3. The in $file statement means use the $file value for the record parameter. |
Names: query | Specifies the user name. ServiceCenter defaults to the operator name, however, the Cisco Info Gateway requires a user name of |
Error Message | When the record could not be written, this message is logged. This field is a free format text field. |
Add | Specifies criteria for the action (pmu) to be taken. This statement must resolve to |
Update | Same as Add. This must be specified with the same statement. |
The Format Control close configuration defines what event must occur when event services closes a problem ticket.
The following figure shows the Long View of the Format Control Maintenance Subroutines window. This example has all of the parameters required for a problem category of equipment.
Table 6-32 describes the fields shown in this example.
| Field Name | Description |
|---|---|
Application Name | This must have a value of axces.write for all instances of the Cisco Info Gateway. |
Names: record | This identifies the record to be written. $file specifies the complete problem record. |
Names: name | The name of the registration type. For close it must have a value of pmc. |
Names: prompt | Specifies the user sequence ID. In this example, str(number in $file) indicates the following: 1. The str function formats the contents of the specified field into a string. 2. The number statement is the name of the field to obtain the value. 3. The in $file statement means use the $file value for the record parameter. |
Names: query | Specifies the user name. ServiceCenter defaults to the operator name, however, the Cisco Info Gateway requires a user name of |
Error Message | When the record could not be written, this message is logged. This field is a free format text field. |
Add | Specifies criteria for the action (pmu) to be taken. This statement must resolve to |
Delete | Same as Add. This must be specified with the same statement. |
This section contains error messages that can be issued by the Cisco Info Gateway. Each message is usually followed by two bullet points. The first provides further details on the error. The second provides a problem resolution or some indication of where to look for further details on the error.
Peregrine Writer <name>: Memory allocation failure.
Explanation Insufficient memory available for the Writer to perform an operation.
Action Release memory by stopping unnecessary processes. Increase the machine's available swap space or add more physical memory.
Peregrine Writer <name>: Failed to re-acquire alert details from OS.
Explanation The Cisco Info Gateway was unable to acquire the necessary data for its cache when it received a notification for an event not in the cache. This occurs when the Cisco Info Gateway is stopped.
Peregrine Writer <name>: Invalid data type for problem number feedback field.
Explanation The problem number feedback field was found not to be a character field.
Action Specify a feedback field which is of type character.
Peregrine Writer <name>: Serial <serial_num> already in serial Cache. Cannot add.
Explanation An insert into the Cisco Info Server with the same serial number occurred. This should not occur, therefore, the record can not be added to the cache.
Peregrine Writer <name>: Serial <serial_num> not found in serial cache. Cannot Update/Delete.
Explanation An event update/delete failed to find the necessary alert details in the Writer's serial cache.
Peregrine Writer <name>: Failed to construct path to Peregrine Read/Write Module.
Explanation Failed to determine the path to the Peregrine read/write module executable.
Peregrine Writer <name>: Failed to find the Peregrine Read/Write Module <name>.
Explanation Failed to access the Peregrine read/write module executable in $OMNIHOME/bin/arch.
Action Verify the existence and location of the module.
Peregrine Writer <name>: Incorrect permissions on the Peregrine module binary <name>.
Explanation The Peregrine read/write module was found, however, it does not have execution or read permissions.
Action Apply the correct permissions to the file.
Peregrine Writer <name>: Failed to construct the argument list for Peregrine Module.
Explanation Failed to construct the launch request for the Peregrine read/write module due to memory limitations.
Action Release memory by stopping unnecessary processes. Increase the machine's available swap space or add more physical memory.
Peregrine Writer <name>: Failed to start the OS-SC Writer.
Explanation The Cisco Info Server to ServiceCenter Writer module failed to start.
Action Examine the Writer module log file for further messages.
Peregrine Writer <name>: Failed to start the SC-OS Reader.
Explanation The ServiceCenter to Cisco Info Server Reader module failed to start.
Action Examine the Reader module log file for further messages.
Peregrine Writer <name>: Failed to create the Serial Cache Mutex.
Explanation Failed to construct the data protection structure due to insufficient memory resources.
Action Release memory by stopping unnecessary processes. Increase the machine's available swap space or add more physical memory.
Peregrine Writer <name>: Failed to start the SC-to-OS service thread.
Explanation The main Peregrine Writer failed to start the ServiceCenter to Cisco Info Server handler thread. This is due to insufficient memory resources.
Action Release memory by stopping unnecessary processes. Increase the machine's available swap space or add more physical memory.
Peregrine Writer <name>: Failed to send a SIGTERM to shutdown SC Writer.
Explanation Failed to stop the ServiceCenter Writer module. This may result in the Cisco Info Gateway port being locked.
Action Find the process in the process list and halt it.
Peregrine Writer <name>: Failed to send a SIGTERM to shutdown SC Reader.
Explanation Failed to stop the ServiceCenter Reader module. This may result in the Cisco Info Gateway port being locked.
Action Find the process in the process list and halt it.
Peregrine Writer <name>: Map '<map name>' is not the journal map and cannot contain the 'JOURNAL_TEXT' map item in Peregrine Writer '<writer name>'.
Explanation The special mapping name JOURNAL_TEXT was contained within a map that was not specified to be the journal map. The mapping name references the position at which journal text should be positioned in the journal PMU event.
Action Remove the names from the incorrect map.
Peregrine Writer <name>: Failed to send SC Event to the SC Writer module.
Explanation A problem was detected with the connection to the ServiceCenter Writer module.
Action Examine the ServiceCenter Writer module log file for further messages.
Peregrine Writer <name>: Failed to wait for return from the SC Writer module.
Action Examine the ServiceCenter Writer module log file to determine the module error.
Peregrine Writer <name>: Failed to read the status return message from the SC Writer module.
Action Examine the ServiceCenter Writer module log file to determine the module error.
Peregrine Writer <name>: Failed to send event to ServiceCenter.
Action Examine the ServiceCenter Writer module log file to determine the module error.
Peregrine Writer <name>: SC Writer Module experienced Fatal Error.
Explanation Unexpected error occurred when the ServiceCenter Writer module terminated.
Action Examine the ServiceCenter Writer module log file to determine the module error.
Peregrine Writer <name>: Failed to build serial index.
Explanation The ServiceCenter Writer was unable to construct the fast access jump index for the Serial index.
Action Check the alerts.status table definitions and ensure the field exists.
Peregrine Writer <name>: Failed to build server serial index.
Explanation The ServiceCenter Writer was unable to construct the fast access jump index for the ServerSerial index.
Action Check the alerts.status table definitions and ensure the field exists.
Peregrine Writer <name>: Failed to build server name index.
Explanation The ServiceCenter Writer was unable to construct the fast access jump index for the ServerName index.
Action Check the alerts.status table definitions and ensure the field exists.
Peregrine Writer <name>: Failed to find field <Field Number> in SC Event.
Explanation The field specified in the action SQL could not be found.
Action Check the full numbers in the returned event map. Specifying the 25th field in a 24 field list also generates this error, as the 25th field does not exist.
Peregrine Writer <name>: Invalid field name for expansion on action SQL.
Explanation An unknown field name was specified in the action SQL for expansion that was neither Serial, ServerSerial, ServerName, or PROBLEM_NUMBER.
Action Correct action SQL.
Peregrine Writer <name>: Unenclosed field expansion request in action SQL <action sql>.
Explanation An unenclosed field expansion was found in the action SQL.
Action This is an expansion not ended with a close parenthesis. Supply the parenthesis.
Peregrine Writer <name>: Failed to send SQL command to Cisco Info Server. SC-to-OS Feedback failed.
Explanation An error occurred when a SQL statement was sent to the feed back Cisco Info Server.
Action When the feed back involved the sending of user defined action SQL, check complete syntax of the action SQL.
Peregrine Writer <name>: Failed to correctly extract the problem number for returned problem open event for serial <serial number>.
Explanation The Cisco Info Gateway could not successfully extract the problem number for the returned ServiceCenter PMO event.
Peregrine Writer <name>: Invalid problem number. Field empty.
Explanation The field index, specified as the field containing the problem number in the returned ServiceCenter PMO event, contained an invalid problem number.
Action Examine the PMO output event mapping and check which field contains the problem number.
Peregrine Writer <name>: Error in the construction of the Open action SQL.
Explanation An error occurred when constructing the open action SQL or the expansion definitions.
Action Check Cisco Info Center the SQL syntax and expansion definitions in the open action SQL.
Peregrine Writer <name>: Failed to create SCAuto Event for journal update.
Explanation An error occurred in the creation of the ServiceCenter event due to insufficient resources.
Action Release memory by stopping unnecessary processes. Increase the machine's available swap space or add more physical memory.
Peregrine Writer <name>: Failed to send journal update event to SC.
Action Examine the ServiceCenter Writer module log file for further details on this error.
Peregrine Writer <name>: Failed to find the COUNTER_PART attribute for the writer. This is necessary due to bi-directional nature.
Explanation The COUNTER_PART attribute is a mandatory attribute that was not specified in the Writer definition.
Action Add the correct attribute to the Writer definition and restart the Cisco Info Gateway.
Peregrine Writer <name>: Is not a name for an Cisco Info Server reader.
Explanation The name specified in the FEEDBACK_SERVER attribute was not the name of an Info Server Reader.
Action Add the correct attribute to the Writer definition and restart the Cisco Info Gateway.
Peregrine Writer <name>: Reader <name>was not found for counter part.
Explanation The specified counter part Reader was not found in the Cisco Info Gateway configuration.
Action Add the correct Reader name in the configuration file and restart the Cisco Info Gateway.
Peregrine Writer <name>: Failed to read the conversions table.
Explanation The Writer failed to read the conversion table.
Action Check whether the conversion files exists. Check the file has the correct field definitions.
Peregrine Writer <name>: Failed to read the system sequence file. Assuming 0000 start.
Explanation The system sequence number could not be read or accessed.
Action Check the existence of the file and that it has read permissions in $OMNIHOME/var.
Peregrine Writer <name>: Invalid system sequence number found in the sequence file <seq num>. Assuming 0 start.
Explanation Corrupted sequence file.
Action Delete the sequence file and restart the Cisco Info Gateway.
Peregrine Writer <name>: SC Event received with error in the evusrseq field.
Explanation A ServiceCenter event was received that contained an invalid value for the evusrseq field.
Action Check the ServiceCenter format control settings for the generation of output events.
Peregrine Writer <name>: Failed to find serial <serial num> in cache for return PMO event.
Explanation Received and returned a PMO event, sent by the Cisco Info Gateway for an opened problem, that was not in the cache and could not be obtained again.
Peregrine Writer <name>: Problem number already determined for serial <serial num>.
Explanation A second return PMO event was received for the same serial number. The problem ticket has already been received.
Action Configure ServiceCenter to only send one PMO return.
Peregrine Writer <name>: Failed to find PM <number> in cache for return PMU event.
Explanation A PMU event was received for a problem that no longer is in the cache and could not be obtained again.
Action The alert may no longer exist in the Cisco Info Server. Check the Cisco Info Server.
Peregrine Writer <name>: Update Feedback Failed.
Explanation An error occurred while attempting to feed back update details to the Cisco Info Server.
Action Examine error messages previous to this message to determine cause of problem.
Peregrine Writer <name>: Failed to find PM <number> in cache for return PMC event.
Explanation A PMC event was received for a problem that is no longer in the cache and could not be obtained again.
Action The alert may no longer exist in the Cisco Info Server. Check the Cisco Info Server.
Peregrine Writer <name>: Close Feedback Failed.
Explanation An error occurred while attempting to feed back close details to the Cisco Info Server.
Action Examine error messages previous to this message to determine cause of problem.
Peregrine Writer <name>: Failed to read SC event from SC Reader Module.
Action Examine the ServiceCenter Reader module log file for further details on this error.
Peregrine Writer <name>: Received event of type <event type> which was unexpected.
Explanation An unexpected event was read by the ServiceCenter Writer module.
Action The Writer module should only read PMO, PMU, and PMC event types. The event returned is ignored.
Peregrine Writer <name>: Failed to block on data feed from SC Reader Module.
Action Examine the ServiceCenter Reader module log file for further details on this error.
Peregrine Writer <name>: Failed to save current eventout system sequence number.
Explanation Could not write the current event out sequence number.
Action Check the write permissions on the sequence file in $OMNIHOME/var.
Peregrine Writer <name>: Failed to shutdown SCAuto Reader/Writer Modules.
Explanation Examine the ServiceCenter Reader/Writer module log files for further details on this error.
Peregrine Writer <name>: Failed to disconnect feedback connection.
Explanation This is a warning message.
Action No action is required.
Peregrine Writer <name>: Failed to delete problem ticket from cache for serial <serial num>.
Explanation This is a warning message.
Action No action is required.
This section describes the integration of Cisco Info Center and Vantive through the Vantive gateway. It is assumed that the reader has administrative experience with Cisco Info Center, as well as an understanding of the Vantive system. It contains the following sections:
The Vantive Enterprise system has a range of integrated applications, each with features developed for a specific business environment. The core business environments are Sales, Support, Field Service, Quality and Help Desk. Each application has unique attributes and features for the particular business function supported, although there are common core technologies that run across all of the applications.
The Vantive Object Studio allows you to tailor the Vantive applications to hold new data, by adding tables to the Vantive database and creating forms to hold the data when they are displayed in Vantive. With the Vantive gateway you will create your own interface. The system enables you to make a new alert record, which can contain all the fields required.
The Vantive alert record should be associated with Vantive user groups, and thereby added to any business environment within the Vantive Enterprise as an independent object. You can also link them into existing Vantive objects or other customized objects, for example, on a Help Desk trouble ticket form you could have a field label that you drill down on to open an alert form.
For information on configuring the Vantive system refer to the "Vantive System Configuration" section.
This chapter contains the following main sections that will help you to implement the Vantive gateway.
You should read the following sections before you attempt to install the gateway.
|
Note The term Vantive alert record, will hereafter be referred to as alert record, and Cisco Info Center alerts will be referred to as alerts. |
For more information about how to use Vantive, refer to the Vantive documentation.
The Vantive gateway is compatible with:
The Vantive gateway is supported on the following platforms for Cisco Info Center2.0:
In a unidirectional implementation, alerts from Cisco Info Center are passed through the gateway to form Vantive alert records. Those alert records can subsequently be updated or closed by another Cisco Info Center alert, but any changes made to the alert records in Vantive are not fed back to Cisco Info Center.
In a bidirectional implementation, alerts from Cisco Info Center are passed through the gateway to form Vantive alert records. Any subsequent changes to those alerts or alert records are reflected in the other application.
Therefore, changes to alerts in Cisco Info Center are reflected in related Vantive alert records and changes to Vantive alert records are reflected in related alerts.
This section describes the operation of the Vantive gateway. The gateway manages four types of event between Vantive and the Info Server. These Vantive event types are:
The codes pmo, pmc, pmu, pmj, associated with each of the event types, are used by the gateway to recognize the type of event being generated.
In summary, for WRITE from Cisco Info Center to Vantive, see below:
pmo (Create an alert record field)
pmc (Set alert record status code to closed)
pmu (Update alert record field)
pmj (Update alert record journal field)
For READ from Vantive to Cisco Info Center, see below:
pmc (Close or delete alert)
pmu (Update alert field)
pmj (Update journal)
The following section describes the functionality of the components and how they work together to maintain Cisco Info Center alerts and Vantive alert records.
The gateway passes information between the Vantive reader and writer modules and the Info Server. New alerts are passed through the gateway to form Vantive alert records. The gateway also feeds back the Vantive alert record ID of new alert records to the Info Server so that alerts can be linked with associated alert records.
Whenever an alert is updated or deleted in the Info Server, the changes are mapped through the gateway to modify the appropriate Vantive alert record. Likewise, if the alert journal is updated in the Info Server, the changes are mapped through the gateway and reflected in the associated Vantive alert record.
If the gateway is bidirectional, changes to any alert record that was originally generated by Cisco Info Center are passed through the gateway and reflected in the associated alert.
|
Note If an alert is deleted in Cisco Info Center, the associated alert record is closed in Vantive and is not deleted. |
The Vantive writer module manages the insertion of Cisco Info Center alerts into Vantive as alert records. There are two key functions that the Vantive writer module performs:
When the gateway writes to Vantive, the writer module provides access to the Vantive database through the Vantive iwserver. This creates a new alert record, adds and saves the alert data, and then sends the record to an Inbox within the Vantive System, for example a Help Desk, where Vantive users can then view it.
When Vantive receives a new alert record, it returns the alert record ID to the Vantive writer module which passes it back through the gateway to be cached in the Info Server. This enables Cisco Info Center to synchronize alerts with their associated alert records.
The Vantive RDBMS is a Sybase, Oracle, Ingres or Microsoft SQL database. It is used to store information required to manage and operate the Vantive suite of applications. It also stores alert records.
The Vantive Event Handlers trigger a Vantive Basic Script in the Vantive Client.
The Echo Server is a simple communications module that receives alert record details from the Vantive Basic Script through nco_tcp_echo, to the nco_echo_server, then forwards any new details to the Vantive Reader Module. The Echo Server is a gateway module, it can be located on the same host as the gateway or the same host as Vantive.
The Echo Server must be running for the bidirectional implementation of the Vantive gateway to work.
The Vantive reader module receives the alert record details from the Echo Server and manages the reflection of the modified Vantive alert records into Cisco Info Center alerts in the alerts.status table.
Bidirectional operation is dependent on properly configured Vantive event handlers and the Echo Server. For configuration details refer to the "Vantive System Configuration" section.
The basic gateway architecture and flow of communications is detailed below. Note that nco_gate will automatically start or stop the nco_vrwmodule7.
Refer to the "Installation" section for a description of how to start the gateway.
The process flow of communications from Cisco Info Center to Vantive is as follows:
nco_objserv > nco_gate > nco_vrwmodule7 (WRITER) > Van API > iwserver > Vantive
The process flow of communications from Vantive to Cisco Info Center is as follows:
Vantive > Event Handler > Vantive Basic Script > nco_tcp_echo > nco_echo_server > nco_vrwmodule7 (READER) > nco_gate > nco_objserv
The following section defines the individual information processes.
The Vantive Event Handlers trigger a Vantive Basic Script in the Vantive Client. This then invokes nco_tcp_echo in order to send information back to the Cisco Info Gateway.
This small binary is installed where it can be accessed by the Vantive Client, and is called by the Vantive Basic Script whenever Cisco Info Center-relevant event handlers are fired. This binary takes text input given to it by the Vantive Basic Script and passes it on to the nco_echo_server over a TCP socket. By default, nco_tcp_echo connects to the nco_echo_server on TCP port 6003.
This binary is resident on the gateway host and acts as a listener for information being sent from nco_tcp_echo (on the Vantive server host). By default, nco_echo_server connects to the nco_vrwmodule7 reader on TCP port 6002. This is the port number you need to specify on the TCP_PORT line in the VAN_GATE.conf configuration file. nco_echo_server writes to $OMNIHOME/log/echo_server.log.
This is the writer component of the nco_vrwmodule7. This process writes new alert records, journal entries, updates and deletes to the Vantive application through the Vantive API. The writer module receives data from nco_gate following an IDUC update from the Info Server. nco_vrwmodule7 (Writer) writes to $OMNIHOME/log/VAN_GATE_VRW_WRITE.log.
This is the reader component of the nco_vrwmodule7. This process handles the information forwarded by nco_echo_server and feeds it to nco_gate for inclusion into an SQL statement (pmo, pmj, pmu, pmc). nco_vrwmodule7 (Reader) writes to $OMNIHOME/log/VAN_GATE_VRW_READ.log.
This is the gateway binary. Vantive information is fed into the nco_gate process and added into the SQL templates loaded into the gateway upon startup. nco_gate then performs the necessary SQL operations on the Info Server. nco_gate writes to $OMNIHOME/log/VAN_GATE.log.
This is the Cisco Info Center Info Server.
The Vantive gateway requires specific configuration during the installation procedure. This section describes the steps involved to help you achieve a clean installation.
The Cisco Info Center installation program installs the files shown in Table 6-33 when you select the Cisco Info Gateway component
| Function | Destination Directory |
|---|---|
Gateway binary | |
Gateway reader or writer module | |
Gateway echo server | |
Example SQL templates for gateway feedback | |
Example Vantive gateway configuration file | |
Table 6-34 shows the directory structure for the Info Server host.
| Function | Destination Directory |
|---|---|
Example | |
Example conversions table | |
Table 6-35 shows the location of the Vantive Server host directory and echo binary file.
| Function | Destination Directory |
|---|---|
Vantive Basic Script | |
TCP echo binary | |
Complete these steps to install the Vantive Info Gateway.
$OMNIHOME/etc/VAN_GATE.conf to suit your environment.
If you are unsure about any of the entries please refer to the "How to Set Up a Unidirectional Vantive Gateway" section of this guide.
Step 2 Ensure that you have created interfaces files on the Info Server and gateway hosts for INFOSERVER and VAN_GATE using $OMNIHOME/bin/nco_xigen.
Step 3 Ensure that you can ping the Vantive Server host from the gateway host.
Step 4 Ensure that you can ping the gateway host from the Vantive Server host.
If Vantive is installed on a Sybase database you can use the embedded Sybase communications layer used by Cisco Info Center. Complete these steps:
Start $OMNIHOME/bin/nco_xigen and create an entry for the target database.
INHFOSERVER.
$OMNIHOME/bin/nco_objserv -name INFOSERVER &Step 2 Enter the following command to start the nco_echo_server.
$OMNIHOME/bin/solaris2/nco_echo_server &Step 3 Start the gateway in debug mode.
$OMNIHOME/bin/nco_gate -name VAN_GATE -debug & It is essential that the nco_echo_server is running before you start nco_gate. If the nco_echo_server is not running, the nco_gate process will exit reporting the following error to VAN_GATE.log:
Error: 16248/10/0: Error in srv_select() - file descriptor 17 is no longer active
This error indicates that a module has failed. Check the log files to see which one.
Your gateway is now connected and running.
The following processes should be running:
/opt/Omnibus/bin/solaris2/nco_vrwmodule7 DEBUG VAN_GATE_%s_WRITE /opt/Omnibus/bin/solaris2/nco_gate -name VAN_GATE -debug /opt/Omnibus/bin/solaris2/nco_vrwmodule7 DEBUG VAN_GATE_%s_READ
If the gateway exits unexpectedly, inspect the three gateway logfiles in $OMNIHOME/log. Contact Technical Support if you are not sure what the error message means. The most useful of the logfiles is the WRITER logfile:
$OMNIHOME/log/VAN_GATE_VRW_WRITE.log
This is the gateway interface into Vantive. If any problems are encountered, run the gateway in debug mode then check the following files:
VAN_GATE_WRITE.log
VAN_GATE.log
VAN_GATE_READ.log
This section describes how to configure your Vantive System to work with the Cisco Info Center Vantive gateway using Object Studio. You must create an Object and forms for the Cisco Info Center alert data. However, there is no provision for defining objects and forms using Vantive's programming API, and hence the Vantive gateway also, so these must be created using the Vantive methodology.
The following sections describe the following steps for creating your object and forms to hold Cisco Info Center alert information.
In your Vantive database you must create a table that can hold Cisco Info Center alert information, for example, table name VG_STATUS. This is necessary before you can define a Vantive object and form with Vantools and VanDesign.
In the example below the columns from the Cisco Info Center status and journal table have been duplicated in the table VG_STATUS, and are prefixed with vg, and the other columns are used by Vantive.
Mandatory columns that the Vantive gateway needs to work are the following:
ID_COLUMN (for example, vgStatusId).
USER_COLUMN (for example, swCreatedBy)
LOCATION_COLUMN (for example, vgLocation)
STATUS_COLUMN (for example, vgAlertStatus)
SERVER_NAME_COLUMN (for example, vgServerName)
SERVER_SERIAL_COLUMN (for example, vgServerSerial)
JOURNAL_COLUMN (for example, vgJournal)
Create a second table that Vantive uses to create a unique ID for each record, for example, table name VG_STATUS_ID.
Define the primary key for your alert table.
Define an index for your alert table.
Seed the alert ID table with a starting ID value.
Grant Vantive's SWB user access to the alert table and the alert ID table.
Create status codes for your status column in Vantive's code value table. You must have at least a new and closed code to enable the gateway to close an alert record in Vantive when an alert is deleted in Cisco Info Center.
The following section is an example of a Sybase SQL File (vg_status.syb):
----------------------------------------------------- -- A. Create Omnibus status table in Vantive database ----------------------------------------------------- use vantive go --drop table VG_STATUS --go create table VG_STATUS ( vgStatusId NUMERIC(15,5) NOT NULL, vgIdentifier VARCHAR(255) NOT NULL, vgSerial NUMERIC(16) NOT NULL, vgNode VARCHAR(64) NULL, vgNodeAlias VARCHAR(64) NULL, vgManager VARCHAR(64) NULL, vgAgent VARCHAR(64) NULL, vgAlertGroup VARCHAR(64) NULL, vgAlertKey VARCHAR(64) NULL, vgSeverity NUMERIC(1) NULL, vgSummary VARCHAR(255) NULL, vgStateChange DATETIME NULL, vgFirstOccurrence DATETIME NULL, vgLastOccurrence DATETIME NULL, vgInternalLast DATETIME NULL, vgPoll NUMERIC(16) NULL, vgType NUMERIC(16) NULL, vgTally NUMERIC(16) NULL, vgClass NUMERIC(16) NULL, vgGrade NUMERIC(16) NULL, vgLocation VARCHAR(64) NULL, vgOwnerUID NUMERIC(16) NULL, vgOwnerGID NUMERIC(16) NULL, vgAcknowledged NUMERIC(16) NULL, vgFlash NUMERIC(16) NULL, vgServerName VARCHAR(64) NULL, vgServerSerial NUMERIC(16) NULL, vgJournal TEXT NULL, swAlertStatus CHAR(30) NULL, swCreatedBy CHAR(20) NOT NULL, swDateCreated DATETIME NOT NULL, timestamp CHAR(16) NULL, PRIMARY KEY (vgStatusId) ) go ----------------------------------------------------- -- B. Create the Corresponding ID table for VG_STATUS ----------------------------------------------------- --drop table VG_STATUS_ID --go create table VG_STATUS_ID ( swId NUMERIC(15,5) NOT NULL, swMaxId NUMERIC(15,5) NULL, timestamp CHAR(16) NULL ) go -------------------------------------------------------------- -- C. Define the primary keys for the Vantive Dictionary table -------------------------------------------------------------- sp_primarykey VG_STATUS, vgStatusId -------------------- -- D. Define Indexes -------------------- create unique index vgstatus01 on VG_STATUS (vgStatusId) go ------------------------------------------- -- E. Seed the ID table with initial values ------------------------------------------- insert into VG_STATUS_ID (swId, swMaxId) values(0, 100000) go --------------------------------------- -- F. Grant permissions to the user swb --------------------------------------- grant all on VG_STATUS to swb go grant all on VG_STATUS_ID to swb go ----------------------------------------- -- G. Seed Alert Status data into Vantive ----------------------------------------- --delete from SW_VALID_CODE where swName = 'Alert Status' --go insert into SW_VALID_CODE( swName, swValue, swDefault, swOrder, swDescription, swCreatedBy, swDateCreated, timestamp ) values( 'Alert Status', 'Assigned', 0, 4, NULL, 'Omnibus', 'Jan 31 1999 12:45AM', '' ) go insert into SW_VALID_CODE( swName, swValue, swDefault, swOrder, swDescription, swCreatedBy, swDateCreated, timestamp ) values( 'Alert Status', 'New', 1, 4, NULL, 'Omnibus', 'Jan 31 1999 12:45AM', '' ) go insert into SW_VALID_CODE( swName, swValue, swDefault, swOrder, swDescription, swCreatedBy, swDateCreated, timestamp ) values( 'Alert Status', 'Closed', 0, 4, NULL, 'Omnibus', 'Jan 31 1999 12:45AM', '' ) go insert into SW_VALID_CODE( swName, swValue, swDefault, swOrder, swDescription, swCreatedBy, swDateCreated, timestamp ) values( 'Alert Status', 'Rejected', 0, 4, NULL, 'Omnibus', 'Jan 31 1999 12:45AM', '' ) go
In the Vantools executable you need to:
VG_STATUS and VG_STATUS_ID
To create the new tables you must enter table and column information for your alert table and alert ID table. Use the Vantive methodology to do this, as in the following example procedure:
Step 2 Set the Table Name to VG_STATUS.
Step 3 Set the ID table to VG_STATUS_ID.
Step 4 Set the ID column to vgStatusId.
Step 5 Add a description.
Step 6 Select the Columns tab, then select New.
Step 7 Enter all the column names, including any descriptions. Click on New before entering each column.
Step 8 Save the changes.
Step 9 Select File and then New and select the Table Information tab.
Step 10 Set the Table Name to VG_STATUS_ID.
Step 11 Add a description.
Step 12 Save the changes.
To create an alert object you must enter the object name, base table and menu label. You must also set the Utility Menu options for sending and dispatching action requests, and assign the object group permissions, as described in the following example procedure:
Step 2 Enter an Object Name as 'ALERT'.
Step 3 Set the Base Table to VG_STATUS.
Step 4 Enter a Menu label as `Alert'.
Step 5 Add a description.
Step 6 Select the Utility Menu tab, then select New.
Step 7 Set the Menu command to Dispatch.
Step 8 Save the changes.
Step 9 Select the Utility Menu tab, then select New.
Step 10 Set the Menu command to Send.
Step 11 Save the changes.
Step 12 Select the Group Permission tab, then select New.
Step 13 Set the Group Name to Help Desk Admin.
Step 14 Set permissions by selecting Create New, Read, Update, and Delete.
Step 15 Save the changes.
In the VanDesign executable, create the following five forms:
The Main Info form holds the data as presented to the user, while the other forms are used for Vantive search operations.
Enter all the required columns from your table (VG_STATUS) as form fields and enter their properties. The labels used on the form fields must be used in the mappings in the gateway configuration file in order to match which fields should be set with data from Cisco Info Center.
The following example procedure uses two pages, with the Journal field on the second page and the other fields on the first page.
The following example procedure describes how to create the first page:
Step 2 Enter the Form Name as vgStatusScr.
Step 3 Set the Table Name to VG_STATUS.
Step 4 Set the Screen Type to Main Info.
Step 5 Add a description.
Step 6 Right-click on the form to bring up the context sensitive menu.
Step 7 Select Properties.
Step 8 Enter the Title as Netcool/OMNIbus Alert.
Step 9 Set the Title Column to vgStatusId.
Step 10 Add a description.
Step 11 Select View.
Step 12 Show the desired palettes.
Step 13 Add and position form fields for each of the columns in the table, with the exception of the ID column vgStatusId.
Step 14 Right-click on each field to bring up the context sensitive menus.
Step 15 Select Properties, then select the Data tab.
Step 16 Set the Column Path to the table column holding the data for the field.
Step 17 Set the fields for Identifier, Serial, Created By and Date Created as required.
Step 18 Select the Visual tab.
Step 19 Set the label and alignment.
Table 6-36 shows the database column names against the field labels used to create the example form
.
| Database Column | Field Label |
|---|---|
| Identifier |
| Summary |
| Alert Key |
| Node |
| Node Alias |
| Alert Group |
| Agent |
| Manager |
| Location |
| Server Name |
| First Occurrence |
| Last Occurrence |
| State Change |
| Internal Timestamp |
| Serial |
| Severity |
| Count |
| Owner |
| Group |
| Type |
| Class |
| Grade |
| Poll |
| Flash |
| Acknowledged |
| Server Serial |
| Status |
| Created By |
| Date Created |
The following example procedure describes how to create the second page:
Step 2 Enter the Page Label as Journal, then click Ok.
Step 3 Add and position a form field for the Journal column on the new page.
Step 4 Right-click the field to display a context sensitive menu.
Step 5 Select Properties, then select the Data tab.
Step 6 Set the column path to the Journal column.
Step 7 Select the Visual tab.
Step 8 Set the label and alignment as shown in Table 6-37.
.
| Database Column | Field Label |
|---|---|
| Journal |
You now need to enter the required columns from VG_STATUS as form fields and enter the properties.
The following example procedure describes how to create the Criteria Open Locator form:
Step 2 Enter the Form Name as vgStatusOSelScr.
Step 3 Set the Table Name to VG_STATUS.
Step 4 Set the Screen Type to Criteria Open Locator.
Step 5 Add a description.
Step 6 Add and position form fields for each required column in the table, with the exception of the ID column vgStatusId.
Step 7 Right-click on each field to bring up the context sensitive menus.
Step 8 Select Properties, then select the Data tab.
Step 9 Set the Column Path to the table column holding the data for the field.
Step 10 Select the Visual tab.
Step 11 Set the label and alignment.
Enter all the required columns from VG_STATUS as form fields and enter properties as described in the following example procedure:
Step 2 Enter the Form Name as vgStatusFSelScr.
Step 3 Set the Table Name to VG_STATUS.
Step 4 Set the Screen Type to Criteria Search Locator.
Step 5 Add a description.
Step 6 Add and position form fields for each required column in the table, with the exception of the ID column vgStatusId.
Step 7 Right-click on each field to bring up the context sensitive menu.
Step 8 Select Properties, then select the Data tab.
Step 9 Set the Column Path to the table column holding the data for the field.
Step 10 Select the Visual tab.
Step 11 Set the label and alignment.
Enter all the required columns and labels as described in the following example procedure:
Step 2 Enter the Form Name as vgStatusOListScr.
Step 3 Set the Table Name to VG_STATUS.
Step 4 Set the Screen Type to Summary Open Locator.
Step 5 Add a description.
Step 6 Select the Data tab.
Step 7 Add a description.
Step 8 Select the Fields tab, then select New.
Step 9 Enter the Field label, Column Path and Display Width for the columns you would like to see at the top of an Open Alert Window, clicking on New before entering each column.
Step 10 Save the changes.
r
Enter all the required columns and labels as described in the following example procedure:
Step 2 Enter the Form Name as vgStatusFListScr.
Step 3 Set the Table Name to VG_STATUS.
Step 4 Set the Screen Type to Summary Search Locator.
Step 5 Add a description.
Step 6 Select the Data tab.
Step 7 Add a description.
Step 8 Select the Fields tab, then select New.
Step 9 Enter the Field label, Column Path and Display Width for the columns you would like to see at the top of a Search - Alert Window, clicking on New before entering each column.
Step 10 Save the changes.
In the Vantools executable, assign Form Permissions for each of the forms to the required user group, so that the group can use them. For example:
Step 2 Click on Search.
Step 3 Double-click on the group you want to be able to access the forms, for example Help Desk Admin.
Step 4 Select the Forms tab, then select New.
Step 5 Set the form type and form name, clicking on New before entering each form.
Step 6 Save the changes.
You may also want to create an Omnibus user as a member of your target user group, and set it in the gateway configuration file as the user to enable the gateway to connect to Vantive. For example:
Step 2 Enter User Login Name.
Step 3 Set Default Inbox.
Step 4 Set Group Name.
Step 5 Set Mobile Group Name.
Step 6 Save the changes.
Step 7 Select New.
Step 8 Set Inbox Name.
Step 9 Set Display Form.
Step 10 Save the changes.
To do this you need to:
To seed the action priority table with values you need to insert suitable values in your Vantive Action Priority Table in the database. An example of a Sybase SQL file that seeds the Action Priority Table with values is listed below:
---------------------------------------------------- -- Seed Vantive's Action Priority Table with values ---------------------------------------------------- use vantive go --delete from SW_VAL_ACT_PRI -- where swObjectType = 'ALERT' --go insert into SW_VAL_ACT_PRI( swObjectType, swPriority, swOrder, swDescription, swCreatedBy, swDateCreated ) values( 'ALERT', 'Critical', 6, 'NetCool Omnibus Alert', 'saint', '' ) go insert into SW_VAL_ACT_PRI( swObjectType, swPriority, swOrder, swDescription, swCreatedBy, swDateCreated ) values( 'ALERT', 'Major', 5, 'NetCool Omnibus Alert', 'saint', '' ) go insert into SW_VAL_ACT_PRI( swObjectType, swPriority, swOrder, swDescription, swCreatedBy, swDateCreated ) values( 'ALERT', 'Minor', 4, 'NetCool Omnibus Alert', 'saint', '' ) go insert into SW_VAL_ACT_PRI( swObjectType, swPriority, swOrder, swDescription, swCreatedBy, swDateCreated ) values( 'ALERT', 'Warning', 3, 'NetCool Omnibus Alert', 'saint', '' ) go insert into SW_VAL_ACT_PRI( swObjectType, swPriority, swOrder, swDescription, swCreatedBy, swDateCreated ) values( 'ALERT', 'Indeterminate', 2, 'NetCool Omnibus Alert', 'saint', '' ) go insert into SW_VAL_ACT_PRI( swObjectType, swPriority, swOrder, swDescription, swCreatedBy, swDateCreated ) values( 'ALERT', 'Clear', 1, 'NetCool Omnibus Alert', 'saint', '' ) go insert into SW_VAL_ACT_PRI( swObjectType, swPriority, swOrder, swDescription, swCreatedBy, swDateCreated ) values( 'ALERT', '5', 6, 'NetCool Omnibus Alert', 'saint', '' ) go insert into SW_VAL_ACT_PRI( swObjectType, swPriority, swOrder, swDescription, swCreatedBy, swDateCreated ) values( 'ALERT', '4', 5, 'NetCool Omnibus Alert', 'saint', '' ) go insert into SW_VAL_ACT_PRI( swObjectType, swPriority, swOrder, swDescription, swCreatedBy, swDateCreated ) values( 'ALERT', '3', 4, 'NetCool Omnibus Alert', 'saint', '' ) go insert into SW_VAL_ACT_PRI( swObjectType, swPriority, swOrder, swDescription, swCreatedBy, swDateCreated ) values( 'ALERT', '2', 3, 'NetCool Omnibus Alert', 'saint', '' ) go insert into SW_VAL_ACT_PRI( swObjectType, swPriority, swOrder, swDescription, swCreatedBy, swDateCreated ) values( 'ALERT', '1', 2, 'NetCool Omnibus Alert', 'saint', '' ) go insert into SW_VAL_ACT_PRI( swObjectType, swPriority, swOrder, swDescription, swCreatedBy, swDateCreated ) values( 'ALERT', '0', 1, 'NetCool Omnibus Alert', 'saint', '' ) go
An action request code allows you to request that an alert is sent to an Inbox using a send action. Define an action request code for the send action in the Vantools executable. For example:
Step 2 Enter New Value as Send and press Return.
Step 3 In Action Defaults, set the Priority value, for example Warning.
Step 4 Save the changes.
You need to create event handlers for your object's Main Info Form. You must have two event handlers for the two Vantive basic functions in the VantiveBasicScript.txt that is provided with the gateway as shown in Table 6-38.
| Event Type | Primary Procedure Call |
|---|---|
Pre Update Record | |
Post Update Record | |
To create event handlers for your object's Main Info Form, use the following example procedure:
Step 2 Double-click on VG_STATUS.
Step 3 Double-click Main Info.
Step 4 Double-click on vgStatusScr.
Step 5 Right-click on the form to bring up the context sensitive menu.
Step 6 Select Properties, then select the Events tab. Form Properties Events Tab
Step 7 Select New.
Step 8 Set the Event Type to PreUpdate Record.
Step 9 Set the Procedure Type to Client Basic Function.
Step 10 Enter the Procedure Call as PreUpdateRecord.
Step 11 Apply the changes.
Step 12 Select New.
Step 13 Set the Event Type to PostUpdate Record.
Step 14 Set the Procedure Type to Client Basic Function.
Step 15 Enter the Procedure Call as PostUpdateRecord.
Step 16 Apply the changes.
To create a new Vantive Basic script, use the following procedure:
Step 2 In the Script window enter the name of the script, for example Cisco Info Center Alerts. Click on OK.
Step 3 Open the VantiveBasicScript.txt file in a text editor.
Step 4 Copy the entire contents to the Script Text window of the Vantive Forms Designer.
Step 5 Click on Compile, then click on Save.
The VantiveBasicScript.txt file is listed below.
'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
''' Add the settings here
'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
Const PROGRAM as String = ""
Const LOCATION_COLUMN as String = ""
Const TABLE_NAME as String = ""
'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
''' Leave everything below unchanged
'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
Const DELIMITER as String = "^"
Const SPACE as String = " "
Const QUOTES as String = Chr$(34)
Const CARRIAGE_RETURN as String = Chr$(13)
Const LINEFEED as String = Chr$(10)
Const UPDATE as String = "UPDATE"
Dim ECHO_MSG as String
Dim LOCATION as String
'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
Function PreUpdateRecord
Dim frm as Form
Dim fld as Field
Dim result() as String
Dim datetime as String
timenow# = Now()
datetime = Format$( timenow#, "General date" )
ECHO_MSG = PROGRAM & SPACE & QUOTES _
& DELIMITER & UPDATE & DELIMITER _
& datetime & DELIMITER
pagecount% = Application.FocusWindow.NumPages
LOCATION = SPACE
''' Find the location to use for identifying the record
For page% = 1 To pagecount%
Set frm = Application.FocusWindow.Page(page%).Form
num% = frm.NumFields
''' Is the location on the current page
For index% = 1 to num%
Set fld = frm.Field(index%)
if fld.Column.ColumnName = LOCATION_COLUMN then
LOCATION = fld.Value
end if
Next index%
Next page%
''' Build where clause and retrieve data from database
if LOCATION <> SPACE then
For page% = 1 To pagecount%
Set frm = Application.FocusWindow.Page(page%).Form
num% = frm.NumFields
For index% = 1 to num%
Set fld = frm.Field(index%)
clause = "select"& SPACE _
& fld.Column.ColumnName & SPACE _
& "from" & SPACE _
& TABLE_NAME & SPACE _
& "where" & SPACE _
& LOCATION_COLUMN & SPACE _
& "=" & SPACE & QUOTES _
& LOCATION & QUOTES
numRows% = Application.SQL(clause, result)
ECHO_MSG = ECHO_MSG _
& fld.Column.ColumnName & DELIMITER _
& result(0,0) & DELIMITER
Next index%
Next page%
end if
End Function
'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
Function PostUpdateRecord
Dim id as Variant
Dim frm as Form
Dim fld as Field
Dim result() as String
Dim datetime as String
''''
'''Open "vantest.dat" For Output As #1
''''
timenow# = Now()
datetime = Format$( timenow#, "General date" )
ECHO_MSG = ECHO_MSG & UPDATE & DELIMITER _
& datetime& DELIMITER
pagecount% = Application.FocusWindow.NumPages
''' Build where clause and retrieve data from database
if LOCATION <> SPACE then
For page% = 1 To pagecount%
Set frm = Application.FocusWindow.Page(page%).Form
num% = frm.NumFields
For index% = 1 to num%
Set fld = frm.Field(index%)
clause = "select" & SPACE _
& fld.Column.ColumnName & SPACE _
& "from" & SPACE _
& TABLE_NAME & SPACE _
& "where" & SPACE _
& LOCATION_COLUMN & SPACE _
& "=" & SPACE & QUOTES _
& LOCATION & QUOTES
numRows% = Application.SQL(clause, result)
ECHO_MSG = ECHO_MSG _
& fld.Column.ColumnName & DELIMITER _
& result(0,0) & DELIMITER
Next index%
Next page%
end if
ECHO_MSG = ECHO_MSG & QUOTES
''' Strip newline characters and replace with spaces
startch% = 1
While startch% <> 0
startch% = InStr( startch%, ECHO_MSG, CARRIAGE_RETURN, 1 )
if startch% <> 0 then
Mid( ECHO_MSG, startch%, 1 ) = SPACE
end if
Wend
''''
''' Print #1,ECHO_MSG
''' Close #1
''''
id = Shell(ECHO_MSG, ebHide)
End Function
To run the gateway, enter the following command:
$OMNIHOME/bin/nco_gate -name VAN_GATE & where VAN_GATE is the name of the gateway server.
Assuming that all command lines are running correctly, you are now ready to start configuring the gateway. Refer to the "How to Set Up a Unidirectional Vantive Gateway" section and the "Vantive System Configuration" section for full configuration details.
When the gateway is started, the following initiation sequence takes place:
1. The gateway is started.
2. The gateway uses the writer attributes, USER and PASSWORD to contact the Vantive writer module which opens a connection to Vantive.
When an alert is passed through the gateway, the following alert record generation sequence takes place:
1. An alert is read from the Info Server.
2. The alert is mapped into open alert record attributes and passed to the Vantive writer module.
3. The Vantive writer module uses the alert record attributes to create an alert record. It then sends the alert record and the query to Vantive.
4. Vantive creates a new record for the alert in the Vantive database and returns the alert ID to the Vantive writer module.
5. The Vantive writer module passes the alert record ID to the gateway.
6. The gateway reads the alert record ID and adds it to the associated alert in the feedback field of the Info Server.
The Info Server now holds the alert and Vantive holds its associated alert record. The alert and the alert record are related by the common alert record ID. The serial and ID are both stored in a gateway cache.
When an alert is changed in the Info Server, the following alert record modification sequence takes place:
1. An alert is read from the Info Server.
2. The alert is mapped into alert record attributes according to its alert type and passed to the Vantive writer module.
3. The Vantive writer module uses the alert record attributes to create an alert record update request. It then sends the request into Vantive.
4. Vantive receives the alert record update request and updates the alert record.
The change that was made to the alert in the Info Server is now reflected in the associated Vantive alert record.
Vantive has event handlers that you can add to an object's form, and for the alert object two event handlers need to be created. These are for Pre Update and Post Update events.
In the bidirectional implementation of the Vantive gateway, when an alert record (that was originally generated from an alert) is modified in Vantive, the following sequence of events takes place:
1. An event will trigger an event handling which will call a Client Basic function in the Vantive Basic Script. The PreUpdateRecord event will trigger the PreUpdateRecord function, which will be followed by a PostUpdateRecord event which will trigger the PostUpdateRecord function.
2. The PreUpdate function queries the database and builds up a string holding all the data before the alert was changed.
3. The PostUpdate function then queries the database and adds the alert data after it was changed to the end of the string. It then runs nco_tcp_echo with that string and sends it to nco_echo_server which forwards it to the gateway module.
4. When the module receives the string holding data from both PreUpdate and PostUpdate, it compares the two sets of data and decides whether to send a close, update or a journal event to the main gateway.
5. The gateway then forwards the details to the associated alert in the Info Server.
|
Note The change that was made to the Vantive alert record is now reflected in the associated Cisco Info Center alert. |
This section describes how to configure Cisco Info Center and Vantive to create Vantive alert records from Cisco Info Center alerts. When you have completed the configuration described in this section, you should have a working unidirectional implementation of the gateway. You will also have completed the first stage of the implementation of a bidirectional gateway.
To configure alert record generation, you need to:
1. Create the gateway configuration file.
2. Configure the Vantive System for the gateway, as described in the "Vantive System Configuration" section.
The Vantive gateway configuration file comprises seven components:
The Info Server reader and the Info Server route are standard gateway components. The other components are gateway specific.
Mappings in the Vantive gateway configuration file must use the following syntax:
CREATE MAPPING mappingname ( `VantiveFieldname' = '@fieldname' [ CONVERT TO DATE | CONVERT TO INTEGER ], ... , [ VantiveFieldname = 'string'], ... , [ VantiveFieldname = variablename], ... ) ;
Where mappingname is the name of the map configuration to be created.
VantiveFieldname is the name of a Vantive alert record field to which a value is assigned.
@fieldname is the name of a field in the Info Server alerts.status table.
string is the value of a static variable that cannot be changed by either Cisco Info Center or Vantive.
For example, you could decide that the AlertGroup field should always have the value Cisco Info Center alert record:
'AlertGroup' = 'Cisco Info Center Alert record',
variablename is the name of a system variable supplied by the gateway. This can be either PROBLEM_NUMBER or JOURNAL_TEXT. When used, the current contents of these variables are substituted in the assigned fields. PROBLEM_NUMBER is propagated with the Vantive alert record ID of the alert. It can only be used in update, close maps and journals. JOURNAL_TEXT holds the journal text and can only be used in a journal map.
The optional CONVERT TO DATE allows the mapping to define a forced conversion to a date type field. Also, CONVERT TO INTEGER allows the mapping to define a forced conversion for long integer field types.
A field can be made up of many values, for example:
`title' = `alert record + @Serial + created + by + @UID + at + @FirstOccurence^'
Note the ^ symbol at the end of the string. This symbol means convert this token to date.
The Vantive open map defines the values that will be assigned to Vantive alert record fields when a new alert is read from the Info Server. When a new alert record is opened, the Vantive alert record ID does not exist, so the PROBLEM_NUMBER cannot be assigned to a Vantive alert record field. The following shows an example mapping:
CREATE MAPPING VAN_OPEN
(
'Acknowledged' = '@Acknowledged',
'Alert Group' = '@AlertGroup',
'Alert Key' = '@AlertKey',
'Agent' = '@Agent',
'Class' = '@Class',
'First Occurrence' = '@FirstOccurrence' CONVERT TO DATE,
'Flash' = '@Flash',
'Grade' = '@Grade',
'Identifier' = '@Identifier',
'Internal Timestamp' = '@InternalLast' CONVERT TO DATE,
'Last Occurrence' = '@LastOccurrence' CONVERT TO DATE,
'Location' = '@Location',
'Manager' = '@Manager',
'Owner' = '@OwnerUID',
'Group' = '@OwnerGID',
'Node' = '@Node',
'Node Alias' = '@NodeAlias',
'Poll' = '@Poll',
'Serial' = '@Serial',
'Severity' = '@Severity',
'Server Name' = '@ServerName',
'Server Serial' = '@ServerSerial',
'State Change' = '@StateChange' CONVERT TO DATE,
'Summary' = '@Summary',
'Count' = '@Tally',
'Type' = '@Type'
);
In your open map you must have a field in Vantive set with the at least one of the following values:
@Serial @ServerName @ServerSerial
The two which are recommended are @ServerName and @ServerSerial. These must also be present in a matching field on fields in the Vantive Close Map, for example:
`Server Serial' = `@ServerSerial' `Server Name' = `@ServerName'
The reason for this matching requirement is that when a gateway starts, its serial and alert record ID cache is not populated. Therefore any close alert events cannot be forwarded to Vantive without this field being set.
The Vantive update map defines the values that will be assigned to Vantive alert record fields when an alert is updated in the Info Server. The variable PROBLEM_NUMBER is populated with the alert record ID that was assigned to the alert record when it was created. This variable ensures that the alert is used by the Vantive writer module to update the correct alert record.
The following shows an example mapping:
CREATE MAPPING VAN_UPDATE
(
'PROBLEM_NUMBER' = PROBLEM_NUMBER,
'Acknowledged' = '@Acknowledged',
'Agent' = '@Agent',
'Alert Group' = '@AlertGroup',
'Alert Key' = '@AlertKey',
'Class' = '@Class',
'First Occurrence' = '@FirstOccurrence' CONVERT TO DATE,
'Flash' = '@Flash',
'Grade' = '@Grade',
'Identifier' = '@Identifier',
'Internal Timestamp' = '@InternalLast' CONVERT TO DATE,
'Last Occurrence' = '@LastOccurrence' CONVERT TO DATE,
'Location' = '@Location',
'Manager' = '@Manager',
'Owner' = '@OwnerUID',
'Group' = '@OwnerGID',
'Node' = '@Node',
'Node Alias' = '@NodeAlias',
'Poll' = '@Poll',
'Serial' = '@Serial',
'Severity' = '@Severity',
'Server Name' = '@ServerName',
'Server Serial' = '@ServerSerial',
'State Change' = '@StateChange' CONVERT TO DATE,
'Summary' = '@Summary',
'Count' = '@Tally',
'Type' = '@Type'
);
The Vantive close map is used when an alert is deleted from the Info Server to close the associated Vantive alert record. The map only assigns the PROBLEM_NUMBER value to uniquely identify the Vantive case to be closed.
A close event sent from Cisco Info Center to Vantive will set the status column to the close code.
The following shows an example mapping:
CREATE MAPPING VAN_CLOSE
(
'PROBLEM_NUMBER' = PROBLEM_NUMBER,
'Server Name' = '@ServerName',
'Server Serial' = '@ServerSerial'
);
Note that the example `Server Serial' = `@ServerSerial' `Server Name' = `@ServerName'matches the Vantive Open Map map example.
The Vantive journal map is used to update the journal field of an alert record when the associated alert journal is updated. The variable PROBLEM_NUMBER is populated with the alert record ID to ensure that the journal is added to the correct alert record. The JOURNAL_TEXT variable is used to assign the new journal entry.
The following shows an example mapping:
CREATE MAPPING VAN_JOURNAL
(
'PROBLEM_NUMBER' = PROBLEM_NUMBER,
'JOURNAL_TEXT' = JOURNAL_TEXT
);
This section describes the writer attributes that are required to establish a connection between the gateway and Vantive. Some of the attributes are only required to enable Vantive alert records to modify Cisco Info Center alerts, these attributes are described in the "How to Set Up a Bidirectional Vantive Gateway" section.
Table 6-39 lists the Vantive Gateway Writer attributes.
| Attribute Name | Mandatory | Description |
|---|---|---|
| Yes | Identifies the type of writer, must be set to a value of |
| Yes | Revision of writer. For this release, this must be set to a value of |
| Yes | Name of the open map. |
| Yes | Name of the update map. |
| Yes | Name of the close map. |
| Yes | Name of the journal map. |
| Yes | Name of the host server on which the Vantive Server iwserver is running. |
| Yes | Name of the host port on which the Vantive Server is running. The default is "". |
| No | Used to specify the machine where the Echo Server is running. The default is |
| No | Used to specify the writer port for the Echo Server. The default is |
| Yes | The name of the user to be used to login to Vantive. |
| Yes | The password used to login to Vantive (if one is required). Can be specified as a null. |
| Yes | This must have a value of |
| Yes | Name of the Info Server to which the gateway feedback mechanism writes the Vantive alert record ID. |
| Yes | Name of the field in the feedback Info Server alert to which the Vantive alert record ID is written. |
| Yes | Must have a value of |
| No | Used in bidirectional implementations. See "How to Set Up a Bidirectional Vantive Gateway". |
| No | Used to select the Vantive version number. The default is 7. |
| No | Used in bidirectional implementations. Refer to "How to Set Up a Bidirectional Vantive Gateway". |
| No | Used in bidirectional implementations. Refer to "How to Set Up a Bidirectional Vantive Gateway". |
| No | Used in bidirectional implementations. Refer to "How to Set Up a Bidirectional Vantive Gateway". |
| No | Used in bidirectional implementations. Refer to "How to Set Up a Bidirectional Vantive Gateway". |
| Yes | Name of the conversions table in the Info Server that holds the data values of required conversions between Vantive and Cisco Info Center fields. |
| Yes | Date conversion specification. The default is |
| Yes | Date conversion specification. The default is |
| Yes | The Poll database is set to |
| Yes | The name of the alert object in Vantive. The default is |
| Yes | The name of the alert object's ID column in the Vantive database. The default is |
| Yes | The name of the alert object's column in the Vantive database, that identifys the user who created the alert record. The default is |
| Yes | The name of the alert object's column in the Vantive database, where the alert record ID is written. This should be equivalent to the feedback field in the Info Server ( |
| Yes | The value to set in the alert object's status column when the writer module receives a close code from the Info Server. This should be one of the values seeded in the |
| Yes | The name of the alert object's status column in the Vantive database. The default is |
| Yes | The name of the alert object's column in the Vantive database, which holds the alert's Server Name value. The default is |
| Yes | The name of the alert object's column in the Vantive database, which holds the alert's Server Serial value. The default is |
| Yes | The name of the alert object's column in the Vantive database, which holds the alert's journal text. The default is |
| Yes | The name of the Inbox in Vantive that alerts records are sent to. The default value is ''. |
| Yes | The default is |
| Yes | The name of the alert object's column in the Vantive database, which holds the alert's Severity value. The default is |
|
Note If the database poll is set to ON, then the writer module will query the database every time a new alert is received, and attempt to match the alert record's form field labels to alert fields as defined by mappings in the VAN_GATE.conf. Should the order of the form fields change while the gateway is still running, due to changes made to in Vantive, the gateway will attempt to continue writing alerts to Vantive using the VAN_GATE.conf mappings. If the database poll is set to OFF, then the writer module will query the database when the gateway first starts up, and will match the alert object's form field labels to alert fields as defined by mappings in the VAN_GATE.conf. It will then cache this information and continue to use it during the rest the gateway operation. The recommended setting is OFF for performance reasons. It is also advisable not to make changes to the alert object in Vantive, while the gateway is running. |
When the gateway is reading alert data from Vantive, the Vantive Basic script has to query the database to enable the reader module to compare the alert data before and after a change has been saved in order to identify what type of event it is (Update, Journal or Close). The script also obtains the event time by running a Vantive Basic function. These two dates are in different formats which is why there needs to be two formats in the gateway config file.
For example:
Where DB is the database and VB is the Vantive Basic.
VB_DATE_FORMAT = '%m/%d/%y %H:%M:%S %p', DB_DATE_FORMAT = '%b %d %Y %H:%M:%S:%f%f%f%p',
An extra conversion character is used in the gateway config file when specifying date formats in addition to the standard ones currently defined by strptime.
In the above example DB_DATE_FORMAT, the conversion specification %f is used to filter out three characters that should be ignored.
This section describes how to configure Cisco Info Center and Vantive so that changes made to Vantive alert records are reflected in Cisco Info Center. When you have completed the configuration described in this section, you should have a working bidirectional implementation of the gateway. Before you configure the applications, as described in this section, you should already have created a unidirectional gateway (refer to the "How to Set Up a Unidirectional Vantive Gateway").
To configure the alert modification, you need to:
1. Define action request code.
2. Create event handlers.
3. Enter Vantive basic script.
4. Enter bidirectional attributes in the Vantive gateway configuration file.
When you have configured the action request code, event handlers and the Vantive basic script, you are ready to run the bidirectional Vantive gateway. Before you run the gateway, however, you should ensure that the Echo Server is running.
Each of the configuration steps is described in the "Vantive System Configuration" section.
Once there is bidirectional communications up and running, take the gateway out of debug mode and put it under PA along with other local Cisco Info Center components, such as Info Server or probes.
The configuration detailed in this document is designed to provide a framework for further development. The gateway is capable of performing complex operations on Vantive over the API.
This section describes the command line options for the nco_tcp_echo command and the Echo Server (nco_echo_server).
The nco_tcp_echo command has the following format:
nco_tcp_echo -hostname string -writer_port numeric -helpTable 6-40 lists the command line parameters for the nco_tcp_echo command.
| Option | Parameter | Description |
|---|---|---|
hostname | string | The name of the host machine where the Echo Server is running. |
writer_port | numeric | The port number to write to the Echo Server. |
help |
| Displays help on the command line options. |
The nco_echo_server command has the following format:
nco_echo_server -messagelog string -reader_port numeric -writer_port numeric -helpTable 6-41 describes the command line parameters for the nco_echo_server command,
| Option | Parameter | Description |
|---|---|---|
messagelog | string | The name of a file to which all output messages are written. |
reader_port | numeric | The port number used by |
writer_port | numeric | The port number for the gateway. This is specified in the writer module attributes (TCP_PORT). |
help |
| Displays help on the command line options. |
This section shows a complete Vantive configuration file, vantive.conf.
###################################### # # # Vantive gateway configuration file # # # ###################################### ########### # Mappings # CREATE MAPPING VAN_OPEN ( 'Acknowledged' = '@Acknowledged', 'Alert Group' = '@AlertGroup', 'Alert Key' = '@AlertKey', 'Agent' = '@Agent', 'Class' = '@Class', 'First Occurrence' = '@FirstOccurrence' CONVERT TO DATE, 'Flash' = '@Flash', 'Grade' = '@Grade', 'Identifier' = '@Identifier', 'Internal Timestamp' = '@InternalLast' CONVERT TO DATE, 'Last Occurrence' = '@LastOccurrence' CONVERT TO DATE, 'Location' = '@Location', 'Manager' = '@Manager', 'Owner' = '@OwnerUID', 'Group' = '@OwnerGID', 'Node' = '@Node', 'Node Alias' = '@NodeAlias', 'Poll' = '@Poll', 'Serial' = '@Serial', 'Severity' = '@Severity', 'Server Name' = '@ServerName', 'Server Serial' = '@ServerSerial', 'State Change' = '@StateChange' CONVERT TO DATE, 'Summary' = '@Summary', 'Count' = '@Tally', 'Type' = '@Type' ); CREATE MAPPING VAN_UPDATE ( 'PROBLEM_NUMBER' = PROBLEM_NUMBER, 'Acknowledged' = '@Acknowledged', 'Agent' = '@Agent', 'Alert Group' = '@AlertGroup', 'Alert Key' = '@AlertKey', 'Class' = '@Class', 'First Occurrence' = '@FirstOccurrence' CONVERT TO DATE, 'Flash' = '@Flash', 'Grade' = '@Grade', 'Identifier' = '@Identifier', 'Internal Timestamp' = '@InternalLast' CONVERT TO DATE, 'Last Occurrence' = '@LastOccurrence' CONVERT TO DATE, 'Location' = '@Location', 'Manager' = '@Manager', 'Owner' = '@OwnerUID', 'Group' = '@OwnerGID', 'Node' = '@Node', 'Node Alias' = '@NodeAlias', 'Poll' = '@Poll', 'Serial' = '@Serial', 'Severity' = '@Severity', 'Server Name' = '@ServerName', 'Server Serial' = '@ServerSerial', 'State Change' = '@StateChange' CONVERT TO DATE, 'Summary' = '@Summary', 'Count' = '@Tally', 'Type' = '@Type' ); CREATE MAPPING VAN_CLOSE ( 'PROBLEM_NUMBER' = PROBLEM_NUMBER, 'Server Name' = '@ServerName', 'Server Serial' = '@ServerSerial' ); CREATE MAPPING VAN_JOURNAL ( 'PROBLEM_NUMBER' = PROBLEM_NUMBER, 'JOURNAL_TEXT' = JOURNAL_TEXT ); ########### # Readers # START READER VAN_READER CONNECT TO NCOMS; ########### # Writers # START WRITER VAN_WRITER ( TYPE = VANTIVE, REVISION = 1, OPEN_MAP = VAN_OPEN, UPDATE_MAP = VAN_UPDATE, CLOSE_MAP = VAN_CLOSE, JOURNAL_MAP = VAN_JOURNAL, FEEDBACK = TRUE, FEEDBACK_SERVER = 'NCOMS', FEEDBACK_FIELD = 'Location', CLOSE_PROBLEMS = TRUE, COUNTERPART = VAN_READER, OPEN_ACTION_SQL = 'open_action.vantive.sql', UPDATE_ACTION_SQL = 'update_action.vantive.sql', CLOSE_ACTION_SQL = 'close_action.vantive.sql', JOURNAL_ACTION_SQL = 'journal_action.vantive.sql', CONVERSIONS_TABLE = 'conversions.vantive', USER = 'Omnibus', PASSWORD = '', VANTIVE_SERVER = 'borg', VANTIVE_PORT = '1570', VANTIVE_VERSION = 7, DATABASE_POLL = 'OFF', OBJECT_NAME = 'ALERT', ID_COLUMN = 'vgStatusId', TARGET_INBOX = 'Help Desk', USER_COLUMN = 'swCreatedBy', FEEDBACK_COLUMN = 'vgLocation', SEVERITY_COLUMN = 'vgSeverity', SERVER_NAME_COLUMN = 'vgServerName', SERVER_SERIAL_COLUMN = 'vgServerSerial', CLOSE_CODE = 'Closed', STATUS_COLUMN = 'vgAlertStatus', JOURNAL_COLUMN = 'vgJournal', VB_DATE_FORMAT = '%m/%d/%y %H:%M:%S %p', DB_DATE_FORMAT = '%b %d %Y %H:%M:%S:%f%f%f%p', IP_ADDRESS = '194.205.96.253', TCP_PORT = '6002' ); ########### # Routes # ADD ROUTE FROM VAN_READER TO VAN_WRITER; ########### # Filters # # CREATE FILTER VAN_FILTER AS ''; # LOAD FILTER FROM '';
|
Note For details on how to create gateway conversions for alphabetic and numeric values refer to "Creating the Cisco Info Gateway Configuration File" section. |
Posted: Tue Jun 13 17:08:57 PDT 2000
Copyright 1989 - 2000©Cisco Systems Inc.