Descripción detallada de Integración

Última modificación por Administrator el 2015/02/13 13:45

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 Trew@ 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 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 será INTERESADO o INT_NO_VIS en función si se desea o no visibilidad del expediente/solicitud desde la Oficina Virtual.
    • INTERESADO Interesado del expediente/solicitud visible en la OV. 
    • INT_NO_VIS Interesado del expediente/solicitud NO visible desde la OV.

Por otro, además, deben estar previamente configurados y establecidos los siguientes puntos:

  • 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 en @firma, 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 firma @firma 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.
  • 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 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:

  • 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".
  • Información adicional de la Ficha del Procedimiento e indicaciones de la Ficha, que detallaran un procedimiento concreto.
  • 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.
  • 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.

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.

Nota: Se distingue cualquiera de los 2 actos administrativos, no es obligatorio usar ambos. Están esos como mínimo porque un acto se corresponde con una fecha concreta, en términos Trew@ con una transición, por defecto está así 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, eso si se usan los actos claro, sino pues podrías poner a las 2 transiciones cualquiera de ellos. Es decir, sólo afecta si usas los actos y lo haces coherente con el modelado. Esto de distinguir cualquiera de los 2 actos es porque se ha dejado lo de por defecto, pero por configuración se podrían añadir los que se quisieran distinguir en caso de ampliarlos.

  • El documento a generar de la solicitud debe ser marcado como obligatorio para que la Oficina Virtual lo genere automáticamente.

dp.png

  • 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 usuario.
  • 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.
  • 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_DGDI_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.

  • Para las tareas concretas definidas en el procedimiento de tipo "generación de escritos" debe establecerse el modo de generación.
  • 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.
  • 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 "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 4.
  • 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.
  • 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
  • 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 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:

  • 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.
  • 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. 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#").
  • 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.

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  http://[servidor]:[puerto]/pfirmav2/external/external?sign=true&gotorequest=#HASHPET# 

  • Otras consideraciones a tener en cuanta para realizar el envío a Port@firmas es que tanto el usuario como el sistema (mismo código que el definido en Trew@) estén dados de alta en Port@firmas.
  • 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" (dónde @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 componente "@FIRMA" correctamente configurado.

Para aquellos documentos que se desee registrar, debe cumplirse:

  • 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).
  • 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.

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.

MPORTANTE: 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-1.0.0 para poder hacer uso de las nuevas funcionalidades de operaciones en bloque y gráficas específicas.

Las funcionalidades ofrecidas por esta 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) 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) throws Exception 
  • 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
  • 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).
  • 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

 

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 describió en los apartados iniciales de este documento.

 

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@:

num1.png

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.

num2.png

El nombre del componente debe coincidir con el definido en la constante, por ejemplo GONCE_RECORD_UTILITIES.

num3.png

Los datos del componente GONCE_RECORD_UTILITIES deben ser los siguientes:

AtributoDescripciónValor
JNDI_EJBNombre JNDI (Java Naming and Directory Interface ) con el que se ha desplegado el EJB.GonceRecordUtilities/GonceRecordUtilitiesBean/remote.
PERFILNombre del perfil con el que se creará la interfaz TrAPIUI (nombre del properties o Datasource).[Nombre del datasource]
PUERTOPuerto en el que se encuentra desplegado el EJB.1099
TIMEOUTTiempo máximo de espera en milisegundos para obtener el número correspondiente para el expediente dentro del procedimiento.2000

