G6Flow® Introducción a BEI

Objetivos de la sesión

En la siguiente sección, se plantea cubrir los siguientes objetivos de estudio.

1. Conocer y comprender el concepto de BEI.
2. Conocer y comprender como BEI puede acelerar el desarrollo de nuevas aplicaciones.
3. Saber que motivo a la creación de estos BEIs .
4. Conocer su diseño y arquitectura.
5. Conocer cuales son las configuraciones compatibles hasta el momento.
6. Entender las características mas relevantes de cada sabor de BEI.
7. Conocer como se realiza su despliegue y configuración.
8. Comprender como es que se generan los API Docs y donde están disponibles para su uso.
9. Conocer las capacidades CRUD de la API.

Concepto de BEI

Acrónimo de Back End Integrator. Su finalidad es la de acelerar la integración con fuentes de datos existentes, agregando inmediatamente, elementos como:

• API Rest y rutas accesibles a la data.
• Swagger Docs
• Acceso permitido por API Key
• Acceso por HTTPS, mediante TLS 1.2

Las características principales del BEI, se pueden resumir como sigue:

• Menos Código.

  • Sin necesidad de realizar desarrollos específicos, y solamente con la configuración de las estructuras de datos y la conexión a la base de datos, se habilita el servicio en cuestión de minutos los servicios del BEI.

• Seguridad inmediata

  • Desde el arranque del BEI, se encuentra habilitado TLS para la exposición de los servicios y para API Key para poderlos consumir. Se puede habilitar MTLS para reforzar aun mas el control de acceso a los servicios.

• Configuración API First

  • A partir de la documentación Swagger u open API, generamos todos los métodos para cada objeto de datos que será expuesto mediante el BEI, así como restricciones y validaciones, basadas en JSON Schema .

• CRUD Instantáneo

  • Al encender y configurar el BEI, tenemos acceso inmediatamente a los métodos GET, POST, PUT y DELETE para interactuar con los datos de las fuentes de datos habilitadas.

• Documentación siempre actualizada

  • El BEI siempre expondrá la documentación relacionada con los servicios configurados; en caso de realizar algún cambio, este se reflejará inmediatamente en la documentación del BEI.

Principales retos de la integración

Como se hablo en la sección de Introducción a la Integración de sistemas, existen diversos factores que implicar diversos retos para la habilitación de interoperabilidad entre plataformas, tales como:

Estos retos, marcar diversos hitos, que nos sirven como motivadores para poder atender cada uno de ellos, y volver a BEI como un conjunto de herramientas para conectar, documentar y asegurar la comunicación con los activos de información actuales de las organizaciones.

Principales motivadores

Para contestar a la pregunta referente a la necesidad de contar con herramientas y componentes que ayuden a realizar integraciones con otros sistemas, utilizaremos los retos como referencia y punto de partida.

Reducción de la complejidad

Mediante el uso de los BEIs , se plantea simplificar la complejidad de conexión, y habilitar un mecanismo replicable y confiable para consumir en forma de servicios REST, fuentes de datos que utilizan protocolos nativos y propietarios, que a veces inclusive, requieren de un licenciamiento especifico para poder ser consumidos. (ej., IBM DB2, SAP, etc.).

Conexión a otros sistemas

Para resolver el problema de interoperabilidad, BEI habilita una capa que logra estandarizar la forma en la que se realiza la conexión a sistemas de diferentes fabricantes; y permite reducir la complejidad que puede representar para los desarrolladores que piensan consumir dichos activos, ayudando a reutilizar librerías que consumar un tipo de servicio rest , y generalizándolo para ser utilizado mediante parámetros, para adaptarse a todos los servicios soportados.

Reducción de costos

Existen diversos puntos donde BEI ayuda a reducir los costos que la integración de sistemas acarrea. Los mas importantes, se destacan a continuación.

a. Costos de talento humano y especialización. b. Costos tecnológicos y de capacitación. c. Costos de adaptación de los sistemas por los fabricantes d. Costos de licenciamiento por apartados de integración.

Todos estos puntos, convergen en la necesidad de simplificar y unificar la forma en la que se consumen las plataformas, con lo que a partir del uso de BEI, podemos atacar a cada uno de ellos, mediante la simplificación de conexión, unificación de la forma de consumir los servicios, la seguridad inicial que se habilita al momento de implementar el BEI y la reducción de la necesidad de solicitudes de adaptación de las plataformas por lo fabricantes, o por los equipos internos, lo que ayuda a mantener garantías sobre las plataformas, y no requerir personal especializado que puede rotar o desaparecer a lo largo del tiempo.

