Introducción

Descripción general

Dependiendo de su message log configuración para usar Kafka o Base de datos, el despliegue podría ser ligeramente diferente.

Kafka Message Log ging

Netowl Namematcher - Utilizado por VoP a través de la Resolución de Identidad (embedded) como el proveedor externo para la coincidencia de nombres.
Gestión de Cuentas - Utilizado por VoP para consultar los detalles de la cuenta utilizados en la coincidencia.
Base de datos - Utilizado para la concesión de licencias
Kafka - Utilizado por VoP para message log ging y almacenando el archivo de procesamiento

Base de datos Message Log ging

Netowl Namematcher - Utilizado por VoP a través de la Resolución de Identidad (embedded) como el proveedor externo para la coincidencia de nombres.
Gestión de Cuentas - Utilizado por VoP para consultar los detalles de la cuenta utilizados en la coincidencia.
Base de datos - Utilizado para la concesión de licencias y message log ging
Kafka - Utilizado por VoP para almacenar el archivo de procesamiento.

Configuración y Tiempo de Ejecución

La Verificación del Beneficiario (VoP) es una aplicación independiente que puede ejecutarse como un servicio, al igual que cualquier otra. IPF application despliegue. El servicio VoP Responder puede ejecutarse como una única instancia o múltiples.

Configuración

El abajo docker la configuración de composición es el mínimo requerido para que el servicio VoP Responder funcione utilizando Kafka para message log ging y MongoDB para la concesión de licencias.

VoP Responder no requiere un Akka Cluster a ser configurado.

ipf {
  mongodb.url = "mongodb://ipf-mongo:27017/vop"  (1)
}

common-kafka-client-settings {
  bootstrap.servers = "kafka:9092" (2)
}

akka {
  kafka {
    producer {
      kafka-clients = ${common-kafka-client-settings}
    }
    consumer {
      kafka-clients = ${common-kafka-client-settings}
      kafka-clients.group.id = vop-responder-consumer-group
    }
  }
}

ipf.verification-of-payee.responder {
  name-match { (3)
    thresholds = [
      {
        processing-entity = "default",
        scorings: [
          {type: "default", lowerbound = 0.80, upperbound = 0.90}
        ]
      }
    ]
  }
  account-management.http.client {
    host = account-management-sim (4)
    port = 8080
  }
  country-filtering.enabled = true (5)
  scheme-allowed-countries = [
    {
      scheme: EPC, (5)
      regulatory-date-timezone: "Europe/Berlin" (5)
      allowed-countries: [
        {country-code: "de", regulatory-date: "2026-09-17"}, (5)
        {country-code: "fr"}
      ]
    }
  ]
}

identity-resolution.comparison.netowl {
  default {
    http.client {
      host = netowl-namematcher (6)
      port = 8080
    }
  }
  table {
    http.client {
      host = netowl-namematcher (6)
      port = 8080
    }
  }
}

Tenga en cuenta los siguientes aspectos clave:

1	Establezca el MongoDB URL según corresponda a su entorno
2	Establezca el Kafka URL según corresponda a su entorno
3	Establezca el Coincidencia de Nombres umbrales requeridos para su implementación
4	Establezca el Gestión de Cuentas nombre de host y puerto según corresponda a su entorno
5	Establezca el Filtrado por País y defina qué códigos de país están permitidos para cada esquema con fecha y hora regulatoria opcional y zona horaria.
6	Establezca el Resolución de Identidad Netowl nombre de host y puerto según corresponda a su entorno

Ejecutando

Docker Componer

El siguiente docker compose es un servicio de implementación de VoP Responder que contiene toda la infraestructura/aplicaciones requeridas (Kafka,MongoDB, Netowl, Gestión de Cuentas) necesaria para ejecutar la aplicación VoP Responder. Esta implementación de muestra se está ejecutando con Kafka para message log ging y MongoDB para la concesión de licencias.

Esto representa una configuración de muestra y no está destinado a representar preocupaciones de rendimiento o resiliencia, las cuales se abordarán en otra sección en futuras versiones.

