Clarity Discovery GUI User Manual 1.5

User Manual
Clarity Discovery GUI

User Manual
Document Version: 1.5

Date: 18 May 2010
Copyright Information
Copyright © 2010. Clarity International Limited. All rights reserved. Clarity
International and the Clarity logo are registered trademarks of Clarity International
Limited, in Australia and other countries. All other trademarks or registered service
marks in this document are the property of Clarity International or their respective
owners. All specifications are subject to change without notice. Clarity International
assumes no responsibility for any inaccuracies in this document or for any obligation to
update information in this document. Clarity International reserves the right to change,
modify, transfer, or otherwise revise this publication without notice.
Document Information
Document History
Version Date Amendment Name Role
0.1 20 Mar 2009 First Draft Swati Mohanty Author
1.1 20 Jan 2010 Updated with Swati Mohanty Author
Header Collection
section.
Updated for release
C10.6.0
1.2 04 Mar 2010 Updated to include Swati Mohanty Author
the changes from
PTTIVB-8 ( Nems
Object ID field)
Version released in
C10.6.3
1.3 25 Mar 2010 Updated to include Swati Mohanty Author
changes for
INTTEST-2115
Version released in
C10.6.4
2
Document History
Version Date Amendment Name Role
1.4 08 Apr 2010 Updated to include Swati Mohanty Author
changes for
INTTEST-2101.
Version released in
C10.6.5
1.5 18 May 2010 Updated to include Swati Mohanty Author
changes from
INTTEST-2348 .
Version released in
C10.6.8
3
4
CHAPTER 1
Overview
The Clarity Discovery module is a vendor independent and technology neutral module.
It enables the automatic collection of physical, logical and service orientated data from
the network; the reconciliation of the collected data with the Clarity master database;
the reporting of all discrepancies; and the selected, automated and manual updating of
the database using a series of business rules; all within acceptable timeframes.
The Clarity Discovery module will primarily be used by:
• Clarity On-Site Professional Services or Third Party Systems Integrators - to
collect all the necessary information from the network and use it to complete
the initial data load into the system.
• Clarity Customers - to periodically audit the database contents against the
Clarity Master Database and flag results or support large-scale network build
projects (using the system in the same manner as it was used for the initial
data load).
In summary, the Discovery module provides the following functionalities:
• Collect and store network provided data;
• View collected data (new and historical);
• Schedule re-occurring collections;
• Initiate an immediate collection;
• View discrepancies based on continuous audits;
• Detect network changes and;
• Define reconciliation rules for manual, semi automated or fully automated
database updates.
Commercial in Confidence 3
OVERVIEW
The three basic methods used to discover objects in the network are:
• The extraction of network information direct from the Network Element
Management System (NEMS). This mechanism applies for customers
operating under a Managed Network environment, or
• Directly interfacing with the network device - this applies for customers
operating without a Management System, or
• Parsing objects that contain network configuration information such as files
or other databases.
The Clarity Discovery module supports the following underlying processes:
Sweeping - maintaining an accurate picture (within the Clarity Inventory Module) of
all the nodes in the network and their current 'Discovery' status.
Collection - mechanism used to collect the detailed information from all parts of the
network. A collection is initiated using either the Management Systems (NEMS), a file or
directly from the Network Elements.
Reconciliation -process employed to compare and map all the collected objects
between the network and the Clarity database.
Loading - the process used to automatically or semi-automatically generate new
records or delete old records in the Clarity system using customer specific business
rules.
Scheduling - a process that manages the timing of each collection, reconciliation,
loading activity, and their dependencies.
Reporting - the presentation of 'Discovery' actions, data inaccuracies and
inconsistencies resulting from the sweeping, collection, reconciliation and loading
processes.
The manner in which these processes are implemented in the Discovery module is
explained in the next chapter.
4 Commercial in Confidence
OVERVIEW
Overview of the Clarity Discovery GUI

Clarity Discovery is hosted on the .NET-based Clarity Workbench application. The
ribbon controls and behaviour of the Discovery GUI is similar to all other application
views launched through Clarity Workbench. For information on Clarity Workbench
framework , refer to the Clarity Workbench User Manual.
Pre-requisites
It is assumed that the user has installed and configured the following prior to launching
and using the Discovery GUI:
• Oracle forms must have been installed and the following configured:
– Object Types must have been set up
– NEMS objects must have been mapped to Clarity Objects
See the Clarity Discovery (Forms) User Manual for information
• The Discovery and Scheduler web services must have been deployed on the
Sun Java System Application Server. For instructions, refer to the Clarity Sun
Java Server Application System Setup Guide , v 2.1.
• The following MDDs and real-time components required for the Discovery
process must have been installed and configured:
– The Loader_Disc MDD
– SNMP_Disc MDD
– Discovery_Pinger MDD
– Library files for the realtime backend environment (
clarity_ClarityRtsShared_v2.0.jar)
It must also be noted that the Clarity Discovery module uses the Clarity Scheduler
module to schedule and trigger various Discovery jobs. Refer to the Clarity Scheduler
User Manual for information on this module.
Launching the Discovery GUI

The Clarity Discovery GUI is launched by clicking on the Discovery application button
on the Quick AccessToolbar in Clarity Workbench. See image below.
Figure 1–1. Discovery Application Button on the Quick Launch Toolbar
OVERVIEW
Clicking on the button will populate the ribbon bar with the Discovery application tabs,
task groups and buttons and launch the default Discovery Views see Figure 1–2.
Figure 1–2. Discovery View
Hint
The Navigator pane which is not used in this application can be hidden by clicking on the
Auto-Hide button and thereby provides the user a larger working area as is illustrated in
Figure 1–2.
The Discovery View is a container for all the reports that are generated for the various
tasks that are run as part of the Discovery module. These tasks and their associated
reports are described in detail in Chapter 2, Using Discovery and Chapter 3, End-User
Capabilities.
Discovery Task Groups and Buttons

Following is a brief description of the task groups and their functions. The next chapter
discusses how these task groups are used in the process of Discovery.
Filter Task Group
The Filter task group contains just the Duration drop-down menu button. Clicking on
the Duration drop-down button will display a set of configurable parameters.
OVERVIEW
Figure 1–3. Duration button menu
Various Discovery jobs are scheduled and run peridodically. The results of these jobs
can be viewed in the Reports sub-view in the Discovery GUI. The Duration button is
used to simply specify the time frame that the system will search and retrieve all
Discovery job reports for. For example, the user may want to view all the Discovery
jobs that have been run or scheduled in the past 10 months. By default, when the GUI is
launched, the jobs that run or been scheduled in the last 24 hours are displayed in the
Reports sub-view.
See Using Discovery on page 9 for detailed discussion on the use of the Duration button
and Reports.
Configuration Task Group
The Configuration task group is used to set up Sweep Configurations, which is
basically the process by which a set of IP addresses are provided for a Discovery job.
For further information see Sweeping on page 10.
OVERVIEW
Figure 1–4. Sweep Configuration button menu
Discovery View
The Discovery View is a container for all the reports that are generated by various
Discovery Jobs.
Figure 1–5. Discovery Report Views
When the Discovery GUI is launched, the following three Report groups will be
automatically displayed:
Audits - contains the reports for all Header Collection, Physical, and Logical Audit jobs
Sweeps - contains reports for all Sweep Runs and Reconcialition processes
Sweep Configuration - contains records of all Sweep Configurations
These reports are described in detail under their respective sections - see Using
Discovery on page 9.
Chapter 1 Overview
Overview of the Clarity Discovery GUI ................................... 5
Pre-requisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Launching the Discovery GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Discovery Task Groups and Buttons 6
Discovery View 8
Chapter 2 Using Discovery

