INTRODUCCIÓN A LA ARQUITECTURA DE DESARROLLO DE APLICACIONES EN ICM

Transcripción

1 INTRODUCCIÓN A LA ARQUITECTURA DE DESARROLLO DE APLICACIONES EN ICM Versión 1.2 Área de Aplicaciones Especiales y Arquitectura de Software

2 Hoja de Control Título Documento de Referencia Responsable Introducción a la Arquitectura de Desarrollo de Aplicaciones en ICM Área de Aplicaciones Especiales y Arquitectura de Software Versión 1.2 Fecha Versión 20/01/2015 Registro de Cambios Versión Causa del Cambio Responsable del Cambio Fecha del Cambio 1.0 Versión inicial del documento Área de Aplicaciones Especiales y Arquitectura de Software 19/09/ Se ha modificado el apartado Portal de conocimiento y soporte ya que se han migrado 1.1 todos los contenidos de soja. Área de Aplicaciones Especiales y - Se incluye nueva tecnología Arquitectura de Software 06/06/2012 para la integración de aplicaciones en un Enterprise Service Bus 1.2 Incluido aplicación Desktop Arquitectura de Software 20/01/2015 Página 2 de 48

3 Índice 1 INTRODUCCIÓN PORTAL DE CONOCIMIENTO Y SOPORTE PROYECTOS Y MODULOS PORTFOLIO DE APLICACIONES CONTROL DE VERSIONES DE PROYECTOS DOCUMENTACION DE PROYECTOS TECNOLOGÍAS DE DESARROLLO BASE DE DATOS DESARROLLO DE APLICACIONES TIPOS DE MÓDULOS TECNICOS EN JAVA ARQUITECTURA DE DESARROLLO PARA MODULOS JAVA/ATLAS UTILIDADES SEGURIDAD GESTION DE ACCESOS MODULOS DE TIPO WEB MODULOS DE TIPO WEBSERVICE CERTIFICADOS DIGITALES GESTION DOCUMENTAL ARQUITECTURA DE DESARROLLO DE DOCUMENTUM TIPOS DE MÓDULOS TECNICOS PARA LA GESTION DOCUMENTAL UTILIDADES DE DESARROLLO DE DOCUMENTUM REPORTING ARQUITECTURA DE DESARROLLO PARA CRYSTAL REPORTS TIPOS DE MÓDULOS TECNICOS PARA CRYSTAL REPORTS UTILIDADES DE DESARROLLO DE CRYSTAL REPORTS BUSSINESS INTELLIGENCE ARQUITECTURA DE PROYECTOS BUSINESS INTELLIGENCE TIPOS DE MÓDULOS TECNICOS PARA BUSINESS INTELLIGENCE UTILIDADES BUSINESS OBJECTS ENTERPRISE SERVICE BUS ARQUITECTURA DE ACCESOS DE PROYECTOS ESB TIPO DE MÓDULO TECNICO PARA ESB PORTALES DE CONTENIDOS FATWIRE CONTENT SERVER ARQUITECTURA DE DESARROLLO DE CONTENT SERVER WEB ESTATICA AYUDAS REDIRECCION DE APLICACIONES ACTIVEX GEA (GESTOR DE EXPEDIENTES ADMINISTRATIVOS) TECNOLOGIAS ANTERIORES FRAMEWORK 1 Y ARQUITECTURA DE DESARROLLO PARA MODULOS FRAMEWORK 1 Y UTILIDADES FORMS ARQUITECTURA DE DESARROLLO PARA MODULOS FORMS UTILIDADES DELPHI MICROSTRATEGY OTROS Página 3 de 48

4 ANEXO 1: LISTADO DE TIPOS DE MÓDULOS TÉCNICOS ANEXO 2: FICHA TECNICA DE LAS TECNOLOGÍAS DE DESARROLLO INTRODUCCIÓN En este documento se presentan las distintas tecnologías utilizadas para el desarrollo de aplicaciones de la Comunidad de Madrid. Todos los desarrollos de aplicaciones de la Comunidad de Madrid deberán ajustarse a las tecnologías propuestas en este documento, siguiendo las pautas indicadas por el Área de Aplicaciones Especiales y Arquitectura de Software de ICM. Página 4 de 48

