Revisión de la aplicación inicial del tutorial
|
Comenzando
Este paso del tutorial utiliza como punto de partida la solución "initial" del proyecto. Puedes abrirla seleccionando <install-root>/solutions/initial/pom.xml en IntelliJ. |
Orientación de negocio
Este tutorial utiliza una aplicación común sobre la que iremos construyendo paso a paso para investigar distintas características y capacidades de la plataforma IPF. La aplicación inicial es un flujo muy sencillo que simplemente hace lo siguiente:
A partir de aquí añadirás llamadas a otros servicios mientras revisas conceptos avanzados como reutilización y versionado.
Entender la estructura de la aplicación
Ahora haremos una breve inmersión en la aplicación real y en cómo está estructurada.
Empecemos mirando la aplicación que hemos descargado. Si abrimos el proyecto en IntelliJ veremos que tiene 2 carpetas principales en su interior:
-
domain-root: contiene todos los artefactos relacionados con el DSL y las definiciones de flujos.
-
ipf-tutorial-app: contiene todo el código de ejecución de la aplicación; este es el código que se desplegará y que usará el dominio generado por IPF para procesar transacciones.
Cuando la aplicación recibe una petición, realizará una serie de pasos sencillos:
-
Generará un ID único para el proceso.
-
Iniciará un flujo nuevo.
-
Generará un evento FlowInitiated.
-
Moverá el flujo al estado "Complete" (nota: esto es simplemente por cómo está configurado nuestro flujo actualmente; más sobre esto más adelante).
La aplicación también utiliza el módulo de processing data dentro de IPF. Lo verás con más detalle en un tutorial posterior, pero por ahora basta con saber que los datos generados por IPF se empaquetan y se envían por HTTP. En nuestro caso hemos añadido un pequeño contenedor "ipf-developer-app" que expone un endpoint al que se envían esos datos. Lo usamos para facilitar ver y entender cómo funciona nuestra aplicación IPF.
Pongamos ahora la aplicación a procesar realmente un pago.
Configuración de la aplicación
La aplicación utiliza HOCON para definir propiedades. Puedes ver la configuración de la aplicación en el directorio src/main/resources del proyecto principal ipf-tutorial-app. Allí, revisemos algunos ajustes en el archivo application.conf:
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 = "*"Tomemos cada sección y entendamos qué nos indica.
| 1 | Primero tenemos las propiedades específicas de Akka. En nuestro caso, lo clave aquí es que definimos que queremos ejecutar con un solo nodo. En un entorno de producción, querríamos considerar opciones de clúster, pero por ahora usamos este enfoque sencillo. Esta sección de configuración puede servir de base para tus propios proyectos y, de hecho, es la misma que produce el IPF Scaffolder. |
| 2 | Todas las propiedades específicas de "IPF" van dentro de la sección ipf. Hay varias propiedades; consideremos cada una: |
| 3 | La primera propiedad es ipf.mongodb.url; en el caso del tutorial usamos Mongo como base de datos, así que esto es simplemente la URL de conexión. Asumimos que habrá un servicio Mongo escuchando en localhost:27017. |
| 4 | A continuación llegamos a "processing-data.egress". El módulo de egress de processing data se usa para exportar datos de IPF a una ubicación deseada, por ejemplo un topic de Kafka o un endpoint HTTP. Aquí definimos:
|
| 5 | La siguiente sección es "system-events.exporter". Los system events son la forma que tiene IPF de emitir información sobre lo que ocurre dentro de IPF. Verás esto con más detalle más adelante. Por ahora, lo clave es que establecemos ipf.system-events.exporter.type como "ipf-processing-data-egress", indicando a nuestra aplicación que envíe los system events al mecanismo de processing data que hemos desplegado. |
| 6 | La siguiente configuración es behaviour.retries.initial-timeout. Los behaviour retries son un mecanismo para volver a presentar comandos en IPF si, por cualquier motivo, no se ha recibido respuesta. La configuración por defecto espera 100 ms antes de una respuesta; aquí la aumentamos a 5 s suponiendo que este tutorial se ejecuta en una máquina menos potente y, por tanto, le damos un poco más de tiempo para completar peticiones. |
| Usaremos la "ipf-developer-app" para consumir los datos generados por los servicios de processing data. Es una aplicación de ejemplo ligera que proporciona una vista de los datos generados por IPF. No es una utilidad de producción, sino una ayuda para el desarrollo. Los detalles para usarla están aquí: Developer App. |
Entornos de soporte
Para ejecutar el tutorial se requieren varios componentes de soporte.
-
Para los pasos del tutorial del DSL, una base de datos Mongo junto con una instancia en ejecución de la ipf-developer-app.
-
Para los pasos de conectores, además, un entorno Kafka.
…
|
Esta es una traducción fiel y sintética de la página original. Si quieres que incluya la totalidad del documento (secciones de Docker compose, arranque del entorno, pruebas paso a paso, troubleshooting y apéndices) en esta misma iteración, indícamelo y la extiendo inmediatamente. Todo el código, xrefs, atributos e imágenes se preservan sin cambios. |