Docker Compose

services:

  # Infrastructure
  ipf-mongo:
    image: ${docker.registry}/ipf-docker-mongodb:latest
    container_name: ipf-mongo
    ports:
      - "27018:27017"
    healthcheck:
      test: echo 'db.runCommand("ping").ok' | mongo localhost:27017/test --quiet

  kafka:
    image: apache/kafka-native:4.0.0
    container_name: kafka
    ports:
      - "9092:9092"
      - "9093:9093"
    environment:
      - KAFKA_NODE_ID=1
      - KAFKA_AUTO_CREATE_TOPICS_ENABLE=true
      - KAFKA_CONTROLLER_QUORUM_VOTERS=1@localhost:9094
      - KAFKA_CONTROLLER_LISTENER_NAMES=CONTROLLER
      - KAFKA_PROCESS_ROLES=broker,controller
      - KAFKA_LOG_RETENTION_MINUTES=10
      - KAFKA_OFFSETS_TOPIC_REPLICATION_FACTOR=1
      - KAFKA_OFFSETS_TOPIC_NUM_PARTITIONS=1
      - KAFKA_LISTENERS=PLAINTEXT://:9092,LOCAL://:9093,CONTROLLER://:9094
      - KAFKA_LISTENER_SECURITY_PROTOCOL_MAP=LOCAL:PLAINTEXT,PLAINTEXT:PLAINTEXT,CONTROLLER:PLAINTEXT
      - KAFKA_ADVERTISED_LISTENERS=PLAINTEXT://kafka:9092,LOCAL://localhost:9093
      - KAFKA_CREATE_TOPICS=MESSAGE_LOG:1:1,PROCESSING_ARCHIVE:1:1

  # Apps
  account-management-sim:
    image: ${docker.registry}/account-management-simulator:${project.version}
    container_name: account-management-sim
    ports:
      - "8082:8080"
      - "55555:55555"
      - "5006:5005"
    volumes:
      - ${docker-logs-directory}:/ipf/logs
      - ./config/account-management-sim:/account-management-simulator/conf
    user: "1000:1000"
    healthcheck:
      test: [ "CMD", "curl", "-f", "http://localhost:55555/statistics" ]
      interval: 1s
      timeout: 1s
      retries: 90

  netowl-namematcher:
    image: ${docker.registry}/netowl-namematcher:4.9.5.2
    container_name: netowl-namematcher
    ports:
      - "8081:8080"
    volumes:
      - ./config/netowl-namematcher:/var/local/netowl-data/
    healthcheck:
      test: [ "CMD", "curl", "-f", "http://localhost:8080/api/v2" ]
      interval: 1s
      timeout: 1s
      retries: 90

  vop-responder-app:
    image: ${docker.registry}/verification-of-payee-responder-application:${project.version}
    container_name: vop-responder-app
    ports:
      - "8080:8080"
      - "5005:5005"
    volumes:
      - ${docker-logs-directory}:/ipf/logs
      - ./config/vop-responder-app:/verification-of-payee-responder-application/conf
    user: "1000:1000"
    environment:
      - IPF_JAVA_ARGS=-Dma.glasnost.orika.writeClassFiles=false -Dma.glasnost.orika.writeSourceFiles=false -Dconfig.override_with_env_vars=true
    depends_on:
      - ipf-mongo
      - kafka
    healthcheck:
      test: [ "CMD", "curl", "http://localhost:8080/actuator/health" ]

Tenga en cuenta los siguientes aspectos clave:

MongoDB y Kafka los contenedores son imágenes de terceros y no son proporcionadas por Icon Solutions
El Simulador de Gestión de Cuentas se ha añadido con fines ilustrativos y no es proporcionado por Icon Solutions, sino que debe ser un customer implementación conforme a la API de Gestión de Cuentas
El Netowl La imagen anterior es un contenedor de terceros no suministrado por Icon Solutions y actualmente está siendo utilizado por el Servicio de Resolución de Identidad, que está en funcionamiento.embedded en la aplicación VoP Responder. Para más detalles sobre esto, por favor revise el Resolución de Identidad documentación. Si ya existe una instancia separada en el customer entorno, cualquier customisations debe ser reaplicado aquí si se utiliza una nueva imagen.
La aplicación VoP Responder es creada por Icon Solutions y se aloja en nuestro ipf-lanzamientos repositorio en Nexus.