5 2 PORTAL DE CONOCIMIENTO Y SOPORTE Toda la documentación y recursos necesarios para el desarrollo de aplicaciones según las distintas tecnologías están disponibles actualmente en el portal arquitecturasw. El portal ARQUITECTURASW incluye toda la documentación y recursos de los distintos framework y tecnologías seleccionadas para el desarrollo de aplicaciones para la Comunidad de Madrid. Acceso desde Internet: Acceso desde Intranet: Este portal es el canal de comunicación de la Unidad de Arquitectura y Soporte de Aplicaciones hacia los proveedores. Cada vez que se publica información en el portal se incluye una noticia indicando la actualización que se ha realizado. El proveedor por lo tanto tiene la responsabilidad de conectarse asiduamente a este portal para estar al corriente de las modificaciones. Las consultas y sugerencias relacionadas con el desarrollo de aplicaciones se deben dirigir a la Unidad de Arquitectura y Soporte de Aplicaciones a través de la herramienta mantis que se ha incorparado a este portal en la sección Consultas. Atención Este portal sustituye al portal de soja. Todos los contenidos del portal de soja relacionados de Arquitectura de Aplicaciones se han migrado al portal arquitecturasw. Página 5 de 48

6 3 PROYECTOS Y MODULOS Las aplicaciones de la Comunidad de Madrid se definen 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 máximo 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. Cada proyecto se creará como una estructura de carpetas en la que la primera carpeta se corresponde con el nombre del proyecto y por cada módulo se creará una carpeta contenedora de dicho módulo. A continuación se muestra la estructura de carpetas sobre cómo se debe crear un proyecto y sus correspondientes módulos. PROYECTO XXXX Atención MÓDULOS XXXX_MODD XXXX_APP BASE DE DATOS APP WEB xxxx se corresponde con el nombre del proyecto y como podemos ver este nombre forma parte del nombre de los módulos. XXXX_WS XXXX_BATCH XXXX_LIB XXXX_ESB SERVICIO WEB BATCH LIBRERIA PROYECTO ESB Observar que el separador utilizado en el nombre de los módulos es el guión bajo. Posteriormente a lo largo de este documento se irán indicando las distintas nomenclaturas según el tipo de módulo. Dentro de los módulos de un proyecto nos podemos encontrar con distintos tipo de módulos (por ejemplo un módulo de Java, un módulo Documentum, un módulo de base de datos, etc). Página 6 de 48

7 3.1 PORTFOLIO DE APLICACIONES Existe una aplicación que nos permite gestionar el portfolio de aplicaciones de la Comunidad de Madrid. Esta aplicación se llama POAPS. Existen dos versiones de la aplicación, una de gestión de aplicaciones y otra de consulta orientadas a distintos perfiles de usuarios. A continuación se muestran las urls de cada una de de estas aplicaciones. Url de acceso a POAPS GESTION Url de acceso a POAPS CONSULTA CONTROL DE VERSIONES DE PROYECTOS El código fuente de los proyectos se mantendrá en un repositorio de versiones. Actualmente se dispone de dos productos para el control de versiones, dependiendo de las tecnologías: Subversión: Proyectos desarrollados con el framework ATLAS Starteam: Resto de proyectos. Descricpción Nomenclatura Ejemplo StarTeam Así se nombrará el proyecto [proy]_[nnnn] EJPL_0100 dentro de los repositorios de Starteam. En NNNN se indicará la versión del proyecto. Subversion Se creará un repositorio en [proy] ejpl subversión para cada proyecto. En este caso el nombre del repositorio será el nombre del proyecto y si hay varias versiones se crearan distintas carpetas dentro de este repositorio. Página 7 de 48

8 Estos repositorios son de uso interno para la gestión del proyecto dentro de ICM. Para más información sobre el uso de subversion consultar el manual ATLAS_INT_Guia_Uso_Subversion.doc. 3.3 DOCUMENTACION DE PROYECTOS Dentro del ciclo de vida de un proyecto, una de las principales actividades es la Gestión de la Documentación. Es preciso que se controle el proceso de elaboración, validación y difusión de la misma, así como su gestión automatizada y almacenaje. El Sistema de Gestión Integrada de la Documentación de Proyectos (MIDOC) es la herramienta para la gestión de la documentación de cualquier proyecto. Url de acceso a MIDOC Para más información sobre esta herramienta acceder a la siguiente url: Página 8 de 48

