HTTP Inicio rápido

Integrándose a un sistema externo a través de HTTP es ligeramente diferente en comparación con JMS or Kafka. Esta guía se aplica a la integración saliente (es decir, donde IPF realiza solicitudes a un sistema externo), para la integración entrante a través de HTTP(es decir, donde IPF recibe solicitudes de otro sistema) por favor consulte HTTP Inicio Rápido del Flujo de Recepción.

Para un ejemplo de uso del HTTP Connector Transport para integrarse con Twitter API, vea Solicitud-Respuesta Encadenada con OAuth.

Al implementar una integración saliente a través de HTTP, en lugar de definir un par de conectores de envío y recepción, un RequestReplySendConnector se requiere en su lugar. Este conector único realiza la solicitud y también maneja la respuesta del sistema externo de manera asíncrona.

Paso 1: Agregue connector-http dependencia

La dependencia que debe agregar a su pom.xml es:

<dependency>
    <groupId>com.iconsolutions.ipf.core.connector</groupId>
    <artifactId>connector-http</artifactId>
</dependency>

Si está importando el Icon BOM, o utilizando el Icon BOM como padre, no es necesario proporcionar una versión separada.

Paso 2: Config

Configuración del conector-en general-está fuertemente impulsado por la configuración. La configuración nos permite especificar:

  • Servidor/puerto HTTP

  • Configuración del proxy

  • Reiniciar configuraciones (en caso de fallo)

Aquí tiene un ejemplo de un bloque de configuración para un HttpConnectorTransportConfiguration que conectaremos a nuestro ConnectorTransport, para el sistema de fraude de un banco ficticio que expone un REST endpoint:

bank.fraud-system { (1)
  http {
    client {
      host = "olaf" (2)
      endpoint-url = "/test" (3)
      proxy-host = "localhost" (4)
      ssl {
        trust-store-location = "target/test-classes/tls/client/trust.p12" (5)
        trust-store-password = "password" (6)
        trust-store-type = "PKCS12" (7)
        key-store-location = "target/test-classes/tls/client/keys.p12" (8)
        key-store-password = "password" (9)
        key-store-type = "PKCS12" (10)
        key-password = "password" (11)
      }
      buffer-size = 1
      concurrency = 1
      status-codes-treated-as-errors = [404, 5xx] (12)
      restart-settings { (13)
        min-backoff = 1s
        max-backoff = 30s
        random-factor = 0. 2
        max-restarts = 200
        max-restarts-within = 12h
      }
      connection-pool { (14)
        max-connections = 5 (15)
      }
    }
  }
}
1 Esto se conoce como la ruta raíz de configuración y se hará referencia en el código. Indica dónde en la aplicación configuración para buscar esto Send Connector Configuraciones de transporte
2 El nombre de host del HTTP servicio
3 La ruta del punto final dentro del servicio
4 Nombre del host del proxy, si se utiliza
5 Una ruta a la ubicación del archivo del truststore
6 Frase de paso para acceder al almacén de claves
7 El tipo de almacén de confianza que debe utilizar. Debe ser uno de PKCS12 o JKS.
8 Una ruta a la ubicación del archivo del almacén de claves
9 Frase de contraseña para acceder al almacén de claves
10 El tipo de almacén de claves a utilizar. Debe ser uno de PKCS12 o JKS.
11 Frase de contraseña para acceder al almacén de claves
12 Códigos de estado que serán tratados como errores. Patrones de códigos de estado estándar en forma de 4xx y 5xx también son compatibles.
13 Bloque de configuración opcional que anulará el flujo predeterminado RestartSettings. Ver:https://doc.akka.io/libraries/akka-core/current//stream/stream-error.html#delayed-restarts-with-a-backoff-operator para más detalles. Tenga en cuenta que esto solo se utiliza en el HttpConnectorTransportConfiguration.
14 Bloque de configuración opcional que anulará Akka la configuración del grupo de conexiones predeterminado de 's
15 Custom valor para el número máximo de conexiones, como ejemplo. La lista detallada de atributos con valores predeterminados y descripción se puede encontrar en #_step_3_transportconfig == Paso 3: Crear HTTP Connector Transport Configuración 
Puede omitir este paso proporcionando configRootPath a la `HttpConnectorTransport. Builder<T>` en lugar de `HttpTransportConfiguration`.

Este ejemplo logra lo mismo que un ejemplo en Step 4:

var connectorTransport = new HttpConnectorTransport. Builder<T>()
                .withActorSystem(actorSystem)
                .withName("exampleHttpConnectorTransport")
                .withConfigRootPath("bank.fraud-system")
                .withTreatErrorResponseAsFailureWhen(httpResponse -> {
                    if(httpResponse.status().intValue() == 505) {
                        return false;
                    }
                    return true;
                })
                .build();

El HTTP Connector Transport La clase de configuración actúa como un contenedor para el HOCON configuración que definimos en Step 2, la aplicación accede a la configuración a través de esta clase.

Aquí está cómo crear un HTTP Connector Transport Clase de configuración para configurar un HTTP Connector Transport:

var connectorTransportConfiguration = HttpConnectorTransportConfiguration.create(actorSystem.classicSystem().settings().config(), (1)
"bank.fraud-system"); (2)
1 Esto recupera la configuración de la aplicación del sistema de actores. El actorSystem puede ser inyectado típicamente como un Spring bean.
2 Esto indica la ruta al archivo de configuración desde el cual la aplicación debe recuperar los valores de configuración. == Paso 4: Crear HTTP Connector Transport

Aquí tiene un ejemplo de cómo un HttpConnectorTransport puede ser creado:

