Descubrimiento de servicios de Kubernetes para Prometheus

Descubrimiento de servicios de Kubernetes para Prometheus
En publicaciones anteriores, describimos cómo configurar Prometheus para trabajar con tus aplicaciones de TIBCO BusinessWorks Container Edition, y puedes leer más al respecto aquí. En esa publicación, describimos que había varias formas de actualizar a Prometheus sobre los servicios que están listos para monitorear. Y elegimos la más simple en ese momento que era la configuración de static_config, lo que significa:
No te preocupes Prometheus, te haré saber la IP que necesitas monitorear y no necesitas preocuparte por nada más.
Y esto es útil para una prueba rápida en un entorno local cuando quieres probar rápidamente tu configuración de Prometheus o quieres trabajar en la parte de Grafana para diseñar el mejor tablero posible para manejar tus necesidades. Pero, esto no es muy útil para un entorno de producción real, aún más, cuando estamos hablando de un clúster de Kubernetes donde los servicios están subiendo y bajando continuamente con el tiempo. Entonces, para resolver esta situación, Prometheus nos permite definir diferentes tipos de formas para realizar este enfoque de «descubrimiento de servicios». En la documentación oficial de Prometheus, podemos leer mucho sobre las diferentes técnicas de descubrimiento de servicios, pero a un nivel alto, estas son las principales técnicas de descubrimiento de servicios disponibles:
  • azure_sd_configs: Descubrimiento de Servicios de Azure
  • consul_sd_configs: Descubrimiento de Servicios de Consul
  • dns_sd_configs: Descubrimiento de Servicios de DNS
  • ec2_sd_configs: Descubrimiento de Servicios de EC2
  • openstack_sd_configs: Descubrimiento de Servicios de OpenStack
  • file_sd_configs: Descubrimiento de Servicios de Archivo
  • gce_sd_configs: Descubrimiento de Servicios de GCE
  • kubernetes_sd_configs: Descubrimiento de Servicios de Kubernetes
  • marathon_sd_configs: Descubrimiento de Servicios de Marathon
  • nerve_sd_configs: Descubrimiento de Servicios de Nerve de AirBnB
  • serverset_sd_configs: Descubrimiento de Servicios de Serverset de Zookeeper
  • triton_sd_configs: Descubrimiento de Servicios de Triton
  • static_config: IP/DNS Estático para la configuración. Sin Descubrimiento de Servicios.
E incluso, si todas estas opciones no son suficientes para ti y necesitas algo más específico, tienes una API disponible para extender las capacidades de Prometheus y crear tu propia técnica de Descubrimiento de Servicios. Puedes encontrar más información al respecto aquí: Pero este no es nuestro caso, para nosotros, el Descubrimiento de Servicios de Kubernetes es la elección correcta para nuestro enfoque. Así que, vamos a cambiar la configuración estática que teníamos en la publicación anterior:
- job_name: 'bwdockermonitoring'
  honor_labels: true
  static_configs:
    - targets: ['phenix-test-project-svc.default.svc.cluster.local:9095']
      labels:
        group: 'prod'
Por esta configuración de Kubernetes
- job_name: 'bwce-metrics'
  scrape_interval: 5s
  metrics_path: /metrics/
  scheme: http
  kubernetes_sd_configs:
  - role: endpoints
    namespaces:
      names:
      - default
  relabel_configs:
  - source_labels: [__meta_kubernetes_service_label_app]
    separator: ;
    regex: (.*)
    replacement: $1
    action: keep
  - source_labels: [__meta_kubernetes_endpoint_port_name]
    separator: ;
    regex: prom
    replacement: $1
    action: keep
  - source_labels: [__meta_kubernetes_namespace]
    separator: ;
    regex: (.*)
    target_label: namespace
    replacement: $1
    action: replace
  - source_labels: [__meta_kubernetes_pod_name]
    separator: ;
    regex: (.*)
    target_label: pod
    replacement: $1
    action: replace
  - source_labels: [__meta_kubernetes_service_name]
    separator: ;
    regex: (.*)
    target_label: service
    replacement: $1
    action: replace
  - source_labels: [__meta_kubernetes_service_name]
    separator: ;
    regex: (.*)
    target_label: job
    replacement: 1
    action: replace
  - separator: ;
    regex: (.*)
    target_label: endpoint
    replacement: $1
    action: replace
