Inicio Rápido del Conector de Recepción

Esta página proporciona detalles sobre cómo comenzar a recibir mensajes de sistemas externos, utilizando conectores de recepción proporcionados por la biblioteca de conectores.

Dependencias

Antes de construir un conector de recepción, el connector-core la biblioteca debe ser incluida como una dependencia.

 <dependency>
    <groupId>com.iconsolutions.ipf.core.connector</groupId>
    <artifactId>connector-core</artifactId>
    <version>${connector.version}</version>
</dependency>

La última versión de la biblioteca de conectores se puede encontrar utilizando este Búsqueda de Nexus.

A menos que proporcione su propia implementación, al menos una biblioteca de transporte debe ser declarada. El esquema de nomenclatura para todos los transportes incluidos en la biblioteca de conectores es connector-[transport], donde [transport] coincide con el esquema de transporte que este conector debe utilizar. Para más detalles sobre connector transport s consulte el Connector Transports documentación.

Aquí tiene un ejemplo de declarar la dependencia para utilizar JMS.

<dependency>
    <groupId>com.iconsolutions.ipf.core</groupId>
    <artifactId>connector-jms</artifactId>
    <version>${connector.version}</version>
</dependency>

Introducción: Conector de Recepción

Los conectores de recepción se utilizan para recibir mensajes, ya sea como respuesta a un mensaje enviado previamente o a una nueva solicitud.

Patrón de Constructor

Los conectores de recepción se instancian utilizando el patrón de constructor. Esto se debe a que los conectores tienen muchos parámetros que configurar y la mayoría son opcionales o tienen valores predeterminados.

Veamos cómo utilizamos el patrón de constructor para instanciar un conector receptor.

Al construir un conector de recepción, lo configuramos para que sea un receptor iniciador o un receptor de respuesta. Un receptor iniciador recibe solicitudes de un sistema externo, mientras que un receptor de respuestas espera que los mensajes sean respuestas a solicitudes realizadas previamente a través de un sending connector.

Iniciando Receptor

El siguiente ejemplo demuestra las propiedades mínimas que deben ser proporcionadas al construir un iniciador.receive connector.

ReceiveConnector<ExampleType> connector = ReceiveConnector
         .<ExampleType>builder("ExampleSystem") (1)
         .withConnectorTransport(transport) (2)
         .withReceiveTransportMessageConverter(converter) (3)
         .withProcessingContextExtractor(processingContextExtractor) (4)
         .withReceiveHandler(receiver) (5)
         .withActorSystem(actorSystem) (6)
         .build();
1 Establece el nombre del conector. El nombre debe representar a qué se está conectando el conector.
2 Proporciona una implementación del ReceivingConnectorTransport interfaz.
3 Proporciona una implementación del ReceiveTransportMessageConverter interfaz. Toma el recibido TransportMessage y lo convierte al tipo objetivo T(ExampleType en este caso).
4 Proporciona una implementación del ProcessingContextExtractor interfaz. Este campo es lo que hace de este un conector de recepción inicial, ya que extrae (o genera) un ProcessingContext desde el mensaje en lugar de obtener uno del servicio de correlación como sería el caso en un conector que recibe respuestas.
5 Una implementación de ReceiveHandler. Aquí es donde iría la lógica de la aplicación para decidir cómo manejar las solicitudes.
6 Establece el sistema de actores utilizado en toda la aplicación.

Receptor de Respuesta

El siguiente ejemplo demuestra cómo construir un conector de recepción de respuesta mínima.

ReceiveConnector<ExampleType> connector = ReceiveConnector
        .<ExampleType>builder("connector-name") (1)
        .withConnectorTransport(transport) (2)
        .withReceiveTransportMessageConverter(converter) (3)
        .withCorrelationIdExtractor(correlationIdExtractor) (4)
        .withCorrelationService(correlationService) (5)
        .withReceiveHandler(receiver) (6)
        .withActorSystem(actorSystem) (7)
        .build();
1 Establezca el nombre del conector. El nombre debe representar a qué se está conectando el conector.
2 Proporciona una implementación del ReceivingConnectorTransport interfaz.
3 Proporciona una implementación de la ReceiveTransportMessageConverter interfaz. Toma el recibido TransportMessage y lo convierte al tipo objetivo,ExampleType en este caso.
4 Proporciona una implementación del CorrelationIdExtractor interfaz. Toma el mensaje recibido y extrae el identificador de correlación para que podamos correlacionarlo con la solicitud original realizada a través de un sending connector.
5 Proporciona una implementación del CorrelationService interfaz. El servicio de correlación toma el identificador de correlación extraído y devuelve el ProcessingContext asociado que se utilizó cuando se envió la solicitud original a través de un sending connector.
6 Una implementación de ReceiveHandler. Aquí es donde iría la lógica de la aplicación para decidir cómo manejar las respuestas.
7 Establece el sistema de actores utilizado en toda la aplicación.

Comience a Recibir Mensajes

El paso final es iniciar el conector llamando a su método de inicio. En este punto, usted debe tener un conector que pueda recibir mensajes a través del transporte configurado.

Para referencia, la configuración predeterminada es.

default-receive-connector {
  manual-start = true
  receiver-parallelism-type = ORDERED_PARTITIONED
  receiver-parallelism-per-partition = 1
  resiliency-settings = ${ipf.connector.default-resiliency-settings}
}

  1. application.conf

example-receive-connector {
  manual-start = false
  throttle-count = 5
  throttle-duration = 10s
}

Los valores que pueden ser configurados a través de las propiedades de configuración se muestran en la siguiente tabla.

Propiedad Descripción Ejemplo

manual-start

Cuando se establece en false, el conector se inicia automáticamente después de su creación; de lo contrario, su método de inicio debe ser invocado manualmente.

verdadero

throttle-count

Si se establece el valor, limita el rendimiento a un número específico de mensajes consumidos por unidad de tiempo. Si está configurado. Si este valor está establecido, también debe establecerse la duración del estrangulador.

10

throttle-duration

Si se establece, se utiliza junto con throttle-count para establecer la tasa máxima para consumir mensajes. Para más detalles, consulte doc.akka.io/japi/akka/2. 6/akka/stream/javadsl/Flow.html#throttle(int,java.time. Duration)

1s

mapping-parallelism

Si se establece, limita el número de concurrentes mapping operaciones ejecutadas sobre los mensajes consumidos.

número de procesadores disponibles

receiver-parallelism-type

Define la forma en que se manejan los mensajes en paralelo.

  • ORDERED - los mensajes se consumen en paralelo en el orden en que se reciben, y se reconocen en el mismo orden

  • ORDERED_PARTITIONED - los mensajes se consumen en paralelo en el orden en que se reciben, y se reconocen en el mismo orden, pero el paralelismo para los mensajes que comparten el UnitOfWorkId está limitado a un grado configurable

  • UNORDERED - los mensajes se consumen en paralelo en el orden en que son recibidos, y se reconocen en su orden de finalización, lo que puede afectar a algunos transportes (por ejemplo,Kafka)

ORDERED_PARTITIONED

receiver-parallelism

Si se establece, limita el número de mensajes mapeados que se permiten procesar de manera concurrente.

número de procesadores disponibles

receiver-parallelism-per-partition

Solo se aplica si receiver-parallelism-type está configurado para ORDERED_PARTITIONED. Si se establece, limita el número de mensajes mapeados por UnitOfWorkId que se permiten procesar de manera concurrente. Debe ser menos que receiver-parallelism.

1

resiliency-settings

Los ajustes de resiliencia que se utilizarán al recibir. Para más detalles, consulte el Resiliencia documentación.