Sweeping ............................................................. 10
DiscoveryPinger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Scheduling Pinging 15
Viewing Sweep Reports 20
SweepReconciler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Scheduling Reconciliation 27
Viewing Reconciliation Results 29
HEADER COLLECTION ............................................... 33
Viewing Header Collection Results 33
PHYSICAL AUDIT .................................................... 41
Viewing Physical Audit Results 45
LOGICAL AUDIT ..................................................... 48
Scheduling Logical Audit 49
Viewing Logical Audit Results 50
Chapter 3 End-User Capabilities

Functionality .......................................................... 54
Resizing Columns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Controlling the Visibility of Columns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Expanding and Collapsing Rows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Navigating Through Rows and Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Rearrange Columns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Selecting Rows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Grouping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Filter Editor - Building Filter Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
CHAPTER 2
Using Discovery
This chapter describes how to use the Clarity Discovery GUI to accomplish the
following processes:
• Sweeping- discovering the presence or absence of network elements
• Header Collection - updating the Clarity Inventory database with any new
equipment record
• Physical Audit - discovering and reconciling the physical devices in the
network
• Logical Audit - discovering and reconciling the logical network components
Note
Reconciliation is the process employed to compare and map all the collected objects
between the network and Clarity database.
The following sections describe each of these processes in detail. Note that a lot of the
tasks or jobs in Discovery are configured and run via the Clarity Scheduler GUI. This
chapter only contains instructions on using the Scheduler view to configure such tasks.
The Scheduler view is explained in detail in the Clarity Scheduler User Manual.
USING DISCOVERY
Sweeping
Sweeping
Sweeping is the mechanism used to collect high-level changes in the network and
update the database accordingly, e.g. a new node that was added to or removed from
the network. The Sweeping module is used on large Tier 1, dynamic, customer
environments under Clarity management where the network topology changes
frequently and where the network provisioning processes do not update the Clarity
database before (or after) that change occurs.
Sweeping accomplishes the following:
• The connection to a series of network elements or management systems and
the collection of any information relating to the presence or absence of a
Network Element;
• The matching of sweep results to the Clarity Inventory Module;
• The reporting of changes to the network;
• The suspension of future 'Full Discovery Collections' for nodes that are no
longer found to exist in the network;
• The resumption of 'Full Discovery Collections' for nodes found to have
reappeared in the network;
• Where new nodes are discovered, the dispatching of collection requests to
collect sufficient information to create an equipment header record; and
• The storage of the results Discovery database.
The Sweeper is given a segment of the network to survey and can discover one or all of
the following scenarios:
• No change, i.e., where an active node still exists at the expected location or
where no new node is discovered at an unexpected location
• A node (modelled in the Clarity database) is not found at that location so
suspend all further collections
• A node (modelled in the Clarity database) is found to exist after collections
were previously suspended,
• A new node is discovered and it should now be added to the full collection
schedule.
The Sweepers 'seed' (called Object Range in the view) can be a range of IP addresses, a
specific NEMS interface and any object ids specific to the NEMS, a file or a specific
network domain.
There are two aspects to Sweeping:
– Pinging the network to discover active and inactive equipment
– Reconciling the data to identify any changes to the network
In order to accomplish the above processes, Discovery uses the following two
components:
• Clarity Real Time application called DiscoveryPinger - to collect all
equipment information from various parts of the network
• Database program called SweepReconciler - to compare objects between
the network and database sources and update the database accordingly
USING DISCOVERY
Sweeping
DiscoveryPinger
The DiscoveryPinger application is used to check if network elements are active or
inactive in the network. In case of an IP network, the DiscoveryPinger uses plain ICMP
ping requests to determine this. For Non-IP networks, the DiscoveryPinger's specific
implementation is responsible for checking the absence or presence of network
elements (managed by the relevant NEMS). Refer to the Clarity Discovery Pinger
Installation and Configuration guide for information on how to start the application in
ICMP or NON-ICMP mode.
A list of active or inactive network elements are stored in the Clarity DB by
DiscoveryPinger application for the next process to occur.
The image below illustrates the DiscoveryPinger mechansim.
Figure 2–1. Pinging Process
To use the Discovery Pinger to successfully ping the network and discover the
equipment, the following must be accomplished:
– Sweep Configurations must be set up that contain the IP addresses that will be
pinged
– The actual pinging job must be scheduled
Once configured, the Discovery Pinger will ping the specific equipment in the network
at the scheduled time and date, the results of which can then be viewed in the
Discovery GUI.
These tasks are described in detail below.
USING DISCOVERY
Sweeping
Adding Sweep Configurations

A Sweep Configuration refers to a set of parameters that provide the DiscoveryPinger
with the IP address or range that it needs to explore and the mechanism to test the IP
connection. Once a Sweep Configuration is defined, the sweeping must then be
scheduled through the Scheduler view.
Users can save the Sweep Configuration defined for a particular IP range and schedule it
to run periodically. The results of the sweep can be viewed in the Discovery View. A
Sweep Configuration that has not been scheduled yet can be deleted.
Sweep Configurations can be added using the Sweep Configuration option available
in the Configuration task group of the Discovery ribbon.
To add a Sweep Configuration
1 In the Configuration task group, click on the Sweep Configuration button. A
drop-down menu is displayed with the following options:
– Add - to add a new Sweep Configuration
– Delete - to delete predefined Sweep Configurations
2 To add a new Sweep Configuration, hover your cursor on the Add option. The
configuration parameters are displayed.
3 Provide the following information.
Field Name Description
Schedule Name This is the identifier of the configuration, i.e. the name for the
Sweep Configuration being added.
Object Range The network element Ids that needs to be processed. Users can
enter a single IP Address, a range of IP addresses, or a
combination of both. When specifying a range, the first and last
numbers in the range should be separated by a hyphen. Individual
IP addresses must eb separated by a comma. For example,
171.16.1.11-172.16.1.112,192.1.1.1-192.1.1.222.
Table 2–1. Sweep Configuration Parameters
USING DISCOVERY
Sweeping
Field Name Description
Connection ID In case of IP addresses or SNMP enabled devices, user has the

following two options:
• Select the management system and check the SNMP
Configuration check box if you want to discover specific class
and version of network elements. The collect header requests
will be sent to the Static MDDs that are setup to process
requests for that class and version.
• Select Ping from the Connection ID drop-down list. The
collect header request will be sent to the Dynamic MDD that
is set up to discover network elements based on the system
description stored in the MIB.
In case of Non-IP configuration, the user can select from a list of
available management systems displayed in the drop-down list or
type in the identifier.
Status Indicates if this configuration is ACTIVE or INACTIVE. An

INACTIVE configuration is simply ignored when sweep
reconciliation is done (Refer to the SweepReconciliation process
described later in this chapter).
SNMP A flag to indicate if the set of network elements specified at the

Configuration 'Object Range' are SNMP devices. This check-box must be
'checked' for any configuration which intends to use the SNMP
Discovery MDDs (DYNAMIC or STATIC) and DiscoveryPinger
in ICMP mode.
Note that the SNMP Configuration flag will be automatically set if
the Connection ID is set to PING.
Table 2–1. Sweep Configuration Parameters
USING DISCOVERY
Sweeping
See image below:
Figure 2–2. Sweep Configuration
4 Click the Save button to save the Sweep Configuration. The following message will
be displayed “Sweep Configuration added‘’. Click Ok to close the message window.
The newly saved configuration can be viewed by expanding the SWEEP
CONFIGURATION report group in the Discovery View. See image below.
USING DISCOVERY
Sweeping
Figure 2–3. Viewing New Sweep Configuration
Sweep Configurations that are not required can also be selected from the report group
and deleted. The procedure below describes how to delete a sweep configuration.
To delete a Sweep Configuration
1 Select the non-required Sweep Configuration record in the Discovery view.
2 Click on the Sweep Configuration button to display additional menu options.
USING DISCOVERY
Sweeping
3 Click Delete. See image below.
Figure 2–4. Delete Sweep Configuration
A message will be displayed stating “Sweep Configuration updated !”. Click Ok to close
the message window.
Note
If a particular Sweep Configuration has been scheduled or run and data collected
against it, it cannot be deleted.
Scheduling Pinging
Once a Sweep Configuration is defined, a task or job needs to be scheduled in order for
the DiscoveryPinger to ping the network elements in order to determine whether they
are active or not. This pinging task is scheduled using the Scheduler GUI.
Note
Various other jobs under the Discovery module are also scheduled using the Scheduler
GUI.
Similar to the Discovery GUI, the Scheduler GUI is also launched through the Quick
Access Toolbar in Clarity Workbench. The Clarity Scheduler user manual describes the
view and its various functionality in detail.
To launch Scheduler View
1 Click on the Scheduler button on the Quick Access Toolbar. The Scheduler
GUI is Iaunched, populating the ribbon bar with the Scheduler task groups and
controls, and adding the Scheduler View beside the Discovery View.
USING DISCOVERY
Sweeping
Pinging is configured under the Schedule Jobs tab available on the Scheduler view.
Figure 2–5. Schedule Jobs Tab; Scheduler View
To schedule Pinging
1 Under the Schedule Jobs tab, select DISCOVERY from the Job Group drop-
down list.
All the Job Types defined for the Discovery module are now available for selection
under the Job Type drop-down list.
2 From the Job Type drop-down list, select the Job Type, for example PING
NETWORK. The Job Parameters sub-view is dynamically updated to display the
Schedule Name drop-down list field. Schedule Name in Discovery refers to the
Sweep Configurations that have been set up by the user.
The Sweep Configurations are available for selection in the Schedule Name
drop-down list.
3 Enter the Trigger Name, which is a user-defined name for the sweeping job being
scheduled. This is a free text field.
4 Click on the Schedule Name drop-down list and select the Sweep Configuration
that you want to schedule a job for. See image below.
USING DISCOVERY
Sweeping
Figure 2–6. Schedule Pinging
USING DISCOVERY
Sweeping
4 Under the Frequency tab, define the sweep run time and frequency. Enter the
following:
– Start Date/End Date - Click on the drop-down button in both these fields
to display the calendar. Select a start date and en end date to specify the time
period during which this job must run.
– Interval - This parameter defines the frequency of the job occurence, for
example whether the job should run every 2 hours during the entered time
period. Enter or scroll for a number and then select the unit of time.
See image below.
Figure 2–7. Schedule Pinging, image 2
5 Click on the Schedule button on the Scheduler Ribbon to save the job definition
and schedule the job. The job is added to the queue automatically to be run by
DiscoveryPinger on the date and time configured for the sweep configuration.
6 To view the job that you have scheduled, click on the Configured Schedules tab
in the Scheduler view. Click on Existing Schedules to populate the schedules.
The pinging jobs scheduled are listed under the PING NETWORK job name.
USING DISCOVERY
Sweeping
Expand the PING NETWORK job name record to view all the jobs scheduled to
run. See image below.
Figure 2–8. Configured Schedules
For each job, you can view the Trigger Name, the Start Time and End Time, the
Next Fire Time (time in which the job is scheduled to run next), and the Previous
Fire Time (time of the last run).
USING DISCOVERY
Sweeping
7 You can further expand the trigger name to view the schedule name and value that
was configured when scheduling this job. See image below.
Figure 2–9. View Trigger Details
Note
Trigger names are unique for each Sweep Configuration. Users must therefore define
one Trigger name for each job that they want to schedule for a sweep configuration.
That is, multiple jobs can be scheduled for one Sweep Configuration, each identified by
a unique Trigger Name.
Viewing Sweep Reports

A list of all the sweeps that are either scheduled, running, completed, or have failed can
be viewed in the Reports sub-view of the Discovery view. When the Discovery view is
launched, by default, the Reports sub-view is populated with reports on all jobs that
have been scheduled or run in the last 24 hours.
To view a list of Sweep Jobs
1 Click on the Duration drop-down arrow button to enter the time period that you
want to query the job list for.
A drop-down window is displayed with the following two options:
– Relative - to enter a flexible time range, such as the last 10 or 12 months, or
the last 5 hours. To define a relative time period, click on the Relative radio
USING DISCOVERY
Sweeping
button to highlight the options under it. Enter or select a number and then
select the period (months, hours or days).
– Absolute - to specify the exact time period. To define an absolute time period,
click on the Absolute radio button to highlight the options under it. Select a
From and To date using the drop-down calendar. See image below.
Figure 2–10. Duration Task Group
2 Click Apply to save your changes.

The database will be automatically refreshed to retrieve and display reports for the
mentioned time frame.
USING DISCOVERY
Sweeping
3 To view the list of Sweep jobs, expand the Sweep record group. See image below.
Figure 2–11. Viewing Sweep Jobs
The following information is displayed for each sweep job:
Column Name Description
Configuration The name of the Sweep Configuration.

Name
Start Time The start time of the run, if applicable. This is filled automatically
when the job starts.
Status Time The end time of the Sweep run. This is updated whenever a
certain status is completed during the sweep run or collection
process and again updated by the Sweeper Reconciliation tool
whenever a certain status is completed during the reconciliation
process for that run. Sweep Reconciliation is explained in the
next section.
Table 2–2. Sweeps Results table
USING DISCOVERY
Sweeping
Status Valid values are :

• Sweep Pending - defines the sweep collection status as
pending. This state is set at the initiation of the request.
• Sweep Failed - defines the sweep collection status as fail. This
state is used when an invalid IP range or where connectivity to
the network is unavailable. An error description with
meaningful comment is generated.
• Sweep In Progress - defines the sweep collection status as in-
progress.
• Sweep Completed - defines the sweep collection status as
completed.
Note:This column also displays the status acquired once the
reconciliation job is run. The reconciliation specific status are
described in the next section.
Description This field provides information extracted from the Scheduler

describing the domain being swept. If the sweep fails, the
Description field also provides information on the reason (this
error information is appended to the record).
Table 2–2. Sweeps Results table
4 For a sweep job that has completed, you can expand the specific Configuration
record to view its details.
The following information is displayed:
Reconciliation If a reconciliation job has run for this sweep configuration, this
Time column displays the time when the reconciliation for all the
network elements in that sweep configuration was completed.
Network Object If the Sweep is IP based then this column lists all the IP addresses
being pinged. If the Sweep is using a file, NEMS, etc, then it is the
label collected from the Sweep describing the node.
Result Result of the sweep run, i.e., whether the equipment being
discovered is active or inactive, or whether the ping resulted in
an error. Where IP Sweeper is used, then these status values
provide an indication of the ping results. Where a NEMS, file, etc,
is used for the sweep then the only result supported is ACTIVE
(as the search only returns active nodes). The ERROR value is
only used when the IP Sweeper encounters a problem.
Table 2–3. Sweep Job Details
USING DISCOVERY
Sweeping
Action Possible value is RECONCILE. This column merely indicates that

the objects pinged are now ready to be reconciled.
Description Any information attached to the network object that is being

