La Prueba Flogo es uno de los pasos principales en tu ciclo de vida CI/CD si estás usando TIBCO Flogo. Probablemente lo has hecho anteriormente en todos tus otros desarrollos como desarrollos en Java o incluso usando BusinessWorks 6 usando el bw6-maven-plugin:
GitHub – TIBCOSoftware/bw6-plugin-maven: Plug-in Code for Apache Maven and TIBCO ActiveMatrix BusinessWorks™
Plug-in Code for Apache Maven and TIBCO ActiveMatrix BusinessWorks™ – GitHub – TIBCOSoftware/bw6-plugin-maven: Plug-in Code for Apache Maven and TIBCO ActiveMatrix BusinessWorks™
Entonces, probablemente te estés preguntando… ¿Cómo se va a hacer esto con Flogo? ¡Ok! Te lo diré.
Primero que nada, necesitas tener en cuenta que Flogo Enterprise es un producto que fue diseñado con todos esos aspectos en mente, así que no necesitas preocuparte por ello.
En cuanto a las pruebas, cuando necesitamos incluirlas dentro de un enfoque de ciclo de vida CI/CD, estas capacidades de prueba deben cumplir con los siguientes requisitos:
Debe estar definido en algunos artefactos.
Debe ejecutarse automáticamente
Debe ser capaz de verificar el resultado.
Flogo Enterprise incluye por defecto capacidades de Prueba en la interfaz web donde no solo puedes probar tus flujos usando la interfaz desde una perspectiva de depuración/solución de problemas, sino que también puedes generar los artefactos que te permitirán realizar pruebas más sofisticadas
Entonces, necesitamos ir a nuestra interfaz web y cuando estemos dentro de un flujo tenemos un botón de “Iniciar Pruebas”:
Y podemos ver toda nuestra Configuración de Lanzamiento cambiar y la parte más importante para este tema es poder exportarla y descargarla a tu máquina local:
Una vez que todo está descargado y tenemos el binario para nuestra aplicación, podemos ejecutar las pruebas de manera automática desde la CLI usando el siguiente comando
Esto va a generar un archivo de salida con el resultado de la prueba de ejecución:
Y si abrimos el archivo obtendremos exactamente el mismo resultado que el flujo devuelve para que podamos realizar cualquier aserción sobre él
Eso fue fácil, ¿verdad? Hagamos algunos ajustes adicionales para evitar que necesites ir a la interfaz web. Puedes generar la configuración de lanzamiento usando solo la CLI.
Para hacer eso, solo necesitas ejecutar el siguiente comando:
OAuth 2.0 es un protocolo que permite a los usuarios autorizar a terceros a acceder a su información sin necesidad de conocer las credenciales del usuario. Generalmente, se basa en un sistema adicional que actúa como Proveedor de Identidad donde el usuario se va a autenticar, y una vez autenticado se le proporciona una pieza segura de información con los privilegios del usuario y puede usar esa pieza para autenticar sus solicitudes por un período de tiempo.
Muestra del Flujo de Autenticación OAuth v2.0
OAuth 2.0 también define una serie de flujos de concesión para adaptarse a diferentes necesidades de autenticación. Estas concesiones de autorización son las siguientes:
Credenciales del Cliente
Código de Autorización
Credenciales de Contraseña del Propietario del Recurso
La decisión de elegir un flujo u otro depende de las necesidades de la invocación y, por supuesto, es una decisión personal del cliente, pero de manera general, la aproximación mostrada en la documentación de Auth0 es la recomendación habitual:
Gráfico de Decisión para elegir la Concesión de Autorización a usar
Estas concesiones se basan en JSON Web Token para transmitir información entre las diferentes partes.
JWT
JSON Web Token es un estándar de la industria para la generación de tokens definido en el estándar RFC 7519. Define una forma segura de enviar información entre partes como un objeto JSON.
Está compuesto por tres componentes (Encabezado, Carga Útil y Firma) y puede ser utilizado por un cifrado simétrico o con un modo de intercambio de clave pública/privada usando RSA o ECDSA.
Muestra de Composición de JWT
Escenario de Caso de Uso
Entonces, OAuth V2 y JWT son la forma habitual de autenticar solicitudes en el mundo de los Microservicios, por lo que es importante tener este estándar soportado en tu marco de trabajo, y esto está perfectamente cubierto en Flogo Enterprise como vamos a ver en esta prueba.
Configuración de AWS Cognito
Vamos a usar AWS Cognito como el Servidor de Autorización, ya que es bastante fácil de configurar y es uno de los principales actores en este tipo de autenticación. En palabras de Amazon:
Amazon Cognito te permite agregar registro de usuarios, inicio de sesión y control de acceso a tus aplicaciones web y móviles de manera rápida y sencilla. Amazon Cognito escala a millones de usuarios y admite inicio de sesión con proveedores de identidad social, como Facebook, Google y Amazon, y proveedores de identidad empresarial a través de SAML 2.0.
En nuestro caso, vamos a hacer una configuración bastante sencilla y los pasos a continuación se muestran a continuación:
Crear un Grupo de Usuarios llamado “Flogo”
Crear un Cliente de Aplicación con un secreto generado llamado “TestApplication”
Crear un Servidor de Recursos llamado “Test” con identificador “http://flogo.test1” y con un alcance llamado “echo”
Configuración del Servidor de Recursos
Establecer la siguiente Configuración del Cliente de Aplicación como se muestra en la imagen a continuación con los siguientes detalles:
Grupo de Usuarios de Cognito seleccionado como Proveedor de Identidad Habilitado
Credenciales del cliente utilizadas como Flujos de OAuth Permitidos
http://flogo.test1/echo seleccionado como un alcance habilitado
Configuración del Cliente de Aplicación
Y eso es toda la configuración necesaria a nivel de Cognito, y ahora volvamos a la interfaz web de Flogo Enterprise.
Configuración de Flogo
Ahora, vamos a crear un Servicio REST y vamos a omitir todos los pasos sobre cómo crear un servicio REST usando Flogo, pero puedes echar un vistazo a los pasos detallados en el flujo a continuación:
Construyendo tu Primera Aplicación Flogo
En el anterior post, introducimos la tecnologión Flogo como una de las cosas en la industria des desarrollo cloud-nativo y ahora vamos a construir nuestra Primera Aplicación Flogo y trytaremos cubrir todas las copas que describimos en el anterior post. NOTE .- If you’ve new to Flogo and you didn’t read the previous post […]
Vamos a crear un servicio de eco alojado en localhost:9999/hello/ que recibe un parámetro de ruta después de hello que es el nombre que nos gustaría saludar, y vamos a establecer las siguientes restricciones:
Vamos a verificar la presencia de un Token JWT
Vamos a validar el Token JWT
Vamos a verificar que el JWT incluya el http://flogo.test1/echo
En caso de que todo esté bien, vamos a ejecutar el servicio, en caso de que no se cumpla algún requisito previo, vamos a devolver un error 401 No Autorizado.
Vamos a crear dos flujos:
Flujo principal que va a tener el Servicio REST
Subflujo para realizar todas las validaciones relacionadas con JWT.
El flujo principal es bastante sencillo, va a recibir la solicitud, ejecutar el subflujo y dependiendo de su salida va a ejecutar el servicio o no:
Entonces, toda la lógica importante está dentro del otro flujo que va a realizar toda la Validación JWT, y su estructura es la que se muestra a continuación:
Vamos a usar la actividad JWT alojada en GitHub disponible en el enlace que se muestra a continuación:
flogo-components/activity/jwt at master · ayh20/flogo-components
Contribute to ayh20/flogo-components development by creating an account on GitHub.
NOTA: Si no recuerdas cómo instalar una extensión de Flogo Enterprise, echa un vistazo al enlace a continuación:
Installing Extensions in Flogo Enterprise
In previous posts, we’ve talked about capabilities of Flogo and how to build our first Flogo application, so at this moment if you’ve read both of them you have a clear knowledge about what Flogo provides and how easy is to create applications in Flogo. But in those capabilities, we’ve spoken about that one of […]
Y después de eso, la configuración es bastante fácil, ya que la actividad te permite elegir la acción que deseas realizar con el token. En nuestro caso, “Verificar” y proporcionamos el token, el algoritmo (en nuestro caso “RS256”) y la clave pública que vamos a usar para validar la firma del token:
Prueba
Ahora, vamos a lanzar la Aplicación Flogo Enterprise desde el binario generado:
Y ahora, si intentamos hacer una ejecución al endpoint sin proporcionar ningún token obtenemos el código de respuesta 401 esperado
Entonces, para obtener el token de acceso, lo primero que necesitamos hacer es enviar una solicitud al endpoint de AWS Cognito (https://flogotest.auth.eu-west-2.amazoncognito.com/oauth2/token) usando nuestras credenciales de aplicación:
Y este token tiene toda la información del cliente y sus permisos, puedes verificarlo en la página web jwt.io:
Y para finalmente probarlo, solo necesitamos agregarlo a la primera solicitud que intentamos como podemos ver en la imagen a continuación:
Recursos
GitHub – alexandrev/flogo-jwt-sample-medium: JWT Support en Flogo Enterprise Post Resource
JWT Support in Flogo Enterprise Post Resource. Contribute to alexandrev/flogo-jwt-sample-medium development by creating an account on GitHub.
En publicaciones anteriores, hemos hablado mucho sobre todas las capacidades de TIBCO Flogo y cómo hacer diferentes tipos de cosas con Flogo, y un mensaje siempre se subrayó allí: rendimiento, rendimiento, rendimiento… pero ¿cómo se compara el rendimiento de Flogo con otros lenguajes de programación modernos?
Para poder compartir algunos datos reales, lo mejor que podemos hacer es realizar nuestra prueba. Para hacer nuestra prueba, vamos a comparar nuestro desarrollo en Flogo frente al mismo usando Python.
Podrías preguntar por qué estamos comparando desarrollos en Flogo y desarrollos en Python y la respuesta es muy simple. Python es ahora uno de los lenguajes más de moda, recientemente agregado como el tercer lenguaje principal en el Índice TIOBE y el lenguaje principal cuando hablamos de scripting de ciencia de datos:
Índice TIOBE que muestra a Python como el 3er lenguaje más usado
Escenario
Prueba 1
Nos gustaría probar ambas tecnologías, pero también ver cómo se comparan con la nueva realidad para microservicios y poder integrarse con Servicios en la Nube, y creemos que la mejor opción para esta prueba será usar Amazon S3 para poder ver cómo se desempeñan ambas tecnologías.
Entonces, vamos a subir archivos a Amazon S3 y ver cómo se desempeñan ambas tecnologías. Y seleccionamos las siguientes pruebas:
Archivo A: pequeño 138 KB. Número de iteraciones, 1, 10, 50.
Archivo B: mediano 7 MB. Número de iteraciones 1, 10, 50.
Archivo C: grande 50MB. Número de iteraciones 1, 10, 50.
Estamos usando el siguiente script de Python para probar la integración con S3:
import boto3
import time
import sys
import psutil
from botocore.exceptions import NoCredentialsError
Y vamos a usar la siguiente Aplicación Flogo (varios flujos para cada uno de los casos que nos gustaría verificar)
Prueba 2
Ahora, como esto va a ser para construir microservicios o aplicaciones en un mundo en la nube, veamos cómo se desempeñan ambos al hacer una simple API REST de Hello World. Para la parte de Python vamos a usar Flask para crear el servicio web y el siguiente fragmento:
from flask import Flask
app = Flask(__name__)
@app.route("/")
def hello():
return "¡Hola Mundo!"
if __name__ == '__main__':
app.run(debug=True)
NOTA: Mantenemos el debug=True para hacerlo equivalente al nivel de sistema INFO predeterminado en la Aplicación Flogo
Y para Flogo un simple REST Hello World como este:
Flogo Hello World REST API
Resultados y Conclusiones
Prueba 1
Estamos obteniendo los siguientes números como puedes ver en el gráfico a continuación:
Incluso en este ejemplo de código bastante simple, el rendimiento de la aplicación Flogo es demasiado increíble para compararse con otro lenguaje bien ejecutado como Python.
Estamos hablando de un promedio de más del 50% más rápido el desarrollo en Flogo frente al de Python, y aún más cuando el tamaño del archivo es pequeño y lo más importante es cómo el lenguaje y las plataformas están manejando las cosas porque el porcentaje de tiempo respecto al ancho de banda no es lo suficientemente grande como para hacer que todos los valores dependan de la conexión que tengas disponible en ese momento.
Si hablamos sobre el consumo de memoria, los datos son bastante estables para ambos lenguajes, lo cual es una muy buena señal de cómo se maneja la memoria para esas plataformas. Pero en esta batalla también gana Flogo porque si usamos el último, el más grande, Flogo es estable en 22,7 MB frente a 55 MB de Python, también más del 50% mejor una vez más.
Prueba 2
Para los resultados del servicio API REST son bastante similares a los de la primera PRUEBA, y estamos viendo los siguientes resultados respecto a TPS y tiempo de respuesta:
Transacciones por segundo API REST Python vs FlogoTiempo de Respuesta API REST Python vs Flogo
Como podemos ver, en primer lugar, el tiempo de respuesta siempre es menor desde la API de Flogo (y recuerda que esta es una prueba predeterminada, sin ajustes especiales o algo similar) y también el tiempo de respuesta se desempeña mejor en Flogo, siendo capaz de mantenerse estable casi hasta 4 hilos y luego ser capaz de controlar el aumento mientras que el servicio REST de Python después de 2 hilos el tiempo de respuesta aumenta más del doble con cada prueba.
Lo mismo ocurre con respecto a TPS, donde en el caso de Flogo todos los valores son mejores que el anterior. Por supuesto, se alcanza algún tipo de límite en 8 hilos, pero en el caso de Python esta raíz se alcanza en 2 hilos y después de ese punto todos los valores son peores que el anterior.
En cuanto a la memoria, el consumo es bastante similar al de la prueba anterior, ambas soluciones mantienen el uso de memoria bastante bajo y estable. En este caso, Python siempre es estable en 20.3 MB y Flogo comienza en 15 MB pero alcanza su pico en 21.8 y luego vuelve a 18.8 MB. Así que, como dije, son bastante similares en cuanto al uso de memoria en esta prueba.
Consumo de Memoria Flogo vs Python
Conclusiones
Entonces, la conclusión es clara, no importa cuán bien creas que tu lógica se está ejecutando en Python, deberías intentar hacerlo usando Flogo porque, en este tiempo donde cada MB y cada milisegundo cuenta para hacer más pequeña tu factura de Infraestructura, Flogo va a ser tu mejor herramienta para exprimir todo el poder de tu infraestructura.
Recursos
Puedes encontrar todo el código que he usado para estas pruebas en el repositorio de GitHub que se muestra a continuación:
GitHub – alexandrev/flogo-vs-python-medium
Contribute to alexandrev/flogo-vs-python-medium development by creating an account on GitHub.
Hemos cubierto los conceptos básicos del desarrollo de Flogo Enterprise en los artículos anteriores, pero hay un tema importante que no se ha discutido hasta ahora, y este es el manejo de errores de flogo. Siempre pensamos que todo va a funcionar como lo planeamos, y todo va a seguir el camino verde, pero la mayoría de las veces no es así, por lo que necesitas preparar tus flujos para estar listo para manejar estas situaciones.
Si estás acostumbrado al desarrollo de TIBCO BusinessWorks te vas a acostumbrar porque la mayoría de las formas de hacer las cosas son prácticamente las mismas, por lo que cualquier tipo de lógica que apliques a tus desarrollos se puede aplicar aquí. Cubramos primero los conceptos básicos.
Manejador de Errores
Un manejador de errores de flogo es la forma principal en que los desarrolladores de Flogo manejan los problemas que ocurren en el desarrollo y ha sido así para todas las versiones desde la primera hasta Flogo Enterprise 2.6.0 porque hasta ese momento era la única forma de hacerlo.
El manejador de errores es un flujo de errores diferente que se va a invocar cuando algo está mal, similar a un flujo de captura en el desarrollo de TIBCO BusinessWorks. Cuando haces clic en el botón de Manejador de Errores vas a entrar en un nuevo flujo con un iniciador predefinido llamado error como puedes ver en la imagen a continuación:
Los datos que van a iniciar este flujo son el nombre de la actividad que falló y el mensaje de falla, y luego puedes realizar cualquier lógica de manejo que necesites hacer hasta que el flujo sea devuelto. Las actividades que podrías usar y la lógica son exactamente las mismas que puedes usar en tu flujo principal.
Condición de Error
Desde Flogo Enterprise 2.6.0 se ha incluido una nueva forma de manejar errores, como dijimos hasta ese punto cualquier error genera una invocación del manejador de errores, pero esto no cubre todos los escenarios de uso cuando ocurre un error.
Como Flogo Enterprise comienza con un escenario de caso de uso de microservicio simple, el manejo de errores era suficiente para manejarlo, pero ahora, a medida que el poder y las características que Flogo proporciona han ido aumentando, se necesitan nuevos métodos para capturar y actuar cuando ocurre un error para cubrir estos nuevos escenarios. Entonces, ahora cuando creas una condición de rama puedes elegir tres opciones: Éxito, Éxito con Condición y Error.
Para hacer eso, solo necesitas hacer clic en el botón de motor que aparece en la creación de la rama desde la actividad que está generando el error:
Y podrías elegir una de las tres situaciones como puedes ver en la imagen a continuación:
Como las ramas son acumulativas, podemos tener una actividad con diferentes ramas de diferentes tipos:
Pero solo puedes agregar una rama de Tipo de Error para cada actividad, si intentas agregar otro campo se va a deshabilitar, por lo que no podrás hacerlo:
Actividad de Lanzar Error
Todo este contenido se ha centrado en cómo manejar errores cuando ocurren, pero también puedes necesitar lo contrario para poder detectar algo, hacer algunas verificaciones y decidir que esto debería manejarse como un error.
Para hacer eso tienes la Actividad de Lanzar Error donde puedes pasar los datos del error que deseas manejar en una interfaz de elemento de dos claves, una para el mensaje de error y otra para los datos del error, como puedes ver en la imagen a continuación:
La reutilización es una de las capacidades más importantes en el desarrollo de aplicaciones y esto es algo que se ha implementado tan bien en Flogo Enterprise que te vas a sorprender de lo genial que es. Echemos un vistazo a los Subflujos de Flogo
En Flogo no existe el concepto de Subflujo cuando creas una aplicación, solo puedes crear flujos. Si recuerdas, el flujo se creó basado en Disparadores y Acciones:
Entonces, ¿qué es un subflujo en Flogo? Un flujo sin los disparadores. Así de simple. Entonces, ¿significa que necesito crear un nuevo flujo, pero eliminando cualquier disparador o usando un disparador especial para que esto pueda ser reutilizado en un flujo diferente? No. No es necesario.
Cualquier flujo puede ser reutilizado como subflujos tal cual. Solo cambia cuando lo invocas como un subflujo, los disparadores no se van a ejecutar. Así de simple. Así que sí, puedes reutilizar cualquier flujo que hayas creado sin hacer nada en absoluto. Veamos cómo
Recuerda la aplicación que creamos en el post anterior sobre GraphQL:
Tenemos un flujo llamado Mutation_asignUser donde necesitamos recopilar la información del usuario y la empresa, lo mismo que ya estábamos haciendo en los siguientes flujos Query_currentUser y Query_company. Entonces, ¿qué tan fácil es reutilizarlos? Echemos un vistazo a Mutation_asignUser con más detalle:
Mutation_asignUser con uso de subflujos resaltado
En las actividades con el cuadro rojo alrededor es donde estamos llamando a nuestros “subflujos” y esto es tan fácil como incluir una actividad llamada “Iniciar un SubFlujo”
Esta actividad va a pedir el flujo, que podría ser cualquier flujo que tengas en tu aplicación (no se pueden incluir flujos de otras aplicaciones como subflujo)
Y una vez que selecciones el flujo, la entrada y salida se van a completar basándose en la interfaz del flujo. Muy fácil, ¿verdad?
¡Vamos a hackearlo! y empezar a crear más aplicaciones Flogo!!!!
El mes pasado, durante el KubeCon 2019 Europa en Barcelona, OpenTracing anunció su fusión con el proyecto OpenCensus para crear un nuevo estándar llamado OpenTelemetry que estará disponible en septiembre de 2019.
OpenTracing, OpenCensus Merge into a Single New Project, OpenTelemetry - The New Stack
Two open source projects that have been instrumental in providing metrics for cloud native operations have merged into a single project. The fusion of Google’s OpenCensus and the Cloud Native Computing Foundation’s OpenTracing will be known as OpenTelemetry, and will be managed by the CNCF. The idea…
Entonces, creo que sería increíble echar un vistazo a las capacidades relacionadas con OpenTracing que tenemos disponibles en TIBCO BusinessWorks Container Edition.
El mundo de hoy es demasiado complejo en términos de cómo se definen y gestionan nuestras arquitecturas. Nuevos conceptos en los últimos años como contenedores, microservicios, malla de servicios, nos dan la opción de alcanzar un nuevo nivel de flexibilidad, rendimiento y productividad, pero también viene con un costo de gestión con el que necesitamos lidiar.
Hace años, las arquitecturas eran más simples, el servicio era un concepto que estaba comenzando, pero incluso entonces comenzaron a surgir algunos problemas relacionados con el monitoreo, rastreo, registro, etc. Entonces, en esos días todo se resolvía con un Marco de Desarrollo que todos nuestros servicios iban a incluir porque todos nuestros servicios eran desarrollados por el mismo equipo, la misma tecnología, y en ese marco, podíamos asegurarnos de que las cosas se manejaban correctamente.
Ahora, confiamos en estándares para hacer este tipo de cosas, y por ejemplo, para el rastreo, confiamos en OpenTracing. No quiero pasar tiempo hablando sobre qué es OpenTracing, donde tienen una cuenta completa en Medium hablando ellos mismos mucho mejor de lo que yo podría hacerlo, así que por favor tómate unos minutos para leer sobre ello.
Distributed Tracing in 10 Minutes
With the intrinsic concurrency and asynchrony of modern software applications, distributed tracing has become part of the table stakes for effective monitoring. That said, instrumenting a system for…
La única declaración que quiero hacer aquí es la siguiente:
El rastreo no es registro, y por favor asegúrate de entender eso.
El rastreo se trata de muestreo, es como cómo se están desempeñando los flujos y si todo está funcionando, pero no se trata de si una solicitud específica se ha realizado bien para el ID de cliente que sea… eso es registro, no rastreo.
Así que OpenTracing y sus diferentes implementaciones como Jaeger o Zipkin son la forma en que podemos implementar el rastreo hoy de una manera realmente fácil, y esto no es algo que solo podrías hacer en tu lenguaje de desarrollo basado en código, puedes hacerlo con nuestras herramientas sin código para desarrollar aplicaciones nativas de la nube como TIBCO BusinessWorks Container Edition y eso es lo que me gustaría mostrarte hoy. Así que, que comience el partido…
Lo primero que me gustaría hacer es mostrarte el escenario que vamos a implementar, y este va a ser el que se muestra en la imagen a continuación:
Vas a tener dos servicios REST que se van a llamar entre sí, y vamos a exportar todos los rastros al componente externo Jaeger y luego podemos usar su interfaz para analizar el flujo de una manera gráfica y fácil.
Entonces, lo primero que necesitamos hacer es desarrollar los servicios que, como puedes ver en las imágenes a continuación, van a ser bastante fáciles porque este no es el propósito principal de nuestro escenario.
Una vez que tengamos nuestras imágenes de Docker basadas en esas aplicaciones, podemos comenzar, pero antes de lanzar nuestras aplicaciones, necesitamos lanzar nuestro sistema Jaeger, puedes leer toda la información sobre cómo hacerlo en el enlace a continuación:
Getting started
Get up and running with Jaeger in your local environment
Pero al final solo necesitamos ejecutar el siguiente comando:
Y ahora, estamos listos para lanzar nuestras aplicaciones y lo único que necesitamos hacer en nuestros desarrollos, porque como pudiste ver no hicimos nada extraño en nuestro desarrollo y fue bastante sencillo, es agregar las siguientes variables de entorno cuando lancemos nuestro contenedor
Y… eso es todo, lanzamos nuestros contenedores con los siguientes comandos y esperamos hasta que las aplicaciones estén en funcionamiento
docker run -ti -p 5000:5000 — name provider -e BW_PROFILE=Docker -e PROVIDER_PORT=5000 -e BW_LOGLEVEL=ERROR — link jaeger -e BW_JAVA_OPTS=”-Dbw.engine.opentracing.enable=true” -e JAEGER_AGENT_HOST=jaeger -e JAEGER_AGENT_PORT=6831 -e JAEGER_SAMPLER_MANAGER_HOST_PORT=jaeger:5778 provider:1.0
docker run — name consumer -ti -p 6000:6000 -e BW_PROFILE=Docker — link jaeger — link provider -e BW_JAVA_OPTS=”-Dbw.engine.opentracing.enable=true” -e JAEGER_AGENT_HOST=jaeger -e JAEGER_AGENT_PORT=6831 -e JAEGER_SAMPLER_MANAGER_HOST_PORT=jaeger:5778 -e CONSUMER_PORT=6000 -e PROVIDER_HOST=provider consumer:1.0
Una vez que estén en funcionamiento, ¡generemos algunas solicitudes! Para hacer eso, voy a usar un proyecto SOAPUI para generar una carga estable durante 60 segundos, como puedes ver en la imagen a continuación:
Y ahora vamos a ir a la siguiente URL para ver la interfaz de Jaeger y podemos ver lo siguiente tan pronto como hagas clic en el botón de búsqueda
Y luego, si hacemos zoom en algún rastro específico:
Eso es bastante asombroso, pero eso no es todo, porque puedes ver si buscas en la interfaz sobre los datos de estos rastros, puedes ver datos técnicos de tus flujos de BusinessWorks Container Edition, como puedes ver en la imagen a continuación:
Pero… ¿qué pasa si quieres agregar tus etiquetas personalizadas a esos rastros? ¡También puedes hacerlo! Déjame explicarte cómo.
Desde BusinessWorks Container Edition 2.4.4 vas a encontrar una nueva pestaña en todas tus actividades llamada «Etiquetas» donde puedes agregar las etiquetas personalizadas que deseas que esta actividad incluya, por ejemplo, un id personalizado que se va a propagar a través de todo el proceso, podemos definirlo como puedes ver aquí.
Y si echas un vistazo a los datos que tenemos en el sistema, puedes ver que todos estos rastros tienen estos datos:
Puedes echar un vistazo al código en el siguiente repositorio de GitHub:
GitHub - alexandrev/bwce-opentracing-customtags
Contribute to alexandrev/bwce-opentracing-customtags development by creating an account on GitHub.
Con el reciente lanzamiento de Flogo Enterprise 2.6 (tómese su tiempo para revisar las notas de la versión y conocer todas las novedades que se han lanzado), se ha incluido soporte para GraphQL. No quiero hacer un artículo completo sobre qué es GraphQL y las ventajas que incluye en comparación con REST y demás. Especialmente cuando hay tantos artículos en Medium sobre ese tema, así que por favor eche un vistazo a los siguientes:
A Beginner’s Guide to GraphQL
One of the most commonly discussed terms today is the API. A lot of people don’t know exactly what an API is. Basically, API stands for…
Entonces, en resumen, GraphQL es un protocolo diferente para definir las interfaces de su API con otro enfoque en mente. Así que, veamos cómo podemos incluir este tipo de interfaces en nuestros flujos de Flogo. Vamos a trabajar con el siguiente esquema de GraphQL que va a definir nuestra API Si esta es la primera vez que ves un esquema de GraphQL, permíteme darte algunas aclaraciones:
El esquema se divide en tres partes: Consultas, Mutaciones y Modelo
Las consultas son solicitudes de tipo GET para obtener información. En nuestro caso, tenemos dos consultas currentUser y company.
Las mutaciones son solicitudes de tipo POST/PUT para modificar información. En nuestro caso, tenemos tres mutaciones: registerUser, registerCompany, asignUser.
El modelo son los diferentes objetos y tipos con los que interactúan nuestras consultas y mutaciones.
Así que, ahora vamos a hacer el trabajo duro en el entorno de Flogo, y comenzamos creando una nueva aplicación que vamos a llamar GraphQL_Sample_1Formulario de creación de la nueva aplicación llamada GraphQL_Sample_V1 Ahora, tenemos una aplicación vacía. Hasta este punto no fue difícil, ¿verdad? Bien, veamos cómo va. Ahora vamos a crear un nuevo flujo, y podemos elegir entre tres opciones:
Flujo vacío
Especificación Swagger
Esquema GraphQL
Así que elegimos la opción del Esquema GraphQL y subimos el archivo y genera un esqueleto de todos los flujos necesarios para soportar esta especificación. Se va a generar un nuevo flujo para cada una de las consultas y cada una de las mutaciones que hemos definido, ya que tenemos dos (2) consultas y tres (3) mutaciones, por lo que cinco (5) flujos en total como puedes ver en la imagen a continuación:Flujos autogenerados basados en el esquema de GraphQL Como puedes ver, los flujos se han generado siguiendo la siguiente convención de nombres:
<TIPO>_<nombre>
Donde <TIPO> puede ser Mutación o Consulta y <nombre> es el nombre que este componente tiene en el Esquema de GraphQL. Ahora, todo está hecho con respecto a la parte de GraphQL, y solo necesitamos proporcionar contenido a cada uno de los flujos. En este ejemplo, voy a confiar en una base de datos PostgreSQL para almacenar toda la información sobre usuarios y empresas, pero el contenido va a ser muy sencillo.
Query_currentUser: Este flujo va a solicitar los datos del cliente a PostgreSQL para devolver sus datos y la empresa a la que pertenece. En caso de que no pertenezca a nadie, solo recopilamos los datos del usuario y en caso de que no esté presente, devolvemos un objeto vacío.
Flujo Query_currentUser
Query_company: Este flujo va a solicitar los datos de la empresa a PostgreSQL para devolverlos y en caso de que no esté presente, devolver un objeto vacío.
Mutation_registerUser: Este flujo va a insertar un usuario en la base de datos y en caso de que su correo ya exista, va a devolver los datos existentes al consumidor.
Mutation_registerCompany: Este flujo va a insertar una empresa en la base de datos y en caso de que su nombre ya exista, va a devolver los datos existentes al consumidor.
Mutation_asignUser: Este flujo va a asignar un usuario a la empresa para hacer eso, va a devolver los datos del usuario basados en su correo electrónico y lo mismo con la empresa y actualizar las actividades de PostgreSQL basadas en esa situación.
Bien, ahora tenemos nuestra aplicación ya construida, veamos cómo podemos probarla y jugar con la API de GraphQL que hemos construido. ¡Así que… es hora del espectáculo!Foto de Yvette de Wit en Unsplash Primero, vamos a construir la aplicación. Como probablemente sepas, puedes elegir entre diferentes tipos de construcciones: imagen de Docker o paquete basado en el sistema operativo. En mi caso, voy a generar una construcción para Windows para facilitar todo el proceso, pero puedes elegir lo que te parezca mejor. Para hacer eso, vamos al menú de la aplicación y hacemos clic en Construir y elegimos la opción de Windows:Opción de construcción para Windows Y una vez que la construcción se haya completado, vamos a tener un nuevo archivo EXE en nuestra carpeta de Descargas. ¡Sí, así de fácil! Y ahora, ¿cómo lanzarlo? Aún más fácil… solo ejecuta el archivo EXE y… ¡está hecho!Aplicación Flogo de GraphQL ejecutándose en la consola de Windows Como puedes ver en la imagen de arriba, estamos escuchando solicitudes en el puerto 7879 en la ruta /graphql. ¡Así que, abramos un cliente de Postman y comencemos a enviar solicitudes! Y vamos a comenzar con las consultas y para poder devolver datos, he insertado en la base de datos un registro de muestra con el correo test@test.com, así que, si ahora intento recuperarlo, puedo hacer esto:
Ejecución de Postman de GraphQL Solo algunos aspectos destacados sobre nuestra consulta de GraphQL:
Podemos elegir la cantidad de atributos que la consulta va a recuperar, y esa es la última parte de la consulta, así que si la cambio, veamos qué pasa:
En publicaciones anteriores, hemos hablado sobre las capacidades de Flogo y cómo construir nuestra primera aplicación Flogo, así que en este momento, si has leído ambos, tienes un conocimiento claro sobre lo que Flogo ofrece y lo fácil que es crear aplicaciones en Flogo.
Pero en esas capacidades, hemos hablado de que una de las fortalezas de Flogo es lo fácil que es extender las capacidades predeterminadas que Flogo ofrece. Las Extensiones de Flogo permiten aumentar las capacidades de integración del producto así como las capacidades de cómputo y se construyen usando Go. Puedes crear diferentes tipos de extensiones:
Disparadores: Mecanismo para activar un flujo de Flogo (generalmente conocidos como Iniciadores)
Actividades/Acciones: Lógica de implementación que puedes usar dentro de tus flujos de Flogo.
Existen diferentes tipos de extensiones dependiendo de cómo se proporcionan y el alcance que tienen.
Conectores Empresariales de TIBCO Flogo: Estos son los conectores proporcionados directamente por TIBCO Software para los clientes que están usando TIBCO Flogo Enterprise. Se lanzan usando TIBCO eDelivery como todos los demás productos y componentes de TIBCO.
Extensiones de Código Abierto de Flogo: Estas son las extensiones desarrolladas por la Comunidad y que generalmente se almacenan en repositorios de GitHub o cualquier otro sistema de control de versiones que esté públicamente disponible.
Extensiones Personalizadas de TIBCO Flogo Enterprise: Estas son las extensiones equivalentes a las Extensiones de Código Abierto de Flogo pero construidas para ser usadas en TIBCO Flogo Enterprise o TIBCO Cloud Integration (iPaaS de TIBCO) y que siguen los requisitos definidos por la Documentación de Flogo Enterprise y proporcionan un poco más de opciones de configuración sobre cómo se muestra esto en la interfaz de usuario.
Instalación usando la Interfaz Web de TIBCO
Vamos a cubrir en este artículo cómo trabajar con todos ellos en nuestro entorno y vas a ver que el procedimiento es prácticamente el mismo, pero la principal diferencia es cómo obtener el objeto desplegable.
Necesitamos instalar alguna extensión y para nuestro caso, vamos a usar ambos tipos de extensiones posibles: Un conector proporcionado por TIBCO para conectar a GitHub y una actividad de código abierto construida por la comunidad para gestionar las operaciones de archivos.
Primero, vamos a comenzar con el conector de GitHub y vamos a usar el Conector de Flogo para GitHub, que se va a descargar a través de TIBCO eDelivery como lo hiciste con Flogo Enterprise. Una vez que tengas el archivo ZIP, necesitas agregarlo a tu instalación y para hacer eso, vamos a ir a la página de Extensiones
Y vamos a hacer clic en Subir y proporcionar el archivo ZIP que hemos descargado con el conector de GitHub
Hacemos clic en el botón «Subir y compilar» y esperamos hasta que el proceso de compilación termine y después de eso, deberíamos notar que tenemos un disparador adicional disponible como puedes ver en la imagen a continuación:
Así que, ya tenemos nuestro disparador de GitHub, pero necesitamos nuestras actividades de Archivo y ahora vamos a hacer el mismo ejercicio pero con un conector diferente. En este caso, vamos a usar una actividad de código abierto que está alojada en el repositorio de GitHub de Leon Stigter. Y vamos a descargar el repositorio completo de flogo-components y subir ese archivo ZIP a la página de Extensiones como lo hicimos antes:
Vamos a extraer el repositorio completo e ir a la ruta de actividad y generar un archivo zip desde la carpeta llamada «writetofile» y ese es el archivo ZIP que vamos a subir a nuestra página de Extensiones:
La estructura del repositorio es prácticamente la misma para todos estos tipos de repositorios de código abierto, generalmente tienen el nombre flogo-components y dentro tienen dos carpetas principales:
actividad: Carpeta que agrupa todas las diferentes actividades que están disponibles en este repositorio.
disparador: Carpeta que agrupa todos los diferentes disparadores que están disponibles en este repositorio.
Cada una de estas carpetas va a tener una carpeta para cada una de las actividades y disparadores que se están implementando en este repositorio como puedes ver en la imagen a continuación:
Y cada una de ellas va a tener la misma estructura:
activity.json: Que va a describir el modelo de la actividad (nombre, descripción, autor, configuraciones de entrada, configuraciones de salida)
activity.go: Contiene todo el código de programación en Go para construir la capacidad que la actividad expone.
activity_test.go: Contiene todas las pruebas que la actividad debe tener listas para ser usadas por otros desarrolladores y usuarios.
NOTA: Las extensiones para TIBCO Flogo Enterprise tienen un archivo adicional llamado activity.ts que es un archivo TypeScript que define las validaciones de la interfaz de usuario que se deben realizar para la actividad.
Y una vez que tengamos el archivo, podemos subirlo de la misma manera que lo hicimos con la extensión anterior.
Usando CLI para Instalar
Además, si estamos usando el CLI de Flogo, aún podemos instalarlo usando directamente la URL a la carpeta de actividad sin necesidad de proporcionar el archivo zip. Para hacer eso, necesitamos habilitar el Administrador de Instalación usando el siguiente comando:
<FLOGO_HOME>/tools/installmgr.bat
Y eso va a construir una imagen de Docker que representa una herramienta CLI con los siguientes comandos:
Menú de uso del Administrador de Instalación
Instalar: Instalar Flogo Enterprise, Conectores de Flogo, Servicios, etc. en el directorio de instalación actual.
Desinstalar: Desinstalar Flogo Enterprise, Conectores de Flogo, Servicios del directorio de instalación actual.
Instalación del Conector de TIBCO usando el CLI del Administrador de Instalación
Y este proceso se puede usar con un Conector oficial así como con una Extensión OSS
Instalación de Extensión OSS usando el CLI del Administrador de Instalación
Las sondas son cómo podemos decirle a Kubernetes que todo dentro del pod está funcionando como se espera. Kubernetes no tiene forma de saber qué está sucediendo dentro a nivel detallado y no tiene forma de saber para cada contenedor si está saludable o no, por eso necesitan ayuda del propio contenedor.
Imagina que eres el controlador de Kubernetes y tienes como ocho pods diferentes, uno con una aplicación por lotes de Java, otro con alguna instancia de Redis, otro con una aplicación de nodejs, otro con un microservicio de Flogo (Nota: ¿Aún no has oído hablar de TIBCO Flogo? Tómate unos minutos para conocer una de las próximas novedades que puedes usar ahora para construir tus aplicaciones nativas en la nube), otro con una base de datos Oracle, otro con algún servidor web jetty y finalmente otro con una aplicación de BusinessWorks Container Edition. ¿Cómo puedes saber que cada componente está funcionando bien?
Primero, puedes pensar que puedes hacerlo con el componente de punto de entrada de tu Dockerfile ya que solo especificas un comando para ejecutar dentro de cada contenedor, así que verifica si ese proceso está en ejecución, ¿y eso significa que todo está saludable? Ok… bastante justo…
Pero, ¿esto es siempre cierto? ¿Un proceso en ejecución a nivel de SO/contenedor significa que todo está funcionando bien? Pensemos en la base de datos Oracle por un minuto, imagina que tienes un problema con la memoria compartida y se mantiene en un estado de inicialización para siempre, K8S va a verificar el comando, va a encontrar que está en ejecución y le dice a todo el clúster: ¡Ok! ¡No te preocupes! La base de datos está funcionando perfectamente, ¡adelante y envía tus consultas a ella!
Esto podría suceder con componentes similares como un servidor web o incluso con una aplicación en sí, pero es muy común cuando tienes servidores que pueden manejar implementaciones en él, como BusinessWorks Container Edition en sí. Y por eso esto es muy importante para nosotros como desarrolladores e incluso más importante para nosotros como administradores. ¡Así que empecemos!
Lo primero que vamos a hacer es construir una aplicación de BusinessWorks Container Edition, como este no es el propósito principal de este artículo, vamos a usar las mismas que he creado para la Integración de BusinessWorks Container Edition — Istio que puedes encontrar aquí.
Entonces, esta es una aplicación bastante simple que expone un servicio web SOAP. Todas las aplicaciones en BusinessWorks Container Edition (así como en BusinessWorks Enterprise Edition) tienen su propio estado, por lo que puedes preguntarles si están en ejecución o no, eso es algo que el «motor» interno de BusinessWorks Container (NOTA: Vamos a usar la palabra motor para simplificar cuando hablamos de los internos de BWCE. En detalle, el componente que conoce el estado de la aplicación es el AppNode interno que inicia el contenedor, pero mantengámoslo simple por ahora)
Sondas de Kubernetes
En Kubernetes, existe el concepto de «sonda» para realizar verificaciones de salud a tu contenedor. Esto se realiza configurando sondas de vivacidad o sondas de preparación.
Sonda de vivacidad: Kubernetes utiliza sondas de vivacidad para saber cuándo reiniciar un contenedor. Por ejemplo, las sondas de vivacidad podrían detectar un bloqueo, donde una aplicación está en ejecución, pero no puede avanzar.
Sonda de preparación: Kubernetes utiliza sondas de preparación para saber cuándo un contenedor está listo para comenzar a aceptar tráfico. Un pod se considera listo cuando todos sus contenedores están listos. Un uso de esta señal es controlar qué pods se utilizan como backends para los servicios. Cuando un pod no está listo, se elimina del balance de carga del servicio
Incluso cuando hay dos tipos de sondas para BusinessWorks Container Edition, ambas se manejan de la misma manera, la idea es la siguiente: Mientras la aplicación esté en ejecución, puedes comenzar a enviar tráfico y cuando no esté en ejecución necesitamos reiniciar el contenedor, por lo que eso lo hace más simple para nosotros.
Implementación de Sondas
Cada aplicación de BusinessWorks Container Edition que se inicia tiene una forma predeterminada de saber si está saludable o no. Esto se hace mediante un endpoint especial publicado por el propio motor:
http://localhost:7777/_ping/
Entonces, si tenemos una aplicación normal de BusinessWorks Container Edition desplegada en nuestro clúster de Kubernetes como la que teníamos para la integración de Istio, tenemos registros similares a estos:
Trazas de inicio de una aplicación de BusinessWorks Container Edition
Como puedes ver, los registros dicen que la aplicación está iniciada. Entonces, como no podemos lanzar una solicitud curl desde dentro del contenedor (ya que no hemos expuesto el puerto 7777 al exterior aún y curl no está instalado en la imagen base), lo primero que vamos a hacer es exponerlo al resto del clúster.
Para hacer eso, cambiamos nuestro archivo Deployment.yml que hemos usado a este:
Archivo Deployment.yml con el puerto 7777 expuesto
Ahora, podemos ir a cualquier contenedor en el clúster que tenga «curl» instalado o cualquier otra forma de lanzar una solicitud como esta con el código HTTP 200 y el mensaje «La aplicación está en ejecución».
Ejecución exitosa del endpoint _ping
NOTA: Si olvidas la última / e intentas invocar _ping en lugar de _ping/ vas a obtener un código HTTP 302 Found con la ubicación final como puedes ver aquí:
Ejecución del código HTTP 302 apuntando a _ping en lugar de _ping/
Ok, veamos qué pasa si ahora detenemos la aplicación. Para hacer eso vamos a entrar en el contenedor y usar la consola OSGi.
Para hacer eso, una vez que estés dentro del contenedor, ejecutas el siguiente comando:
ssh -p 1122 equinox@localhost
Va a pedir credenciales y usa la contraseña predeterminada ‘equinox’. Después de eso, te dará la oportunidad de crear un nuevo usuario y puedes usar las credenciales que te funcionen. En mi ejemplo, voy a usar admin / adminadmin (NOTA: La longitud mínima para una contraseña es de ocho (8) caracteres.
Si ejecutamos frwk:la va a mostrar las aplicaciones desplegadas, en nuestro caso la única, como debería ser en la aplicación de BusinessWorks Container Edition:
Para detenerla, vamos a ejecutar el siguiente comando para listar todos los paquetes OSGi que tenemos en este momento en ejecución en el sistema:
frwk:lb
Ahora, encontramos los paquetes que pertenecen a nuestra aplicación (al menos dos paquetes (1 por módulo BW y otro para la aplicación)
Mostrando paquetes dentro de la aplicación BusinessWorks Container
Y ahora podemos detenerlo usando felix:stop <ID>, así que en mi caso, necesito ejecutar los siguientes comandos:
stop “603”
stop “604”
Comandos para detener los paquetes que pertenecen a la aplicación
Y ahora la aplicación está detenida
Consola OSGi mostrando la aplicación como Detenida
Entonces, si ahora intentamos lanzar el mismo comando curl que ejecutamos antes, obtenemos la siguiente salida:
Ejecución fallida del endpoint ping cuando la aplicación está detenida
Como puedes ver, un error HTTP 500 que significa que algo no está bien. Si ahora intentamos iniciar nuevamente la aplicación usando el comando de inicio de paquete (equivalente al comando de detención de paquete que usamos antes) para ambos paquetes de la aplicación, verás que la aplicación dice que está en ejecución nuevamente:
Y el comando tiene la salida HTTP 200 como debería tener y el mensaje «La aplicación está en ejecución»
Entonces, ahora, después de saber cómo funciona el endpoint _ping/ solo necesitamos agregarlo a nuestro archivo deployment.yml de Kubernetes. Así que modificamos nuevamente nuestro archivo de implementación para que sea algo como esto:
NOTA: Es bastante importante la presencia del parámetro initialDelaySeconds para asegurarse de que la aplicación tenga la opción de iniciarse antes de comenzar a ejecutar la sonda. En caso de que no pongas este valor, puedes obtener un bucle de reinicio en tu contenedor.
NOTA: El ejemplo muestra el puerto 7777 como un puerto exportado, pero esto solo es necesario para los pasos que hemos hecho antes y no será necesario en un entorno de producción real.
Así que ahora desplegamos nuevamente el archivo YML y una vez que tengamos la aplicación en ejecución, vamos a intentar el mismo enfoque, pero ahora como tenemos las sondas definidas tan pronto como detenga la aplicación, los contenedores se reiniciarán. ¡Veamos!
Como puedes ver en la imagen de arriba, después de que la aplicación se detiene, el contenedor se ha reiniciado y debido a eso, hemos sido expulsados de dentro del contenedor.
Así que eso es todo, espero que te ayude a configurar tus sondas y en caso de que necesites más detalles, por favor echa un vistazo a la documentación de Kubernetes sobre sondas httpGet para ver toda la configuración y opciones que puedes aplicarles.
En la publicación anterior, presentamos la tecnología Flogo como una de las cosas en la industria del desarrollo nativo en la nube y ahora vamos a construir nuestra primera aplicación Flogo e intentar cubrir todas las opciones que describimos en la publicación anterior.
NOTA .- Si eres nuevo en Flogo y no leíste la publicación anterior sobre las capacidades de Flogo, por favor tómate unos minutos para leerla antes de continuar.
TIBCO Flogo Introduction
Flogo is the next new thing in the developing applications in a cloud-native way. Since its foundation has been designed to cover all the new challenges that we need to face when dealing with new cloud-native development. So, please, if you or your enterprise is starting its movement to the cloud it’s the moment to […]
Primero que nada, me gustaría presentar el escenario, este va a ser un escenario simple que muestra de la manera más sencilla los conceptos dentro de una aplicación Flogo, así que vamos a crear una aplicación Hola Mundo que va a ser expuesta usando el protocolo HTTP/JSON para comunicarse. Así que, el escenario va a ser como la imagen mostrada a continuación:
Entonces, lo primero que necesitamos hacer es lanzar la interfaz web de Flogo, así que vamos a nuestra carpeta donde tenemos nuestra instalación de TIBCO Flogo Enterprise y ejecutamos el comando desde el directorio bin
./run-studio.bat
Ahora, podemos ir a la ubicación http://localhost:8090 y vemos algo similar a esto:
Ahora, vamos a crear nuestra primera aplicación, así que hacemos clic en el botón “Crear” y proporcionamos un nombre para la aplicación, en nuestro caso la vamos a llamar “HelloWorldREST”
Ahora, entraremos en la página principal de una aplicación que es la que se muestra a continuación:
Es importante notar que los servicios Flogo se basan en flujos, por lo que puedes crear uno o más flujos que van a orquestar la lógica que necesitas implementar. Así que, lo primero que necesitamos hacer es crear un flujo, y lo vamos a hacer haciendo clic en el botón “Crear un flujo” y proporcionar un nombre para el flujo, en nuestro caso, como esta va a ser una aplicación simple, vamos a usar “main” como nombre del flujo que vamos a crear:
Y se te llevará al lienzo vacío de tu nuevo flujo “main”:
Hay dos conceptos importantes en un flujo Flogo:
Disparador: Esta es la forma en que este flujo va a ser iniciado, hay varias maneras de iniciar un flujo Flogo, por ejemplo, con una solicitud HTTP o un temporizador, o una fuente de eventos AWS Lambda, un tema de Kafka o un mensaje MQTT, etc. Puedes tener uno o más disparadores en tu aplicación y deberías tener uno si este es un flujo principal (en lugar de un subflujo que discutiremos en una publicación diferente). Los disparadores se muestran a la izquierda del lienzo como pequeños iconos cuadrados como puedes ver en la imagen a continuación:
Actividades: Son las que van a decidir qué lógica se va a ejecutar. Cada actividad tiene una acción que realizar que podría ser una interna como un registro de trazas o una externa como invocar un servicio REST o algo similar, y vamos a usar el resto del lienzo para construir el flujo lógico.
Entonces, lo primero que necesitamos hacer es configurar el Disparador de este flujo, y para hacer eso hacemos clic en el icono de más en el área de Disparadores y seleccionamos el disparador HTTP REST:
Y lo vamos a configurar como la imagen mostrada a continuación:
Método: GET
Ruta del recurso: /hello/{name}
Y hacemos clic en Continuar y en la siguiente ventana seleccionamos “Copiar Esquema”, para copiar el Esquema de Salida del Disparador al Esquema de Entrada del Flujo. Ahora, hemos añadido el disparador pero necesitamos configurar cómo se van a transferir los datos a las actividades del flujo. Para hacer esto, hacemos clic en la “Configuración del Disparador” porque necesitamos mapear los datos del disparador a la entrada del flujo, así que en caso de que tengamos más de un disparador podemos tener diferentes mapeos de cada uno de los disparadores a la entrada del flujo.
Ahora, vamos a la pestaña de Salida y seleccionamos “name” bajo el objeto pathParams y lo mapeamos al mismo atributo (name bajo pathParams del objeto $trigger).
Así que ahora este nombre va a ser transferido a la entrada del flujo y podemos usarlo en la lógica del flujo. Ahora es el momento de construir la lógica del flujo. En este caso va a ser muy fácil, ya que ya tenemos una actividad de retorno que se añade por defecto, solo vamos a añadir una actividad de Registro para imprimir los nombres que estamos recibiendo.
Para hacer eso hacemos clic en el botón de más en el lienzo y seleccionamos dentro de la Sección General la actividad Registrar Mensaje:
Y necesitamos configurarlo como muestra la imagen a continuación:
Así que, hacemos clic en la sección de Entrada y en este caso la actividad por defecto solo tiene un parámetro llamado “mensaje” que es el mensaje de registro que se va a imprimir, y creamos una estructura basada en la concatenación de un valor constante “Recibe solicitud con nombre: “ y el nombre que fue previamente mapeado en la configuración del disparador.
Como puedes ver, siempre tienes visibles todas las funciones que tienes disponibles agrupadas en diferentes categorías y también todos los datos de la tubería que puedes usar que están siendo generados por la ejecución de todas las actividades dentro del flujo
Así que, lo último que necesitamos hacer es configurar la actividad de retorno. Para hacer eso hacemos clic en la actividad de retorno y mapeamos los atributos código (a constante 200) y mensaje a la estructura mostrada a continuación:
Y eso es todo. Estamos listos. Así que ahora podemos comenzar a probar el servicio simple que hemos creado. Para hacer eso, Flogo Studio proporciona un Motor de Pruebas capaz de verificar que la lógica que has construido está funcionando bien. Este Motor de Pruebas va a probar la lógica del flujo, no los disparadores, así que comienza desde la primera actividad y no incluye la interacción con el disparador.
Para hacer eso solo necesitas hacer clic en el botón Iniciar Pruebas y proporcionar valores de entrada a tu flujo.
En nuestro caso, como la mayor parte de la lógica se basa en el disparador, no tiene sentido hacer ese paso, pero volveremos al Motor de Pruebas en próximas publicaciones sobre el Desarrollo Flogo. Así que, en lugar de hacer eso, vamos a construir el servicio directamente. Para hacer eso salimos del lienzo del flujo y volvemos a la página principal de la aplicación y vamos a hacer clic en el botón Construir y seleccionar la arquitectura que vas a usar para probar tu aplicación, en mi caso será Windows
Y eso va a generar un archivo ejecutable, en mi caso una aplicación EXE que tiene mi lógica que solo necesitamos ejecutar para ejecutar nuestro servicio
Así que, ahora, lo lanzamos y obtendremos una salida similar a esta:
Para probar la aplicación vamos a abrir una nueva pestaña en nuestro navegador y escribir la siguiente URL:
