TIVA Versión 1.0
Hoja de Control Título WebRatio Normativa Documento de Referencia Responsable Área de Integración y Arquitectura de Aplicaciones Versión 1.0 Fecha Versión 19/09/2012 Registro de Cambios Versión Causa del Cambio Responsable del Cambio Fecha del Cambio 1.0 Versión inicial del documento Área de Integración y Arquitectura de Aplicaciones 19/09/2012 2 de 37
Índice 1. INTRODUCCIÓN... 5 1.1. AUDIENCIA OBJETIVO... 5 1.2. CONOCIMIENTOS PREVIOS... 5 2. DESCRIPCION... 6 3. PORTAL PARA EL DESARROLLO DE APLICACIONES... 6 4. ENTORNO DE DESARROLLO... 6 5. PROYECTOS Y MODULOS... 7 6. ARQUITECTURA... 9 6.1. CONFIGURACIÓN... 9 6.2. PRESENTACION... 10 6.2.1. Internacionalización... 11 6.2.2. Estructura y decoración de la página... 12 6.2.3. Normas de estilo... 13 6.2.4. Interfaces ricas de usuario (RIA)... 14 6.3. SERVICIOS DE NEGOCIO... 14 6.3.1. MANEJO DE ERRORES Y EXCEPCIONES... 14 6.3.2. TRANSACCIONALIDAD... 14 6.3.3. FICHEROS TEMPORALES... 15 6.4. ACCESO A DATOS... 15 6.4.1. Datasource y Sesiones de Hibernate... 15 6.4.2. Entidades volátiles... 16 6.4.3. Tipos de datos BLOB... 16 6.4.4. Uso de sentencias SQL/HQL... 17 7. SERVICIOS BASICOS... 18 7.1. SERVICIO DE AUTENTICACION Y AUTORIZACION... 18 3 de 37
7.2. COMPONENTES DE PRESENTACION... 20 7.3. SERVICIO DE TRAZAS... 21 7.4. SERVICIO DE AUDITORIA DE SEGURIDAD... 21 8. INTEGRACION... 22 8.1. SERVICIO DE INVOCACIÓN DE SERVICIOS WEB... 22 8.2. SERVICIO DE GESTIÓN DOCUMENTAL... 23 8.3. SERVICIO DE PLANIFICACION... 23 8.4. SERVICIO DE CERTIFICADOS DIGITALES... 24 8.5. SERVICIO DE PROCESOS DE NEGOCIO... 24 8.6. INFORMES (REPORTING)... 25 8.7. COMPOSICION DE DOCUMENTOS... 26 8.8. GESTION DE DOCUMENTOS EXCEL... 26 8.9. GENERACION DE GRAFICOS... 27 8.10. USO ARCHIVOS MULTIMEDIA... 27 8.11. XML... 28 8.12. ENVIO DE CORREO... 28 8.13. ENVIO DE SMS... 29 9. HERRAMIENTA DE CALIDAD... 30 9.1. HERRAMIENTA DE VALIDACIÓN... 30 9.2. DEBUG... 30 10. PRUEBAS... 30 10.1. TIPOS DE PRUEBAS... 31 10.2. PLAN DE PRUEBAS... 31 10.3. DOCUMENTACION DEL MODELO... 32 11. ENTREGA... 33 A1.1 S... 35 A1.1 BUENAS PRACTICAS... 37 4 de 37
1. INTRODUCCIÓN La presente guía presenta la herramienta WebRatio para el desarrollo de aplicaciones para la Comunidad de Madrid y establece la normativa a cumplir en estos desarrollos. En esta normativa se incluyen dos tipos de indicaciones para el correcto desarrollo de aplicaciones: Normas: Son requisitos de obligado cumplimiento, y se encuentran definidas dentro de una caja de color azul: NombreDeNorma Contenido de la Norma 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. NombreDeBuenaPractia BUENA PRACTICA Contenido de la Buena Práctica 1.1. AUDIENCIA OBJETIVO Este documento va dirigido a jefes de proyecto, analistas y desarrolladores de proyectos que utilicen WebRatio. 1.2. CONOCIMIENTOS PREVIOS Se recomienda tener al menos un conocimiento básico de la aplicación WebRatio y de las tecnologías empleadas en el desarrollo de aplicaciones web para un completo entendimiento del documento. Sin embargo, puede servir de guía para cualquier persona que vaya a iniciarse en el desarrollo de proyectos sobre WebRatio o quiera conocer qué funcionalidad y posibilidades de desarrollo se ofrecen. Otras aplicaciones/herramientas relacionadas: Eclipse, Subversion, Tomcat, BB.DD. Oracle y Jmeter. 5 de 37
2. DESCRIPCION WebRatio es una herramienta para el desarrollo de aplicaciones web basada en el concepto Model Driven Development (MDD) y Domain Specific Languages (DSL), que permite modelar gráficamente la aplicación y generar código java directamente. Además cuenta con la posibilidad de diseñar procesos de negocio con BPMN y crear el modelo WebML a partir de dicho modelo del proceso. 3. PORTAL PARA EL DESARROLLO DE APLICACIONES Toda la documentación y recursos de WebRatio se encuentra accesible en el portal para el desarrollo de aplicaciones de la Unidad de Arquitectura y Soporte de Aplicaciones en la URL: http://desarrollo.madrid.org/arquitecturasw Esta web es el canal de comunicación de la Unidad de Arquitectura y Soporte de Aplicaciones hacia los desarrolladores. Cada vez que se publica algo en la web se incluye una noticia indicando la actualización que se ha realizado. El desarrollador por lo tanto tiene la responsabilidad de conectarse asiduamente a esta web para estar al corriente de las modificaciones. Las consultas relacionadas con el desarrollo de aplicaciones se deben dirigir a la Unidad de Arquitectura y Soporte de Aplicaciones a través del portal para el desarrollo en el apartado Contactar con Arquitectura en la página de Inicio. 4. ENTORNO DE DESARROLLO En el manual WR_MUS_Preparacion_Entorno_Desarrollo detalla la relaciones de productos, el proceso de instalación y preparación del entorno para el desarrollo de aplicaciones con WebRatio. 6 de 37
Entorno El desarrollador deberá trabajar con el entorno de desarrollo definido por ICM en cuanto a productos y versiones de los mismos. Las aplicaciones deberán desarrollarse teniendo en cuenta que las aplicaciones web y servicios web se van a ejecutar en varias maquinas virtuales (cluster) por lo tanto los objetos que se dejen en la memoria de la maquina virtual o los ficheros de filesystem no estarán replicados en las diferentes instancias a no ser que se disponga de un mecanismo para ello. EntornoEjecucion Las aplicaciones se desplegarán en el servidor de aplicaciones Oracle Weblogic 10.3.3 y se ejecutarán con la JDK JRockit 1.6.0_20 por lo tanto el código entregado deberá estar preparado para funcionar correctamente en este servidor de aplicaciones. Aunque se utilice otro servidor distinto para el desarrollo de la aplicación (por ejemplo Tomcat), deberá probarse la aplicación en Weblogic antes de proceder a su entrega. 5. PROYECTOS Y MODULOS En general, 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. Sin embargo, el proceso de desarrollo con WebRatio, que integra la gestión del modelo de datos, orienta el desarrollo hacía proyectos con una única aplicación (módulo único). Las aplicaciones diseñadas con WebRatio cuentan con la posibilidad de gestionar diversas secciones denominadas SiteViews para la organización de los modelos, por tanto no existe la necesidad de varios módulos independientes. Internamente, todos los proyectos de la Comunidad de Madrid tienen un nombre de 4 letras que identifican al proyecto. Este nombre va a ser utilizado 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. La disponibilidad de este código puede obtenerse consultando la aplicación POAPS en la URL: http://intranet.madrid.org/poaps 7 de 37
ATENCIÓN xxxx se corresponde con el nombre del proyecto y como 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. NombreArchivo Los nombres de los archivos sólo pueden estar formados por caracteres [a-z] y guiones medio y bajo, no pudiéndose utilizar caracteres acentuados ni la letra eñe. En los nombres de los archivos pueden utilizarse letras mayúsculas cuando sea conveniente. Template Todos los proyectos deberán desarrollarse a partir de una copia del proyecto ICM_Plantilla que debe tenerse instalado en el entorno de desarrollo. Se utilizará la última versión del template, correspondiente a la versión actual de la normativa y el entorno de desarrollo. EstiloUnits Adicionalmente a utilizar el template como punto de partida, antes de comenzar el desarrollo de un proyecto se instalará el estilo ICM_Style, así como todas las Units que se indican en el manual WR_MUS_Preparacion_Entorno_Desarrollo. 8 de 37
Versionado Todos los proyectos deben versionarse utilizando los mecanismos de versionado que ofrece Subversion (según se indica en la Guía de Uso de Subversion). Siempre que se realicen modificaciones sobre una aplicación y se proceda a una entrega (en cualquier entorno), se ha de modificar el número de versión. El número de versión estará formado por tres dígitos. Ejemplo: 1.0.3 La primera versión de un proyecto será la 1.0.0 NomEntidades Los nombres de las entidades del modelo de datos deben empezar por XXXX_, siendo XXXX el código del proyecto. 6. ARQUITECTURA Tanto el modelo como el código generado por WebRatio cuenta con una estructura en tres capas: presentación, datos y lógica de negocio. Cada capa está soportada por una tecnología, destacando la capa de servicios con Struts y el acceso a datos con Hibernate. 6.1. CONFIGURACIÓN En todas las aplicaciones es necesario establecer ciertos parámetros que permitan modificar el estado o la configuración del sistema. Así, por ejemplo, a la hora de desarrollar una aplicación se suelen definir constantes y valores predeterminados que quizás interese cambiar a lo largo del tiempo, por lo que incluirlos en el código sería un grave error ya que cada modificación implicaría una recompilación del código. Además dentro de estas configuraciones nos podemos encontrar con configuración que depende del entorno en el que se ejecute la aplicación (local, desarrollo, validación y producción) y la que no depende de dicho entorno. En WebRatio, las variables de la aplicación así como las de configuración y sus valores se almacenan en un fichero webratio.properties para poder ser modificado según el entorno. 9 de 37
La incorporación de variables y valores se realizará en los procesos de paso entre entornos, siendo recogida dicha información de las solicitudes de paso a producción. Los ficheros enviroment.properties situados en el directorio war contienen las variables donde se tiene que configurar toda la información que es susceptible de ser distinta en los diferentes entornos de ICM. Estos ficheros no deben ser modificados por los desarrolladores, ya que será durante la instalación en los diferentes entornos de ICM cuando se modifiquen y adapten al entorno. Un ejemplo de fichero es: 6.2. PRESENTACION 10 de 37
La lógica de presentación de la aplicación abarca todos los aspectos relacionados con la presentación de información al usuario final. Esta lógica queda prácticamente oculta al desarrollador, pues WebRatio permite únicamente gestionar la distribución de los elementos sobre un grid definido en el template y ciertas propiedades (parámetros) de los elementos que componen la aplicación. POB Las páginas deben ser compatibles con las versiones de Navegador Internet Explorer 6.0 o superior y Mozilla Firefox 2 o superior. Los módulos que se desarrollen para los usuarios de la Intranet deben funcionar correctamente con el POB (Puesto ofimático básico) que tienen instalado en su PC. BUENA PRACTICA PageTamano Las páginas se deberán diseñar y modularizar de tal forma que no tomen unas dimensiones excesivas. 6.2.1. Internacionalización El conjunto de elementos culturales, políticos y específicos de una región representados en una aplicación se denominan locale. Las aplicaciones deberían personalizar la presentación de los datos en función del locale preferido del usuario, de esta manera se puede definir el concepto de internacionalización (También conocida como I18n) como el proceso de separar las dependencias locale del código fuente de la aplicación. Ejemplos de dependencias locale pueden ser el conjunto de caracteres, encoding, moneda, formato de tiempo, calendarios, etc. El concepto de Localización (También conocido como L10n) es el proceso de adaptar una aplicación internacionalizada a un locale específico, por lo que las aplicaciones tendrán que estar internacionalizadas de forma previa a ser localizadas. 11 de 37
WebRatio dispone de un potente soporte a la internacionalización y la localización. Para desarrollar una aplicación completamente internacionalizada, todos los literales incluyendo etiquetas, campos de fecha, textos de unidades, pueden ser traducidos a través de la funcionalidad de localización. Basta para ello indicar que sección de la aplicación quiere localizarse y traducir todos las cadenas y elementos a localizar que existen en el mismo. Internacionalizacion Las aplicaciones contendrán un fichero para almacenar los mensajes internacionalizados. Esto se indicará mediante la propiedad Localized del proyecto. El mecanismo de internacionalización no aplica a mensajes incluidos en trazas, al no ser directamente visualizados por los usuarios finales. I18NEs Al menos se debe de entregar el fichero de mensajes del locale Español (es) 6.2.2. Estructura y decoración de la página Durante el desarrollo de una aplicación surge la necesidad de implementar un mecanismo mediante el cual mantengamos un interfaz consistente entre todas las páginas que conforman la aplicación Web (y entre todas las aplicaciones), lo que implicará tener elementos comunes de página para ser implementados como componentes reutilizables. WebRatio cuenta con la posibilidad de definir estilos que dan forma al diseño de las aplicaciones mediante plantillas (disposición de elementos) y hojas de estilo (representación visual). Dentro del estilo ICM_Style que se configura al instalar el entorno, se ha creado un layout que tienen que utilizar las aplicaciones desarrolladas con esta aplicación. El uso de este estilo garantiza la homogeneidad de los desarrollos y facilita el mantenimiento de los mismos. 12 de 37
El layout desarrollado cuenta con un menú horizontal, uno vertical y en el resto de la página se muestra el contenido. Además de cabecera con nombre de la unidad orgánica y aplicación, información de conexión y pie de página con normativa legal. ModifTemplate BUENA PRACTICA Aunque se utilice el ICM_Template e ICM_Style como punto de partida, pueden modificarse y personalizarse para el proyecto, eliminando ciertos componentes visuales que no quieran utilizarse. 6.2.3. Normas de estilo Puesto que el estilo se ha desarrollado a partir del creado para el framework Atlas, existe un documento llamado Atlas Guía de Estilo que incluye información sobre: o Estilo de las aplicaciones o Accesibilidad o Usabilidad 13 de 37
Dicho documento puede consultarse a través de la Web de ArquitecturaSw. 6.2.4. Interfaces ricas de usuario (RIA) Existen tecnologías que pretenden mejorar las aplicaciones web asemejándolas todo lo posible a las aplicaciones de escritorio tradicionales. En esta línea de trabajo, WebRatio permite crear aplicaciones RIA utilizando AJAX. Con Ajax se puede recargar determinados componentes de la página sin necesidad de recargarla por completo, gestionar la visibilidad de los elementos de presentación, realizar peticiones al servidor automáticas, control de cualquier evento de usuario, etc. AjaxLimite Se recomienda limitar la cantidad de información intercambiada mediante AJAX. BUENA PRACTICA Para esto se recomienda restringir las regiones AJAX de modo que se procese el mínimo número de componentes. También se recomienda procesar únicamente la propiedad que desencadena el evento. Por último, en ocasiones es preferible recargar la página de nuevo, a intercambiar mediante AJAX gran cantidad de información. 6.3. SERVICIOS DE NEGOCIO Los servicios de negocio son aquellos que implementan la lógica que complementa las operaciones de acceso a datos para cubrir los requisitos de negocio de una aplicación. 6.3.1. MANEJO DE ERRORES Y EXCEPCIONES WebRatio permite gestionar los errores de ejecución en el flujo de la aplicación. Se recomienda gestionar estos errores y dar información al usuario sobre los mismos. 6.3.2. TRANSACCIONALIDAD 14 de 37
La transaccionalidad es fácilmente tratada en WebRatio pues permite obligar a que un conjunto de operaciones se agrupen en una Operation Group Unit y forzar la ejecución global o no del conjunto. 6.3.3. FICHEROS TEMPORALES En algunas aplicaciones es necesario generar ficheros temporales en un directorio del entorno. Actualmente todos los entornos ya tienen preparados estos directorios y están compartidos por NFS entre las distintas máquinas del cluster. Las aplicaciones podrán acceder a estos directorios para dejar y eliminar ficheros pero no podrán crear carpetas dentro de estos directorios. Existen jobs periódicos que se encargan de limpiar estos directorios, para eliminar los ficheros temporales obsoletos. FichTemporal Salvo autorización expresa de ICM, las aplicaciones no generarán ficheros temporales en el servidor que deban ser accedidos por cualquiera de las máquinas del cluster. Si se autorizase, los ficheros generados por las aplicaciones y que se necesiten dejar en disco se ubicarán según se indique en un parámetro del fichero de configuración. Esta ubicación corresponderá con un directorio compartido por las distintas maquinas que compongan el cluster. 6.4. ACCESO A DATOS El acceso a datos es una de las partes con mayor índice de criticidad que pueda existir en cualquier aplicación web. Para el acceso a los distintos sistemas relacionales, WebRatio emplea internamente la tecnología Hibernate. 6.4.1. Datasource y Sesiones de Hibernate Todas las aplicaciones definirán un datasource vía JNDI para conectarse con la base de datos desde los servidores de aplicación de los distintos entornos (salvo en el entorno local del desarrollador). Esta conexión se define en los parámetros de los ficheros de configuración enviroment.properties. 15 de 37
DAODataSource En las aplicaciones desplegadas en entornos de ICM, deberá utilizarse un DataSource y nunca obtener directamente las conexiones jdbc. De esto se asegurará el área de ICM encargada de instalar las aplicaciones en los distintos entornos. El nombre del DataSource será parametrizable a través del fichero environment.properties, utilizando la variable icmauth.database.url El valor de la variable icmauth.database.mode para los entornos de ICM deberá ser datasource 6.4.2. Entidades volátiles El modelo de datos de WebRatio permite trabajar con entidades que almacenan información de manera volatil, en memoria, manteniéndose en el ámbito de la sesión o de la aplicación. APPEntity Salvo autorización expresa por parte de ICM, se prohibe el empleo de entidades volátiles de ámbito de sesión. BUENA PRACTICA SesionEntity Para evitar un consumo elevado de memoria, se recomienda emplear las entidades de sesión únicamente cuando sea estrictramente necesario. 6.4.3. Tipos de datos BLOB Los tipos de datos BLOB hacen referencia a aquellos elementos utilizados en una bases de datos para almacenar entidades de gran tamaño que puedan cambiar de forma dinámica enfocados a datos binarios (por ejemplo una imagen). 16 de 37
UploadLob Cuando surja la necesidad de subir y almacenar ficheros en el servidor, estos deberán almacenarse en campos tipo CLOB, no pudiendo dejarse como ficheros físicos del sistema. 6.4.4. Uso de sentencias SQL/HQL Es posible realizar consultas complejas a las bases de datos a través de la QueryUnit que ofrece WebRatio. Dichas consultas se tendrán que realizar bajo una serie de condiciones. ADSQLUso En el caso de utilizar SQL dentro de una QueryUnit, se deberán tener en cuenta las siguientes restricciones: No se podrán utilizar sentencias SQL-DML ni SQL-DDL desde el código ni utilizar los mecanismos de Hibernate que permitan realizar ese tipo de operaciones desde el código. No se deben utilizar las sentencias SELECT * en su lugar se incluirán los nombre de los campos que en realidad se van a consultar. En el caso de utilizar una sentencia SELECT FOR UPDATE se hará con la clausula NO WAIT. ADHQL Se deberá utilizar en la medida de lo posible el lenguaje de acceso a datos HQL, por ser un lenguaje más enfocado a objetos que el propio SQL. BUENA PRACTICA Aún así se podrá extender este modelo haciendo uso del lenguaje SQL siempre y cuando sea necesario. Esto será necesario en casos de querer usar querys SQL no ANSI-Estándar, querys que por su complejidad sea más adecuado SQL en lugar del mapeo objeto-relacional, operaciones de larga duración del tipo batch, streaming de BLOBs, operaciones de tipo select complejas, etc. 17 de 37
ADCatalogos No se permiten realizar actualizaciones en tablas de catálogos generales (SUCA, CATA, etc.). Tampoco se podrán realizar borrados en cascada sobre tablas de catálogos. 7. SERVICIOS BASICOS WebRatio, bien directamente o bien a través de desarrollos realizados sobre el mismo como extensiones, ofrece un conjunto de servicios básicos para cubrir aquellos requisitos comunes a la mayoría de las aplicaciones. En ICM se han desarrollado una serie de servicios comunes a todas las aplicaciones, que ya se encuentran disponibles en el entorno de Webratio una vez instalado siguiendo el manual WR_MUS_Preparacion_Entorno_Desarrollo.pdf (incluye ICM_Template, ICM_Units e ICM_Style). 7.1. SERVICIO DE AUTENTICACION Y AUTORIZACION La Comunidad de Madrid dispone de aplicaciones de carácter público y privado, dependiendo, tanto del tipo de función que desempeñan como del tipo de usuarios al que van dirigidas. En WebRatio se ha modificado el proceso de login para cubrir este requisito de gestión de accesos. Las aplicaciones de carácter privado limitarán su acceso a determinados usuarios. La forma de acceder a este tipo de aplicaciones puede ser mediante dos mecanismos: certificado digital y/o login/password. Los usuarios que tienen su acceso permitido a determinadas aplicaciones estarán dados de alta en alguno de los repositorios de usuarios de ICM. En estos repositorios de usuarios se encuentra toda la información de los usuarios y sus perfiles o roles de trabajo para cada aplicación. Estos repositorios son los que se muestran a continuación: Política Repositorio a validar y acciones LDAP USU USUI Almacena los datos de login de los usuarios de la intranet. Se utiliza para la autenticación de los usuarios. Repositorio de usuarios y perfiles de la Comunidad de Madrid con acceso desde la intranet. Se utiliza para la autorización de los usuarios. Repositorio de usuarios y perfiles de la Comunidad de Madrid con 18 de 37
acceso desde Internet. Se utiliza para la autenticación y autorización de los usuarios. USUJ Repositorio de usuarios y perfiles de la Comunidad de Madrid para aplicaciones de Justicia. Se utiliza para la autenticación y autorización de los usuarios. Para WebRatio se han definido unas políticas de acceso para las aplicaciones que consisten en la definición de unas reglas de validación de acceso de los usuarios. Estas políticas indican cual es el mecanismo de acceso, contra qué repositorios se deben llevar a cabo el proceso de autenticación, así como otras medidas a adoptar. A continuación se muestra una tabla con la lista de políticas de acceso que se pueden seguir con WebRatio y que se pueden utilizar en las aplicaciones web. Política Público Público Certificado Usuario Intranet Usuario Internet Demo Repositorio a validar y acciones No se realizará ninguna acción de autenticación Validar Certificado contra la plataforma multipki de ASF Validar el usuario contra LDAP y recoger el rol de USU Validar Certificado (multipki) o validar el usuario y recoger su rol en USUI Política para desarrollo en la cual no es necesario disponer de ningún repositorio, pues se usa el modelo de datos interno de WebRatio. No se emplea el módulo de login. En algunas aplicaciones se puede dar el caso de que, dependiendo del entorno desde donde se acceda a la aplicación, la forma de autenticación sea distinta. Por ejemplo: una autenticación con certificado si la aplicación es accedida desde internet y permitir acceso mediante usuario/contraseña para los accesos desde la intranet. El Servicio de Autenticación y Autorización de usuarios permite que dependiendo del dominio/host al que se conecte el usuario se presente una política de acceso u otra, según se haya definido en la aplicación a la que se está accediendo. 19 de 37
SBAutenAuto Aquellas aplicaciones web que tengan que restringir el acceso a determinados usuarios deberán utilizar el módulo de login del ICM_template y siempre utilizando alguna de las políticas ya definidas en el mismo. Por otra parte dentro de una aplicación determinados usuarios tendrán acceso a unas opciones y otros usuarios a otras opciones (autorización). Esto se gestionará creando distintos perfiles o roles según el tipo de usuario y limitando el acceso a las opciones de menú o partes de la aplicación y a las rutas de acceso según los perfiles creados. La gestión de los permisos a los distintos módulos o secciones tiene que gestionarse en las aplicaciones de WebRatio, por lo que se han desarrollado dos módulos que permiten la gestión de grupos (perfiles), los módulos o secciones sobre los que aplicar las políticas de acceso y la relación entre perfiles y secciones. Para más información sobre el uso de estos módulos, consultar la documentación del ICM_Template. SBAutoPerfiles Si la aplicación tiene distintos perfiles de acceso, la seguridad se debe implementar a nivel de elementos a incorporar en menú (áreas, páginas, módulos). 7.2. COMPONENTES DE PRESENTACION WebRatio ofrece un conjunto de componentes visuales para el desarrollo de las interfaces gráficas de usuario de las aplicaciones web. Estos componentes cuentan con un estilo unificado.los componentes que ofrece WebRatio son: Layout Componente Componentes de Menú Descripción Plantillas para organizar la información dentro de la página Componentes para la construcción de menús en una aplicación. Existen 2 tipos de menús: 20 de 37
Menú Vertical Menú Horizontal Rastro de Migas Calendario Lista de Valores Lista Paginada Captcha Árbol Jerárquico Indicador de navegación para situar al usuario en la estructura de contenidos Facilita al usuario introducir una fecha en un formulario mostrando en un panel emergente un calendario mensual. Facilita al usuario la introducción de un valor que está asociado a un catálogo Muestra una lista de datos de forma tabulada en una serie de páginas Ofrece el mecanismo de prueba necesario para determinar cuando un usuario es humano o no. La prueba consiste en introducir por parte del usuario una serie de caracteres los cuales son mostrados de forma distorsionada por pantalla. Permite mostrar un conjunto de datos organizados jerárquicamente en forma de árbol Adicionalmente, a través de la WebRatio Store se pueden obtener componentes adicionales para mostrar la información, bien sea mediante Units específicas o templates. 7.3. SERVICIO DE TRAZAS El Servicio de Trazas de WebRatio proporciona a todas las aplicaciones una serie de logs automáticos durante la ejecución de la aplicación, tanto generados automáticamente por el componente como los definidos por la propia aplicación a través de la ICM_Trace Unit. La configuración de los ficheros de log se hace mediante dos ficheros de configuración existentes en los directorios WEB-INF\conf de las aplicaciones: RTXLogConfig.properties y StrutsLogConfig.properties, y que vienen configurados en el ICM_Template. 7.4. SERVICIO DE AUDITORIA DE SEGURIDAD 21 de 37
Los Sistemas de Información de la Comunidad de Madrid en algunos casos tratan datos de carácter personal que son especialmente protegidos por la Agencia de Protección de Datos. En estos casos es obligado que se recoja información sobre los accesos realizados a dichos datos. Actualmente no existe ningún servicio de auditoría automático sobre WebRatio. Cada acceso que debiese ser auditado, debería ser gestionado de manera individual a través de un módulo o similar, previa autorización por ICM. SBAudit Si se desea realizar auditoría de datos sobre alguna tabla del modelo, deberá consensuarse con ICM y obtener una autorización excepcional para ello. 8. INTEGRACION Para cubrir los requisitos de integración con otros productos, WebRatio ofrece una serie de servicios adicionales que vamos a denominar servicios de integración, y que se describen en los siguientes apartados. 8.1. SERVICIO DE INVOCACIÓN DE SERVICIOS WEB Muchas de las aplicaciones que se desarrollan para la Comunidad de Madrid necesitan acceder a servicios web, tanto servicios que se han desarrollado específicamente para la tramitación electrónica como otros servicios web que incluso pueden estar fuera de nuestros entornos. WebRatio proporciona una unidad de acceso a webservices fácilmente utilizable en cualquier proyecto. Para más información sobre el uso de esta unidad, consultar el manual de WebRatio así como el proyecto ICM_Webservices de ejemplo. Las transformaciones de los objetos respuesta se realizarán mediante scripts de Groovy, evitando el uso de transformaciones XSLT. 22 de 37
INTWS Para invocar a un servicio web se hará mediante la utilización de la unidad Request Response Unit. La transformación de los objetos se realizará mediante scripts de Groovy. 8.2. SERVICIO DE GESTIÓN DOCUMENTAL La solución de gestión documental para las aplicaciones de la Comunidad de Madrid es el gestor de documental de EMC Documentum. Se ha desarrollado un servicio llamado Servicio de Gestión Documental que ofrece una interfaz con los servicios que se pueden realizar con una plataforma de gestión documental. Este servicio se puede utilizar, desde WebRatio, como un servicio web. SIGDOC Las aplicaciones que necesiten acceder a un gestor documental lo harán a través del Servicio de Gestión Documental y accediendo a través de los servicios web implementados dentro de este servicio. Actualmente este Servicio de Gestión Documental se ha implementado sobre el producto EMC Documentum. 8.3. SERVICIO DE PLANIFICACION En ocasiones es necesario ejecutar ciertas tareas a una hora concreta, en base a una planificación preestablecida. Tal es el caso de la ejecución de informes periódicos, o la generación de estadísticas. Para este tipo de tareas normalmente pesadas, existe una solución simple: planificar la creación del informe para las horas cuando el sistema tiene menor carga de trabajo. WebRatio cuenta con la posibilidad de ejecutar y controlar tareas programadas mediante un sistema interno basado en Quartz. Una vez configurado el proyecto adecuadamente a través de las propiedades del mismo, se cuenta con unidades para lanzar, cancelar y conocer el estado de una tarea programada. 23 de 37
SIPLAN Las aplicaciones que necesiten invocar una tarea batch lo harán a través de las Unidades de Servicio que ofrece WebRatio para tareas programadas (jobs). 8.4. SERVICIO DE CERTIFICADOS DIGITALES Las aplicaciones de la Comunidad de Madrid en ocasiones requieren de la utilización de certificados digitales que posibilitan la tramitación electrónica. Para soportar dicha funcionalidad se cuenta con el Servicio de Certificados basado en la Plataforma ASF, una solución completa para la integración de la Firma Electrónica Avanzada en una infraestructura informática de una entidad u organización. El Servicio de Certificados, provee las siguientes funcionalidades: Cifrado y descifrado de datos Firma electrónica en servidor Verificación de firmas electrónicas Validación de certificados digitales Obtención de datos de un certificado La integración con ASF se realiza mediante Servicios Web a los siguientes módulos: Policy Manager, X509Validator, SignatureServer, EncryptionServer, NonRepudiationService y TSAClient. SICert Las aplicaciones que necesiten realizar operaciones con certificados digitales lo harán a través de los Servicio de Certificados Digitales que ofrece la plataforma ASF. Para más información sobre el uso del servicio de certificados digitales, consultar el manual de ASF ASF50_Manual de Integracion Servicio ASF.pdf 8.5. SERVICIO DE PROCESOS DE NEGOCIO 24 de 37
Un proceso de negocio es la representación del trabajo realizado por las personas y los sistemas de una organización, con el objetivo de ofrecer un servicio a sus clientes. Business Process Management (BPM) es el proceso de formalizar la automatización de los procesos de negocio. Webratio proporciona la posibilidad de definir un proceso mediante notación BPMN con su representación gráfica y generar un modelo WebML a partir de dicho modelo BPMN. Este modelo web puede ser tratado como un modelo normal y sincronizado con el BPM en caso de modificaciones en el mismo. SIBPM Las aplicaciones que necesiten acceder a un motor de procesos lo harán a través de las posibilidades de diseño de procesos de Webratio. ATENCIÓN El estilo gráfico desarrollado para ICM (ICM_style) no soporta en la actualidad las aplicaciones de gestión de procesos de negocio, por lo que debe utilizarse el estilo BPM que WebRatio proporciona por defecto 8.6. INFORMES (REPORTING) WebRatio permite la generación de informes en formato PDF o RTF. Para diseñar los informes se emplea ireport de Jaspersoft, cuyos diseños se compilan e integran con el modelo desarrollado sobre WebRatio. SOLRpt La herramienta de diseño de los informes de las aplicaciones de WebRatio será ireport. 25 de 37
SOLNomRpt El nombre de los informes de ireport tendrá la siguiente nomenclatura: XXXXNombreDelInforme.jrxml, donde xxxx es el nombre del proyecto y NombreDelInforme el nombre del informe que debe estar escrito en minúsculas, excepto la primera letra de cada palabra que estará en mayúsculas. Este nombre no puede contener espacios en blanco. 8.7. COMPOSICION DE DOCUMENTOS Para la generación dinámica de documentos RTF, se debe emplear el mismo proceso que para la generación de informes, puesto que se permite la inclusión de variables dentro de la plantilla. SOLCompositor Para la composición de documentos en WebRatio se seguirá el mismo proceso que para la generación de informes, utilizando ireport para el diseño del documento. Las plantillas se crearán en formato jrxml y su compilado jasper, y los documentos generados tendrán formato RTF. Si se desea permitir modificar un documento RTF por el usuario, se puede emplear la unidad RTF Filler Unit disponible en la Webratio Store. 8.8. GESTION DE DOCUMENTOS EXCEL WebRatio dispone de la unidad Excel Unit para la lectura, generación o modificación de ficheros excel (xls o xlsx) directamente, cuya tecnología está basada en Apache POI. 26 de 37
SOLExcel Para la gestión de documentos Excel en las aplicaciones WebRatio se utilizará la unidad Excel Unit. SOLCSV Para crear o leer ficheros csv, se utilizará la CSV Unit disponible en la WebRatio Store. 8.9. GENERACION DE GRAFICOS Para la generación de gráficos se utilizará la unidad ChartUnit disponible en la WebRatio Store. Esta unidad permite la creación de gráficos de tipo barras, burbujas, lineas, columnas, fechas y circulares. Si se desea realizar un diagrama de Gantt, se debe emplear la unidad GanntUnit disponible igualmente en la WebRatio Store. SOLGraf Para la generación de gráficos se utilizará la Chart Unit disponible en la WebRatio Store. 8.10. USO ARCHIVOS MULTIMEDIA En muchas ocasiones surge la necesidad de desarrollar aplicaciones que muestren archivos de audio, video, imágenes u otro tipo de archivos multimedia en aplicaciones Java. WebRatio no dispone directamente de unidades para la presentación o tratamiento, pero a través de unidades de la WebRatio Store es posible la gestión de contenidos multimedia. Las principales unidades de trabajo disponibles son: MultimediaPlayer Unit: permite visualizar múltiples ficheros de vídeo, audio, animaciones e imágenes con los controles típicos de los visores. ImageGallery Unit: permite mostrar una galería de imágenes 27 de 37
Para el manejo de imágenes: o Crop Image Unit: permite cortar una porción de una imagen o Scale Image Unit: permite escalar una imagen, dando su tamaño en pixels SOLMultimedia Para la gestión de contenidos multimedia, se utilizarán las diversas Units disponibles en la WebRatio Store. 8.11. XML Para facilitar la gestión de los ficheros XML, se disponen de una serie de unidades agrupadas bajo el epígrafe de Service Units que permiten la manipulación de los ficheros XML. Estas unidades son: Adapter Unit: permite aplicar una transformación XSL o groovy sobre el fichero XML entrante, generando un documento XML como resultado. XML In Unit: inserta un documento XML canónico en una entidad del modelo relacional. XML Out Unit: transforma un fragmento del esquema de entidades-relaciones en un documento XML en formato canónico-relacional. Hierarchical XML Out Unit: de manera similar, transforma un fragmento del esquema de entidadesrelaciones jerarquizado en un documento XML en formato canónico-relacional. Get XML Unit: obtiene contenido XML desde una URL local o remota. SOLXML Cuando las aplicaciones necesiten trabajar con ficheros XML, tanto para generarlos como para leerlos, se utilizarán las distintas unidades para el manejo de documentos XML y se desarrollarán los scripts necesarios sobre Groovy. 8.12. ENVIO DE CORREO Webratio ofrece una unidad para enviar correos electrónicos personalizados tanto en formato texto plano como html, sobre sistemas de correo SMTP. 28 de 37
SOLCorreo Para el envío de correo desde las aplicaciones se empleará la unidad de envío de correo (Mail Unit). De esta forma se pueden crear plantillas de correo mediante cualquier editor (por ejemplo, con un editor de HTML), y definir variables que se establecerán en tiempo de ejecución para el mensaje de correo. 8.13. ENVIO DE SMS La Comunidad de Madrid dispone de una plataforma desarrollada por Telefónica Soluciones para el envío y recepción de mensajes SMS, que recibe el nombre de MenTeS (Mensajería de Telefónica Soluciones). Sobre esta plataforma se ha desarrollado un servicio web que ofrece una interfaz estándar para el acceso a estas funcionalidades desde cualquier tipo de aplicativo. El siguiente diagrama muestra la arquitectura del sistema: Para el envío de mensajes SMS se empleará el servicio web desarrollado sobre la plataforma MenTeS. La forma de invocar a este servicio web será la normal de uso de servicios web. 29 de 37
SOLSMS Para el envío de SMSs se utilizarán los servicios web que proporciona la plataforma MenTeS de ICM. 9. HERRAMIENTA DE CALIDAD 9.1. HERRAMIENTA DE VALIDACIÓN WebRatio ofrece una herramienta que asegura la calidad de los modelos diseñados, en cuanto a la validación del modelo de datos, el modelo de presentación y el modelo de negocio, proporcionando información de los errores existentes así como avisos sobre malas prácticas. Los errores impiden la ejecución correcta de la aplicación a partir del modelo generado. ValFrecuente BUENA PRACTICA Se recomienda ejecutar la herramienta de validación frecuentemente desde el inicio del proyecto (no sólo al final del proyecto) con el fin de evitar que los errores se vayan acumulando a lo largo del desarrollo y esto suponga carga adicional de trabajo. La herramienta de validación cuenta con un sistema de arreglo rápido de errores en algunos casos. 9.2. DEBUG WebRatio ofrece la posibilidad de realizar un debug visual del modelo, permitiendo realizar la ejecución del mismo paso a paso, obteniendo información de los distintos parámetros empelados en el diseño del mismo. 10. PRUEBAS El desarrollo de software requiere e implica la construcción de aplicaciones de forma robusta, extensible y escalable. Conseguir dichos objetivos requiere la aplicación de una metodología de desarrollo que incluya la realización de pruebas de software precisas. 30 de 37
El objetivo de las pruebas de software es asegurar que el producto final cumple todas las funcionalidades requeridas por los usuarios. Para conseguir dicho objetivo, los encargados de realizar las pruebas tendrán que revisar el producto final y concluir si los requisitos iniciales son completamente satisfechos. La ejecución de pruebas es tan importante que se debe hacer durante todo el tiempo y a lo largo del ciclo de vida de desarrollo del software. 10.1. TIPOS DE PRUEBAS Por las características propias del desarrollo dirigido a modelos, los elementos unitarios generan código repetitivo ya probado, por lo que el proceso de testeo no sigue el de las aplicaciones desarrolladas sobre lenguajes de programación, al no tener que evaluar la calidad del código, sino la correcta ejecución del modelo, es decir, pruebas funcionales generalmente. Pruebas de carga y stress: las pruebas de carga y stress evalúan el rendimiento del sistema en base a los requisitos. Permite verificar el comportamiento del sistema en situaciones extremas, tanto en carga como en tiempo, donde los usuarios y peticiones se producen de forma concurrente. TESTRendimiento Se implementarán pruebas de carga y estrés para las funcionalidades de la aplicación en las que el rendimiento sea un factor a tener en cuenta o el volumen de usuarios concurrentes sea muy elevado. Para implementar las pruebas de carga y estrés se utilizará JMeter. Los tests de JMeter deben ir incluidos en un directorio llamado test/jmeter, que se crea al generar el proyecto partiendo del template. 10.2. PLAN DE PRUEBAS Un plan de pruebas debe ser interpretado como la piedra angular y en consecuencia el principal factor crítico de éxito para la puesta en práctica de un proceso de pruebas que permita entregar un software de calidad ya que resumirá, entre otras cosas, las actividades de prueba que se deberán realizar. De tal forma, se puede definir el plan de pruebas como un documento que describe el alcance, enfoque, recursos y calendario de las actividades de prueba. 31 de 37
Además, los planes de pruebas deben ser documentos sencillos, fáciles de revisar. TESTPlanPruebas Como parte de los entregables de los proyectos será necesario entregar los planes de pruebas, los resultados de los mismos y un informe de evaluación de dichos resultados. El plan de pruebas entregado por el desarrollador tendrá que incorporar (como mínimo) los siguientes elementos: Identificador del plan de pruebas: El identificador será de alguna forma mnemónica que permita relacionarlo con su alcance, por ejemplo: PP-Global (plan de pruebas global), PP- Aceptacion (plan de pruebas para pruebas de aceptación), etc. Versión y la fecha del plan de pruebas. Alcance del plan de pruebas: Se deberá especificar los requisitos que se van a probar con este plan. Por otra parte se deberán indicar igualmente aquellos requisitos excluidos justificando los motivos por los cuales no se van a probar. Configuración necesaria Para cada uno de los siguientes tipos de pruebas incluir un apartado donde se especifiquen los casos de prueba, el instrumento o herramienta usada, donde pueden ser encontrados, cómo serán ejecutados y los datos que serán usados. o o Pruebas funcionales Pruebas de carga y estrés (si fuesen necesarias por la volumetría de usuarios de la aplicación). 10.3. DOCUMENTACION DEL MODELO La documentación del modelo debe explicar claramente qué función realiza cada elemento y debe exponer toda funcionalidad interna que afecte a su comportamiento externo. Para ello WebRatio permite incorporar información en cada uno de los elementos y genera un documento con información del mismo, incluyendo el proyecto global, modelo de datos y modelo de negocio. 32 de 37
WRDOC Todas las unidades de las aplicaciones deberán incluir la información permitan generar la documentación correspondiente. 11. ENTREGA El desarrollador desarrollará en su entorno de desarrollo local, y con base de datos del entorno de desarrollo de ICM. Cuando desee disponer la aplicación en uno de los entornos Weblogic de ICM (desarrollo, validación, producción), realizará la entrega en Subversion del software desarrollado a la Unidad de Puesta en Producción de Aplicaciones con una petición a través de la aplicación GPAP. WRSVN Las entregas del código para ser instaladas en los distintos entornos de ICM se realizarán utilizando el repositorio de código Subversion, siguiendo la nomenclatura indicada en el manual Guía de Uso de Subversion. La Unidad de ICM destinada a la instalación de la aplicación accederá a Subversión donde recogerá las entregas. En cada entrega, el desarrollador deberá cumplimentar una ficha de instalación. 33 de 37
EntregaParcial BUENA PRACTICA A lo largo del ciclo de vida del desarrollo del proyecto es recomendable realizar al menos dos entregas intermedias, al 30% y 70% del desarrollo, no realizando una única entrega final con todo el proyecto sólo cuando esté finalizado. Se puede ajustar las entregas al cierre de siteviews o áreas funcionales. La Unidad de ICM destinada a la instalación de la aplicación responderá de la instalación a través de GPAP. EntregaErrores Es obligatorio que la aplicación entregada no tenga errores en el diseño. 34 de 37
A1.1 S ENTORNO... 7 ENTORNOEJECUCION... 7 NOMBREARCHIVO... 8 TEMPLATE... 8 ESTILOUNITS... 8 VERSIONADO... 9 NOMENTIDADES... 9 POB... 11 INTERNACIONALIZACION... 12 I18NES... 12 FICHTEMPORAL... 15 DAODATASOURCE... 16 APPENTITY... 16 UPLOADLOB... 17 ADSQLUSO... 17 ADCATALOGOS... 18 SBAUTENAUTO... 20 SBAUTOPERFILES... 20 SBAUDIT... 22 INTWS... 23 SIGDOC... 23 SIPLAN... 24 SICERT... 24 SIBPM... 25 SOLRPT... 25 SOLNOMRPT... 26 SOLCOMPOSITOR... 26 SOLEXCEL... 27 SOLCSV... 27 SOLGRAF... 27 35 de 37
SOLMULTIMEDIA... 28 SOLXML... 28 SOLCORREO... 29 SOLSMS... 30 TESTRENDIMIENTO... 31 TESTPLANPRUEBAS... 32 WRDOC... 33 WRSVN... 33 ENTREGAERRORES... 34 36 de 37
A1.1 BUENAS PRACTICAS PAGETAMANO... 11 MODIFTEMPLATE... 13 AJAXLIMITE... 14 SESIONENTITY... 16 ADHQL... 17 VALFRECUENTE... 30 ENTREGAPARCIAL... 34 37 de 37