En este apartado se explicarán los servicios de pfi y cómo inicializar su cliente java
ÍNDICE DEL CONTENIDO
Inicialización del cliente mediante CXF
Mediante sintaxis xml podemos definir fácilmente la configuración del cliente CXF para que acceda a los servicios de PFI. Inicialmente deberemos definir la referencia a la interfaz del servicio, que se encuentra dentro del cliente suministrado, así como a la dirección a la que apunta el wsdl levantado.
<simple:client id="pfiClient" serviceClass="es.aragon.pfi.core.ws.IDocumentIntegrationService" address="http://[entorno:puerto]/pfi_core/services/IDocumentIntegrationServiceWS" serviceName="s:IDocumentIntegrationService" xmlns:s="http://ws.core.pfi.aragon.es/ " endpointName="s:IDocumentIntegrationServiceWS" > <simple:outInterceptors> <ref bean="authorizeInterceptor" /> </simple:outInterceptors> </simple:client>
Como se puede observar en la definición XML del cliente CXF, se deberán configurar las urls donde se ubica el servicio IDocumentIntegrationServiceWS, para ello habrá que sustituir entorno y puerto por los valores correctos.
Las aplicaciones que se integran con PFI deben proporcionar en todas las peticiones el código de aplicación.
Para ello, utilizando los denominados interceptores, es posible rellenar este valor automáticamente en todas las peticiones. Como se ve en la definición del cliente se ha definido un interceptor de salida que entra en funcionamiento en el momento de construir la petición SOAP y que inserta el valor del código de aplicación en los parámetros de todos los métodos de PFI invocados.
<simple:outInterceptors> <ref bean="authorizeInterceptor" /> </simple:outInterceptors>
La definición al bean authotizeInterceptor que se incluye a continuación, permite indicarle el código de la aplicación, de esta manera el interceptor se encarga de establecer dicho valor en todos los parámetros de las llamadas a los servicios PFI. La clase con el interceptor de salida AuthorizeOutInterceptor se proporciona junto con el cliente de PFI.
<bean id="authorizeInterceptor" class="es.aragon.pfi.core.util.interceptors.AuthorizeOutInterceptor"> <property name="applicationId" value="[código aplicación llamante]"/> </bean>
-
Capturar notificaciones sobre cambios de estado en los documentos
Las aplicaciones integradoras deben definir un servlet al que invoque PFI cuando cambie el estado de un documento, no obstante, se puede consultar directamente al repositorio una vez que haya sido notificado el cambio para garantizar el último estado real.
No debe utilizarse la consulta directa al repositorio como mecanismo de control del estado de los documentos, ya que el número de llamadas recurrentes genera sobrecarga en los entornos, causando problemas tanto al propio integrador como al resto de los usuarios.
Dicho servlet se invocará con tres parámetros mediante querystring:
Parámetro | Descripción |
---|---|
idApp | PFI |
CSV | Identificador del documento que ha sufrido un cambio de estado |
estado | Estado en que se ha quedado el documento, borrador(1) u original(0) |
-
Para que PFI pueda invocar a dicha url, ésta debe estar asociada a la aplicación a través de la plataforma PAU, en el atributo responseUrl correspondiente a la aplicación. Para ello el integrador deberá completar primero el 4.- Servicios de PFI#Procedimiento de alta descrito previamente en este manual.
-
Servicios DocumentIntegrationService
Método 'sendDocumentumDocument'
Cuando una aplicación que integra Porta-firmas almacena un documento en Documentum y desea que quede guardado en Porta-firmas, invoca este servicio para que posteriormente Porta-firmas pueda hacer uso de dicho documento.
Método 'updateQuorumAndLimitDateDocument'
Método que actualiza el número mínimo de firmantes que deben firmar un documento y fecha límite de firma en los documentos con más de un firmante
Suscripción a eventos
PFI se integra con SGA para el envío de eventos. Para que una aplicación pueda recibir los eventos de PFI, es necesario que esté dada de alta en SGA y que publique un servicio web para la recepción de los eventos. En el manual de SGA se explica cómo publicar el servicio web para poder recibir los eventos.
PFI envía eventos a través de los siguientes métodos:
- expiredDocument → Método que informa los documentos que han quedado expirados por no haber sido firmados antes de la fecha límite configurada. En los datos del evento llega el código CSV del documento y su estado. Los estados a recibir son los siguientes:
- Estado 0 (BORRADOR ) → Un documento queda expirado en estado 0 (BORRADOR) cuando no tiene ninguna firma realizada y no ha sido firmado antes de la fecha límite configurada
- Estado 2 (FIRMADO) → Un documento queda expirado en estado 2 (FIRMADO) cuando tiene todas las firmas necesarias realizadas pero por algún motivo ha quedado en el estado erróneo y no se ha cumplido la fecha límite configurada
Ejemplo de datos del evento que recibiría la aplicación destino:
La aplicación destino que desee recibir los eventos debe estar suscrita en SGA al método expiredDocument de PFI. Además, en PAU deberá tener permiso sobre el método expiredDocument de PFI.
- sendEvent → Método que informa sobre los cambios de estado de los documentos de PFI. Para poder recibir estos eventos de cambios de estado, los documentos deben tener asignado el alias de la aplicación receptora en el metadato dea_ident_codigo_aplicacion. De lo contrario, no se recibirán los eventos. El evento se compone de clave y valor. La clave es el CSV del documento y el valor es el estado del documento. Los cambios de estado que se notifican son los siguientes:
- Estado 3 (Firmando asíncronamente) → Estado al que se pasan los documentos al inicio del proceso de firma para indicar que se está realizando la firma del documento.
- Estado 6 (Firma paralela) → Se alcanza este estado cuando un documento tiene varios firmantes propuestos y alguno de ellos ya ha firmado pero todavía no se cumple el quorum.
- Estado 2 (Firmado) → Documento firmado.
- Estado 0 (Borrador) → Se recibe este evento cuando se rechaza un documento pendiente de firma.
- Estado 9 (Anulado) → Se recibe este evento cuando se anula un documento.
Ejemplo de datos del evento que recibiría la aplicación destino:
La aplicación destino que desee recibir los eventos debe estar suscrita en SGA al método sendEvent de PFI. Además, en PAU deberá tener permiso sobre el método sendEvent de PFI.
Anexos
Objectos Comunes
Objeto 'ParamUpdateQuorumAndLimitDate'
Nombre | Tipo | Descripción |
---|---|---|
csv | String | CSV del documento |
quorum | Integer | Cantidad de firmas necesarias para firmar un documento |
quorumOnly | Boolean | Indica, en el caso de multifirma, si se admiten más firmas que las mínimas requeridas (quorum). |
date | Date | Fecha limite para firmar |
Objeto 'ResultUpdateQuorumAndLimitDate'
Nombre | Tipo | Descripción |
---|---|---|
errorCode | String | Código de error del servicio |
returnCode | String | Indica si la llamada ha finalizado correctamente (OK) o en error (ERROR) |
errorMessage | String | Descripción del mensaje de error |
Objeto 'ParamSendDocument'
Nombre | Tipo | Descripción |
---|---|---|
applicationId | String | Aplicación que ejecuta el método |
userNif | String | Nif del usuario |
csv | String | Código seguro de verificación del documento |
Objeto 'ResultSendDocument'
Nombre | Tipo | Descripción |
---|---|---|
returnCode | String | Indica si la llamada ha finalizado correctamente (OK) o en error (ERROR) |
errorCode | String | Código de error del servicio |
errorMessage | String | Mensaje de error del servicio |
exception | String | Excepción producida durante el proceso |