What is the configuration_reader_service probe in DX UIM 23.4.0?

Products

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

Issue/Introduction

• In 23.4 DX UIM version, what is the use of the Configuration Reader Service (CRS)?
  
  
• Is it required for our environment and if yes how to implement it? 

 

Environment

• DX UIM 23.4.*

Cause

• Guidance

Resolution

• The Configuration Reader Service is available 'out of the box' and is automatically installed on the Primary hub. It need not be manually implemented on the Primary hub. It is a new probe introduced as part of 23.4.0 from DX UIM.

• Deploy the CRS on all existing secondary hubs to support the redesigned MCS v23.4.0. For more information please refer to this KB Article:

  Leverage the Redesigned MCS v23.4.0 article

• The CRS PULLS relevant profiles and policies contents from the mon_config_service probe and the backend database into its local cache and makes this cached data available to robots whenever robots are pulling the profiles/policies configuration.

  • This intermediate caching helps interaction between the robot and the mon_config_service probe/database and thus helps achieve higher scalability.

• Lastly, the configuration_reader_service is required because it is already part of the UIM 23.4 build! But there is nothing you have to do to implement it. It works via the 'pull' approach now and should scale better than the previous approach in MCS (mon_config_service 'push' to robots).

Details:

In UIM version 23.4.0, please refer to the document link below for reference.

See: Configuration Reader Service (CRS) Release Notes

Note: Configuration Reader Service, MCS Reader Service, and mcs_reader_service are the same as configuration_reader_service (i.e. the exact probe name). These terms will be corrected in the docs moving forward. Also, the name MCS_Service will be corrected in the tech docs as it's the same as the mon_config_service (i.e. the exact probe name).

The CRS is a Java intermediate layer acting as the interface between Robot and MCS at the Primary hub. It has its own separate cache. This is present at the hub level, and for every polling interval, it synchronizes with MCS at the Primary hub for any updates and subsequently updates the cache. 

The cache has the format-> profile_id, policy_id, hash_profile_id, and hash_policy_id.

The functionality at the Primary hub is as follows:

• CRS connects to MCS (mon_config_service) for any communication
• CRS Synchronizes the cache with the Database at regular intervals.
• Pushes the data to the secondary hub for any notifications.
• Performs an additional role to serve the configuration_reader_service running on non-primary (secondary) hubs.
• CRS performs a callback on the mon_config_service probe to store the robot status.
  • This will happen to change the profile or policy state to OK from pending only when the deployment is successful and checksum matches.

The functionality at the secondary hub is as follows:

• It connects to the CRS probe on the Primary hub.
• Synchronizes the cache with the cache at the Primary at regular intervals. It subscribes to notifications from the Primary hub CRS probe
• Connects to the CRS on the Primary hub to keep its cache up-to-date.
• Connects to the CRS on the Primary hub to provide robot status