swept. If the sweep fails, the Description field also provides
information on the reason (this error information is appended to
the record)
Table 2–3. Sweep Job Details
When viewing these reports, you can drag a column to the right or left, disable a
particular column from view temporarily, and also use filters on each column to view a
small set of data at a time. The column behaviour of these tables and the options
available are discussed in Chapter 3, End-User Capabilities.
Sweep Reconciliation
When the Sweep Collection is complete, a reconciliation action takes place to
determine if there have been any changes in the network since the last sweep so that
the objects being discovered can be reconciled against the Inventory database. This
process is invoked by the DiscoveryPinger application once the collection process is
complete. The reconciliation tool checks the collected results from DiscoveryPinger
application against the equipment records and can report on one or some of the
following scenarios:
• No change has occurred to the network - nodes that exist match the
Network Elements modelled in the database or no new nodes were
identified
• A node does not exist at the expected location. This process marks the node
as being Inactive (for Discovery) to avoid future Collection activities.
• An inactive node exists at the expected location. The node is marked as being
active for future collections.
• A new node exists. This triggers a equipment header collection request to
extract sufficient information in order to create an equipment header record.
Note
To maintain the Discovery status of a node, a 'Discovery Status' field is associated with
the Network Element record in the Clarity database. This field is managed
automatically and is not visible to users through the Clarity screens. Valid status values
are:
– Off
– On
USING DISCOVERY
Sweeping
The figure below describes the process used when reconciling the sweep collection
results against the Clarity database contents.
Figure 2–12. Sweep Reconcile Process
The reconcilation process results in one or fewof the following actions:
Node Exists in
Response Clarity Node
Received? Database? Status Action
Yes Yes Active No further action is required
Yes Yes Inactive Reactivate discovery to check the

particular node found in the network.
Set discovery status field for
Equipment Record=ON
Yes No New equipment identified. Schedule

header equipment record collection.
No Yes Set Discovery status field for

Equipment Record to Discovery =
OFF
No No No action.
Table 2–4. Reconciliation Results
USING DISCOVERY
Sweeping
Viewing Reconciliation Results

Once the Sweep Reconcile job has been executed, the results can be viewed in the
Discovery view under the Reports sub-view. Expand the SWEEPS record group in the
Reports sub-view. See image below.
Figure 2–13. Viewing Sweep Results
When a reconciliation job is run, the sweep record is updated the reflect the following:
Configuration The name of the Sweep Configuration.

Name
Start Time The time when the reconciliation started.
Table 2–5. Updated Sweep Results table
USING DISCOVERY
Sweeping
Status Time This is updated by the Sweeper Reconciliation tool whenever a

certain status is completed during the reconciliation process for
that run.
Status Valid values are :

• RECON_PENDING - defines the sweep reconciliation status
as pending. This state is set when the Sweep completes and
data is ready to be processed.
• RECON_INPROGRESS - defines the sweep reconciliation
status as in-progress.
• RECON_COMPLETE - defines the sweep reconciliation
status as completed.
• RECON_FAILED - a meaningful failure message is provided,
e.g. database failure.
Description This field provides information extracted from the Scheduler

describing the domain being reconciled. If the reconciliation fails,
the Description field also provides information on the reason
(this error information is appended to the record).
Table 2–5. Updated Sweep Results table
USING DISCOVERY
Sweeping
Expand each record to view the reconcilation details. See image below.
Figure 2–14. Viewing Sweep Details
The Sweep Results table is updated to indicate the Reconciliation Time, possible
action and description(where applicable).
Reconciliation The time when the reconciliation for all the network elements in
Time that sweep configuration was completed.
Network Object If the Sweep is IP based, then this column lists all the IP
addresses. If the Sweep is using a file, NEMS, etc, then it is the
label collected from the Sweep describing the node.
Table 2–6. Reconcile Job Details
USING DISCOVERY
Sweeping
Result Result of the sweep run, i.e., whether the equipment being
discovered is active or inactive, or whether the ping resulted in
an error. Where IP Sweeper is used, then these status values
provide an indication of the ping results. Where a NEMS, file, etc,
is used for the sweep then the only result supported is ACTIVE
(as the search only returns active nodes). The ERROR value is
only used when the IP Sweeper encounters a problem.
Action Possible values are as follows:

• If Object is in database (Discovery is Active) and in network:
NO_ACTION
• If Object is in database (Discovery is Inactive) and in network:
EQUIP_ON
• Object is in database and not in network: EQUIP_OFF
• Object in network and not in database: COLLECT_HEADER
See Table 2–4 on page 26 for details.
Description Any information or error message associated with the network

object.
Table 2–6. Reconcile Job Details
Note
When the SweepReconciler process runs, it just reconciles the objects that are under
an ACTIVE Sweep Configuration.
USING DISCOVERY
HEADER COLLECTION
HEADER COLLECTION
Header Collection refers to the automatic process by which a new equipment record,
that is discovered during a Sweep and Reconcile process is added into the Clarity
Inventory database. When a new node is identified, the Reconcile agent initiates the
Equipment Header Record collection process by adding a new record to the Discovery
queue. The Discovery MDD (SNMP or Loader) collects the NE Object parameters so
that an Equipment record can be created in the OSS.
The equipment parameter information collected depends on the type of technology,
equipment and management system in use. These parameters are configurable in the
Clarity system to form a suitable network element header for a particular device.
Note
A set of mandatory parameters are necessary to automatically create the Equipment
Header record. Refer to the Clarity Discovery(Forms) User Manual for information on
these parameters.
Viewing Header Collection Results

The results of the header collection process can be viewed in the Discovery view under
the Audits record group in the Reports sub-view.
The results are displayed under the COLLECT_HEADER report group. The Audits
record group also contains other Discovery reports. To view only the results
associated with the Header Collection process, filter on the COLLECT_HEADER Audit
Name. To filter, click on the small filter icon on the Audit Name column. A list of
USING DISCOVERY
HEADER COLLECTION
report types available for viewing under the Audits report group displays. Select
COLLECT_HEADER. See image below.
Figure 2–15. Applying Filter
USING DISCOVERY
HEADER COLLECTION
The table automatically refreshes to display only Header Collection reports. See image
below.
Figure 2–16. Viewing Header Collection Results
The following information is displayed for each Header Collection process:
Audit Name Indicates the Audit process being run, in this case
COLLECT_HEADER.
Management For IP-based header collection - this is always auto-populated

System with the value SNMP_HEADER_COLLECTION.
For non IP-based header collection - this reflects the name of the
actual management system.
Audit Start Date Indicates the date and time in which the selected audit job
started.
Table 2–7. Header Collection Results Table
USING DISCOVERY
HEADER COLLECTION
Audit Processed Indicates the audit completion date and time.

Date
Audit Status Possible values are:

• INPROGRESS - defines that the header collection is in-
progress.
• COMPLETED- defines that the header collection is
completed.
• ERROR- defines that the header collection has failed.
Audit Details A description of the audit job or error message(if associated with
the job).
Realm Realm to which the network element that has been discovered
belongs. This is determined by the Header Reconciliation
backend process. It is not displayed in the Header Collection
results table. This column is populated for a Physical Audit job.
Table 2–7. Header Collection Results Table
USING DISCOVERY
HEADER COLLECTION
The details of each Header Collection process can be viewed by expanding the specific
COLLECT_HEADER request. See image below.
Figure 2–17. Expand Collect_Header Process
Each report displays the following information:

Discovery Objects Tab - These are the discovery objects that have been collected
and/or reconciled for a particular audit. This can be a list of the network elements and
system configuration data associated with these network elements. The following data
is displayed for each object at the parent level.
Name The object type collected, for example NE or System

