Table Of Contents
Introduction
What's New in WANDEST 2.6
Support for Solaris 9
What's New in WANDEST 2.5
CORBA Upgrade
Selectable Triggers for Database Tables
Features Introduced in WANDEST 2.4
Server Persistency
Schema Verification Prior to Full Upload
CORBA Upgrade
Support for Solaris 8
Server Ping Utility
Requirements
Interoperability
Components
Functionality
Introduction
The Cisco WAN Data Extraction and Synchronization Tool (WANDEST) provides a flexible and scalable mechanism to achieve database synchronization between the Cisco WAN Manager (CWM) system and either an Operational Support System (OSS) or other applications in a TELCO environment.
WANDEST extracts CWM database information and passes the selected information in a predefined format to either an OSS or other application. WANDEST can upload a full database or incremental updates of changes.
CWM is a network management system for WAN switches that reflects network changes in real time. Since the WANDEST database upload is a snapshot of the database, the snapshot might not reflect the current state of the CWM. Over time, the changes are propagated to OSS from CWM. Many data propagation methods used by TELCOs without transaction level integrity employ this manner of keeping the two databases correct.
All times within WANDEST server and client are noted in Greenwich Mean Time (GMT).
What's New in WANDEST 2.6
Support for Solaris 9
Release 2.6 of both the WANDEST client and server now can be installed and run on workstations running Solaris 9. Release 2.6 can also be installed and run on workstations running Solaris 8.
What's New in WANDEST 2.5
CORBA Upgrade
Both the WANDEST client and server now support CORBA Orbix E2A Application Server Platform 6.0.
Selectable Triggers for Database Tables
Prior to this release, every table within the stratacom database was accessed by WANDEST, regardless of whether the customer used the table or not. Now you can select the tables you need. Refer to the "Enabling WANDEST Table Selection" section for more information on setting up this feature.
Features Introduced in WANDEST 2.4
Server Persistency
The WANDEST server operates as a persistent server. This means that after the WANDEST server restarts, the WANDEST client will re-register with the server and continue running from the point it was last used. After re-registering, the client will work with the same set of CORBA object references it was using before the server restarted.
Schema Verification Prior to Full Upload
Before executing a FULL upload, the WANDEST server will check for changes to the schema. Upon receiving a FULL upload request, the WANDEST server gets the latest schema from the Informix database and validates the request by confirming that the requested tables are still available.
CORBA Upgrade
Both the WANDEST client and server now support CORBA Orbix E2A Application Server Platform 5.1.
Support for Solaris 8
Both the WANDEST client and server now support Solaris 8.
Server Ping Utility
WANDEST 2.4 introduced a utility script that you use to ping the designated WANDEST server from the WANDEST client to confirm connectivity
Step 1
FTP the /usr/users/svplus/orbix_domain/domains/cwm_<serverhost>_domain.cfg file from the CWM server workstation to the /usr/users/wandest/orbix_domain/domains/ directory on the WANDEST client workstation.
Step 2
Run the command ping_server <serverhostname> on the client.
In the example that follows, the WANDEST server hostname is sunfire280r1
tballraker28% /usr/users/wandest/scripts/ping_server sunfire280r1
Servers running on sunfire280r1:
Note
Run one instance of this command for each WANDEST server the client accesses.
Requirements
The WANDEST 2.6 server is installed on the same workstation as the CWM.
The WANDEST 2.6 server supports the following programs and operating systems:
•
Sun Solaris 8 or 9
•
IONA Orbix E2A Application Server Platform 6.0
•
Informix 9.4
•
CWM 15.1
WANDEST supports client configurations with the following platform requirements:
•
WANDEST 2.6 client without Informix bundle;
Supported on either Solaris version 8 or Solaris version 9.
The WANDEST client is implemented using any Common Object Request Broker Architecture (CORBA) E2A Application Server Platform 6.0 compliant implementation.
Interoperability
The WANDEST server provides its services using CORBA 5.1 standard and Internet Inter-ORB Protocol (IIOP) using the IONA Orbix environment. The WANDEST server can coexist with other instances of WANDEST servers within the same Orbix domain. No name server is used as the host name of the WANDEST server is the host name of the CWM workstation. There can only be one WANDEST server per CWM workstation.
Components
WANDEST is composed of two components: WANDEST server and WANDEST client. and illustrate an overview of WANDEST.
The WANDEST server runs on the workstation where CWM resides; the WANDEST client runs on the workstation where the OSS application resides. The WANDEST server provides its services only when CWM is operational.
Cisco provides the Admin Utility, a command line tool that allows the user to enter commands to the WANDEST client in place of the OSS application.
The WANDEST server provides the following services to the client through CORBA interfaces:
Services
|
Description
|
Full Database Upload
|
The WANDEST server takes a snapshot of a user-determined set of tables from the CWM database and returns the data as a set of ASCII text files to the client. The client then uses this data to initialize its database.
|
Incremental Updates
|
WANDEST server collects incremental updates of a user-determined set of tables since the client last sync time with the server and returns the data as a set of ASCII text files to the client. (The last sync time is defined as the start of a Full Upload request or an Incremental Update request. The sync time is discussed in greater detail in "WANDEST Server.") The client applies these updates to the database, which brings the client database in sync with the server database.
|
Database Schema
|
The WANDEST server provides schema validation of the database tables supported by the full upload and incremental update services. The WANDEST server also validates a table specification without doing a full upload or incremental update.
|
Previous Incremental Updates
|
The WANDEST server allows the client to revert to the last sync time and to the previous last sync time for a set of tables. The client can ask the server to resend the updates that were returned by the last incremental update request.
|
Version
|
The WANDEST server provides an interface to obtain the versions of CWM, the WANDEST server, and the WANDEST IDL definition.
|
The WANDEST server does not support statistics data tables, internal Informix tables, or temporary tables used within CWM. All other tables in the CWM stratacom database are supported.
The WANDEST client can be any CORBA client application that uses the CORBA services provided by the server. Cisco provides a generic client for server verification operations.
Figure 1-1 WANDEST Architecture
Figure 1-2 WANDEST Interactions Between Server, Client, and an OSS Application
Functionality
Because WANDEST extraction and synchronization operate on an operational CWM that continuously changes its database, the WANDEST server may not take a static snapshot of the database for a full upload. To have a static snapshot, the WANDEST server needs to lock the CWM database, which can adversely affect CWM operation.
To capture changes occurring during a full upload, the incremental updates tracking is started before a full upload begins. This means that some updates might be reflected in the full upload snapshot. Figure 1-3 shows the full upload and incremental updates process.
For example, in the I (insert) event occurring during the full upload might be part of the full upload data when the unloading of the inserted row occurs after that insertion has taken place.
All the changes are kept in the server tracking tables.
Figure 1-3 Full Upload and Incremental Updates
To resolve the possibility of duplicates, the WANDEST client uses the following process for incremental updates:
•
Insert and Update
The client assumes that the row does not exist and attempts to insert the row. If the row already exists, the client overwrites it.
•
Delete
The client assumes that the row exists and attempts to delete the row. If the row does not exist, the client does nothing.
The client is able to receive duplicate updates while maintaining data integrity.