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.
...
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
...
| Info |
|---|
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
...
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).
| Info |
|---|
Para más información acerca de los eventos, consulte la documentación de SGA. |
...
| Info |
|---|
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
...
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).
| Info |
|---|
Para más información acerca de los eventos, consulte la documentación de SGA. |
...
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.
...
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.
...
- 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)1: signatura de la solicitud que se va a subsanar.
- requestCode (opcional)1: 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.
| Info |
|---|
1Los 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:
| Code Block | ||||
|---|---|---|---|---|
| ||||
queryParams {numExpediente: "555",miCosa: "otroIdentificador"} |
...