Como puedes ver, esto es bastante más complejo que la configuración anterior, pero no es tan complejo como podrías pensar a primera vista, revisémoslo por diferentes partes.
- role: endpoints
    namespaces:
      names:
      - default
Dice que vamos a usar el rol para los endpoints que se crean bajo el namespace por defecto y vamos a especificar los cambios que necesitamos hacer para encontrar los endpoints de métricas para Prometheus.
scrape_interval: 5s
 metrics_path: /metrics/
 scheme: http
Esto dice que vamos a ejecutar el proceso de scrape en un intervalo de 5 segundos, usando http en la ruta /metrics/ Y luego, tenemos una sección de relabel_config:
- source_labels: [__meta_kubernetes_service_label_app]
    separator: ;
    regex: (.*)
    replacement: $1
    action: keep
  - source_labels: [__meta_kubernetes_endpoint_port_name]
    separator: ;
    regex: prom
    replacement: $1
    action: keep
Eso significa que nos gustaría mantener esa etiqueta para prometheus:
- source_labels: [__meta_kubernetes_namespace]
    separator: ;
    regex: (.*)
    target_label: namespace
    replacement: $1
    action: replace
  - source_labels: [__meta_kubernetes_pod_name]
    separator: ;
    regex: (.*)
    target_label: pod
    replacement: $1
    action: replace
  - source_labels: [__meta_kubernetes_service_name]
    separator: ;
    regex: (.*)
    target_label: service
    replacement: $1
    action: replace
  - source_labels: [__meta_kubernetes_service_name]
    separator: ;
    regex: (.*)
    target_label: job
    replacement: 1
    action: replace
  - separator: ;
    regex: (.*)
    target_label: endpoint
    replacement: $1
    action: replace
Eso significa que queremos hacer un reemplazo del valor de la etiqueta y podemos hacer varias cosas:
  • Renombrar el nombre de la etiqueta usando el target_label para establecer el nombre de la etiqueta final que vamos a crear basado en las source_labels.
  • Reemplazar el valor usando el parámetro regex para definir la expresión regular para el valor original y el parámetro replacement que va a expresar los cambios que queremos hacer a este valor.
Así que, ahora después de aplicar esta configuración cuando despleguemos una nueva aplicación en nuestro clúster de Kubernetes, como el proyecto que podemos ver aquí: Automáticamente vamos a ver un objetivo adicional en nuestra configuración de job-name “bwce-metrics”

📚 Want to dive deeper into Kubernetes? This article is part of our comprehensive Kubernetes Architecture Patterns guide, where you’ll find all fundamental and advanced concepts explained step by step.

Configuración de TIBCO Flogo: ¿Cómo dominarla en 5 minutos?

Configuración de TIBCO Flogo: ¿Cómo dominarla en 5 minutos?

TIBCO Flogo es una plataforma excelente para construir tus microservicios y, desde el principio, vas a alcanzar un número de rendimiento increíble.

Pero, incluso con eso, estamos trabajando en un mundo donde cada milisegundo cuenta y cada MB de memoria cuenta, por lo que es importante conocer las herramientas que tenemos en nuestras manos para ajustar a un nivel más fino nuestra aplicación Flogo Enterprise.

Como ya sabes, Flogo está construido sobre el lenguaje de programación Go, por lo que vamos a diferenciar los parámetros que pertenecen al propio lenguaje de programación, y luego otros parámetros que son específicos de Flogo.

Todos estos parámetros deben definirse como variables de entorno, por lo que la forma de aplicarlos dependerá de cómo configures las variables de entorno en tu propia plataforma de destino (Windows, Linux, OSX, Docker, etc…)

Parámetros Específicos de Flogo OSS

Puedes consultar todos los parámetros y sus valores predeterminados en la documentación de Flogo:

Configuraciones Relacionadas con el Rendimiento

  • FLOGO_LOG_LEVEL: Permite establecer a nivel de inicio el nivel de registro que deseas usar para la ejecución de la aplicación. El valor predeterminado está configurado en «INFO» y se puede aumentar a DEBUG para realizar algunos diagnósticos o análisis adicionales y configurar en «WARN» o «ERROR» para aplicaciones de producción que necesitan el máximo rendimiento evitando imprimir trazas adicionales.
  • FLOGO_RUNNER_TYPE: Permite establecer a nivel de inicio el tipo de corredor y el valor predeterminado es POOLED.
  • FLOGO_RUNNER_WORKERS: Permite establecer a nivel de inicio el número de trabajadores de Flogo que van a ejecutar la lógica. El valor predeterminado es 5 y se puede aumentar cuando estás ejecutando en hardware potente que tiene mejores capacidades de paralelismo.
  • FLOGO_RUNNER_QUEUE: Permite configurar a nivel de inicio el tamaño de la cola del corredor que va a mantener en memoria las solicitudes que van a ser manejadas por los trabajadores. El valor predeterminado es 50 y cuando el número es alto también será alto el consumo de memoria, pero el acceso de los trabajadores a la tarea será más rápido.

Otras Configuraciones

  • FLOGO_CONFIG_PATH: Establece la ruta del archivo JSON de configuración que se va a usar para ejecutar la aplicación en caso de que no esté incrustado en el propio binario. El valor predeterminado es flogo.json
  • FLOGO_ENGINE_STOP_ON_ERROR: Establece el comportamiento del motor cuando ocurre un error interno. Por defecto está configurado en true y significa que el motor se detendrá tan pronto como ocurra el error.
  • FLOGO_APP_PROP_RESOLVERS: Establece cómo se van a recopilar las propiedades de la aplicación para ser utilizadas. El valor es el resolvedor de propiedades a usar en tiempo de ejecución. Por defecto es None y se incluye información adicional en la sección de documentación de propiedades de la aplicación.
  • FLOGO_LOG_DTFORMAT: Establece cómo se van a mostrar las fechas en las trazas de registro. El valor predeterminado es «2006–01–02 15:04:05.000».

Parámetros Específicos de Flogo Enterprise

Incluso cuando todas las propiedades de Project Flogo son compatibles con Flogo Enterprise, la versión empresarial incluye propiedades adicionales que se pueden usar para establecer comportamientos adicionales del motor.

FLOGO_HTTP_SERVICE_PORT: Esta propiedad establece el puerto donde se alojarán los puntos finales internos. Este punto final interno se utiliza para el punto final de verificación de estado, así como para la exposición de métricas y cualquier otro acceso interno que proporcione el motor.

FLOGO_LOG_FORMAT: Esta propiedad nos permite definir el formato de notación para nuestras trazas de registro. TEXT es el valor predeterminado, pero podemos usar JSON para que nuestras trazas se generen en JSON, por ejemplo, para ser incluidas en algún tipo de plataforma de ingestión de registros.

Parámetros Específicos del Lenguaje de Programación Go

  • GOMAXPROCS: Limita el número de hilos del sistema operativo que pueden ejecutar código Go a nivel de usuario simultáneamente. No hay límite para el número de hilos que pueden estar bloqueados en llamadas al sistema en nombre del código Go; esos no cuentan contra el límite de GOMAXPROCS.
  • GOTRACEBACK: Controla la cantidad de salida generada cuando un programa Go falla debido a un pánico no recuperado o una condición de tiempo de ejecución inesperada. Por defecto, un fallo imprime una traza de pila para la goroutine actual, omitiendo funciones internas del sistema de tiempo de ejecución y luego sale con el código de salida 2. El fallo imprime trazas de pila para todas las goroutines si no hay una goroutine actual o el fallo es interno al tiempo de ejecución. GOTRACEBACK=none omite completamente las trazas de pila de goroutine. GOTRACEBACK=single (el valor predeterminado) se comporta como se describe arriba. GOTRACEBACK=all agrega trazas de pila para todas las goroutines creadas por el usuario. GOTRACEBACK=system es como «all» pero agrega marcos de pila para funciones de tiempo de ejecución y muestra goroutines creadas internamente por el tiempo de ejecución. GOTRACEBACK=crash es como «system» pero falla de una manera específica del sistema operativo en lugar de salir.
  • GOGC: Establece el porcentaje objetivo inicial de recolección de basura. Se activa una recolección cuando la proporción de datos recién asignados a datos vivos restantes después de la recolección anterior alcanza este porcentaje. El valor predeterminado es GOGC=100. Configurar GOGC=off desactiva completamente el recolector de basura.