Configuration data.
Table 2–8. Discovered Objects Information
USING DISCOVERY
HEADER COLLECTION
Nems Object ID Displays the NEMS_NE_NAME for the Network Element. For
child objects such as cards and ports, this field will display the
NEMS_CARD_NAME, and NEMS_PORT_NAME respectively.
The object id enables users to identify the specific instance of the
network object from the Discovery Objects list. For any other
object the field will be empty.
Note: If the field is empty for NE, Card, or Port; make sure that
the aforementioned parameters were discovered.
Status Indicates whether the collection/reconciliation is completed, in

progress, or has failed for the specific discovered object.
Reconcile Status Indicates the reconciliation status. For a header collection job,
this is always:
CREATED - The collected parameter value was missing from the
database and has been added.
Table 2–8. Discovered Objects Information
Errors - This tab displays any errors that have occurred during collection or
reconciliation.
You can futher expand each discovered object record to view the following details that
have been collected.
Parameters
Tab
Name The name of the parameter.
Network Value The parameter value as collected from the network.
Clarity Value Value of the parameter in the Clarity database.

Note:This field contains no value for the Header Collection record
since the object discovered is new and not identified in the
Clarity database yet.
Status This filed is also not populated at this process level since the
object discovered is new.
Table 2–9. Discovered Object Details
USING DISCOVERY
HEADER COLLECTION
Errors This tab displays any errors/information messages that have

occurred with the selected discovery object during collection or
reconciliation.
Child Objects This tab contains a list of all the child objects of the selected
discovery object. For example, all the CARDS on a NE are
displayed under this Child Objects tab.
Table 2–9. Discovered Object Details
For each equipment header collected, this process also determines the realm for that
equipment using discovered parameters and the configuration in the Realm Tables.
This is done by selecting the RLHM_REALM value from the REALM_HIERARCHY table
where the discovered parameters DOMAIN, FUNCTION, AREA and REALM_TYPE
match the RLHM_DOMAIN, RLHM_FUNCTION, RLHM_AREA and RLHM_TYPE
respectively. Once the REALM is determined, the process creates the Equipment
Record as normal with the EQUP_REALM being populated with the determined value
above.
Optionally, the user can also configure a new parameter in the NEMS Object
Mappings screen to directly assign the Realm value to the discovered objects. To
configure the new parameter:
• The new parameter EQUP_RELM_TYPE must first be added as a parameter
for the NE object type in the Discovery Object Types screen.
• It must then be added for the object NE in the NEMS Object Mappings
screen.
• The user must define a value for the parameter in this screen.
This parameter will take precedence over the other four parameters described above.
That is , if this parameter has been set up, when an object is discovered, the Collect
Header report will display the value of EQUP_RELM_TYPEas <realm name>, and the
Network Element screen will also display the same in the Realm field.
The EQUP_MANS_NAME will be populated with the value of
<NEMS_CLASS>%<NEMS_VERSION>%<NEMS_INSTANCE>. If the
NEMS_INSTANCE parameter is not defined in the NEMS Object Mappings then the
EQUP_MANS_NAME will be populated with the value of
<NEMS_CLASS>%<NEMS_VERSION>%<REALM>.
If a MANAGEMENT_SYSTEM record for this NEMS does not exist, the process creates
one, populating the mandatory columns as follows:
Column Description
MANS_NAME As detailed above.
Table 2–10.
USING DISCOVERY
HEADER COLLECTION
Column Description
MANS_CLASS Value of the NEMS_CLASS parameter
MANS_VERSION Value of the NEMS_VERSION parameter
MANS_INSTANCE Value of the NEMS_INSTANCE (if provided)

or the 'REALM Name' in the absence of
NEMS_INSTANCE parameter.
MANS_IPADDRESS 'NA'
MANS_SUPPLIER NA
MANS_LOCN_TTNAME Value of the EQUP_LOCN_TTNAME

parameter.
MANS_AUTOEXECUTE N'
Table 2–10.
In the event that a REALM could not be determined, then the Equipment record should
not be created and the DISC_OBJECT should be updated with a status of ERROR and
DISC_ERROR record created with the description "Unable to create Equipment
because REALM could not be determined". This will enable corrections and/or
configuration updates to be made that will correct the error and the next discovery will
be able to create equipment record without any chance of conflicting data being in the
database.
It is important to identify the realm to which each network element belongs because
the next two Discovery processes, Physical Audit and Logical Audit, use Realm as the
search parameter to collect and display information.
An EQUIPMENT_ALIAS record will also be created for the equipment using the
NEMS_NE_NAME as the EQUA_ALIAS and the REALM as the
EQUA_NAMING_DOMAIN.
Note
This alias creation will be done by Discovery without relying on any Alias Mapping
configuration.
In addition, the Discovery process will create an alias for the equipment using the Alias
creation rule specified by the user in the Integration > MDD Configuration >
Discovery > Object Mappings > Alias Mapping tab. An alias of an inventory
object is the name by which the object is known in the network. Refer to the process
Defining Alias for Inventory Objects ( page 33) in the the Clarity Discovery ( Forms) User
Manual for information on how an alias creation rule is set up.
USING DISCOVERY
HEADER COLLECTION
An example configuration of an alias creation rule is given below:
Figure 2–18. Defining the alias creation rule using the NEMS Object Mappings form
Note
For network elements, aliases are created during Header Collection. For Cards/Ports,
aliases are created during Physical Audit..
USING DISCOVERY
PHYSICAL AUDIT
PHYSICAL AUDIT
Physical Audit is a process in the Clarity Discovery module that is specifically
responsible for discovering the physical existence of devices in the network. Its core
function is to discover/reconcile the physical components in a network element like
chassis, slots, cards and their associated physical ports or interfaces.
In networking terminology, a 'Chassis' refers to a metal frame that serves as the
structural support for electronic components. The chassis contains slots for the various
card components and expansion boards. Additional boards can be inserted through
expansion chassis which provides additional slots.
Physical Audit identifies the device status along with other relevant parameters such as
Model, Manufacturer, Serial Number, Software Version and Revision, Management IP
Address, etc.
This physical chassis and card discovery gives the ability to:
• Audit the node chassis information
• Identify the number of physical card slots that the chassis can accommodate
• Identify the physical slots that are 'In Use' within the chassis (i.e., having a
Card with status equal to 'ACTIVE' or 'IN USE as Card Protection')
• Identify the physical slots that are 'Not In Use' within the chassis (i.e., having a
Card with status equal to 'SPARE or UNUSED')
• Identify the physical ports (both 'ACTIVE' and 'INACTIVE') associated with
the card and
• Perform deep discovery of all its other key system components and sub-
systems
The Inventory database supports the storage of a wide range of asset information,
which includes Serial Number, Part Number, Manufacture Date, CLEI and other
information to give users an easy way to track hardware and software firmware
revisions loaded on the various devices. This information is audited if it is available for
collection.
Clarity also stores card and port information and these parameters are validated against
the Inventory tables to check if the discovered parameters match the card and port
configuration that exists on the database.
Discovery does not automatically update the existing inventory model with the results
collected from the Physical Audit process, where that action could result in database
corruption. The reporting tool provide complete details of any reconciliation results
with the option to upload the changes into the database.
Note the following scenarios:
• A new equipment chassis is discovered in the network which does not exist
in the database. The Clarity Inventory tables are automatically updated.
• Newly discovered (added) cards are found on the chassis which do not exist
in the database. The Clarity Inventory tables are automatically updated.
• Newly discovered physical ports associated with the card and not existing in
the database. The Clarity Inventory tables are automatically updated.
• An existing chassis, card and physical port is discovered to be active but has
an Inactive status in the master database. This is an example of something
USING DISCOVERY
PHYSICAL AUDIT
that exists in Clarity Inventory but has a different value in the network. No
auto action is taken by the Discovery module. Instead the user must review
these discrepancies and take necessary action manually.
• A chassis or assets such as cards and its physical ports exist on the master
database but are not found in the network.
Note
Deactivating this equipment results in the cancellation of all active connections or
Services using this equipment. Hence, no action is taken by Discovery. The user must
update it manually.
• A new parameter, that is added to the equipment, cards, or ports (e.g.,

through IOS / software upgrades) but not existing in Clarity Inventory, is
discovered. In this scenarios, the Clarity Inventory tables are automatically
updated.
From the above reconciliation process, the possible reconcile statuses that are
determined for each object and associated parameters are as follows:
• EQUAL - Parameter value matches what is in the database.
• NOT_EQUAL - Parameter value does not match what is in the database.
• CREATED - Parameter was missing from the database and has now been
added.
The image below describes the Physical Audit process.
Figure 2–19. Physical Audit Process Diagram
USING DISCOVERY
PHYSICAL AUDIT
Scheduling Physical Audit

