Dynamic Config Adapter - Changes & Fixes

This page covers the changes and fixes provided to Dynamic Config Adapter in IPF Release 2025.4.0

New

  • Introduced the Dynamic Config Adapter to generate and maintain the dynamic configuration model for the Rules Designer.(PAY-16426)

    • It enables the synchronisation of dynamic configuration settings into the processing registry for use in business rules.

    • The adapter is responsible for reading overridden values from CPS and registering them with the Rules Designer.

  • Enhanced Application Startup with Configuration Validation

    • The adapter now performs strict validation of static configuration properties upon startup to ensure system stability.

    • Validations include checks for supported data types, uniqueness of variable keys and mandatory correlation entries.

    • Prevents application startup in case of critical configuration mismatches (e.g. duplicate destination keys).

  • Refresh All Trigger on Application Startup / Restart

    • Added a "Refresh All" trigger that executes during application startup and restart.

    • The adapter automatically fetches all relevant custom processing settings based on correlation entries and populates the dynamic registry.

  • Refresh on Periodic Interval Trigger

    • Introduced a configurable background trigger that periodically synchronises dynamic variables.

    • Controlled via ipf.dynamic-config-adapter.value-refresh-period, ensuring the registry remains up to date with the latest values from CPS.

  • Real-time Updates via Kafka Integration

    • Added CpsKafkaNotificationHandler that implements `CpsCrudNotificationHandlerPort from CPS service to process live configuration changes.

    • The adapter now listens for CpsCrudNotification events (CREATE, UPDATE, DELETE) and propagates changes to the registry instantly without requiring a service restart.

    • It is important to note that if there is a need for multiple nodes to be able to receive all notifications and update their registries accordingly, consumer group id (in this case ipf.cps-api.client.notification.kafka.consumer.kafka-clients.group.id) needs to be setup differently, it needs to be unique for each node in deployment. Suggested configuration in deployment:(PAY-16431)

ipf.cps-api.client.notification.kafka.consumer.kafka-clients {
        # important to note that if there are multiple instances in environment
        # for each instance to be able to receive all of these notifications and update their registries accordingly
        # consumer group id needs to be setup differently, it needs to be unique
        # that is why here we rely on POD_NAME as consumer group id
        # POD_NAME is coming through environment in deployment manifest
        group.id = ${POD_NAME}
        # since each time pod is restarted we will have different consumer group created
        # it is important to set auto.offset.reset to latest
        # so we always read the latest offset, latest message
        auto.offset.reset = latest
}