DSL 5 - Usando un Decision
|
Iniciando
El paso del tutorial utiliza el 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 el 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 debe 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 utilizar "decisiones" para modelar este comportamiento.
Una "decisión" 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 datos empresariales complejos, un resultado solo puede ser una cadena simple, por ejemplo.SKIP or CHECK. Esta simplicidad en una decisión nos proporciona varios beneficios:
-
Una decisión no requiere la definición de respuestas.
-
Una decisión no requiere la definición del comportamiento de entrada.
-
Una decisión no requiere que se definan eventos.
Configuración de DSL
Añadiendo un Decision
Comencemos añadiendo una nueva biblioteca de decisiones a nuestro modelo. Así que, como anteriormente, haga clic derecho en el modelo y seleccione .
Esto debería abrir la nueva página de la biblioteca de decisiones:
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 fuera necesario.
Así que procedamos a añadir nuestra lógica para nuestra decisión. 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 datos empresariales, utilizaremos " Customer Credit Transfer "
El siguiente campo que tenemos es "Resultados", el cual es un concepto nuevo.
Un "Resultado" es simplemente un posible resultado de la decisión. Una decisión puede tener tantos resultados diferentes como usted 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 completada, nuestra decisión debería verse así:
Esa es nuestra decisión definida y lista para usar, por lo que el siguiente paso es integrarla al flujo.
Usando un Decision
Una decisión se maneja de manera ligeramente diferente a la función de dominio o a 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 una decisión, sin embargo, es solo una posición de enrutamiento en el flujo y, como tal, ahora introducimos el concepto de un pseudo estado. Estos se utilizarán en diferentes casos más adelante en el tutorial, pero por ahora solo utilizaremos el que necesitamos para decisiones, al que nos referiremos como un estado de decisión.
Como se mencionó en la introducción, la decisión es muy ligera, por lo que no es necesario agregar eventos o comportamientos de entrada aquí. Podemos pasar directamente a la Event Procesamiento de comportamiento.
Una vez que hayamos recibido el evento de Validación de Cuenta Aprobada, debemos ejecutar la decisión de verificación de fraude. Si se requiere una verificación de fraude, ejecutaremos la verificación de fraude como antes; de lo contrario, simplemente completaremos nuestro pago.
Así que comencemos editando nuestro manejo del evento "Validación de Cuenta Aprobada", antes teníamos:
Ahora, en lugar de pasar al estado de "Verificación de Fraude", nos moveremos al estado de decisión "Ejecutar Verificación de Fraude" y ejecutaremos nuestra decisión. Para esto, en lugar de seleccionar un estado concreto como "Verificación de Fraude" en el "Mover a" State " sección elegimos "Crear Decision State.
Aquí podemos ingresar el nombre del estado como "Ejecutar Verificación de Fraude" (teniendo en cuenta que este no tiene que ser el mismo nombre que la decisión que pretendemos utilizar. Es una buena regla general hacerlo así, pero al permitir cualquier nombre aquí podemos reutilizar la misma decisión 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 decisión "Ejecutar Verificación de Fraude" (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 comportamiento de evento y luego especificará:
-
el "Con Actual State "ser nuestro estado de decisión de 'Ejecutar verificación de fraude'."
-
el "Cuándo" para estar "Encendido"
Para el evento, utilizamos un tipo especial de evento.- el "Decision Resultado Event" así que seleccionamos "*Decision Resultado" y luego elija nuestro resultado "SKIP_FRAUD". Luego, para completar nuestro comportamiento, simplemente nos movemos a "Completar". Una vez finalizado, debería verse así:
A continuación, necesitamos realizar el comportamiento cuando la decisión indica que debemos ejecutar la verificación de fraude. En ese caso, simplemente queremos pasar al estado de "Verificando Fraude" y ejecutar la solicitud de "Verificación de Fraude". Intente añadir esto, o si lo prefiere, la solución se encuentra a continuación:
Eso es todo, ahora hemos integrado nuestra decisión en nuestro flujo. Abramos 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 las transiciones de estado, lo cual puede ser más fácil de visualizar. 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 la parte de java.
Primero necesitamos regenerar el código de la aplicación para recoger los cambios que hemos realizado en la edición de nuestro 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 paquete de decisiones (& 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 transferencia de crédito, pero podemos estar enviando múltiples elementos a los datos comerciales para una decisión. 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 que esté 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 ya está completa.
Verificando nuestra Solución
Verifiquemos que los cambios en nuestra aplicación funcionen, como de costumbre, iniciaremos la aplicación como se indicó anteriormente (las instrucciones 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 pestaña (buscar por id de unidad de trabajo, haga clic en ver, haga clic domain events)
Ahora estamos recibiendo el nuevo evento para "Ejecutar Verificación de Fraude FRAUD_REQUIRED" seguido de la ejecución de la verificación de fraude, y podemos ver que nuestro código está funcionando como esperábamos.
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 la decisión misma (representada como un diamante).
Fraude Omitido
Ahora intentemos nuestro caso inverso enviando un pago con un valor < 10 USD y luego observemos los eventos de nuestro pago devuelto (recordando reemplazar el id de agregado con el suyo):
curl -X POST localhost:8080/submit -H 'Content-Type: application/json' -d '{"value": "5"}' | jqEsta vez, esperaríamos ver la decisión ejecutar y decidir 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 pestaña (buscar por id de unidad de trabajo, haga clic en ver, haga clic en domain events)
¡Y encontramos exactamente lo que esperábamos! Por lo tanto, hemos demostrado que ahora estamos invocando nuestra decisión y hemos superado con éxito nuestra verificación de fraude.
Conclusiones
En esta sección, hemos:
-
Se añadió una decisión
-
se proporcionó una implementación predeterminada que verifica el valor del pago
-
utilizó nuestra decisión para impulsar el enrutamiento de flujo
-
verificó que nuestra decisión está funcionando y siendo llamada
Ahora que ha configurado nuestra aplicación para tomar decisiones sobre cómo procesar el pago, examinemos otra capacidad:xref:add_mapping_function.adoc[] |