SGNTJ - LexNET
SUBDIRECCIÓN GENERAL DE LAS NUEVAS TECNOLOG�AS DE LA JUSTICIA
|
|
SGNTJ - LexNET |
DIRECCIÓN GENERAL DE RELACIONES CON LA ADMINISTRACIÓN DE JUSTICIA
SUBDIRECCIÓN GENERAL DE LAS NUEVAS TECNOLOG�AS DE LA JUSTICIA |
SGNTJ
|
LexNET
|
Guía de uso de los Web Services de integración (entidades): ws LexNET 3.18
|
Público
| ELABORADO POR: Desarrollo LexNET |
REVISADO POR: Desarrollo LexNET |
APROBADO POR: SGNTJ |
| Fecha: |
Fecha: |
Fecha: |
| |
|
| AUTOR: |
|
| RESPONSABLE: |
Jose Francisco Merli |
| PROYECTO: |
LexNET |
| LUGAR DE REALIZACIÓN: |
|
| NOMBRE DEL DOCUMENTO: |
Web services de integración (entidades) |
| CÓDIGO: |
|
| Palabras Clave del documento: |
LexNET, integradores web service, entidades |
Versión
|
Fecha
|
Descripción del cambio
|
1.0
|
24/10/2016
|
Se crea una versión de documentación reducida para la entrega correspondiente a la versión 4.7. Se modifica el campo expediente para envío de iniciadores y atestados. Se elimina el SW ObtenerHistoricoMensajeGeneral y el SW ObtenerTiposProcedimientoGeneral. Se marca a obligatorio el campo expedienteNumero para partes hospitalarios. |
ÍNDICE
ÍNDICE
4
1. INTRODUCCIÓN
6
2. ARQUITECTURA PARA INVOCACIÓN A LOS SERVICIOS WEB DE LEXNET
8
3. EJEMPLOS DE USO E INVOCACIÓN A LOS SERVICIOS WEB LEXNET
8
3.1. Autenticación en LexNET
8
3.2. Envío de mensajes
9
3.3. Descarga de mensajes
11
4. DESCRIPCIÓN DE LOS SERVICIOS WEB LEXNET
14
4.1. De uso general
16
4.1.1. Respuesta de error
16
4.1.2. LoginServiciosGeneral
17
4.1.3. LogOut
19
4.1.4. ObtenerDestinatariosGeneral
21
4.1.5. ObtenerOrigenes
25
4.1.6. ObtenerCatalogoGeneral
28
4.1.7. ObtenerPendientesGeneral
33
4.1.8. ObtenerCabecerasGeneral
35
4.1.9. ObtenerMensajeGeneral
45
4.1.10. ObtenerBloque
63
4.1.11. TerminarDescarga
65
4.1.12. DescargarMensaje
67
4.1.13. EnviarEscritoGeneral
70
4.1.14. EnviarIniciadoresGeneral
83
4.1.15. EnviarEjecucionesGeneral
110
4.1.16. EnviarPersonacionesGeneral
122
4.1.17. EnviarRecursoQuejaGeneral
132
4.1.18. EnviarRecursoCasacionGeneral
143
4.1.19. EnviarBloqueGeneral
155
4.1.20. EnviarVerificacionLecturaGeneral
159
4.1.21. ObtenerAvisosGeneral
163
4.1.22. ObtenerAceptadosRechazadosGeneral
165
4.1.23.
Impr
imirMensajeGeneral
169
4.2. De uso por Colegios Profesionales
172
4.2.1. GestionProfesionales
172
4.2.2. ObtenerPendientesColegiadosGeneral
180
5
GLOSARIO
183
1. INTRODUCCIÓN
El objeto de este documento es describir las interfaces de Servicios Web dirigidas a entidades de la plataforma LexNET para que los desarrolladores de aplicaciones puedan integrar y utilizar los servicios ofrecidos por la misma.
En específico, este documento cubre la versión LexNET 3.18 de los Servicios Web, a la vez que sigue proporcionando soporte a las versiones anteriores 3.17, 3.16, 3.15, 3.14, 3.13 y 3.12.
Durante la fase de desarrollo, los integradores invocarán los servicios web del entorno de integración de LexNET ( https://lexnet3pruebas.justicia.es ) cuya definición WSDL pueden encontrar en https://lexnet3pruebas.justicia.es/services/ NombreServicioWeb?wsdl . (Ej: El WSDL del servicio web de Logout puede descargarse desde https://LexNET3pruebas.justicia.es/services/Logout?wsdl )
A partir de esta versión de servicios web y para poder disponer de los parámetros de entrada/salida que se incorporan en esta versión, la invocación debe realizarse de la siguiente manera:
xmlns= https://wslexnet.webservices.lexnet/ 3.XX (En el caso de esta versión xmlns=”https://wslexnet.webservices.lexnet/3.18 ”)
El cambio de invocación respecto a versiones anteriores de los servicios web se ha realizado para posibilitar introducir nuevos parámetros de entrada/salida en nuevas versiones de los servicios web sin impactar en integradores que ya estuvieran utilizando versiones anteriores de los servicios.
Una vez desarrolladas las aplicaciones y antes de su pase a producción, estas aplicaciones habrán tenido que pasar previamente un proceso de homologación de su aplicación en el que se comprobará el funcionamiento adecuado del cliente desarrollado conforme a los requisitos del RD 84/2007 regulador del sistema LexNET. Una vez pasado el proceso de homologación, La Subdirección General de Nuevas Tecnologías de la Justicia asignará un identificador único e intransferible a la aplicación lo que permitirá su intercomunicación con LexNET por servicios web.
Este documento cubre los siguientes aspectos:· Descripción de los distintos tipos de servicios web contemplados en este documento y la arquitectura necesaria para su invocación
· Descripción de la interfaz de Servicios web de la plataforma LexNET mediante la especificación de mensajes XML-SOAP de solicitud y respuesta. (Ejemplos de petición/respuesta en adjunto)
· Descripción de ejemplos uso e invocación de los servicios web LexNET para la realización de los procesos principales aportados por el sistema LexNET: envío y descarga de mensajes.
La plataforma LexNET publicará los siguientes Web Services de integración con LexNET:· De uso general
· De uso por parte de aplicaciones de Colegios Profesionales
Todos los servicios web publicados constan de una sola operación. Todas las operaciones reciben como único parámetro de entrada un String con formato XML. Cada servicio publicado dispone de un formato de XML específico que viene definido por el XML Schema de los mensajes a los Web Services. En este Schema se definen todos los mensajes de todos los web services, tanto los de petición, como los de respuesta, incluida la respuesta en caso de error (En el Anexo I se especifican los códigos de error que devuelven los servicios web, así como su descripción).
2. ARQUITECTURA PARA INVOCACIÓN A LOS SERVICIOS WEB DE LEXNET
LexNET posibilita la interconexión e invocación con los servicios web desde una arquitectura de conexión con certificado de servidor
La invocación a LexNET desde una aplicación de una entidad, se realizará abriendo en primer lugar un túnel seguro SSL utilizando el certificado de servidor de la aplicación. A continuación, LexNET permite iniciar la invocación a sus servicios web, de acuerdo con las funcionalidades requeridas.
Figura 1 Arquitectura de interconexión cliente-LexNET
3. EJEMPLOS DE USO E INVOCACIÓN A LOS SERVICIOS WEB LEXNET
El uso de los principales servicios web de LexNET requiere la invocación de los mismos en un orden determinado. A continuación se detalla el proceso de invocación para algunos de los procesos más importantes aportados por LexNET, utilizando una arquitectura de invocación desde servidor, habiéndose establecido previamente una conexión SSL con LexNET con el certificado de servidor de dicha aplicación.
Nota: La descripción detallada de uso e invocación de todos los servicios web ofrecidos por LexNET se encuentra en el apartado 1
3.1. AUTENTICACIóN EN LEXNET
La autenticación en LexNET, utilizando una arquitectura de interconexión con certificado de servidor desde la aplicación de una entidad, habiéndose establecido previamente SSL con el certificado de servidor, implica los siguientes pasos:
· Invocación a LoginServiciosGeneral: la aplicación cliente iniciará la solicitud de login, enviando su identificador de aplicación y la firma de un token aleatorio con su certificado de aplicación. LexNET, enviará como respuesta un identificador de sesión
· Invocación a los servicios web de LexNET: la aplicación cliente invocará a los distintos servicios web ofrecidos por LexNET.
· Invocación a Logout: la aplicación cliente enviará a LexNET la solicitud de desconexión
Figura 2 Conexión con certificado de servidor
3.2. ENVíO DE MENSAJES
El envío de mensajes a través de LexNET, utilizando una arquitectura de interconexión con certificado de servidor, implica los siguientes pasos:
· Invocación a EnviarMensajeGeneral: la aplicación cliente solicitará el envío de un mensaje. LexNET devolverá la plantilla de mensaje de envío (SMIME o CADES). La aplicación cliente deberá generar el mensaje de envío, firmados los documentos por el usuario.
· Invocación a EnviarBloqueGeneral: la aplicación cliente enviará a LexNET el mensaje, dividido en bloques, a través de invocaciones sucesivas a EnviarBloqueGeneral.
Figura 3 Envío de mensajes
Figura 4 Composición de mensajes en origen previo a envío
3.3. DESCARGA DE MENSAJES
La descarga de mensajes desde LexNET (ej.: descarga de escritos, notificaciones, etc), utilizando una arquitectura de interconexión con certificado de servidor, implica los siguientes pasos:
· Invocación a ObtenerPendientesGeneral: la aplicación cliente, solicitará conocer el nº de mensajes recibidos nuevos que todavía no se hubiera descargado
· Invocación a ObtenerCabecerasGeneral: la aplicación cliente, solicitará la cabecera de los mensajes recibidos
· Invocación a EnviarVerificacionLecturaGeneral (en caso de entidades que requieran firma de recibí; ej.: Colegios de Abogados, Abogacías del Estado, etc.): la aplicación cliente solicitará el envío de un recibí. LexNET devolverá la plantilla de mensaje de envío. La aplicación cliente deberá generar el mensaje de envío (recibí), firmado por el usuario.
· Invocación a EnviarBloqueGeneral: la aplicación cliente enviará a LexNET el recibí, dividido en bloques, a través de invocaciones sucesivas a EnviarBloqueGeneral.
· Invocación a ObtenerMensajeGeneral: la aplicación cliente solicitará la descarga del mensaje
· Invocación a ObtenerBloque: la aplicación cliente solicitará la descarga en bloques de los documentos principal y adjuntos del mensaje. Los identificadores de dichos documentos fueron obtenidos en el paso anterior. Para ello, se realizará sucesivas llamadas al servicio web ObtenerBloque.
· Invocación a TerminarDescarga: una vez descargados todos los bloques del documento principal y de todos los adjuntos, la aplicación cliente realizará una solicitud al servicio web TerminarDescarga, para indicarle a LexNET la finalización del proceso de descarga del mensaje completo.
Figura 5 Descarga de Mensajes
Figura 6 Descarga de mensajes. Descarga de adjuntos.
4.
5. DESCRIPCIÓN DE LOS SERVICIOS WEB LEXNET
En este apartado se detallan los servicios Web de LexNET incluyendo su descripción y parámetros de entrada y salida. Para facilitar la integración de las aplicaciones clientes, cada una de las operaciones que se pueden realizar en LexNET a través de servicios web, se han definido como un servicio web independiente, cada uno con una sola operación. Como se verá más adelante en la definición WSDL de los servicios web, cada uno de ellos (con su única operación) aceptan como parámetro de entrada un String, el cual representa un mensaje formateado en XML a través del cual se envían los datos necesarios para realizar la operación que representa. Asimismo, el mensaje de respuesta que envía el servidor LexNET será también un String formateado en XML con los datos específicos de la operación realizada o, en caso de que ocurra algún error, los datos del mismo. Como la respuesta de error es común para todos los servicios, se indica el formato de dicha respuesta de error en el apartado 4.1.1.
5.1. DE USO GENERAL
A continuación se muestran el conjunto de servicios web de uso general
5.2. RESPUESTA DE ERROR
5.3. DESCRIPCIóN
Se dedica este apartado al mensaje de respuesta de error ya que es único para todos los servicios. Además, como se podrá apreciar en las definiciones WSDL, ninguno de los servicios web define un mensaje “default” en sus operaciones, esto es debido a que en caso de error se utiliza el mismo mensaje de salida. Es por esto que las aplicaciones clientes, al recibir una respuesta de cualquiera de los servicios web, deberán preguntar si el mensaje es de error o de respuesta real a la operación invocada.
El mensaje de error incluye información sobre el momento en que ocurre el error, códigos definidos (para más información sobre los códigos de error consulte el apartado 5.1), un mensaje explicativo y el módulo en el que ocurre.
En el ejemplo que se muestra a continuación se ha escenificado el siguiente error: se solicita la operación ObtenerMensaje por parte de un usuario que requiere el envío de una verificación de lectura previo a la petición de este servicio web. El servicio ObtenerMensaje devolvería un mensaje de error, causado por el hecho de que el usuario necesitaba enviar una verificación de lectura antes de descargar el mensaje.
5.4. MENSAJE SOAP DE RESPUESTA
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/ " xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/ " xmlns:xsd="http://www.w3.org/2001/XMLSchema " xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance ">
<soapenv:Header/>
<soapenv:Body>
<p703:ObtenerMensajeOut xmlns:p703="https://obtenermensaje.servicio.wslexnet.webservices.lexnet.satec.es ">
<![CDATA[
<?xml version="1.0" encoding="ISO-8859-1"?>
<mensajeWS xmlns="https://wslexnet.webservices.lexnet ">
<respuestaError xmlns="">
<tiempo>[fechaError]</tiempo>
<codigo>[codigoError]</codigo>
<texto>[texto]</texto>
<actor>[actor]</actor>
<detalle>[detalle]</detalle>
<token>[token]</token>
</respuestaError>
</mensajeWS>
]]>
</p703:ObtenerMensajeOut>
</soapenv:Body>
</soapenv:Envelope>
Los elementos principales se describen a continuación:
5.5. LOGINSERVICIOSGENERAL
5.6. DESCRIPCIóN
Esta funcionalidad permite a un usuario de una aplicación externa o directamente a una aplicación externa (que llamaremos aplicación cliente) conectarse con LexNET.
La implementación de este servicio web comprobará en LexNET la información del certificado utilizado por la aplicación cliente, si éste existe y si es válido.
El servicio devolverá a la aplicación cliente el identificador de sesión generado en el proceso de autenticación.
5.7. RUTA WSDL
Ruta WSDL (entorno de Pruebas): https://lexnet3pruebas.justicia.es/services/LoginServiciosGeneral?wsdl
5.8. MENSAJE SOAP DE PETICIóN
LoginServiciosGeneral_peticion.xml
Los elementos principales se describen a continuación:
5.9. VALIDACIONES
Estas son las validaciones que se aplican al servicio web:· idAplicacion: se comprueba que el identificador de la aplicación está admitido en el entorno actual.
· Certificado: se comprueba que el certificado de la conexión SSL que se usa para identificar a la aplicación es correcto.
· Firma de usuario: se comprueba que la firma del usuario/servidor introducida es correcta.
· Certificado de la firma: se comprueba que el certificado de aplicación obtenido de la firma del token es correcto y válido.
· Aplicacion: se comprueba que el certificado corresponde a una aplicación valida en LexNET y está activada.
5.10. MENSAJE SOAP DE RESPUESTA
LoginServiciosGeneral_respuesta.xml
Los elementos principales se describen a continuación:
5.11. LOGOUT
5.12. DESCRIPCIóN
Este servicio permite a una aplicación cliente de los servicios web LexNET solicitar la desconexión del sistema. En el lado del servidor LexNET se libera toda la información no permanente de la sesión, impidiendo futuras operaciones con esta sesión.
5.13. RUTA WSDL
Ruta WSDL (entorno de Pruebas):
https://lexnet3pruebas.justicia.es/services/Logout?wsdl
5.14. MENSAJE SOAP DE PETICIóN
LogOut_peticion.xml
Los elementos principales se describen a continuación:
5.15. VALIDACIONES
Este servicio web no realiza ninguna comprobación.
5.16. MENSAJE SOAP DE RESPUESTA
LogOut_respuesta.xml
Los elementos principales se describen a continuación:
5.17. OBTENERDESTINATARIOSGENERAL
5.18. DESCRIPCIóN
Este servicio permite al usuario cliente o a una aplicación cliente obtener la lista de los destinatarios válidos para poder enviar mensajes en función del usuario que ha hecho Login o el usuario introducido en el apartado remitente y de los parámetros de filtrado que se le pasen al servicio (entidad destino, rol, nif, etc).
Nota: En el filtrado se aplica una función AND para realizar la búsqueda.
En una aplicación cliente que cuente con una base de datos interna (Ver Anexo III), se aconseja realizar esta operación de obtener los posibles destinatarios dentro de los procesos de configuración e inicialización de la aplicación para obtener todos los destinatarios válidos y almacenar su resultado, ya que la información devuelta por esta operación no cambia frecuentemente. Si al solicitar el envío de un mensaje, el servidor devuelve un error de destinatario no válido, se podría volver a lanzar esta operación para actualizar la información de los destinatarios y así solucionar el error. No es aconsejable invocarla cada vez que se realiza un envío para no saturar el servidor.
5.19. RUTA WSDL
Ruta WSDL (entorno de Pruebas): https://lexnet3pruebas.justicia.es/services/ObtenerDestinatariosGeneral?wsdl
5.20. MENSAJE SOAP DE PETICIóN
ObtenerDestinatariosGeneral_peticion.xml
Los elementos principales se describen a continuación:
Nota.- Si los campos optativos comunidad, provincia y partido judicial son nulos, se tomarán como filtros de búsqueda la comunidad y provincia de la entidad logada.
5.21. VALIDACIONES
Estas son las validaciones que se aplican al servicio web:· idAplicacion: se comprueba que el identificador de la aplicación está admitiendo en el entorno actual.
· idSujetoEntidad: se comprueba que el identificador de la entidad sea correcta y pertenezca a la aplicación.
· idSesion: se comprueba que el identificador de sesión es correcto ya que el usuario previamente lo ha debido introducir con anterioridad. La sesión tiene una caducidad máxima de 30 minutos.
5.22. MENSAJE SOAP DE RESPUESTA
ObtenerDestinatariosGeneral_respuesta.xml
Los elementos principales se describen a continuación:
Nota: En versiones anteriores de este servicio web se devolvía el parámetro certificado dentro del parámetro profesional. En ese parámetro, se incluía la parte pública del certificado de profesional codificada en base64, pero se ha eliminado en esta versión para mejorar el rendimiento del servicio.
5.23. OBTENERORIGENES
5.24. DESCRIPCIóN
Este servicio permite a una aplicación cliente obtener la lista de los orígenes válidos 1 que tiene almacenada la base de datos LexNET para ese servidor cliente que realiza la petición. Se utiliza para que un servidor cliente pueda conocer las entidades dependientes de él y para las cuales, puede interactuar con LexNET como intermediario. Estas entidades se habrán dado de alta previamente en la base de datos de LexNET.
Nota: Con los parámetros de entrada de este servicio web, el resultado de la búsqueda ObtenerOrigenes se realiza aplicando una función AND
En una aplicación cliente que cuente con una base de datos interna se aconseja realizar esta operación dentro de los procesos de configuración e inicialización de la misma para obtener todos los orígenes válidos y almacenar su resultado. La información devuelta por esta operación no cambia frecuentemente. Si al solicitar el envío de un mensaje, el servidor devuelve un error de origen no válido, se podría volver a lanzar esta operación para actualizar la información de los orígenes disponibles en el servidor externo que invoca el servicio en LexNET y así solucionar el error. No es aconsejable invocarla cada vez que se realiza un envío para no saturar el servidor LexNET.
5.25. RUTA WSDL
Ruta WSDL (entorno de Pruebas):
https://lexnet3pruebas.justicia.es/services/ObtenerOrigenes?wsdl
5.26. MENSAJE SOAP DE PETICIóN
ObtenerOrigenes_peticion.xml
Los elementos principales se describen a continuación:
5.27. VALIDACIONES
Estas son las validaciones que se aplican al servicio web:· idAplicacion: se comprueba que el identificador de la aplicación es está admitido en el entorno actual.
· idSesion: se comprueba que el identificador de sesión es correcto ya que el usuario previamente lo ha debido introducir con anterioridad. Tiene una caducidad máxima de 30 minutos.
5.28. MENSAJE SOAP DE RESPUESTA
Los elementos principales se describen a continuación:
5.29. OBTENERCATALOGOGENERAL
5.30. DESCRIPCIóN
Este servicio web, permite obtener diversos catálogos de datos de LexNET.
Nota: Se recomienda consultar estos catálogos de forma periódica y no continúa en cada conexión a LexNET al tratarse de catálogos de datos con pocas variaciones a lo largo del tiempo.
5.31. RUTA WSDL
Ruta WSDL (entorno de Pruebas):
https://lexnet3pruebas.justicia.es/services/ObtenerCatalogoGeneral?wsdl
5.32. MENSAJE SOAP DE PETICIóN
ObtenerCatalogoGeneral_peticion.xml
Los elementos principales se describen a continuación:
5.33. VALIDACIONES
Estas son las validaciones que se aplican al servicio web:· idAplicacion: se comprueba que el identificador de la aplicación está admitido en el entorno actual.
· idSesion: se comprueba que el identificador de sesión es correcto ya que el usuario previamente lo ha debido introducir con anterioridad. Tiene una caducidad máxima de 30 minutos.
· catalogo: se verifica que el código de catálogo solicitado existe.
5.34. MENSAJE SOAP DE RESPUESTA
ObtenerCatalogoGeneral_respuesta.xml
Los elementos principales se describen a continuación:
5.35. OBTENERPENDIENTESGENERAL
5.36. DESCRIPCIóN
Esta operación devuelve la lista de tipos de mensaje (y sus subtotales) que quedan por descargar por parte de la entidad que realiza la petición. Los subtotales a los que se refiere el resultado de este servicio se refieren a aquellos mensajes que no se han descargado nunca desde el cliente.
5.37. RUTA WSDL
Ruta WSDL (entorno de Pruebas): https://lexnet3pruebas.justicia.es/services/ObtenerPendientesGeneral?wsdl
5.38. MENSAJE SOAP DE PETICIóN
ObtenerPendientesGeneral_peticion.xml
Los elementos principales se describen a continuación:
5.39. VALIDACIONES
Estas son las validaciones que se aplican al servicio web:· idAplicacion: se comprueba que el identificador de la aplicación es está admitido en el entorno actual.
· idSesion: se comprueba que el identificador de sesión es correcto ya que el usuario previamente lo ha debido introducir con anterioridad. Tiene una caducidad máxima de 30 minutos.
· idSujetoEntidad: se comprueba que el identificador de la entidad sea correcta y pertenezca a la aplicación.
5.40. MENSAJE SOAP DE RESPUESTA
ObtenerPendientesGeneral_respuesta.xml
Los elementos principales se describen a continuación:
5.41. OBTENERCABECERASGENERAL
5.42. DESCRIPCIóN
Este servicio permite al cliente obtener las cabeceras de los mensajes que cumplan unas determinadas condiciones de filtrado para el actor que realiza la petición. El servidor LexNET devuelve como salida del servicio una lista con las cabeceras de los mensajes (de cada mensaje: identificador LexNET más datos de origen y destino y datos adicionales) que cumplen con los parámetros de búsqueda, que puede ser:· por fecha exacta,
· rango de fechas,
· tipo de mensaje
· sólo mensajes pendientes de descarga (por defecto a no ser que se indique una fecha exacta o rango de fechas),
· sólo acuses de envíos realizados:
o 1) aceptados por el Sistema de Gestión Procesal destinatario
o 2) rechazados por el Sistema de Gestión Procesal destinatario.
Al contrario de lo que ocurre con la operación ObtenerPendientesGeneral, esta operación no filtra los resultados por estado de descarga, a no ser que así se especifique en los parámetros; es decir: la cabecera de un mensaje se puede descargar más de una vez. Por esta razón, es conveniente que las aplicaciones cliente lleven algún control de fechas para no hacer solicitudes cuya respuesta sea de un volumen muy grande de información que perjudique el rendimiento del servidor y de la aplicación cliente.
En el caso de envío de mensajes de tipo escritos e itineraciones enviadas a un órgano judicial por una entidad o un usuario, los mensajes tienen que ser integrados en el Sistema de Gestión Procesal desde el que se aceptan o rechazan. Por ello, tras la realización de un envío, la entidad/usuario remitente podrá descargar un acuse del envío hacia el órgano judicial. Posteriormente, a través de este servicio web podrá verificar si el mensaje enviado (acuse) se encuentra aceptado o rechazado por el Sistema de Gestión Procesal del órgano judicial destinatario.
5.43. RUTA WSDL
Ruta WSDL (entorno de Pruebas): https://lexnet3pruebas.justicia.es/services/ObtenerCabecerasGeneral?wsdl
5.44. MENSAJE SOAP DE PETICIóN
ObtenerCabecerasGeneral_peticion.xml
Los elementos principales se describen a continuación:
5.45. VALIDACIONES
Estas son las validaciones que se aplican al servicio web:· idAplicacion: se comprueba que el identificador de la aplicación está admitido en el entorno actual.
· idSesion: se comprueba que el identificador de sesión es correcto ya que el usuario previamente lo ha debido introducir con anterioridad. Tiene una caducidad máxima de 30 minutos.
· idSujetoEntidad: se comprueba que el identificador de la entidad sea correcta y pertenezca a la aplicación.
5.46. MENSAJE SOAP DE RESPUESTA
ObtenerCabecerasGeneral_respuesta.xml
Los elementos principales se describen a continuación:
En el caso que el usuario conectado pertenezca a un rol para el que esté definido que debe enviar una verificación de lectura antes de descargarse el mensaje, la respuesta a este servicio web sería la siguiente:
En el caso de que para la entidad conectada sea obligatorio el envío de una verificación de lectura antes de la descarga del mensaje, la petición a este servicio sin haber enviado previamente la verificación de lectura, devolvería únicamente como respuesta el identificador del mensaje en LexNET y la fecha de envío del mismo.
Por tanto, para este tipo de entidades, la secuencia de petición a los servicios web LexNET para la descarga de la cabecera de un mensaje o del mensaje completo sería la siguiente: primero se enviaría la verificación de lectura (petición al servicio EnviarVerificacionLecturaGeneral), posteriormente se descargaría la cabecera del mensaje (petición al servicio ObtenerCabeceraGeneral) o el mensaje completo (petición al servicio ObtenerMensajeGeneral).
Figura 7 Descarga de mensajes
5.47. OBTENERMENSAJEGENERAL
5.48. DESCRIPCIóN
Con esta operación un servidor solicita la descarga de los datos asociados a un mensaje concreto (con un identificador determinado) desde el servidor LexNET para el usuario/entidad que está en la petición. LexNET responde con los datos del mensaje:· datos de cabecera
· destinos
· adjuntos
· firmantes
Así como la información de control de los bloques de los archivos adjuntos del mensaje (tamaño de los bloques) que se podrán descargar a través de la operación ObtenerBloque descrita posteriormente.
5.49. RUTA WSDL
Ruta WSDL (entorno de Pruebas): https://lexnet3pruebas.justicia.es/services/ObtenerMensajeGeneral?wsdl
5.50. MENSAJE SOAP DE PETICIóN
ObtenerMensajeGeneral.xml
Los elementos principales se describen a continuación:
5.51. VALIDACIONES
Estas son las validaciones que se aplican al servicio web:· idAplicacion: se comprueba que el identificador de la aplicación es está admitido en el entorno actual.
· idSesion: se comprueba que el identificador de sesión es correcto ya que el usuario previamente lo ha debido introducir con anterioridad. Tiene una caducidad máxima de 30 minutos.
· idSujetoEntidad: se comprueba que el identificador de la entidad sea correcta y pertenezca a la aplicación.
· id: se comprueba que el valor introducido es un identificador valido para un mensaje existente. Además para el caso de usuarios o entidades que requieran firma de recibí previa a la descarga del mensaje, también se comprueba que para el mensaje introducido se envió un recibí previamente (a través del servicio EnviarVerificacionLecturaGeneral).
5.52. MENSAJE SOAP DE RESPUESTA
ObtenerMensajeGeneral_respuesta.xml
Los elementos principales se describen a continuación:
Nota: En versiones anteriores de este servicio web, si el firmante era un profesional o usuario judicial, se devolvía el elemento certificado incluido dentro del elemento profesional o usuario judicial, con la parte pública del certificado de profesional codificada en base64, pero se ha eliminado para mejorar el rendimiento del servicio y porque no es un dato importante.
5.53. OBTENERBLOQUE
5.54. DESCRIPCIóN
Esta funcionalidad permite descargar, por fragmentos, los ficheros adjuntos de un mensaje concreto (con un identificador LexNET de mensaje determinado). Previamente a la descarga de los ficheros por bloques se debe invocar la función Obtenermensajegeneral para recibir la información relativa a la descarga de adjuntos: los identificadores y nombres de los adjuntos, así como el tamaño de los bloques que enviará el servidor.
Nota: es importarte resaltar que es responsabilidad de la aplicación cliente llevar el control de la descarga, pidiendo los bloques según los vaya consolidando, ya que el Servicio Web no esperará recibir las peticiones en orden: enviará el bloque que el cliente le solicite. El servidor LexNET sí indicará cuándo el bloque que está entregando es el último para ese adjunto (no necesariamente indica que el cliente terminó la descarga, sino que indica que ese identificador de bloque es el mayor admitido para ese adjunto) de modo que el cliente pueda consolidar el fichero adjunto (si ha solicitado los bloques de forma secuencial).
5.55. RUTA WSDL
Ruta WSDL (entorno de Pruebas):
https://lexnet3pruebas.justicia.es/services/ObtenerBloque?wsdl
5.56. MENSAJE SOAP DE PETICIóN
ObtenerBloque_peticion.xml
Los elementos principales se describen a continuación:
5.57. VALIDACIONES
Estas son las validaciones que se aplican al servicio web:· idAplicacion: se comprueba que el identificador de la aplicación es está admitido en el entorno actual.
· idSession: se comprueba que el identificador de sesión es correcto ya que el usuario previamente lo ha debido introducir con anterioridad. Tiene una caducidad máxima de 30 minutos.
· idSujetoEntidad: se comprueba que el identificador de la entidad sea correcta y pertenezca a la aplicación.
· idLexnet: se comprueba que el valor coincide con un mensaje existente y valido.
· idAdjunto: se comprueba que el número del adjunto a descargar es válido.
5.58. MENSAJE SOAP DE RESPUESTA
ObtenerBloque_respuesta.xml
Los elementos principales se describen a continuación:
5.59. TERMINARDESCARGA
5.60. DESCRIPCIóN
Es muy importante que la aplicación cliente invoque esta operación cuando finalice la descarga de los ficheros adjuntos de un mensaje para indicarle al servidor LexNET que ha recibido correctamente todos los bloques y así este pueda limpiar los ficheros temporales y atributos de sesión que haya creado para esa descarga.
5.61. RUTA WSDL
Ruta WSDL (entorno de Pruebas):
https://lexnet3pruebas.justicia.es/services/TerminarDescarga?wsdl
5.62. MENSAJE SOAP DE PETICIóN
TerminarDescarga_peticion.xml
Los elementos principales se describen a continuación:
5.63. VALIDACIONES· idAplicacion: se comprueba que el identificador de la aplicación es está admitido en el entorno actual.
· idSession: se comprueba que el identificador de sesión es correcto ya que el usuario previamente lo ha debido introducir con anterioridad. Tiene una caducidad máxima de 30 minutos.
· idSujetoEntidad: se comprueba que el identificador de la entidad sea correcta y pertenezca a la aplicación.
5.64. MENSAJE SOAP DE RESPUESTA
Los elementos principales se describen a continuación:
5.65. DESCARGARMENSAJE
5.66. DESCRIPCIóN
Este servicio web descargará todos los adjuntos del mensaje indicado y el acuse que se obtiene al invocar el SW de imprimirMensaje en un zip codificado en base64. De esta forma se reducirá el número de llamadas a los SW pues no se necesitará invocar el SW de ObtenerBLoque por cada adjunto pues se descargarán todos juntos.
Previamente a la descarga de los ficheros por bloques se debe invocar la función Obtenermensajegeneral para recibir la información relativa a la descarga de adjuntos: los identificadores y nombres de los adjuntos, así como el tamaño de los bloques que enviará el servidor.
Nota: es importarte resaltar que es responsabilidad de la aplicación cliente llevar el control de la descarga, pidiendo los bloques según los vaya consolidando, ya que el Servicio Web no esperará recibir las peticiones en orden: enviará el bloque que el cliente le solicite. El servidor LexNET sí indicará cuándo el bloque que está entregando es el último para ese adjunto (no necesariamente indica que el cliente terminó la descarga, sino que indica que ese identificador de bloque es el mayor admitido para ese adjunto) de modo que el cliente pueda consolidar el fichero adjunto (si ha solicitado los bloques de forma secuencial).
5.67. RUTA WSDL
Ruta WSDL (entorno de Pruebas):
https://lexnet3pruebas.justicia.es/services/DescargarMensaje?wsdl
5.68. MENSAJE SOAP DE PETICIóN
ObtenerBloque_peticion.xml
Los elementos principales se describen a continuación
5.69. VALIDACIONES
Estas son las validaciones que se aplican al servicio web:· idAplicacion: se comprueba que el identificador de la aplicación es está admitido en el entorno actual.
· idSession: se comprueba que el identificador de sesión es correcto ya que el usuario previamente lo ha debido introducir con anterioridad. Tiene una caducidad máxima de 30 minutos.
· idSujetoEntidad: se comprueba que el identificador de la entidad sea correcta y pertenezca a la aplicación.
· idLexnet: se comprueba que el valor coincide con un mensaje existente y valido.
5.70. MENSAJE SOAP DE RESPUESTA
ObtenerBloque_respuesta.xml
Los elementos principales se describen a continuación:
5.71. ENVIARESCRITOGENERAL
5.72. DESCRIPCIóN
Este servicio se utiliza para informar al sistema LexNET la intención de enviar un escrito de trámite.
Este servicio permitirá dos tipos de comportamiento en LexNET, tal como se indica al principio del documento:· envío por parte de un usuario conectado a un sistema externo: el usuario origen del escrito ya ha quedado identificado en loginserviciosgeneral
· envío por parte de un servidor de aplicación: el servidor desde el que se envía el escrito ya ha quedado identificado en loginserviciosgeneral. La entidad a la que pertenece el usuario origen del escrito debe ser indicado por el servidor de aplicación en cada envío que se haga con EnviarEscritoGeneral. El usuario personal podrá ser identificado a través del certificado usado en la firma por el servidor LexNET.
Este servicio se utiliza para informar al sistema de la intención de enviar un escrito. En la petición a este servicio web, el cliente enviará los datos del escrito (destinatarios, título, referencia externa, nombres de los adjuntos, etc.) que posteriormente se remitirá. Tras validar los datos recibidos, el servidor LexNET devolverá una plantilla de mensaje, junto con el identificador del envío.
El formato de la plantilla de mensaje devuelto por LexNET incluirá los datos principales del escrito según lo enviado en la petición.
El cliente de los servicios web LexNET deberá añadir a esa plantilla el contenido físico de los datos adjuntos y firmarla con la clave privada de remitente.
En el ANEXO III: Guía de cumplimentación de las plantillas de los mensajes de envío, al final de este documento, se encuentra una explicación detallada acerca de los formatos de plantilla posibles devueltos por LexNET en respuesta a la petición, junto con una explicación acerca de cómo completar y firmar dichas plantillas.
El escrito resultante (plantilla enviada por LexNET completada por el cliente con datos adjuntos, firmas, etc.) será enviado por fragmentos a LexNET, utilizando la operación EnviarBloqueGeneral (para lo cual se precisará el identificador del envío devuelto por EnviarEscritoGeneral).
Nota: La SGNTJ va a eliminar la posibilidad de envío en formato MIME con fecha de 30 de Junio de 2015, siendo sólo posible la firma del envío en CAdES a partir de esa fecha. De manera adicional, se recomienda a los nuevos integradores que los ficheros adjuntos al envío tengan formato PDF y estén firmados en PADES. Aunque el formato de fichero RTF está soportado, se prevé su eliminación en futuras versiones.
5.73. RUTA WSDL
Ruta WSDL (entorno de Pruebas):
https://lexnet3pruebas.justicia.es/services/EnviarEscritoGeneral?wsdl
5.74. MENSAJE SOAP DE PETICIóN
EnviarEscritoGeneral_peticion.xml
Los elementos principales se describen a continuación:
5.75. VALIDACIONES
Estas son las validaciones que se aplican al servicio web:· idAplicacion: se comprueba que el identificador de la aplicación es está admitido en el entorno actual.
· idSesion: se comprueba que el identificador de sesión es correcto ya que el usuario previamente lo ha debido introducir con anterioridad. Tiene una caducidad máxima de 30 minutos.
· idSujetoEntidad: se comprueba que el identificador de la entidad sea correcta y pertenezca a la aplicación.
· destinos: se comprueban que todos los destinatarios son validados para la entidad o usuario logado y que pueden recibir escritos.
· adjuntos: se comprueban que los adjuntos introducidos son correctos. Se comprueba la extensión del fichero principal y anexos además del número de los mismos. Siempre ha de existir al menos el fichero principal, a excepción de la corrección de escritos, en la que no se adjuntan ficheros.
· esPieza: Booleano que no puede ser nulo.
· esCorrecion: Booleano que no puede ser nulo.
· tipoProcedimiento: se comprueba que el procedimiento es válido para el órgano judicial interviniente en el mensaje.
· numeroProcedimiento: se comprueba que el número de procedimiento es válido.
· tipoProcedimientoOrigen: se comprueba que el procedimiento es válido si se ha marcado la opción de esPieza = true.
· numeroProcedimientoOrigen: se comprueba que el número de procedimiento es válido si se ha marcado la opción de esPieza = true.
· numeroPieza: se compruba si es válido si se ha marcado la opción de esPieza = true.
· fechaSGP: Fecha de generación del mensaje en el SGP ha de ser válido en notificaciones e itineraciones (formato dateTime).
· idExterno: Identificador del escrito en el sistema cliente.
· idMensajeCorreccion: Si esCorreccion = true, su valor ha de identificar a un escrito cancelado por un SGP en LexNET.
· intervinientes: en el caso de demandas se valida que exista al menos un interviniente y se valida cada interviniente de la siguiente manera:
· tipoPersona no puede ser nulo, ha de ser “F” o “J”.
· idFunción no puede ser nulo.
· Si el tipoPersona es “F”, física:
o El tipoDocumento ha de corresponderse a los especificados para una intervinientes física en las líneas anteriores.
o El idTipoDocumento no puede ser nulo.
o El nombre no puede ser nulo.
o El apellido1 no puede ser nulo.
· Si el tipoPersona es “J”, física:
o El tipoDocumento ha de corresponderse a los especificados a un interviniente jurídico en las líneas anteriores.
o El idTipoDocumento no puede ser nulo.
o El razonSocial no puede ser nulo.
· idOrden: en el caso de los escritos se valida que el idOrden se corresponda con los valores 1 = CIVIL, 2=PENAL, 3=SOCIAL, 4=CONTENCIOSO.
· idMateria y descripMateria: en el caso de los escritos se válida para el idOrden indicado. Es obligatorio en los casos que el idOrden sea CIVIL, CONTENCIOSO y SOCIAL
· Organismo: en el caso de los escritos de idOrden sea CONTENCIOSO no puede ser nulo.
· Localidad: en el caso de los escritos con idOrden PENAL no puede ser nulo.
· datosResolucion: en el caso que exista datosResolución se validará que tipoResolucion, fechaResolucion y numeroResolucion estén informados.
5.76. MENSAJE SOAP DE RESPUESTA
EnviarEscritoGeneral_respuesta.xml
Los elementos principales se describen a continuación:
5.77. ENVIARINICIADORESGENERAL
5.78. DESCRIPCIóN
Este servicio se utiliza para informar al sistema de la intención de enviar un escrito iniciador de asunto, atestado o parte hospitalario. En la petición a este servicio web, el cliente enviará los datos del Iniciador (destinatarios, título, referencia externa, nombres de los adjuntos, etc.) que posteriormente se remitirá. Tras validar los datos recibidos, el servidor LexNET devolverá una plantilla del Iniciador, junto con el identificador del envío.
El formato de la plantilla de mensaje devuelto por LexNET incluirá los datos principales del mensaje según lo enviado en la petición.
El cliente de los servicios web LexNET deberá añadir a esa plantilla el contenido físico de los datos adjuntos y firmarla con la clave privada del usuario remitente.
En el apartado 5.2 al final de este documento, se encuentra una explicación detallada acerca de los formatos de plantilla posibles devueltos por LexNET en respuesta a la petición, junto con una explicación acerca de cómo completar y firmar dichas plantillas.
El mensaje resultante (plantilla enviada por LexNET completada por el cliente con datos adjuntos, firmas, etc.) será enviado por fragmentos a LexNET, utilizando la operación EnviarBloqueGeneral (para lo cual se precisará el identificador del envío devuelto por EnviarIniciadoresGeneral).
Nota: La SGNTJ va a eliminar la posibilidad de envío en formato MIME con fecha de 30 de Junio de 2015, siendo sólo posible la firma del envío en CADES a partir de esa fecha. De manera adicional, los ficheros adjuntos al envío deberán tener formato PDF y estar firmados en PADES.
A partir de la versión XSD 3.15 existen tres tipos de iniciadores distintos: iniciador de asunto, iniciador atestado e iniciador parte hospitalario. A continuación se detallan por separado los campos necesarios en la petición para cada tipo de iniciador.
5.79. RUTA WSDL
Ruta WSDL (entorno de Pruebas): https://lexnet3pruebas.justicia.es/services/EnviarIniciadoresGeneral?wsdl
5.80. INICIADOR DE ASUNTO
5.81. INICIADOR ATESTADO
5.82. INICIADOR PARTE HOSPITALARIO
5.83. VALIDACIONES
Estas son las validaciones que se aplican al servicio web:
· idAplicacion: se comprueba que el identificador de la aplicación está admitido en el entorno actual.
· idSesion: se comprueba que el identificador de sesión es correcto ya que el usuario previamente lo ha debido introducir con anterioridad. Tiene una caducidad máxima de 30 minutos.
· idSujetoEntidad: se comprueba que el identificador de la entidad sea correcta y pertenezca a la aplicación.
· destinos: se comprueban que todos los destinatarios son validados para la entidad o usuario logado y el tipo de mensaje.
· adjuntos: se comprueban que los adjuntos introducidos son correctos. Se comprueba la extensión del fichero principal y anexos además del número de los mismos. Siempre ha de existir al menos el fichero principal, a excepción de la corrección de escritos, en la que no se adjuntan ficheros.
· intervinientes: en el caso de demandas se valida que exista al menos un interviniente y se valida cada interviniente de la siguiente manera:
· tipoPersona no puede ser nulo.
· idFunción no puede ser nulo.
· Si el tipoPersona es física:
o El tipoDocumento ha de corresponderse a los especificados para una intervinientes física en las líneas anteriores.
o El idTipoDocumento no puede ser nulo.
o El nombre no puede ser nulo.
o El apellido1 no puede ser nulo.
· Si el tipoPersona es jurídica:
o El tipoDocumento ha de corresponderse a los especificados a un interviniente jurídico en las líneas anteriores.
o El idTipoDocumento no puede ser nulo.
o El razonSocial no puede ser nulo.
· idOrden: en el caso de las demandas se valida que el idOrden se corresponda con los valores 1 = CIVIL, 2=PENAL, 3= CONTENCIOSO, 4=SOCIAL.
· tipificacion no puede ser nulo para PENAL o CIVIL
o esViolenciaGenero no puede ser nulo para PENAL o CIVIL. Por defecto false.
o esViolenciaDomestica no puede ser nulo para PENAL o CIVIL. Por defecto false.
· Causa no puede ser nulo para PENAL.
o esDetenido no puede ser nulo para PENAL. Por defecto false.
o esPreso no puede ser nulo para PENAL. Por defecto false.
· codigoMateria y descripMateria: en el caso de las demandas se valida para el idOrden indicado. Es obligatorio en los casos que el idOrden sea CIVIL, CONTENCIOSO y SOCIAL
· Organismo: en el caso de las demandas que idOrden sea CONTENCIOSO no puede ser nulo.
· Localidad: en el caso de las demandas con idOrden PENAL no puede ser nulo.
· El destinatario no puede ser una entidad que cumpla las siguientes condiciones: no decanato y no única.
· datosResolucion: en el caso que exista datosResolución se validará que tipoResolucion, fechaResolucion y numeroResolucion estén informados.
5.84. MENSAJE SOAP DE RESPUESTA
EnviarIniciadores_respuesta.xml
Los elementos se enumeran a continuación:
5.85. ENVIAREJECUCIONESGENERAL
5.86. DESCRIPCIóN
Este servicio se utiliza para informar al sistema de la intención de enviar un escrito iniciador de ejecución. En la petición a este servicio web, el cliente enviará los datos de la Ejecución (destinatarios, título, referencia externa, nombres de los adjuntos, etc.) que posteriormente se remitirá. Tras validar los datos recibidos, el servidor LexNET devolverá una plantilla de la Ejecución junto con el identificador del envío.
El formato de la plantilla de mensaje devuelto por LexNET incluirá los datos principales del mensaje según lo enviado en la petición.
El cliente de los servicios web LexNET deberá añadir a esa plantilla el contenido físico de los datos adjuntos y firmarla con la clave privada del usuario remitente.
En el apartado 5.2 al final de este documento, se encuentra una explicación detallada acerca de los formatos de plantilla posibles devueltos por LexNET en respuesta a la petición, junto con una explicación acerca de cómo completar y firmar dichas plantillas.
El mensaje resultante (plantilla enviada por LexNET completada por el cliente con datos adjuntos, firmas, etc.) será enviado por fragmentos a LexNET, utilizando la operación EnviarBloqueGeneral (para lo cual se precisará el identificador del envío devuelto por EnviarIniciadoresGeneral).
5.87. RUTA WSDL
Ruta WSDL (entorno de Pruebas): https://lexnet3pruebas.justicia.es/services/EnviarEjecucionesGeneral?wsdl
5.88. MENSAJE SOAP DE PETICIóN
EnviarEjecucionesGeneral_peticion.xml
5.89. VALIDACIONES
Estas son las validaciones que se aplican al servicio web:
· idAplicacion: se comprueba que el identificador de la aplicación está admitido en el entorno actual.
· idSesion: se comprueba que el identificador de sesión es correcto ya que el usuario previamente lo ha debido introducir con anterioridad. Tiene una caducidad máxima de 30 minutos.
· idSujetoEntidad: se comprueba que el identificador de la entidad sea correcta y pertenezca a la aplicación.
· destinos: se comprueban que todos los destinatarios son validados para la entidad o usuario logado y el tipo de mensaje.
· adjuntos: se comprueban que los adjuntos introducidos son correctos. Se comprueba la extensión del fichero principal y anexos además del número de los mismos. Siempre ha de existir al menos el fichero principal, a excepción de la corrección de escritos, en la que no se adjuntan ficheros.· idAdjunto: Campo obligatorio. Númerico entre 1 y 99.
· intervinientes: en el caso de ejecucións se valida que exista al menos un interviniente y se valida cada interviniente de la siguiente manera:
· idOrden: en el caso de las ejecucións se valida que el idOrden se corresponda con los valores 1 = CIVIL, 2=PENAL, 3=SOCIAL, 4=CONTENCIOSO.
5.90. MENSAJE SOAP DE RESPUESTA
EnviarEjecucionesGeneral_respuesta.xml
Los elementos se enumeran a continuación:
5.91. ENVIARPERSONACIONESGENERAL
5.92. DESCRIPCIóN
Este servicio se utiliza para informar al sistema de la intención de enviar una personacion. En la petición a este servicio web, el cliente enviará los datos de la personación (destinatario, nombres de los adjuntos, etc.) que posteriormente se remitirá. Tras validar los datos recibidos, el servidor LexNET devolverá una plantilla, junto con el identificador del envío.
El formato de la plantilla de mensaje devuelto por LexNET incluirá los datos principales del mensaje según lo enviado en la petición.
El cliente de los servicios web LexNET deberá añadir a esa plantilla el contenido físico de los datos adjuntos y firmarla con la clave privada del usuario remitente.
En el apartado 5.2 al final de este documento, se encuentra una explicación detallada acerca de los formatos de plantilla posibles devueltos por LexNET en respuesta a la petición, junto con una explicación acerca de cómo completar y firmar dichas plantillas.
El mensaje resultante (plantilla enviada por LexNET completada por el cliente con datos adjuntos, firmas, etc.) será enviado por fragmentos a LexNET, utilizando la operación EnviarBloqueGeneral (para lo cual se precisará el identificador del envío devuelto por EnviarPersonacionesGeneral).
5.93. RUTA WSDLRuta WSDL (entorno de Pruebas):
https://lexnet3pruebas.justicia.es/services/EnviarPersonacionesGeneral?wsdl
5.94. VALIDACIONES
Estas son las validaciones que se aplican al servicio web:
· idAplicacion: se comprueba que el identificador de la aplicación está admitido en el entorno actual.
· idSesion: se comprueba que el identificador de sesión es correcto ya que el usuario previamente lo ha debido introducir con anterioridad. Tiene una caducidad máxima de 30 minutos.
· destinos: se comprueban que todos los destinatarios son validados para la entidad o usuario logado y el tipo de mensaje.
· adjuntos: se comprueban que los adjuntos introducidos son correctos. Se comprueba la extensión del fichero principal y anexos además del número de los mismos. Siempre ha de existir al menos el fichero principal, a excepción de la corrección de escritos, en la que no se adjuntan ficheros.
· intervinientes: en el caso de demandas se valida que exista al menos un interviniente y se valida cada interviniente de la siguiente manera:
· Si el tipoPersona es “F”, física:
o El tipoDocumento ha de corresponderse a los especificados para una intervinientes física en las líneas anteriores.
o El idTipoDocumento no puede ser nulo.
o El nombre no puede ser nulo.
o El apellido1 no puede ser nulo.
· Si el tipoPersona es “J”, física:
o El tipoDocumento ha de corresponderse a los especificados a un interviniente jurídico en las líneas anteriores.
o El idTipoDocumento no puede ser nulo.
o El razonSocial no puede ser nulo.
· idOrden: en el caso de las demandas se valida que el idOrden se corresponda con los valores 1 = CIVIL, 2=PENAL, 3=SOCIAL, 4=CONTENCIOSO.
· El destinatario no puede ser una entidad que cumpla las siguientes condiciones: decanato o única.
· datosResolucion: en el caso que exista datosResolución se validará que tipoResolucion, fechaResolucion y numeroResolucion estén informados.
5.95. MENSAJE SOAP DE RESPUESTA
EnviarPersonacionesGeneral_respuesta.xml
Los elementos se enumeran a continuación:
5.96. ENVIARRECURSOQUEJAGENERAL
5.97. DESCRIPCIóN
Este servicio se utiliza para informar al sistema de la intención de enviar un recurso de queja. En la petición a este servicio web, el cliente enviará los datos del recurso (destinatario, nombres de los adjuntos, etc.) que posteriormente se remitirá. Tras validar los datos recibidos, el servidor LexNET devolverá una plantilla, junto con el identificador del envío.
El formato de la plantilla de mensaje devuelto por LexNET incluirá los datos principales del mensaje según lo enviado en la petición.
El cliente de los servicios web LexNET deberá añadir a esa plantilla el contenido físico de los datos adjuntos y firmarla con la clave privada del usuario remitente.
En el apartado 5.2 al final de este documento, se encuentra una explicación detallada acerca de los formatos de plantilla posibles devueltos por LexNET en respuesta a la petición, junto con una explicación acerca de cómo completar y firmar dichas plantillas.
El mensaje resultante (plantilla enviada por LexNET completada por el cliente con datos adjuntos, firmas, etc.) será enviado por fragmentos a LexNET, utilizando la operación EnviarBloqueGeneral (para lo cual se precisará el identificador del envío devuelto por EnviarPersonacionesGeneral).
5.98. RUTA WSDLRuta WSDL (entorno de Pruebas):
https://lexnet3pruebas.justicia.es/services/EnviarRecursoQuejaGeneral?wsdl
5.99. VALIDACIONES
Estas son las validaciones que se aplican al servicio web:
· idAplicacion: se comprueba que el identificador de la aplicación está admitido en el entorno actual.
· idSesion: se comprueba que el identificador de sesión es correcto ya que el usuario previamente lo ha debido introducir con anterioridad. Tiene una caducidad máxima de 30 minutos.
· destinos: se comprueban que todos los destinatarios son validados para la entidad o usuario logado y el tipo de mensaje.
· adjuntos: se comprueban que los adjuntos introducidos son correctos. Se comprueba la extensión del fichero principal y anexos además del número de los mismos. Siempre ha de existir al menos el fichero principal, a excepción de la corrección de escritos, en la que no se adjuntan ficheros.
· intervinientes: en el caso de demandas se valida que exista al menos un interviniente y se valida cada interviniente de la siguiente manera:
· Si el tipoPersona es “F”, física:
o El tipoDocumento ha de corresponderse a los especificados para una intervinientes física en las líneas anteriores.
o El idTipoDocumento no puede ser nulo.
o El nombre no puede ser nulo.
o El apellido1 no puede ser nulo.
· Si el tipoPersona es “J”, física:
o El tipoDocumento ha de corresponderse a los especificados a un interviniente jurídico en las líneas anteriores.
o El idTipoDocumento no puede ser nulo.
o El razonSocial no puede ser nulo.
· idOrden: en el caso de las demandas se valida que el idOrden se corresponda con los valores 1 = CIVIL, 2=PENAL, 3=SOCIAL, 4=CONTENCIOSO.
· El destinatario no puede ser una entidad que cumpla las siguientes condiciones: decanato o única.
· datosResolucion: en el caso que exista datosResolución se validará que tipoResolucion, fechaResolucion y numeroResolucion estén informados.
5.100. MENSAJE SOAP DE RESPUESTA
EnviarPersonacionesGeneral_respuesta.xml
Los elementos se enumeran a continuación:
5.100.1. EnviarRecursoCasacionGeneral
5.100.1.1. Descripción
Este servicio se utiliza para informar al sistema de la intención de enviar un recurso de casación. En la petición a este servicio web, el cliente enviará los datos del recurso (destinatarios, nombres de los adjuntos, etc.) que posteriormente se remitirá. Tras validar los datos recibidos, el servidor LexNET devolverá una plantilla junto con el identificador del envío.
El formato de la plantilla de mensaje devuelto por LexNET incluirá los datos principales del mensaje según lo enviado en la petición.
El cliente de los servicios web LexNET deberá añadir a esa plantilla el contenido físico de los datos adjuntos y firmarla con la clave privada del usuario remitente.
En el apartado 4.2 al final de este documento se encuentra una explicación detallada acerca del formato de plantilla devuelto por LexNET en respuesta a la petición, junto con una guía para su relleno.
El mensaje resultante (plantilla enviada por LexNET completada por el cliente con datos adjuntos, firmas, etc.) será enviado por fragmentos a LexNET, utilizando la operación EnviarBloqueGeneral (para lo cual se precisará el identificador del envío devuelto por EnviarRecursoCasacionGeneral).
El envío deberá ser firmado en CAdES y el documento principal del envío, en formato PDF, deberá estar firmado en PAdES.
5.100.1.2. Ruta WSDLRuta WSDL (entorno de Pruebas):
https://lexnet3pruebas.justicia.es/services/EnviarRecursoCasacionGeneral?wsdl
5.100.1.3. Validaciones
Estas son las validaciones que se aplican al servicio web:
· idAplicacion: se comprueba que el identificador de la aplicación está admitido en el entorno actual.
· idSesion: se comprueba que el identificador de sesión es correcto ya que el usuario previamente lo ha debido introducir con anterioridad. Tiene una caducidad máxima de 30 minutos.
· destinos: se comprueban que todos los destinatarios son validados para la entidad o usuario logado y el tipo de mensaje.
· adjuntos: se comprueban que los adjuntos introducidos son correctos. Se comprueba la extensión del fichero principal y anexos además del número de los mismos. Siempre ha de existir al menos el fichero principal, a excepción de la corrección de escritos, en la que no se adjuntan ficheros.
· intervinientes: en el caso de demandas se valida que exista al menos un interviniente y se valida cada interviniente de la siguiente manera:
· Si el tipoPersona es “F”, física:
o El tipoDocumento ha de corresponderse a los especificados para una intervinientes física en las líneas anteriores.
o El idTipoDocumento no puede ser nulo.
o El nombre no puede ser nulo.
o El apellido1 no puede ser nulo.
· Si el tipoPersona es “J”, física:
o El tipoDocumento ha de corresponderse a los especificados a un interviniente jurídico en las líneas anteriores.
o El idTipoDocumento no puede ser nulo.
o El razonSocial no puede ser nulo.
· idOrden: en el caso de las demandas se valida que el idOrden se corresponda con los valores 1 = CIVIL, 2=PENAL, 3=SOCIAL, 4=CONTENCIOSO.
· El destinatario no puede ser una entidad que cumpla las siguientes condiciones: decanato o única.
· datosResolucion: en el caso que exista datosResolución se validará que tipoResolucion, fechaResolucion y numeroResolucion estén informados.
5.100.1.4. Mensaje SOAP de Respuesta
EnviarRecursoCasacion_respuesta.xml
Los elementos se enumeran a continuación:
5.101. ENVIARBLOQUEGENERAL
5.102. DESCRIPCIóN
Esta operación permite al cliente enviar, en orden secuencial, los bloques que componen el mensaje. El cliente habrá compuesto el mensaje partir de la plantilla de mensaje (esqueleto) obtenida en la llamada previa al servicio EnviarMensajeGeneral). El Servidor LexNET realiza el control de flujo de los bloques recibidos a través de este servicio web (EnviarBloqueGeneral) por parte del cliente.
Al enviar el último bloque, que deberá ser identificado por el cliente como el último (aunque el servidor también interpretará como último bloque aquel cuyo tamaño sea menor que el indicado en la respuesta de la operación EnviarMensajeGeneral), el servidor LexNET consolidará en disco el mensaje recibido. Además realizará las comprobaciones necesarias sobre el mensaje, lo firmará y enviará al Sellador de Tiempo del Ministerio y generará el Acuse de Recibo.
El servidor LexNET responde al envío de cada bloque (cada petición a EnviarBloqueGeneral) con el identificador del bloque consolidado (o con una respuesta de error). En el caso de la respuesta al último bloque, la respuesta incluirá además la información de identificación del Acuse de Recibo generado y la fecha de sellado del mensaje enviado.
5.103. RUTA WSDL
Ruta WSDL (entorno de Pruebas):
https://lexnet3pruebas.justicia.es/services/EnviarBloqueGeneral?wsdl
5.104. MENSAJE SOAP DE PETICIóN
EnviarBloqueGeneral_peticion.xml
Los elementos principales se describen a continuación:
5.105. VALIDACIONES
Estas son las validaciones que se aplican al servicio web:· idAplicacion: se comprueba que el identificador de la aplicación es está admitido en el entorno actual.
· idSesion: se comprueba que el identificador de sesión es correcto ya que el usuario previamente lo ha debido introducir con anterioridad. Tiene una caducidad máxima de 30 minutos.
· idSujetoEntidad: se comprueba que el identificador de la entidad sea correcta y pertenezca a la aplicación.
· idEnvío: se comprueba que el identificador del envío ha sido obtenido anteriormente por el servicio Obtenermensajegeneral.
· idBloqueEnviado: se comprueba que el bloque a enviar es consecutivo al último recibido correctamente.
· bytesContenido: se comprueba que los datos del bloque están codificados correctamente en Base64 y tienen la longitud correcta.
5.106. MENSAJE SOAP DE RESPUESTA
EnviarBloqueGeneral_Respuesta.xml
Los elementos principales se describen a continuación:
Figura 8 Envío de mensajes
5.107. ENVIARVERIFICACIONLECTURAGENERAL
5.108. DESCRIPCIóN
Esta operación es específica para los usuarios de LexNET que por su rol tienen obligación de firmar una verificación de lectura (“Recibí”) antes de descargar los mensajes (por ejemplo: Abogados del Estado, Fiscalías, etc.). Estos usuarios, antes de solicitar la descarga de un mensaje (ObtenerMensaje) deberán invocar esta operación (EnviarVerificacionLecturaGeneral) indicando el identificador del mensaje para el cual desean enviar el recibí.
Este servicio se utiliza para informar al sistema de la intención de enviar un mensaje de verificación de lectura. Tras validar los datos recibidos, el servidor LexNET devolverá una plantilla de mensaje de verificación de lectura, junto con el identificador del envío.
El formato de la plantilla de mensaje devuelto por LexNET incluirá los datos principales del mensaje según lo enviado en la petición.
El cliente de los servicios web LexNET deberá cumplimentar esa plantilla y firmarla con la clave privada del remitente.
En el apartado ANEXO III: Guía de cumplimentación de las plantillas de los mensajes de envío, al final de este documento, se encuentra una explicación detallada acerca de los formatos de plantilla posibles devueltos por LexNET en respuesta a la petición a EnviarVerificacionLecturaGeneral, junto con una explicación acerca de cómo completar y firmar dichas plantillas.
El mensaje resultante (plantilla enviada por LexNET completada por el cliente) será enviado por fragmentos a LexNET, utilizando la operación EnviarBloqueGeneral (para lo cual se precisará el identificador del envío devuelto por EnviarVerificacionLecturaGeneral).
Nota: La SGNTJ va a eliminar la posibilidad de envío en formato MIME con fecha de 30 de Junio de 2015, siendo sólo posible la firma del envío en CAdES a partir de esa fecha.
5.109. RUTA WSDL
Ruta WSDL (entorno de Pruebas): https://lexnet3pruebas.justicia.es/services/EnviarVerificacionLecturaGeneral?wsdl
5.110. MENSAJE SOAP DE PETICIóN
EnviarVerificacionLecturaGeneral_peticion.xml
Los elementos principales se describen a continuación:
5.111. VALIDACIONES
Estas son las validaciones que se aplican al servicio web:· idAplicacion: se comprueba que el identificador de la aplicación es está admitido en el entorno actual.
· idSesion: se comprueba que el identificador de sesión es correcto ya que el usuario previamente lo ha debido introducir con anterioridad. Tiene una caducidad máxima de 30 minutos.
· idSujetoEntidad: se comprueba que el identificador de la entidad sea correcta y pertenezca a la aplicación.
· Remitente: se comprueba que la entidad que quiere enviar el recibí tiene la funcionalidad de enviar verificaciones de lectura.
5.112. MENSAJE SOAP DE RESPUESTA
EnviarVerificacionLecturaGeneral_respuesta.xml
Los elementos principales se describen a continuación:
Figura 9 Envío de verificación de lectura previo a descarga de mensaje
5.113. OBTENERAVISOSGENERAL
5.114. DESCRIPCIóN
Esta operación devuelve la lista de avisos activos en la aplicación LexNET para el usuario en nombre del cual actúa la aplicación (acceso con certificado de servidor). Este servicio se llamaría para emular el funcionamiento de la aplicación vía web cuando el usuario al hacer Login le presenta una ventana emergente con la lista de avisos de mayor importancia, o al botón del menú principal donde se listan todos los avisos activos. Es importante mantener actualizada la lista de avisos ya que los usuarios que acceden a la aplicación vía servicios web es la única forma de que se enteren de los avisos de parada de la aplicación.
5.115. RUTA WSDL
Ruta WSDL (entorno de Pruebas): https://lexnet3pruebas.justicia.es/services/ObtenerAvisosGeneral?wsdl
5.116. MENSAJE SOAP DE PETICIóN
ObtenerAvisosGeneral_peticion.xml
Los elementos principales se describen a continuación:
5.117. VALIDACIONES
Estas son las validaciones que se aplican al servicio web:· idAplicacion: se comprueba que el identificador de la aplicación es está admitido en el entorno actual.
· idSession: se comprueba que el identificador de sesión es correcto ya que el usuario previamente lo ha debido introducir con anterioridad. Tiene una caducidad máxima de 30 minutos.
· idSujetoEntidad: se comprueba que el identificador de la entidad sea correcta y pertenezca a la aplicación.
5.118. MENSAJE SOAP DE RESPUESTA
ObtenerAvisosGeneral_respuesta.xml
Los elementos principales se describen a continuación:
5.119. OBTENERACEPTADOSRECHAZADOSGENERAL
5.120. DESCRIPCIóN
Esta operación devuelve los identificadores de acuses de recibo de mensajes enviados previamente por el usuario logado que han sido aceptados/rechazados por el órgano destino (mensajes tramitados por su órgano destino).
Este servicio web posibilita por tanto a un usuario conocer si un mensaje enviado (ej: un escrito de trámite) ha sido aceptado por el órgano judicial al que lo envió o ha sido rechazado por algún error, permitiendo por tanto, remitir un escrito de subsanación.
La consulta se realiza entre periodos de fechas entre las que fueron aceptados/rechazados posibilitando a los integradores tener un control de periodos de fechas consultados y no tener que repetir consultas ya realizadas.
5.121. RUTA WSDL
Ruta WSDL (entorno de Pruebas):
https://lexnet3pruebas.justicia.es/services/ObtenerAceptadosRechazadosGeneral?wsdl
5.122. MENSAJE SOAP DE PETICIóN
ObtenerAceptadosRechazadosGeneral_peticion.xml
Los elementos principales se describen a continuación:
5.123. VALIDACIONES
Estas son las validaciones que se aplican al servicio web:· idAplicacion: se comprueba que el identificador de la aplicación está admitido en el entorno actual.
· idSesion: se comprueba que el identificador de sesión es correcto ya que el usuario previamente lo ha debido introducir con anterioridad. Tiene una caducidad máxima de 30 minutos.
· fechaInicio/fechaFin: se comprueba que se ha introducido un periodo de fechas anterior o igual a la fecha de consulta
· tipoMensaje: se comprueba que el identificador del tipo mensaje es correcto. (ver Anexo I):
5.124. MENSAJE SOAP DE RESPUESTA
ObtenerAceptadosRechazadosGeneral_respuesta.xml
Los elementos principales se describen a continuación:
5.125. IMPRIMIRMENSAJEGENERAL
5.126. DESCRIPCIóN
Este servicio permite a la Entidad la descarga de un PDF con la información relativa a uno de los mensajes residentes en su buzón. Para ello ha de haberse invocado previamente sobre el mensaje el Servicio Web ObtenerMensajeGeneral.
Este servicio permite al cliente de los servicios web LexNET obtener un documento PDF de descarga con la información de un mensaje específico. El PDF resultante se devolverá en un fichero PDF codificado en Base64.
Este servicio solo está disponible a partir de la vesión 3.12 del xsd.
5.127. RUTA WSDL
Ruta WSDL (entorno de Pruebas): https://lexnet3pruebas.justicia.es/services/ImprimirMensajeGeneral?wsdl
5.128. MENSAJE SOAP DE PETICIóN
ImprimirMensajeGeneral_peticion.
A continuación se enumeran los elementos de solicitudImprimirMensajeType definidos en el fichero WSLexNET.xsd:
5.129. VALIDACIONES
Estas son las validaciones que se aplican al servicio web:· idAplicacion: se comprueba que el identificador de la aplicación está admitido en el entorno actual.
· idSesion: se comprueba que el identificador de sesión es correcto ya que el usuario previamente lo ha debido introducir con anterioridad. Tiene una caducidad máxima de 30 minutos.
· idSujeto: si no es nulo, se comprueba que el usuario cuyo mensaje se está solicitando el PDF de descarga existe en el sistema y pertenece al Colegio de Procuradores que está realizando la petición.
· idLexnet: se comprueba que el mensaje existe, es válido, se ha ejecutado previamente el Servicio Web Obtener Mensaje.
5.130. MENSAJE SOAP DE RESPUESTA
ImprimirMensajeGeneral_respuesta.xml
A continuación se se enumeran los elementos de solicitudImprimirMensajeType definidos en el fichero WSLexNET.xsd:
5.131. DE USO POR COLEGIOS PROFESIONALES
A continuación se muestran el conjunto de servicios web de uso por parte de Colegios de Profesionales (procuradores, abogados, graduados sociales)
5.132. GESTIONPROFESIONALES
5.133. DESCRIPCIóN
Este servicio web, cuyo uso está destinado a la administración de usuarios de los distintos colectivos de profesionales, permite gestionar a dichos usuarios creando sus altas o modificando sus datos. También permite crear sustituciones y asignar personal autorizado
5.134. RUTA WSDL
Ruta WSDL (entorno de Pruebas):
https://lexnet3pruebas.justicia.es/services/GestionProfesionales?wsdl
5.135. MENSAJE SOAP DE PETICIóN
GestionProfesionales_peticion.xml
Los elementos principales se describen a continuación:
5.136. VALIDACIONES
Estas son las validaciones que se aplican al servicio web:· Certificado: se comprueba que el certificado de aplicación en la conexión SSL es correcto.
· Aplicación cliente: se comprueba, para cada alta de profesional, que la aplicación cliente tiene permisos para ejecuta el servicio sobre la entidad en la que quiere dar de alta o modificar el profesional.
· idAplicacion: se comprueba que el identificador de la aplicación está admitido en el entorno actual.
· accion: Se comprueba que contiene uno de los valores admitidos definidos anteriormente.
· tipo: se verifica que el rol indicado es uno de los admitidos para la entidad indicada en la solicitud de alta.
· codigoConsejo: se verifica que la entidad asociada a dicho código existe y es compatible con el rol indicado.
· nif: se verifica que es NIF o NIE bien formado.
· nombre, apellido1 y apellido2: se pasarán a mayúsculas
· email: se verifica si está bien formado.
· telefono: si se rellena notificableSMS, se verifica que está relleno y tenga un formato correcto.
· codigoProfesional: se verifica que no existe ya otro usuario con dicho código de profesional en la entidad en la que se quiere dar de alta.
Por cada profesional que se quiera dar de alta se comprobará:
· Que el usuario no esté dado ya de alta: Si el usuario ya está dado de alta, no se realizará el alta y se devolverá un mensaje informativo.
· Que el usuario no tenga pendiente una solicitud de alta: Si alguno de los usuarios tiene pendiente una solicitud de alta, se rechazará dicha solicitud de alta y se aceptarán como válidos para realizar el alta los datos proporcionados por este servicio.
5.137. MENSAJE SOAP DE RESPUESTA
GestionProfesionales_respuesta.xml
Los elementos principales se describen a continuación:
En caso de no superarse la validación o se produzca un error al tratar uno de los profesionales introducidos en los parámetros de entrada sólo se devolverán los parámetros de entrada más el elemento <resultadoAccion> que define un error del siguiente catálogo:
Indica que se ha producido un error no controlado. Indica que no se ha introducido un campo obligatorio Indica que no se ha introducido un campo no tiene el formato adecuado Indica que si el usuario es notificable por SMS es obligatorio introducir un número de teléfono Indica que la acción introducida no es aceptado por LexNET Indica que el tipo de rol introducido no es correcto Indica que el usuario ya está dado de alta en LexNET Indica que existe un colegiado en la entidad con el mismo número de colegiado Indica que el rol indicado no está asociado con el sujeto. Indica que el rol indicado no está relacionado con la entidad. Indica que el usuario ya está relacionado con la entidad Indica que no se han introducido datos para modificar sobre el profesional Indica que la aplicación no tiene permisos para gestionar los profesionales de la entidad. El usuario no está dado de alta en LexNET No se puede dar de altaporque ya está dado de alta pero en estado inactivo Se están indicando roles de profesionales diferentes para una sustitución. Las fechas de inicio y fin son incorrectas. La persona a la que se quiere designar como autorizada ya lo es actualmente. El DNI de la persona autorizada es incorrecto. No existe relación entre los profesionales indicados. No existe el profesional indicado No existe el profesional sustituto indicado Nota.- En la versión actual de LexNET los campos notificableSMS y teléfono no se almacenaran en las Bases de Datos de LexNET, En las siguientes versiones se almacenará. Se ha decido introducir estos campos en esta versión para facilitar la integración y posterior uso en próximas funcionalidades que se añadirán a LexNET.
5.138. OBTENERPENDIENTESCOLEGIADOSGENERAL
5.139. DESCRIPCIóN
Esta operación devuelve la lista de mensajes pendientes por tipos de mensaje (y sus subtotales) que quedan por descargar por parte de los colegiados de la entidad que realiza la petición. Los subtotales a los que se refiere el resultado este servicio se refieren a aquellos mensajes que no se han descargado nunca desde el cliente.
5.140. RUTA WSDL
Ruta WSDL (entorno de Pruebas): https://lexnet3pruebas.justicia.es/services/ObtenerPendientesColegiadosGeneral?wsdl
5.141. MENSAJE SOAP DE PETICIóN
ObtenerPendientesColegiadosGeneral_peticion.xml
Los elementos principales se describen a continuación:
5.142. VALIDACIONES
Estas son las validaciones que se aplican al servicio web:· idAplicacion: se comprueba que el identificador de la aplicación es está admitido en el entorno actual.
· idSesion: se comprueba que el identificador de sesión es correcto ya que el usuario previamente lo ha debido introducir con anterioridad. Tiene una caducidad máxima de 30 minutos.
· profesional: en el caso de introducir el filtro de profesional se comprueba de que se han rellenado alguno de los elementos para identificar al profesional, que existe el profesional y en caso de encontrarlo de que pertenece a la entidad que ejecuta la petición.
5.143. MENSAJE SOAP DE RESPUESTA
ObtenerPendientesColegiadosGeneral_respuesta.xml
Los elementos principales se describen a continuación:
5.144.
5 GLOSARIO
ACRÖNIMO /TÉRMINO SGNTJ RD N/A WS TSA SGP CAdES Tabla 1. Glosario
Aug 29, 2018 LX4_4.7v1 DSI Manual_Uso_Lexnet_Servicios_Web_Integracion_SGNTJ_ENTIDADES