A continuación vamos a ver ejemplos de implementación java de los casos de uso principales de la aplicación TTO. Para ubicarlos en el proceso general, vamos a mostrar de nuevo el esquema del inicio que muestra cómo integrarse con TTO.
TTO es una herramienta que necesita de la configuración de los procedimientos y formularios para poder mostrar a los ciudadanos la información y los campos necesarios para completar su trámite. De esta forma, TTO no tiene un desarrollo específico para cada formulario, si no que tiene una serie de campos, configuraciones, funcionalidades y validaciones que pueden usarse para definir cada formulario y procedimiento específico.
Tanto para mostrar la interfaz, como para almacenar la información de un trámite concreto, TTO necesita leer la configuración del procedimiento y un xml donde se encuentra definida la estructura del formulario de ese procedimiento. Igualmente, una aplicación integradora de TTO, necesita conocer esa misma estructura para poder recoger la información concreta de los trámites de los procedimientos que gestiona. La configuración del procedimiento (los plazos de presentación, su origen, los parámetros admitidos...) puede variar en el tiempo, sin ir vinculado a una versión del formulario, son independientes. La configuración va a definir el comportamiento, pero no la información mostrada ni almacenada.
Cuando se producen cambios en la definición de los formularios en el entorno de producción, se cambia la versión del formulario, por lo que este dato también es relevante para las integraciones, ya que no siempre los cambios realizados son compatibles con versiones anteriores. Esto no depende de TTO, puesto que no va vinculado a una evolución del desarrollo de la herramienta, si no de cómo se defina el formulario, según las necesidades de sus responsables.
Subsanaciones y Aportaciones
El caso de subsanaciones y aportaciones no es una excepción a lo expuesto anteriormente. Para TTO son un trámite más, no existe un desarrollo que los trate de forma particular, si bien se han abordado desarrollos para que TTO permitiese nuevas funcionalidades y campos adaptados a sus necesidades. Es el diseño del formulario y la configuración de los procedimientos que los respalda, lo que los hace particulares.
No obstante, por su relevancia de cara a la integración, se ha incluido este apartado recopilando la información necesaria para facilitar esta labor.
Lo primero necesario para integrarse con Subsanaciones y/o Aportaciones, es ser conocedor de la estructura de cada formulario en ese momento. Para ello, se pueden solicitar por medio de soportesae los xml que los definen en su última versión.
La forma de integrarse, sería, como en el resto de casos, haciendo uso de los eventos SGA. Esta integración sería la descrita en el apartado 3.2-Cómo integrarse con TTO. El servicio list debería quedar reservado para consultas puntuales o de respaldo, pero no como la forma principal y única de integración con TTO. Cuando se registra un trámite en TTO, se emite a través de esta plataforma un evento con los datos básicos de dicho trámite. En el caso concreto de subsanaciones y aportaciones, las aplicaciones integradoras deben consumir el evento finishedProcedureWithOrigin, que es el que permite recibir eventos cuando entran trámites que no son solicitudes.
Los datos de este evento finishedProcedureWithOrigin son:
- signature. Es la signatura del procedimiento que da respaldo al formulario en TTO y que, por tanto, nos indica la estructura de la información que va a tener el trámite finalizado.
- number y requestCode. Son identificadores únicos del trámite finalizado y han de usarse para recuperar la información de dicho trámite. En los servicios actuales se utiliza requestCode, pero se mantiene number por compatibilidad con versiones anteriores.
- origin. El origen del trámite, el cuál permite una primera discriminación sobre la tipología del trámite finalizado. Los posibles valores para el campo origin son: APORTACION, RECURSO, SOLICITUD, SUBSANACION
De esta forma, cuando una aplicación integradora recibe un evento de este tipo, puede discriminar con la signatura y el origen, si el trámite le resulta de interés o si necesita más información para saber si debe procesarlo. De ser así, debe llamar al siguiente servicio para recuperar los datos del trámite:
http://[entorno]/tto_core/rest/tramite/get?applicationId=APP&requestCode=XXXXXXXXX
O, si se desea una respuesta en XML:
http://[entorno]/tto_core/rest/tramite/getXml?applicationId=APP&requestCode=XXXXXXXXX
Entre los datos del trámite figuran los datos necesarios para poder decidir si la aplicación integradora debe procesar la solicitud: signatura de la solicitud sobre la que se realiza la subsanación o aportación (requestSignature), organismos de destino y registro, etc. Se detallan todos los datos de la respuesta en los apartados del servicio IRequestService (servicios get y getXml).
Para hacer uso del servicio rest list, para poder recuperar los trámites correspondientes a una subsanación o aportación mediante este servicio list, es necesario especificar el parámetro origin=SUBSANACION (APORTACION), o bien origin=TODOS, de la siguiente forma:
Dónde:
- applicationId. Es el identificador de la aplicación integradora
- signature. La signatura del procedimiento de subsanación/aportación
- summaryInfo. Este parámetro determina que se devuelva toda la información del tramite (incluido el formulario)
- origin. Origen del trámite. Sus posibles valores para el campo origin son: APORTACION, RECURSO, SOLICITUD, SUBSANACION y TODOS.
- requestSignature. Filtra aquellos trámites que estén subsanando o aportando sobre un procedimiento concreto
Con el servicio rest list y los servicios rest get/getXml se puede recuperar la misma información, no es necesario invocar a uno y luego al otro.
De cara a la integración, también es relevante la forma en la que se presentó la solicitud:
- Si las solicitudes del procedimiento sobre el que se desean capturar las subsanaciones y/o aportaciones se presentan (o han presentado) por medio de TTO, es relevante capturar el campo requestCodeAssociated del objeto RequestInformation, ya que este campo tendrá la clave de TTO (requestCode) de la solicitud sobre la se está realizando el trámite de subsanación y/o aportación. Siempre que el ciudadano haya rellenado ese campo. Dentro del formulario también vendrá el campo informado, pero se recomienda capturarlo del citado objeto RequestInformation, para no tener dependencia de las futuras versiones de los formularios. En estos casos, el ciudadano, al presentar la solicitud original por TTO, recibirá en el mail, junto con su pdf de solicitud, las URLs directas para subsanar y aportar directamente sobre su solicitud, facilitándole la labor de rellenar dicho campo, que ya le saldrá precargado en el formulario.
http://[entorno]/tramitar/[alias-tramite]/requestCode - Dónde "alias-tramite" será el correspondiente a subsanaciones o aportaciones. En los servicios digitales de la SEDE electrónica, podrán consultarse los alias actualizados para subsanaciones y aportaciones. - Si las solicitudes del procedimiento sobre el que se desean capturar las subsanaciones y/o aportaciones no se presentan por medio de TTO, desde la herramienta integradora (o de forma manual) se podría generar una URL particular para facilitarle a cada ciudadano y que, tras presentar su trámite de subsanación o aportación por TTO haciendo uso de dicha URL, desde la gestión se pueda identificar la solicitud original sobre la que se está subsanando o aportando. Para ello, será necesario hacer uso de la URL de subsanaciones o aportaciones, indicando:
- La signatura sobre la que se va a subsanar o aportar. Con este dato los documentos del trámite se metadatarán en esta signatura siempre que el procedimiento siga publicado. A su vez, este parámetro, permitirá a la aplicación discernir sobre las subsanaciones y aportaciones que corresponden a sus procedimientos.
- Los parámetros (clave=valor) necesarios para su posterior identificación en la gestión. TTO almacenará un nuevo bloque de datos en el json o xml del trámite concreto, queryParams, que contendrá los pares clave=valor con las que se haya iniciado un trámite. Existe un parámetro relevante, numExpediente, que en el caso de ser informado en la URL de inicio, se le mostrará al ciudadano junto al título del formulario. Este parámetro es el que se recomienda usar para identificar el expediente o solicitud del ciudadano.La forma de identificar expedientes puede ser propia de cada Servicio/sección, por lo que podría darse el caso de que en dos sitios distintos (de distintos procedimientos) utilizasen el mismo identificador para referenciar una solicitud, por lo que no sería suficiente, por si solo, para identificar si se debe procesar un trámite. Otros datos a tener en cuenta podrían ser el organismo de destino y registro, así como el interesado del trámite y de la subsanación.
http://[entorno]/tramitar/[alias-tramite]/requestSignature?numExpediente=XXXXXX - Dónde "alias-tramite" será el correspondiente a subsanaciones o aportaciones. En los servicios digitales de la SEDE electrónica, podrán consultarse los alias actualizados para subsanaciones y aportaciones.
A continuación se incluyen ejemplos que pueden clarificar esta información.
Ejemplo 1: recibir evento de un trámite TTO por medio de SGA
Para poder recibir eventos de trámites se deberán realizar los pasos descritos en el apartado 2.- Permisos y consideraciones previas para integración con TTO y suscribirse al evento finishedProcedure de SGA-Eventos.
El ciudadano habrá creado un trámite y TTO generará eventos para las aplicaciones integradoras. Para la recepción de los eventos a los que se haya suscrito la aplicación integradora, debe implementar un servicio rest, accesible por SGA, que implemente la interfaz NotificationManager
/** * Interfaz REST común para las aplicaciones que integren el sistema de eventos * */ public interface NotificationManager{ @PUT @Consumes(MediaType.APPLICATION_JSON) @Produces(MediaType.APPLICATION_JSON) Map<Long, Boolean> processNotification(RestEvent eventData); }
La aplicación obtendrá un objeto JSON como el siguiente:
{ number=10073; requestCode=100737Q9AYWCNQ9; signature=1774; }
Los datos que nos interesan son requestCode y signature. Con estos datos:
Comprobaremos si la signatura se corresponde con la de un trámite que sea de interés.
- En el caso de que la solicitud sea de interés, realizar una invocación al servicio get/getXml de TTO utilizando como parámetro de entrada requestCode. En el Ejemplo 3 se muestra cómo realizar esta invocación.
Una vez terminado todo el proceso, el servicio tiene que devolver a SGA un mapa donde la clave sea ese id único y el valor el resultado de procesar los datos asociados (true → procesado con éxito; false → se ha producido algún error).
Para más información acerca de los eventos, consulte la documentación de SGA.
Ejemplo 2: recibir evento de una subsanación o aportación de TTO por medio de SGA
Para poder recibir eventos de trámites se deberán realizar los pasos descritos en el apartado 2.- Permisos y consideraciones previas para integración con TTO y suscribirse al evento finishedProcedureWithOrigin de SGA-Eventos.
El ciudadano habrá realizado una subsanación o aportación y TTO generará eventos para las aplicaciones integradoras. Para la recepción de los eventos a los que se haya suscrito la aplicación integradora, debe implementar un servicio rest, accesible por SGA, que implemente la interfaz NotificationManager
/** * Interfaz REST común para las aplicaciones que integren el sistema de eventos * */ public interface NotificationManager{ @PUT @Consumes(MediaType.APPLICATION_JSON) @Produces(MediaType.APPLICATION_JSON) Map<Long, Boolean> processNotification(RestEvent eventData); }
La aplicación obtendrá un objeto JSON como el siguiente:
{ number=10073; requestCode=100737Q9AYWCNQ9; signature=1774; origin="SUBSANACION"; // Puede tomar los valores APORTACION, RECURSO, SUBSANACION y TODOS }
Los datos que nos interesan son requestCode, signature y origin. Con estos datos:
Comprobaremos si la signatura se corresponde con la de un trámite que sea de interés.
- En el caso de que la solicitud sea de interés o se necesiten más datos para determinarlo, realizar una invocación al servicio get/getXml de TTO utilizando como parámetro de entrada requestCode. En el Ejemplo 3 se muestra cómo realizar esta invocación.
Una vez terminado todo el proceso, el servicio tiene que devolver a SGA un mapa donde la clave sea ese id único y el valor el resultado de procesar los datos asociados (true → procesado con éxito; false → se ha producido algún error).
Para más información acerca de los eventos, consulte la documentación de SGA.
Ejemplo 3: construcción de la URL para subsanar con parámetros adicionales
Cuando se necesite asociar solicitudes existentes con nuevos trámites de tipo subsanación o aportación se utilizará la siguiente URL:
Los parámetros para poder construir la URL correctamente son los siguientes:
- entorno1: el entorno en el que se necesite asociar.
- alias-tramite: el tipo de trámite nuevo que se va a asociar. Los tipos de trámite existentes son "subsanaciones" y "aportaciones".
- requestSignature (opcional)2: signatura de la solicitud que se va a subsanar.
- requestCode (opcional)2: código de la solicitud que se va a subsanar.
- numExpediente (opcional): número de expediente de la solicitud a subsanar. Se indica en el caso en el que la solicitud a subsanar no haya sido tramitada por el tramitador.
- otros parámetros opcionales: otros parámetros adicionales personalizados que las aplicaciones integradoras deseen asociar a las solicitudes.
1Es necesario que siempre sea https ya que esta funcionalidad hace uso del almacenamiento del navegador.
2Los parámetros requestSignature y requestCode son excluyentes. Sólo se puede indicar uno de los dos parámetros.
Tanto el número de expediente como otros parámetros adicionales se guardaran en el bloque queryParams:
queryParams {numExpediente: "555",miCosa: "otroIdentificador"}
Ejemplos de invocación
Asociar una subsanación en el entorno de DES a la solicitud con signatura 1774 y número de expediente 5764 y un identificador personalizado "unIdentificador" 123456789:
Asociar una aportación en el entorno PRE a la solicitud con código 100737Q9AYWCNQ9 y número de expediente 5764 y un identificador personalizado "otroIdentificador" AAAAAAAA:
Asociar una aportación en el entorno PRO a la solicitud con número de expediente 5764 y un identificador personalizado "tercerIdentificador" BBBBBBB:
Ejemplo 4: consultar una solicitud, subsanación o aportación finalizada
Una vez recibido un SGA-Evento de TTO, comprobaremos si el trámite es de interés para la aplicación. En el caso de que la solicitud sea de interés, realizar una invocación al servicio get/getXml de TTO utilizando como parámetro de entrada requestCode.
Ejemplo 5: obtener la información de un listado de solicitudes de un día concreto
El servicio de consulta de un listado de solicitudes puede tener diversas aplicaciones puntuales.
El ejemplo de invocación que se muestra a continuación será de utilidad para consultar las solicitudes finalizadas en un día concreto. Así se podrá consultar si, por algún fallo técnico, la aplicación integradora no ha recibido alguna solicitud finalizada del trámite que nos interesa. Se va a tomar como ejemplo la signatura 1903 y el día 26/03/2020.
Ejemplo 6: obtener la información de un listado de subsanaciones de un día concreto
El servicio de consulta de un listado de solicitudes puede tener diversas aplicaciones puntuales.
El ejemplo de invocación que se muestra a continuación será de utilidad para consultar las subsanaciones finalizadas en un día concreto. Así se podrá consultar si, por algún fallo técnico, la aplicación integradora no ha recibido alguna subsanación finalizada del trámite que nos interesa. Se va a tomar como ejemplo la signatura 1903 y el día 26/01/2021.