Habilitar la seguridad del consumo “por defecto”

Desde el momento en que se realiza la configuración de un BEI, este nace con habilidades de seguridad mínimas necesarias, para poder exponerse, o ser incorporado atrás de una capa de refuerzo de seguridad. Sin embargo, los desarrolladores pueden enfocarse en su uso, y no tanto en la seguridad, que, sin lugar a dudas, debe ser el eje de la exposición de los servicios.

Coherencia y homogeneidad de datos

Sin importar el modelo del fabricante del motor de base de datos, o sistema al que se desea conectar; BEI habilita una línea base, que simplifique la necesidad de conocimientos y conceptos, referentes a como realizar la conexión, como consumir, que operaciones existen para con los datos y sobre todo, la disponibilidad de documentación inmediata, posterior a la configuración del BEI.

Facilitar la toma de decisiones técnicas y de negocio.

Al contar con BEIs que habilitan la integración, es más fácil contarlos como activos tecnológicos, que pueden concentrarse en portales de desarrollo, y ser empaquetados. Con la información de los consumos realizados, es más fácil saber qué servicios son los más críticos, y permite pensar como podemos explotar de otra forma, servicios que ya existen.

A nivel de negocio, permite pensar en diferentes formas de crear nuevas líneas de negocio , sin pensar si “es factible o no”.

Habilitar y acelerar la transformación digital

El conjunto de los puntos anteriores, sirven como elementos para poder introducir o potenciar una estrategia de Transformación digital en las organizaciones, ya que son todos ellos, elementos principales no solo para crear servicios y exponer la información; si no, para habilitar el cambio de mentalidad en la organización y la habilitación de líneas de innovación y gestación de productos y servicios modernos, con elementos de alta automatización y excelencia operativa.

Componentes y arquitectura

El siguiente mapa, muestra los componentes de arquitectura con los que cuenta el BEI a nivel general.

Se debe tener en cuenta, que, de un BEI a otro, pueden variar según el modelo de micro servicio de que se trate, pero que se trata de mantener al máximo el patrón de diseño general de este.

Ilustración 1 : Diagrama de exposición de G6Flow BEI

En el diagrama anterior, podemos observar al centro, el BEI, que tiene la forma de MICRO SERVICIO. El concepto que gira en torno a él, es el de habilitar mediante micro servicios, la conexión con múltiples sistemas, y la formación de enjambres de micro servicios, que puedan ser susceptibles de configuración a niveles muy finos , control de concurrencia mediante crecimiento horizontal , y SIEMPRE ASEGURDADO por defecto.

Los elementos que se habilitan al incorporar BEI a las arquitecturas tecnológicas modernas, son los siguientes:

Habilitación mediante configuración

Mediante el api de configuración, es posible impactar cambios en la configuración, y definir los esquemas de datos que BEI utilizara para realizar las configuraciones. Al momento de impactar los cambios, el BEI se reiniciará automáticamente para aplicar las configuraciones, cosa que no toma más que un par de milésimas de segundo.

Conexión inmediata al backend .

Mediante la configuración del esquema de datos a utilizar por el BEI para comunicarse con el sistema al que se va a conectar, se puede revisar inmediatamente si existe o no el canal necesario para la lectura del mismo. Además, se pueden realizar pruebas inmediatamente para verificar si se cuenta con los permisos necesarios y no hay ningún inconveniente al momento de realizar la comunicación.

Habilitación de Middleware de consumo

Cuando se cuenta con un conjunto de BEIs conectados y configurados, se puede apreciar que toman la forma de un Middleware, que expone un grupo de servicios y documentación, disponibles para ser consumidos en la capa de red en la que se han habilitado. Todos los servicios, aunque independientes, mantienen características similares en términos de seguridad y formato de exposición, con lo que es posible apreciarlos como si fueran un solo frente de consumo.

El formato en el que se exponen las URL del BEI, que depende de las tablas que se configuran, es el siguiente:

/[bei-prefix]/[database]/[table]

En donde:

• [bei-prefix] : El prefijo configurado en el BEI al momento del despliegue.
• [database] : Base de datos en la que se encuentran las tablas o colecciones a exponer desde el BEI.
• [table] : Es la tabla o la colección configurada en el BEI.