9 4 TECNOLOGÍAS DE DESARROLLO En este apartado se presentan las distintas tecnologías de desarrollo que se utilizan actualmente para las nuevas aplicaciones de la Comunidad de Madrid (en el apartado 5 se mostrarán las tecnologías utilizadas anteriormente). 4.1 BASE DE DATOS La base de datos sobre la que se desarrollan las aplicaciones es Oracle 9 y la herramienta de modelado y documentación del modelo de datos debe ser Erwin 7. El modelo de datos de un proyecto debe ser entregado como un módulo técnico según la nomenclatura que se indica en la siguiente tabla y atendiendo al formato de entrega indicado en la normativa antes indicada: Tipo de módulo Descricpción Nomenclatura Ejemplo Modelo de Datos Modulo técnico de base de datos que incluye todo los ficheros relacionados con el modelo de datos: fichero Erwin, ficheros adicionales para la carga inicial de datos, etc) [proy]_modd ejpl_modd Para más información sobre la normativa de Base de datos y uso de la herramienta Erwin consultar el manual Normativa de Uso de Base de Datos y ERWIN 7 así como el Ejemplo de Uso de la Normativa de Base de Datos y ERWIN 7 Página 9 de 48

10 4.2 DESARROLLO DE APLICACIONES El desarrollo de aplicaciones se realizará en Java utilizando el framework Atlas que proporciona ICM. La arquitectura del framework Atlas está basada en tres tecnologías ampliamente extendidas y utilizadas en el desarrollo de aplicaciones Java. Estas tecnologías son: JSF (JavaServer Faces) que se utiliza en la capa de presentación, Spring en la capa de lógica de negocio e Hibernate en el acceso a los datos. Sobre estas tecnologías se ha construido una capa de servicios y herramientas propios de ICM cuya misión es simplificar el desarrollo de aplicaciones, a la vez que facilitar el mantenimiento de las mismas. Entre los servicios que ofrece el framework están los siguientes: Servicio de autenticación y autorización basado en políticas de seguridad predefinidas. Componentes de presentación más habituales en los desarrollos de la Comunidad de Madrid. Servicio de Trazas con información que permite la monitorización de las aplicaciones. Servicio de Auditoría de acceso a datos personales para cumplimiento de la LOPD. Servicios de integración con otras tecnologías: Gestión Documental, Certificados Digitales, Servicios Web, Planificación, Reporting, Bussiness Intelligent, etc. Adicionalmente a estos servicios, para asegurar la calidad del código de las aplicaciones desde su comienzo se han seleccionado una serie de herramientas que facilitan la construcción de pruebas automatizadas, como son JMeter, JUnit y Selenium, y se ha desarrollado la herramienta de ayuda a la verificación automática de la calidad del código. Como base para el arranque de nuevos desarrollos, se proporcionan una serie de Arquetipos o plantillas de partida que incluyen toda la configuración necesaria para utilizar los distintos servicios que ofrece el framework según se indica en la normativa. Actualmente se dispone de arquetipos para aplicaciones web, procesos batch, librerías, servicios web y aplicaciones que se integren con Documentum. En ATLAS, todo el código fuente de las distintas aplicaciones se almacena en un único repositorio centralizado (Subversion). Para la gestión del ciclo de vida de las aplicaciones se utiliza la herramienta Maven, que aporta los siguientes beneficios: 1) Permite la automatización de las tareas más comunes (como la compilación, empaquetado y despliegue de las aplicaciones en los distintos entornos de ICM). 2) Proporciona la gestión automática de las dependencias de un proyecto, descargando todas las librerías necesarias para una aplicación de un repositorio centralizado de librerías (Artifactory). 3) Establece un método único de gestión de la configuración: Permite la gestión de las versiones del framework y de las aplicaciones, lo que aporta control sobre su estado y evolución a lo largo del tiempo. El desarrollo de una aplicación con el framework ATLAS puede implicar la construcción de uno o varios módulos técnicos dependiendo de las necesidades particulares de las mismas. Página 10 de 48