Prometheus TIBCO Monitoring para Contenedores: ¡Rápido y Sencillo en 5 Minutos!

Prometheus TIBCO Monitoring para Contenedores: ¡Rápido y Sencillo en 5 Minutos!

Prometheus se está convirtiendo en el nuevo estándar para la monitorización de Kubernetes y hoy vamos a cubrir cómo podemos hacer la monitorización de Prometheus TIBCO en Kubernetes.

Estamos viviendo en un mundo con cambios constantes y esto es aún más cierto en el mundo de las Aplicaciones Empresariales. No pasaré mucho tiempo hablando de cosas que ya conoces, pero solo diré que el enfoque de arquitectura de microservicios y las soluciones PaaS han sido un cambio de juego para todas las tecnologías de integración empresarial.

Esta vez me gustaría hablar sobre la monitorización y las capacidades de integración que tenemos al usar Prometheus para monitorear nuestros microservicios desarrollados bajo la tecnología TIBCO. Tampoco me gusta pasar demasiado tiempo hablando sobre qué es Prometheus, ya que probablemente ya lo sepas, pero en resumen, esta es una plataforma de monitorización distribuida de código abierto que ha sido el segundo proyecto lanzado por la Cloud Native Computing Foundation (después de Kubernetes en sí) y que se ha establecido como un estándar de facto de la industria para la monitorización de clústeres K8S (junto con otras opciones en el mercado como InfluxDB, etc.).

Prometheus tiene muchas características excelentes, pero una de ellas es que tiene conectores para casi todo y eso es muy importante hoy en día porque es tan complicado/no deseado/inusual definir una plataforma con un solo producto para la capa PaaS. Así que hoy, quiero mostrarte cómo monitorear tus aplicaciones de TIBCO BusinessWorks Container Edition usando Prometheus.

La mayor parte de la información que voy a compartir está disponible en el repositorio de GitHub bw-tooling, por lo que puedes ir allí si necesitas validar alguna declaración específica.

¿Ok, estamos listos? ¡¡Empecemos!!

Voy a asumir que ya tenemos un clúster de Kubernetes en su lugar y Prometheus instalado también. Entonces, el primer paso es mejorar la imagen base de BusinessWorks Container Edition para incluir la integración de capacidades de Prometheus. Para hacer eso, necesitamos ir a la página del repositorio de GitHub y seguir estas instrucciones:

  • Descargar y descomprimir la carpeta prometheus-integration.zip.
  • Abrir TIBCO BusinessWorks Studio y apuntarlo a un nuevo espacio de trabajo.
  • Hacer clic derecho en Project Explorer → Importar… → seleccionar Plug-ins y Fragmentos → seleccionar el botón de radio Importar desde el directorio
Prometheus TIBCO Monitoring para Contenedores: ¡Rápido y Sencillo en 5 Minutos!
Prometheus TIBCO Monitoring para Contenedores: ¡Rápido y Sencillo en 5 Minutos!
  • Navegar a la carpeta prometheus-integration (descomprimida en el paso 1)
Prometheus TIBCO Monitoring para Contenedores: ¡Rápido y Sencillo en 5 Minutos!
  • Ahora hacer clic en Siguiente → Seleccionar el plugin de Prometheus → hacer clic en el botón Agregar → hacer clic en Finalizar. Esto importará el plugin en el estudio.
Prometheus TIBCO Monitoring para Contenedores: ¡Rápido y Sencillo en 5 Minutos!
  • Ahora, para crear el JAR de este plugin, primero necesitamos asegurarnos de actualizar com.tibco.bw.prometheus.monitor con ‘.’ (punto) en el campo Bundle-Classpath como se indica a continuación en el archivo META-INF/MANIFEST.MF.
Prometheus TIBCO Monitoring para Contenedores: ¡Rápido y Sencillo en 5 Minutos!
  • Hacer clic derecho en Plugin → Exportar → Exportar…
