Skip Headers
Oracle® Communications Network Integrity Developer's Guide
Release 7.1

E23701-03
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

6 Working with Discovery Actions and Processors

The discovery action is used to discover data, typically from the network, and to persist the discovered data in the Results Model. The discovery action accesses the network using a variety of technologies and protocols; for example: SNMP.

Because SNMP is such an important protocol for network discovery, Network Integrity provides specific features to allow streamlined development of SNMP network discovery cartridges within Design Studio for Network Integrity.

See "Working with SNMP Processors" for further information.

About Supported Processors

The discovery action supports the following processor types:

  • Discovery processor. The discovery processor is a general processor, which has no concrete implementation; it can be implemented using Design Studio to discover network data through various technologies and protocols (for example, TL1 and CORBA) or to model discovered data and persist the data in the Results Model. See "Configuring a Discovery Processor".

  • SNMP processor. The SNMP Processor is a completely implemented processor that polls SNMP-enabled network devices using SNMP. See "Configuring the SNMP Processor".

  • File Transfer processor. For information about the File Transfer processor, see Network Integrity File Transfer and Parsing Guide.

  • File Parsing processor. For information about the File Parsing processor, see Network Integrity File Transfer and Parsing Guide.

Creating a Discovery Action

To create a discovery action:

  1. In Design Studio, from the Studio menu, click Show Design Perspective.

  2. Select New from the Studio menu, then select Integrity, then select Discovery Action.

    The Discovery Action Wizard appears.

  3. Refer to Network Integrity Studio online Help for further information on creating an action.

Configuring a Discovery Action

This section covers those fields that are specific to the discovery action. For information about configuring common fields for all action types, see "Working with Actions" or Design Studio Help.

About Address Handlers

You use the Details tab in the Design Studio action editor to configure a discovery action with an optional Address Handler. To add an existing address handler to a discovery action, see Network Integrity Studio online Help.

If the discovery action is configured with an Address Handler, the Address Handler validates the addresses configured in the scope for the discovery action; depending on the implementation of the Address Handler, the Address Handler may also expand a range of addresses when saving a scan. If the address specified in the scope is not valid, the scan is not saved.

The Address Handler is an optional component for the discovery action. A discovery action without an Address Handler does not have the addresses validated (or expanded if it is a range) when creating a scan. In this case, every address configured in the scope is treated as a single valid address. This approach is not recommended, because an invalid address fails a network discovery at run time. A properly implemented Address Handler catches this kind of error at scan configuration time.

About Result Categories

A discovery action must be configured with a valid result category, which is a mandatory field for a discovery action. If no result category is configured, a validation error is raised and an error marker displayed against the discovery action.

The following is a sample validation error message for a discovery action without result category configured:

Missing - Action has not specified a result category. At least one result category must be specified.

To add a result category to a discovery action, see Network Integrity Studio online Help.

Model validation is required to ensure there is no overlap in the registration of results from different sources.

To add result categories:

  1. Click the Details tab of the action in a configuration editor.

  2. In the Results Categories area, click Add.

    The Create Results Categories dialog box appears.

  3. In the Name field, enter a name for the result category. Specify a proper name for the result category to be created. In Figure 6-1, the name Device is provided.

  4. In the Description field, you can add information about the result category.

  5. Click OK.

  6. From the File menu, select Save.

Figure 6-1 displays a result category, Device.

Figure 6-1 Create Result Category Dialog

Shows Create Result Category dialog box

About the Discovery Action in the Network Integrity User Interface

After successfully building a discovery action in Design Studio (see "Building and Packaging Cartridges"), deploy the cartridge to Network Integrity (see "Deploying and Undeploying Cartridges").

When the cartridge containing the discovery action is successfully deployed to Network Integrity, log on to the Network Integrity user interface and configure a scan using the deployed discovery action.

The recently deployed discovery action is available in the Scan Action list when creating a scan configuration. See Network Integrity online Help for further information about creating a scan.

Figure 6-2 displays a discovery action called Discover Sample Device.

Figure 6-2 Creating a New Scan Configuration

Shows Create Scan, General tab

About UI Parameters

You can configure UI parameters for a discovery action. Usually, a discovery action requires configuration to establish a connection to network devices.

For example, the following parameters could be considered:

  • Port: the port number that a discovery command is sent to

  • Username: the user name to make the connection

  • Password: the password to make the connection

When a scan is created using Discover Sample Device (see "About the Discovery Action in the Network Integrity User Interface"), the Scan Action Parameters section on the Create Scan page is filled with SNMP UI parameters.

