...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

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

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.

...

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.
• requestSignature: En los casos en los que un tramite pueda ser multiprocedimiento, este campo determinará el procedimiento efectivo del tramite a efectos de metadatado y registro.
• 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

/**
 * 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);
}

{
  number=10073;
  requestCode=100737Q9AYWCNQ9;
  signature=1774;
  requestSignature=1818;
}

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

Ejemplo 2: recibir evento de una subsanación o aportación de TTO por medio de SGA

...

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);
}

{
  number=10073;
  requestCode=100737Q9AYWCNQ9;
  signature=1774;
  requestSignature=1818;
  origin="SUBSANACION"; // Puede tomar los valores APORTACION, RECURSO, SUBSANACION y TODOS
}

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

Ejemplo 3: recibir evento de registro de un trámite de TTO por medio de SGA

...

El ciudadano habrá creado registrado un trámite y TTO generará eventos para las aplicaciones integradoras.  Para la la recepción de los eventos a  a los que se haya suscrito haya suscrito la aplicación integradora, debe implementar un servicio rest, accesible por SGA, que implemente la interfaz 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:

{
  csvRegisterReceipt=CSVMD3O30L6DG1X00SRT;
  csvRequest=CSV5745Q0P5D01X01TTO;
  number=10073;
  requestCode=100737Q9AYWCNQ9;
  signature=1774;=31904;
  registerId=RT_000009292/2022;
  requestCode=31904AXZS1MXKFF;
  requestSignature=1903;
  signature=1903
}

Los datos que nos interesan

...

Comprobaremos si la signatura se corresponde con la de un trámite que sea de interés.

...

son csvRegisterReceipt, csvRequest 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 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.
• Este evento se emite para todos los trámites una vez completado el registro y de forma previa a su envío a BENT, por eso en este evento no recibimos el identificador de BENT.
• Con desarrollos futuros previstos en la aplicación, hay que tener en cuenta que ciertos datos de este evento pueden venir vacíos, en concreto csvRequest y csvRegisterReceipt, es decir, el CSV de la solicitud y del justificante de registro.

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

Se recomienda el uso de este nuevo evento para obtener la información de los trámites registrados ya que es independiente del origen del trámite y se recibe más información que en finishedProcedure o finishedProcedureWithOrigin. 

Para más información acerca de los eventos, consulte la documentación de SGA.

Ejemplo

...

4: recibir evento

...

de recibo de información adicional de un trámite de TTO por medio de SGA

...

El ciudadano habrá realizado una subsanación o aportación registrado un trámite y TTO generará eventos para las aplicaciones integradoras.  Para la la recepción de los eventos a  a los que se haya suscrito haya suscrito la aplicación integradora, debe implementar un servicio rest, accesible por SGA, que implemente la interfaz NotificationManagerun servicio rest, accesible por SGA, que implemente la interfaz NotificationManager.

Este evento addInfoProcedure complementa al descrito en el punto anterior ya que envía toda la información de un trámite completo, es decir una vez se haya finalizado su registro y su envío a BENT. De esta manera nos informará de datos que no nos han llegado en el evento anterior registerProcedure .

/**
 * 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
  bentId=44640;
  csvRegisterReceipt=CSVYE7XAJO2CE1900SRT;
  csvRequest=CSV1C5BIDD4CK1X01TTO;
  number=31908;
  registerId=RT_000009293/2022;
  requestCode=31908HXDMDTK7H8;
  originrequestSignature="SUBSANACION"1903;
// Puede tomar los valores APORTACION, RECURSO, SUBSANACION y TODOS
}

...

Comprobaremos si la signatura se corresponde con la de un trámite que sea de interés.

...

signature=1903
}

Los datos que nos interesan son bentId, csvRegisterReceipt, csvRequest 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 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.
• Este evento se emite para todos trámites registrados cuando actualicemos alguna de su información, en concreto el idBent ya que el anterior evento registerProcedure se emite de manera previa a su generación. Con desarrollos futuros previstos en la aplicación, hay que tener en cuenta que los datos que se actualicen en este evento pueden ser otros y no únicamente el identificador de BENT.

• Este evento addInfoProcedure se lanza siempre después del explicado en el punto anterior registerProcedure, ya que amplía los datos enviados por este primero. Podría darse la situación en el que ocurrieran errores en la aplicación SGA y estos eventos llegaran en una secuencia distitna.

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

...

Se recomienda el uso de este nuevo evento para obtener la información completa de los trámites ya que es independiente del origen del trámite y se recibe más información que en finishedProcedure o finishedProcedureWithOrigin. 

Para más información acerca de los eventos, consulte la documentación de SGA.

Ejemplo

...

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

...

• 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"}

...

Ejemplo

...

6: 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.

...

// PASO 1: Establecer los parámetros de búsqueda
// Id de la aplicación que está accediendo a TTO
String APPLICATION_ID = "XXX";
// identificador de la solicitud
String requestCode = "100737Q9AYWCNQ9";
 
// PASO 2: Establecer la conexión
URL url = new URL("https://aplicaciones.aragon.es/tto_core/rest/tramite/get?" +
"applicationId=" + APPLICATION_ID +
"&requestCode =" + requestCode);
HttpURLConnection connection = (HttpURLConnection) url.openConnection();
connection.setRequestMethod("GET");
connection.setRequestProperty("Accept", "application/json");
 
// Gestionar respuesta incorrecta
if (connection.getResponseCode() != 202) {
    System.out.println("Respuesta incorrecta");
}
 
// PASO 3: Convertir la respuesta del servicio en el objeto del trámite
TransformXMLToObject transformer = new TransformXMLToObject();
ResultTramiteBean tramite = transformer.parseTramiteBeanFromFile(
            connection.getInputStream());
 
// PASO 4: Desconectar
connection.disconnect();

Ejemplo

...

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

...

// PASO 1: Establecer los parámetros de búsqueda
// Id de la aplicación que está accediendo a TTO
String APPLICATION_ID = "XXX";
  
// Signaturas de los procedimientos a consultar
int signature = 1903;
// Se consultan las solicitudes registradas
boolean isRegistered = true;
// Se consultan únicamente la información básica de las solicitudes, no el formulario
boolean isSummaryInfo = true;
// Fecha inicio de registro de la solicitud
String registerStartDate = "26/01/2021";
// Fecha fin de registro de la solicitud
String registerEndDate = "26/01/2021";
 
  
// PASO 2: Preparar la conexión
URL url = new URL("https://aplicaciones.aragon.es/tto_core/rest/tramite/list?" +
        "applicationId=" + APPLICATION_ID +
        "&signature=" + signature +
        "&registered=" + isRegistered +
        "&summaryInfo=" + isSummaryInfo +
        "&registerStartDate =" + registerStartDate +
        "&registerEndDate =" + registerEndDate );
 
HttpURLConnection connection = (HttpURLConnection) url.openConnection();
connection.setRequestMethod("GET");
connection.setRequestProperty("Accept", "application/json");
  
if (connection.getResponseCode() != 202) {
    System.out.println("Respuesta incorrecta");
}
    
// PASO 3. Recuperamos la respuesta del servicio en formato String
StringBuilder responseStrBuilder = new StringBuilder();
BufferedReader streamReader = new BufferedReader(
        new InputStreamReader(connection.getInputStream(), "UTF-8"));
String inputStr;
while ((inputStr = streamReader.readLine()) != null) {
  responseStrBuilder.append(inputStr);
}
  
// PASO 4. Configurar GSON para recuperar las fechas desde formato UNIX
GsonBuilder builder = new GsonBuilder();
builder.registerTypeAdapter(Date.class, (JsonDeserializer<Date>) (json, typeOfT, context) ->
        new Date(json.getAsJsonPrimitive().getAsLong()));
Gson gson = builder.create();
  
// PASO 5. Convertir la respuesta al objeto del trámite
JsonArray json = gson.fromJson(responseStrBuilder.toString(), JsonArray.class);
ResultTramiteBean tramite = gson.fromJson(responseStrBuilder.toString(),
        ResultTramiteBean.class);
ResultTramiteBean tramiteList[] = gson.fromJson(json, ResultTramiteBean[].class);
  
// PASO 6. Desconectar
connection.disconnect();

Ejemplo

...

8: 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.

...