num4.png

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 (donde 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/0123456789.
  5. 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.

 

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.

num5.png

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.

num6.png

 

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:

  • no-evaluadas.png Las condiciones no han sido evaluadas, el usuario puede pulsar para que se evalúen en ese momento.
  • todas-evaluadas.png Las condiciones han sido evaluadas y todas las condiciones obligatorias se cumplen, se puede ejecutar.
  • alguna-evaluada.png Las condiciones han sido evaluadas y alguna condición obligatoria no se cumple, no se puede ejecutar.

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:

ConstanteDescripciónValores 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

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.

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 config-agenda.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:

EtiquetaDescripciónValor de ejemplo
<code>Código o identificador de la operación en bloqueOP_GEN_01
<textKey>Clave de la etiqueta en el fichero  etiquetas.propiedades o texto literal para mostrar de la operación en bloque.operacionesBloque.tramitar
<url>Dirección url de la operación en bloque.http://localhost:8080/opbloque-gonce/tramitar/tramitacionBloque.jsf
<key>Clave 3DES para el cifrado de los parámetros0x11,0x11,0x11,0x11,0x11,0x11,0x11,0x11,0x11,0x11,0x11,0x11,0x11,0x11,0x11,0x11,0x11,0x11,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.10000
<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.

num7.png

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:

AtributoDescripciónValor de ejemplo
idCódigo o identificador de la operación en bloqueOP_ESP_MAIL
descriptionDescripción para mostrar de la operación en bloque.Envío de mails en bloque
urlDirección url de la operación en bloque.http://localhost:8080/opbloque-gonce/email/envioEmailsBloque.jsf
keyClave 3DES para el cifrado de los parámetros0x11,0x11,0x11,0x11,0x11,0x11,0x11,0x11,0x11,0x11,0x11,0x11,0x11,0x11,0x11,0x11,0x11,0x11,0x11,0x11,0x11,0x11,0x11,0x11
lifetimeTiempo de vida en milisegundos para la validez del ticket con el que se cifran los parámetros.10000
accessTypeTipo 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.

num8.png

num9.png

num10.png

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:

num11.png

Clave de la propiedadValor de la propiedad
ID_STMAIdenficador del sistema establecido en la Agenda
COD_STMACódigo del sistema establecido en la Agenda
DESC_STMADescripción del sistema establecido en la Agenda
USUARIOCódigo del usuario autenticado en la Agenda.
NOMBRE_USUNombre del usuario autenticado en la Agenda.
APELLIDO1_USUPrimer apellido del usuario autenticado en la Agenda.
APELLIDO2_USUSegundo apellido del usuario autenticado en la Agenda.
IDENT_USUIdentificador (NIF) del usuario autenticado en la Agenda.
EXPEDIENTESLista de los identificadores de los expedientes seleccionados, separados por el carácter #.
ID_PROCEDIMIENTOIdentificador del procedimiento.
ABREV_PROCAbreviatura del procedimiento.
DESC_PROCDescripción del procedimiento.
COD_PTO_TRABAJOCódigo del puesto de trabajo seleccionado para el usuario autenticado en la Agenda.
NOMB_PTO_TRABAJONombre del puesto de trabajo seleccionado para el usuario autenticado en la Agenda.
DESC_PTO_TRABAJODescripción del puesto de trabajo seleccionado para el usuario autenticado en la Agenda.
ID_ORGANISMOIdentificador del organismo al que pertenece el puesto de trabajo seleccionado para el usuario autenticado en la Agenda.
COD_ORGANISMOCódigo del organismo al que pertenece el puesto de trabajo seleccionado para el usuario autenticado en la Agenda.
DESC_ORGANISMODescripción del organismo al que pertenece el puesto de trabajo seleccionado para el usuario autenticado en la Agenda.
FECHA_HORA_ACTUALFecha y hora actual en la que se invoca a la operación en bloque. Formato "dd/MM/yyyy HH:mm".
IDIOMAIdioma establecido en la Agenda.
<Propiedades del fichero agenda.properties>Conjunto de propiedades de configuración recogidas en el fichero agenda.properties.

 

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:

EtiquetaDescripciónValor 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 interfazcom.gtel.integracion.graficas.GraficaAgenda para devolver los datos con los que se construye la gráfica.com.gtel.agenda.graficas.GraficaGenericaExpedientes
<accessType>Tipo de apertura para la gráfica / estadística. 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.

num12.png

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:

AtributoDescripciónValor de ejemplo
idCódigo o identificador de la gráfica.GR_ESP_01
descriptionDescripción de la gráfica a mostrar en la Agenda.Estadística específica del procedimiento
accessTypeTipo de apertura para la gráfica / estadística. Los valores permitidos son ¿iframe¿ (capa dentro de la Agenda) o ¿popup¿ (ventana nueva).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 Descripción
EJB_xxx 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 "gonce.ear" deberá ser /gonce/GonceEnvironmentIntegrationEJB/remote.
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.
OP_BLOCK_xxx Indica el nombre de la clase que implementa el 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.
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 por defecto 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 INVOKER_PROC01.

 

¿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.
  • Á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 menú 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 (AGRICULTURA Y GANADERÍA)
  • CULTURA 
  • ECONOMIA (ECONOMÍA Y COMERCIO)
  • EDUCACION 
  • IDI (I+D+I)
  • IMPUESTOS 
  • INDUSTRIA (G·ONCE)
  • INFRAESTRUCTURA (INFRAESTRUCTURAS Y TRANSPORTE)
  • JUSTICIA 
  • JUVENTUD 
  • NATURALEZA (NATURALEZA Y MEDIO AMBIENTE)
  • OCIO (OCIO-DEPORTES)
  • PESCA 
  • SALUD (SALUD Y BIENESTAR)
  • TRABAJO (TRABAJO-EMPLEO)
  • TURISMO

 

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 sí, 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 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').

 

Accesos a la Oficina Virtual.

La oficina virtual, permite el acceso directo a ciertas pantallas, mediante la inclusión parámetros en la url: http://.../oficina/tramites/acceso.do//////////////

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:

http://.../oficina/tramites/acceso.do?id=731&proc=GONCE2
Mediante esta URL accederemos a la ficha del procedimiento cuyo identificador sea el 731 y su abreviatura GONCE2.

http://.../oficina/tramites/acceso.do?id=731&proc=GONCE2#plantillas
Mediante esta URL accederemos a la sección de descargas, en la ficha del procedimiento cuyo identificador sea el 731 y su abreviatura GONCE2.

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:

  • 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.

Ejemplo:
http://.../oficina/tramites/acceso.do?id=731&alta=certificado
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:

  • 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.

Ejemplo:
http://.../oficina/tramites/acceso.do?id=731&descarga=true
Mediante esta URL descargaremos los documentos asociados al procedimiento cuyo identificador sea el 731.

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:

  • 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.

 

Configuración de la 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.

 

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
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);
© 2014 GOBIERNO DE CANTABRIA - AVISO LEGAL Y PROTECCIÓN DE DATOS