Miscellaneous Tasks

Miscellaneous Tasks
uimpga-ga
This article provides the following information:
Compiling and Deploying Example Probes
The Probe SDK package has example probes that you can compile and deploy to a robot in a CA UIM infrastructure. The examples probes are in the examples directory in the Probe SDK package. After you compile and deploy an example probe to Admin Console
Follow these steps:
  1. Access the directory where you placed the Probe SDK package.
  2. Open a command prompt and go to one of the supplied example probe directories.
  3. Enter the command:
    mvn install
    A target directory is added to the selected example probe directory. The target directory contains the compiled probe Zip file you import to Admin Console and then deploy to a robot.
  4. Add and configure new probe profiles, save the configuration, and watch for generated QoS messages and alarms.
For more information about how to configure probes using Admin Console, see the Using Admin Console documentation on the CA Unified Infrastructure Management wiki.
Understanding the Scheduler
When a probe is configured with more than one profile, the scheduler determines when the collection cycle for each profile will run. For example, suppose there are two resources (profiles) configured with an interval of 600. The scheduler will spread the load by spacing out the collection cycle start times. You can see how the scheduler spaces out collection cycles by searching the log file for 'SCHEDULER' as shown in the following log snippet. Note that in this sample the two profiles were named ds1 and ds2 and the scheduler spaced them 180 seconds apart.
Aug 10 14:26:19:083 [main, mock_vm_host] SCHEDULER: using scheduler_maximum_spread_delay_in_seconds = 180 Aug 10 14:26:19:083 [main, mock_vm_host] SCHEDULER: 2 resources with interval of 600 using spread of 180.00 seconds. ... Aug 10 14:26:20:084 [Data Collector - 3, mock_vm_host] PERF: START: ----- Pass-001 --- Data Collector Check Interval for: ds1 ... Aug 10 14:26:20:131 [Data Collector - 3, mock_vm_host] PERF: DONE: mock_vm_host inventory update for ds1 {Seconds=0.047} ... Aug 10 14:29:20:085 [Data Collector - 4, mock_vm_host] PERF: START: ----- Pass-001 --- Data Collector Check Interval for: ds2 ...
Identifying a Probe as Local or Remote
By default, a local probe monitors an element of the local robot system and a remote probe monitors a remote resource. The probe framework uses the local or remote designation when it constructs the 'source' for QOS messages. Indicating that a probe is either local or remote is important so the framework can construct the QOS messages correctly.
Some differences to understand between a local and a remote probe are:
  • Local Probe
    • Not required to have host and port as profile configuration properties
    • Probe config UI displays the inventory as: (Probe)->(Robot)->(Resource)->Inventory
  • Remote Probe
    • Required to have host and port as profile configuration properties.
    • Probe config UI displays the inventory as: (Probe)->(Resource)->(host)->(Inventory)
The reason why the local and remote probe trees are constructed differently is because UIM is designed around everything being attached to an IP device. For local probes, the framework inserts the robot into the inventory to satisfy the IP Device requirement. 
By default probe framework probes are considered to be remote, but can easily be changed to be 'local'. To identify a probe as being a local probe, add the following line of code in the probe constructor:
public ProbeMain(String[] args) throws NimException { super(args, PROBE_NAME, PROBE_VERSION, PROBE_VENDOR); // This is a local probe, so set the flag setLocalMode(true);
Configuration Item Localization
Sometimes when a custom probe is developed, there is also a need to define new CI definitions and metrics. New CI definitions are managed by CA Technologies. When new CI definitions are approved, the new UIM packages become available. These packages are the ci_defn_pack.zip, the mps_language_pack.zip, and the wasp_language_pack.zip. The ci_defn_pack and the mps_language_pack packages are installed on the UIM instance, while the wasp_language_pack package is installed on the robot running CA Unified Management Portal (UMP).
Follow these steps:
  1. Use Admin Console to
    Import
    ci_defn_pack.zip, mps_language_pack.zip, and wasp_language_pack.zip packages into your Archive.
  2. Deploy ci_defn_pack and mps_language_pack to your primary hub. Deploy wasp_language_pack to the robot running UMP. After deploying the packages, they will appear in
    Installed Packages
    .
  3. On the primary hub,
    Restart
    the nis_server service.
  4. On the primary hub,
    Restart
    service_host, which restarts Admin Console. While service_host is restarting, Admin Console is unavailable.
After nis_server restarts, you can verify that the new CI Type and Metric Definitions were added by inspecting the database tables:
  • CM_CONFIGURATION_ITEM_DEFINITION
  • CM_CONFIGURATION_ITEM_METRIC_DEFINITION
The SNAPSHOT localization packages CA makes available to probe developers are for the purpose of testing a probe only. Do not distribute them to customers.
Communicating with a Device Under Test
The means by which your probe interacts with the system or device under test is outside of the scope of the Probe SDK. The Probe SDK provides no assistance and places no restrictions in this manner. Some general software engineering practices that may be of benefit when designing how to communicate to the device under test are:
  • Construct your domain specific code in a manner that allows it to be executed and validated independently of the Probe SDK components.
  • Place domain specific logic in a separate class that is invoked from getUpdatedInventory()
  • Don't swallow exceptions and silently fail. You should catch any exceptions your logic throws in getUpdatedInventory() and wrap and re throw as a NimException. The probe framework will then generate an alarm.
  • Avoid circular dependencies. The primary probe class, ProbeMain.java, is dependent on the probe framework and will be dependent on the domain specific logic you write. However there is no reason that your domain specific logic needs to be dependent on the probe framework.