The Physical Audit process is scheduled using the Scheduler view. It can be run either
periodically or as a one off process.
To schedule Physical Audit
1 Under the Schedule Jobs tab, select DISCOVERY from the Job Group drop-
down list.
2 From the Job Type drop-down list, select the PHYSICAL AUDIT Job Type. Enter
a trigger name.
3 The Job Parameters sub-view is refreshed to display the Realm Name field.
Enter the Realm Name for which the physical audit job needs to be run.
Note
Realm Name is a mandatory parameter as it is the basis on which the physical audit
job is run. Therefore, realms data should have been configured for each network
element..
4 An additional Network Elements list box is displayed on the Scheduler GUI. It

lists network elements by their alias names which belong to the 'Realm' selected by
the user in the 'Realm Name' drop-down list and allows users to schedule/execute
physical audit jobs either by selecting specific network elements (multiple of them
can be selected by holding down the Ctrl key) in the list or by selecting the 'All
Network Elements' list item which will send physical audit request for all the
network elements in the realms (the previous functionality).
Note
For network elements to appear in the Scheduler GUI list, certain attributes should
exist in Clarity inventory for those NEs. They are as follows:
– Should have an alias with Naming Domain as the Realm Name which was selected in
the Scheduler GUI. (This will be automatically created when Discovery processes the
Header Collect requests).
– EQUP_RELM_NAME field should match the 'Realm' selected in the Scheduler GUI.
(If specified in Object Mappings, this will be created when Discovery processes the
Header Collect requests).
– EQUP_MANS_NAME field should have some value. (If specified in Object Mappings,
this will be created when Discovery processes the Header Collect requests)
USING DISCOVERY
PHYSICAL AUDIT
5 Under the Frequency tab, specify the duration and frequency for the job. See
Scheduling Pinging on page 16 for information on these parameters.
Figure 2–20. Scheduling Physical Audit
6 Click Schedule to save the job definition.
USING DISCOVERY
PHYSICAL AUDIT
Viewing Physical Audit Results

The results of Physical Audits can be viewed in the Discovery view under the Audits
record group in the Reports sub-view. The results are displayed under the
PHYSICAL_AUDIT report group. See image below.
Figure 2–21. Viewing Physical Audit results
The columns and information displayed in the Physical Audit table is the same as the
information displayed for the Header Collection process.
Audit Name Indicates the Audit process being run, in this case
PHYSICAL_AUDIT.
Table 2–11. Physical Audit Results Table
USING DISCOVERY
PHYSICAL AUDIT
Management For IP-based header collection - this is always auto-populated

System with the value SNMP_HEADER_COLLECTION.
For non IP-based header collection - this reflects the name of the
actual management system.
Audit Start Date Indicates the date and time in which the selected audit job
started.
Audit Processed Indicates the audit completion date and time.

Date
Audit Status Possible values are:

• INPROGRESS - defines that the physical audit is in-progress.
• COMPLETED- defines that the physical audit is completed.
• ERROR- defines that the physical audit has failed.
Audit Details A description of the audit job or error message(if associated with
the job).
Realm Realm to which the network element that is being audited

belongs. This is populated from the Clarity database. For a new
network element that has been discovered in the network and
does not exist in the Clarity database, this value is determined by
the Header Reconciliation backend process.
Table 2–11. Physical Audit Results Table
Expand on the specific record to view the parameters, associated values, and child
objects, if any, recovered for the network element that has been audited. The table is
the same as displayed for a Header Collection audit job, the only differences being:
• The column Clarity Value is populated with the value of the parameter as
existing in the Clarity database. In the Header Collection job, this column is
USING DISCOVERY
PHYSICAL AUDIT
empty as the network element in question is newly discovered in the

network and has no corresponding value in the Clarity database yet.
• The Status column indicates any of the three following values:
– EQUAL - The collected parameter value matches the database.
– NOT EQUAL - The collected parameter value does not match the database.
– CREATED - The collected parameter value was missing from the database and
has been added.
Figure 2–22. Physical Audit Detailed View
USING DISCOVERY
LOGICAL AUDIT
LOGICAL AUDIT
Logical Audit is a process run in the Clarity Discovery module to collect and reconcile
the existence of logical network components such as Termination Points, Links and
Paths contained within a network component across Network Domains. This includes
changes, additions and deletions of those non-physical inventories and/or logical
configuration for network objects. Logical audit provides important information that
can not be collected from the physical discovery where it identifies the paths traversed
by packets sent from each source to the receivers and indicates where these paths
diverge and merge. The latter information is useful for the evaluation of the resource
sharing capability of the network and can guide the decisions of source-based routing
algorithms.
The objects that are collected at this level usually include Logical Ports, Configuration
Elements, and Configuration Element Details.
The reconciliation process is similar to Physical Audit and the same three statuses are
determined for any objects and its parameters:
• EQUAL - Parameter value matches what is in the database.
• NOT_EQUAL - Parameter value does not match what is in the database.
• CREATED - Parameter was missing from the database and is added.
Figure 2–23. Logical Audit Process Diagram
USING DISCOVERY
LOGICAL AUDIT
Scheduling Logical Audit

Logical Audit is scheduled in exactly the same manner as a Physical Audit job, except
that when selecting the Job Type under the Schedule tab in the Scheduler view, the
user must select the LOGICAL AUDIT job type. See example below.
Figure 2–24. Scheduling Logical Audit
USING DISCOVERY
LOGICAL AUDIT
Viewing Logical Audit Results

The results of Logical Audits can be viewed in the Discovery view by expanding the
Audits record group and and filtering on the LOGICAL_AUDIT report type. See
image below:
Figure 2–25. Viewing Logical Audit Results
You can also expand each Logical Audit record to view its details. The information
displayed in the Logical Audit report is the same as the details displayed for the Physical
Audit reports, the only difference being the Discovered Object during a Logical Audit is
a Configuration Element as opposed to a physical network element.
USING DISCOVERY
LOGICAL AUDIT
See image below.
Figure 2–26. Logical Audits Detailed View
Note
Even though the Logical Audit just collects logical entities (Logical Ports, Configuration
Elements, etc.) from the network; the view displays the parents of those logical entities
as well. For example, if a Logical Port was discovered/reconciled, then the view displays
its immediate parent, grandparent and so forth, that is, the Physical Port, Card, and
NE that the logical port belongs to.
CHAPTER 3
End-User Capabilities
This chapter provides information on the various controls available to the end-user to
organize and display information on the Discovery view, for example grouping reports
based on columns, adding, deleting, or rearranging columns, and so on.
END-USER CAPABILITIES
Functionality
Functionality
The Discovery view displays the following three kinds of reports resulting from various
Discovery jobs:
• Audits - reports related to the Header Collection, Logical Audit, and
Physical Audit jobs.
• Sweeps - reports resulting from Sweep and Sweep Reconciliation jobs.
• Sweep Configuration - list of all the sweep configurations set up by the
user.
When the Discovery view is launched, the Discovery view is rendered with these three
report groups in focus. By default, reports collected in the past one day are loaded into
the Discovery view under these report groups. Using the Duration task group, you
can enter a wider time range based on which the system will query and display data.
Reports are displayed in a tabular format. Each report group needs to be expanded to
view the entire list of reports collected for that particular report group.
The following sections describe the various viewing, navigation, filter, and grouping
options available to the user.
Resizing Columns
Resize Columns in Grid Views