Prometheus TIBCO Monitoring para Contenedores: ¡Rápido y Sencillo en 5 Minutos!
  • Seleccionar tipo como archivo JAR y hacer clic en Siguiente
Prometheus TIBCO Monitoring para Contenedores: ¡Rápido y Sencillo en 5 Minutos!
  • Ahora hacer clic en Siguiente → Siguiente → seleccionar el botón de radio para usar el archivo MANIFEST.MF existente y buscar el archivo manifest
Prometheus TIBCO Monitoring para Contenedores: ¡Rápido y Sencillo en 5 Minutos!
  • Hacer clic en Finalizar. Esto generará prometheus-integration.jar

Ahora, con el JAR ya creado, lo que necesitamos hacer es incluirlo en tu propia imagen base. Para hacer eso, colocamos el archivo JAR en <TIBCO_HOME>/bwce/2.4/docker/resources/addons/jar

Prometheus TIBCO Monitoring para Contenedores: ¡Rápido y Sencillo en 5 Minutos!

Y lanzamos el comando de construcción de imagen nuevamente desde la carpeta <TIBCO_HOME>/bwce/2.4/docker para actualizar la imagen usando el siguiente comando (usa la versión que estés usando en el momento)

docker build -t bwce_base:2.4.4 .

Entonces, ahora tenemos una imagen con soporte para Prometheus! ¡Genial! Estamos cerca del final, solo creamos una imagen para nuestra Aplicación de Contenedor, en mi caso, esto va a ser un servicio de eco muy simple que puedes ver aquí.

Y solo necesitamos mantener estas cosas en particular cuando desplegamos en nuestro clúster de Kubernetes:

  • Debemos establecer una variable de entorno con BW_PROMETHEUS_ENABLE en “TRUE”
  • Debemos exponer el puerto 9095 desde el contenedor para ser usado por Prometheus para integrar.
Prometheus TIBCO Monitoring para Contenedores: ¡Rápido y Sencillo en 5 Minutos!

Ahora, solo necesitamos proporcionar este endpoint al sistema de scrapper de Prometheus. Hay varias maneras de hacer eso, pero nos vamos a centrar en la más simple.

Necesitamos cambiar el prometheus.yml para agregar los siguientes datos del trabajo:

- job_name: 'bwdockermonitoring'
  honor_labels: true
  static_configs:
    - targets: ['phenix-test-project-svc.default.svc.cluster.local:9095']
      labels:
        group: 'prod'

Y después de reiniciar Prometheus, tenemos todos los datos indexados en la base de datos de Prometheus para ser usados en cualquier sistema de panel de control.

Prometheus TIBCO Monitoring para Contenedores: ¡Rápido y Sencillo en 5 Minutos!

En este caso, voy a usar Grafana para hacer un panel de control rápido.

Prometheus TIBCO Monitoring para Contenedores: ¡Rápido y Sencillo en 5 Minutos!

Cada uno de estos componentes de gráfico está configurado en base a las métricas que están siendo extraídas por el exportador de Prometheus TIBCO.

Prometheus TIBCO Monitoring para Contenedores: ¡Rápido y Sencillo en 5 Minutos!

Prueba de Flogo: ¡Aprende a Dominar las Pruebas en Flogo!

Prueba de Flogo: ¡Aprende a Dominar las Pruebas en Flogo!

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:

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”:

Prueba de Flogo: ¡Aprende a Dominar las Pruebas en Flogo!

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:

Prueba de Flogo: ¡Aprende a Dominar las Pruebas en Flogo!

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

.FlogoJWTEcho-windows_amd64.exe' -test -flowin .MainFlow_Launch_Configuration_1.json -flowout MainFlow_out.json

Esto va a generar un archivo de salida con el resultado de la prueba de ejecución:

Prueba de Flogo: ¡Aprende a Dominar las Pruebas en Flogo!

Y si abrimos el archivo obtendremos exactamente el mismo resultado que el flujo devuelve para que podamos realizar cualquier aserción sobre él

Prueba de Flogo: ¡Aprende a Dominar las Pruebas en Flogo!

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:

.FlogoJWTEcho-windows_amd64.exe' -test -flowdata MainFlow
Prueba de Flogo: ¡Aprende a Dominar las Pruebas en Flogo!

Pero, ¿cómo sabes los flujos en tu aplicación sin ir a la interfaz web de Flogo? Solo con el siguiente comando:

.FlogoJWTEcho-windows_amd64.exe' -test  -flows
Prueba de Flogo: ¡Aprende a Dominar las Pruebas en Flogo!

Soporte JWT de Flogo

Soporte JWT de Flogo

Introducción a OAuth 2.0 y JWT

OAuth 2.0

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.

Soporte JWT de Flogo
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:

Soporte JWT de Flogo
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.

Soporte JWT de Flogo
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”
Soporte JWT de Flogo
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:
  1. Grupo de Usuarios de Cognito seleccionado como Proveedor de Identidad Habilitado
  2. Credenciales del cliente utilizadas como Flujos de OAuth Permitidos
  3. http://flogo.test1/echo seleccionado como un alcance habilitado
Soporte JWT de Flogo
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:

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:

Soporte JWT de Flogo

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:

Soporte JWT de Flogo

Vamos a usar la actividad JWT alojada en GitHub disponible en el enlace que se muestra a continuación:

NOTA: Si no recuerdas cómo instalar una extensión de Flogo Enterprise, echa un vistazo al enlace a continuación:

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:

Soporte JWT de Flogo
Soporte JWT de Flogo

Prueba

Ahora, vamos a lanzar la Aplicación Flogo Enterprise desde el binario generado:

Soporte JWT de Flogo

Y ahora, si intentamos hacer una ejecución al endpoint sin proporcionar ningún token obtenemos el código de respuesta 401 esperado

Soporte JWT de Flogo

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:

Soporte JWT de Flogo

Y este token tiene toda la información del cliente y sus permisos, puedes verificarlo en la página web jwt.io:

Soporte JWT de Flogo

Y para finalmente probarlo, solo necesitamos agregarlo a la primera solicitud que intentamos como podemos ver en la imagen a continuación:

Soporte JWT de Flogo

Recursos

Comparativa de Rendimiento: TIBCO Flogo vs Python en Servicios Eficientes

Comparativa de Rendimiento: TIBCO Flogo vs Python en Servicios Eficientes

Introducción

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:

Comparativa de Rendimiento: TIBCO Flogo vs Python en Servicios Eficientes
Í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
ACCESS_KEY = 'XXXXXXXXXXXXXXXXX'
SECRET_KEY = 'XXXXXXXXXXXXXXXXXXXXXXXXXXX'
def upload_to_aws(local_file, bucket, s3_file):
       s3 = boto3.client('s3', aws_access_key_id=ACCESS_KEY,
       aws_secret_access_key=SECRET_KEY)
       try:
           s3.upload_file(local_file, bucket, s3_file)
          print("Subida Exitosa")
          return True
       except FileNotFoundError:
          print("El archivo no fue encontrado")
          return False
       except NoCredentialsError:
          print("Credenciales no disponibles")
          return False
def launch():
    start = time.time()
    for x in range(0, int(sys.argv[1])):
    uploaded = upload_to_aws('D:/Data/Downloads/export.sql', 'testflogovspython', 'export.sql')
    end = time.time()
    print("Tiempo: " +  str(end - start))
launch()

Y vamos a usar la siguiente Aplicación Flogo (varios flujos para cada uno de los casos que nos gustaría verificar)

Comparativa de Rendimiento: TIBCO Flogo vs Python en Servicios Eficientes

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:

Comparativa de Rendimiento: TIBCO Flogo vs Python en Servicios Eficientes
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:

Comparativa de Rendimiento: TIBCO Flogo vs Python en Servicios Eficientes

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.

Comparativa de Rendimiento: TIBCO Flogo vs Python en Servicios Eficientes

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.

Comparativa de Rendimiento: TIBCO Flogo vs Python en Servicios Eficientes

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:

Comparativa de Rendimiento: TIBCO Flogo vs Python en Servicios Eficientes
Transacciones por segundo API REST Python vs Flogo
Comparativa de Rendimiento: TIBCO Flogo vs Python en Servicios Eficientes
Tiempo 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.

