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

9 Working with Assimilation Actions and Processors

Assimilation actions perform additional processing on existing Network Integrity network data to derive additional, often higher level, information from the data. For example, an assimilation action might be used to derive connectivity relationships between endpoints discovered by previous scans.

Assimilation actions are different from other types of scans in that they do not retrieve their data from external sources. Instead, assimilation action scans work on the scan results of other discovery, import, or assimilation scans. When you run an assimilation action scan, the scan selects other scans as inputs to the assimilation scan in the Scope page of the Network Integrity GUI. You can select discovery, import, or other assimilation scans as input.As with other scan types, the data from assimilation actions is stored in the Oracle Communications Information Model representation. The data from assimilation scans is flagged as having come from the network. The Network Integrity GUI displays and reports on the data discovered by an assimilation action. The data can also subsequently be processed by discrepancy actions, which compare network discovered data to inventory discovered data and report where differences are found.

Assimilation 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 assimilation action is not abstract, Studio automatically packages the action into a cartridge Integrity ARtifact (IAR) file, which can be easily deployed into the Network Integrity server. Then, on the Network Integrity server, an assimilation scan can be created and executed, and the scan results viewed or reported on.

To create an assimilation action, see the following:

To configure an assimilation action, see the following:

To create an assimilation processor, see the following:

To configure an assimilation processor, see the following:

To implement an assimilation processor, see the following:

Creating Assimilation Actions

You can create assimilation actions using Design Studio. Assimilation actions are created inside a Network Integrity project.

To create an assimilation action:

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

    The Assimilation Action Wizard appears.

  2. In the Project field, set the value to the previously selected cartridge. You can change the cartridge under which the assimilation 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 Assimilation 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 Assimilation Actions

The assimilation action editor contains several tabbed pages.

The following link takes 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 9-1.

Table 9-1 Details Page

Item Description

Description

Lets you provide a short description of the action.

Implementation Prefix

This field is a read-only field. The value for this field is set automatically by Design Studio and is derived from Assimilation Action's name. 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

This multi-valued field lets you define the result categories for the assimilation 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 that comprise the action.

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

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

The Processors tab also enables you to associate conditions with a processor.

UI Parameters Page

Use this page to define the UI Parameters for the assimilation action. UI Parameters are displayed as editable fields in the Network Integrity GUI. The UI Parameters are passed to the implementation code for the assimilation 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 assimilation 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 assimilation 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 Assimilation Actions

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

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

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

    2. Choose whether the assimilation 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 the user enters in the Network Integrity GUI when running a scan.

  3. On the Model page, define the parts of the static Information Model and the dynamic extension that the assimilation action uses to persist its data.

  4. On the Processors page, define the flow of processors that comprise the assimilation 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 about the For Each construct.

To complete the editing of the assimilation action, the assimilation processors must be edited.

Note:

Design Studio does not force any particular order for defining the editing. It is an iterative process in which you switch between various GUI screens to build up the model.

Creating Assimilation Processors

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

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

    The Assimilation 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 Assimilation 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 assimilation action.

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

Configuring Assimilation Processors

The assimilation processor editor contains several tabbed pages.

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

Details Page

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

Table 9-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 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 assimilation 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 Assimilation Processors

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

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

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

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

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

Implementing Assimilation Processors

Many deployment artifacts for the assimilation action and its processors are generated automatically while editing. However, you must supply implementations for the assimilation 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(AssimilationProcessorContext context,
                ExampleProcessorRequest request) throws ProcessorException {
       // TODO Auto-generated method stub
 
}
// Signature for processor which has output parameters
public ExampleProcessorResponse invoke(AssimilationProcessorContext 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, which has the following getters:

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

    • If properties are defined for the assimilation 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.

    This class is generated by Design Studio.

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

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

    • 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.

    • getLatestReultGroupsInScope: returns an IteratorDisResultGroup, which is the latest results in scope. This is essentially the discovery or assimilation scan inputs to the assimilation action.

    • getLatestScanRunsInScope: returns an IteratorDisScanRun, which is the latest scan runs in scope.

      This is also essentially the discovery or assimilation scan inputs to the assimilation action but includes several other objects from the Network Integrity model.

      These additional Network Integrity model objects might be useful in carrying out assimilation processing in some cases.

    • getPreviousAssimilationScanRun: returns the latest completed scan run for the current assimilation scan. Use this to look at previous results, comparing current scope with previous scope.

    • haveAllLatestScansInScopeChanged: returns true if any of the following conditions are met; false otherwise:

      • This is the first scan run for the assimilation scan

      • The latest scan run of every scan that is in the scope of both the previous assimilation run and the current assimilation run is more recent than the previous assimilation run

    • haveLatestScanInScopeChanged: returns true if any of the following conditions are met; false otherwise:

      • This is the first scan run for the assimilation scan

      • At least one scan run in scope is more recent than latest assimilation scan run

      • The scope of the assimilation scan has changed between this run and the previous run

      This function is used to avoid unnecessary assimilation processing.

    • getResultGroup: used to get an existing result group from your current scan if you need to 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.