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 considera conceptos avanzados como la reutilización y el versionado.
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 evento.
-
Moverá el flujo al estado "Completo" (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 módulo de procesamiento de datos 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 se envíen esos datos. Esto lo estamos utilizando como una forma de facilitar la visualización y comprensión del funcionamiento de nuestra Aplicación IPF.
Ahora configure 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 de la 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 a través de lo que nos está indicando.
| 1 | En primer lugar, tenemos las propiedades específicas de akka.En nuestro caso, la clave aquí es que definimos que queremos ejecutar con un solo nodo. En un entorno de producción, deberíamos considerar nuestras opciones para el agrupamiento, pero por ahora utilizamos este enfoque simple. 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. Asumimos en lo anterior que habrá un servicio de mongo ejecutándose en localhost:27017, |
| 4 | A continuación, llegamos al "processing-data.egress". El módulo de salida de datos de procesamiento 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 "system-events.exporter". Los eventos del sistema son la forma en que IPF emite información sobre lo que está sucediendo dentro de IPF mismo. Usted se encontrará con estos en mayor profundidad más adelante. Por ahora, la clave es simplemente que estamos configurando ipf.system-events.exporter.type para que sea "ipf-processing-data-egress", indicando a nuestra aplicación que envíe los eventos del sistema a la configuración de procesamiento de datos que hemos desplegado. |
| 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. |
| Utilizaremos la "ipf-developer-app" para consumir los datos generados a partir de los servicios de procesamiento de datos. Esta es una aplicación de ejemplo simple y ligera que proporciona una vista de los datos generados por IPF. No es una utilidad de producción, sino que se utiliza para asistir en el desarrollo. Los detalles para utilizar la aplicación de desarrollador se enumeran aquí:Ejecutando la aplicación de desarrollador. |
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 entorno docker de soporte y, segundo, ejecutar utilizando un conjunto de archivos jar ejecutables.
Ejecutando el entorno de soporte de Docker
Como se discutió en el resumen del tutorial, el proyecto base del tutorial tiene un proyecto "ipf-tutorial-docker". Este puede ser construido simplemente ejecutando una compilación de maven desde esa carpeta:
mvn clean installDespués de que esto se haya ejecutado, hay dos métodos para iniciar nuestro entorno de docker. En primer lugar, se proporcionan dos ejecutores de java:
El 'DSLTutorial Launcher' puede ejecutarse y esto construirá un entorno docker 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 ejecutarse y esto construirá un entorno docker más completo que contiene mongo, la aplicación ipf-developer-app y todos los simuladores listos para que los utilice. Esto será necesario al ejecutar los tutoriales "CONN".
Alternativamente, si usted mira en el directorio de destino, entonces bajo la carpeta de docker puede ver los dos archivos básicos de docker-compose para ambas opciones.
| También en el directorio de destino encontrará el directorio docker/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 principal ipf-tutorial-docker, 'clean-all.sh'. Este puede ser ejecutado para restablecer completamente su entorno de docker y eliminar todos los datos hasta la fecha. |
Ejecutando los archivos JAR ejecutables de soporte
Si no desea utilizar un entorno docker, podemos implementarlo como una aplicación tradicional de spring boot y utilizar 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 adecuada de la aplicación para desarrolladores desde ipf-lanzamientos repositorio Nexus, por ejemplo, la versión 2.1.2 se puede encontrar aquí:
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"
Si está utilizando 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 de la aplicación del 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 código de 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 implementaciones de comportamiento basadas en eventos junto con todos los puertos con los que se comunicará el dominio.
-
El código de prueba generado estará en "domain-root/test/target" - esto contiene el código del marco de prueba generado 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 ejecutar la aplicación como una simple aplicación de Spring Boot. En IntelliJ, puede hacerlo simplemente haciendo clic derecho en el archivo principal 'Application.java' y eligiendo 'Run Application'.
Suponiendo que nuestras propiedades son correctas, entonces la aplicación se iniciará y estaremos listos para continuar.
| Por defecto, los tutoriales han sido configurados para utilizar el entorno docker de soporte. 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 una imagen de docker
Si lo deseamos, también podemos construir la solución del tutorial como una imagen de docker. Para ello, debemos ir a la raíz de la solución y ejecutar el siguiente comando:
mvn clean install -rf:ipf-tutorial-app -PcontainerLas cosas clave a tener en cuenta aquí son la bandera -Pcontainer, esto indica Maven para activar el perfil que contiene el complemento de generación de imágenes de docker. Consulte el archivo pom de la ipf-tutorial-app para ver cómo se hace.
Tenga en cuenta en lo anterior el uso de -rf:ipf-tutorial-app -> esto le indica a maven que solo reconstruya 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í. |
La imagen de docker que se genera puede ser utilizada como parte de un entorno docker añadiendo esto a su archivo docker-compose:
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 el contenedor docker en ejecución. 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 entorno de Docker 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 contenedor de docker junto con el entorno de soporte de docker mencionado anteriormente, entonces deberá cambiar los hosts para utilizar los nombres de host de docker. 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 echando un vistazo a la InitiationController.
Esta clase ha sido construida simplemente como una forma rápida de interactuar con el IPF application El sistema y, dependiendo de los requisitos de su solución, puede que no sea necesario. Utiliza un simple endpoint REST para proporcionar capacidades de verificación de estado 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 "opcional". InitiationRequest ", 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.- a 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 json devuelto de nuestros comandos de una manera atractiva. En todos estos, por lo tanto, puede simplemente eliminar el | jq¡para devolver json puro!
Creemos un pago en nuestro nuevo entorno. Para ello, simplemente necesitamos pulsar el ejemplo. InitiationController el punto final de envío de 's, 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- este es el "id de unidad de trabajo", es el único ID 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 el " requestId " en su respuesta teniendo el valor "abc". Más tarde 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 dado en el comando a lo que se devolvió cuando creó su pago. También deberá reemplazar el carácter | con el codificado '%7C'. Alternativamente, podría 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 eventos 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 eventos en el diario. Esta es una colección que se almacena en mongo, bajo la base de datos IPF. Si usted utiliza su visor de mongo favorito (por ejemplo, nuestros ingenieros a menudo utilizan Robo3t)
Entonces puede ver los eventos 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 evento.
-
"estado":`{"originatingStatus":"Initial","resultingStatus":"Complete","globalStatus":"ACCEPTED"}` - aquí podemos ver que este evento fue recibido en el
Initialestado y causó que el pago se moviera alCompleteestado. Ha transformado el pago a la globalACCEPTEDestado. -
associationId":`Ipftutorialflow|44d0f1df-eb66-4826-8b1f-63eac604b730` - esto es el aggregateId.
-
unitOfWorkId":`8995c642-a887-4676-a690-2bf261fba172` - este es el identificador de la unidad de trabajo de pago general.
-
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 ID de unidad de trabajo 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, por lo que solo vemos un registro. En un 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 él 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 nuestras decisiones de pago sobre 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 tanto datos proporcionados al flujo a través de eventos como datos calculados por el propio IPF (esto lo abordaremos en DSL 6 - Funciones de Mapeo)
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 se han registrado durante el proceso de pago. Hay un par de puntos interesantes a tener en cuenta aquí:
-
Número de Secuencia- Este es un orden de los eventos 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 veamos la vista de eventos del sistema:
Aquí podemos ver que nuestro flujo ha generado 7 eventos del sistema. Los eventos del sistema 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, reflexionemos rápidamente sobre lo que nos están indicando. Efectivamente, están proporcionando una historia de los "eventos" que han ocurrido en nuestro "sistema" y que están asociados a este pago en particular. Nos cuenta una historia:
_El flujo comenzó > Se recibió un comando (la instrucción de iniciación) > Un dominio Event se persistió (el evento de Flujo Iniciado) > Hubo una transición de estado (de Inicial a Completo) > El Flujo Finalizó. _
Consulte los diferentes eventos generados aquí y revise 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 completo 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.