CON1 - Añadiendo la Iniciación de Pagos
|
Iniciando
El paso del tutorial utiliza el Si en algún momento desea ver la solución a este paso, puede encontrarla en el |
En el tutorial de DSL, construimos una aplicación que utiliza el Icon Payment DSL para establecer un flujo. Para iniciar este flujo, nuestra aplicación de muestra tenía un simple REST controlador que nos permitió iniciar el flujo. Pudimos enviar en ciertos valores clave-como la cantidad-para ayudarnos a probar diversas condiciones dentro de nuestro flujo. Sin embargo, en el mundo real, estos pagos instructions provendría de una fuente externa a través de algún tipo de intermediario de mensajes.
En esta sección, vamos a utilizar un módulo de prueba existente.- el "Iniciador de Pago de Muestra" como la fuente externa. Esta es una aplicación simple que podemos utilizar para probar nuestra aplicación. Tiene algunas propiedades clave:
-
Proporciona un simulador simple que nos permite generar pain001’s, ofreciendo una interfaz para establecer algunos de los valores clave.
-
La aplicación puede ser utilizada con diferentes tipos de intermediarios de mensajes (Kafka,JMS)
-
La aplicación viene con un conjunto de paquetes predefinidos.Conector s. Estos son los clientes componentes-construido utilizando el marco de trabajo Icon Connector-que permiten una integración rápida y sencilla entre la aplicación principal de IPF y el simulador de iniciación de pagos.
En este tutorial, vamos a utilizar el Kafka versión del simulador de pagos.
Comencemos y configuremos todo para que podamos empezar a enviar mensajes a nuestro IPF application desde el Simulador de Iniciación de Pagos.
Un resumen rápido
Hagamos un breve resumen sobre el flujo existente, el clave aquí es el flujo de iniciación y su initiation behaviour:
Lo clave a tener en cuenta aquí es que estamos enviando una iniciación de pago (pain001) para iniciar el flujo. No nos preocuparemos acerca del objeto de datos de ejemplo aquí, ya que se utilizó simplemente como una forma de ilustrar custom tipos.
Puede que recuerde que-cuando se genera-esto creará un nuevo método en el controlador de iniciación del dominio que
nos permite realizar solicitudes de inicio de flujo. En el flujo actual, hacemos esto dentro del controlador del principal
ipf-tutorial-app`aplicación. 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 utilizando la muestra pain001 que generamos como nuestros datos de iniciación de pago cuando construimos el entrada de iniciación. Usted hará algo muy similar al configurar el simulador de iniciación de pagos.
Añadiendo el Conector
Primero necesitamos agregar la dependencia para comunicarnos con el simulador de iniciación de muestra que utilizaremos para recibir el pago.
mensajes de iniciación. Agregue esto al ipf-tutorial-app’s `pom.xml:
<dependency>
<groupId>com.iconsolutions.ipf.sample.samplesystems</groupId>
<artifactId>payment-initiation-connector-kafka</artifactId>
</dependency>No es necesario especificar una versión aquí porque se hereda de la versión de lanzamiento.core BOM.
Tenga en cuenta también que hemos elegido el Kafka implementación aquí como nuestro protocolo.
Si se ejecuta a través del scaffolder, necesitaremos declarar la última versión (2. 4. 0) o agregar el sample-systems-bom a nuestro padre para heredarlo. |
El Adaptador de Cliente
Cuando se ejecute el simulador de iniciación de pagos, enviará mensajes a los relevantes Kafka tema. Vamos a utilizar el
conector de íconos preempaquetado en nuestra aplicación, que consumirá mensajes de iniciación de ese tema y procesará
mensajes. Para ser notificado de los mensajes de inicio de pago que lleguen, el conector proporciona una interfaz-the PaymentInitiationClientAdapter - que necesitaremos implementar en ipf-tutorial-app. Nuestra implementación será
necesita proporcionar lo mismo core lógica que la iniciación actual REST el controlador hace, es decir, toma el pain001 y comienza
un flujo con ello.
Comencemos por examinar la definición de esta interfaz:
public interface PaymentInitiationClientAdapter {
ProcessingContext determineContextFor(PaymentInitiationRequest request);
CompletionStage<Void> handle(ReceivingContext context, PaymentInitiationRequest request);
}Hay dos métodos que proporciona:
-
determineContextFor- Esta es la oportunidad de proporcionar un anticipoProcessingContext, por ejemplo elunitOfWorkIdque representa una referencia de IPF utilizada para rastrear toda la actividad en contra. -
handle- Aquí es donde gestionamos los mensajes entrantes, y para nosotros necesitamos pasar el mensaje al flujo.
Consideremos lo que queremos hacer en nuestra implementación específica.
-
determineContextFor- en nuestro caso no estamos demasiado preocupados por los id’s. Pero si hubiera un id de solicitud específico del cliente o unit of work id que usted requiere que sus mensajes utilicen, este sería el lugar para configurarlo. Sin embargo, utilizaremos un generado unit of work id. -
handle- aquí es donde necesitamos extraer el pain001 del objeto de solicitud y pasarlo a los métodos de iniciación del dominio.
Vea si puede averiguar cómo implementar estos dos métodos usted mismo. Alternativamente, la solución
(to add to the ipf-tutorial-app) está abajo:
@Slf4j
@Service
public class SamplePaymentInitiationAdapter implements PaymentInitiationClientAdapter {
@Override
public ProcessingContext determineContextFor(PaymentInitiationRequest paymentInitiationRequest) {
return ProcessingContext.builder().unitOfWorkId(UUID.randomUUID().toString()).build();
}
@Override
public CompletionStage<Void> handle(ReceivingContext receivingContext, PaymentInitiationRequest paymentInitiationRequest) {
return IpftutorialmodelDomain.initiation().handle(
new InitiateInitiationFlowInput. Builder(UUID.randomUUID().toString())
.withProcessingContext(receivingContext.getProcessingContext())
.withPaymentInitiation(paymentInitiationRequest.getPayload().getContent())
.build())
.thenAccept(done -> log.debug("Completed request"));
}
}Tenga en cuenta aquí que utilizamos Spring’s @Service anotación para conectar la dependencia.
Eso es todo nuestro código terminado, así que construyamos la aplicación.
Tenga en cuenta que solo hemos cambiado el código de implementación y no nuestro flujo, por lo que no es necesario reconstruir el. MPS componentes en
esta vez. Así que podemos usar Maven’s --resume-from flag(o -rf para corto) para solo construir ipf-tutorial-app:
esta vez. Así que podemos usar Maven’s --resume-from flag(o -rf para corto) para solo construir ipf-tutorial-app:
mvn clean install -rf:ipf-tutorial-appConfigurando la Aplicación
Ahora es el momento de configurar la configuración. Necesitaremos la configuración para que nuestro conector de iniciación de pagos se comunique con kafka.
Configuración
La configuración estándar-como el tema del cual consumiremos mensajes de iniciación de pago-se proporciona listo para usar. Va a leer mensajes de la PAYMENT_INITIATION_REQUEST tema. Así que todo lo que necesitamos es indicarle cómo conectarse a Kafka.
Sin embargo, necesitamos proporcionar los detalles de dónde kafka se ubicará. Todos los conectores IPF utilizarán por defecto una raíz de configuración de akka. Esto significa que si tenemos múltiples servicios que utilizan el mismo kafka Podemos definir la configuración una vez y permitir que todos nuestros servicios la utilicen. Vamos a asumir para este tutorial que ese es el caso, por lo que configuraremos nuestro servicio de esa manera. Ahora realizará algunos ajustes para proporcionarnos funcionalidad adicional.
// default settings for kafka
common-kafka-client-settings { (1)
bootstrap.servers = "localhost:9093" (2)
}
akka.kafka {
producer {
kafka-clients = ${common-kafka-client-settings} (3)
}
consumer {
kafka-clients = ${common-kafka-client-settings} (4)
}
}
// end default kafka settingsRevisemos algunos aspectos de esto:
| 1 | Extraemos nuestra materia prima kafka configuraciones (id de grupo, servidores bootstrap) en una sección separada. Esto significa que podemos reutilizar esto en diferentes conjuntos de propiedades. Puede ver eso en los puntos 3 y 4. |
| 2 | Esto es el kafka La URL de bootstrap puede ser diferente para su entorno; esto es lo que se necesita si se ejecuta el 'connectors.dsl' proporcionado. |
| 3 | Aquí reutilizamos nuestro común kafka configuración para el productor. |
| 4 | Aquí reutilizamos nuestro común kafka ajustes para el consumidor. |
Tenga en cuenta que puede proporcionar cualquier estándar Kafka configuraciones de consumidor or configuraciones del productor junto a bootstrap.servers. Esto
la sección de la configuración simplemente tratará cualquier clave de configuración que usted especifique como Kafka propiedades.
Ejecutando la Aplicación
Finalmente, está listo para ejecutar la aplicación. Cómo lo haga depende del entorno en el que esté siguiendo el tutorial. Asumimos aquí que utilizará el entorno proporcionado por el tutorial.docker configuración en la que necesitamos iniciar el archivo connectors.yml.
Una vez que hayamos hecho eso, estamos listos para continuar, tal como lo estábamos con los tutoriales anteriores.
Non-Docker
Kafka
Cuando no se está ejecutando en Docker, deberá utilizar su propio Kafka broker. Esto debe tener dos temas disponibles:
-
PAYMENT_INITIATION_RESPONSE -
PAYMENT_INITIATION_REQUEST
A continuación, necesitamos indicarle a la aplicación tutorial de IPF cómo conectarse a Kafka. Luego deberá actualizar el `bootstrap.servers`config que configuramos en la sección anterior para alcanzar su específico kafka entorno.
Simulador de Iniciación de Pagos
Los detalles sobre cómo ejecutar el simulador de iniciación de pagos se pueden encontrar aquí:Uso del simulador de iniciación de pagos.
Pruebas de la Aplicación
Como es habitual, ahora verifiquemos que nuestra solución funciona. Inicie la aplicación como se indicó anteriormente (instructions están disponibles en Revisando la solicitud inicial si necesita un repaso)
Ahora el Simulador de Iniciación de Pagos estará disponible (junto con el Zookeeper y Kafka setup).
Puede acceder al simulador en localhost:8083/index.html
Cuando se cargue, debería verse así:
Hay un par de funciones clave a tener en cuenta aquí. Usted puede:
-
Establezca la tasa de carga-esto nos permite enviar una tasa consistente de transacciones, por ejemplo, 10TPS, a nuestra aplicación.
-
Inicie el pago único-esto nos permite enviar un único pago con los valores proporcionados.
No utilizará "Ver Actividad Actual" por ahora, pero permite que el simulador rastree las respuestas a los pagos, su latencia, tasas de error, etc.
Comenzará llamando a un pago individual. Haga clic en el botón de iniciar pago único y luego deje todo como predeterminado y haga clic en iniciar pago. Esto generará un pago. Aparecerá un cuadro emergente que continuará girando, esto se debe a que el simulador, por defecto, espera que haya una respuesta a su mensaje. Por ahora, no tenemos esto, por lo que el giro es el comportamiento esperado.
Vamos a abrir la aplicación IPF Developer en localhost:8081/explorer.html y ejecute una búsqueda. Debe ver un nuevo registro creado hace unos segundos:
Veamos este registro y luego vayamos a la "pestaña de mensajes":
Aquí puede ver que IPF ha "recibido" un PaymentInitiationRequest. Puede ver el cuerpo del mensaje si lo desea.
Siéntase libre en esta etapa de intentar enviar algunos mensajes diferentes con distintos valores, o de enviar una carga fija.