ESB NORMATIVA DE DESARROLLO DE PROYECTOS

Transcripción

1 ESB NORMATIVA DE DESARROLLO DE PROYECTOS Versión 1.0 Área de Integración y Arquitectura de Aplicaciones Versión 1.0 Área de Aplicaciones Especiales y Arquitectura de Software

2 Hoja de Control Título Normativa de desarrollo de Proyectos ESB Documento de Referencia Responsable Área de Integración y Arquitectura de Aplicaciones Versión 1.0 Fecha Versión 09/01/2012 Registro de Cambios Versión Causa del Cambio Responsable del Cambio Fecha del Cambio 1.0 Versión inicial del documento y Revisión de formatos (inicializar versión para portal arquitecturasw) Área de Integración y Arquitectura de Aplicaciones 30/05/ de 32

3 Índice 1. INTRODUCCIÓN AUDIENCIA OBJETIVO CONOCIMIENTOS PREVIOS DESCRIPCION ARQUITECTURA DEL ESB EN ICM PROYECTOS, MODULOS ORGANIZACIÓN Y ESTRUCTURA DEL ESB SBCONSOLE: EXPLORADOR DE PROYECTOS COMPONENTES COMUNES DEL ESB (FRAMEWORK): PROYECTO FESB Estructura del Proyecto FESB_ESB Plantillas de proxy Alertas genéricas predefinidas Funcionalidad del Módulo de Auditoría y Control de Excepciones Funcionalidad del Servicio de envío mail TIPOLOGIA DE PROYECTOS PROYECTO SIMPLE: PASARELA DE SERVICIOS + AUDITORÍA PROYECTO COMPLEJO PASOS A SEGUIR EN LA DEFINICIÓN / IMPLEMENTACIÓN DE UN PROYECTO ESB ESTRUCTURA DE CARPETAS INTERFACES: WSDL BUSINESS SERVICES Detalles de Configuración del Servicio Configuración Operativa Reglas de Alertas de SLA PROXY SERVICES Adaptación del Proxy tipo pasarela Detalles de Configuración Configuración Operativa Reglas de Alertas de SLA de 32

4 Adaptaciones del Flujo de Mensajes Arquitectura IN ALERTAS ESPECIFICAS DEL PROYECTO ENTREGA DE PROYECTOS GENERACIÓN DEL EXPORTADO DE PROYECTOS COMPLETOS GENERACIÓN DEL EXPORTADO PARCIAL DE PROYECTOS: ENTREGAS INCREMENTALES A. NORMAS de 32

5 BUENA PRACTICA NORMA ESB (Enterprise Service Bus) 1. INTRODUCCIÓN El presente documento tiene por objeto servir de guía de usuarios para desarrollar módulos técnicos de tipo ESB (Enterprise Service Bus), de manera que se asegure una manera común de trabajar con el producto, el cumplimiento de buenas prácticas y se facilite el trabajo de los equipos que hacen proyectos utilizando esta plataforma en ICM. Los objetivos perseguidos con la realización de este documento de instalación se resumen en los siguientes puntos: Guiar y facilitar la construcción de un módulo técnico de tipo ESB. Estandarizar los componentes del ESB a incorporar o reutilizar en el proyecto ESB a desarrollar. En esta normativa se incluyen dos tipos de indicaciones para el correcto desarrollo de aplicaciones: o Normas: Son requisitos de obligado cumplimiento, y se encuentran definidas dentro de una caja de color azul: NombreDeNorma Contenido de la norma. o Buenas prácticas: Son recomendaciones para el desarrollo. No son de obligado cumplimiento aunque para un correcto funcionamiento se recomienda cumplirlas siempre que sea posible. Se encuentran definidas dentro de una caja de color amarillo NombreDeBuenaPractica Contenido de la Buena Práctica. 5 de 32

6 1.1. AUDIENCIA OBJETIVO Este documento va dirigido a todas aquellas personas de ICM o de sus proveedores que vayan a hacer proyectos de tipo Enterprise Service Bus y por tanto necesiten conocer las normas de desarrollo particulares de la implantación de ICM y otras informaciones o recomendaciones de interés CONOCIMIENTOS PREVIOS Para un completo entendimiento del documento, el lector deberá tener conocimientos previos: Oracle Service Bus. Nociones básicas de Oracle Weblogic Server. 2. DESCRIPCION ARQUITECTURA DEL ESB EN ICM En ICM el producto elegido como solución Enterprise Service Bus es el Oracle Service Bus, en la actualidad la versión 11g R1. Dentro de las posibles soluciones de implementación de módulos de ESB, se acota que éstas, en principio serán desarrollos de módulos ESB simples de tipo pasarela, es decir, su funcionalidad básica será recibir peticiones de clientes a servicios finales, realizar auditoría y control de excepciones, encaminar dichas peticiones al servicio, recoger las respuestas y finalmente devolverlas a los clientes. La representación gráfica de este tipo de módulos es: OSB Proxy Service Pipeline Pipeline Business Service xxxx_ws clientes Envío de mail Informes Panel de control 6 de 32

7 Con el objeto de reutilizar componentes comunes así como el de normalizar la estructura de las soluciones implementadas en el OSB, se ha creado e implantado en el OSB, el módulo FESB_ESB. Dentro de este módulo se incluye una plantilla de proxy que ya tiene implementada la funcionalidad básica de auditoría y control de excepciones. En principio, todos los módulos que se desarrollen en el OSB deberán partir de esta plantilla. 3. PROYECTOS, MODULOS Las aplicaciones de la Comunidad de Madrid se definirán en el marco de un proyecto, denominando a las distintas aplicaciones que se desarrollen para un proyecto módulos. Por lo tanto podemos decir que un proyecto es un conjunto de módulos. Todos los proyectos de la Comunidad de Madrid tienen un nombre de 4 letras que identifican al proyecto y que van a ser fundamentales en la nomenclatura de muchos de los elementos del proyecto por lo tanto es fundamental disponer de este identificador antes de abordar ningún tipo de desarrollo. A continuación se muestra la estructura de carpetas sobre como se debe crear un proyecto y sus correspondientes módulos. 7 de 32

8 PROYECTO XXXX MÓDULOS XXXX_MODD BASE DE DATOS XXXX_APP APP WEB XXXX_WS SERVICIO WEB XXXX_BATCH BATCH XXXX_LIB LIBRERIA XXXX_ESB PROYECTO ESB Atención xxxx se corresponde con el nombre del proyecto y cómo podemos ver este nombre forma parte del nombre de los módulos. Observar que el separador utilizado en el nombre de los módulos es el guión bajo. Dentro de los módulos de un proyecto nos podemos encontrar con módulos de tipo ESB, que ofrecen un acceso a un webservice del proyecto pero a través del Enterprise Service Bus. 8 de 32

9 NORMA NORMA ESB (Enterprise Service Bus) IMPLESB Para implementar un módulo ESB se creará con la siguiente nomenclatura: xxxx_esb donde xxxx se corresponde con el nombre del proyecto 4. ORGANIZACIÓN Y ESTRUCTURA DEL ESB 4.1. SbConsole: EXPLORADOR DE PROYECTOS En la consola del ESB, la opción explorador de proyectos enumera todos los proyectos del dominio. Los proyectos del ESB no son jerárquicos, no se superponen ni se pueden agrupar en un nivel superior. Todos los recursos utilizados por el ESB, residen siempre dentro de un proyecto, se pueden crear directamente sobre el proyecto o se pueden organizar mediante carpetas. Nomenclatura de proyecto En el OSB el nombre del proyecto debe ser: XXXX_ESB, donde XXXX es el acrónimo del proyecto. 9 de 32

10 4.2. COMPONENTES COMUNES DEL ESB (FRAMEWORK): PROYECTO FESB Tal y como se dijo en el apartado inicial Descripción, todos los módulos técnicos de tipo ESB, reutilizaran elementos comunes, utilidades y plantillas que se encuentran en el proyecto FESB. Los objetivos principales de este proyecto ESB son: Reutilización de componentes en tiempo de ejecución Este proyecto contendrá componentes que podrán ser llamados desde otros proyectos. Por ejemplo, alertas, auditoría y control de excepciones. Normalización de componentes: Uso de plantillas Incorporará una serie de plantillas según el tipo de proxy a desarrollar, que ya tendrá incorporados elementos generales comunes Estructura del Proyecto FESB_ESB En los entornos de ICM, en el Oracle Service Bus se encuentra desplegado el módulo FESB_ESB que corresponde con el concepto de proyecto del producto OSB Plantillas de proxy En este apartado se indican las plantillas de proxy actualmente accesibles. Las plantillas se ubican en el proyecto FESB, en la ruta: Proxy Llamada simple a Business: proxy_pasarela La finalidad de los proxys que utilicen esta plantilla, sería simplemente de ejercer de pasarela al servicio final pero añadiendo funcionalidades tales como trazas, auditoría y control de excepciones. Tendrá el siguiente formato: 10 de 32

11 Alertas genéricas predefinidas En el OSB se pueden definir destinos de alerta, estas alertas se podrán activar desde cualquier proxy o desde cualquier SLA definido en un business o proxy. Cuando se activa una alerta, ésta aparecerá en la consola del OSB, en el Panel de Control. Si la alerta se activa desde el flujo de un proxy, se mostrará en la solapa Alertas de Pipeline. Y si la alerta se activa desde una regla de alertas de SLA, se mostrará en la solapa Alertas de SLA. Cada proyecto puede definirse sus propios destinos de alerta, pero dentro del proyecto FESB están predefinidos, en la plantilla FESB_Plantilla_proxy_pasarela_PS, tres destinos de alerta que se activarán cuando se produzcan errores en el flujo de un proxy. Las alertas definidas son: Enrutador Alertas Críticas Enrutador Alertas Medias Enrutador Alertas Warning No hay alertas definidas del tipo SLA en el proyecto FESB 11 de 32

12 Funcionalidad del Módulo de Auditoría y Control de Excepciones Todos los proxys públicos como utilizarán la plantilla definida, ya tendrán implementada la llamada al proxy de auditoría y el control de excepciones, en concreto, las llamadas al proxy de auditoría están incluidas en los stages: Arquitectura_IN y Arquitectura_OUT Configuración en el stage Arquitectura_IN En el stage Arquitectura_IN, en la plantilla, vienen definidas unas variables que servirán para localizar una determinada petición en las trazas del ESB. En concreto las variables son: IdProyecto: contendrá el valor XXXX es el acrónimo del proyecto. IdPeticion: proyecto + fecha + hora IdOperacion: Nombre del proxy IdReq: operación solicitada en la petición Ejemplo de stage Arquitectura_IN: 12 de 32

13 NORMA ESB (Enterprise Service Bus) Cuando se parte de la plantilla, sólo hay que sustituir XXXX por el código de proyecto, el resto de variables se completan de forma automática en la ejecución del proxy. Variables de proyecto: IdProyecto En los proxys públicos, en el stage Arquitectura_IN hay que informar el dato de la variable: IdProyecto: contendrá el valor XXXX es el acrónimo del proyecto Esquema XSD auditoria El módulo de auditoría para su ejecución, recibe unos parámetros en formato xml, y por tanto tendrá un comportamiento u otro, dependiendo de la información que se le indique en la llamada. El XSD del parámetro: 13 de 32

14 Ejemplo de definición de variable: (En este ejemplo se puede ver dónde se configura la variable TrazaIN) TrazaIN contiene: Comportamiento del módulo de Auditoría El proxy módulo de auditoría tiene la siguiente estructura: 14 de 32

15 En el stage gestión de la traza se realizará: Si la etiqueta REPORT = 1 : Se generará un informe con el contenido de la variable TraceIN y con las claves: Proyecto-Petición-Request) Si la etiqueta MAIL = 1 : Se enviará un mail a los destinatarios indicados en la etiqueta MAIL-TO. Si la etiqueta ALERT = 1 : Se activará una de las siguientes alertas (Critica, Media, Warning) dependiendo de la etiqueta ALERT_SEVERITY (CRITICAL, MAJOR, resto ) Tratamiento de excepciones Las excepciones se capturan a dos niveles, en el stage de enrutado y en el proxy general: 15 de 32

16 El proxy para el tratamiento de excepciones es el mismo que para la gestión de auditoría, utiliza el mismo proxy y esquema xsd, el comportamiento dependerá de los parámetros indicados en el xml pasado en la llamada. Ejemplo de proxy: Funcionalidad del Servicio de envío mail Dentro del framework está habilitado un proxy de uso local, que posibilita el envío de mail, dicho proxy está configurado para recibir un mensaje xml basado en el esquema fesb_esquema_mail.xsd. En el caso de querer enviar mail, particulares para un proyecto, para utilizar el proxy FESB_EnvioMail_LPS, en el pipeline dónde se requiera, habría que incluir un stage de publicar que realice la publicación al proxy, y se debe sustituir el body por los parámetros adecuados del mail. Ejemplo: En la versión actual del proxy, sólo se admiten envíos de mails sin anexos, por lo tanto sólo se utilizarán los parámetros: to, subject, content. 16 de 32

17 Ejemplo: 5. TIPOLOGIA DE PROYECTOS 5.1. PROYECTO SIMPLE: PASARELA DE SERVICIOS + AUDITORÍA Los proyectos ESB simples tendrán una funcionalidad básica de pasarela al webservice, pero con las utilidades ya incorporadas en las plantillas de auditoría y alertas de servicio PROYECTO COMPLEJO Para ésta versión de normativa, no se especifica metodología de desarrollo para proyectos más complejos. Los proyectos que tengan un alcance mayor deberán consultarse al grupo de arquitectura del software. 6. PASOS A SEGUIR EN LA DEFINICIÓN / IMPLEMENTACIÓN DE UN PROYECTO ESB En este apartado se indicarán los componentes básicos para generar un proyecto simple de ESB Estructura de Carpetas Dentro de la Estructura interna del Oracle Service Bus, cada uno de los proyectos del ESB, tendrá una carpeta, y ésta a su vez, se estructurará en una serie de directorios y subdirectorios que agruparán sus componentes. (Ver pantalla de ejemplo). 17 de 32

18 NORMA NORMA ESB (Enterprise Service Bus) Estructura de Directorios Un proyecto ESB, debe tener la estructura dividida en público y privado para contener los distintos componentes según su uso. Al menos contendrá: 6.2. Interfaces: WSDL El primer paso para desarrollar un proyecto ESB es importar la definición del servicio al que llamará el ESB. Ubicación de los archivos WSDL Los archivos WSDL deberán incluirse dentro de las carpetas privado/interfaces Business Services Se generará un al menos un Business Service para cada interface del proyecto. 18 de 32

19 NORMA ESB (Enterprise Service Bus) Nomenclatura y ubicación de los Business Services Los Business Services deben definirse según la nomenclatura: XXXX_<Descripción>_BS Donde: XXXX es el acrónimo del proyecto. <Descripción> será un texto si caracteres especiales Se ubicarán en el directorio: XXXX_ESB/privado/definicion_servicios Detalles de Configuración del Servicio En este apartado se indican una serie de recomendaciones en la configuración del Business Configuración de tipo de Transporte El protocolo para proyectos sencillos siempre será http. Para otros protocolos se deberá consultar al Área de Aplicaciones Especiales y Arquitectura de Aplicaciones Algoritmo de balanceador El algoritmo de balanceo de carga deberá ser round-robin Punto final de acceso al servicio Dado que los entornos de ICM están configurados con alta disponibilidad, los Business deberán tener configurado dos URI s Parámetros de Reintentos Al disponer de dos servidores en todos los entornos, se recomienda que el número de reintentos sea 1, y el intervalo de reintento 5 segundos. En principio, Retry Application Errors tendrá el valor a false. Salvo que por requerimientos concretos, sea necesario realizar reintentos cuando se produzca un soap fault Nivel autentificación (No, Básico, Certificado) 19 de 32

20 Para proyectos sencillos en nivel de autentificación será No. Si fuera necesario otro tipo de autentificación, se deberá consultar al Área de Aplicaciones Especiales y Arquitectura de Aplicaciones Configuración Operativa En principio se mantendrán los siguientes valores, salvo justificación: Por defecto, estarán deshabilitadas las trazas en consola pero si activada la monitorización del servicio cada 10 minutos Reglas de Alertas de SLA Por regla general, se crearán dos reglas de SLA que se encargarán de activar las alertas cuando no esté disponible uno de los servidores del servicio final, o cuando los dos servidores no estén activos. Cada regla necesitará una alerta específica que se activará cuando se cumplan las condiciones indicadas en la regla. 20 de 32

21 A continuación se incluyen dos ejemplos de ambas reglas: Ejemplo de alerta Major 21 de 32

22 Ejemplo de alerta Fatal 6.4. Proxy Services Para cada uno de los proxy a implementar en el ESB, se indicaran una serie de parámetros o indicaciones. Dependiendo del tipo de proxy a implementar, se utilizará una plantilla u otra, en principio está definida la plantilla para proyectos que únicamente realicen de pasarela a servicios web Adaptación del Proxy tipo pasarela En el proyecto FESB_ESB, están ubicados las plantillas proxy, concretamente en el directorio privado/herramientas/plantillas: 22 de 32

23 NORMA ESB (Enterprise Service Bus) Se duplicará el proxy: FESB_Plantilla_proxy_pasarela_PS según la norma: Nomenclatura y ubicación de los Proxy Services Los Proxy Services deben definirse según la nomenclatura: XXXX_<Descripción>_PS Donde: XXXX es el acrónimo del proyecto. <Descripción> será un texto si caracteres especiales Se ubicarán en el directorio: XXXX_ESB/privado/publicacion_servicios Partiendo del proxy duplicado, habría que modificar: Detalles de Configuración Configuración General o WSDL Web Service Se actualizará con el wsdl del webservice. Deberá seleccionarse del directorio interface. 23 de 32