11 Todos los módulos técnicos que se desarrollen con el framework ATLAS tienen que cumplir la normativa correspondiente que se encuentra publicada en el portal arquitecturasw ( TIPOS DE MÓDULOS TECNICOS EN JAVA A continuación se muestran los distintos tipos de módulos técnicos que se pueden implementar y cuál va a ser la nomenclatura. Tipo de módulo Descricpción Nomenclatura Ejemplo APLICACIONES Módulo técnico que contiene [proy]_[descripcion] ejpl_pub WEB una aplicación web. Obligatoriamente llevarán después del código del proyecto un sufijo que identifique lo más claramente posible al módulo (este sufijo no puede ser _web ). PROCESOS Todos los módulos técnicos [proy]_batch_[descripción] ejpl_batch BATCH Java que implementen procesos ejpl_batch_susc a ejecutar en modo Batch, ejpl_batch_cdatos obligatoriamente llevarán después del código del proyecto la partícula _batch. Opcionalmente se podrá incluir un sufijo descriptivo del módulo técnico. Este sufijo será obligatorio en caso de que para un proyecto existan varios módulos Batch. En el caso de que sea un Java Batch para la carga Inicial de datos de Documentum la descripción será cdatos SERVICIOS Los servicios web que se [proy]_ws_[descripción] ejpl_ws WEB necesiten dentro de un proyecto ejpl_ws_envio se crearán como un módulo ejpl_ws_recep técnico específico. Obligatoriamente llevarán Página 11 de 48

12 después del código del proyecto la particula _ws. Opcionalmente se podrá incluir un sufijo descriptivo del módulo técnico. Este sufijo será obligatorio en caso de que para un proyecto existan varios servicios web. LIBRERÍAS Todos los módulos técnicos [proy]_lib_[descripción] ejpl_lib_general Java Librería, obligatoriamente llevarán después del código del proyecto la partícula _lib. Opcionalmente se podrá incluir un sufijo descriptivo del módulo técnico. Este sufijo será obligatorio en caso de que para un proyecto existan varios módulos de tipo librería. APLICACIONES DESKTOP Módulo técnico que contiene una aplicación de tipodesktop. obligatoriamente llevarán después del código del proyecto la partícula _desktop. Opcionalmente se podrá incluir un sufijo descriptivo del módulo técnico. Este sufijo será obligatorio en caso de que para un proyecto existan varios módulos de tipo Desktop. [proy]_desktop_[descripción] ejpl_desktop ejpl_desktop_solicitud Página 12 de 48

13 4.2.2 ARQUITECTURA DE DESARROLLO PARA MODULOS JAVA/ATLAS A continuación se muestra un gráfico con los distintos elementos que forman parte de la arquitectura física de desarrollo donde se van a desplegar los módulos desarrollados con el framework ATLAS antes de proceder a su puesta en producción. desarrollo.madrid.org desarrollo3.madrid.org desmultipki.madrid.org deswebservices.madrid.org desservicios.madrid.org Oracle Web Cache icmcache01 Oracle Web Cache icmcache02 Apache icmdesweb01 Apache icmdesweb02 icmdesbatch Weblogic icmaplides03 Weblogic icmaplides04 Como se puede ver en el gráfico, se dispone de una arquitectura en cluster. La URL de entrada a esta arquitectura depende del tipo de módulos técnico con el que se está trabajando. La solicitud de instalación y ejecución de aplicaciones en el entorno de desarrollo se hará a través de la Unidad de Recepción de Aplicaciones. En los siguientes sub-apartados se detallan cada una de las entradas URLS DE ENTRADA PARA MODULOS TIPO WEB Url Descripción Módulos web sin certificado digital. Aquí también irían los servicios web que tienen que ser visibles desde Internet. Página 13 de 48

14 Módulos web seguros con certificado digital opcional. La aplicación comprueba si el certificado digital es válido para esa aplicación. Módulos web seguros sin certificado digital URLS DE ENTRADA PARA MODULOS TIPO SERVICIO WEB Url Descripción Servicios web de ASF Servicios web internos (solo son invocados por aplicaciones instaladas en los entornos de ICM) Servicios web que son accedidos desde otros ámbitos, por ejemplo Sanidad. A esta url es necesario acceder con un certificado digital al que previamente se haya autorizado el acceso. La autorización de este acceso la realiza la DPI ENTORNOS PARA MODULOS TIPO BATCH El entorno de ejecución de módulos tipo batch es la maquina icmdesbatch UTILIDADES A continuación se muestran algunas utilidades para el desarrollo de aplicaciones. Artifactory: Repositorio de librerías centralizado del framework. Todas las librerías homologadas del framework Atlas se encuentran dentro de este repositorio. En el caso de que se necesite alguna librería adicional debido a un requisito concreto de una aplicación se hará la correspondiente solicitud a la Unidad de Arquitectura y Soporte de Aplicaciones. En ningún caso se podrá utilizar una librería no homologada o autorizada. Este repositorio es el mismo para desarrollo y producción. Url de acceso a ARTIFACTORY (El usuario/contraseña se solicitará a la Unidad de Arquitectura de Aplicaciones) Página 14 de 48

15 MULO_WEB: Esta aplicación web nos permite consultar los logs de aplicaciones en el entorno de desarrollo. Url de acceso a MULO_WEB (Usuario ADMON/ADMON) Página 15 de 48

16 4.3 SEGURIDAD GESTION DE ACCESOS La gestión de acceso a las aplicaciones es el proceso por el cual a un usuario se le asignan los privilegios adecuados para hacer uso de los servicios que ofrece la aplicación MODULOS DE TIPO WEB Según el acceso que se realice a los módulos web este puede ser: 1) Acceso público Módulo de acceso libre que no realiza ningún tipo de control sobre el usuario que se conecta al mismo. Bajo esta categoría se incluyen también los módulos públicos con certificado, cuya única diferencia es la obligatoriedad de que el usuario de acceso tenga un certificado digital de cliente para conectarse. 2) Acceso privado Módulo de acceso restringido que aplicará control de acceso sobre el usuario que se conecta al mismo. Bajo esta categoría se incluyen también los módulos públicos con certificado, cuya única diferencia es la obligatoriedad de que el usuario de acceso tenga un certificado digital de cliente para conectarse. Dentro de acceso privado dependiendo del tipo de usuario tenemos los siguientes: 2.1) Usuarios de INTRANET Acceso mediante usuario y contraseña Los usuarios se identifican mediante usuario/contraseña. La autenticación se realiza verificando la contraseña del usuario contra el repositorio LDAP de aplicaciones. Una vez autenticado, se aplicará el perfil existente en las tablas de USU de la base de datos. Navegador Servidor de aplicaciones INTRANET DASC Cliente de la aplicación XXXX Módulo INTRANET XXXX_WEB Autenticación LDAP aplics Usuario Contraseña Autorización BBDD Meta Directorio USUG Identificación XXXX USU FWs Desarrollo Página 16 de 48

