Closed tgaya-dgtic closed 1 year ago
Ayer hicimos pruebas, y únicamente falla con los cades detached. Parece que la versión, en ese caso específico, queda a null. Pendiente que comprobéis por qué quedan así estos ficheros, al cerrar el expediente.
Durante el cierre de expediente se lanza una actualización de propiedades al copiar el contenido al RM, el documento pasa de tener de v1.0 a null en esta actualización. Actualmente estamos revisando los Behaviours configurados por si pudiesen ser parte del problema.
Seguimos revisando código.
Si queréis que os lance alguna prueba mañana para hacer debug, llamadme.
Compilado el código de ayer, hechas pruebas, esto sigue fallando. Podéis comprobar en el share que ese documento existe.
{
"getDocVersionListRequest": {
"serviceHeader": {
"serviceVersion": "1.0",
"auditInfo": {
"application": "PETICIONS_BUS2"
},
"securityInfo": {
"user": "app1",
"password": "XXXXX"
}
},
"param": {
"nodeId": "9ec827ab-2be1-4cc9-bd33-68c58537fe26"
}
}
}
{
"tipus-error": "Request failed with status code 404",
"missatge-error": "Request failed with status code 404. RESPOSTA REBUDA: {\"exception\":{\"code\":\"COD_001\",\"description\":\"No se ha encontrado el documento con id 9ec827ab-2be1-4cc9-bd33-68c58537fe26.\"}}"
}
Hemos realizado pruebas con el SOAP UI y desde el ArxiuCaibClient y hemos comprobado lo siguiente:
Si ejecutamos desde el SOAP UI directamente contra GDIB funciona bien el nodo que da error, pero no devuelve resultados ya que la etiqueta de versionLabel es null:
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ws="http://www.caib.es/gdib/repository/ws">
<soapenv:Header/>
<soapenv:Body>
<ws:getNodeVersionList>
<!--Optional:-->
<ws:nodeId>9ec827ab-2be1-4cc9-bd33-68c58537fe26</ws:nodeId>
<!--Optional:-->
<ws:gdibHeader>
<ws:gdibAudit>
<ws:applicant>
<ws:document>123456789Z</ws:document>
<ws:name>Manuel P[0xc3][0xa9]rez</ws:name>
</ws:applicant>
<ws:application>PINBAL</ws:application>
<ws:esbOperation>createFile</ws:esbOperation>
<ws:fileUid>Proc. Subvenciones empleo</ws:fileUid>
</ws:gdibAudit>
<ws:gdibRestriction>
<ws:types>eni:documento</ws:types>
</ws:gdibRestriction>
<ws:gdibSecurity>
<ws:user>xxxxxxx</ws:user>
<ws:password>xxxxxx</ws:password>
</ws:gdibSecurity>
</ws:gdibHeader>
</ws:getNodeVersionList>
</soapenv:Body>
</soapenv:Envelope>
RESPUESTA:
<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
<S:Body>
<ns2:getNodeVersionListResponse xmlns:ns2="http://www.caib.es/gdib/repository/ws"/>
</S:Body>
</S:Envelope>
Y esto en la traza de log de Alfresco:
2023-03-07 11:02:58,989 DEBUG [impl.authtrans.AuthTransRepositoryServiceSoapPortImpl] [ajp-nio-0.0.0.0-8009-exec-11] Autenticacion realizada
2023-03-07 11:02:59,037 INFO [ws.impl.RepositoryServiceSoapPortImpl] [ajp-nio-0.0.0.0-8009-exec-11] Lista de versiones de 9ec827ab-2be1-4cc9-bd33-68c58537fe26 recuperada en 40ms.
2023-03-07 11:02:59,055 INFO [impl.authtrans.AuthTransRepositoryServiceSoapPortImpl] [ajp-nio-0.0.0.0-8009-exec-11] getNodeVersionList(9ec827ab-2be1-4cc9-bd33-68c58537fe26) securizado ejecutado en: 136 ms.
Como se puede ver no hay errores, simplemente devuelve una lista vacía. Comprobando el código y la lógica del BUS, hemos encontrado que el mensaje de error que devuelve de "No se ha encontrado el documento con id 9ec827ab-2be1-4cc9-bd33-68c58537fe26." es debido a la lógica del BUS, si no devuelve un resultado mayor que cero, devuelve este error, creo que debería ser mayor o igual a cero. Hemos modificado esta lógica en el BUS y ahora devuelve lo siguiente:
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Header/>
<soapenv:Body>
<jsonObject>
<getDocVersionListRequest>
<serviceHeader>
<serviceVersion>1.0</serviceVersion>
<auditInfo>
<application>PETICIONS_BUS5_JAVA</application>
</auditInfo>
<securityInfo>
<user>app1</user>
<password>xxxxxx</password>
</securityInfo>
</serviceHeader>
<param>
<nodeId>9ec827ab-2be1-4cc9-bd33-68c58537fe26</nodeId>
</param>
</getDocVersionListRequest>
</jsonObject>
</soapenv:Body>
</soapenv:Envelope>
RESPUESTA:
<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
<S:Body>
<csgd:getDocVersionListResult xmlns:csgd="urn:es.caib.archivodigital.esb.services:1.0.0">
<csgd:result>
<csgd:code>COD_000</csgd:code>
<csgd:description>Petición realizada correctamente.</csgd:description>
</csgd:result>
</csgd:getDocVersionListResult>
</S:Body>
</S:Envelope>
Que me parece que es una respuesta correcta. Pero el ArxiuPluginCaib no controla esto en el código, y haciendo pruebas en ArxiuCaibClient , nos da ahora este error:
-- detallsDocument --
0 [main] DEBUG es.caib.plugins.arxiu.caib.ArxiuCaibClient - Enviant petici¾ HTTP a l'arxiu (url=https://esbdes3.caib.es:4430/esb/services/getDocVersionList, tipus=application/json )
1391 [main] DEBUG es.caib.plugins.arxiu.caib.ArxiuCaibClient - Rebuda resposta HTTP de l'arxiu (status=200)
Exception in thread "main" es.caib.plugins.arxiu.api.ArxiuException: S'ha produit un error cridant el mètode /services/getDocument
at es.caib.plugins.arxiu.caib.ArxiuPluginCaib.documentDetalls(ArxiuPluginCaib.java:907)
at client.ArxiuCaibClient.detallsDocument(ArxiuCaibClient.java:189)
at client.ArxiuCaibClient.main(ArxiuCaibClient.java:813)
Caused by: java.lang.NullPointerException
at java.base/java.util.Collections.sort(Collections.java:179)
at es.caib.plugins.arxiu.caib.ArxiuPluginCaib.documentVersionsComu(ArxiuPluginCaib.java:1598)
at es.caib.plugins.arxiu.caib.ArxiuPluginCaib.documentDarreraVersio(ArxiuPluginCaib.java:1619)
at es.caib.plugins.arxiu.caib.ArxiuPluginCaib.documentDetalls(ArxiuPluginCaib.java:893)
... 2 more
Mirando el código de ArxiuPluginCaib en esa línea, vemos que no se controla la lógica de devolverte un listado vacío.
List<VersionNode> versions = resposta.getGetDocVersionListResult().getResParam();
Collections.sort(
versions,
new Comparator<VersionNode>() {
public int compare(VersionNode vn1, VersionNode vn2) {
return vn1.getDate().compareTo(vn2.getDate());
}
});
La variable "versions" no se hace comprobación de que esté vacía y da error el Collection.sort.
Si quieres lo hablamos la posible solución, también podríamos entregar en la petición GDIB un objeto 1.0 DUMMY, pero esto me parece una solución peor.
Evidentemente, el problema es que al crear cualquier otro tipo de documento en RM, GDIB le añade una versión, y en cambio para los cades detached no le añade versión. Habría que comprobar por qué actúa distinto en ese caso. Creo que por coherencia, en el caso de cades detached debería añadir una versión, al igual que hace con los otros tipos de documentos.
Y para los casos que ya estén en RM y no tengan número de versión, yo devolvería una versión 1.0 dummy, como ya hemos hecho en las otras issues, y así sería "coherente" a nivel de bus y a nivel de plugin de arxiu.
Si queréis, lo hablamos.
Hemos subido al control de versiones un cambio que soluciona este problema, ahora siempre devuelve el listado del nodo actual, con la versión "1.0" y la fecha de creación en el site del RM. Lo hemos desplegado ya en DES y probado:
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ws="http://www.caib.es/gdib/repository/ws">
<soapenv:Header/>
<soapenv:Body>
<ws:getNodeVersionList>
<!--Optional:-->
<ws:nodeId>9ec827ab-2be1-4cc9-bd33-68c58537fe26</ws:nodeId>
<!--Optional:-->
<ws:gdibHeader>
<ws:gdibAudit>
<ws:applicant>
<ws:document>123456789Z</ws:document>
<ws:name>Manuel P[0xc3][0xa9]rez</ws:name>
</ws:applicant>
<ws:application>PINBAL</ws:application>
<ws:esbOperation>createFile</ws:esbOperation>
<ws:fileUid>Proc. Subvenciones empleo</ws:fileUid>
</ws:gdibAudit>
<ws:gdibRestriction>
<ws:types>eni:documento</ws:types>
</ws:gdibRestriction>
<ws:gdibSecurity>
<ws:user>gdibadmin5</ws:user>
<ws:password>inetum</ws:password>
</ws:gdibSecurity>
</ws:gdibHeader>
</ws:getNodeVersionList>
</soapenv:Body>
</soapenv:Envelope>
<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
<S:Body>
<ns2:getNodeVersionListResponse xmlns:ns2="http://www.caib.es/gdib/repository/ws">
<ns2:result>
<ns2:id>1.0</ns2:id>
<ns2:date>2023-03-03T10:53:52.515+01:00</ns2:date>
</ns2:result>
</ns2:getNodeVersionListResponse>
</S:Body>
</S:Envelope>
Además, hemos cambiado un método que estaba deprecado en el código ("version.getCreatedDate()" por "version.getFrozenModifiedDate()") que mostraba la fecha de una versión de un nodo determinado:
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ws="http://www.caib.es/gdib/repository/ws">
<soapenv:Header/>
<soapenv:Body>
<ws:getNodeVersionList>
<!--Optional:-->
<ws:nodeId>1573f880-afdd-429f-9c03-3230e255e89c</ws:nodeId>
<!--Optional:-->
<ws:gdibHeader>
<ws:gdibAudit>
<ws:applicant>
<ws:document>123456789Z</ws:document>
<ws:name>Manuel P[0xc3][0xa9]rez</ws:name>
</ws:applicant>
<ws:application>PINBAL</ws:application>
<ws:esbOperation>createFile</ws:esbOperation>
<ws:fileUid>Proc. Subvenciones empleo</ws:fileUid>
</ws:gdibAudit>
<ws:gdibRestriction>
<ws:types>eni:documento</ws:types>
</ws:gdibRestriction>
<ws:gdibSecurity>
<ws:user>gdibadmin5</ws:user>
<ws:password>inetum</ws:password>
</ws:gdibSecurity>
</ws:gdibHeader>
</ws:getNodeVersionList>
</soapenv:Body>
</soapenv:Envelope>
<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
<S:Body>
<ns2:getNodeVersionListResponse xmlns:ns2="http://www.caib.es/gdib/repository/ws">
<ns2:result>
<ns2:id>1.3</ns2:id>
<ns2:date>2023-03-06T17:44:01.118+01:00</ns2:date>
</ns2:result>
<ns2:result>
<ns2:id>1.2</ns2:id>
<ns2:date>2023-03-06T17:43:58.260+01:00</ns2:date>
</ns2:result>
<ns2:result>
<ns2:id>1.1</ns2:id>
<ns2:date>2023-03-06T17:43:56.087+01:00</ns2:date>
</ns2:result>
<ns2:result>
<ns2:id>1.0</ns2:id>
<ns2:date>2023-03-06T17:43:53.716+01:00</ns2:date>
</ns2:result>
</ns2:getNodeVersionListResponse>
</S:Body>
</S:Envelope>
También hemos probado ahora el ArxiuCaibClient y ahora sale correctamente la traza del detalle del documento:
-- detallsDocument --
0 [main] DEBUG es.caib.plugins.arxiu.caib.ArxiuCaibClient - Enviant petici¾ HTTP a l'arxiu (url=https://esbdes3.caib.es:4430/esb/services/getDocVersionList, tipus=application/json )
2354 [main] DEBUG es.caib.plugins.arxiu.caib.ArxiuCaibClient - Rebuda resposta HTTP de l'arxiu (status=200)
2380 [main] DEBUG es.caib.plugins.arxiu.caib.ArxiuCaibClient - Enviant petici¾ HTTP a l'arxiu (url=https://esbdes3.caib.es:4430/esb/services/getDocument, tipus=application/json )
5748 [main] DEBUG es.caib.plugins.arxiu.caib.ArxiuCaibClient - Rebuda resposta HTTP de l'arxiu (status=200)
nodeId: 9ec827ab-2be1-4cc9-bd33-68c58537fe26
Firma tipus: TF04 (Firma perfil: T)
csv: 5148cfea0f3fa319731d5c3fae189033eeefacde54ad5e076e84218213d3ede7
tipusDocument: definitiu
Metadades: es.caib.plugins.arxiu.api.DocumentMetadades@5f7b97da[identificador=ES_A04013511_2023_kqq15h1vkvkftp3jerp7d0ii106568,versioNti=http://administracionelectronica.gob.es/ENI/XSD/v1.0/documento-e,origen=1,organs=[A04013511],dataCaptura=Fri Mar 03 10:53:50 CET 2023,estatElaboracio=EE01,tipusDocumental=TD10,format=PDF,extensio=.pdf,identificadorOrigen=<null>,metadadesAddicionals={eni:estado_archivo=Ingresado, eni:tipo_valor=Administrativo, eni:documento_vital=false, eni:codigo_causa_limitacion=D, eni:perfil_firma=T, eni:lopd=Basico, eni:plazo=100, eni:tipo_dictamen=EP, eni:tipo_clasificacion=Funcional, eni:valor_secundario=Sin cobertura de calificacion, eni:fecha_fin_exp=2023-03-03T10:53:54.226+01:00, eni:tipoFirma=TF04, eni:tamano_logico=7155, eni:fecha_sellado=1970-01-01T01:00:00.000+01:00, eni:tipo_acceso=Libre, eni:cond_reutilizacion=fdvd, eni:fase_archivo=Archivo historico, eni:categoria=Documento simple, eni:estado_exp=E01, eni:app_tramite_doc=app1, eni:plazo_accion_dictaminada=1, eni:soporte=Digital, eni:normativa=dddd, gdib:mimeType=pdf},serieDocumental=S0002,csv=5148cfea0f3fa319731d5c3fae189033eeefacde54ad5e076e84218213d3ede7,csvDef=<null>,tipusDocumentalAddicional=<null>]
temps => entorn des3, 08/03/2023 10:58:26, detallsDocument, 6297 ms
Probé de consultar un documento de un expediente ya cerrado, y fue bien.
Al consultar las versiones del documento con firma cades detached, una vez cerrado, da error. Parece que es cuando el bus parsea la respuesta recibida desde GDIB. Pero bueno, hay que comprobarlo.