Revisando la aplicación tutorial inicial
|
Iniciando
El paso del tutorial utiliza la solución "inicial" del proyecto como punto de partida. Puede abrirla seleccionando <install-root>/solutions/initial/pom.xml en Intellij. |
Orientación Empresarial
Este tutorial utiliza una aplicación común sobre la cual construiremos de manera paso a paso para investigar diferentes características y capacidades de la Plataforma IPF. La aplicación inicial es un flujo muy simple que simplemente realiza:
A partir de aquí, usted avanzará para agregar llamadas a otros servicios mientras examina conceptos avanzados como la reutilización y versioning.
Comprendiendo la estructura de la aplicación
Ahora tendrá una breve inmersión en la aplicación real y en la forma en que está estructurada.
Comencemos por examinar la aplicación que hemos descargado. Si abrimos el proyecto en Intellij, podemos ver que tiene 2 carpetas principales dentro de él:
-
domain-root- esto contiene todos los artefactos relacionados con la DSL y las definiciones de flujo.
-
ipf-tutorial-app- esto contiene todo el código de ejecución de la aplicación, este es el código que se desplegará y utilizará el dominio generado por el IPF para procesar transacciones.
Cuando la aplicación recibe una solicitud, realizará una serie de pasos simples:
-
Generará un ID único para el proceso.
-
Iniciará un nuevo flujo.
-
Generará un nuevo FlowInitiated event.
-
Moverá el flujo a "Completo" state(Tenga en cuenta que esto se debe simplemente a cómo está configurado actualmente nuestro flujo. Se investigará más sobre esto más adelante.)
La aplicación también está utilizando el processing data módulo dentro de IPF. Usted lo examinará con mayor profundidad en un tutorial posterior, pero por ahora lo que necesitamos saber es que los datos generados por IPF están siendo empaquetados y enviados a través de HTTP. En nuestro caso, hemos añadido un pequeño contenedor "ipf-developer-app" que tiene un punto final publicado para que esos datos sean enviados. Esto lo estamos utilizando como una forma de facilitar la visualización y comprensión de cómo nuestro IPF Application está funcionando.
Ahora configuremos la aplicación para procesar un pago.
Configuración de la Aplicación
La aplicación utiliza hocon para definir propiedades. Puede ver la configuración de la aplicación dentro del directorio src/main/resources del proyecto principal ipf-tutorial-app. Allí, revisemos algunas configuraciones dentro del application.conf archivo:
akka { (1)
cluster {
seed-nodes = ["akka://"${actor-system-name}"@0. 0. 0. 0:"${akka.remote.artery.canonical.port}]
sharding.remember-entities = on
}
remote.artery {
canonical.port = 55001
canonical.hostname = 0. 0. 0. 0
bind.hostname = 0. 0. 0. 0
bind.port = 55001
}
}
ipf { (2)
mongodb.url = "mongodb://localhost:27017/ipf" (3)
processing-data.egress { (4)
enabled = true
transport = http
http {
client {
host = "localhost"
port = 8081
endpoint-url = "/ipf-processing-data"
}
}
}
system-events.exporter { (5)
type = ipf-processing-data-egress
}
behaviour.retries { (6)
initial-timeout=5s
}
}
management.endpoints.web.exposure.include = "*"Analicemos cada sección de esto y trabajemos en lo que nos está indicando.
| 1 | En primer lugar, tenemos el akka propiedades específicas. En nuestro caso, la clave aquí es que definimos que queremos operar con un solo nodo. En un entorno de producción, deberíamos considerar nuestras opciones para el agrupamiento, pero por ahora simplemente utilizamos este enfoque sencillo. La sección de configuración aquí podría utilizarse como base para sus propios proyectos y, de hecho, es la misma que la producida por el IPF. Scaffolder. | ||
| 2 | Todas las propiedades específicas de "IPF" se encuentran en la sección ipf aquí. Hay algunas propiedades diferentes, así que consideremos cada una por separado: | ||
| 3 | La primera propiedad que encontramos es ipf.mongodb.url, en el caso del tutorial estamos utilizando mongo como nuestro proveedor de base de datos, por lo que esta es simplemente la URL de conexión. Estamos asumiendo en lo anterior que habrá un servicio de mongo ejecutándose en localhost:27017, | ||
| 4 | A continuación, llegamos a "processing-data.egress". El processing data El módulo de salida se utiliza para exportar datos desde IPF a una ubicación deseada, por ejemplo, un Kafka tema o un HTTP punto final. Aquí estamos definiendo:
|
||
| 5 | La siguiente sección es para "sistema-events.exportador". System events son la forma de IPF de emitir información sobre las cosas que están sucediendo dentro de IPF mismo. Usted se encontrará con estos temas en mayor profundidad más adelante. Por ahora, la clave es simplemente que estamos configurando ipf.system-events.exporter.type debe ser "ipf-processing-data-egress", indicando a nuestra aplicación que envíe el system events a la processing data configuración que hemos implementado. | ||
| 6 | La siguiente configuración es el "behaviour.retries.initial-timeout". Los reintentos de comportamiento son un mecanismo para reenviar comandos a IPF si por alguna razón no se ha recibido una respuesta. La configuración predeterminada está establecida para esperar 100 ms antes de una respuesta; sin embargo, aquí estamos aumentando esto a 5 s simplemente bajo la suposición de que este tutorial se está ejecutando en una máquina de menor capacidad y, por lo tanto, para darle un poco más de tiempo para completar cualquier solicitud.
|
Entornos de Soporte
Para ejecutar el tutorial, se requieren varios componentes de soporte.
-
Para los pasos del tutorial de DSL, una base de datos mongo junto con una instancia en ejecución de la aplicación de desarrollador IPF.
-
Para los pasos del tutorial del conector, además de la aplicación base de mongo y la aplicación de desarrollador, también necesitamos las diferentes instancias de los simuladores de soporte que requeriremos:
-
Iniciación de Pago
-
Sanciones
-
Fraude
-
Para utilizar estos, hay un par de opciones disponibles, primero ejecutar utilizando un soporte docker entorno y, en segundo lugar, ejecutar utilizando un conjunto de archivos JAR ejecutables.
Ejecutando el soporte docker entorno
Como se discutió en el resumen del tutorial, el proyecto base del tutorial tiene un "ipf-tutorial-docker "proyecto. Esto se puede construir simplemente ejecutando un maven construya desde esa carpeta:
mvn clean installDespués de que esto se haya ejecutado, hay dos métodos para iniciar nuestro docker entorno. En primer lugar, hay dos java runners proporcionados:
El 'DSLTutorial Launcher' puede ser ejecutado y esto construirá un docker entorno que contiene mongo y la aplicación ipf-developer-app lista para que usted la utilice. Esto será necesario al ejecutar los tutoriales "DSL".
El 'ConnectorTutorialsLauncher' puede ser ejecutado y esto construirá un más completo docker entorno que contiene mongo, la aplicación ipf-developer-app y todos los simuladores listos para que usted los utilice. Esto será necesario al ejecutar los tutoriales "CONN".
Alternativamente, si usted mira en el directorio de destino, entonces bajo el docker carpetas puede ver los dos básicos docker- componga archivos para ambas opciones.
| También en el directorio de destino encontrará el docker El directorio /logs donde se escribirán todos los registros de los diversos componentes en caso de que sean necesarios. |
| También se proporciona un script en el directorio de scripts del tutorial principal ipf-tutorial-docker, 'clean-all.sh'. Esto puede ser ejecutado para restablecer completamente su docker el entorno y elimine todos los datos hasta la fecha. |
Ejecutando los archivos JAR ejecutables de soporte
Si no desea utilizar un docker entorno, podemos mencionarlo como un tradicional spring boot aplicación y uso de alguna infraestructura existente, por ejemplo, un entorno mongo compartido.
Para los tutoriales de DSL, solo necesitará mongo y la aplicación ipf-developer-app ejecutable.
Ejecutando la aplicación ipf-developer-app
Primero, deberá descargar la versión apropiada de la aplicación para desarrolladores desde ipf-lanza repositorio Nexus, por ejemplo, la versión 2. 1. 2 se puede encontrar aquí:
https://nexus.ipf.iconsolutions.com/repository/ipf-releases/com/iconsolutions/ipf/developer/ipf-developer-app/2. 1. 2/ipf-developer-app-2. 1. 2-runnable.jar[[_note_about_versions]]
Debe elegir y descargar una versión de la ipf-developer-app *que sea compatible con la versión de IPF que está utilizando*. Por favor, verifique y reemplace los números de versión según el xref:reference::release/releases.adoc[Documentación de liberación de IPF] y/o los detalles para su entorno objetivo. |
Para ejecutar esto, simplemente necesitamos ejecutar el siguiente comando, reemplazando {version} con la versión que está utilizando (por ejemplo, 2. 1. 2):
java -cp "ipf-developer-app-{version}-runnable.jar:config" -D"ma.glasnost.orika.writeClass Files"=false -D"ma.glasnost.orika.writeSource Files"=false -D"config.override_with_env_vars"=true -D"loader.main"="com.iconsolutions.ipf.developer.app. IpfDeveloperApplication" "org.springframework.boot.loader.launch. PropertiesLauncher"
[SUGERENCIA]
====
Si utiliza Windows, necesitamos reemplazar el primero `:` con un `;`. Por ejemplo:`ipf-developer-app-+{version}+-runnable.jar;config`
====Esto se ejecutará con la configuración predeterminada, a saber:
-
ipf.mongo.url = "mongodb://ipf-mongo:27017/ipf" -
server.port = "8081"
Es posible anular estos valores añadiendo un `application.conf` archivo bajo un `config` directorio en la misma carpeta desde la cual está ejecutando el comando anterior. Se proporciona un ejemplo en el `supporting-apps/ipf-developer-app` carpeta del `ipf-tutorial` proyecto.
Después de iniciar un entorno mongo y la aplicación ipf-developer-app, ahora estamos listos para ejecutar todos los tutoriales de 'DSL'.
Ejecutando los simuladores ejecutables
Para ejecutar los tutoriales basados en el otro conector, también necesitaremos los simuladores. Al igual que la aplicación ipf-developer-app, estos también están disponibles en nexus.
La configuración para cada uno de estos se puede encontrar junto a la del aplicativo de desarrollador.
| Cada una de las aplicaciones ejecutables viene acompañada de un archivo 'Readme' que explica cómo iniciarlas. |
Construyendo la aplicación tutorial
Para construir la aplicación utilizamos Maven, necesitaremos ejecutar esto desde la raíz de nuestro módulo inicial:
mvn clean installLa compilación utilizará los flujos definidos para generar el código de la aplicación. El código generado puede verse en varios lugares clave:
-
El código de dominio generado estará en "domain-root/domain/target" - esto incluirá todo el Akka event implementaciones de comportamiento obtenidas junto con todos los puertos con los que el dominio se comunicará.
-
El código de prueba generado estará en "domain-root/test/target" - esto contiene lo generado test framework código para proporcionar una capacidad de prueba contra nuestro dominio.
-
Los adaptadores de muestra generados estarán en "domain-root/sampleapp/target - Esto contiene un conjunto de implementaciones de muestra simples para todos los puertos generados. Estos pueden ser utilizados para iniciar rápidamente un flujo complejo y hacerlo ejecutable. En esta etapa, dado que nuestro flujo es tan simple, lo único que tenemos aquí es un archivo de configuración de ejemplo.
Ejecutando la aplicación tutorial
Una vez que tengamos el entorno de soporte adecuado en funcionamiento, necesitamos iniciar la aplicación. La forma más sencilla de hacerlo es simplemente ejecutar la aplicación como un simple spring boot aplicación. En IntelliJ, podemos hacer esto simplemente haciendo clic derecho en la 'Aplicación' principal.java’archivo y eligiendo 'Ejecutar Aplicación'.
Suponiendo que nuestras propiedades son correctas, entonces la aplicación se iniciará y estamos listos para continuar.
| Por defecto, los tutoriales han sido configurados para utilizar el soporte docker entorno. Si está ejecutando en su propio entorno, entonces puede necesitar cambiar la configuración. En particular, por ejemplo, puede necesitar cambiar la URL de mongo que está utilizando. Consulte la explicación de la configuración anterior para más detalles. |
Construyendo el tutorial como un docker imagen
Si lo deseamos, también podemos construir la solución del tutorial como un docker imagen. Para hacer esto, vamos a la raíz de la solución y ejecutamos el siguiente comando:
mvn clean install -rf:ipf-tutorial-app -PcontainerLas cosas clave a tener en cuenta aquí son el -Pcontainer flag, esto indica Maven para activar el perfil que contiene el docker plugin de generación de imágenes. Consulte el archivo pom de la aplicación ipf-tutorial-app para ver cómo se hace esto.
Tenga en cuenta en lo anterior el uso de -rf:ipf-tutorial-app -> esto indica maven para reconstruir únicamente el proyecto ipf-tutorial-app. Puede reconstruir todo y omitir esto, pero dado que acabamos de generar todo nuestro código hace un momento, no hay necesidad de reconstruir esos proyectos aquí. |
El docker la imagen que se genera puede luego ser utilizada como parte de un docker entorno al agregar esto a su docker-archivo de composición:
ipf-tutorial-app-initial:
image:ipf-tutorial-app-initial:latest
container_name: ipf-tutorial-app-initial
ports:
- 8080:8080
- 8559:8558
- 5006:5005
- 55002:55001
- 9002:9001
volumes:
-./config/ipf-tutorial-app-initial:/ipf-tutorial-app-initial/conf
-./logs:/ipf/logs
environment:
- IPF_JAVA_ARGS=-Dma.glasnost.orika.writeClass Files=false -Dma.glasnost.orika.writeSource Files=false -Dconfig.override_with_env_vars=true
depends_on:
- ipf-mongo-ipf-developer-app
healthcheck:
test: [ "CMD", "curl", "http://localhost:8080/actuator/health" ]
Algunas cosas a tener en cuenta sobre esta configuración:
-
Exponemos el puerto "5006" - este es el puerto "debug", permitirá que adjuntemos un depurador remoto.
-
Mapeamos el directorio "logs" en nuestra máquina local al directorio "/ipf/logs" en la ejecución.docker contenedor. Esto significa que podemos ver todos los registros de la aplicación en _docker/logs/
-
La configuración se encontrará en _docker/config/ Aquí necesitaremos proporcionar sobreescrituras de configuración que sean específicas para el docker entorno que necesitamos ejecutar. Para ello, cree un application.conf archivo y añada las propiedades que necesite.
Por ejemplo, si ejecuta la aplicación tutorial como un docker contenedor junto al docker apoyando docker el entorno anterior, entonces deberá cambiar los hosts para utilizar el docker nombres de host. Así que su application.conf el archivo se vería así:
ipf {
mongodb.url = "mongodb://ipf-mongo:27017/ipf"
processing-data.egress {
http {
client {
host = "ipf-developer-app"
}
}
}
}Realizando un pago
Ahora que hemos iniciado nuestra aplicación y el entorno de soporte, es momento de procesar algunos pagos a través de ella. Comencemos por echar un vistazo rápido al InitiationController.
Esta clase ha sido construida simplemente como una forma rápida de interactuar con el IPF application sistema y dependiendo de los requisitos de su solución, puede que no sea necesario. Utiliza un simple rest punto final para proporcionar capacidades de verificación de salud y envío. En una aplicación "real", la iniciación puede provenir de muchos canales diferentes y a través de cualquier número de protocolos.
Si observamos el método principal de iniciación en el controlador:
@RequestMapping(value = "/submit", method = RequestMethod. POST)
public Mono<InitiationResponse> submit(@RequestBody(required = false) InitiationRequest request) {
String unitOfWorkId = UUID.randomUUID().toString(); // this is the common id used to link all flow elements and uniquely identify a request.
String clientRequestId = Objects.nonNull(request) && Objects.nonNull(request.getRequestId())? request.getRequestId(): UUID.randomUUID().toString(); // this is a client id (if required)
String entityId = UUID.randomUUID().toString(); // this is the entity id to uniquely identify the current flow.
var samplePacs008 = Pacs008Generator.generate();
if (Objects.nonNull(request) && Objects.nonNull(request.getValue())) {
samplePacs008.getCdtTrfTxInf().get(0).getIntrBkSttlmAmt().setValue(request.getValue());
}
return Mono.fromCompletionStage(IpftutorialmodelDomain.initiation().handle(new InitiateIpftutorialflowInput. Builder(entityId)
.withProcessingContext(ProcessingContext.builder()
.unitOfWorkId(unitOfWorkId)
.clientRequestId(clientRequestId)
.build())
.withCustomerCreditTransfer(samplePacs008)
.build()).thenApply(done -> InitiationResponse.builder().requestId(clientRequestId).uowId(unitOfWorkId).aggregateId(done.getAggregateId()).build()));
}Podemos ver aquí que nuestro controlador toma un "InitiationRequest" opcional, examinemos eso también:
@Data
public class InitiationRequest {
private String requestId;
private BigDecimal value;
private String version;
}Podemos ver aquí que hemos proporcionado 3 propiedades en nuestra solicitud de inicio.- un requestId, un valor y una versión. Esto se utilizará en sesiones de tutorial posteriores para probar diversas cosas.
Esta serie de tutoriales asume que usted tiene una pequeña utilidad llamada jq instalado en su máquina, esto simplemente formateará el devuelto json de nuestros comandos de una manera atractiva. En todos estos, por lo tanto, puede simplemente eliminar el | jq para devolver puro json!
Creemos un pago en nuestro nuevo entorno. Para ello, simplemente necesitamos acceder al endpoint submit del InitiationController de ejemplo, lo cual podemos hacer ejecutando el siguiente comando:
curl -X POST localhost:8080/submit | jqEsto devolverá los detalles del pago que ha sido creado, tales como:
{ "requestId": "220b4868-a96c-4d9a-8b17-b1aa714f05e8", "uowId": "8995c642-a887-4676-a690-2bf261fba172", "aggregateId": "Ipftutorialflow|44d0f1df-eb66-4826-8b1f-63eac604b730" }Aquí podemos ver una serie de aspectos clave:
-
El "request Id" - esto identifica la solicitud que se está realizando. Normalmente, esto sería proporcionado por el sistema que realiza la llamada, pero en nuestro caso, es generado automáticamente por la prueba "Controlador de Iniciación".
-
El "uow Id" - esto es el " unit of work "id", es el ID único que puede ser utilizado a lo largo de la aplicación para rastrear el pago. Esto se vuelve particularmente útil, por ejemplo, al considerar un pago que abarca múltiples flujos.
-
El "aggregate Id" - este es el ID del individuo payment flow que ha sido iniciado.
Si quisiéramos, podríamos suministrar los parámetros adicionales en nuestro comando, por ejemplo:
curl -X POST localhost:8080/submit -H 'Content-Type: application/json' -d '{"value": "150", "requestId":"abc"}' | jqEsto enviaría una solicitud con un valor de "150" y un requestId de "abc". Si usted intenta esto ahora, veremos que el "requestId" en su respuesta tiene el valor "abc". Más adelante podemos verificar que el valor de nuestro pago también se ha establecido en 150 USD.
Consultando el pago
La aplicación tutorial también proporciona un controlador de consultas simple que nos permite realizar llamadas básicas a IPF para recuperar datos. Por lo tanto, por ejemplo, puede recuperar el estado del pago llamando a:
curl -X GET localhost:8080/query/Ipftutorialflow%7C44d0f1df-eb66-4826-8b1f-63eac604b730/status | jqEsto debería devolver el valor "COMPLETE" - Tenga en cuenta que necesitaremos intercambiar el aggregateId proporcionado en el comando por aquel que fue devuelto cuando creó su pago. También deberá reemplazar el carácter | con el codificado '%7C'. Alternativamente, puede simplemente pegar la ruta en su navegador favorito.
La tabla a continuación muestra la lista de puntos finales disponibles que pueden ser consultados. Para utilizarlos, simplemente reemplace "aggregate/status" en el comando anterior por la ruta del punto final indicada en la tabla.
| Ruta del Endpoint | Proporciona.. |
|---|---|
consulta/{aggregateId} |
Una copia completa del agregado para su pago |
consulta/{aggregateId}/estado |
El estado actual de su pago |
consulta/{aggregateId}/eventNames |
Una lista de events que han ocurrido con su pago |
consulta/{aggregateId}/processingContext |
El contexto de procesamiento de su pago |
¡Pruebe algunos de estos ahora para familiarizarse con el uso del controlador y el tipo de datos que proporciona!
Tenga en cuenta que el servicio de consulta en este punto del tutorial es una implementación muy simple basada en controladores. En sesiones posteriores de esta serie de tutoriales, trabajaremos en proporcionar una mayor profundidad y posibilidades a través de la proyección de datos e introduciremos el IPF independiente. ODS Servicio.
El diario de pagos
A medida que IPF realiza su procesamiento, escribe todos sus events al diario. Esta es una colección que se almacena en mongo, bajo la base de datos IPF. Si utiliza su visor de mongo favorito (por ejemplo, nuestros ingenieros a menudo utilizan Robo3t)
Entonces puede ver el events que han sido persistidos en el diario. Debe poder encontrar un registro como:
{ "_id": ObjectId("62bb257a29d64365337f88be"), "eventPayloads": [ { "deleted": false, "manifest": "", "payload": { "type": "om.iconsolutions.ipf.tutorial.ipftutorialflow.events. FlowInitiated", "value": "{"createdAt":1656431994. 593398000,"originalCommandId":"HandleInitiateIpftutorialflow|07adee15-80ea-44d0-ab3b-efe3be1ba20e|be7cf0a8-29af-4d96-9018-8efecb8b3bc6","status":{"originatingStatus":"Initial","resultingStatus":"Complete","globalStatus":"ACCEPTED"},"eventId":"Ipftutorialflow|44d0f1df-eb66-4826-8b1f-63eac604b730|1","processingContext":{"associationId":"Ipftutorialflow|44d0f1df-eb66-4826-8b1f-63eac604b730","unitOfWorkId":"8995c642-a887-4676-a690-2bf261fba172","clientRequestId":"220b4868-a96c-4d9a-8b17-b1aa714f05e8","processingEntity":"UNKNOWN"},"initiatingId":"44d0f1df-eb66-4826-8b1f-63eac604b730","causedByEventId":null,"responseCode":null,"originalResponseCode":null,"reasonCode":null,"originalReasonCode":null,"reasonText":null,"originalReasonText":null,"failureResponse":false,"customerCreditTransfer":\{"grpHdr":\{"msgId":"42708ab4-a5ee-4c07-9331-3c34a1438bfa","creDtTm":1656431994. 184934000,"btchBookg":null,"nbOfTxs":"1","ctrlSum":null,"ttlIntrBkSttlmAmt":\{"value":10. 45,"ccy":"USD"},"intrBkSttlmDt":[2022, 6, 28],"sttlmInf":\{"sttlmMtd":"CLRG","sttlmAcct":null,"clrSys":null,"instgRmbrsmntAgt":null,"instgRmbrsmntAgtAcct":null,"instdRmbrsmntAgt":null,"instdRmbrsmntAgtAcct":null,"thrdRmbrsmntAgt":null,"thrdRmbrsmntAgtAcct":null},"pmtTpInf":null,"instgAgt":\{"finInstnId":\{"bicfi":"IPSTFRP0","clrSysMmbId":null,"lei":null,"nm":null,"pstlAdr":null,"othr":null},"brnchId":null},"instdAgt":\{"finInstnId":\{"bicfi":"ICSLGBL1","clrSysMmbId":null,"lei":null,"nm":null,"pstlAdr":null,"othr":null},"brnchId":null}},"cdtTrfTxInf":[\{"pmtId":\{"instrId":null,"endToEndId":"866afe26-c173-4921-9587-468f2f974b73","txId":"cecbe387-3906-4351-9fab-dd8b1ad48333","uetr":"1e97e521-d7d6-4913-b941-63e437f884f9","clrSysRef":"2c3b0220-1df4-4a3e-8372-0d7a5a15b3c3"},"pmtTpInf":null,"intrBkSttlmAmt":\{"value":10. 45,"ccy":"USD"},"intrBkSttlmDt":null,"sttlmPrty":null,"sttlmTmIndctn":null,"sttlmTmReq":null,"accptncDtTm":1656431994. 191809000,"poolgAdjstmntDt":null,"instdAmt":null,"xchgRate":null,"chrgBr":null,"chrgsInf":[],"prvsInstgAgt1":null,"prvsInstgAgt1Acct":null,"prvsInstgAgt2":null,"prvsInstgAgt2Acct":null,"prvsInstgAgt3":null,"prvsInstgAgt3Acct":null,"instgAgt":null,"instdAgt":null,"intrmyAgt1":null,"intrmyAgt1Acct":null,"intrmyAgt2":null,"intrmyAgt2Acct":null,"intrmyAgt3":null,"intrmyAgt3Acct":null,"ultmtDbtr":null,"initgPty":null,"dbtr":\{"nm":"7f0d8165-9c67-4989-865e-15fce48689c1","pstlAdr":null,"id":null,"ctryOfRes":null,"ctctDtls":null},"dbtrAcct":\{"id":\{"iban":"GB26MIDL40051512345674","othr":null},"tp":null,"ccy":"EUR","nm":null,"prxy":null},"dbtrAgt":\{"finInstnId":\{"bicfi":"ICSLGBL1","clrSysMmbId":null,"lei":null,"nm":null,"pstlAdr":null,"othr":null},"brnchId":null},"dbtrAgtAcct":null,"cdtrAgt":\{"finInstnId":\{"bicfi":"ICSLGBL2","clrSysMmbId":null,"lei":null,"nm":null,"pstlAdr":null,"othr":null},"brnchId":null},"cdtrAgtAcct":null,"cdtr":\{"nm":"bc67af37-93f1-452b-918e-c4fb65f2d6f2","pstlAdr":null,"id":null,"ctryOfRes":null,"ctctDtls":null},"cdtrAcct":\{"id":\{"iban":"GB26MIDL40051512345675","othr":null},"tp":null,"ccy":"EUR","nm":null,"prxy":null},"ultmtCdtr":null,"instrForCdtrAgt":[],"instrForNxtAgt":[],"purp":null,"rgltryRptg":[],"tax":null,"rltdRmtInf":[],"rmtInf":null,"splmtryData":[]}],"splmtryData":[]},"paymentJourneyType":null,"paymentType":null}" }, "persistenceId": "Ipftutorialflow|44d0f1df-eb66-4826-8b1f-63eac604b730", "sequenceNumber": NumberLong(1), "tags": [ "tag-1" ], "timestamp": NumberLong(0), "writerUuid": "06cf3f62-65fe-43db-80f2-7a98a483fea4" } ], "hiSeq": NumberLong(1), "loSeq": NumberLong(1), "persistenceId": "Ipftutorialflow|44d0f1df-eb66-4826-8b1f-63eac604b730" }
Desglosemos la carga útil un poco para que podamos ver las partes constitutivas:
-
"tipo":`com.iconsolutions.ipf.tutorial.ipftutorialflow.events. FlowInitiated` - aquí puede ver el nombre de nuestro event.
-
"estado":`{"originatingStatus":"Initial","resultingStatus":"Complete","globalStatus":"ACCEPTED"}` - aquí podemos ver que esto event fue recibido en el
Initialstate y causó que el pago se trasladara alCompletestate. Ha transformado el pago a lo globalACCEPTEDstate. -
"associationId":`Ipftutorialflow|44d0f1df-eb66-4826-8b1f-63eac604b730` - este es el aggregateId.
-
unitOfWorkId":`8995c642-a887-4676-a690-2bf261fba172` - este es el pago total unit of work id.
-
clientRequestId":`220b4868-a96c-4d9a-8b17-b1aa714f05e8` - este es el id de solicitud original.
Tenga en cuenta que para los datos mostrados arriba, estos ids corresponden a los Ids recibidos como respuesta a la solicitud de envío inicial.
El Developer GUI
La aplicación del tutorial IPF ha sido configurada para publicar sus datos de manera que puedan ser leídos por el IPF. Developer GUI. Esta es una interfaz gráfica de usuario ligera utilizada para pruebas y para demostrar la capacidad de crear diferentes vistas de los datos que está publicando IPF. Puede acceder a ella yendo a localhost:8081/explorer.html. Exploremos un poco lo que nos dice sobre nuestra aplicación simple.
Buscar
Comenzará buscando nuestra transacción utilizando el unit of work ID que se nos devolvió de nuestra solicitud de inicio:
Flujos
Deberíamos ver un registro devuelto, con los detalles básicos de ese pago. Ahora, presionemos el botón "ver" para ver más detalles:
Aquí vemos los "flujos" que componen nuestro pago. Un pago puede tener muchas etapas a través de diferentes flujos en su ciclo de vida. Por el momento, tenemos la configuración más simple disponible y es solo un flujo, de ahí que solo veamos un registro. Por ejemplo, comenzaremos a agregar múltiples flujos.
Mientras tanto, podemos observar muchas cosas sobre nuestro flujo, así que intentemos algunas de ellas.
Gráficas
En primer lugar, podemos ver el gráfico.- haga clic en el botón del gráfico y deberíamos ver el gráfico que teníamos de nuestro MPS configuración antes:
Tenga en cuenta cómo esta vez estamos coloreando en el flujo.- el camino tomado a través de está resaltado en naranja. Esto se volverá más obvio más adelante a medida que construyamos la complejidad de nuestro flujo y podamos ver nuestro pago tomando decisions acerca de qué ruta seguir.
Datos Agregados
Cerramos el gráfico y luego haga clic para ver los datos agregados.
Aquí podemos ver todos los datos "en vivo" del flujo. Nos indica todo lo que IPF tiene en memoria sobre ese flujo, incluyendo todos los datos disponibles para el flujo. Esto puede ser datos proporcionados al flujo a través de events o calculado por el IPF mismo (cubriremos esto en DSL 6 - Using an aggregate function)
Domain Events
La siguiente vista interesante es la domain events uno, hagamos clic en el naranja " Domain Events " botón:
Esto nos muestra todo el domain events que han sido registrados durante el proceso de pago. Hay un par de puntos interesantes a tener en cuenta aquí:
-
Número de Secuencia- esto es un pedido de la events a medida que llegan. En nuestro caso es trivial, pero en casos más complicados de múltiples flujos, este será el orden a través de todos los flujos, no solo uno.
-
Process Flow- esto se vuelve útil cuando hay múltiples flujos en su lugar.
-
Contenido- esto proporcionó una vista completa de todo el domain event.
System Events
Ahora examinemos el system events ver:
Aquí podemos ver que nuestro flujo ha generado 7 system events. System events son una forma de rastrear lo que ha sucedido dentro de un IPF application. Usted discutirá estos en mayor profundidad en un tutorial posterior, pero por ahora, pensemos rápidamente en lo que nos están diciendo. Ellos están proporcionando efectivamente una historia del " events " que han ocurrido en nuestro "sistema" que están asociados a este pago en particular. Nos cuenta una historia:"
_El flujo comenzó > Se recibió un comando (la instrucción de inicio) > Un domain Event fue persistido (el Flujo Iniciado event) > Hubo un state transición (de Inicial a Completo) > El Flujo Terminado. _
Consulte los diferentes events generado aquí, y consulte los detalles que están proporcionando.
Estructura de Datos del Mensaje
A continuación, veamos la pestaña Estructuras de Datos de Mensaje:
Esto nos está mostrando las diferentes estructuras de datos de mensajes preconfiguradas que están disponibles para el flujo. Discutiremos esto con mucho más detalle en tutoriales posteriores, pero por ahora podemos ver que tenemos el total pacs. 008 disponible junto con la transacción de crédito individual que corresponde a nuestro pago (notando que por ahora solo estamos tratando con relaciones 1-1 entre pacs008 y transferencias de crédito, pero más adelante esto puede convertirse en 1-n).
Las otras pestañas-mensajería y custom Los objetos están en blanco por ahora. Estos no están siendo utilizados por nuestro flujo simple aún.