Optimizar construcción de la petición, a Eeutil-Vis-Docexp, de visualización de expediente ENI

[ja-garcia]

Se ha detectado que para la construcción de la llamada al servicio de Eeutil-Vis-Docexp, para la obtención de la visualizacion del índice de expediente ENI en PDF, se recorre el índice del expediente, de manera recursiva, recuperando el nombre natural de cada documento que contiene, pero haciendo una consulta independiente a la base de datos por cada documento. Este comportamiento dispara los tiempos de ejecución de las operaciones de Inside que hacen uso de la visualización del expediente, cuando se trata con expedientes grandes (cientos o miles de documentos). Se propone:

• Optimizar la recuperación de todos los documentos del expediente a visualizar en una sola consulta y que la construcción del objeto que aloja el índice, para invocar a Eeutil-Vis-Docexp (y que se convierte a posteriori en la estructura XML de la petición a la operación de visualización), haga uso del resultado de esta consulta previa global para todo el expediente, en la construccion de la petición.
  • Una vez montada la nueva consulta, podemos agregar, si fuese necesario, un índice de base de datos, para que haga uso del mismo (si no existe ya).
• Una posible solución es sobrecargar el método fillItemWithIndice para llamar a su versión optimizada desde expedienteInsideToItemVisualizacion. La versión sobrecargada podría recibir un objeto adicional, con el resultado de la consulta de todos los documentos del expediente, de la que pueda recuperar los nombres naturales de los documentos sin tener que consultar la base de datos por cada documento, durante el recorrido recursivo que hace de los ítems del expediente.

Para poder activar este comportamiento, vamos a usar una propiedad configurable, de manera que sea posible volver al comportamiento original del código liberado si se desactiva la misma o no se declara en el fichero de propiedades extendidas.

En fichero: file:${config.path}/enhanced_carm.properties Propiedad: eeutils.vis-docexp.exp.optimizar.dml.indice=<true|false>

[josefsabater]

Buenas @ja-garcia

respecto a la descripción de la issue, no nos queda claro que quieres decir en la siguiente frase:

"Una vez montada la nueva consulta, podemos agregar, si fuese necesario, un índice de base de datos, para que haga uso del mismo (si no existe ya)."

Se supone que los índices están ya creados, de hecho es lo que se esta consultando ¿a que te refieres con lo de crear uno nuevo?

[ja-garcia]

Hola @josefsabater. Cuando hablo de la posibilidad de agregar un índice, me refiero a un índice MySQL (no al índice del expediente ENI). Sería para ayudar al ORM (Hibernate en este proyecto) a ejecutar más rápido la nueva consulta que recupera de golpe todos los documentos (o sus nombres naturales) de un expediente ENI concreto (lo más probable es que ya exista ese índice y no haga falta añadirlo, pero no he revisado recientemente el modelo a ese nivel, y por eso lo comento como opción).

[abilionavarro]

Buenas, hemos estado viendo como se podrían consultar los documentos que forman un expediente a través de una SQL. En principio, y conforme esta montado el modelo de datos (estructura de arbol), es necesario recuperar las carpetas, de forma recursiva, para poder consultar los documentos relacionados con cada carpeta, o si la carpeta a su vez esta dentro de otra carpeta o si esta simplemente a nivel de expediente (sin estar dentro de una carpeta).

No se si se ha contemplado la posibilidad de realizar un procedimiento en PL-SQL para realizar esta consulta porque estamos viendo que en un principio con un sql sería bastante compleja, en el caso de que fuese posible realizarla, que tampoco lo tenemos claro dada la complejidad de almacenamiento de los Índices de los expedientes ENI.

[ja-garcia]

Hola @abilionavarro. La eficiencia de la opción del procedimiento almacenado va a depender del número de consultas que se terminen ejecutando (por ejemplo, si necesita ejecutar consulta por cada carpeta del expediente, no ganamos tanto, porque estos expedientes grandes suelen tener multiterceros y una carpeta por cada uno de ellos, que termina resultando en un número elevado de carpetas).

Como la opción que ofrece MySQL para consultas recursivas jerárquicas está disponible a partir de la versión 8 (e Inside está utilizando la 5.7) y además, hay cierta urgencia para poder mejorar la tramitación de este tipo de expedientes, podéis valorar la opción de utilizar dos veces el método fillItemWithIndice, para que haga dos recorridos del expediente cuando opciones.isExterno() es false (que es la opción que está haciendo que se disparen los tiempos de ejecucuión, al tener que hacer una consulta a base de datos por documento):

• El primer recorrido puede servir para obtener los identificadores de todos los documentos del expediente, fijando opciones.isExterno() a true, puesto que este recorrido en Java es muy rápido.
• Con los identificadores de los documentos del expediente, obtenidos en el primer recorrido, se puede hacer la consulta a la base de datos para obtener los nombres naturales de todos los documentos del expediente, ya que MySQL no limita el número de valores de la cláusula IN.

  The number of values in the IN() list is only limited by the max_allowed_packet value.

• El segundo recorrido sería similar al que se hace cuando opciones.isExterno() es true, pero obteniendo el nombre natural de los documentos desde la colección obtenida en el punto anterior, en lugar de hacer una consulta individual por cada uno de los documentos.

[aid35y]

Buenas @ja-garcia

Ya hemos realizado los cambios correspondientes y refactorizado el código. Necesitamos que se despliegue la rama en desarrollo para hacer las pruebas.

En la nueva consulta HQL, hemos tenido que meter los parámetros a fuego ya que a través del método setParameterList no ha funcionado.

Los resultados obtenidos son:

Procedimiento 688 --> Documentos: 33

Resultado: 1s 53ms-- > OPTIMIZADO Resultado: 19s 88ms--> NO OPTIMIZADO

Procedimiento 10171 --> Documentos: 492

Resultado: 2s 27ms-- > OPTIMIZADO Resultado: 3m 53s--> NO OPTIMIZADO

Muchas gracias.

Saludos.

[ja-garcia]

Hola @aid35y, se han desplegado los cambios en desarrollo y pruebas, tras aplicar una buena refactorización a la entrega inicial (incluyendo buena parte de la que ha estado aplicando @josefsabater). La rama que he desplegado, feat/jgl13r/optimizar-peticion-eeutil-vis-expediente-#70, lleva algunas correciones más sobre la refactorización de @josefsabater.

Para los próximos issues, no hay problema en que hagáis el push a la rama del repositorio remoto, pero por favor, que lo valide @josefsabater o quien internamente decidáis, antes de avisarme por el issue de que está para entregar. Gracias.