DSL 5 - Usando un Decision
Si en algún momento desea ver la solución a este paso, puede encontrarla en el |
¿Qué es un Decision?
Hasta ahora hemos añadido una función de dominio (llamada interna) y un dominio externo (llamada externa). Ahora es momento de considerar algunas de las opciones de procesamiento disponibles para determinar cómo procesar nuestros pagos.
En esta sección del tutorial, necesitamos decidir cuándo realizar la verificación de fraude que usted debería haber implementado como parte del ejercicio en el tutorial anterior (incorpore la implementación de la verificación de fraude desde add_external_domain aquí si no completó este ejercicio). Los criterios que determinan si realizamos la verificación de fraude son los siguientes:
-
Si el valor del pago es ⇐ 10, entonces omitimos la verificación de fraude.
-
Si el valor del pago es > 10, entonces ejecutamos la verificación de fraude.
Podemos usar " decisions " para modelar este comportamiento.
A "" decision"en el DSL es muy simple, es una función que recibe algunos datos y devuelve un tipo especial de resultado llamado "resultado". A diferencia de una función de dominio donde el resultado puede ser complejo business data, un resultado solo puede ser una cadena simple, por ejemplo,SKIP or CHECK. Esta simplicidad de un decision nos proporciona varios beneficios:
-
A decision no requiere definición de respuestas
-
A decision no requiere definición del comportamiento de entrada
-
A decision no requiere events por definir.
Configuración de DSL
Añadiendo un Decision
Comencemos por añadir un nuevo decision biblioteca a nuestro modelo. Así que, como se mencionó anteriormente, haga clic derecho en el modelo y seleccione .
Esto debería mostrar el nuevo decision página de la biblioteca:
Esta vez simplemente dejaremos nuestra biblioteca con el nombre predeterminado " Decision "Biblioteca". Podría proporcionar un nombre diferente aquí y tener muchas bibliotecas diferentes si lo necesitara.
Así que procedamos a agregar nuestra lógica para nuestro decision. En primer lugar, añadiremos los campos como lo hemos hecho muchas veces en pasos anteriores:
-
Para el nombre, utilizaremos "Ejecutar Verificación de Fraude".
-
Para la descripción, utilizaremos "El valor del pago de cheques requiere una verificación de fraude".
-
Para business data, utilizaremos " Customer Credit Transfer "
El siguiente campo que tenemos es "Resultados", que es un concepto nuevo.
Un "Resultado" es simplemente un posible resultado de la decision. A decision puede tener tantos resultados diferentes como desee-estos son muy similares a los " Response Codes "que utilizamos anteriormente."
El campo de resultado es un texto libre simple que nos permite ingresar un nombre, así que especifiquemos dos resultados:
-
FRAUD_REQUIRED
-
SKIP_FRAUD
Para ingresar nuevos resultados, simplemente presione la tecla de retorno después de completar el anterior.
Una vez completado, nuestro decision debería verse así:
Eso es nuestro decision definido y listo para usar, por lo que el siguiente paso es integrarlo al flujo.
Usando un Decision
A decision se maneja de manera ligeramente diferente a la función de dominio o las llamadas de dominio externo que hemos utilizado hasta la fecha. En esos ejemplos, utilizamos pasos concretos específicos para representar el hecho de que el sistema estaba realizando esas funciones. En el caso de un decision sin embargo, es solo una posición de enrutamiento en el flujo y, como tal, ahora introducimos el concepto de un pseudo state. Estos se utilizarán en diferentes casos más adelante en el tutorial, pero por ahora solo utilizaremos el que necesitamos para decisions el cual nos referiremos como un decision state.
Como se mencionó en la introducción, el decision es muy ligero, por lo que no es necesario añadir events or input behaviours aquí. Podemos saltar directamente a la Event Procesamiento de comportamiento.
Una vez que hayamos recibido la Validación de Cuenta Aprobada event, debemos realizar la verificación de fraude decision. Si requiere una verificación de fraude, ejecutaremos la verificación de fraude como antes; de lo contrario, simplemente completaremos nuestro pago.
Comencemos editando nuestro manejo de la "Validación de Cuenta Aprobada".event, antes teníamos:
Ahora, en lugar de pasar a la "Verificación de Fraude" state pasaremos a la "Ejecutar Verificación de Fraude" decision state y ejecute nuestro decision. Para esto, en lugar de seleccionar un concreto state como "Verificación de Fraude" en el "Mover a" State " sección elegimos "Crear Decision State.
Aquí podemos ingresar el nombre del state como "Ejecutar Verificación de Fraude" (teniendo en cuenta que este no tiene que ser el mismo nombre que el decision tenemos la intención de utilizar. Es una buena regla general hacerlo, pero al permitir cualquier nomenclatura aquí, podemos reutilizar el mismo decision en múltiples casos de uso diferentes a lo largo de nuestro flujo).
Luego, en la acción de realizar, elegimos "Enrutamiento". Decision "y luego simplemente elegimos la opción 'Ejecutar Verificación de Fraude'" decision(que creamos en nuestro " Decision Biblioteca".
Una vez completado, deberíamos lucir así:
Ahora manejemos el resultado de nuestra verificación de fraude. Para ello, debemos añadir Event Behaviours para completar el flujo (si se omite la verificación) o realizar la verificación de fraude (si se requiere la verificación).
Así que comencemos añadiendo el caso de omisión. Usted añadirá un nuevo event comportamiento y luego especifique:
-
el "Con Actual State "para ser nuestro "Ejecutar Verificación de Fraude"" decision state.
-
el "Cuándo" debe estar "Activado"
Para el event, utilizamos un tipo especial de event-the "" Decision Resultado Event"así que seleccionamos"*Decision "Resultado" y luego elija nuestro resultado "SKIP_FRAUD". Luego, para completar nuestro comportamiento, simplemente movemos a "Completar". Una vez finalizado, debería verse así:
A continuación, necesitamos realizar el comportamiento cuando el decision dice que necesitamos realizar la verificación de fraude. En ese caso, simplemente queremos pasar a la "Verificación de Fraude".state y ejecute la solicitud "Verificación de Fraude". Intente agregar esto, o si lo prefiere, la solución se encuentra a continuación:
Eso es todo, ahora hemos integrado nuestro decision en nuestro flujo. Abramoslo en el Visor de Flujos (Herramientas > "Abrir Visor de Flujos") y veamos cómo se ve:
Consejo Principal A medida que nuestros gráficos se vuelven más complicados, hay algunas cosas útiles de las que debe estar al tanto. La primera opción que tenemos en la parte superior es "Mostrar Acciones"; por defecto, esta opción está activada, pero desmarcarla cambiará la vista para mostrar únicamente state transiciones que pueden ser más fáciles de ver. La segunda es que tenemos la capacidad de manipular la vista del diagrama:
Nota: Si desea restablecer la vista predeterminada, deberá minimizar/cerrar el visor flo y volver a abrirlo. |
Java Implementación
El Decision Interfaz
Cambiemos a Intellij para trabajar con el java lado.
Primero necesitamos regenerar el código de la aplicación para recoger los cambios que hemos realizado en nuestra edición de DSL. Usted hará esto ejecutando lo siguiente desde la raíz de nuestro proyecto (ipf-tutorial):
mvn clean installEsto debería tomar un minuto aproximadamente, ya que se generan todo el código y las dependencias. Una vez que esté completo, navegue al directorio objetivo del proyecto domain-root/domain y deberíamos encontrar un nuevo Decision Interfaz en el decisions paquete (& emun para resultados generados):
package com.iconsolutions.ipf.tutorial.ipftutorialmodel.decisions;
public interface DecisionLibraryPort {
RunFraudCheckDecisionOutcomes performRunFraudCheck(RunFraudCheckDecisionParameters decision);
}Al igual que con otros puertos que hemos considerado anteriormente, la verificación toma un conjunto de parámetros.- en nuestro caso, este es un soporte para solo el customer credit transfer, pero podemos estar enviando múltiples artículos a business data a un decision. Devolverá un nuevo elemento de enumeración (RunFraudCheckDecisionOutcomes) que ha sido generado para cada uno de los resultados que definimos.
De acuerdo con nuestros requisitos, si el valor del pago es <10 debemos omitir la verificación de fraude y si > 10 debemos realizar la verificación de fraude. Intente implementar esta lógica y conectarla al dominio. Una vez listo, puede ver la solución a continuación:
@Bean
public IpftutorialmodelDomain init(ActorSystem actorSystem) {
// All adapters should be added to the domain model
return new IpftutorialmodelDomain. Builder(actorSystem)
.withDomainFunctionAdapter(input -> CompletableFuture.completedStage(new DuplicateCheckResponseInput. Builder(input.getId(), AcceptOrRejectCodes. Accepted).build()))
.withAccountingSystemActionAdapter(new SampleAccountingSystemActionAdapter())
.withFraudSystemActionAdapter(new SampleFraudSystemActionAdapter())
.withDecisionLibraryAdapter(input ->
input.getCustomerCreditTransfer().getCdtTrfTxInf().get(0).getIntrBkSttlmAmt().getValue().compareTo(BigDecimal. TEN)>0?
RunFraudCheckDecisionOutcomes. FRAUDREQUIRED: RunFraudCheckDecisionOutcomes. SKIPFRAUD)
.build();
}Eso es todo, nuestra implementación está ahora completa.
Verificando nuestra Solución
Verifiquemos que los cambios en nuestra aplicación funcionen, como de costumbre, iniciaremos la aplicación como anteriormente (instructions están disponibles en Revisando la solicitud inicial si necesita un repaso!)
Fraude Requerido
Ahora podemos utilizar nuestra capacidad para enviar diferentes valores de pago utilizando los valores en la solicitud de inicio (consulte para refrescar la memoria).
curl -X POST localhost:8080/submit -H 'Content-Type: application/json' -d '{"value": "150"}' | jqEsto enviará un valor de pago de 150 USD. Por lo tanto, recordando nuestra implementación, en este caso se debe requerir una verificación de fraude. Vamos a presentar el pago en el Developer GUI y mencione el domain events tab (buscar por unit of work id, haga clic en ver, haga clic domain events)
Así que ahora estamos recibiendo el nuevo event para "Ejecutar Verificación de Fraude FRAUD_REQUIRED" seguida de la ejecución de la verificación de fraude, y podemos ver que nuestro código está funcionando como esperaríamos.
Para su interés, también puede observar el gráfico aquí (utilizando el botón "Flujos").
Aquí podemos ver el camino que se está tomando, incluyendo el decision en sí mismo (representado como un diamante).
Fraude Omitido
Ahora intentemos nuestro caso inverso enviando un pago con un valor < 10 USD y luego observemos el events para nuestro pago devuelto (recuerde reemplazar el id agregado con el suyo):
curl -X POST localhost:8080/submit -H 'Content-Type: application/json' -d '{"value": "5"}' | jqEsta vez, esperaríamos ver el decision ejecute y decida que podemos omitir el fraude y permitir que el flujo se complete de inmediato.
Hablemos del pago en el Developer GUI y mencione el domain events tab (buscar por unit of work id, haga clic en ver, haga clic domain events)
¡Y encontramos exactamente lo que esperábamos! Por lo tanto, hemos demostrado que ahora estamos invocando nuestro decision y hemos superado con éxito nuestro control de fraude.
Conclusiones
En esta sección, hemos:
-
Añadido un decision
-
se proporcionó una implementación predeterminada que verifica el valor del pago
-
usó nuestro decision para impulsar el enrutamiento de flujo
-
verificó nuestro decision está funcionando y siendo llamado
Ahora, habiendo configurado nuestra aplicación para realizar decisions sobre cómo procesar el pago, analicemos otra capacidad:xref:add_mapping_function.adoc[]