Plataforma de Tramitación G ONCE Manual de Integración

Transcripción

1 Plataforma de Tramitación G ONCE Manual de Integración Pastor y Landero, Sevilla (España) tel cliente: fecha: 12 de mayo de 2014 versión: v01r21 Queda prohibido cualquier tipo de explotación y, en particular, la reproducción, distribución, comunicación pública y/o transformación, total o parcial, por cualquier medio, de este documento sin el previo consentimiento expreso y por escrito de Guadaltel, S.A.

2 ÍNDICE DE CONTENIDO 1.Introducción Descripción general de Integración Arquitectura de Integración Descripción general del entorno de despliegue Diagrama de clases de integración Diagrama de secuencia general Diagrama de despliegue Conclusiones Descripción detallada de Integración Requisitos previos Configuración y administración previa Definición de procedimientos Requisitos particulares para la interfaz de Oficina Virtual Requisitos particulares para la interfaz de Agenda de Tramitación Interfaz de integración Integración de condiciones, acciones y variables [G ONCE v /12/2012] Acción para la numeración de expedientes [G ONCE v /12/2012] Actualización del número de expediente por procedimiento mediante HAT [G ONCE v /03/2014] Evaluación de condiciones [G ONCE v /12/2012] Operaciones en bloque Operaciones en bloque genéricas Operaciones en bloque específicas Propiedades accesibles mediante ticket [G ONCE v /12/2012] Estadísticas Estadísticas genéricas Estadísticas específicas Configuración del sistema en Trew@ Cómo integrar un procedimiento en la Plataforma G ONCE? Inclusión de los procedimientos en el modo de visualización por áreas Definir nuevas áreas en la oficina virtual...42 [ v01r20 ] 03/04/2014 Pág 2 de 67

3 3.12.[G ONCE v /12/2012] Implementación correcta de tareas [G ONCE v /12/2012] Accesos a la Oficina Virtual Detalles de procedimientos Inicio de expediente Descarga de documentos relativos al procedimiento: Otros parámetros en las llamadas [G ONCE v /12/2012] Configuración de seguridad de la Oficina Virtual [G ONCE v /01/2014] Recarga de expediente desde tarea Ejemplo Descripción general del procedimiento de ejemplo Configuración en el motor Trew@ Descripción del archivo de despliegue de ejemplo [G ONCE v /03/2014] Guía de Buenas Prácticas Objetivos Minimizar las llamadas a la integración vía EJB Definición de elementos en los procedimientos Mecanismos de configuración Creación del api de Trew@ en la clase de integración Agilizar el cálculo de variables en documentos...65 [ v01r20 ] 03/04/2014 Pág 3 de 67

4 1. Introducción El objeto del presente documento es describir la arquitectura general de implantación e integración con la Plataforma de Tramitación G ONCE, tomando como base dos de sus principales componentes: Oficina Virtual del Ciudadano y Agenda de Tramitación del Gestor. Pretende además describir qué requisitos, configuraciones y otros aspectos deben tenerse en cuenta para los distintos desarrollos que se vayan incorporando a dicha plataforma. Se aplica todo lo anterior al caso concreto de un ejemplo de desarrollo que acompaña a este documento, detallando aquellos aspectos más relevantes. Durante la fase de estudio de escenarios, análisis de requisitos y arquitectura deseada, se establecieron los siguientes objetivos que debe cumplir la Plataforma de Tramitación G ONCE: Desarrollos independientes: Los desarrollos realizados sobre la plataforma deben ser lo más independientes posibles, así como independizar dichos desarrollos de la evolución futura de la propia Plataforma de Tramitación G ONCE. Alta disponibilidad: La caída temporal o la actualización de un desarrollo concreto no debería afectar a la disponibilidad del resto de desarrollos disponibles en la Plataforma de Tramitación. Escalabilidad: Un aumento en el número de usuarios sobre la Plataforma de Tramitación debería ser fácilmente escalable simplemente añadiendo nuevos servidores de aplicaciones al entorno de producción. [ v01r20 ] 03/04/2014 Pág 4 de 67

5 Este documento está dirigido a todos aquellos usuarios relacionados con la implantación y posteriores desarrollos sobre G ONCE como Plataforma de Tramitación y más concretamente para: El colectivo de usuarios desarrolladores. El colectivo de usuarios administradores de los desarrollos y la propia Plataforma. [ v01r20 ] 03/04/2014 Pág 5 de 67

6 2. Descripción general de Integración 2.1. Arquitectura de Integración Descripción general del entorno de despliegue A continuación se describe mediante un diagrama un determinado entorno de despliegue, en el que puede destacarse por un lado la plataforma de tramitación (Oficina Virtual y Agenda de Tramitación) y por otro un archivo de despliegue como ejemplo (en adelante gonce2.ear ). c m p C o m p o n e n t s D e p l o y m e n t E n v i r o n m e n t g o n c e 2. e a r O f i c i n a V i r t u a l. e a r l i b O f i c i n a V i r t u a l. w a r G «l i b r a r y» o n c e I n t e g r a t i o n g o n c e 2. w a r «l i b r a r y» o f i c i n a g o n c e. p r o p e r t i e s «l i b r a r y» G o n c e G O N C E I n t e g r a t i o n I m p l «l i b r a r y» t r e w a - a p i t i c k e t. p r o p e r t i e s «l i b r a r y» C o n d i t i o n s A c t i o n s V a r i a b l e s «E J B» G o n c e E n v i r o n m e n t I n t e g r a t i o n E J B A g e n d a. e a r A g e n d a. w a r O p B l o q u e G e n e r i c a s. w a r G o n c e R e c o r d U t i l i t i e s. e a r «l i b r a r y» t r e w a - a p i «l i b r a r y» t r e w a - a p i l i b «u s e» «l i b r a r y» r e c o r d N u m b e r - f o r m a t t e r «E J B» G o n c e R e c o r d U t i l i t i e s E J B «l i b r a r y» a g e n d a «l i b r a r y» o p b l o q u e «l i b r a r y» t r e w a - a p i Diagrama 1 : Arquitectura general de la Plataforma G ONCE y desarrollos sobre la misma. En la parte de la izquierda del diagrama aparece representado el archivo de despliegue gonce2.ear (EAR Enterprise Archive format, estándar de JEE [ v01r20 ] 03/04/2014 Pág 6 de 67

7 Java Enterprise Edition) correspondiente a un desarrollo concreto tomado como ejemplo. Cabe destacar en este momento que en el diagrama anterior sólo se muestra como ejemplo un único archivo de despliegue EAR, pero como podrá deducirse de la lectura de este documento la arquitectura de despliegues permite tantos como sean necesarios (siempre teniendo en cuenta la propia arquitectura de servidores de aplicaciones en cada entorno y los límites y características que se establezcan para los mismos -despliegues en cluster, etc.-). Continuando con la descripción del diagrama, cada uno de dichos ficheros EAR es el producto de un desarrollo concreto que da soporte a la implementación de un procedimiento administrativo concreto que pretende instanciarse sobre la Plataforma de Tramitación G ONCE. El contenido de cada fichero EAR será: Uno o varios ficheros.war que contendrán las páginas web y toda la lógica de control relativas a ellas (en el gráfico de ejemplo gonce2.war ). Esto es, en general, la implementación de las tareas de manipulación de datos definidas en el procedimiento administrativo objeto del desarrollo. Una carpeta lib dónde se encontrará la lógica de negocio así como la capa de persistencia (si la hubiere) empaquetadas en ficheros en formato JAR. Cada desarrollo debe incluir además aquí la librería GonceIntegration.jar que contiene la implementación de referencia necesaria para la integración ( GonceIntegrationReferenceImp ), junto con su implementación, en el ejemplo GonceGONCE2IntegrationImpl.jar, que extiende de dicha implementación de referencia. Esta carpeta lib contendrá además la(s) librería(s) que implementan las condiciones, acciones y/o variables incluidas en los procedimientos administrativos definidos en el motor de tramitación Trew@ (en el gráfico de ejemplo ConditionsActionsVariables.jar ). [G ONCE v /12/2012] Además en esta carpeta se encuentran las librerías necesarias para llevar a cabo la numeración de expedientes para cada procedimiento (recordnumber-action). Todo ello se lleva a cabo mediante una acción asociada a una transición, documento o tarea. Más detalles sobre esta acción en el apartado correspondiente. Un JAR, GonceEnvironmentIntegrationEJB.jar, que se suministra [ v01r20 ] 03/04/2014 Pág 7 de 67

8 acorde a la versión de Plataforma de Tramitación G ONCE. El contenido de este JAR es un EJB (Enterprise Java Bean) que es necesario para permitir la integración de la Plataforma de Tramitación con cada uno de los desarrollos. El archivo de properties gonce.properties sólo debe tenerse en cuenta para el caso concreto tomado como ejemplo más adelante. En dicho ejemplo de desarrollo se utiliza para ciertas configuraciones que se permiten, como por ejemplo, el nombre del datasource usado para las conexiones que desde el propio ejemplo se hacen al motor Trew@ o el nombre del datasource de conexión al modelo de datos particular para este ejemplo de desarrollo. El fichero ticket.properties que se utiliza para el cifrado de los parámetros de la url de acceso a las tareas. En la carpeta META-INF debemos tener el archivo llamado application.xml donde declararemos el EJB de integración de la plataforma y el contexto de la aplicación del procedimiento si quisiéramos darle un contexto diferente al que se tenga por defecto. Por último, en esta carpeta META-INF también incluiremos un archivo jboss-app.xml donde declararemos el loader repository de nuestro.ear y evitar así posibles conflictos entre clases. [G ONCE v /12/2012] Por otro lado, se incluye el módulo GonceRecordUtilities.ear mediante el cuál se puede llevar a cabo la numeración sincronizada de expedientes de los distintos procedimientos mediante el uso de la librería GonceRecordUtilitiesEJB.jar. Este servicio sincronizado permite numerar el expediente por cada procedimiento simplemente definiendo una acción suministrada (recordnumber-action.jar) con el siguiente formato AÑO/PROCEDIMIENTO/NUMERO, por ejemplo 2012/GONCE2/ Por otro lado, en la parte de la derecha del diagrama se encuentran los componentes principales de la Plataforma de Tramitación G ONCE, concretamente Oficina Virtual (interfaz del ciudadano) y Agenda de Tramitación (interfaz del gestor). Dichas interfaces son las encargadas de la integración y comunicación con cada desarrollo desplegado en el entorno, que cumpla los requisitos necesarios para la integración incluyendo las librerías anteriormente descritas. Mediante esta comunicación, tanto la Oficina Virtual como la Agenda de tramitación son capaces de realizar las acciones necesarias para la [ v01r20 ] 03/04/2014 Pág 8 de 67

9 tramitación completa de un expediente, acorde a un procedimiento administrativo definido en el motor de tramitación Trew@. [ v01r20 ] 03/04/2014 Pág 9 de 67

10 Diagrama de clases de integración A continuación se presenta un diagrama de clases en el que se representan las más representativas incluidas en las librerías necesarias para la integración descritas en el apartado anterior y en el que se avanza qué implementación debe realizarse para permitir la integración de la Plataforma de Tramitación G ONCE con el desarrollo concreto necesario para un determinado procedimiento administrativo: Diagrama 2: Diagrama de clases que intervienen en el proceso de integración. [ v01r20 ] 03/04/2014 Pág 10 de 67

11 Diagrama de secuencia general Una vez visto el diagrama de clases aportaremos ahora una visión más dinámica mediante el diagrama de secuencia que se muestra a continuación: Diagrama 3: Diagrama de secuencia ejemplo de un proceso concreto de integración. En este diagrama de secuencia se presenta el ciclo de vida de una llamada al método taskaccess que más adelante se concreta, los demás métodos que intervienen en la integración no se han representado por similitud con éste en la secuencia de invocaciones. [ v01r20 ] 03/04/2014 Pág 11 de 67