var connectorTransport = new HttpConnectorTransport. Builder<T>() (1)
                .withName("exampleHttpConnectorTransport") (2)
                .withActorSystem(actorSystem)
                .withConfigRootPath("example-transport-configuration") (3)
                .withTreatErrorResponseAsFailureWhen(httpResponse -> { (4)
                    if(httpResponse.status().intValue() == 505) {
                        return false;
                    }
                    return true;
                })
                .build();
1 Reemplace T con el tipo de destino que está enviando
2 Dé el ConnectorTransport un nombre significativo
3 Proporcione una ruta raíz de configuración a su HTTP connector transport configuración (consulte Step 3 por un ejemplo)
4 Puede opcionalmente customize cómo manejar específico HTTP Response codes. Toma un Predicate<HttpResponse>, En el ejemplo, vamos a tratar un código de respuesta 505 como una respuesta de éxito. Esto podría utilizarse en conjunto con Resiliencia configuraciones para customize comportamiento de reintento. Por ejemplo, al no tratar una respuesta como un fallo, puede eludir el manejo de reintentos predeterminado. Esta configuración puede evitarse. si establecemos status-codes-treated-as-errors parámetro en nuestra ruta raíz de configuración. Los estados que establezcamos allí serán tratados como errores, y aquellos que no están en la lista no lo harán.
si establece ambos withTreatErrorResponseAsFailureWhen y utilice el status-codes-treated-as-errors configuración, lo último será ignorado. Si usted está simplemente verificando HTTP códigos de estado para éxito o fracaso, Puede utilizar simplemente la clave de configuración sin necesidad de escribir ningún código.
Si el endpoint al que se está conectando utiliza autenticación Bearer, consulte la guía de autenticación Bearer.aquí

Paso 5: Crear HTTP Receive Connector Transporte

Aquí tiene un ejemplo de cómo un HttpReceiveConnectorTransport puede ser creado:

var configRootPath = "receive-example"; (1)
var config = actorSystem.classicSystem().settings().config().getConfig(configRootPath + ".http.receive");
var connectorTransport =  HttpReceiveConnectorTransport.builder()
        .withName("exampleHttpConnectorTransport") (2)
        .withActorSystem(actorSystem)
        .withHost(config.getString("host"))
        .withPort(config.getString("port"))
        .withSslConfiguration(HttpReceiveTransportConfiguration. SSLConfig.buildSslContextFromConfiguration(config))
        .withResponder(req -> HttpResponse.create().withStatus(202))
        .withConfigRootPath(configRootPath)
        .build();
1 Establecer configRootPath
2 Dé el ConnectorTransport un nombre significativo

Paso 6: Crear HTTP Request Reply Send Connector

Aquí tiene un ejemplo de cómo un RequestReplySendConnector puede ser creado:

var connectorConfigRootPath = "ipf.example-project.transport.connector";
var transportRootPath = "ipf.example-project.transport";
var resiliencySettingsRootPath = connectorConfigRootPath + ".resiliency-settings";

var rrSendConnector = new RequestReplySendConnector. Builder<REQ_D, REQ_T, REP_D, REP_T>(
        "RRSendConnector", connectorConfigRootPath, actorSystem)
        .withConnectorTransport(new HttpConnectorTransport. Builder<REQ_D>("RRSendConnectorTransport", actorSystem, transportRootPath).build())
        .withMessageLogger(messageLogger)
        .withCorrelationIdExtractor(payload -> null)
        .withReceiveTransportMessageConverter(t -> convertToDomain(t.getPayload().toString()))
        .withTargetToDomainTypeConverter(payload -> payload)
        .withSendTransportMessageConverter(settingsApiGetAllTransportMessageConvertor)
        .build();

Paso 7: Enviar Mensajes

Habiendo creado un send connector en este caso, ahora puede ser utilizado para enviar mensajes al punto final objetivo, de la siguiente manera:

rrSendConnector.send(PROCESSING_CONTEXT, message) (1)
        .handle((response, e) -> { (2)
            if (response!= null) {
                return.. // successful case
            }

            if (ExceptionUtils.getRootCause(e) instanceof HttpStatusErrorException se) { (3)
                var transportMessage = se.getResponseMessage(); (4)
                var errorPayload = transportMessage.getPayload().toString();
                var mappedResponse =.. (5)
                return mappedResponse;
            } else {
                .. (6)
            }
        });
1 Enviando mensajes utilizando HTTP y un Request Reply Send Connector comienza igual que con el asincrónico send connector s que utilizan JMS or Kafka.
2 A diferencia de JMS or Kafka, donde los mensajes que indican errores comerciales se envían a una cola/tópico de respuesta preasignada, aquí los errores comerciales se devolverán instantáneamente a través del HTTP respuesta. HTTP las respuestas que contengan códigos de estado que se consideran errores resultarán en failed CompletableFutures siendo devuelto por el conector de Solicitud Respuesta. Aquí estamos accediendo al error que causó la falla del futuro a través de un handle método pero exceptionally,whenComplete o cualquiera de sus alternativas también funcionaría.
3 Las excepciones que fallan en los futuros tendrán como causa raíz una instancia de HttpStatusErrorException. <4>`HttpStatusErrorException` lleva dentro de sí un TransportMessage representando la respuesta de error recibida. <5>`TransportMessage` solo lleva la carga útil de respuesta en bruto, que es de String or byte[] tipo. Eso es por lo que un mapping Este paso casi siempre será necesario en sus controladores de excepciones.
4 Su futuro puede fracasar con un no-HttpStatusErrorException y estos deben ser manejados de alguna manera también.