CON1 - Añadir iniciación de pagos
|
Comenzando
Este paso del tutorial utiliza como punto de partida la solución Si en cualquier momento quieres ver la solución de este paso, la encontrarás en la solución |
En el tutorial del DSL construimos una aplicación que usa el DSL de Pagos de Icon para crear un flujo. Para iniciar este flujo, nuestra aplicación de ejemplo tenía un sencillo controlador REST que nos permitía iniciar el flujo. Podíamos enviar algunos valores clave —como el importe— para ayudarnos a probar distintas condiciones dentro del flujo. Sin embargo, en el mundo real, estas instrucciones de pago vendrían de una fuente externa a través de algún tipo de broker de mensajes.
En esta sección vamos a usar un módulo de pruebas existente —el "Sample Payment Initiator"— como fuente externa. Es una aplicación sencilla que podemos usar para probar nuestra aplicación. Tiene algunas propiedades clave:
-
Proporciona un simulador sencillo que permite generar pain001, ofreciendo una interfaz para ajustar algunos valores clave.
-
La aplicación puede usarse con diferentes tipos de broker de mensajes (Kafka, JMS).
-
La aplicación viene con un conjunto de Conectores preempaquetados. Son los componentes cliente —construidos con el framework de Conectores de Icon— que permiten una integración rápida entre la app IPF principal y el simulador de iniciación de pagos.
En este tutorial usaremos la versión Kafka del simulador de pagos.
Pongámonos en marcha y configuremos todo para poder empezar a enviar mensajes a nuestra aplicación IPF desde el Payment Initiation Simulator.
Un repaso rápido
Repasemos el flujo existente; el clave aquí es el flujo de iniciación y su initiation behaviour:
Lo principal a notar es que enviamos una iniciación de pago (pain001) para iniciar el flujo. No nos preocuparemos por el objeto example data aquí, ya que solo se usó para ilustrar tipos personalizados.
Quizá recuerdes que —cuando se genera— esto crea un nuevo método en el controlador de iniciación del dominio que
nos permite realizar peticiones de iniciación de flujo. En el flujo actual lo hacemos dentro del controlador de la
aplicación principal ipf-tutorial-app. Recordemos ese código (tomado de InitiationController):
Mono.fromCompletionStage(IpftutorialmodelDomain.initiation().handle(new InitiateInitiationFlowInput.Builder(entityId)
.withProcessingContext(ProcessingContext.builder()
.unitOfWorkId(unitOfWorkId)
.clientRequestId(clientRequestId)
.build())
.withPaymentInitiation(samplePain001)
.withExampleData(IpfTutorialBean.builder().intField(7).stringField("Test").build())
.build()).thenApply(done -> InitiationResponse.builder().requestId(clientRequestId).uowId(unitOfWorkId).aggregateId(done.getAggregateId()).build()));El punto clave es que estamos usando el pain001 de ejemplo que generamos como datos de iniciación de pago al construir la entrada de iniciación. Harás algo muy similar al configurar el uso del simulador de iniciación de pagos.
Añadir el conector
Primero tenemos que añadir la dependencia para hablar con el simulador de iniciación que usaremos para recibir mensajes de iniciación.
Añade esto al pom.xml de ipf-tutorial-app:
<dependency>
<groupId>com.iconsolutions.ipf.sample.samplesystems</groupId>
<artifactId>payment-initiation-connector-kafka</artifactId>
</dependency>No necesitamos especificar la versión aquí porque se hereda del BOM de la release core.
Observa también que hemos escogido la implementación Kafka como protocolo.
|
Si trabajas con el scaffolder, tendrás que declarar la versión más reciente (2.4.0) o añadir el sample-systems-bom a tu parent para heredarla. |
El adaptador cliente
Cuando se ejecuta el simulador de iniciación de pagos, enviará mensajes al topic Kafka correspondiente. Vamos a usar el
Conector de Icon preempaquetado en nuestra aplicación, que consumirá mensajes de iniciación de ese topic y procesará
los mensajes. Para ser notificados de los mensajes de iniciación que llegan, el conector proporciona una interfaz —
PaymentInitiationClientAdapter— que tendremos que implementar en ipf-tutorial-app. Nuestra implementación deberá
proporcionar la misma lógica central que el actual controlador REST de iniciación: tomar el pain001 e iniciar
un flujo con él.
Veamos la definición de esta interfaz:
public interface PaymentInitiationClientAdapter {
ProcessingContext determineContextFor(PaymentInitiationRequest request);
CompletionStage<Void> handle(ReceivingContext context, PaymentInitiationRequest request);
}Proporciona dos métodos:
-
determineContextFor: es la oportunidad de proporcionar unProcessingContextinicial, por ejemplo elunitOfWorkIdque representa una referencia IPF usada para seguir toda la actividad asociada. -
handle: aquí gestionamos los mensajes entrantes; en nuestro caso, debemos pasar el mensaje al flujo.
Pensemos qué queremos hacer en nuestra implementación específica.
-
determineContextFor: en nuestro caso no nos preocuparemos demasiado por los id. Si hubiese un client request id o un unit of work id específico que tus mensajes deban usar, aquí es donde configurarlo. Nosotros usaremos un unit of work id generado. -
handle: aquí es donde debemos extraer el pain001 del objeto de petición y pasarlo a los métodos de iniciación del dominio.
Configuración del conector
Además de implementar el PaymentInitiationClientAdapter, debemos proporcionar la configuración para que el conector Kafka
sepa de qué topics leer y, si aplica, a qué topics escribir. Esto se hace en resources/application.conf, por ejemplo:
payment-initiation {
transport = kafka
kafka {
consumer {
topic = PAYMENT_INITIATION_REQUEST
}
producer {
topic = PAYMENT_INITIATION_RESPONSE
}
}
}Asegúrate de que los topics existan en tu entorno Kafka (o que la creación automática esté activada) y de que la aplicación esté conectada a tu clúster.
Arranque y prueba
-
Arranca el entorno docker del tutorial (incluyendo Kafka y el simulador de iniciación de pagos), o apunta la configuración a tu entorno existente.
-
Inicia
ipf-tutorial-app. -
Desde el simulador de iniciación, genera un pain001 con el valor que desees para probar rutas del flujo.
-
Verifica en la Developer App que se han recibido los eventos y que el flujo de iniciación ha comenzado, así como los mensajes asociados (initiation request/response si aplica).