To resize columns
• Drag the right edge of the target column header. See image below.
Figure 3–1. Resizing Columns
Functionality
To change a column's width so that it displays its contents compactly in

their entirety
Do one of the following:

• Double-click the right edge of the column header or
• Right-click the column's header and select Best Fit.
Figure 3–2. Changing a Columns Width
Functionality
To change the widths of all columns so that they display their contents in
the best possible way
1 Right-click the header of any column and select Best Fit (all columns).
Figure 3–3. Changing the Width of All Columns
Functionality
Controlling the Visibility of Columns
Hiding Columns in Grid Views

To Hide Columns in Grid Views

• Click a column header and drag it onto the grid control's cell area, until the
cursor changes its image to big 'X'. Then drop the header or
• Drag and drop a column header onto the Customization Form if it's open.
Figure 3–4. Hiding Columns from View
Functionality
Expand/Collapse Group Rows in Grid Views

To expand/collapse a group row

• Click the row's expand button.
Figure 3–5. Expanding Rows using button
• Double-click the group row.

• Double-click the indicator cell corresponding to the group row.
Figure 3–6. Expanding Rows using Indicator Cell
Functionality
Expanding and Collapsing Rows
Expand/Collapse Master Rows in Grid Views

To expand/collapse a master row

• Click the master row's expand button:
Figure 3–7. Expanding Master Row
• Double-click the indicator cell corresponding to the master row:
Navigating Through Rows and Cells
Move Focus Between Rows

To move focus between cells and rows use the ARROW, TAB, HOME, END, PAGE UP
and PAGE DOWN keys. Note that the ARROW, HOME and END keys are used for
navigation between rows only when the focused cell is not being edited. Otherwise,
these keys affect focus movement within the currently edited cell.
To focus the next cell
• Press TAB or
• In Grid Views, press RIGHT ARROW. If a cell editor is active, pressing
RIGHT ARROW moves focus to the next cell if the caret is positioned at the
end of the current cell's text or if the cell's text is selected in its entirety.
To focus the previous cell
• Press SHIFT+TAB or
• In Grid Views, press LEFT ARROW. If a cell editor is active, pressing LEFT
ARROW moves focus to the previous cell if the caret is positioned at the
beginning of the current cell's text or if the cell's text is selected in its
entirety.
Functionality
To focus the first cell within the current row in Grid Views
Press HOME.
To focus the last cell within the current row in Grid Views
Press END.
To focus the first row
• Press CTRL+HOME in Grid Views.
To focus the last row
• Press CTRL+END in Grid Views.
To move focus to the Auto Filter Row displayed at the top of a Grid View

• Click this row.
• If a top data row is focused, press CTRL+UP ARROW.
To Move Focus Away From the Grid Control
Press CTRL+TAB.
Functionality
Rearrange Columns
Reorder Columns in Grid Views

To reorder columns
Drag and drop a column header to a new position.
Figure 3–8. Reordering Columns
Functionality
Selecting Rows
Select Individual Rows

To select a row and clear existing selection

• In Grid Views, click the row's indicator cell or any of its data cells:
• Select the row using the ARROW keys.
To shift the focus to a report group or report
• By default, the Discovery view displays three report groups. When viewing a
report group or an individual report, you can shift the focus such that only
Functionality
that particular report group or report displays in the Discovery View. See
examples below.
• Select the report group that you want to bring to focus.
• Select the Focus button at the header level. See image below.
Figure 3–9. Focusing on a report group
• Click on the button. Only that report group is now in focus. See example
below.
Functionality
Figure 3–10. Viewing a single Report Group
• To return to the original tabular view, click on the X marked button that
appears at the header level.
Functionality
Figure 3–11. Moving out of focus
• Expand a report to view its details.
Figure 3–12. Expand Report
• Click on the focus button at the header level header under this report. The
details table is now in focus.
Functionality
Figure 3–13. Focusing on Report Details
Functionality
Grouping
Group Data
To group by a specific column

• Expand a report group. Right-click on any column and select Group by Box
from the context menu. See example below.
Figure 3–14. Group by Box option
• Click on the option. A group panel now appears above the header row. See
image below.
Functionality
Figure 3–15. Group Panel
• Drag a column header from the column header panel and drop in onto the
group panel. The reports are now grouped based on this column. See image
below.
Functionality
Figure 3–16. Example of Grouping by Column
• Optionally, Right-click a column header and select Group By This Column

from the context menu.
Functionality
Figure 3–17. Group by Column, example 2
Functionality
See example:
Figure 3–18. Sample Grouping
• You can configure multiple grouping using the same methods. See example
below.
Functionality
Figure 3–19. Multiple Grouping
To change Group Order

• To change group order, move a grouping column header to another position
within the group panel.
Ungroup Data
To ungroup data, do one of the following:
Functionality
• Drag a column header from the group panel to the column header panel.
• Collapse the record at the parent level and expand again. The table is
displayed in its original format.
• Right-click a grouping column's header and selecting the UnGroup from the
context menu. See image below:
Figure 3–20. Ungroup Columns
• To remove grouping by all columns, right click the group panel and select
Clear Grouping from the context menu.
Filtering
Create a Simple Filter Condition

To select records that contain a specific value in a specific column field
Do the following:
Functionality
1 Invoke the filter drop-down list containing available filter values. To do this, click on
the filter button.
Figure 3–21. Filter button
2 By default, if filtering is applied, the filter drop-down only displays the values which
match the current filter criteria. If the SHIFT key is pressed while opening the filter
Functionality
drop-down, all values are listed (not only those that match the current filter
criteria).
Figure 3–22. Filter Criteria
3 Select the required filter value in the filter drop-down list:
Functionality
The filter drop-down list is immediately closed, and the control displays the records
which contain the specified value in the specified column field. Additional, the filter
applied is displayed in a Filter panel as shown below.
Figure 3–23. Displaying applied Filter
If the filter drop-down list provides check boxes to the left of filter values, multiple
values can be selected (checked) simultaneously:
In this mode, click Ok to close the filter drop-down list and apply the filter.
You can sequentially filter data against multiple columns using the method described
above
Functionality
Create Complex Filter Criteria

To construct filter criteria involving multiple columns fields, and using
various comparison operators

• Invoke the filter drop-down list (see below) and click Custom. This invokes
the Custom Filter Dialog, allowing you to compare a column with one or two
values.
Figure 3–24. Custom AutoFilter window
• Use the Filter Builder, that allows complex filter criteria to be constructed.
See the Filter Editor section to learn more.
Functionality
Clear the Filter

To clear the filter applied to a specific column

• Invoke the filter drop-down list and click (All).
• In Grid Views, right-click the column header and select Clear Filter:
To clear the total filter criteria
Click the Close Filter button within the Filter Panel.

To disable/enable the Filter
Click the Enable Filter button within the Filter Panel.
Figure 3–25. Buttons in the Filter Panel
Filter Editor - Building Filter Criteria