Exposición de API REST y servicios CRUD

Cada BEI cuenta con 5 operaciones básicas, las cuales ayudan a realizar las cuatro acciones que se pueden realizar con la información, las cuales son:

• Creación ( Create )
• Lectura ( Read )
• Actualización ( Update )
• Eliminación ( Delete )

Estas cuatro operaciones son conocidas como CRUD por sus iniciales en inglés, y a continuación, describiremos las características que se debe de tener en cuenta, para cada una de ellas.

Acción CREATE

Es ejecutada mediante el método POST. Dependiendo del Endpoint , puede o no requerir un valor en el identificador, o, además, requerir información adicional, según se declare en el esquema de configuración de la tabla, documento o componente de datos a utilizar.

Acción READ

Se divide en dos. Un GET sin parámetros en la URL para obtener un listado completo, o restringido en cuanto a cantidad limite de datos a desplegar; configurado al momento de declarar la configuración, y un GET con un ID, también configurado al momento de configurar el objeto de datos.

En ambos casos, es posible seleccionar que Campos o propiedades necesitamos listar de la tabla específica en tiempo de ejecución mediante el query parameter de “ fields ”, el cual, si no se utiliza, retornara por defecto todos los campos de la tabla, pero si se introduce una lista separada por comas, se obtendrán solamente los valores de los campos requeridos.

Además, se puede agregar un filtro simple, donde se puede colocar una condición, para obtener desde un campo en particular, los registros que cumplan con la condición. Se pueden utilizar el formato de SQL para aplicar los filtros.

Ilustración 2 : Acción GET y sus parámetros.

En la opción de Get By ID, se puede cerrar la solicitud de información, a un solo registro especificado por el ID del mismo. Este valor es configurable en el BEI, y puede cambiarse según la necesidad.

Ilustración 3 : Acción GET By ID y sus parámetros.

Acción UPDATE

Esta acción se relaciona con la actualización de un registro. Se utiliza el método PUT del protocolo HTTP. Utiliza un parámetro de URL, para indicar el Identificador del registro a actualizar, y también usa como referencia el esquema declarado para realizar la acción de actualización.

Acción DELETE

Esta acción se relaciona con la eliminación de registros. Utiliza el método DELETE del protocolo HTTP. Utiliza un parámetro de URL para indicar el identificador del registro. No utiliza cuerpo de mensaje y retorna 201 o 200, dependiendo del modelo del BEI.

Exposición de API Docs. de los servicios.

Dependiendo del prefijo configurado en el BEI, se puede acceder a la documentación mediante la siguiente URL:

http(s)://[bei-location]:[port]/bei-admin/v1/docs

en donde :

• [bei-location] : Dirección en la que se encuentra publicado el servicio de BEI.
• [port]: Numero del puerto donde se encuentra expuesto el servicio.

A partir de esa URL, es posible entrar una interfaz de Swagger UI, donde podemos ver la definición del BEI.

Compatibilidad de BEI.

Actualmente, contamos con los siguientes modelos de BEI, los cuales pueden servir como referencia para ofrecimiento o inclusión en marcos de diseño técnico de diversos proyectos de integración de fuentes.

• BEI para Microsoft® SQL Server.
• BEI para Azure Cosmos DB.
• BEI para Oracle ® Relational Database Management System.
• BEI para IBM® DB2®
• BEI para IBM® MQ
• BEI para MySQL Server
• BEI para MariaDB
• BEI para PostgreSQL
• BEI para MongoDB
• BEI para Apache Kafka
• BEI para Rabbit MQ.
• BEI para Trino
• BEI para File Transfer ing .

La mayoría de l os BEIs que se utilizan para conectarse con bases de datos relacionales, mantienen el 99% de la estructura similar.

Los BEIs de bases de datos de tipo NoSQL, pueden tener variaciones, dependiendo del modelo, pero tratan de respetar la estructura al máximo.

Existen BEIs que tienen como finalidad la de conectar un sistema de colas o de flujos de mensajería. La ventaja de usar el BEI, es que regularmente, no se maneja información estructurada en estos sistemas, sin embargo, el BEI puede adicionar esta capa, que puede ayudar a homologar la mensajería que pasa por este tipo de sistemas.