17 2.2) Usuarios de INTERNET Acceso mediante certificado digital Los usuarios se identifican mediante un certificado digital de cliente. La autenticación se realiza validando dicho certificado (caducidad, revocación y políticas de seguridad) contra la plataforma ASF. Una vez autenticado, se aplicará el perfil existente en las tablas de USUI de la base de datos. Navegador Servidor de aplicaciones INTERNET Plataforma MultiPKI (ASF) DASC + Otros Cliente de la aplicación XXXX Módulo INTERNET XXXX_WEB Autenticación XXXX Identificación FWs Desarrollo Autorización XXXX USUI depart. USUI USUI Central Acceso mediante usuario y contraseña (con certificado digital opcional). En primer lugar se ofrece la posibilidad de identificarse con certificado digital de cliente, que se realizaría como se indica en el punto anterior. Si carece del mismo, o no tiene acceso, se pide usuario y contraseña. En tal caso, la autenticación se realiza verificando la contraseña del usuario contra la tabla de usuarios de USUI. Una vez autenticado, se aplicará el perfil existente en las tablas de USUI de la base de datos departamental. Navegador Servidor de aplicaciones INTERNET DASC + Otros Cliente de la aplicación XXXX Módulo INTERNET XXXX_WEB Autenticación USUI depart. Usuario Contraseña Autorización XXXX USUI USUI Central Identificación FWs Desarrollo 2.3) Usuarios de JUSTICIA Tanto la autenticación como la autorización se realizan a través de una capa intermedia formada por un servicio web denominado USUJ_WS. Esta capa aisla el desarrollo de los sistemas finales de autenticación y autorización. Página 17 de 48

