Pasos de Migración para IPF-2024.4.0
Pasos de Migración para CSM Reachability
Límite de Direcciones en la Configuración de Liquidación de Agentes
| Este script de migración es opcional; sin embargo, se recomienda encarecidamente ejecutar lo siguiente para garantizar la compatibilidad con futuros cambios. Esto se debe a que se ha añadido la dirección de límite como una opción en la configuración de Liquidación de Agentes. |
Si se ejecuta el script, el limitDirection el campo se le asignará un valor predeterminado de OUTBOUND. Si el script no se ejecuta,limitDirection permanecerá sin establecer en la base de datos, pero aún se tratará como OUTBOUND en el código.
db.getCollection("settings-agent-settlement-settings")
. updateMany(
{ "payload.agentLimits.limitValue":{$exists: true}},
{ $set: { "payload.agentLimits.$[elem].limitDirection": "SALIDA"}},
{ arrayFilters: [ { "elem.limitDirection": { $exists: false} } ] }
)
db.getCollection("settings-agent-settlement-settings")
. updateMany(
{ "carga.customParticipantLimits.limitValue":{$exists: true}},
{ $set: { "payload.customParticipantLimits.$[elem].limitDirection": "SALIDA"}},
{ arrayFilters: [ { "elem.limitDirection": { $exists: false} } ] }
)
db.getCollection("settings-agent-settlement-settings")
. updateMany(
{ "payload.participantCountryLimits.limitValue":{$exists: true}},
{ $set: { "payload.participantCountryLimits.$[elem].limitDirection": "SALIDA"}},
{ arrayFilters: [ { "elem.limitDirection": { $exists: false} } ] }
)Pasos de Migración para el Procesador de Métricas
Los elementos de la configuración del Procesador de Métricas IPF se han desacoplado de versiones específicas. MPS versiones y nombres de flujo.
Anteriormente, cuando payment flows obtener un aumento de versión o nombres de events o (global) los estados cambian, la configuración del procesador de métricas debe actualizarse de acuerdo con estos cambios, de lo contrario, las métricas de pagos no se etiquetarán correctamente en Prometheus.
Tres de las configuraciones del Procesador de Métricas que se basaron en versiones de flujo y state los nombres han sido eliminados, con la especificación de que estos han sido trasladados a la MPS Definición de Flujo.
Estos tres valores de configuración requieren:
-
critical-path-duration- requiere la configuración de global state nombres por tipo de pago -
waiting-duration.waiting-states- utilizado para indicar dónde el payment flows tuve que esperar por external responses -
tagged-with-htm-on-any-of- se utiliza para indicar que un pago se realizó en HTM
La migración es actualmente opcional, con el Procesador de Métricas aún apoyando lo anterior. Hocon claves de configuración. Sin embargo, se recomienda actualizar su MPS Payment Flows con el apropiado etiquetas para indicar el camino crítico y los estados de espera, luego elimine la configuración existente del Procesador de Métricas.
La migración requiere el uso de MPS Etiquetas de flujo como reemplazo para el HOCON configuración, consulte el Documentación de Orquestación de Flujos para más información sobre Etiquetas.
Se pueden añadir etiquetas a ambos State Definiciones y Event Definiciones utilizando el MPS Inspector ventana como así:
-
Ventana del Inspector para Event Definiciones
-
Ventana del Inspector para State Definiciones
Ejemplo de Migración
Los siguientes pasos harán referencia a los nombres de flujo y estados del ejemplo a continuación Procesador de Métricas HOCON configuración como guía para migrar su MPS Definiciones de flujo. Estos nombres y estados de flujo son únicamente un ejemplo, su implementación existente será diferente.
ipf.business-metrics-processor.payment-metrics {
htm {
events = ["Manual Intervention", "Registered Task" ]
}
payment-duration {
critical-path {
critical-path-states-by-payment-type = [
{
payment-type = "InstantPayment"
start-state = "Validating"
end-state = "Instructing"
}
]
}
waiting {
waiting-states-by-flow = [
{
flow-name = "DebtorCT"
states = ["Checking Bank System A", "Checking Bank System B", "Waiting for Response"]
}
]
}
}
}Duración de la Ruta Crítica
Para migrar la configuración de la ruta crítica para el ejemplo anterior,MPS flujos que comprenden el InstantPayment El tipo de pago necesita ser actualizado.
Dentro de estos MPS Flujos, los estados de flujo que se alinean con el global states Validating, y Instructing debe ser actualizado con las etiquetas CRITICAL_PATH_START y CRITICAL_PATH_END respectivamente.
Una vez que este cambio se haya propagado a las aplicaciones descendentes, es seguro eliminar el Procesador de Métricas.critical-path bloque de configuración.
Duración de la Espera
Para migrar la configuración de espera para el ejemplo anterior, el DebtorCT MPS El flujo necesita ser actualizado.
El WAITING_STATE se debe agregar una etiqueta al Checking Bank System A,Checking Bank System B y Waiting for Response estados dentro de la DebtorCT MPS Flujo.
Una vez que este cambio se haya propagado a las aplicaciones descendentes, es seguro eliminar el Procesador de Métricas.waiting bloque de configuración.
HTM etiqueta métrica
El HTM la etiqueta solo está disponible al utilizar el Human Task Manager Flo Client para integrarse con el Human Task Manager aplicación.
Para migrar el HTM configuración para el ejemplo anterior, el Manual Intervention y Registered Task events dentro de todo MPS Los flujos deben ser actualizados con el HTM etiqueta.
Una vez que este cambio se haya propagado a las aplicaciones descendentes, es seguro eliminar el Procesador de Métricas.htm bloque de configuración.
Pasos de Migración para el Poller de Archivos
El sondeador de archivos ha sido actualizado para limpiar y recrear el sondeador de archivos.scheduler trabajos al iniciar la aplicación. Como parte de este cambio, los valores para jobRequestor y jobSpecificationId Los campos han sido actualizados. Los nuevos y los valores anteriores se enumeran a continuación.
| Campo | Anterior | Nuevo |
|---|---|---|
|
|
|
|
Prefijado con |
Prefijado con |
Dado que la lógica de limpieza implementada se basa en los nuevos valores anteriores, los trabajos existentes en el jobSpecification y jobExecutionStatus Las colecciones en Mongo deberán ser eliminadas manualmente de estas colecciones.
Pasos de Migración para Egreso Processing Data
La configuración predeterminada para IPF Processing Data plugins para System Event Exporter, Direct Data Exporter y Message Logger para propagate-transport-errors ha sido cambiado a false.
Si desea continuar propagando errores de transporte, debe actualizar su configuración para establecer propagate-transport-errors to true para cada exportador en búfer.
ipf.processing-data.egress{
system-events {
buffered-exporter {
propagate-transport-errors = true
}
}
message-logger {
buffered-exporter {
propagate-transport-errors = true
}
}
direct-exporter {
buffered-exporter {
propagate-transport-errors = true
}
}
}Pasos de migración para SerializationHelper
Todas las llamadas a SerializationHelper.objectMapper() donde el ObjectMapper la instancia que devuelve es customised, por ejemplo, llamando setSerializationInclusion(), debe ser reemplazado por ObjectMapperFactory.createObjectMapper() que devuelve una nueva instancia.
Ver Documentación de serialización para más información