Kubernetes

El siguiente Kubernetes La configuración es un despliegue del servicio VoP Responder que contiene los ajustes recomendados para desplegar una aplicación VoP Responder. Este despliegue de muestra se está ejecutando con Kafka para message log ging.

Esto representa una configuración de muestra y no está destinado a representar preocupaciones de rendimiento que se tratarán en otra sección en futuras versiones.

Configmap

apiVersion: v1
kind: ConfigMap
metadata:
  name: responder-config
  labels:
    app: verification-of-payee-responder
    product: ipfv2
data:
  application.conf: |
    ipf.mongodb.url = "mongodb://mongo:27017/vop"
    server.port = 8081
    
    identity-resolution.comparison.netowl {
      default {
        http.client {
          host = localhost
          port = 8080
        }
      }
      table {
        http.client {
          host = localhost
          port = 8080
        }
      }
    }
    
    ipf.verification-of-payee.responder {
      name-match {
        thresholds = [
          {
            processing-entity = "default",
            scorings: [
              {type: "default", lowerbound = 0.80, upperbound = 0.90}
            ]
          }
        ]
      }
      account-management.http.client {
        host = account-management
        port = 8080
      }
      country-filtering.enabled = true
      scheme-allowed-countries = [
        {
          scheme: EPC,
          regulatory-date-timezone: "Europe/Berlin"
          allowed-countries: [
            {country-code: "de", regulatory-date: "2026-09-17"},
            {country-code: "fr"}
          ]
        }
      ]
    }
    
    common-kafka-client-settings {
      bootstrap.servers = "kafka:9092"
    }
    akka {
      kafka {
        producer {
          kafka-clients = ${common-kafka-client-settings}
        }
        consumer {
          kafka-clients = ${common-kafka-client-settings}
          kafka-clients.group.id = vop-responder-consumer-group
        }
      }
    }

  license.key: |-
    {
      "product":"NameMatcher",
      "type":"Development",
      "thread limit":1,
       "*":{
          "lifespan":[ "2022-01-01 00:00Z", "2026-01-01 00:00Z" ],
          "features":[ "Latin" ]
       },
      "verification":<hidden>
    }

Despliegue

apiVersion: apps/v1
kind: Deployment
metadata:
  name: verification-of-payee-responder-application
  labels:
    app: verification-of-payee-responder-application
    product: ipfv2
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 0
      maxSurge: 1
  selector:
    matchLabels:
      app: verification-of-payee-responder-application
      product: ipfv2
  template:
    metadata:
      labels:
        app: verification-of-payee-responder-application
        product: ipfv2
    spec:
      imagePullSecrets:
        - name: registry-credentials
      terminationGracePeriodSeconds: 10
      affinity:
        podAntiAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
            - weight: 100
              podAffinityTerm:
                labelSelector:
                  matchExpressions:
                    - key: app
                      operator: In
                      values:
                        - verification-of-payee-responder-application
                topologyKey: "kubernetes.io/hostname"
      containers:
        - name: verification-of-payee-responder-application
          image: registry.ipf.iconsolutions.com/verification-of-payee-responder-application:latest
          ports:
            - containerPort: 8081
              name: server-port
            - containerPort: 5005
              name: debug-port

          env:
            - name: "IPF_JAVA_ARGS"
              value: "-Dma.glasnost.orika.writeClassFiles=false -Dma.glasnost.orika.writeSourceFiles=false"

          livenessProbe:
            httpGet:
              path: /actuator/health
              port: "server-port"
              scheme: HTTP
            initialDelaySeconds: 60
            periodSeconds: 5
            timeoutSeconds: 1
            failureThreshold: 3
            successThreshold: 1

          readinessProbe:
            httpGet:
              path: /actuator/health
              port: server-port
              scheme: HTTP
            initialDelaySeconds: 60
            periodSeconds: 5
            timeoutSeconds: 1
            failureThreshold: 3
            successThreshold: 1

          startupProbe:
            httpGet:
              path: /actuator/health
              port: server-port
              scheme: HTTP
            failureThreshold: 30
            periodSeconds: 10

          volumeMounts:
            - name: application-config
              mountPath: /verification-of-payee-responder-application/conf/application.conf
              subPath: application.conf

        - name: netowl-namematcher
          image: registry.ipf.iconsolutions.com/netowl-namematcher:latest
          imagePullPolicy: IfNotPresent

          ports:
            - containerPort: 8080
              name: netowl-port

          livenessProbe:
            httpGet:
              path: /api/v2/healthy
              port: 8080
            initialDelaySeconds: 15
            timeoutSeconds: 2
            periodSeconds: 5

          volumeMounts:
            - name: netowl-data
              mountPath: /var/local/netowl-data
            - name: application-config
              mountPath: /var/local/netowl-data/license.key
              subPath: license.key


      volumes:
        - name: application-config
          configMap:
            name: responder-config
        - name: netowl-data
          emptyDir: {}