The Filter Editor allows an end-user to filter data (display those records that meet
specific requirements), by visually constructing filter criteria in a straightforward
graphical form. Although, using the Filter Editor, an end-user can build both simple and
complex filter criteria, the main destination of the Filter Editor is creating and
representing complex filter criteria, consisting of multiple conditions. Simple filter
conditions can easily be created using columns' filter drop-down lists or the Custom
Filter Dialog.
Functionality
The following sections demonstrate how to construct filter criteria for a grid control
using the Filter Editor.
How to Construct a Simple Filter Condition

Basically, filter conditions specify what data to select from a data source and display in a
grid control. A typical simple filter condition consists of three parts: the column/field
name, operator and a value(s). For instance, '[Discount] >= 0.05' is a simple filter
condition, where '[Discount]' is a field name, '>=' is an operator and '0.05' is a value.
This condition when applied to the grid control selects records that have values in the
Discount column greater than or equal to 0.05. Here is how to create this condition via
the Filter Editor (it's assumed that the grid control contains the Discount column,
otherwise, this column is not accessible in the Filter Editor's column list):
1. Open the Filter Editor (for instance, by right-clicking any column's header and
selecting the Filter Editor option).
Figure 3–26. Opening Filter Editor
2. The Filter Editor pop-up displays. If no filtering has yet been applied, the Filter
Editor contains a new filter condition referring to the clicked column. If, say, the
Functionality
Filter Editor has been opened by right-clicking a Product Name column, it looks
like the image below:
Figure 3–27. Filter Editor
3. To create a new filter criteria, such as filtering against the Audit Name, click the
condition's link displaying the column names. This displays the list of available
columns. Select the Audit Name column in this list.
Figure 3–28. New filter selection
4. To select the operator, click the condition's operator link ('Equals') to display the
Functionality
list of supported comparison operators and select the required operator.The

comparison operator list displays only those operators that are supported by the
current column's data type.
Figure 3–29. Selecting Comparison Operator
5. Select a comparison operator and then click on the value box and enter the value.
See example below.
Figure 3–30. Example of New Filter
Functionality
6. Click OK or Apply to filter data using the created filter condition. The grid shows
the filter panel displaying the current filter criteria:
The filter panel contains the Edit Filter button, which also allows an end-user to
invoke the Filter Editor.
How to Construct Complex Filter Criteria With One Logical

Operator
Filter criteria typically consist of two or more simple filter conditions combined by
logical operators (AND, OR, NOT AND, NOT OR). The following example shows
how to construct filter criteria in the Filter Editor, that consist of multiple conditions
Functionality
combined by one logical operator. The "[Audit Name] = 'Physical_Audit' AND [Audit
Status]= Error. To construct it, do the following:
1. Invoke the Filter Editor
2. Set the first condition to: [Audit Name] Equals Physical_Audit.
3. To add a second condition, press the button next to the group's AND operator:
This creates a new condition below the current one:
4. Set the second condition to :[Audit Status] Equals Error.
Figure 3–31. Complex Filter Setup
5. Click OK or Apply to apply the created filter criteria.
How to Construct Filter Criteria Consisting of Multiple
Functionality
Different Logical Operators

Some filter criteria contain multiple logical (Boolean) operators combining simple filter
conditions. To build such criteria via the Filter Editor, first, you need to identify groups
of filter conditions. A filter group is a set of simple filter conditions or other groups
Functionality
combined by the same logical operator. You can think of groups as of clauses in a filter
expression wrapped by round brackets.
1. Invoke the Filter Editor by right-clicking a column's header and selecting the Filter
Editor option.
2. Clear existing filter conditions (if any) by clicking the button:
3. Change the root logical operator to OR. To do this, click the current AND
operator and select OR.
4. Add a new filter condition group by clicking the OR operator and selecting Add
Group.
5. For the created condition, set up the desired values.
Functionality
6. Click the button to add a new condition to the current group.

7. Set up the values for the new condition.
8. Add a new filter condition group. To do this, click the root OR operator and select
Add Group. This adds a new condition group.
9. Click the button to add a new condition to the new group.
10. Click OK or Apply, to apply the created filter criteria.
Functionality
Functionality
About Clarity
Clarity is the telecommunication industry's Operational Support System (OSS) business process
automation company - providing a pre-integrated product and database that streamlines the 17
eTOM elements of OSS into a single suite. This also allows Clarity to provide executive visibility
of the network's impact on revenue and customer experience across both service fulfillment and
assurance.
Having simplified the management of both legacy and next-generation network environments,
Clarity OSS is network and services neutral, driven by templates that are rapidly configurable to
allow operators to cut time to market for any new service by two-thirds. Today Clarity simplifies
network support for over 90 million subscribers worldwide.
Established in 1993, Clarity's global headquarter is in Sydney, Australia, with offices in Asia, the
Middle East, Europe and North America.
For more information, please visit us at www.clarity.com
CLARITY INTERNATIONAL LIMITED

LEVEL 3
15 BLUE STREET
NORTH SYDNEY NSW 2060
AUSTRALIA
TEL: +61 2 9925 5000

FAX: +61 2 9955 9999

Clarity Discovery GUI User Manual 1.5

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Clarity Discovery GUI User Manual 1.5

Uploaded by

Copyright:

Available Formats

User Manual

Clarity Discovery GUI

Document Version: 1.5

Overview of the Clarity Discovery GUI

Launching the Discovery GUI

Figure 1–1. Discovery Application Button on the Quick Launch Toolbar

Figure 1–2. Discovery View

Discovery Task Groups and Buttons

Figure 1–3. Duration button menu

Figure 1–4. Sweep Configuration button menu

Figure 1–5. Discovery Report Views

Chapter 2 Using Discovery

Chapter 3 End-User Capabilities

Figure 2–1. Pinging Process

Adding Sweep Configurations

Field Name Description

Table 2–1. Sweep Configuration Parameters

Field Name Description

Connection ID In case of IP addresses or SNMP enabled devices, user has the

Status Indicates if this configuration is ACTIVE or INACTIVE. An

SNMP A flag to indicate if the set of network elements specified at the

Table 2–1. Sweep Configuration Parameters

See image below:

Figure 2–2. Sweep Configuration

Figure 2–3. Viewing New Sweep Configuration

3 Click Delete. See image below.

Figure 2–4. Delete Sweep Configuration

Figure 2–5. Schedule Jobs Tab; Scheduler View

Figure 2–6. Schedule Pinging

Figure 2–7. Schedule Pinging, image 2

Figure 2–8. Configured Schedules

Figure 2–9. View Trigger Details

Viewing Sweep Reports

Figure 2–10. Duration Task Group

2 Click Apply to save your changes.

Figure 2–11. Viewing Sweep Jobs

The following information is displayed for each sweep job:

Column Name Description

Configuration The name of the Sweep Configuration.

Table 2–2. Sweeps Results table

Column Name Description

Status Valid values are :

Description This field provides information extracted from the Scheduler

Table 2–2. Sweeps Results table

Column Name Description

Table 2–3. Sweep Job Details

Column Name Description

Action Possible value is RECONCILE. This column merely indicates that

Description Any information attached to the network object that is being

Table 2–3. Sweep Job Details

Figure 2–12. Sweep Reconcile Process

The reconcilation process results in one or fewof the following actions:

Yes Yes Active No further action is required

Yes Yes Inactive Reactivate discovery to check the

Yes No New equipment identified. Schedule

No Yes Set Discovery status field for

Table 2–4. Reconciliation Results

Viewing Reconciliation Results

Figure 2–13. Viewing Sweep Results

Column Name Description

Configuration The name of the Sweep Configuration.

Start Time The time when the reconciliation started.

Table 2–5. Updated Sweep Results table

Column Name Description