Documentation for a newer release is available. View Latest

Inicio rápido del Receiving Connector

Esta página proporciona detalles sobre cómo comenzar a recibir mensajes de sistemas externos mediante receiving connectors proporcionados por la biblioteca de connector.

Dependencias

Antes de construir un receiving connector, la biblioteca connector-core debe incluirse como 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 del connector puede encontrarse usando esta búsqueda en Nexus.

A menos que proporcione su propia implementación, al menos una biblioteca de transport debe declararse. El esquema de nombres para todos los transports incluidos en la biblioteca del connector es connector-[transport], donde [transport] coincide con el esquema de transport que este connector debe usar. Para más detalles sobre connector transports consulte la documentación de Connector Transports.

Aquí hay un ejemplo de declaración de dependencia para usar JMS.

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

Primeros pasos: Receiving Connector

Los receiving connectors se utilizan para recibir mensajes, ya sea como respuesta a un mensaje enviado previamente o como una nueva solicitud.

Patrón Builder

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

Veamos cómo usamos el patrón builder para instanciar un receiving connector.

Al construir un receiving connector lo configuramos para que sea un initiating receiver o un response receiver. Un initiating receiver recibe solicitudes de un sistema externo, mientras que un response receiver espera que los mensajes sean respuestas a solicitudes hechas previamente mediante un sending connector.

Initiating Receiver

El siguiente ejemplo muestra las propiedades mínimas que deben proporcionarse al construir un initiating 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 connector. El nombre debe representar con qué se conecta el connector.
2 Proporciona una implementación de la interfaz ReceivingConnectorTransport.
3 Proporciona una implementación de la interfaz ReceiveTransportMessageConverter. Toma el TransportMessage recibido y lo convierte al tipo objetivo T (ExampleType en este caso).
4 Proporciona una implementación de la interfaz ProcessingContextExtractor. Este campo es lo que hace que esto sea un initiating receiving connector ya que extrae (o genera) un ProcessingContext del mensaje en lugar de obtener uno del correlation service como sería el caso en un response receiving connector.
5 Una implementación de ReceiveHandler. Aquí iría la lógica de la aplicación para decidir cómo manejar las solicitudes.
6 Establece el actor system utilizado en toda la aplicación.

Response Receiver

El siguiente ejemplo muestra cómo construir un response receiving connector mínimo.

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 connector. El nombre debe representar con qué se conecta el connector.
2 Proporciona una implementación de la interfaz ReceivingConnectorTransport.
3 Proporciona una implementación de la interfaz ReceiveTransportMessageConverter. Toma el TransportMessage recibido y lo convierte al tipo objetivo, ExampleType en este caso.
4 Proporciona una implementación de la interfaz CorrelationIdExtractor. Toma el mensaje recibido y extrae el identificador de correlación para que podamos correlacionarlo con la solicitud original realizada mediante un sending connector.
5 Proporciona una implementación de la interfaz CorrelationService. El correlation service toma el identificador de correlación extraído y devuelve el ProcessingContext asociado utilizado cuando la solicitud original se envió mediante un sending connector.
6 Una implementación de ReceiveHandler. Aquí iría la lógica de la aplicación para decidir cómo manejar las respuestas.
7 Establece el actor system utilizado en toda la aplicación.

Comenzar a recibir mensajes

El paso final es iniciar el connector llamando a su método start. En este punto debería tener un connector que puede recibir mensajes mediante el transport configurado.

Como 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}
}
application.conf
example-receive-connector {
  manual-start = false
  throttle-count = 5
  throttle-duration = 10s
}

Los valores que pueden configurarse mediante propiedades de configuración se muestran en la siguiente tabla.

Property Description Example

manual-start

Cuando se establece en false, el connector se inicia automáticamente después de su creación; de lo contrario, su método start debe invocarse manualmente.

true

throttle-count

Si se establece el valor, limita el throughput a un número especificado de mensajes consumidos por unidad de tiempo. Si se establece. Si este valor se establece, también es necesario establecer throttle-duration.

10

throttle-duration

Si se establece, se usa junto con throttle-count para fijar la velocidad máxima de consumo de mensajes. Para más detalles, vea 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 operaciones de mapping concurrentes ejecutadas sobre los mensajes consumidos.

número de procesadores disponibles

receiver-parallelism-type

Define la manera en que los mensajes se manejan 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 mensajes que comparten el UnitOfWorkId se limita a un grado configurable

  • UNORDERED - los mensajes se consumen en paralelo en el orden en que se reciben, y se reconocen en su orden de finalización, lo cual puede impactar algunos transports (por ejemplo, Kafka)

ORDERED_PARTITIONED

receiver-parallelism

Si se establece, limita el número de mensajes mapeados que pueden procesarse concurrentemente.

número de procesadores disponibles

receiver-parallelism-per-partition

Solo se aplica si receiver-parallelism-type está establecido en ORDERED_PARTITIONED. Si se establece, limita el número de mensajes mapeados por UnitOfWorkId que pueden procesarse concurrentemente. Debe ser menor que receiver-parallelism.

1

resiliency-settings

La configuración de resiliencia que se utilizará al recibir. Para más detalles, consulte la documentación de Resilience.