Data Loading...
ASO: API Steward Office, Oficina Administrativa de APIs. Organismo encargado de asegurar las pautas básicas de diseño de SN, con el fin de favorecer su homogeneidad y su reutilización, así como promover su uso, tanto dentro como fuera de BBVA. Los SN son una de las piezas principales de la estructuración en tres capas de las aplicaciones en BBVA.
ASO realiza el gobierno centralizado de servicios.
Las funciones de ASO son las siguientes: Definición del concepto de SN Identificación, en cada proyecto o iniciativa, de qué se considera SN Aprobación de los diseños de SN a ser creados, modificados y reutilizados Gestión del ciclo de vida de los SN Asegurar el cumplimiento de todas las normas del modelo de gobierno de servicios Definición y mantenimiento del MCD Gestión de un catálogo de errores comunes a todos los aplicativos SMC: Unidad atómica de funcionalidad (operación), que garantiza única unidad transaccional SN: Agrupación de operaciones con sentido funcional, favoreciendo a la reutilización por consumidores de distinta naturaleza y garantizando la capacidad de interaccionar entre sistemas dispares, que pueden ser consumidos sin conocer la tecnología que los soporta. Los SN se pueden remotizar mediante diferentes tecnologías, como REST, HTTPInvoker o SOAP.
API: Agrupación de SN con sentido funcional determinado. Se utilizan para exponer un conjunto de necesidades a consumidores externos. Conector técnico: Componentes que facilitan el acceso a los distintos backends, aislando el desarrollo de la complejidad de acceso a éste. Son utilizados desde la implementación de los SN. Repositorio de SN. Sería ideal mantener un repo similar a ETHER. Modelo de Diseño: Orientado a Recurso, modo por defecto Orientado a Acciones: por situaciones especiales Diseño de Servicios de Negocio MCD: DyD durante el diseño de un SN identificarán las entidades con las que éste trabajará, y definirán su estructura. Algunas de estas entidades podrán ser consideradas universales. ASO gobernará y homogeneizará la nomenclatura de estas entidades, de modo que siempre se utilicen los mismos términos para cada uno de los conceptos bancarios, y con la misma estructura. Diseño Multi-* El servicio debe ser capaz de ofrecer la misma funcionalidad para todos los ejes multi definidos en BBVA: Multicanal / multidispositivo Multientidad Multidioma Multidivisa Sin Sesión Los SN no disponen de acceso a sesión. Es decir, no se puede almacenar el estado del servicio o información contextual relativa a la llamada y que pudiera variar en función del instante de la petición. Sin acceso a contexto Durante la ejecución de un servicio, existe una serie de datos de contexto, relativos a la aplicación llamante, de uso exclusivo de la Arquitectura de Servicios. Esta información no es accesible desde un SN. Por tanto, no será posible particularizar el comportamiento de un SN en función de la aplicación llamante (multicanal). Sin embargo, los conectores proporcionados por Arquitectura de Servicios si tendrán acceso a esta información, y la emplearán para comunicarse con los distintos backends. A priori, el interfaz de un servicio no incluirá como parámetros datos accesibles por las transacciones en su contexto de Arquitectura (país, banco, divisa, canal, etc.). Cuando el backend asociado al servicio necesite hacer uso de dichos campos para llevar a cabo su operativa, accederá a su contexto de Arquitectura para obtener dicha información. Solamente se incluirá en el interfaz del servicio estos parámetros cuando el servicio funcionalmente necesite trabajar con datos distintos a los almacenados en contexto.
Prohibido llamar a otros SN El servicio puede realizar llamadas a la siguiente capa de la arquitectura, es decir, a los backends que corresponda en cada caso, pero no a otro SN. Gestión de errores normalizada
Únicamente lógica de integración El SN en ningún caso contendrá presentación ni lógica de negocio. Tiene que estar totalmente aislado de la capa de presentación. Toda la lógica de negocio debe residir en el backend, mientras que la lógica de presentación estará en el frontend. Cualquier tratamiento adicional sobre la información que se necesite realizar antes o después de la llamada a los backends debe ser analizada por ASO. Sin cache Los SN, dada si naturaleza de meros mediadores entre la capa cliente y el backend, no deberían utilizar mecanismos de cache de datos. No obstante, es posible solicitar a ASO la incorporación de esta característica únicamente para su aplicación en operaciones de consulta de datos estáticos o de poca volatilidad**. La caché que se utilice requerirá una configuración tal que establezca mecanismos de refresco de los datos con cierta periodicidad. Subrecursos Un subrecurso es un recurso que se encuentra anidado bajo otro recurso. Realmente, un subrecurso solo puede existir si existe el recurso bajo el que se ubica. ASO limita la profundidad máxima a dos niveles, de tal forma que, como máximo, podremos tener: /complaints/123/issues/456/entries/789 Otros tipos de relación La abstracción de subrecursos se emplea habitualmente para reflejar un grado de relación fuerte: el subrecurso sólo tiene sentido dentro del ámbito del recurso bajo el que se ubica. Es posible trabajar con grados de relación más débiles /a/123 /b/456 -> href: /a/123 También se permite: /a/123 /b/456/a/123
Especificar exactamente qué información se desea obtener Es posible especificar exactamente qué atributos de un recurso deseamos obtener: ?$fields=[atribute],[aribute],… Es posible especificar también subatributos: ?$fields=id, target(status, claimedBank) , cannel.id Esta opción estará limitada a las posibilidades de los distintos backends Expandir subrecursos Los subrecursos normalmente se incluyen en la representación del recurso que los contiene, en forma de hipervínculo. Es posible solicitar que la representación de un subrecurso sea incluida en la representación del recurso que lo contiene. ?$expands=[subresource] , [subresource], . . . Por ejemplo: ?$expands=issues, complaints Filtrado Es posible indicar opciones de filtrado con sintaxis Feed Item Query Languages (FIQL)