18 Acceso mediante certificado digital Los usuarios se identifican mediante un certificado digital de cliente. La autenticación se realiza validando dicho certificado (caducidad, revocación y políticas de seguridad) contra la plataforma ASF. Una vez autenticado, se aplicará el perfil existente en las tablas de USUJ/INTS de la base de datos. Navegador Servidor de aplicaciones JUSTICIA Plataforma MultiPKI (ASF) Cliente de la aplicación XXXX Módulo JUSTICIA XXXX_WEB Autenticación Autorización Módulo USUJ_WS XXXX USUJ / INTS Identificación FWs Desarrollo XXXX USUJ Acceso mediante usuario y contraseña (con certificado digital opcional). En primer lugar se ofrece la posibilidad de identificarse con certificado digital de cliente, que se realizaría como se indica en el punto anterior. Si carece del mismo, o no tiene acceso, se pide usuario y contraseña. En tal caso, la autenticación se realiza verificando la contraseña del usuario contra el repositorio LDAP de aplicaciones. Una vez autenticado, se aplicará el perfil existente en las tablas de USUJ/INTS de la base de datos. Navegador Servidor de aplicaciones JUSTICIA LDAP aplics Cliente de la aplicación XXXX Usuario Contraseña Módulo JUSTICIA XXXX_WEB Autenticación Autorización Módulo USUJ_WS USUJ / INTS Identificación FWs Desarrollo XXXX USUJ DASC Página 18 de 48

19 MODULOS DE TIPO WEBSERVICE Acceso público Servicio de acceso libre. No se realiza ningún tipo de control sobre el cliente. El canal de comunicación no está cifrado. Cliente WS Servidor WS HTTP Acceso público securizado Servicio de acceso libre. No se realiza ningún tipo de control sobre el cliente. Canal cifrado de comunicación. Para establecer la comunicación el cliente debe confiar en el certificado del servidor. Cliente WS Servidor WS HTTPS Trusted CA SSL Server Acceso privado con certificado digital cliente Servicio de acceso restringido. Se realiza control de acceso sobre el cliente identificado por el certificado digital requerido. Canal cifrado de comunicación. Para establecer la comunicación el cliente y servidor deben confiar en sus respectivos certificados. Es habitual que el cliente utilice un tipo de certificado cliente denominado de componente (no personal). Cliente WS Servidor WS HTTPS SSL Client Client trusted Server trusted SSL Server Server trusted de la CAM Servidores Web Caché Página 19 de 48

20 4.3.2 CERTIFICADOS DIGITALES Un certificado digital es un fichero digital intransferible y no modificable, emitido por una tercera parte de confianza (CA), que asocia a una persona o entidad una clave pública (ligada a otra privada que sólo el titular del certificado conoce y posee). Un certificado sirve para: Identificar de forma electrónica a un usuario ante terceros. Cifrar/descifrar datos para que sólo el destinatario del documento pueda acceder a su contenido. Firmar digitalmente de forma que se garantice la integridad de los datos y su procedencia. La CAM dispone de una plataforma de firma electrónica avanzada (ASF) para facilitar todas las operativas criptográficas de las aplicaciones. Las operaciones se pueden realizar en el lado del cliente o en el del servidor. 1) Operaciones en cliente Se realizan con un applet de java que forma parte de la plataforma ASF denominado WebSigner. Este componente agiliza la inclusión de operaciones criptográficas en las aplicaciones, aislándolas de la complejidad derivada del uso de diferentes sistemas operativos, navegadores y máquinas virtuales java. Las funcionalidades disponibles en el componente de firma en cliente son: - Obtención y filtrado de certificados del puesto cliente. - Firma. - Verificación de firma. - Cifrado y descifrado asimétrico. La operativa es la siguiente: - Petición de operación criptográfica a la aplicación. - Verificar aplicación/operación y obtención de restricciones. - Preparación/composición de la página a devolver al navegador del cliente. - Envío a la página del cliente. - Operación autónoma en cliente. Página 20 de 48