Figure 6-3 displays the Scan Action Parameters section for Discover Sample Device with SNMP UI parameters configured.

Figure 6-3 Scan Configuration: UI Parameters

Shows scan action parameters

To make configuration items available when creating the scan, appropriate UI parameters must be configured.

Use the UI Parameters tab in the Design Studio action editor to configure a discovery action with appropriate UI parameters. Add new UI parameters or select existing ones. See Network Integrity online Help for further information.

See also "Working with UI Parameters" for further information.

Creating Discovery Processors

There are several ways to create a discovery processor. However, the best way is to create it using the Processor tab for the discovery action. This method automatically adds the processor to the list of processors that the action uses. And it also ensures that only the supported type of processor is created for the current action.

To create a processor, see Network Integrity Studio online Help.

Note:

Discovery actions support two types of processor: discovery processor and SNMP processor. In the Processor Wizard, the Type field is enabled. Ensure Discovery Processor is selected when creating a discovery processor.

Configuring a Discovery Processor

See "Working with Processors" for more information on configuring a discovery processor in Design Studio.

Implementing a Discovery Processor

Configuration of the discovery action and its discovery processors results in the generation of many deployment artifacts. However, you must supply implementations for the discovery processors.

The implementation needs to implement the invoke method. Two forms of this method are shown:

// Signature for processor which does not have output parameters
public void invoke(DiscoveryProcessorContext context,
                ExampleProcessorRequest request) throws ProcessorException {
       // TODO Auto-generated method stub
 
}
// Signature for processor which has output parameters
public ExampleProcessorResponse invoke(DiscoveryProcessorContext context,
               ExampleProcessorRequest request) throws ProcessorException {
         // TODO Auto-generated method stub
         return null;
}

The parameters and return type of the invoke method are:

  • Processor_NameProcessorResponse: this is the return type, for processors that have output parameters. For processors that do not have output parameters, the return type is void. This class is generated by Design Studio. It is a value object containing values for each of the processor's output parameters. For processors that have output parameters, the invoke method must create a ProcessorResponse object, set it values and return the ProcessorResponse object.

  • Processor_NameProcessorRequest: this is a value object that has the following getters:

    • If UI Parameters have been specified for the discovery action, there is a getter that returns a UI Parameters value object

    • If properties have been defined for the discovery processor, there is a getter that returns a Processor_NameProcessorProperties value object

    • There is a getter for each input parameter that is defined for the processor

    • There is a getter method called getScopeAddress. This method returns the scope address configured for this discovery action

    This class is generated by Design Studio.

  • DiscoveryProcessorContext context: this is an SDK type, which has the following methods:

    • getActionName: returns the name of the action that the processor is executing under

    • getProcessorName: returns the name of the processor

    • persistResults: causes POMS objects to be flushed to the database. This helps to reduce memory consumption. See "About Persist Results" for more information.

    • addToResult: this is used to add a graph of POMS objects to the database under a result group. This method takes three parameters:

      • String resultGroupName: this is the name of a result group under which the results are persisted

      • String resultGroupType: this is the type of the result group under which the results are persisted. This should match a category defined on the action.

      • DiscrepancyEnabled result: this is the root of result object graph to be persisted.

    • getResultGroup: used to get an existing result group from your current scan if you must access the graph of POMS objects previously added to a result group. This method takes two parameters:

      • String resultGroupName: this is the name of a result group under which the results are persisted.

      • String resultGroupType: this is the type of result group under which the results are persisted. This should match a category defined on the action.

Implementation Code Sample

The following Java code snippet demonstrates how to implement invoke for a discovery processor, and how to add results to the result group using the method, addToResult.

public SampleProcessorResponse invoke(
             DiscoveryProcessorContext context,
             SampleProcessorRequest request) throws ProcessorException {
       SampleProcessorResponse modelerResponse = new SampleProcessorResponse();
       SampleDevice device;
 
       // Get the input Sample Response Document from the Request.
       // This input response document is used to model the sample device.
       SampleResponseType response = request.getSampleResponseDocument();
 
       try {
              // Make the Sample Device 
              device = makeSampleDevice(response);
              // Add the device to the result group "Device", which matches 
              // the result category configured in the Discovery Action.
              context.addToResult(device.getName(), "Device", device);
              modelerResponse.setSampleDevice(device);

       } catch (Exception e) {
              // Handle exception here…
       }
       return modelerResponse;
}