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

8 Working with Import Actions and Processors

Import actions are used to import data from an inventory system into Network Integrity. The data is stored in the Oracle Communications Information Model representation and is flagged as having come from the inventory system. The Network Integrity GUI displays and reports on the data discovered by an import action. The data can also subsequently be processed by Discrepancy actions that compare network-discovered data to inventory-discovered data, and reports differences between them.

Import actions are edited in Design Studio. As a result of the editing, Studio generates most of the required deployment artifacts. However, you must supply some Java implementation. After this is done, and all error problems are cleared, and if the import action is not abstract, Studio automatically packages the action into a cartridge Integrity ARtifact (IAR) file that can be easily deployed into the Network Integrity server. Then, on the Network Integrity server, an import scan can be created and executed, and the scan results viewed or reported on.

To create an import action, see the following:

To configure an import action, see the following:

To create an import processor, see the following:

To configure an import processor, see the following:

To implement an import processor, see the following:

Creating Import Actions

You can create import actions using Design Studio. Import actions are created inside a Network Integrity project.

To create an import action:

  1. Select New from the Studio menu, then select Integrity, then Import Action.

    The Import Action Wizard appears.

  2. In the Project field, set the value to the previously selected cartridge. You can change the cartridge under which the import action is created by selecting a different cartridge.

  3. In the Name field, enter a name for the new action.

  4. In the Folder field, select a location for the action. If you leave the Folder field blank, the action is created in the default location. The folders can be found inside the Import Actions folder of the project tree in the Cartridge view.

  5. Click Finish.

    Studio creates the new action and displays it in the action editor. The Details page is displayed. See "Details Page" for more information on configuring this page.

Configuring Import Actions

The import action editor contains several tabbed pages.

The following links take you to reference topics for the pages used to define an action:

Details Page

The Details page contains general settings for the action, as shown in Table 8-1.

Table 8-1 Details Page

Item Description

Description

Lets you provide a short description of the action.

Implementation Prefix

Takes the value of the component name by default. This field cannot be changed. This field is used by Design Studio when creating some deployable artifacts.

Abstract

Lets you specify whether the action is abstract.

If the action is abstract, it can only be used as a component within another action.

If the action is not abstract, it can be deployed and a scan can be executed from it.

Result Categories

A multi-valued field that lets you define the result categories for the import action.

A result category classifies the results of a scan. Different parts of a scan can be placed into different result categories.

Documentation

Lets you add any other information about the action.


Processors Page

The Processors page is used to define the processors included with the action.

See "About the Processors Tab" for more information about the tasks carried out using the Processors tab.

The only processor type that can be created and used for an import action is the import processor.

UI Parameters Page

Use this page to define the UI Parameters for the import action. UI Parameters are displayed as editable fields in the Network Integrity GUI. The UI Parameters are passed to the implementation code for the import action processors.

See "Using UI Parameters in Actions" for more information about UI parameter configuration.

Model Page

Use the Model page to specify the model collections that the import action uses. The model collection defines the parts of the Information Model and the dynamic extensions that are related to the model collection. In effect, the Model tab specifies which parts of the Information Model are used by the import action.

See "About Model Collections in Actions" for more information about model collections.

Conditions Page

The Conditions page allows conditions to be defined. Conditions can be associated with processors to cause conditional execution of the processor.

See "About Conditions" for more information about conditions.

Editing Import Actions

This section provides an outline of the main steps involved in editing an import action.

  1. From the import action editor, select the Details page.

    1. Define the result categories to be produced by the import action.

    2. Choose whether the import action is abstract

    3. Enter a short description in the Description field

    4. Enter a more complete description in the Documentation field.

  2. On the UI Parameters page, define the parameters that the user enters in the Network Integrity GUI when running a scan.

  3. On the Model page, define the Model Collections that the import action uses. The Model Collections define a subset of the Information Model and specifications.

  4. On the Processors page, define the flow of processors that comprise the import action.

    1. If conditional logic is required, use the Conditions tab to define conditions for the processors. Use the Processor tab to associate the conditions with the processors.

    2. Define iterating logic using For Each constructs.

      See "About For Each Processors" for more information on the For Each construct.

Creating Import Processors

There are several ways to create an import processor. However, the best way is to create it using the Processor tab for the import 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 an import processor:

  1. From the Processor tab of the import action, in the action processors section, click Add.

    The Import Processor Wizard appears.

  2. Do not change the value in the Project field, as this field should already be set to the correct cartridge.

  3. In the Name field, enter a name for the new processor.

  4. In the Folder field, select a location for the processor. If you leave the Folder field blank, the action is created in the default location. The folders can be found inside the Import Processors folder of the project tree in the Cartridge view.

  5. Click Finish.

    Studio creates the new processor and displays it in the action editor. The Details page is displayed.

  6. Click Save to save the import action.

  7. Double-click the new import processor in the Actions Processors list to open the new import processor editor.

Configuring Import Processors

The import processor editor contains several tabbed pages.

The following link takes you to reference topics for the pages used to define an import processor:

Details Page

The Details page contains general setting for the processor, as shown in Table 8-2.

Table 8-2 Details Page

Item Description

Description

Lets you provide a short description of the processor.

Implementation Class

Lets you specify the implementation class for the processor.

Design Studio automatically generates an interface class, which the implementation class must implement.

You can select an existing class, or create a class, by selecting the Implementation Class link.

If you use the link, the implementation class is created to match the processor interface.

Implementation Prefix

You cannot change this field. It is set automatically, and is based on the name of the import processor.

This field's value is used by Design Studio when creating some deployable artifacts.

Documentation

Lets you add any other information about the processor.


Context Parameters Page

The Context Parameters page is used to define the processor's inputs and outputs.

See "About Context Parameters" for more information about the tasks done using the Context Parameters page.

Properties Page

Use this page to define the properties for the import processor. Properties are name value pairs that are passed to the processor.

See "About Properties and Property Groups" for more information about properties configuration.

Editing Import Processors

This section provides an outline of the main steps involved in editing an import processor.

  1. Define properties to be passed to the import processor using the Properties page.

  2. On the Context Parameters page, define the inputs and outputs for the import processor.

  3. Use the Details page to specify the implementation class.

When the editing of the import action and processors is completed, complete the import action by coding the implementations for the import processors.

Implementing an Import Processor

Many deployment artifacts for the import action and its processors are generated automatically while editing. However, you must supply implementations for the import processors using the invoke method.

Two forms of this method are shown in the following code fragments:

// 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 its values and return the ProcessorResponse object.

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

    • If UI Parameters are specified for the import action, there is a getter that returns a UI Parameters value object

    • If properties are defined for the import 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 is not useful for import processor implementation. Instead, the inventory system address and authentication information should be retrieved using the POMS API.

      See "POMS SDK" for more information.

    This class is generated by Design Studio.

  • DiscoveryProcessorContext context: this is an SDK type that 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.