|Oracle® Communications Network Integrity Developer's Guide
|PDF · Mobi · ePub|
Actions are Network Integrity entities that represent a particular software function that a Network Integrity cartridge performs at run time. A Network Integrity cartridge usually contains multiple actions.
At run time, when an action is deployed to Network Integrity (by deploying a Network Integrity cartridge from Studio, or by using the Oracle Cartridge Deployer), an action is implemented as a J2EE Message Driven Bean (MDB).
Actions are of different types:
Discovery Action: used for discovering data, typically from a network, and persisting the discovered data in the Results Model using POMS entity managers.
Import Action: used for importing data, typically from an inventory system, and persisting the inventory data in the Results Model using POMS entity managers.
Assimilation Action: used for post-processing previously discovered data, and persisting the data in the Results Model using POMS entity managers. The assimilation action cannot produce import results.
Discrepancy Detection Action: used for finding discrepancies between discovered entities and imported entities.
Discrepancy Resolution Action: used for fixing discrepancies in an external system, or a network.
To create an action, see the Network Integrity Studio online Help.
An action performs a certain function that is supported by a Network Integrity cartridge. To implement this function, a processor is introduced to implement an atomic sub-function, which is part of the functions that this action performs. For example, an SNMP discovery action at least has a processor that carries out SNMP polling on network devices and another processor that models the discovered raw SNMP data into Results Model and persists it using POMS entity managers.
An action contains one or more processors. Each processor is responsible for an atomic function. By chaining the processors inside an action, the action can perform a complex function, such as discovering a network, importing an inventory system, assimilating discovered data, or detecting and resolving discrepancies.
Figure 4-1 shows a sample action, containing three processors.
When an action is invoked, the processors are executed in the sequence they were placed inside this action. The code-generated Action Controller controls execution. In the example shown in Figure 4-1, the three processors are executed in the following sequence:
See "Working with Processors" for more information about processors.
The Processors tab in the Action Editor enables you to:
Add a processor to an action. For more information, see the Network Integrity Studio online Help.
Create and configure For Each components within an action. For more information about For Each components, see "About For Each Processors".
Move the processor up or down to change the execution sequence of the processors. For more information, see the Network Integrity Studio online Help.
Remove a processor from the action. For more information, see the Network Integrity Studio online Help.
Add conditions to apply to the action. For more information, see "Setting Conditions in Network Integrity".
An action can contain another action. This is done by adding an existing action to a new action. This extensibility is done using Network Integrity Design Studio.
When an action contains another action, it replicates the other action's processors and executes the processors in the same sequence. The execution sequence of the processors added from another action cannot be changed.
New processors can be inserted in between if the overall sequence of the imported processors from another action remains the same.
To add an existing action:
Select the Processors tab in the Action Editor.
A dialog is displayed asking you to select an action or processor to add.
From the list of available actions, select an action to add.
Click OK to add the action.
Figure 4-2 shows the composition of an action.
Action B contains two processors (processor B1 and processor B2), and an action (action A is the sample action shown in Figure 4-1).
In this example, action B actually contains five processors. The sequence of the processors from action A cannot be changed in action B. However, new processors can be inserted between the processors from action A.
For example, the Cisco SNMP cartridge contains a Discovery action, which extends the Discovery action from the MIB-II SNMP cartridge.
Figure 4-3 shows the processors contained inside the Cisco SNMP Cartridge.
This discovery action contains Discover MIB II SNMP as the imported action. By importing the MIB II SNMP Discovery action, Cisco SNMP Discovery action automatically gets the MIB II discovery functions (logical device discovery) provided by the productized MIB-II SNMP cartridge.
In addition, the Cisco SNMP discovery action discovers physical devices (through Cisco SNMP Physical Collector processor and Cisco SNMP Physical Modeler processor), modeling the logical side (through the Cisco SNMP Logical Collector Processor and Cisco SNMP Logical Modeler processor).
Every action becomes a J2EE Message Driven Bean (MDB) at run time. The Controller controls the execution sequence of the processors inside an action.
Both the Action MDB and Controller classes are code-generated. No further Java coding is necessary for either the MDB or the Controller class. These two classes are transparent to a Network Integrity cartridge developer using Design Studio. At design time, the cartridge developer should not have to implement any Java code for an action because all required Java implementations for actions are code-generated.
The generated Action MDB and Controller classes can be found at the following directory:
where the elements on the path are defined as follows:
Studio_Workspace: Eclipse Workspace root
NI_Project_Root: Network Integrity project root
Project_Default_Package: The default package configured at the cartridge editor
Action_Type: Select from the available action types:
Action_Implementation_Prefix: action implementation prefix in lowercase.
The generated MDB class is named: ActionNameMessageDrivenBean.java.
The generated Controller class is named ActionNameMessageDrivenBeanController.java.
During design time, compilation errors or warnings against this Java class might occur. These errors and warnings are cleared after properly implementing and configuring the action (and its processors).
Figure 4-4 shows the directory that contains the generated MDB and Controller classes.
Actions can contain conditions. By creating conditions and applying conditions to processors, you can dynamically control which processors are executed inside an action.
See "Setting Conditions in Network Integrity" for more information about conditions.
Actions can contain model collections. A model collection is a collection of specifications.
See "Model Extension Using Specifications" for more information.
Adding a model collection to an action enables the generation of the Specification Helper classes (when Studio is building the action). These classes are by the action for modeling the discovered data into the Oracle Communications Information Model and persisting it using POMS entity managers.
If an action is imported into another action in a different cartridge, the Network Integrity packager uses the model collections to determine how to build the specification DAO files so that all the model collections (from both the imported action and the current action) are included.
See "Model Collections" for more information about model collections.
An action can contain a For Each processor, which is added when configuring processors using the Processors tab. The Action Controller sets the execution sequence of the processors based on the order in which the processors are configured. Usually a processor is invoked only once, and when it has executed, the Controller invokes the next processor, until all processors in an action are invoked. However, one or more processors may be executed repeatedly. For example, when importing an inventory system, it is typical to first get a list of devices from the inventory system, then go through the list of devices and import each device singly into Network Integrity. In this example, the processor importing a single device is repeatedly executed for all the devices in the returned device list. You can use For Each processors to create a loop, containing one or more processors, to repeatedly execute the processors. Design Studio for Network Integrity supports nested For Each processors.
A For Each processor expects a collection as the input parameter so that it can iterate through the collection and, for each object in the collection, invoke the processors inside the loop. There must be a preceding processor that outputs an array or a Java object that implements
java.lang.Iterable (for example,
java.util.List) as an output parameters to create a For Each processor.
Figure 4-5 displays a processor, GetAllDevices, which outputs a list, deviceList in the action, DemoImportAction.
The next step is to create a For Each processor, called For Each device in deviceList. To create a For Each processor, see the Network Integrity Studio online Help.
Figure 4-6 displays the new For Each processor.
Next, create a processor, ImportDevice, which runs inside the For Each processor to import a single device into Network Integrity. To create a processor, see the Network Integrity Studio online Help.
After creating the processor, click Move Up to move this processor inside the For Each processor.
Figure 4-7 shows the resultant processor implementation.
Expand the For Each processor to see ImportDevice inside the For Each loop. For each device from the input device list, ImportDevice imports it into Network Integrity.