oi_connector and apm_bridge setup and best practices
search cancel

oi_connector and apm_bridge setup and best practices

book

Article ID: 412443

calendar_today

Updated On:

Products

CA Unified Infrastructure Management On-Premise (Nimsoft / UIM) CA Unified Infrastructure Management SaaS (Nimsoft / UIM) DX Unified Infrastructure Management (Nimsoft / UIM)

Issue/Introduction

This Article includes guidence on setting up the oi_connector and apm_bridge for integrating DX UIM into DXO1.

Environment

  • DX UIM 23.4.*
  • DXOI / DX02


    Best practice for latest versions to run as of February 2026:

     

  • For DX UIM 23.4.4 and earlier 

 

Cause

Setup and configuration guidance

Resolution

oi_connector deployment and configuration

  1. Deployment

    The oi_connector must be on a robot connected to/under the Primary hub but ideally not on the Primary hub robot itself. It can also be installed to a secondary hub connected directly to the Primary hub.

    The oi_connector and apm_bridge should be co-located on the same robot.

    If both probes are already on the Primary Hub, then establish and use a dedicated robot for both the oi_connector and apm_bridge and deactivate the oi_connector on the Primary.

     

Steps required to install the oi_connector on a robot under the Primary hub:

For an OI Connector instance deployed on a remote robot machine connected to the primary hub the following keys must be set via Raw configure:

    • data_engine_address
    • primary_hub_address
    • connect_to_primary_hub

The values of the following parameters can be set from Infrastructure Manager -> Setup -> Raw Configure. To do so, deactivate if the running probe is running, set the parameter values, and activate the probe again.

For example:

data_engine_address = /<domain_name>/ <primary_hub_name>/<primary_robotname>/data_engine

primary_hub_address = /<domain_name>/ <primary_hub_name>/<primary_robotname>/hub

connect_to_primary_hub = true

     2. Configuration

         Add/adjust the following recommended keys and value:

skip_second_pass_ci_fetch = true


The keys listed below should already be present and set in the oi_connector but it's good to double-check and adjust their values as well.

get_ci_details_alive_time_days = 30 but this may need to be tested by setting it lower, e.g., 10

qos_bulk_size = 5000

qos_payload_bulk_size = 5000

get_ci_details_by_met_id_list = true

task_count = 1000

bulk_size = 2000

db_conn_max_pool_size = 15   (default is 10)

     3. This oi_connector parameter needs to be set to false but under good processing could be set to true.

         enable_alive_time_batches = false
         

     4. loglevel = 1 or 2



  • The Hub Status ->Queued column should remain low when refreshed and not continue to build.
  • The queue should remain green not turn yellow.
  • The Sent column should be continuously sending QOS messages.

      5. Check the log for OutOfMemory errors, for example:

Caused by: java.lang.OutOfMemoryError: GC overhead limit exceeded 
  • If any Java memory errors exist add 2GB or more to the min and the max and deactivate the probes
  • Java best practice: keep the min and max within 2 GB of each other
  • Wait for the port and PID to drop
  • Activate the probes.

An attached file (oi_connector setup parameters) includes a partial extract to serve as a short reference for the <setup> section parameter values used in a very large environment which processes millions of messages.

apm bridge deployment and configuration

 

  • When the apm_bridge is deployed on the same robot as the oi_connector, it needs the following parameters updated with the relevant information, 

primary_hub_address = /<domain_name>/ <primary_hub_name>/<primary_robotname>/hub
connect_to_primary_hub = true



  • In apm_bridge 2.03 and earlier the inventory_alive_time_days parameter is only configurable in the range of 1 to 7.

    The inventory related to certain probes (such as url_response and net_connect) are not being published because these probes do not periodically update the alive_time in the cm_computer_system table. Therefore, with these settings the inventory count in DX UIM may not correspond /differs to inventory count in DXO2 as it would be missing those devices.

    To avoid this the patch for apm_bridge included in this KB can be deployed: Not all devices / inventory are published from DX UIM to DXO2 

 

After following the steps above, if the issue persists, attach the oi_connector.log and apm_bridge.log and data_engine.log to your support case.

Compatibility of Deployment on Secondary Hubs and Robots Connected to the Primary Hub
  • Configure the Security certificate on the secondary hub (hub-robot) or robot under the hub

    The certificate (certificate.pem) is stored on the Primary Hub in the ../nimsoft/security folder.

  • opy the certificate FROM the Primary hub TO the robot where the probe is deployed and add the path of the certificate pointing to the target robot's controller configuration file .../opt/nimsoft/robot/robot.cfg.

    For example, you may take a look at the Primary Hub's controller configuration file.

    Linux robot example:

       cryptkey = /opt/nimsoft/security/certificate.pem
     

    Windows robot example:

     
     

 

Upgrade oi_connector and apm_bridge: 


To upgrade oi_connector and amp_bridge follow the Best Practices to upgrade oi_connector and apm_bridge

Additional Information

Network
When the oi_connecter and apm_bridge are offloaded/deployed on a separate robot under the Primary hub, best practice is that the robot is on the same subnet.

Java memory settings
Set the apm_bridge java min/max memory settings under the Startup->options section to at least 2g and 4g respectively. In larger environments with millions of QOS messages being processed through the queue, the java min/max may be set as high as 14/16GB RAM respectively but its best to track the memory usage and see how much memory the probe takes versus what it appears to need. Use Windows Task Manager and/or top command (Linux/Unix).

Robot system sizing (oi_connector and apm_bridge)
Processor 3GHz or higher recommended

  • 12 cores
  • 16-GB RAM (Consider increasing the max heap by 4 GB to use the reconciliation feature)
  • SSD: 200-GB or more

oi_connector queue processing
Also note that the axaqueuegateway.uimQos queue processing can benefit from the addition of more virtual processors on the system in cases where the probe may be having difficulty with qos event processing, and/or throwing errors such as:

[QOS_PROCESSOR_THREAD-337, oi_connector] Error while posting the qos data net.sf.ehcache.CacheException: Faulting from repository failed


Related KBs/Documents: 

    Attachments

    oi_connector setup parameters for reference get_app
    Powered by Wolken Software