21 Cliente de la aplicación XXXX Servidor de aplicaciones Operación cliente Plataforma Firma Avanzada (ASF) Navegador JavaScript WebSigner Módulo XXXX_WEB SOAP Restricciones certificados Restricciones CAs Lógica propia de la página Operar BBDD ASF ASF 2) Operaciones en servidor Se realizan contra los servicios web de la plataforma ASF. Todo lo que interviene en la operativa del servidor (aplicaciones, operaciones, CAs, certificados digitales, etc) está definido en la plataforma. Las funcionalidades disponibles en los servicios son: - Políticas de acceso para las aplicaciones y sus operaciones. - Filtrado de certificados del puesto cliente. - Validación y extracción de datos de un certificado. - Comprobación de revocación. - Firma y verificación de firma. - Sellado de tiempo. - Cifrado y descifrado con algoritmos simétricos y asimétricos. La operativa es la siguiente: - Petición de operación criptográfica a la aplicación. - Verificar aplicación/operación y obtención de restricciones. - Ejecución de operación utilizando API java sobre los servicios web. - Devolución resultado al cliente. Página 21 de 48

22 Cliente de la aplicación XXXX Servidor de aplicaciones Operación servidor Plataforma Firma Avanzada (ASF) Navegador Módulo XXXX_WEB SOAP BBDD ASF ASF Página 22 de 48

23 4.4 GESTION DOCUMENTAL La solución de gestión documental para los proyectos de la Comunidad de Madrid es el gestor de documental de EMC Documentum. Sobre este producto se ha construido una capa de servicios web que permiten el acceso a la plataforma de gestión documental independientemente de la solución elegida y simplificando por lo tanto la integración con esta tecnología. A continuación se muestra un gráfico con las distintas formas de integrar los proyectos con Documentum. MODULO TECNICO YYYY deswebservices.madrid.org/ docu_ws MODULO TECNICO YYYY + DOCU_LIB WEBTOP Documentum Content Server Página 23 de 48

