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.

Image Removed

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.

Image Added

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:

https://[entorno]/tto_core/rest/tramite/list?applicationId=XXX&signature=000&creationStartDate=dd/mm/yyyy&summaryInfo=false&origin=SUBSANACION&requestSignature=XYZ

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.

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

...

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

...

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

...

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

...

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

...

• entorno: 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)¹: signatura de la solicitud que se va a subsanar.
• requestCode (opcional)¹: 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.

Tanto el número de expediente como otros parámetros adicionales se guardaran en el bloque queryParams:

queryParams {numExpediente: "555",miCosa: "otroIdentificador"}

...

Asociar una subsanación en el entorno de DES a la solicitud con signatura 1774 y número de expediente 500027674637846764 5764 y un identificador personalizado "unIdentificador" 123456789:

Ejemplo 4: consultar una solicitud, subsanación o aportación finalizada

...