Comparativa de Rendimiento: TIBCO Flogo vs Python en Servicios Eficientes
Comparativa de Rendimiento: TIBCO Flogo vs Python en Servicios Eficientes
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:

Manejo de Errores de Flogo

Manejo de Errores de Flogo

Introducción

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:

Manejo de Errores de Flogo

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:

Manejo de Errores de Flogo

Y podrías elegir una de las tres situaciones como puedes ver en la imagen a continuación:

Manejo de Errores de Flogo

Como las ramas son acumulativas, podemos tener una actividad con diferentes ramas de diferentes tipos:

Manejo de Errores de Flogo

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:

Manejo de Errores de Flogo

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:

Manejo de Errores de Flogo

Subflujos de Flogo: Impulsando la Mantenibilidad de su Software

Subflujos de Flogo: Impulsando la Mantenibilidad de su Software

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:

Subflujos de Flogo: Impulsando la Mantenibilidad de su Software
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”

Subflujos de Flogo: Impulsando la Mantenibilidad de su Software

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)

Subflujos de Flogo: Impulsando la Mantenibilidad de su Software

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!!!!

Compatibilidad con OpenTracing en TIBCO BusinessWorks Container Edition

Compatibilidad con OpenTracing en TIBCO BusinessWorks Container Edition

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.

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.

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:

Compatibilidad con OpenTracing en TIBCO BusinessWorks Container Edition

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:

Pero al final solo necesitamos ejecutar el siguiente comando:

docker run -d --name jaeger -e COLLECTOR_ZIPKIN_HTTP_PORT=9411  -p 5775:5775/udp  -p 6831:6831/udp  -p 6832:6832/udp  -p 5778:5778  -p 16686:16686  -p 14268:14268  -p 9411:9411  jaegertracing/all-in-one:1.8

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

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

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
Compatibilidad con OpenTracing en TIBCO BusinessWorks Container Edition
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
Compatibilidad con OpenTracing en TIBCO BusinessWorks Container Edition

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:

Compatibilidad con OpenTracing en TIBCO BusinessWorks Container Edition

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

Compatibilidad con OpenTracing en TIBCO BusinessWorks Container Edition

Y luego, si hacemos zoom en algún rastro específico:

Compatibilidad con OpenTracing en TIBCO BusinessWorks Container Edition

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:

Compatibilidad con OpenTracing en TIBCO BusinessWorks Container Edition

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í.

Compatibilidad con OpenTracing en TIBCO BusinessWorks Container Edition

Y si echas un vistazo a los datos que tenemos en el sistema, puedes ver que todos estos rastros tienen estos datos:

Compatibilidad con OpenTracing en TIBCO BusinessWorks Container Edition

Puedes echar un vistazo al código en el siguiente repositorio de GitHub:

Soporte de GraphQL en Flogo Enterprise

Soporte de GraphQL en Flogo Enterprise

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:

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_1

Soporte de GraphQL en Flogo Enterprise
Formulario 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
Soporte de GraphQL en Flogo Enterprise

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:

Soporte de GraphQL en Flogo Enterprise
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.
Soporte de GraphQL en Flogo Enterprise
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.
Soporte de GraphQL en Flogo Enterprise
  • 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.
Soporte de GraphQL en Flogo Enterprise
  • 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.
Soporte de GraphQL en Flogo Enterprise
  • 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.
Soporte de GraphQL en Flogo Enterprise

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!

Soporte de GraphQL en Flogo Enterprise
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:

Soporte de GraphQL en Flogo Enterprise
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!

Soporte de GraphQL en Flogo Enterprise
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:

{
 “query” : “query($email: String!) { currentUser( email: $email) { id firstName email } }”,
 “variables” : {“email” : “test@test.com” }
}
Soporte de GraphQL en Flogo Enterprise
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:
{
 “query” : “query($email: String!) { currentUser( email: $email) { id } }”,
 “variables” : {“email” : “test@test.com” }
}

Y ahora, solo estamos obteniendo esta salida:

Soporte de GraphQL en Flogo Enterprise
Salida de GraphQL devolviendo solo el id