¿Qué es un Vocabulario de Términos?

Si somos puristas y nos vamos a la definición que nos provee la Real Academia Española y la Asociación de Academias de la Lengua Española sobre el Vocabulario o Glosario de Términos, para este caso gramaticales es un recurso didáctico se ponen a disposición de los docentes de lengua de todos los países hispanohablantes. Los objetivos fundamentales de esta obra son los siguientes:

• Contribuir a mejorar la formación gramatical de cuantos enseñan español en los cursos previos a la universidad.
• Explicar y justificar la terminología gramatical que puede adaptarse a esos niveles de la enseñanza, así como ayudar a que los docentes la manejen con destreza y propiedad.
• Mejorar el conocimiento de las estructuras gramaticales y de su relación con los significados que expresan.
• Simplificar didácticamente las nociones más complejas, aclarar las tradicionales e introducir algunos conceptos modernos, ampliamente usados en la actualidad, que resultan de gran utilidad para analizar la gramática de nuestra lengua.
• Contribuir a que la enseñanza de la gramática constituya una tarea más reflexiva y menos mecánica de lo que a veces resulta ser.

Si asemejamos esto al mundo de la integración se podría definir como:

• Una herramienta que nos ayude a gestionar términos que contiene los estándares de nombres y detalles de todas las entidades y atributos comerciales. Donde cada dato comercial se agrupa como objeto complejo por entidades funcionales con un significado particular. Lo que es lo mismo, un diccionario donde agrupamos todos los posibles parámetros presentes de una entidad comercial.

Bajo estas premisas de lo que consideramos como vocabulario de términos, y aterrizándolo en la plataforma de MuleSoft – Anypoint Platform sobre las APIs, nos encontramos con lo que se denomina API Fragments.

¿Qué son los API Fragments de MuleSoft?

Un API Fragment es un documento que tiene una versión y un identificador, pero no es en sí mismo un API Spec completa. Es una parte de un API Spec, por lo que su comprensión comienza en el nivel de especificación de API.

Un API Spec consiste en un plan de cómo debería verse estructuralmente su API, como el plano de una casa. En definitiva, se trata del contrato que estandariza el intercambio de datos entre los diferentes servicios. Es decir, sirve para estandarizar el Modelo de Datos...

Un API Spec proporciona una comprensión integral de cómo se comporta una API y se vincula con otras API. También explica cómo funciona la API y los resultados que se esperan al usar la API.

Un API Spec documenta lo que hace una API y la llamada y respuestas esperadas que pueden esperar de ella. Es una parte clave del desarrollo de API porque puede ayudarle a aislar los posibles fallos o problemas de diseño antes de escribir una línea de código.

Una forma de crear API de manera más eficiente es reutilizar partes o fragmentos de un API Spec, para que estos no tengan un formato diferente entre los diferentes servicios que dispongamos. Por ejemplo, que un recurso tenga siempre la misma estructura modelo entre los diferentes servicios que intercambian información de este, haciendo único el modelo de datos en todas las capas, desde el front-end al back-end.

Es por eso que podemos considerar a los API Fragments de MuleSoft como un diccionario, un vocabulario de términos al que consultar y con los cuales formar la especificación de nuestras APIs en la capa de Integración.

Dicha colección o vocabulario de términos es más que recomendable que se dividan en pequeños módulos y se externalicen en API Fragments la capa de integracion con APIs en lo que a Anypoint Platform se refiere, los API Spec de esos recursos, parámetros, esquemas… En definitiva, de este modelo de datos.

La gran ventaja de los API Fragments es que podemos reutilizarlo en todas las API Spec que requieran de él, consiguiendo así una cohesión y coherencia en toda la capa de APIs en nuestro modelo API Led. Además, con ello conseguimos que el diseño y la creación de una especificación API reutilizable sean aún más rápidas y sencilla, pues no se comienza desde cero.

Modelo Común Datos

¿Cuántas veces hemos llegado a un proyecto en el que la misma entidad está definida de manera diferente según qué API, endpoint, operación, etc., donde uno o más parámetros tienen un nombre diferente?

Pongamos algunos ejemplos:

Para estos casos, existen los Modelos Comunes de Datos también conocidos como “Canonical Data Model (CDM)”. Este modelo de datos ha de ser estandarizado y consensuado dentro de la entidad comercial, para seguidamente hacerlo extensible en todas las capas, desde el front-end al back-end.
 

Podríamos definir los CDMs como un tipo de modelo de datos que tiene como objetivo presentar entidades y relaciones de datos de la forma más simple posible para integrar procesos en varios sistemas y bases de datos.

Hay muchos casos en los cuales podemos encontrarnos con un Modelo Común de Datos estandarizado en el sector, que nos indica cuáles son las entidades principales que se han de tener en cuenta y sus parámetros como pueden ser:

• BIAN: Basado en una arquitectura orientada a servicios que define las capacidades comerciales estándar que componen un banco, como pagos, ofertas de préstamos o servicios comerciales.
• ACORD: Marco para la industria de seguros que consta de procesos de negocios, modelos de productos, marcos de desarrollo, modelos de información, modelos de datos y modelos de capacidad que ayudan a las organizaciones a ejecutar, desarrollar, modificar y mantener diversas aplicaciones de la industria de seguros.

Gracias a los API Fragments, podemos aterrizar estos modelos de datos en las APIs para poder ser reutilizados internamente en un API Spec, cerciorándonos así que tendremos un Modelo Común de Datos cross a todas las APIs, ya esté basado en algún estándar común a un sector, o sea propio de la entidad.

La importancia de Anypoint Design Center y Anypoint Exchange

Gracias a estas dos herramientas integradas en Anypoint Platform, el Anypoint Design Center y el Anypoint Exchange, los usuarios podrán aprovechar verdaderamente los fragmentos de API, pues nos ofrecen las capacidades que hacen que la reutilización tenga el peso y la importancia que se merecen.

Anypoint Exchange ayuda a los usuarios a facilitar el componente de reutilización de Anypoint Platform. A medida que los usuarios comienzan a definir fragmentos de API, pueden publicarse en Exchange y luego ponerse a disposición para su descubrimiento en toda la organización en Anypoint Design Center. Una vez que utilizan los activos, los usuarios también pueden calificarlos o dejar comentarios y preguntas.

La estrecha integración del diseñador del API y Anypoint Exchange es realmente fundamental para crear un flujo de trabajo eficiente y necesario para cerrar la brecha en la entrega de TI. Sin la conexión entre el diseñador de API y Exchange. La coherencia y visibilidad que proporcionan las herramientas hacen posible la reutilización, el aumento de la productividad y la eficiencia.

Conclusiones

Debido a la agilidad que nos brindan los API Fragments a la hora de enfrentarnos a una nueva integración y/o API en su fase de diseño de la especificación, creo que es una gran característica que nos brinda MuleSoft con la que poder disponer de un Diccionario de Vocabulario de Términos reutilizables con el que poder tener una coherencia y cohesión cross a toda la entidad en términos de un Modelo de Datos Común (CDM).

Además, los API Fragments no solo nos brindan esta coherencia y cohesión, sino que al juntarlo con las herramientas de Anypoint Platform del Design Center y Exchange, se ven potenciadas en cuanto a la coherencia y visibilidad que nos proporcionan haciendo posible la reutilización, el aumento de la productividad y la eficiencia ante una nueva integración, caso de uso y/o API, pudiendo definir un Ciclo de Vida de una API y un flujo de trabajo mucho más cercano y eficiente necesario para cerrar la brecha en la entrega de TI.