Existe un modelo especifico, que ayuda a intercambiar archivos para que sean colocados y publicados en un sistema de archivos, el cual puede servir para habilitar flujos de intercambio de archivos específicos, mediante sistemas de transferencia de archivos automatizada o manual tales como sftp , ssh , ftp, smb, etc.

Despliegue del BEI.

Regularmente, este despliegue esta pensado para realizarse en un formato de contenedor, sin embargo, de ser necesario, se puede prepara una instalación en Virtual Appliance, dependiendo de la necesidad especifica. Sin embargo, siempre se recomienda, utilizar el container form factor, y crecer mediante el uso de Pods, en infraestructura de hyper convergencia o Kubernetes (K8s).

Se debe solicitar un Access Key, para tener acceso al Container Image Registry privado de Global SEIS, desde donde se puede tener acceso a las imágenes de los componentes de G6Flow, y a sus actualizaciones. Esta debe ser solicitada con su representante de canales, o de ventas de Global SEIS. Este Access Key, debe ser solicitado para cada cliente, ya que, con este, se controla la descarga de los BEIs y la cantidad de descargas realizadas por dicho Access Key, para efectos del cumplimiento del acuerdo licenciamiento de software específico.

Se debe configurar la cuenta de AWS, para poder tener acceso al ECR, utilizando el comando:

aws configure

El comando anterior, solicitara el Access Key y el Secret Access Key, asi como la región desde donde se realizara la conexiona AWS.

La llave otorgada, solo tiene permisos para listar el repositorio de las imágenes, y para hacer pull de las mismas.

Se debe de agregar el Registro a su clúster de Kubernetes usando la siguiente url:

docker pull 735877081960.dkr.ecr.us-west-2.amazonaws.com/ < bei -image > :latest

Pa ra ello es necesario contar con las credenciales para poder tener acceso al repositorio privado de imágenes. Se debe reemplazar “< bei-image > ” por el modelo de BEI que se desea desplegar.

Una vez obtenida la imagen, se pueden descargar los HELM Charts para iniciar con la configuración inicial de los pods, y la indicación de puertos, identificaciones y certificados, e información d el BEI.

Al utilizar HELM Charts, se puede realizar de manera mas sencilla el despliegue de los BEIs , y el uso de las credenciales de AWS para la descarga y despliegue de las mismas.

Estructura de la configuración

Una vez que logramos desplegar alguna de las imágenes de BEI disponibles, estos siguen un patrón de configuración comun, que tiene la siguiente estructura:

{
  "_id": "string",
  "database": "string",
  "host": "string",
  "port": 0,
  "user": "string",
  "password": "string",
  "description": "string",
  "tables": [
    {
      "identifier": "string",
      "name": "string",
      "description": "string",
      "methods": {
        "get": {},
        "getid ": {},
        "post": {},
        "put": {},
        "delete": {}
      }
    }
  ]
}

Esta estructura, puede usarse como plantilla para la configuración inicial del BEI, y contiene desde la información de conexión a la base de datos, hasta la declaración de las tablas o estructuras de datos a las cuales se realizarán las peticiones desde el BEI.

Existen algunas consideraciones de a tener en cuenta como:

• La contraseña de conexiona la base de datos, se encripta y es devuelta en formato ofuscado.
• Si no se agrega un identificador de BEI, este se calculará utilizando un string aleatorio, y en formato MD5.
• El formato para a la definición de los objetos, está basada en JSON- Schema , por lo que sigue las mismas reglas.
• Mientras mas información se especifique en la definición de los esquemas de las tablas, más información se desplegará en la documentación Swagger del BEI.

Conclusiones.

BEI es el acrónimo de Back End Integrator .

Su rol es el de acelerar la exposición de un destino de datos, incorporando desde el inicio, elementos de seguridad y de esquematización de datos al momento de ser habilitado.

Los BEIs , habilitan las operaciones CRUD para las tablas o colecciones referenciadas, y estas cuentas con diferentes opciones de uso, como por ejemplo GET, puede recibir por query parameter , la lista de campos a utilizar, y un pequeño filtro para reducir la cantidad de registros a listar. También, opciones como GET by ID, PUT y DELETE, utilizan un URL parameter , para indicar el Identificador de un registro específico.

Aunque se puede realizar la disposición en formato de Virtual Appliance, se sugiere siempre el uso en forma de Contenedor y Pod .

Se debe utilizar HELM para simplificar la instalación de los BEIs .

Se debe solicitar un Access Key, para poder tener acceso a las imágenes de BEI para su uso.