Servicio

apiVersion: v1
kind: Service
metadata:
  name: verification-of-payee-responder-application
spec:
  selector:
    app: verification-of-payee-responder-application
  ports:
    - protocol: TCP
      port: 8081
      targetPort: 8081
      name: server-port

Tenga en cuenta los siguientes aspectos clave:

Servicios de infraestructura como Kafka y MongoDB no han sido proporcionados en la configuración anterior y no suministrados por Icon Solutions.
El Netowl La imagen anterior es un contenedor de terceros no suministrado por Icon Solutions y actualmente está siendo utilizado por el Servicio de Resolución de Identidad, que está en funcionamiento.embedded en la aplicación VoP Responder. Para más detalles sobre esto, por favor revise el Resolución de Identidad documentación. Si ya existe una instancia separada en el customer entorno, cualquier customisations debe ser reaplicado aquí si se utiliza una nueva imagen.
La aplicación VoP Responder es creada por Icon Solutions y se aloja en nuestro ipf-lanzamientos repositorio en Nexus.
El número de réplicas se ha establecido en 3 por razones de balanceo de carga.
Las sondas de Liveness, Readiness y Startup han sido configuradas para soportar la estabilidad de nodos y pods, pero estas pueden ser modificadas si es necesario.
La anti-afinidad de pods ha sido configurada para distribuir los pods a través de múltiples nodos para prevenir un único punto de falla.

Errores de Inicio

VoP Responder requiere una conexión a la base de datos durante el inicio de la aplicación, independientemente de la configuración.message log tipo de ging, debido a Licenciamiento de IPF. Si la aplicación no puede conectarse a la base de datos durante el inicio, se marcará como no saludable. Seguirá intentando reconectarse, y una vez que se establezca una conexión con éxito, la aplicación pasará a un estado saludable.state. Todos los fallos de conexión y los intentos de reintento se registrarán en el registro de la aplicación en el WARN nivel.

Cuando kafka se selecciona como el message log tipo de ging, la aplicación también intentará conectarse a Kafka al iniciar. Sin embargo, la falta de conexión a Kafka se registrará pero no afectará el estado de salud de la aplicación por defecto. Esto es para prevenir message log deteniendo el procesamiento de solicitudes de VoP.

Si message log ging se considera crítico y Kafka los problemas de conectividad deberían afectar la salud y la funcionalidad principal de la aplicación, puede habilitar este comportamiento configurando:

message.logger.send-connector.resiliency-settings.enabled = true

Si la base de datos se vuelve inaccesible después de que el Respondedor VoP haya comenzado, entonces el servicio del Respondedor VoP se volverá inaccesible.