Adaptador de Configuración Dinámica - Cambios y Soluciones
Esta página cubre los cambios y correcciones proporcionados al Adaptador de Configuración Dinámica en la versión 2025.4.0 de IPF.
Nuevo
-
Introdujo el Adaptador de Configuración Dinámica para generar y mantener el modelo de configuración dinámica para el Diseñador de Reglas.(PAY-16426)
-
Permite la sincronización de configuraciones dinámicas en el registro de procesamiento para su uso en reglas de negocio.
-
El adaptador es responsable de leer los valores sobrescritos de CPS y registrarlos con el Diseñador de Reglas.
-
-
Inicio de Aplicación Mejorado con Validación de Configuración
-
El adaptador ahora realiza una validación estricta de las propiedades de configuración estática al iniciar para garantizar la estabilidad del sistema.
-
Las validaciones incluyen verificaciones de tipos de datos soportados, unicidad de las claves de las variables y entradas de correlación obligatorias.
-
Previene el inicio de la aplicación en caso de desajustes críticos de configuración (por ejemplo, claves de destino duplicadas).
-
-
Actualizar Todos los Disparadores al Iniciar / Reiniciar la Aplicación
-
Se añadió un disparador de "Actualizar Todo" que se ejecuta durante el inicio y reinicio de la aplicación.
-
El adaptador obtiene automáticamente toda la información relevante custom configuración de procesamiento basada en entradas de correlación y pobla el registro dinámico.
-
-
Actualización en el desencadenador de intervalo periódico
-
Se introdujo un disparador de fondo configurable que sincroniza periódicamente variables dinámicas.
-
Controlado a través de
ipf.dynamic-config-adapter.value-refresh-period, asegurando que el registro se mantenga actualizado con los últimos valores de CPS.
-
-
Actualizaciones en tiempo real a través de Kafka Integración
-
Agregado
CpsKafkaNotificationHandler that implements `Cps Crud Notification Handler Portdesde el servicio CPS para procesar cambios de configuración en vivo. -
El adaptador ahora escucha por
CpsCrudNotificationeventos (CREAR, ACTUALIZAR, ELIMINAR) y propaga los cambios al registro instantáneamente sin requerir un reinicio del servicio. -
Es importante señalar que si existe la necesidad de que múltiples nodos puedan recibir todas las notificaciones y actualizar sus registros en consecuencia, el id del grupo de consumidores (en este caso
ipf.cps-api.client.notification.kafka.consumer.kafka-clients.group.id) necesita ser configurado de manera diferente, debe ser único para cada nodo en la implementación. Configuración sugerida en la implementación:(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
}