24 NORMA ESB (Enterprise Service Bus) Configuración de Transporte o Endpoint URI Se actualizará con la dirección dónde se atenderán las peticiones al proxy. Para los entornos de ICM, según la arquitectura del ESB, la ruta será relativa. Por ejemplo: Enpoint URI del Proxy La URI debería ser relativa, teniendo en cuenta que la URL final sería: Siendo <host-esb> la dirección utilizará en el balanceador que direcciona al esb. Por ejemplo: desesb.madrid.org Configuración Operativa Se mantendrá la siguiente configuración: 24 de 32

25 Reglas de Alertas de SLA Inicialmente la plantilla proxy, contiene dos alertas que pueden modificarse o eliminarse según los requerimientos del proyecto. A continuación se muestra la configuración de ambas reglas: 25 de 32

26 En caso de definir reglas de alerta SLA, se deberán crear según la normativa definida. 26 de 32

27 Adaptaciones del Flujo de Mensajes El proxy hay que adaptarlo para que las trazas que se generan sean uniformes, para ello partiendo del flujo: El flujo de mensajes definido en la plantilla del proxy tiene dividido el flujo para diferenciar la entrada (petición) y la salida (respuesta) de los mensajes, y además, contempla manejadores de excepciones a dos niveles: en el enrutado y general al proxy que hay que adaptar. Las modificaciones a realizar son: Arquitectura IN Se editará la etapa Arquitectura IN para crear las variables locales: Id Proyecto IdPeticion IdOperacion IdReq Y definir la variable traza: TrazaIN 27 de 32

28 Sólo se modificará el contenido de la variable IdProyecto, con el código del proyecto. (Ver Componentes Comunes del ESB del presente documento) 28 de 32

29 NORMA NORMA ESB (Enterprise Service Bus) 6.5. Alertas especificas del proyecto Las alertas que se activen en los flujos de proxy, deberán cumplir la norma: Nomenclatura de Alertas Las alertas de un proyecto deben definirse según la nomenclatura: XXXX_Alerta_YYY_<nivel alerta> Donde: XXXX es el acrónimo del proyecto. YYY será PIP o SLA dependiendo del uso de la alerta <nivel alerta> podrá ser: critica, media, warning Las alertas que se activen en las reglas SLA, deberán cumplir la norma: Nomenclatura y ubicación de las alertas SLA Las alertas se deben definirse según la nomenclatura: XXXX_Alerta_SLA_<Criticidad> Donde: XXXX es el acrónimo del proyecto. <Criticidad> Será un texto sin caracteres especiales. Los valores podrían ser: critica, fatal, warning, major. Se ubicarán en el directorio: XXXX_ESB/publico/alertas_SLA 29 de 32

30 7. ENTREGA DE PROYECTOS 7.1. Generación del Exportado de proyectos completos Como punto de partida para el paso entre entornos de proyectos esb, se generará el exportado desde la consola ESB. Las opciones para exportar serán Exportar Proyectos y no incluir dependencias. 30 de 32

31 NORMA ESB (Enterprise Service Bus) Nomenclatura y opciones de exportado de proyectos Las opciones en el Export serán: Exportar Proyectos El nombre der archivo exportado tendrá la nomenclatura: xxxx_esb.jar (Donde: xxxx es el acrónimo del proyecto en minúsculas) 7.2. Generación del Exportado parcial de proyectos: entregas incrementales Para entregas incrementales, el procedimeinto será el mismo pero seleccionando mediante un check aquellos componentes que se quieran exportar. 31 de 32

32 A. NORMAS IMPLESB... 9 NOMENCLATURA DE PROYECTO... 9 VARIABLES DE PROYECTO: IDPROYECTO ESTRUCTURA DE DIRECTORIOS UBICACIÓN DE LOS ARCHIVOS WSDL NOMENCLATURA Y UBICACIÓN DE LOS BUSINESS SERVICES NOMENCLATURA Y UBICACIÓN DE LOS PROXY SERVICES NOMENCLATURA DE ALERTAS NOMENCLATURA Y UBICACIÓN DE LAS ALERTAS SLA NOMENCLATURA Y OPCIONES DE EXPORTADO DE PROYECTOS de 32