Table of Contents |
---|
...
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.
...
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 anterioresde 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
...
Code Block | ||||
---|---|---|---|---|
| ||||
{
number=10073;
requestCode=100737Q9AYWCNQ9;
signature=1774;
requestSignature=1818;
} |
Los datos que nos interesan son requestCode, y signature y requestSignature. 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).
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
...
Code Block | ||||
---|---|---|---|---|
| ||||
{
number=10073;
requestCode=100737Q9AYWCNQ9;
signature=1774;
requestSignature=1818;
origin="SUBSANACION"; // Puede tomar los valores APORTACION, RECURSO, SUBSANACION y TODOS
} |
...
Los datos que nos interesan son requestCode, signature, requestSignature 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).
Info |
---|
Para más información acerca de los eventos, consulte la documentación de SGA. |
...
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)21: signatura de la solicitud que se va a subsanar.
- requestCode (opcional)21: 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 |
---|
1 Es 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:
Code Block | ||||
---|---|---|---|---|
| ||||
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 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:
...