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, esta se puede encontrar 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 una 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 en el mundo real, estas instrucciones de pago provendrían 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 comportamiento de iniciación:
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 recordar 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 del BOM central de la versión.
Tenga en cuenta también que hemos elegido el Kafka implementación aquí como nuestro protocolo.
Si se ejecuta a través del andamiaje, será necesario 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 los 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 la misma lógica central 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 transmitir 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 identificadores. Pero si hubiera un identificador de solicitud de cliente específico o un identificador de unidad de trabajo que usted requiriera que sus mensajes utilizaran, este sería el lugar para configurarlo. Sin embargo, utilizaremos un identificador de unidad de trabajo generado. -
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 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 bandera (o -rf para corto) para solo construir ipf-tutorial-app:
esta vez. Así que podemos usar Maven’s --resume-from bandera (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 sobre dónde se ubicará Kafka. 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 brindarnos 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 la configuración cruda de kafka (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 | Esta es la URL de arranque de Kafka y puede ser diferente para su entorno; esto es lo que se necesita si se ejecuta el 'connectors.dsl' proporcionado. |
| 3 | Aquí reutilizamos nuestra configuración común de kafka para el productor. |
| 4 | Aquí reutilizamos nuestra configuración común de kafka 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. La forma en que lo hace depende del entorno en el que esté siguiendo el tutorial. Asumimos aquí que utilizará el entorno proporcionado por la configuración de docker del tutorial, en cuyo caso necesitamos iniciar el archivo connectors.yml.
Una vez que hayamos hecho eso, estaremos listos para continuar, tal como lo estuvimos con los tutoriales anteriores.
Non-Docker
Kafka
Cuando no se está ejecutando en Docker, usted necesitará 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 entorno específico de kafka.
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.
Probando la Aplicación
Como es habitual, ahora verifiquemos que nuestra solución funcione. Inicie la aplicación como se indicó anteriormente (las instrucciones 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.