24 4.4.1 ARQUITECTURA DE DESARROLLO DE DOCUMENTUM Introducción a la Arquitectura de Desarrollo En el siguiente esquema se muestra la arquitectura de desarrollo con Documentum: TIPOS DE MÓDULOS TECNICOS PARA LA GESTION DOCUMENTAL A continuación se muestra una tabla con los distintos tipo de módulos que se pueden crear para la gestión documental de un proyecto y su correspondiente nomenclatura. Todos estos módulos técnicos tienen que cumplir la normativa correspondiente que se encuentra publicada en el portal arquitecturasw ( Tipo de módulo Descricpción Nomenclatura Ejemplo MODELO Módulo que contiene la [proy]_docu ejpl_docu DOCUMENTAL docapp y los scripts necesarios para crear el modelo de datos de Documentum JAVAMETODO Para implementar procesos [proy]_jmtd_[descripción] sedp_jmtd_mantenimiento planificados en Documentum, las Página 24 de 48

25 aplicaciones crearán un único módulo de Java Métodos, que contendrá todos los métodos que necesiten ejecutarse en modo batch. TBO Para personalizar la [proy]_tbo_[descripción] funcionalidad por defecto de sedp_tbo_expedientes los eventos asociados a los tipos documentales, se desarrollará un módulo TBO por cada uno de los tipos documentales a personalizar. WEBTOP La personalización del [proy]_webtop sedp_webtop cliente estándar de Documentum se entregará en un módulo aparte UTILIDADES DE DESARROLLO DE DOCUMENTUM A continuación se muestran algunas utilidades para el desarrollo de aplicaciones. WEBTOP: Url de acceso a WEBTOP (Es necesario tener un usuario de acceso) MULO_WEB: Consulta de logs de aplicaciones. Es la misma utilidad de consulta de log de módulos que nos permite también consultar los logs de los servicios web de documentum. El módulo se los servicios web se llama DOCU_WS. Url de acceso a MULO_WEB (Usuario ADMON/ADMON) Página 25 de 48

26 4.5 REPORTING La solución de reporting para los proyectos de la Comunidad de Madrid es el producto SAP Crystal Reports La solución propuesta para el uso de informes con Crytal Reports se basa en la publicación de los informes en la plataforma Business Objects Enterprise corporativa Para más información sobre el uso de Crystal Reports 2008 consultar el manual Utilización de informes de Crystal Reports ARQUITECTURA DE DESARROLLO PARA CRYSTAL REPORTS El siguiente esquema muestra a modo general la arquitectura de la solución propuesta, así como los tres pasos necesarios para mostrar un informe de Crystal Reports 2008: Publicación del informe, Autenticación en la Plataforma, y Apertura del informe: Página 26 de 48

27 4.5.2 TIPOS DE MÓDULOS TECNICOS PARA CRYSTAL REPORTS Tipo de módulo Descricpción Nomenclatura Ejemplo [proy]_crws Módulo técnico que contiene los [proy]_crws sedp_crws informes Crystal Reports de un determinado proyecto que se invocan a través de web services Informes Crystal Módulo técnico que contiene los [proy]_crbo sedp_crbo Report Plataforma informes Crystal Business Objects Reports de un determinado proyecto que se invocan a través de la plataforma de Business Objects Informes Crystal Los informes de Crystal cuya [PROY]_[NNNN].[ext] Reports 10, 11 ejecución se realice bajo plataforma Windows deben seguir ésta nomenclatura. (Los contenidos en un.ear no han de seguirla). Extensión rpt UTILIDADES DE DESARROLLO DE CRYSTAL REPORTS 2008 La principal utilidad es el propio producto Crystal Reports Adicionalmente, a través del portal InfoView se puede acceder a los informes publicados en el portal de Business Objects. o INFOVIEW: Url de acceso a INFOVIEW (Es necesario tener un usuario de acceso) Página 27 de 48

28 4.6 BUSSINESS INTELLIGENCE La solución de Business Intelligence para los proyectos de la Comunidad de Madrid es el producto SAP Business Objects 3.1 SP3 FP3.3. Para más información sobre el uso de Business Objects consultar los siguientes manuales: Libro Blanco de Business Objects Metodología de Desarrollo de proyectos Business Objects Metodología Entregas Incrementales Business Objects ARQUITECTURA DE PROYECTOS BUSINESS INTELLIGENCE A continuación se muestra un esquema con las distintas fases de un proyecto de Business Intelligence y los componentes de la plataforma involucrados: TIPOS DE MÓDULOS TECNICOS PARA BUSINESS INTELLIGENCE Tipo de módulo Descricpción Nomenclatura Ejemplo DATA SERVICES Todos los módulos técnicos de [proy]_bo_etl sedp_bo_etl ETL ETL (Data Services), obligatoriamente llevarán después del código del proyecto el sufijo _bo_etl. DATAWAREHOUSE Todos los módulos técnicos [proy]_bo_dw sedp_bo_dw (INFORMES Y UNIVERSOS DE LA PLATAFORMA BO) Datawarehouse (Business Objects), obligatoriamente llevarán después del código del proyecto el sufijo _bo_dw. Página 28 de 48

29 4.6.3 UTILIDADES BUSINESS OBJECTS Las utilidades para el desarrollo de proyectos de business intelligence se detallan en el documento Libro Blanco de Business Objects. A continuación se listan algunas de ellas: o INFOVIEW: Url de acceso a INFOVIEW (Es necesario tener un usuario de acceso) o CMC (CONSOLA DE ADMINISTRACIÓN): Url de acceso a CMC (Es necesario tener un usuario de acceso) Página 29 de 48

30 4.7 ENTERPRISE SERVICE BUS La solución de integración de servicios web en el Enterprise Service Bus para los proyectos de la Comunidad de Madrid es el producto Oracle Service Bus versión 11g R1. Sobre este producto se ha construido un framework que ofrece una serie de proxys a reutilizar por todos los proyectos ARQUITECTURA DE ACCESOS DE PROYECTOS ESB A continuación se muestra un esquema con los posibles accesos a servicios desplegados en el ESB. Página 30 de 48