12 Diagrama de despliegue Por último para concluir las especificaciones de la arquitectura se presenta a continuación un diagrama de despliegue del entorno, con lo que se ofrecerá una visión general de la plataforma: c m p D e p l o y m e n t D i a g r a m A p p l i c a t o n S e r v e r 1 J B o s s S e r v e r G A, G A S e r v l e t C o n t a i n e r «u s e» E J B C o n t a i n e r O p B l o q u e G e n e r i c a s. w a r A g e n d a. w a r O f i c i n a V i r u t a l. w a r G o n c e R e c o r d U t i l i t i e s E J B A p p l i c a t i o n S e r v e r 2 J B o s s S e r v e r G A, G A S e r v l e t C o n t a i n e r E J B C o n t a i n e r g o n c e 2. w a r G o n c e E n v i r o n m e n t I n t e g r a t i o n E J B Diagrama 4: Diagrama de despliegue. [G ONCE v /12/2012] A modo de resumen, en cada uno de los desarrollos además de la lógica de negocio y tareas propias relacionadas con la implementación de un procedimiento administrativo concreto (condiciones, acciones, variables -en nuestro ejemplo ConditionsActionsVariables.jar -, WAR con las páginas web y la lógica relativa a ellas en el ejemplo gonce2.war, etc., sólo es necesaria la programación de la implementación [ v01r20 ] 03/04/2014 Pág 12 de 67

13 concreta para la integración ( GonceGONCE2IntegrationImpl.jar ), además de las operaciones en bloque y estadísticas específicas para cada procedimiento, todo lo demás necesario para la integración viene proporcionado por la Plataforma. [ v01r20 ] 03/04/2014 Pág 13 de 67

14 2.2. Conclusiones De la arquitectura descrita en el apartado anterior, se pueden obtener las siguientes conclusiones relativas a los objetivos principales planteados al inicio de este documento: Escalabilidad, los servidores de aplicaciones actualmente disponibles en el mercado permiten escalar fácilmente las aplicaciones que en ellos se desplieguen mediante la implantación en cluster o la ampliación de nuevos nodos a uno ya existente. Sin embargo, para que esto sea posible, las aplicaciones deben seguir una serie de directrices (los objetos deben ser serializables, etc.) que deben tenerse en cuenta. Alta disponibilidad, gracias a la arquitectura diseñada, esto es, separación por un lado de Plataforma de Tramitación G ONCE y por otro los distintos desarrollos, es posible proporcionar una alta disponibilidad del conjunto. Si este diseño además se combina con el uso de cluster de aplicaciones, puede deducirse que si cae uno de los nodos donde se encuentre desplegada la Plataforma de Tramitación, seguirá habiendo otros nodos que den soporte a los usuarios de la Plataforma mientras que se levanta de nuevo el nodo caído. Igualmente para los desarrollos sobre la plataforma. Desarrollo independiente, dado que el producto del desarrollo que da soporte a un procedimiento administrativo concreto será un fichero EAR que se despliega en el servidor de aplicaciones, puede observarse claramente que éste es independiente de otros EAR correspondiente a otros desarrollos. De esta forma, cada EAR podría utilizar librerías distintas (o las mismas pero con distintas versiones) sin llegar a entrar en conflictos con la Plataforma de Tramitación u otros desarrollos para la misma. Esto permitirá además actualizar, si procede, la Plataforma de Tramitación G ONCE a nuevas versiones sin necesidad de modificar los desarrollos ya implementados con esta arquitectura, siempre que evidentemente dicha actualización no conlleve una modificación en la interfaz de integración descrita a lo largo de este documento. [ v01r20 ] 03/04/2014 Pág 14 de 67

15 3. Descripción detallada de Integración 3.1. Requisitos previos Debe tenerse en cuenta que para la comprensión de los siguientes apartados el lector debe tener conocimiento profundo sobre los conceptos relacionados con el Motor de Tramitación y más concretamente con las herramientas de definición, administración e instanciación de procedimientos que dicho motor ofrece. De la misma forma, la definición y configuración de sistemas así como otros aspectos técnicos concretos a tener en cuenta relacionados con los desarrollos y que no son objeto este documento, deberán seguir las directrices marcadas por el grupo de Arquitectura de sistemas. En esta línea hay que tener en cuenta: Clasificación lógica por sistemas. Usuarios de conexión para la plataforma a los que asignar perfiles sobre sistemas que deben ver. Usuarios de conexión y administración por sistemas o grupos de sistemas. Asociación de procedimientos a tipos de expediente. Uso de elementos comunes definidos. Igualmente cabe destacar que en el momento de los despliegues de desarrollos concretos, la Plataforma de Tramitación G ONCE debe encontrarse previamente configurada para su correcto funcionamiento e integración con los componentes habilitantes de Administración Electrónica Configuración y administración previa Se enumeran en este apartado el conjunto de configuraciones previas y [ v01r20 ] 03/04/2014 Pág 15 de 67

16 requisitos de administración que deben establecerse previamente y estar disponibles para el funcionamiento de cualquier despliegue sobre la Plataforma. Algunos de los puntos enumerados a continuación son necesarios en tiempo de definición del procedimiento o al menos en tiempo de carga del procedimiento en el motor Trew@ para completar dicha definición. Por un lado, en el motor de tramitación debe existir: Al menos un sistema definido en el que se importarán los procedimientos. Estructura de Organismos, como mínimo aquellos que tendrán asociado algún procedimiento a instanciar desde la Plataforma. Dichos Organismos deben disponer del atributo Provincia para el correcto funcionamiento de la selección de firmantes de documentos en tiempo de instanciación de los procedimientos. Usuario Trew@ que representará al usuario virtual de trabajo del ciudadano desde la Oficina Virtual de la Plataforma, en adelante por ejemplo, usuario CIUDADANO. Dicho usuario deberá tener como mínimo el perfil de Trew@ TR_R_USUARIO y debe ser conocido en tiempo de instalación de la Plataforma. Puestos de Trabajo, como mínimo el correspondiente al usuario CIUDADANO descrito anteriormente, que se asociará a un organismo para su posterior definición como Firmante de documentos. Catálogo de razones de interés existentes por defecto. Como mínimo la necesaria para asociar el interesado al expediente en la instanciación de procedimientos desde la interfaz de Oficina Virtual. En la plataforma del Gobierno de Cantabria, dicha razón de interés se denomina INTERESADO. Provincia y municipio para el caso de ciudadanos extranjeros. Deben estar dadas de alta y configuradas en la Plataforma. Por otro, además, deben estar previamente configurados y establecidos los siguientes puntos: [ v01r20 ] 03/04/2014 Pág 16 de 67

17 Componentes habilitantes de Administración Electrónica, tales como firma y registro. Para la autenticación con certificado digital es necesario que la Agenda y la Oficina Virtual estén registradas estos datos se indicarán en la configuración correspondiente del componente authenticator. En la plataforma del Gobierno de Cantabria, se ha creado el componente de para aquellos documentos que deben ser firmados directamente y no a través de port@firmas. Cada sistema existente en el motor debe configurarse con los anteriores componentes, según proceda. Debe existir la configuración mínima necesaria para cada sistema en Trew@. Se deben conocer de antemano el conjunto de tareas reservadas para funcionalidades concretas de la Plataforma de Tramitación G ONCE. Cabe destacar que estas tareas no deben ser implementadas por los desarrolladores aunque las mismas se indiquen en la definición del procedimiento. Igualmente debe conocerse de antemano el conjunto de posibles tipos de entrada a los procedimientos configuradas en la Plataforma y el catálogo de tipos de actos administrativos reservados preestablecidos para cada tipo de entrada según mecanismo de autenticación. Además debe conocerse el tipo de indicación de la ficha del Procedimiento que servirá para indicar el código de servicio necesario para las notificaciones telemáticas, si procede Definición de procedimientos Durante los siguientes apartados se pretende describir qué características deben cumplirse y qué elementos deben estar definidos en un procedimiento concreto, para su disponibilidad e instanciación mediante la Plataforma de Tramitación G ONCE. Como puede deducirse, mientras la definición de procedimientos sea más completa más información existirá disponible de los mismos en la Plataforma [ v01r20 ] 03/04/2014 Pág 17 de 67

18 de Tramitación y más funcionalidades de la misma podrán tenerse en cuenta. Cabe destacar como requisito principal que el procedimiento debe estar disponible en el motor de tramitación Trew@ para poder ser instanciado por las herramientas de la Plataforma, esto es, debe estar importado sin errores de definición, no bloqueado, asociado a algún tipo de expediente (según clasificación que se establezca) y por último completado al menos con la información de firmantes de cada tipo de documento Requisitos particulares para la interfaz de Oficina Virtual Concretamente en este caso debe tenerse en cuenta que para la instanciación de procedimientos desde esta interfaz destinada a ciudadanos debe existir como mínimo la siguiente información asociada al mismo, así como otras opciones de administración en el motor y que se especifican a continuación: 1. Datos generales del procedimiento, como nombre, descripción, etc. que aparecerán visualizados en la Plataforma en el apartado de Procedimientos disponibles. Cómo mínimo, el procedimiento deberá estar asociado a un Organismo dentro de la estructura orgánica establecida mediante el atributo Organismo pertenece. 2. Información adicional de la Ficha del Procedimiento e indicaciones de la Ficha, que detallaran un procedimiento concreto. [G ONCE de 19/03/2014] En caso de definir documentos descargables asociados al procedimiento, debe tenerse en cuenta que el nombre de la plantilla debe llamarse DOCUMENTO DESCARGABLE o Documento descargable para que éstos se tengan en cuenta en el área de descarga del procedimiento (configurados por defecto en Oficina Virutal). 3. Para que pueda instanciarse un procedimiento desde esta interfaz el usuario CIUDADANO debe tener asignados los perfiles TR_R_USUARIO Y PF_CIUDADANO para la transición o transiciones de entrada al procedimiento. 4. Las transiciones de entrada al procedimiento así como el resto de transiciones que debe ejecutar el usuario CIUDADANO, deben estar etiquetadas con los actos administrativos necesarios en caso de necesitar distinguir las disponibles según los tipos de autenticación habilitados en la Plataforma. En este caso la plataforma permite distinguir los actos ACCESO_CER y FIRMA para el caso de entrada con certificado digital y el acto ACCESO_AN para el entrada anónima. [ v01r20 ] 03/04/2014 Pág 18 de 67

19 Debe asegurarse mediante el modelado, en caso de usar los actos administrativos para esta funcionalidad, que para cada tipo de autenticación sólo exista una transición posible. Se distinguen cualquiera de los dos actos administrativos, no es obligatorio usar ambos. Se indican estos como mínimo porque un acto se corresponde con una fecha concreta, en términos con una transición, por defecto se indica de esta forma por si se quiere etiquetar la transición de entrada y la transición de presentación con actos diferentes. Son fechas distintas y actos distintos, en el caso de usarse acto administrativo, sino se podría poner a las dos transiciones cualquiera de ellos. Es decir, sólo afecta si usas los actos y se hace de forma coherente con el modelado. El hecho de distinguir cualquiera de los dos actos es debido a que se ha mantenido la opción por defecto, pero por configuración se podrían añadir los que se quisieran distinguir en caso de ampliarlos. 5. [29/11/2013] El documento a generar de la solicitud debe ser marcado como obligatorio para que la Oficina Virtual lo genere automáticamente. 6. El usuario CIUDADANO debe tener asignados, además, los perfiles correspondientes a aquellas tareas definidas en la fase o fases que intervenga del procedimiento y que deberán ser ejecutadas por dicho [ v01r20 ] 03/04/2014 Pág 19 de 67

20 usuario. 7. El asistente de tareas que se le muestra al ciudadano desde la Oficina Virtual, utiliza el campo orden de las tareas definidas para establecer el orden de ejecución de las mismas. 8. Si procede, debe conocerse el nombre de la tarea preestablecida que permite la asociación datos de contacto del interesado al expediente, si no existe dicha tarea definida se tomarán los de por defecto del interesado. En adelante tomaremos como ejemplo de nombre de tarea TA_DGSA_DATOS_INTERESADO. Esta tarea debe definirse en el procedimiento para ofrecer la interfaz por defecto de recogida de datos de contacto del ciudadano. Igualmente, debe tenerse en cuenta que el interesado se asociará al expediente resultado de la instanciación del procedimiento mediante una razón de interés previamente configurada, que en el caso de la plataforma de Gobierno de Cantabria se ha definido como INTERESADO. En este punto, la plataforma permite distinguir para esta funcionalidad las tareas nombradas como TA_XXXX_DATOS_INTERESADO, dónde XXXX es un acrónimo de 4 letras que puede corresponderse con el procedimiento en el que se usa o el sistema en general al que pertenece dicho procedimiento. 9. Para las tareas concretas definidas en el procedimiento de tipo generación de escritos debe establecerse el modo de generación. 10.Para los documentos que deban ser firmados debe establecerse el tipo de firma e indicar como firmante del mismo el correspondiente al usuario CIUDADANO. El proceso de firma se habilita mediante lo descrito en el siguiente punto. 11. Como última tarea en la fase destinada a las tareas del ciudadano debe definirse la correspondiente tarea reservada para la finalización del proceso por parte del ciudadano según el tipo de autenticación disponible. Téngase en cuenta para este punto que además las tareas deben tener ciertas características, como por ejemplo, si los documentos deben registrarse (atributo Registrable ) después de la firma, etc.. En este caso la plataforma permite distinguir para el caso de autenticación con certificado las tareas nombradas como TA_XXXX_FIRMAR_REGISTRAR o TA_XXXX_FIRMAR_REGISTRAR_SOLICITUD ; además [ v01r20 ] 03/04/2014 Pág 20 de 67

21 TA_XXXX_CERRAR o TA_XXXX_CIERRE_SOLICITUD para el caso de entrada anónima, dónde XXXX es un acrónimo de 4 letras que puede corresponderse con el procedimiento en el que se usa o el sistema en general al que pertenece dicho procedimiento. Debe tenerse en cuenta que la Oficina Virtual organiza el orden de las tareas en función del atributo orden establecido en tiempo de modelado de las mismas, por lo que estas tareas reservadas deben ubicarse con el orden más alto dentro de la fase. Además provocan el siguiente cambio de fase por lo que la transición de salida de fase debe tener el perfil adecuado asociado al ciudadano además del acto administrativo correspondiente en caso de usar esta funcionalidad anteriomente descrita en el punto Para el resto de tareas, destacar simplemente las concretas del tipo manipulación de datos que serán invocadas según mecanismo de integración que se describe más adelante. 13.Para la generación del documento Recibí para el ciudadano desde la Oficina Virtual, debe tenerse en cuenta que la plataforma espera obtener la plantilla de generación del mismo de un tipo de documento RECIBI que debe existir definido en el sistema Trew@ en el que se importan los procedimientos. 14.[G ONCE v /12/2012] Para permitir la subida de Otra documentación desde el paso de incorporación de documentos, debe existir el tipo de documento por defecto que se asociará, por defecto DOC_ADICIONAL Requisitos particulares para la interfaz de Agenda de Tramitación De la misma forma que en el apartado anterior, se describen a continuación los requisitos a tener en cuenta en la definición del procedimiento para ciertas funcionalidades de la interfaz destinada al Gestor, Agenda de Tramitación. Pueden clasificarse los mismos en varios grupos. En general, el usuario Gestor autenticado en la Plataforma deberá estar dado de alta como usuario de Trew@ y debe tener los perfiles de usuario adecuados, al menos TR_R_USUARIO de Trew@ y los perfiles necesarios definidos en el procedimiento para la realización de tareas y tramitación de fases. Estos perfiles determinaran qué acciones puede realizar en cada momento e incluso qué tipos de expediente puede dar de alta directamente desde la Agenda de Tramitación de G ONCE. Las tareas de gestión de escritos, al igual que en la Oficina Virtual, deberán [ v01r20 ] 03/04/2014 Pág 21 de 67

22 tener establecido los atributos que indican el modo de generación de los mismos y plantilla de generación. De la misma forma las tareas concretas del tipo manipulación de datos serán invocadas según mecanismo de integración que se describe más adelante. En cuanto a las funcionalidades de firma de documentos: 1. El tipo de documento que se vaya a firmar debe tener definidos los firmantes que coincidirán en provincia y tipo de organismo con el puesto de trabajo del usuario autenticado en la Agenda de Tramitación. 2. Además, para realizar la firma de un documento, el tipo de documento en el procedimiento debe estar definido con los correspondientes atributos de firma ( Tipo de firma, Firma digital?, etc.), es decir, que su tipo de firma sea en Paralelo o Cascada y tiene que tener firmantes definidos.[g ONCE v /12/2012] A la hora de mostrar la lista de posibles firmantes, la agenda puede seleccionar uno por defecto tomándolo de la lista de usuarios asignados cuya razón de asignación coincida con #puesto_de_trabajo# (dónde puesto_de_trabajo se corresponda con el código del puesto del firmante definido, por ej. #PT_GESTOR# ). 3. Si se realiza el envío a Port@firmas se debe asegurar que el sistema tiene configurado el componente correspondiente al cual se realizará el envío Firmar docs en... (Dicho componente debe tener sus datos de componente previamente configurados). Además el tipo de documento se debe definir con el atributo Versionable (sólo para el caso de WebOffice), ya que al exportar el documento a PDF después de la selección de firmantes, se crea una nueva versión del mismo que permite volver a la versión editable del documento. [G ONCE v /12/2012] Para llevar a cabo la firma en trámite de una petición de firma de un documento enviado al propio Portafirmas del usuario autenticado en la Agenda de tramitación es necesario dar de alta el siguiente dato componente del componente PORTAFIRMAS (o el seleccionado en el sistema para Firmar docs en ) : URL_FIRMA_TRAMITE sign=true&gotorequest=#hashpet# 4. Otras consideraciones a tener en cuanta para realizar el envío a [ v01r20 ] 03/04/2014 Pág 22 de 67

23 es que tanto el usuario como el sistema (mismo código que el definido en estén dados de alta en 5. Si se desea para algún tipo de documento que su firma sea directamente con la Plataforma de Firma Electrónica (y no a través de Port@firmas) se debe definir en el texto auxiliar del tipo de documento COMP:@FIRMA es el nombre del componente en Trew@ configurado que representa esta plataforma de firma). Por ejemplo, si ponemos COMP:#@FIRMA#, debe existir en este caso un correctamente configurado. Para aquellos documentos que se desee registrar, debe cumplirse: 6. Para realizar el registro de un documento se debe definir el tipo de documento con el atributo Registrable y se debe asegurar que el sistema tiene configurado un componente de registro en el atributo Registrar docs en.... (dicho componente debe tener sus datos de componente previamente configurados). 7. Las oficinas de registro que se muestran en el formulario de registro de la Plataforma dependen del procedimiento y del tipo de registro que se realice. Registro de entrada: la unidad de registro y el destino se obtienen del procedimiento al que pertenece el expediente. La procedencia se obtiene del interesado del expediente. Registro de salida externo: la unidad de registro se obtiene del procedimiento al que pertenece el expediente y el destinatario es el interesado en el expediente. Registro de salida interno: la unidad de registro se obtiene del procedimiento al que pertenece el expediente y el registro y unidad administrativa de destino se seleccionan en el mismo formulario Interfaz de integración A continuación se describen aquellos aspectos técnicos relacionados con el desarrollo propiamente dicho y enfocados a que la Plataforma de Tramitación G ONCE pueda integrarse con cada uno de los desarrollos. Hablamos en los siguientes apartados de los aspectos de programación e implementación que deben tenerse en cuenta por los desarrolladores. [ v01r20 ] 03/04/2014 Pág 23 de 67

24 En líneas generales y cómo se apuntaba en los apartados iniciales de este documento, para la integración con la Plataforma se hará uso de una implementación de la interfaz es.guadaltel.gonce.integracion.client.gonceintegration (incluida en GonceIntegration.jar suministrado). En dicha implementación se debe recoger la funcionalidad particular de cada despliegue o desarrollo concreto de un procedimiento. IMPORTANTE: A partir de la versión v2.7.0 de la plataforma G ONCE (18/12/2012) es necesario actualizar a la librería GonceIntegration para poder hacer uso de las nuevas funcionalidades de operaciones en bloque y gráficas específicas. Las funcionalidades ofrecidas por ésta interfaz que deben ser implementadas son: Url de acceso a las tareas de manipulación de datos. Para ello se debe implementar el método taskaccess el cuál debe devolver la url que será instanciada desde la Plataforma de Tramitación, correspondiente a la tarea de manipulación de datos. public String taskaccess(trapiui apiui, String refexp, String reftarea, String nomtarea, String reftareaexp, String idiom, Map<String, Object> map) throws Exception Parámetros de documentos (tareas de generación de escritos). Devolverá un conjunto de parámetros y valores para los mismos definidos para el cálculo de variables del documento. Mediante este mecanismo se guardará el valor del parámetro en concreto que se utilizará posteriormente por el motor Trew@ en el cálculo de las variables al realizar la sustitución de las mismas en los documentos. public TrValorParametro[] documentparameters(trapiui apiui, String refexp, String refdocexp, String idiom, Map<String, Object> map) throws Exception [G ONCE v /12/2012] Operaciones en bloque específicas del procedimiento. Devolverá una lista de operaciones en bloque específicas para el procedimiento. Para cada operación se debe indicar su identificador, descripción, clave 3DES para cifrar los parámetros, url de la operación, el tiempo de vida (lifetime) en milisegundos para la validez del ticket y el tipo de acceso o forma en la que se abrirá (popup o iframe). public List<OperationBlock> operationsinblock(trapiui apiui, String refprocedimiento, String lang, Map<String, Object> propiedades) throws Exception [ v01r20 ] 03/04/2014 Pág 24 de 67

25 [G ONCE v /12/2012] Estadísticas específicas del procedimiento. Devolverá una lista de estadísticas en bloque específicas para el procedimiento. Para cada estadísticas (gráfica) devolverá el identificador, descripción y el tipo de acceso o forma en la que se abrirá (popup o iframe). [G ONCE v /12/2012] Datos de la estadística específica del procedimiento. Devolverá un objeto ChartData que incluye un mapa en el que se indica la etiqueta y el número de elementos para dicha etiqueta para montar la gráfica correspondiente. A este método se le indica mediante el parámetro codgrafica el identificador de la estadística (gráfica) seleccionada de las disponibles para el procedimiento. public ChartData chartdata(trapiui apiui, String refproc, String codgrafica, List<String> expedientes, String lang) throws Exception Obtención de la API de Trew@. Debe devolver un objeto apiui de Trew@ que será usado por los mecanismos de integración de la Plataforma de Tramitación en aquellas operaciones que lo necesite. public TrAPIUI getapiui(string locateduser, String locatedcodesystem) throws Exception Cerrado de la API de Trew@. Permite indicar a cada desarrollo cuándo deja de ser útil el api obtenida mediante el método anterior. Esto permite por ejemplo indicar al desarrollo concreto que puede cerrar ordenadamente el api si fue creada como objeto nuevo exclusivamente para devolverla en el método anterior. public void closeapiui(trapiui apiui) throws Exception 3.5. Integración de condiciones, acciones y variables El desarrollo de estos elementos no requiere interfaz concreta de integración, basta con hacer el desarrollo de los métodos que representan a los mismos tal como se haya definido en el procedimiento importado en el motor Trew@ (ver para más detalles el apartado sobre condiciones acciones y variables java en el documento Guía de referencia JtrApi de Trew@). Los métodos que implementen las condiciones, acciones y variables definidas en cada procedimiento deben encontrarse disponibles en la carpeta lib del despliegue, empaquetadas en ficheros.jar para que estén accesibles al mecanismo de integración de la Plataforma de Tramitación G ONCE, como se [ v01r20 ] 03/04/2014 Pág 25 de 67

26 describió en los apartados iniciales de este documento [G ONCE v /12/2012] Acción para la numeración de expedientes Para llevar a cabo la numeración de expedientes de forma sincronizada e independiente por cada procedimiento la plataforma de tramitación G ONCE dispone de una acción, que se puede asociar a cualquier transición, documento o tarea del procedimiento, mediante la cuál se invoca a un servicio sincronizado para llevar a cabo la numeración del expediente. La clase de la acción es es.guadaltel.gonce.framework.actions.recordnumberaction la cuál invoca al EJB GonceRecordUtilitiesEJB.jar del módulo GonceRecordUtilities.ear. A continuación se puede ver la definición de la acción en Model@: Definición de la acción para la numeración de expedientes Una vez definida la acción es necesario asociarla a la transición en la que el procedimiento considere que la solicitud pasa a ser un expediente. La configuración del EJB se lleva a cabo en el componente definido en la constante COMP_RECORD_UTIL. [ v01r20 ] 03/04/2014 Pág 26 de 67

27 Constante COMP_RECORD_UTIL indicando el componente El nombre del componente debe coincidir con el definido en la constante, por ejemplo GONCE_RECORD_UTILITIES. Componente que contiene la configuración (Dirección ip) Los datos del componente GONCE_RECORD_UTILITIES deben ser los siguientes: Atributo Descripción Valor JNDI_EJB Nombre JNDI (Java Naming and Directory Interface ) con el que se ha desplegado el EJB. GonceRecordUtilities /GonceRecordUtilitie sbean/remote. PERFIL Nombre del perfil con el que se creará la interfaz TrAPIUI (nombre del properties o Datasource). [Nombre del datasource] PUERTO Puerto en el que se encuentra desplegado el EJB TIMEOUT Tiempo máximo de espera en milisegundos para obtener el número correspondiente para el expediente dentro del procedimiento Datos del componente para la numeración de expedientes [ v01r20 ] 03/04/2014 Pág 27 de 67

28 En resumen, la secuencia que se sigue para llevar a cabo la numeración de un expediente es la siguiente: 1. Se da de alta la solicitud con un número provisional SOLI#xxx (dónde xxx es un número de 10 dígitos). 2. Se tramita la transición a la que se ha definido la acción de numeración de expedientes. 3. Al tramitar, se ejecuta la acción que invoca al servicio sincronizado para llevar a cabo la numeración del expediente. 4. Se modifica el número del expediente, numerándolo con el formato AÑO/PROCEDIMIENTO/NÚMERO, por ejemplo 2012/GONCE2/ El número provisional de la solicitud se almacena en las observaciones del expediente para que se pueda obtener mediante una consulta desde la Agenda de tramitación una vez que el expediente se haya numerado. De esta forma se puede obtener el expediente tanto por el número de expediente como por el número de solicitud [G ONCE v /12/2012] Actualización del número de expediente por procedimiento mediante HAT Mediante la Herramienta de Administración de Trew@ es posible actualizar el número del último expediente dado de alta para un procedimiento y un año concretos. Para ello es necesario modificar el campo Otros datos del procedimiento que contiene un xml con la siguiente estructura, mediante la cual se indica el último número que se ha asignado al expediente. Para modificar el procedimiento, accedemos al menú Definición de procedimientos > Procedimientos y Versiones de procedimientos, seleccionamos el procedimiento y pulsamos el botón Editar. Desde esta pantalla podemos descargar para modificar el xml y volver a subirlo con el número actualizado. [ v01r20 ] 03/04/2014 Pág 28 de 67

29 3.7. [G ONCE v /03/2014] Evaluación de condiciones La evaluación de condiciones de tramitar, iniciar tareas, generar o incorporar documentos, al mostrar las transiciones, eventos y tareas permitidas, se puede configurar para que se realice siempre, a petición del usuario o a nivel del procedimiento o sistema del expediente. El icono de la condición nos indica si ésta ha sido evaluada o no y su resultado. Los distintos estados en los que se puede mostrar son los siguientes: Las condiciones no han sido evaluadas, el usuario puede pulsar para que se evalúen en ese momento. Las condiciones han sido evaluadas y todas las condiciones obligatorias se cumplen, se puede ejecutar. Las condiciones han sido evaluadas y alguna condición obligatoria no se cumple, no se puede ejecutar. [ v01r20 ] 03/04/2014 Pág 29 de 67

30 Si la evaluación de condiciones está desactivada por defecto, se puede particularizar su evaluación a nivel de procedimiento o sistema mediante las constantes siguientes: Constante Descripción Valores posibles EVCON_TRA_xxx Permite configurar la evaluación de condiciones de tramitar al cargar las transiciones. En xxx se debe indicar la abreviatura del procedimiento o el código del sistema. true o false EVCON_EVE_xxx Permite configurar la evaluación de condiciones de tramitar al cargar los eventos. En xxx se debe indicar la abreviatura del procedimiento o el código del sistema. true o false EVCON_TAR_xxx Permite configurar la evaluación de condiciones de iniciar tareas al cargar las tareas permitidas. En xxx se debe indicar la abreviatura del procedimiento o el código del sistema. true o false EVCON_DOC_xxx Permite configurar la evaluación de condiciones de generar o incorporar al cargar los documentos permitidos. En xxx se debe indicar la abreviatura del procedimiento o el código del sistema. true o false 3.8. [G ONCE v /12/2012] Operaciones en bloque Existen dos tipos de operaciones en bloque disponibles para la plataforma de tramitación G ONCE. Por una parte existen las operaciones en bloque genéricas que vienen integradas por la plataforma y por otro existen las operaciones en bloque específicas que cada procedimiento puede incluir ampliando así la funcionalidad de la plataforma. [ v01r20 ] 03/04/2014 Pág 30 de 67

31 Operaciones en bloque genéricas Existen varias operaciones en bloque ya integradas por defecto en la plataforma G ONCE. Estas operaciones se definen en el fichero configagenda.xml de la Agenda de tramitación mediante las etiquetas <operationsinblock> y <operation>. Los datos necesarios para definir una operación en bloque genérica son los siguientes: Etiqueta Descripción Valor de ejemplo <code> Código o identificador de la operación en bloque OP_GEN_01 <textkey> Clave de la etiqueta en el fichero etiquetas.propiedades o texto literal para mostrar de la operación en bloque. operacionesbloque.tram itar <url> Dirección url de la operación en bloque. opbloquegonce/tramitar/tramita cionbloque.jsf <key> Clave 3DES para el cifrado de los parámetros 0x11,0x11,0x11,0x11,0x 11,0x11,0x11,0x11,0x11,0x11,0x11,0x11,0x11,0 x11,0x11,0x11,0x11,0x1 1,0x11,0x11,0x11,0x11, 0x11,0x11 <lifetime> Tiempo de vida en milisegundos para la validez del ticket con el que se cifran los parámetros <accesstype> Tipo de apertura para la operación en bloque. Los valores permitidos son iframe (capa dentro de la Agenda) o popup (ventana nueva). iframe A continuación se adjunta un fragmento del fichero config-agenda.xml a modo de ejemplo. [ v01r20 ] 03/04/2014 Pág 31 de 67

32 Operaciones en bloque específicas Las operaciones en bloque específicas están disponibles para un procedimiento en particular. Para hacer funcionar estas operaciones es necesario definir y configurar correctamente las constantes CLS_OP_BLOQUE y OP_BLOCK_xxx (más información de estas constantes en el apartado Configuración del sistema en Trew@ ). Mediante la implementación del método operationsinblock se ponen a disposición del usuario las operaciones específicas para el procedimiento seleccionado en la búsqueda. Este método devuelve una lista de operaciones en bloque (OperationBlock) cuyos atributos son los siguientes: Atributo Descripción Valor de ejemplo id Código o identificador de la operación en bloque OP_ESP_MAIL description Descripción para mostrar de la operación en bloque. Envío de mails en bloque url Dirección url de la operación en bloque. opbloquegonce/ /envio sbloque.jsf key Clave 3DES para el cifrado de los parámetros 0x11,0x11,0x11,0x11,0x 11,0x11,0x11,0x11,0x11,0x11,0x11,0x11,0x11,0 x11,0x11,0x11,0x11,0x1 [ v01r20 ] 03/04/2014 Pág 32 de 67

33 1,0x11,0x11,0x11,0x11, 0x11,0x11 lifetime Tiempo de vida en milisegundos para la validez del ticket con el que se cifran los parámetros accesstype Tipo de apertura para la operación en bloque. Los valores permitidos son iframe (capa dentro de la Agenda) o popup (ventana nueva). iframe A continuación se adjunta una captura de la implementación de dicho método en la clase de integración para el procedimiento de ejemplo GONCE2. En este caso se devuelve una operación específica de envío de correos electrónicos en bloque y su configuración se obtiene del fichero gonce.properties. GonceGONCE2IntegrationImpl.java gonce.properties [ v01r20 ] 03/04/2014 Pág 33 de 67

34 Implementación del método operationsinblock Propiedades accesibles mediante ticket Las operaciones en bloque reciben el parámetro ticket mediante el que pueden obtener un mapa de propiedades con los siguientes valores: Inicialización del componente ticket y obtención de mapa de propiedades Clave de la propiedad ID_STMA COD_STMA Valor de la propiedad Idenficador del sistema establecido en la Agenda Código del sistema establecido en la Agenda [ v01r20 ] 03/04/2014 Pág 34 de 67

35 DESC_STMA USUARIO NOMBRE_USU APELLIDO1_USU APELLIDO2_USU IDENT_USU EXPEDIENTES ID_PROCEDIMIENTO ABREV_PROC DESC_PROC COD_PTO_TRABAJO NOMB_PTO_TRABAJO DESC_PTO_TRABAJO ID_ORGANISMO COD_ORGANISMO DESC_ORGANISMO FECHA_HORA_ACTUAL Descripción del sistema establecido en la Agenda Código del usuario autenticado en la Agenda. Nombre del usuario autenticado en la Agenda. Primer apellido del usuario autenticado en la Agenda. Segundo apellido del usuario autenticado en la Agenda. Identificador (NIF) del usuario autenticado en la Agenda. Lista de los identificadores de los expedientes seleccionados, separados por el carácter #. Identificador del procedimiento. Abreviatura del procedimiento. Descripción del procedimiento. Código del puesto de trabajo seleccionado para el usuario autenticado en la Agenda. Nombre del puesto de trabajo seleccionado para el usuario autenticado en la Agenda. Descripción del puesto de trabajo seleccionado para el usuario autenticado en la Agenda. Identificador del organismo al que pertenece el puesto de trabajo seleccionado para el usuario autenticado en la Agenda. Código del organismo al que pertenece el puesto de trabajo seleccionado para el usuario autenticado en la Agenda. Descripción del organismo al que pertenece el puesto de trabajo seleccionado para el usuario autenticado en la Agenda. Fecha y hora actual en la que se invoca a la operación en [ v01r20 ] 03/04/2014 Pág 35 de 67

36 bloque. Formato dd/mm/yyyy HH:mm. IDIOMA <Propiedades del fichero agenda.properties> Idioma establecido en la Agenda. Conjunto de propiedades de configuración recogidas en el fichero agenda.properties [G ONCE v /12/2012] Estadísticas En la plataforma de tramitación G ONCE existen dos tipos de gráficas de estadísticas: genéricas que ya vienen integradas por defecto y específicas que se obtienen mediante la implementación de una clase de integración Estadísticas genéricas Existen varias gráficas estadísticas que vienen integradas en la plataforma. Para definir estas estadísticas como genéricas es necesario darlas de alta en el fichero config-agenda.xml mediante las etiquetas <charts> y <chart> y definir los valores de las siguientes etiquetas: Etiqueta Descripción Valor de ejemplo <code> Código o identificador de la gráfica. GR_GEN_01 <textkey> Clave de la etiqueta en el fichero etiquetas.propiedades o texto literal para mostrar de la estadística o gráfica. graficas.expporprocedimientos <class> Clase que implementa la interfaz com.gtel.integracion.g raficas.graficaagenda para devolver los datos con los que se construye la gráfica. com.gtel.agenda.graficas.grafi cagenericaexpedientes <accesstype> Tipo de apertura para la gráfica / estadística. Los valores permitidos son iframe [ v01r20 ] 03/04/2014 Pág 36 de 67

37 iframe (capa dentro de la Agenda) o popup (ventana nueva). A continuación se adjunta un fragmento del fichero config-agenda.xml a modo de ejemplo Estadísticas específicas Las estadísticas específicas sólo están disponibles para un procedimiento en particular. Para hacer funcionar estas operaciones es necesario definir y configurar correctamente las constantes CLS_ESTADISTICAS y CHART_xxx (más información de estas constantes en el apartado Configuración del sistema en Trew@ ). Mediante la implementación del método chartsprocedure se devuelven las estadísticas específicas para el procedimiento. La consulta de estadísticas específicas devuelven una lista de objetos Chart para los que se deben indicar los siguientes atributo: Atributo Descripción Valor de ejemplo id Código o identificador de la gráfica. GR_ESP_01 description Descripción de la gráfica a mostrar en Estadística [ v01r20 ] 03/04/2014 Pág 37 de 67

38 la Agenda. accesstype Tipo de apertura para la gráfica / estadística. Los valores permitidos son iframe (capa dentro de la Agenda) o popup (ventana nueva). específica del procedimiento iframe Una vez seleccionada la estadística a mostrar se obtienen los datos mediante el método chartdata indicándole la gráfica seleccionada. Este método devuelve un objeto ChartData con el siguiente atributo: Configuración del sistema en Trew@ Para realizar la correcta integración de Oficina Virtual, Agenda de Tramitación y Trew@ con los distintos despliegues realizados, se deberá configurar en Trew@ las constantes del sistema concreto al que pertenecen los procedimientos que pretenden implantarse: Código EJB_xxx Descripción Indica la ruta JNDI (Java Naming and Directoring Interface) del EJB (Enterprise Java Bean) para la integración con la Plataforma de Tramitación. En el código de la constante se debe indicar la abreviatura del procedimiento en lugar de xxx, por ejemplo EJB_PROC01. Mediante este EJB se obtendrá la url de acceso a las tareas, las oficinas de registro, etc. El valor de esta constante para un despliegue gonce2.ear deberá ser /gonce2/gonceenvironmentintegrationbean/remot e. TASK_ACC_xxx Indica el nombre de la clase que implementa el método que devuelve la url de acceso a las tareas (taskaccess). En el código de la constante se debe indicar, en lugar de xxx, la abreviatura del procedimiento, por ejemplo TASK_ACC_PROC01. [G ONCE v2.7.0 Indica el nombre de la clase que implementa el [ v01r20 ] 03/04/2014 Pág 38 de 67

39 18/12/2012] OP_BLOCK_xxx método que devuelve la lista de operaciones en bloque específicas. (operationsinblock) En el código de la constante se debe indicar, en lugar de xxx, la abreviatura del procedimiento, por ejemplo OP_BLOCK_PROC01. [G ONCE v /12/2012] CHARTS_xxx Indica el nombre de la clase que implementa los métodos que devuelven la lista de estadísticas específicas (chartsprocedure) y los datos de la gráfica específica seleccionada (chartdata). En el código de la constante se debe indicar, en lugar de xxx, la abreviatura del procedimiento, por ejemplo CHARTS_PROC01. DOC_PARAM_xxx Indica el nombre de la clase que implementa el método que devuelve el conjunto de parámetros a establecer para el documento (documentparameters). En el código de la constante se debe indicar, en lugar de xxx, la abreviatura del procedimiento, por ejemplo DOC_PARAM_PROC01. IMPORTANTE: Si no se van a definir parámetros adicionales no es necesaria. INV_MTHD_xxx Indica el nombre de la clase que implementa el método getapiui que devuelve una instancia del TrAPIUI ya creada, que se le establecerá a la condición, acción o variable que extienda de TrAccesoUI. Si no es necesario disponer de un TrAPIUI en la condición, acción o variable no es necesario definir esta constante. En el código de la constante se debe indicar, en lugar de xxx, la abreviatura del procedimiento, por ejemplo INV_MTHD_PROC01. INVOKER_xxx Indica el nombre de la clase que ejecutará las condiciones, acciones y variables de Trew@. El valor debe ser es.guadaltel.invoker.invokerlocalorejb. En el código de la constante se debe indicar, en lugar de xxx, la abreviatura del procedimiento, por ejemplo [ v01r20 ] 03/04/2014 Pág 39 de 67

40 INVOKER_PROC Cómo integrar un procedimiento en la Plataforma G ONCE? A modo de resumen, tal como se ha especificado durante los apartados anteriores, y teniendo en cuenta que el Procedimiento concreto está implantado en el Motor de Tramitación Trew@ (suficientemente definido con las consideraciones que se describen en los apartados anteriores), cada desarrollo que implementa un determinado procedimiento administrativo sobre la Plataforma de Tramitación G ONCE, debe suministrar los siguientes recursos: Clase que extienda GonceIntegrationReferenceImpl (lógica por defecto para cada una de las funcionalidades ofrecidas) que a su vez implementa GonceIntegration. Clases de condiciones, acciones y variables definidas en el procedimiento Trew@. Aplicación web que incluirá los formularios y pantallas relativos a las tareas de manipulación de datos definidas en el procedimiento Trew@. Configurar las constantes de sistema en Trew@ definidas en el apartado Configuración del sistema en Trew@. Todos estos recursos (excepto el relativo a configuración) deberán ir empaquetados en un fichero.ear tal como se indica en el Diagrama 1 definido en el apartado Arquitectura de integración ( gonce2.ear ) Inclusión de los procedimientos en el modo de visualización por áreas. Para mostrar los procedimientos en el modo de visualización por áreas, es necesario tener en cuenta los distintos apartados de este modo: Trámites destacados: En este apartado aparecen los procedimientos que entre sus fichas se encuentra una cuyo tipo indicación es DES y su descripción corresponde al orden de aparición. Trámites más usados: En este apartado aparecerán automáticamente los procedimientos que más expedientes tienen creados. [ v01r20 ] 03/04/2014 Pág 40 de 67

41 Áreas: El resto de áreas que aparecerán corresponden con los procedimientos que entre sus fichas se encuentra al menos una, cuyo tipo de indicación es AREA y su descripción corresponde con alguna de las áreas definidas en la oficina virtual Definir nuevas áreas en la oficina virtual. Para definir nuevas áreas en la oficina virtual, hay que tener en cuenta los siguientes pasos: En el fichero messages_xx.properties deben existir las etiquetas para cada área, por lo tanto para crear una nueva área necesitaremos crear dos nuevas etiquetas de la siguiente manera: tramites.xxxxxx.titulo=titulo DEL NUEVO ÁREA tramites.xxxxxx.descripcion=descripción del nuevo área. Donde XXXXXX será el identificador del nuevo área. En la carpeta menu del tema utilizado por la oficina virtual se debe incorporar una imagen con el nombre de fichero XXXXXX definido en el punto anterior y la extensión png, de forma que la imagen para el área debe quedar de la siguiente manera: /temas/cantabria/menu/xxxxxx.png Por defecto, en el messages_es.properties, se han definido las siguientes áreas, que no serán necesario definir de nuevo: AGRICULTURA CULTURA ECONOMIA EDUCACION IDI IMPUESTOS INDUSTRIA INFRAESTRUCTURA JUSTICIA JUVENTUD NATURALEZA OCIO PESCA SALUD TRABAJO TURISMO [ v01r20 ] 03/04/2014 Pág 41 de 67

42 3.12. [G ONCE v /12/2012] Implementación correcta de tareas. Como norma general, se implementarán las tareas con dos formas de uso, alta y modificación, el proceso de alta será el que se ejecute cuando se acceda a la tarea por primera vez, esto se podrá detectar porque el estado de la tarea en Trew@, al acceder, será iniciado ( I ). La tarea debe comprobar que estado tiene establecida en Trew@. Si el estado es iniciado ( I ), mostraremos la tarea totalmente funcional, permitiendo introducir datos y trabajar con la tarea normalmente. Si el estado es finalizado ( F ), la tarea se mostrará en solo lectura, con un botón específico para modificar, pulsando este botón se cambiará el estado de la tarea, haciendo un reanudar de la tarea, volviendo a encontrarse en estado iniciado ( I ) y mostrando la tarea, ahora si, totalmente funcional. En el wizard existen los botones Salir, Atrás, Siguiente y Finalizar cuyo funcionamiento será el siguiente: Salir: Sale del asistente, volviendo a la Oficina Virtual y permitiendo continuar con el proceso más adelante. Atrás: Retrocede un paso en el asistente. Siguiente: Avanza un paso en el asistente, para permitir el avance se debe haber finalizado la tarea en Trew@, de esto se encargará la propia tarea, no la Oficina Virtual. Finalizar: Finalizará el trámite, saliendo del asistente, pero sin poder reanudarlo más adelante. Esta acción está destinada a las tareas de cierre, por lo que siempre mostraremos este botón desactivado. Para poder invocar estas funcionalidades desde las tareas de manipulación de datos, deberemos tener en cuenta estas consideraciones: La oficina y los procedimientos debe encontrarse bajo el mismo dominio, para evitar problemas de seguridad con el navegador. Si se desea desplegar en dos subdominios distintos, será necesario enmascararlos tras un servidor http, bajo el mismo dominio. Para realizar el avance desde una tarea, se debe implementar la tarea de forma que el botón Siguiente guarde los datos de la tarea, finalice la tarea en Trew@ y vaya a una nueva pantalla donde se especifique que la acción se ha [ v01r20 ] 03/04/2014 Pág 42 de 67

43 realizado correctamente, en esta pantalla deberemos introducir el siguiente código JavaScript: <!-- Al llegar a esta página se produce un avance en el wizard. --> <script type="text/javascript"> window.parent.dowizardaction('_wizard_next'); </script> De esta forma, al acceder esta página se mostrará el mensaje del proceso satisfactorio, mientras se avanza al siguiente paso del asistente. Para invocar el resto de funcionalidades basta con indicar la acción deseada ('_wizard_prev','_wizard_exit', '_wizard_finish') [G ONCE v /12/2012] Accesos a la Oficina Virtual. La oficina virtual, permite el acceso directo a ciertas pantallas, mediante la inclusión parámetros en la url: Detalles de procedimientos Para acceder al detalle de un procedimiento se le deben agregar cualquiera de los siguientes parámetros, con sus respectivos valores: idexterno: Corresponde al código w@nda del procedimiento, definido en las pantallas de administración de G ONCE. id: Corresponde al identificador del procedimiento. proc: Corresponde a la abreviatura del procedimiento. Si se facilitan más de uno de los parámetros anteriores, el filtrado para obtener el procedimiento se realizará buscando el procedimiento que cumpla con todos los parámetros facilitados. Si se desea acceder directamente a la sección de descargas de documentos de la ficha del procedimiento se puede acceder añadiéndole #plantillas a la URL montada con el procedimiento anterior. Ejemplo: [ v01r20 ] 03/04/2014 Pág 43 de 67

44 Mediante esta URL accederemos a la ficha del procedimiento cuyo identificador sea el 731 y su abreviatura GONCE2. Mediante esta URL accederemos a la sección de descargas, en la ficha del procedimiento cuyo identificador sea el 731 y su abreviatura GONCE Inicio de expediente Para dar de alta un expediente en un procedimiento, a la URL del acceso generada en el apartado anterior habría que añadirle el parámetro alta con los siguientes valores: Ejemplo: alta=true: Si está permitida el alta de solicitudes anónimas, se inicia un trámite de forma anónima, si no está permitida, se pedirá autenticación. alta=certificado: Se pedirá autenticación para iniciar el trámite. Mediante esta URL iniciaremos un trámite en el procedimiento cuyo identificador sea el 731, solicitando autenticación Descarga de documentos relativos al procedimiento: Para descargar los documentos asociados a un procedimiento directamente, podremos utilizar el siguiente parámetro: Ejemplo: descarga=true: En cuyo caso, se descargará el fichero asociado, en el caso que solo exista uno, y un zip con todos los documentos, en el caso que existan más. Mediante esta URL descargaremos los documentos asociados al procedimiento cuyo identificador sea el Otros parámetros en las llamadas Se ha habilitado la posibilidad de añadir los siguientes parámetros en la llamada a la oficina, y poder modificar los valores configurados: [ v01r20 ] 03/04/2014 Pág 44 de 67

45 activebreadcrumb: Si es true, activa la miga de pan, en otro caso depende de la configuración de la Oficina. norestrinction: Si es true, se permite acceso a toda la aplicación, en otro caso depende de la configuración de la Oficina [G ONCE v /12/2012] Configuración de seguridad de la Oficina Virtual. La oficina virtual permite activar un filtro de seguridad, mediante el cuál los usuarios solo podrán acceder a las secciones habilitadas. Para activar este filtro se debe configurar a true la propiedad application.security, en el oficina.properties, si se encuentra desactivada, se podrá acceder a la aplicación sin restricciones de seguridad. Estas restricciones, se pueden saltar facilitando un parámetro en la url, si en la url se añade el parámetro norestrinction=true, el usuario podrá acceder a la aplicación sin restricciones. Como complemento a esta característica, existe la posibilidad de desactivar la miga de pan de la aplicación, para evitar que el usuario pueda acceder a secciones no permitidas, para ello se configurará, en el oficina.properties, la propiedad application.breadcrumb.show, si se configura con valor true, la miga de pan seguirá apareciendo, en el caso de configurarlo como false, la miga desaparecerá. Al igual que la configuración de la seguridad, la miga de pan se puede activar, aún cuando se encuentre desactivada para la aplicación, para ello, será necesario añadir el parámetro activebreadcrumb=true, a la url, de esta manera la miga de pan se activará, para la sesión del usuario. Para configurar las secciones accesibles con la seguridad activada, se debe modificar el fichero web.xml, añadiendo los actions a los que se permite el acceso, en el init-param accionessinrestriccion, del filtro AuthenticationFilter [G ONCE v /01/2014] Recarga de expediente desde tarea Para recargar un expediente desde una tarea es necesario invocar a una función javascript ofrecida por la plataforma. Para que el funcionamiento sea correcto se debe de tener en cuenta la siguiente consideración: la Agenda y los procedimientos debe encontrarse bajo [ v01r20 ] 03/04/2014 Pág 45 de 67

46 el mismo dominio, para evitar problemas de seguridad con el navegador. Si se desea desplegar en dos subdominios distintos, será necesario enmascararlos tras un servidor http, bajo el mismo dominio. La función javascript a invocar es la siguiente: recargarexpediente(idexpediente, ocultarcapas); cuyos parámetros son el identificador del expediente que se quiere recargar en la Agenda y un booleano que indica si se oculta la propia capa de la tarea y la capa de fondo. Su uso debe ser el siguiente dependiendo de si la tarea es abierta en modo iframe o popup. Si la tarea es abierta en modo iframe se debe invocar el siguiente javascript: parent.recargarexpediente(idexpediente, true); en cambio, si la tarea es abierta en modo popup se debe invocar el siguiente javascript: opener.recargarexpediente(idexpediente, true); [ v01r20 ] 03/04/2014 Pág 46 de 67

47 4. Ejemplo Durante los siguientes apartados se describen los detalles del ejemplo realizado junto con este manual. Debe tomarse lo que a continuación se describe, como una guía de referencia general en los aspectos destacados para entender el funcionamiento general de la plataforma y no como estándar de facto sobre modelado de procedimientos o tecnologías de programación, que forman parte del desarrollo particular de los procedimientos a desplegar en la plataforma G ONCE y que deben regirse por las directrices y normas establecidas por el grupo de Arquitectura de Sistemas Descripción general del procedimiento de ejemplo El procedimiento del ejemplo es un procedimiento sencillo en el que se simula la presentación de una solicitud por parte de un ciudadano y la posterior intervención de un gestor para realizar una serie de actuaciones sobre dicha solicitud, para acabar almacenándola. Comenzaremos recorriendo el modelado del procedimiento paso a paso: [ v01r20 ] 03/04/2014 Pág 47 de 67

48 Como podemos observar el procedimiento permite iniciar una solicitud mediante distintas transiciones. Se definen las siguientes transiciones de inicio: TELEMÁTICA: Inicia una solicitud de forma telemática firmando electrónicamente la misma, desde la Oficina Virtual Para ello es necesario tener el perfil PF_CIUDADANO. SIN_CERTIFI: Inicia una solicitud sin certificado desde la Oficina Virtual. Para ello es necesario tener el perfil PF_CIUDADANO. PRESENCIAL: Inicia una solicitud de manera presencial desde la Agenda de Tramitación. Para ello es necesario tener el perfil PF_GESTOR. Si el alta de la solicitud realizada desde la Oficina Virtual y se ha realizado mediante certificado digital se tramitará la transición TELEMÁTICA y se llega a la fase de PRESENTACIÓN TELEMÁTICA. Por otro lado, si se realiza sin certificado digital se tramitará la transición SIN_CERTIFI y se llega a la fase PRESENTACIÓN PRESENCIAL. Estas fases representan el alta de una solicitud por parte de un ciudadano, en el caso de la telemática el ciudadano firmará y registrará su solicitud además de incorporar documentación. En esta fase se han creado una serie de tareas que son las citadas a continuación : [ v01r20 ] 03/04/2014 Pág 48 de 67

49 1. TA_DGSA_DATOS_INTERESADO. Esta tarea permite ofrecer la interfaz por defecto de recogida de datos de contacto del ciudadano. 2. EXPONE_SOLICITA: Esta tarea es de manipulación de datos, y en nuestro ejemplo es la tarea encargada de llamar al gonce2.ear y presentar el formulario que hayamos creado para el caso. 3. DOCUMENTO_DNI: Tarea de incorporación de documentación, en el ejemplo se ha simulado como la incorporación del DNI del ciudadano. 4. SOLICITUD: Tarea de generación de documentación, en este caso se ha simulado la generación de un documento de solicitud, en este documento se ha incluido una serie de variables cuyos valores se obtienen a través de la integración de la plataforma con el ejemplo desarrollado. 5. TA_DGSA_FIRMAR_REGISTRAR: Tarea reservada para la plataforma que indica a la misma que se va a realizar firma y registro en la Oficina Virtual de los documentos incorporados y generados en la fase (en el caso de acceso con certificado). 6. TA_DGSA_CIERRE_SOLICITUD: Como la anterior es una tarea reservada cuya finalidad es la de cerrar la solicitud y los documentos de la fase en el caso de acceso anónimo a la Oficina Virtual. El perfil para cada una de las tareas en esta fase es el mismo que en la transición inicial: PF_CIUDADANO. Como puede deducirse, las tareas 5 o 6 (la de firma sólo para el inicio de manera TELEMÁTICA) se encargan de indicar a la plataforma el cierre de la realización de tareas por parte del usuario ciudadano. Debe tenerse en cuenta que la Oficina Virtual organiza el orden de las tareas en función del atributo orden establecido en tiempo de modelado de las mismas, por lo que estas tareas reservadas deben ubicarse con el orden más alto dentro de la fase. Además provocan el siguiente cambio de fase por lo que la transición de salida de fase ( PRESENTAR ) debe tener el perfil adecuado asociado al ciudadano. [ v01r20 ] 03/04/2014 Pág 49 de 67

50 Si el alta de la solicitud se realiza desde la Agenda de Tramitación la transición inicial debe ser PRESENCIAL la cuál sólo está permitida realizar al perfil de usuario PF_GESTOR. En esta fase se han creado una serie de tareas que son las citadas a continuación : 1. EXPONE_SOLICITA: Esta tarea es de manipulación de datos, y en nuestro ejemplo es la tarea encargada de llamar al gonce2.ear y presentar el formulario que hayamos creado para el caso. 2. DOCUMENTO_DNI_PRESENCIAL: Tarea de incorporación de documentación, en el ejemplo se ha simulado como la incorporación del DNI del ciudadano. Para este tipo de documento se ha configurado el texto auxiliar del mismo indicando COMP:@FIRMA para que el gestor realice la firma del documento incorporado 3. SOLICITUD PRESENCIAL: Tarea de generación de documentación, en este caso se ha simulado la generación de un documento de solicitud, en este documento se ha incluido una serie de variables cuyos valores se obtienen a través de la integración de la plataforma con el ejemplo desarrollado. 4. [G ONCE v /12/2012] PUBLIC_NOTA: Tarea de tipo Otras que permite recoger en la tramitación del expediente la publicación de forma manual de una nota en el tablón de anuncios. [ v01r20 ] 03/04/2014 Pág 50 de 67

51 Una vez presentada se puede observar que la siguiente fase del procedimiento es SOLICITUD PRESENTADA la cuál simula la recogida por parte del gestor de las solicitudes creadas por los ciudadanos, el gestor podrá con esto incorporar un documento, podrá generar otro ( informe ) que podrá firmar y registrar. En la fase SOLICITUD PRESENTADA existen tres tareas correspondientes al gestor : 1. INFORME_GESTOR : Esta tarea es de manipulación de datos, y en nuestro ejemplo es la tarea encargada de llamar al gonce2.ear y presentar el formulario que hayamos creado para el caso. 2. DOCUMENTO_AYUDA : Tarea de incorporación de documentos, en este caso se ha simulado como la incorporación de un documento de ayuda. 3. INFORME : Tarea de generación de documento, se ha simulado en el ejemplo como la generación de un informe por parte del gestor. Contiene una serie de variables de ejemplo cuyo valor es obtenido a través de la integración de la plataforma. Este documento se ha modelado para que permita firma digital y registro por parte del gestor desde la Agenda de Tramitación que ofrece la Plataforma. [ v01r20 ] 03/04/2014 Pág 51 de 67

52 De forma análoga a como hicimos en al fase anterior debemos asignar un perfil a cada una de las tareas. En este caso y para distinguir el perfil que debe realizar las tareas (al estar en una fase destinada al gestor) el perfil se ha denominado PF_GESTOR. Continuando con el flujo tenemos la fase ARCHIVO, fase en la que se archiva la solicitud. No dispone de tareas ni de documentos. El perfil necesario para acceder a esta tarea es el del gestor PF_GESTOR. Por último como podemos observar disponemos de un evento denominado DOC_ADIC que lleva la solicitud a la fase DOCUMENTACIÓN ADICIONAL, en la cuál el gestor puede incorporar documentación adicional a la solicitud en cualquier momento de la tramitación de la misma. Al incorporar el documento se ejecuta la acción de enviar un correo informativo a los interesados de una solicitud. El perfil para realizar esta incorporación de documento es el del gestor PF_GESTOR. También se ha modelado en este documento a incorporar en el evento una condición de ejemplo asociada a esta tarea. [ v01r20 ] 03/04/2014 Pág 52 de 67

53 4.2. Configuración en el motor Se describe en este apartado los ajustes y configuraciones necesarias en el motor de tramitación Trew@ para poder instanciar el procedimiento desde la plataforma. Para ello una vez cerrado el procedimiento en Model@ e importado en el motor se han tenido en cuenta los requisitos que se describieron en apartados anteriores. En resumen: 1. Creación del sistema. En nuestro caso el sistema es DGOT, este sistema debe coincidir con el indicado en el campo Sistema al definir el procedimiento en Model@. 2. Creación de los organismos asociados al procedimiento. 3. Tipos de normativas, ámbitos de ley y tipos de publicación asociadas al procedimiento, si procede. 4. Tipos de indicaciones asociadas al procedimiento, si procede. 5. El procedimiento no debe estar bloqueado y debe estar asociado a algún tipo de expediente (todo ello en estado vigente). Igualmente, como se describía en los apartados anteriores sobre configuración del sistema, deben establecerse en el sistema que hemos importado nuestro procedimiento de ejemplo, las constantes de configuración que permiten la integración de la plataforma con el ejemplo desarrollado: Concretamente para la correcta integración con las pantallas de manipulación de datos del ejemplo deben existir como puede observarse: 1. EJB_GONCE2 : Indica la ruta el EJB de integración, dónde GONCE2 es el nombre del procedimiento como se indicó en el apartado 3.6. El valor de la constante para nuestro ejemplo es en este caso /gonce2/gonceenvironmentintegrationbean/remote (suponiendo que el.ear de despliegue se llama gonce2.ear ). 2. TASK_ACC_GONCE2 : Indica la clase que contiene el método que nos devolverá la url de la tarea, dónde GONCE2 es el nombre del procedimiento de ejemplo como se describió anteriormente. El valor es [ v01r20 ] 03/04/2014 Pág 53 de 67

54 es.guadaltel.gonce.integration.client.impl.goncegonce2integrationimpl, el nombre de la clase que hemos implementado para este ejemplo Descripción del archivo de despliegue de ejemplo A continuación se describe el archivo de despliegue desarrollado para el procedimiento de ejemplo GONCE2, que en nuestro caso se trata de gonce2.ear. En el ejemplo, los formularios que representan las tareas de manipulación de datos definidas en el procedimiento están empaquetados en una aplicación gonce2.war, empaquetado dentro del EAR. Debe tenerse en cuenta que esta aplicación concreta de ejemplo está desarrollada con tecnología Struts y usa además del propio motor de tramitación Trew@, un modelo de datos propio ( cliente ) para guardar una serie de campos recogidos mediante pantallas al efecto. Cabe destacar en este punto (como se enunciaba al inicio de este apartado sobre descripción del ejemplo) que los distintos desarrollos que se hagan sobre la plataforma no tienen por qué tener obligatoriamente un modelo de datos propio o usar el motor Trew@ (aunque ambos casos serán evidentemente frecuentes), ni usar tecnología Struts, es decir, que si queremos desarrollar tareas en una aplicación con tecnología Seam y usar como modelo de datos propio una base de datos MySql es totalmente factible para su funcionamiento en la plataforma. A continuación se presenta la estructura del gonce2.ear del ejemplo: La carpeta lib contiene las siguientes librerías: ConditionsActionsVariables.jar : Librería que contiene las condiciones, acciones y variables de ejemplo. GonceGONCE2IntegrationImpl.jar : Implementación concreta desarrollada para el ejemplo de la interfaz de integración. Trewa-api : Api de Trew@ además del conjunto de librerías [ v01r20 ] 03/04/2014 Pág 54 de 67

55 necesarias (necesario en el ejemplo por desarrollar un acceso a Trew@ mediante este api). El fichero gonce.properties se usa en nuestro ejemplo concreto para definir la URL de retorno del acceso tarea, el perfil o nombre del datasource de conexión a Trew@ y el datasource de conexión al modelo de datos propio. Esto quiere decir que ésto sólo es para nuestro ejemplo concreto, perfectamente la URL de retorno podríamos haberla recuperado de un fichero.txt o de un campo en una base de datos o cualquier otro mecanismo existente, incluyendo el de obtención mediante código del contexto de nuestro despliegue. El fichero ticket.properties que se utiliza para el cifrado de los parámetros de la url de acceso a las tareas. La carpeta META-INF contiene el archivo application.xml donde debe declararse el EJB y opcionalmente el nombre de contexto de la aplicación para el procedimiento. También incluiremos un archivo jboss-app.xml donde declararemos el loader repository de nuestro.ear y evitar así posibles conflictos entre clases. [G ONCE v /03/2014] GonceEnvironmentIntegrationEJB-cluster jar corresponde al EJB de integración de la plataforma necesario para las llamadas de ésta al desarrollo desplegado. gonce2.war es el archivo de despliegue del procedimiento concreto que contiene las pantallas que representan las tareas de manipulación de datos definidas en este ejemplo y todo lo necesario para la construcción del mismo con tecnología Struts. Insistimos de nuevo en este punto, en el caso de este ejemplo sólo existe un único war pero podrían construirse desarrollos en los que existieran distintos archivos wars, por ejemplo, gonce1.war, gonce2.war y gonce3.war cada uno de ellos con tecnologías distintas si fuera el caso, depende en definitiva de la propia construcción o requerimientos del procedimiento y organización del desarrollo que se lleve a cabo. [ v01r20 ] 03/04/2014 Pág 55 de 67

56 5. [G ONCE v /03/2014] Guía de Buenas Prácticas 5.1. Objetivos Durante los siguientes apartados se describen algunos aspectos a tener en cuenta para la integración de procedimientos con la Plataforma de Tramitación G ONCE, enfocados sobre todo al particular mecanismo de integración de procedimientos habilitado en la misma. Estas consideraciones generales no pretenden establecer unas normas de obligado cumplimiento, pero sí describir unas pautas que pueden tenerse en cuenta durante la definición y construcción del procedimiento, y que pueden tener efectos beneficiosos para la integración del mismo en la Plataforma, evidentemente en aquellos casos que puedan aplicarse según las características concretas de los propios procedimientos. El objetivo de esta guía, está orientado sobre todo a conocer con mayor detalle los mecanismos de integración y proponer sobre todo algunas técnicas o actuaciones que pueden aplicarse sobre los mismos, en aras de mejorar sobre todo el rendimiento global durante los procesos de integración entre Plataforma y los propios desarrollos de procedimientos junto con los elementos que lo componen Minimizar las llamadas a la integración vía EJB Tomando como punto de partida que, en cualquier ámbito, una comunicación entre 2 puntos tiene un determinado coste (adicional al de la operación concreta para la que se realiza dicha comunicación), y que en nuestro escenario puede existir un volumen alto de comunicaciones; las actuaciones que a continuación de describen se apoyan en el principio básico de minimizar dicho coste de integración, es decir, pretenden describir algunos mecanismos o técnicas disponibles que permiten disminuir o agilizar en gran medida el número de comunicaciones y procesos de integración, lo que influye directamente en una disminución del citado coste y por tanto en una mejoría del rendimiento en la comunicación, notable cuando existe elevado número de comunicaciones en un corto espacio de tiempo, pero aplicable de forma generalizada. Minimizar las llamadas a la integración vía EJB entre Plataforma y los Procedimientos mejora en su conjunto el rendimiento global del sistema, ya [ v01r20 ] 03/04/2014 Pág 56 de 67

57 que cada ejecución relacionada con la integración requiere de un coste de conexión entre los distintos servidores, lógica de aplicación, etc. que debe sumarse al propio coste de evaluación del resultado. Para minimizar estas llamadas existen tanto técnicas de definición como mecanismos de configuración, es decir, van desde la propia definición del procedimiento y los elementos que lo componen, hasta la configuración del mismo para parametrizar la lógica de ejecución en la que se traducen estos elementos al instanciarse Definición de elementos en los procedimientos Uno de los principales elementos de definición que tiene una implicación directa en los procesos de integración es el de Condiciones. Éstas pueden definirse tanto a nivel de transiciones/eventos como a nivel de cualquier tipo de tarea (documentos o formularios) y es un elemento de uso muy común, sobre todo asociado a la definición de eventos y en muchas ocasiones para ayudar a guiar al usuario en la tramitación o incluso para unificación de varios procedimientos en uno sólo. Hay que tener en cuenta que las condiciones modeladas en el procedimiento se convertirán en código o lógica de aplicación que será instanciada desde la plataforma. Para más detalles en este caso, es el propio motor de tramitación quien eleva las peticiones de ejecución por cada condición, por lo que hay que ser conscientes ya en tiempo de definición que a mayor número de condiciones definidas en una determinada transición o tarea mayor será el coste de evaluación de las mismas, ya que no sólo aumentamos el coste de la lógica en sí de la condición, sino que tenemos que añadir el tiempo necesario en los mecanismos de integración para poder ejecutar dicha lógica. No existen unas reglas básicas para aplicar en el modelado o definición de procedimientos ya que puede haber multitud de factores que intervengan (tipología y complejidad del procedimiento, tipo de usuario al que está destinado el mismo, hitos a cumplir, experiencias anteriores, etc.), no obstante, se enumeran a continuación algunos puntos que pueden tenerse en cuenta por si procediera su aplicación, al menos pueden permitir hacer un mejor análisis en tiempo de definición para tener en cuenta como se usarán los mismos dentro de la Plataforma y a qué puede afectar en tiempo de ejecución, permitiendo además plantear alternativas, mejores soluciones o como mínimo sopesar la idoneidad de las mismas. NOTA: Aunque este apartado se centra principalmente en el concepto de Condición, la mayoría de los puntos descritos son de aplicación igualmente al [ v01r20 ] 03/04/2014 Pág 57 de 67

58 elemento Acción, que aunque su fin es otro y su utilización es más concreta mantiene estrechos lazos de relación con el primero, ya que en ambos casos son lógica desarrollada que se definen y asocian a los mismos elementos de tramitación en un determinado procedimiento y que se ejecutan exactamente de la misma forma. Minimizar el número transiciones de salida desde una fase Aunque a priori no influye en los mecanismos de integración son elementos candidatos a llevar asociadas condiciones en un futuro, por tanto minimizando los puntos de decisión que representan estas transiciones colaboraría en minimizar el número de condiciones futuras que pudieran asociarse en las posibles reingenierías del procedimiento que se lleven a cabo. Sí existe un beneficio directo de aplicar esta técnica y es que la plataforma visualiza al usuario todas las opciones de salida que existen desde una determinada fase, por tanto, incluso aunque no lleven condiciones asociadas, en ciertos casos el usuario agradecerá que las posibles opciones que se le ofrezcan sean reducidas en número, de forma que le sea fácil tomar la decisión adecuada de una forma más ágil. Minimizar el número de eventos El punto anterior es aplicable a los eventos que pueden definirse en un procedimiento, igualmente puede tenerse en cuenta el numero de eventos que en un momento dado estarán disponibles para el usuario en un determinado expediente. Por definición, los eventos suelen tener asociadas condiciones de visualización o tramitación, en el primer caso para habilitarlos o deshabilitarlos según necesidades y en el segundo para hacer ciertas comprobaciones. Minimizar el número de eventos colaborará igualmente en disminuir el número de condiciones candidatas a evaluar y por tanto disminuirá el coste en evaluar las mismas, en definitiva el coste de integración en ejecución, además de agilizar las opciones de tramitación para el usuario desde su interfaz como se ha descrito anteriormente en el caso de transiciones. A veces los eventos se suelen modelar para representar funcionalidades a habilitar en interfaz más que para modelar las características del procedimiento y la naturaleza original para las que existen estos elementos. Es decir, se suelen utilizar en ocasiones no para modelar una nueva situación del expediente en el proceso administrativo, sino para poder habilitar alguna tarea gobernada por la lógica de las condiciones, aprovechando evidentemente los elementos de definición disponibles. En ocasiones es preferible habilitar estas funcionalidades mediante otro mecanismo de los disponibles antes que [ v01r20 ] 03/04/2014 Pág 58 de 67

59 incluirlo en las reglas del propio procedimiento. Un evento modelado sin condiciones es un ejemplo de caso a analizar, ya que significará que está disponible durante toda la tramitación y por tanto puede ser un caso de funcionalidad en interfaz genérica al procedimiento en vez de elemento de tramitación a definir. Minimizar el número de tareas en una fase De la misma forma que en los casos anteriores, disminuir el número de tareas por fase, no sólo ayudará a que el usuario de Plataforma tenga una interfaz más ágil en cuanto a los trabajos que deben realizarse en la fase, sino que además minimizará el número de tareas candidatas a las que añadir condiciones en un futuro. En algunos casos y siempre que sea posible, es más práctico para el usuario tener 5 tareas repartidas en 3 fases secuenciales en vez de 15 tareas asociadas a la misma fase, ya que además de simplificar la interfaz al usuario éste puede tener mayor sensación de ser guíado durante la tramitación del procedimiento. Minimizar el número de condiciones global en elementos de una fase La interfaz de usuario de la plataforma, en cuanto a la tramitación de un determinado expediente se refiere, visualiza en un sólo paso el número de transiciones y eventos posibles, así como el número de tareas disponibles en una determinada fase definida, todos estos elementos candidatos a albergar condiciones, algunos de ellos incluso por definición como es el caso de eventos. Por tanto, un índice de referencia que puede tenerse en cuenta es el número total de condiciones definidas que se evaluarán para todos estos elementos anteriores en una determinada fase, ya que son instanciados en un corto espacio de tiempo para visualizarlos por interfaz y como ya se ha nombrado, a mayor numero de condiciones a ejecutar mayor es el nivel de acoplamiento con los mecanismos de integración. En definitiva, hay que ejecutar de una vez toda la lógica de todas las condiciones disponibles. Minimizar el número de condiciones va a favorecer como mínimo el coste empleado en los mecanismos de integración, reduciéndolos proporcionalmente al número de condiciones existentes, o dicho de otra forma, se reducirán las invocaciones al EJB disminuyendo los costes adicionales de establecimiento de la conexión entre Plataforma y la lógica desarrollada. Para analizar esta reducción ya sea en tiempo de definición o desarrollo del procedimiento pueden tenerse en cuenta los siguientes factores: [ v01r20 ] 03/04/2014 Pág 59 de 67

60 Posibilidad de agrupamiento de varias condiciones en una única asociada a la transición, evento o tarea. A veces, en tiempo de diseño se tiende a modularizar en forma de condiciones cuando finalmente no es necesario hacerlo, incluso puede darse que exactamente las mismas condiciones definidas son reutilizadas en su totalidad en otro elemento del mismo procedimiento o incluso otro, lo que puede indicar que es más práctico agruparlas en una sola, facilitando además el mantenimiento en todas las instancias a las que deban asociarse como un todo. En otros casos, es inevitable el necesitar mantenerlas por separado, pero aún así puede encapsularse en una única condición que se encargue de invocar a las ya existentes, estableciéndose así una única llamada EJB además de simplificar la definición del procedimiento. Analizar la idoneidad de definición de condiciones de visualización. Hay que tener en cuenta que la evaluación de este tipo de condiciones se encuentra habilitada por defecto en la Plataforma y pueden asociarse igualmente a todos los elementos principales: transiciones, eventos, documentos y resto de tareas. Un alto grado de definición de este tipo de condiciones en un determinado procedimiento para parametrización del mismo, puede ser indicador de existencia de un procedimiento resumen (a modo de factor común ) lo que quizás debiera estar separado en varios procedimientos. Evitar trasladar, en la medida de lo posible, lógica de aplicación a las condiciones de tramitación. En ocasiones se suelen modelar en forma de condiciones, validaciones concretas sobre ciertos atributos del expediente que tienen una relación directa con otros elementos existentes en el procedimiento, alejándose de la naturaleza original de las condiciones de tramitación. Un caso concreto es la definición de validaciones de campos obligatorios a completar antes de poder abandonar la fase actual en forma de condiciones. Definir este tipo de condiciones obligatorias puede ser indicador de inexistencia de dicha validación obligatoria en los formularios donde se recoge el dato, práctica que obliga en cierta medida a ampliar con mayor detalle la definición del procedimiento cuando quizás no sea necesario. Si un dato es obligatorio, es obligatorio con gran probabilidad desde el momento que se habilita su introducción, aconsejándose en tal caso su validación en lógica de aplicación para evitar trasladarlo a lógica de tramitación, éstas últimas más encaminadas a definir aspectos globales que ayuden en la toma de decisiones. [ v01r20 ] 03/04/2014 Pág 60 de 67

61 Mecanismos de configuración En el caso de haber tenido en cuenta la revisión de elementos de definición detallada en los apartados anteriores, acerca de las distintas técnicas para minimizar el número de integraciones entre Plataforma y EJB de procedimiento (principalmente en lo que a condiciones se refiere) y encontramos con el punto inevitable de no poder reducir el número de elementos que intervienen en los mecanismos de integración, hay que tener en cuenta que la Plataforma ofrece además mecanismos de configuración que pueden habilitarse en caso necesario. En esta línea, se puede configurar a nivel del procedimiento para qué elementos (transiciones, eventos, tareas y documentos) se evalúan automáticamente las condiciones, o bien, para qué elementos se lanzan las ejecuciones bajo demanda del usuario (al hacer click en el icono de condiciones que existe en interfaz). Esto permite afinar mediante configuración en caliente y en los casos necesarios, el momento en el que la Plataforma lanzará las ejecuciones de lógica definidas en el procedimiento, en resumen, cuándo se evaluarán las condiciones de tramitación definidas. De forma general se puede desactivar dicha evaluación en los casos que concretos que exista un alto coste de evaluación de condiciones, ya sea por la propia lógica de las condiciones o por el alto grado de integración (elevado número existente). Para más detalles sobre esta configuración véase el apartado Evaluación de condiciones. Adicionalmente, la Plataforma ofrece al usuario desde el apartado de preferencias, la posibilidad de cambiar a nivel de sesión las configuraciones que por defecto se han establecido sobre la evaluación de condiciones, permitiendo a dicho usuario cierta libertad de parametrización de su interfaz en los casos que se crean necesarios y mientras dure la sesión del mismo Creación del api de Trew@ en la clase de integración Como se describe en diversos apartados de este mismo documento, el mecanismo de integración entre la Plataforma y los Procedimientos se lleva a cabo mediante la disponibilidad en estos últimos de un EJB, que permite a la Plataforma ejecutar métodos remotos integrados en el despliegue de dicho procedimiento, normalmente para obtener los datos necesarios particulares a éste en cada caso, ya sea para ejecutar lógica de elementos de definición (condiciones, acciones, variables, tareas en forma de formularios, etc.) o para la obtención y posterior invocación de funcionalidades particulares al procedimiento (operaciones en bloque, estadísticas, etc.). [ v01r20 ] 03/04/2014 Pág 61 de 67

62 La ejecución de cada método del EJB, realiza una llamada al método getapiui de la implementación concreta que exista de la clase de integración (más detalles en el apartado Interfaz de Integración ), para obtener una instancia del api de que posteriormente es enviada como parámetro a los demás métodos de dicha clase de integración del procedimiento. Normalmente se tiende a implementar este método haciendo Factory del api con cada llamada, teniendo que en procedimientos con un alto grado de integración se traduzca en multitud de llamadas al mismo. Hay que tener en cuenta que en la creación del api no sólo se están instanciando los objetos correspondientes sino que implican conexiones a base de datos y consultas a la misma para inicializar los atributos del api, operaciones que evidentemente tienen un determinado coste de ejecución y que en estos casos de muchas llamadas no parece práctico implementar la creación e inicialización de dicho api con cada llamada. En estos casos, aunque también de forma generalizada, para minimizar el tiempo de ejecución de las integraciones entre Plataforma y los Procedimientos, es recomendable implementar el método getapiui de la clase de integración de forma que mantenga la instancia del api de Trew@ sin hacer Factory con cada llamada, es decir, no creando una nueva instancia de este api por cada ejecución (TrAPIUIFactory.crearAPIUI), sino manteniéndose la instancia y sólo se haga la creación del api en la primera ejecución o cuando sea necesario porque no exista ya creada, de esta forma en ejecuciones secuenciales simplemente se devolvería el api ya instanciado (patrón Singleton) lo que supondría un ahorro sustancial en los costes de integración. Debe tenerse en cuenta además, que la implementación de este método getapiui debe estar coordinada con el método closeapiui a implementar también en la misma clase de integración de los procedimientos, y con mayor importancia, que con cada ejecución vía EJB se instancia una nueva clase de integración del procedimiento (se crea y destruye). Por tanto, la instancia del objeto TrAPIUI no debe mantenerse en esta clase de integración, deberá mantenerse en otra clase distinta de forma que el framework concreto (sobre el que se desarrolle el procedimiento) facilite obtenerla en distintas ejecuciones. A modo de ejemplo: [ v01r20 ] 03/04/2014 Pág 62 de 67

63 Como puede deducirse, mediante este mecanismo se pueden agilizar notablemente los procesos de integración, ya que la clase de integración del procedimiento no provoca la creación de conexión a base de datos de Trew@ e inicialización del api por cada ejecución de un elemento de integración (condición, acción, variable, etc.) Agilizar el cálculo de variables en documentos El proceso de sustitución de variables en documentos es otro de los puntos en los que se realizan invocaciones a los mecanismos de integración entre Plataforma y despliegue del procedimiento concreto. Este proceso consiste principalmente en la obtención del valor de cada variable asociada a un determinado documento, típicamente mediante la ejecución de métodos de clases java los cuales están representados en tiempo de definición por una variable concreta. Si bien el objetivo es el mismo que en el caso de las condiciones (reducir en la manera de lo posible los costes de integración), se detalla de forma separada en este apartado por su especial naturaleza y por su estrecha relación con los componentes que forman parte del motor de tramitación Trew@, que ya ofrece funcionalidades de uso recomendado independientemente del mecanismo de integración que se use para obtener el valor asociado a las variables, aunque de igual aplicación a los mecanismos de integración que por defecto se tienen en la Plataforma. Concretamente, para poder minimizar los costes de ejecución en el caso de variables, el motor de tramitación Trew@ permite devolver un mapa que [ v01r20 ] 03/04/2014 Pág 63 de 67

64 contenga el valor de varias variables a la vez, facilitando obtener un conjunto de valores con la invocación al código de una sóla variable. De esta forma no se ejecutan las llamadas a los métodos que representan el resto de variables de las que ya se dispone o han sido calculadas, disminuyendo por tanto las comunicaciones de integración. Para ello, simplemente la clase que implemente las variables del documento debe devolver un mapa (java.util.map) en vez de String, cuyo key será el nombre de cada variable y como value el dato calculado correspondiente a sustituir en el documento. Mediante este mecanismo, con la ejecución de una sóla variable se puede llegar a obtener el valor de todas las variables del documento, evitando que el motor invoque a los métodos del resto de variables pendientes de calcular. Previamente, será necesario detectar en qué momento de la construcción del código nos interesa utilizar este mecanismo y coordinarlo con la definición concreta de variables establecida para un documento. Se expone a continuación, a modo de ejemplo para entender mejor esta técnica, un escenario concreto en el que puede aplicarse. Supongamos que para un determinado documento disponible en un procedimiento se encuentran asociadas las siguientes variables: Variable Clase Método V_NOMBRE es.guadaltel.gonce.variables getnombre() V_APELLIDO1 es.guadaltel.gonce.variables getapellido1() V_APELLIDO2 es.guadaltel.gonce.variables getapellido2() [ v01r20 ] 03/04/2014 Pág 64 de 67

65 Normalmente, se tiende a desarrollar el código que representa a cada variable en métodos separados e independientes (agrupados bajo la misma clase, o no, según diseño), instanciándose la clase que ofrece el método con cada llamada e incluso donde la consulta a base de datos de los valores a obtener se realiza de forma aislada por cada método concreto. Por ejemplo: En este caso, es muy probable que los 3 valores se den en un mismo documento, o dicho de otra forma, se puede preveer que cuando alguna de estas variables exista en un documento, con mucha probabilidad existirán las otras 2. Además, en casos como el del ejemplo, los 3 valores se encontraran almacenados seguramente en la misma entidad de base de datos, con lo que parece más práctico obtener todos de una vez y no en consultas separadas. Por tanto, estamos ante un escenario en el que podemos aplicar la técnica descrita en este apartado, que además de minimizar las llamadas de integración nos van a permitir minimizar las consultas a base de datos. De esta forma y sin modificar la definición de variables para el documento en [ v01r20 ] 03/04/2014 Pág 65 de 67