Prueba de concepto: Interoperabilidad Java - MS Access por Benoît Verhaeghe y Julien Morgan de Rivery

Dirigimos este proyecto para determinar la posibilidad de controlar una aplicación de Microsoft Access 2013 (o versiones más recientes) desde un programa Java para permitir su migración.
Hemos establecido un enfoque de dos pasos:

1. Un primer paso para permitir la utilización de la interfaz de programación de aplicaciones (API) del software Access.
2. A continuación, estudiamos la API que nos permite manipular la aplicación Access desde un software Access.

El objetivo final es realizar la concepción de la arquitectura presentada en la figura siguiente (Figura 1) posible.

Ingeniería inversa de DLL

El primer paso fue habilitar el control del software Access desde Java. El principal proyecto que permite controlar la aplicación Microsoft Office es " PDI Apache ". Sin embargo, no es compatible con la aplicación MS Access. El único proyecto que conocemos que permite manipular Access desde fuera es el proyecto de interoperabilidad desarrollado por Microsoft. Pero ha sido desarrollado para el lenguaje de programación C# y no para Java como necesitábamos.
Así, podríamos haber seguido dos vías para controlar el software Access desde Java:

1. Haciendo el vinculante en C# y utilizarlo con Java
2. Hacer la ingeniería inversa de la DLL de Access, el binding C# y reutilizarlos para crear la misma API en Java

Para controlar la aplicación desde Java y acercarse al contexto de migración que ya hemos trabajado (Powerbuilder, VB6, etc.), decidimos trabajar en la ingeniería inversa de la DLL.

La ingeniería inversa de DLL se basa en el uso de una herramienta de exploración de DLL en Windows, y una aplicación existente (TLBCodeGenerator) que genera el código Java para llamar a la DLL de ActiveX.
Para convertir la API C# en Java, seguimos estos pasos:

1. Identificación de la DLL ActiveX en MS Access (MSACC.dll).
2. Extraiga el archivo de definición (.tlb) con "Hacker de recursos". Por defecto, una DLL de ActiveX toma su archivo de definición, pero no lo expone.
3. Utilizar TBLCodeGenerator con el archivo .tlb en la DLL principal de Access: este paso generará código Java con errores en la DLL no incluida en el proyecto Java.
4. Cada error indica la dirección base del registro de Windows donde se encuentra la DLL dependiente. Lo encontramos, gracias a la herramienta de registro de Windows.
5. Vuelva a ejecutar el proceso para cada DLL faltante identificado.
6. Si no falta la DLL, añada la DLL recién migrada al proyecto original como dependencia de Maven.

Así, el acceso a la DLL principal y sus dependencias se han migrado a Java.
Hemos realizado estos pasos manualmente y han sido necesarios cinco tratamientos de DLL para obtener un binding utilizable y compilable. Aunque es concebible automatizar el proceso para proyectos más grandes con más DLL necesarias.

Uso de Java JNI/JNA

Una vez realizada la ingeniería inversa de la DLL para controlar el software MS Access, analizamos la interoperabilidad de la API para extraer el método para manipular una aplicación (El software de Access no es una aplicación de Access. Es un IDE -Entorno de Desarrollo Integrado- para desarrollar aplicaciones de Access).
Definimos diferentes restricciones que hay que resolver para asegurarse de que es posible manipular una aplicación:

1. Lanzar una aplicación
   a. Lanzar una aplicación MS Access desde Java
   b. Lanzar varias veces la misma aplicación MS Access desde la misma aplicación Java
2. Llamar a las funciones de VBA (Virtual Basic for Application)
   a. Lanzar las funciones de VBA sin argumento
   b. Lanzar funciones de VBA con argumentos simples (int, boolean, ...)
   c. Lanzar funciones de VBA con argumentos complejos (Tipo definido por el usuario)
   d. Lanzar la clase de funciones VBA

Para descubrir el funcionamiento de la API, nos hemos basado en la documentación de Microsoft para C# y Acceda a. A pesar de algunas diferencias, nos ayudó a manipular más fácilmente la versión Java de ingeniería inversa.
A continuación se presenta el uso técnico de nuestra encuadernación después de su instalación.

Iniciar una aplicación (y detenerla)

La apertura de una aplicación requiere tres pasos:
1. Inicialización de la comunicación con el protocolo COM a través del archivo de definición STDOLE2.tbl

2. Creación de una instancia de aplicación

3. Abrir la base de datos

Una vez realizados estos pasos, es posible lanzar las funciones de VBA. (Nota: cuando se lanzan varias aplicaciones juntas, éstas trabajan en espacios de memoria diferentes para evitar cualquier conflicto de acceso a variables entre ellas)

Para detener la aplicación, hay que ejecutar diferentes acciones para evitar la aparición de procesos "zombis" en Windows.

Iniciar las funciones de VBA

Hoy en día, lanzamos una parte de las funciones de VBA. Tratamos las funciones de VBA sin argumentos y con argumentos simples. En ambos casos, las funciones de VBA deben ser públicas (si una función es privada, puede convertirse fácilmente en pública añadiendo el modificador Público antes del nombre de la función).
Entonces es posible llamar a un método utilizando la API de Java con el método "Run".

El método tiene en cuenta el nombre de la función llamada y sus parámetros.

En resumen

Proponemos un enfoque y una herramienta para manipular las aplicaciones de Microsoft Access de acuerdo con las siguientes restricciones:

1. Las DLL de MS Access deben estar instaladas en el sistema de la herramienta utilizada
2. La versión de MS Access debe ser la 2013 o más reciente
3. Los puntos de entrada de la aplicación Access deben representarse como métodos públicos VBA

Posibilidades futuras

Hay varias posibilidades de continuar este proyecto:

1. Finalizar el trabajo de la función de llamada incluyendo el tratamiento de las clases VBA y el tratamiento de la función utilizando argumentos complejos.
2. POC en una aplicación pequeña o en una aplicación más importante claramente separada del resto de la aplicación.
3. Estudiar la posible implementación de nuestro enfoque en dockers (u otro sistema de implementación) en el que la DLL puede colocarse de forma diferente o no estar.
4. Hoy en día utilizamos archivos de MS Access no compilados (.accdb), tendremos que asegurarnos de que podemos utilizarlos en la implementación.
5. Para finalizar el proyecto, tenemos que procesar al control de la aplicación y no al control del software de Access. Debería ser posible procesarlo manualmente a partir de nuestro trabajo, pero la creación de un proceso semiautomatizado de la aplicación Java (Figura 1) sería un valor añadido al trabajo de migración de la interoperabilidad. Una vía a seguir es trabajar sobre las herramientas ya desarrolladas en el DRIT sobre el estudio de la aplicación MS Access (Santiago Bragagnolo, candidato a doctor en el DRIT, está trabajando en ello por su tesis).

Recursos

GitLab: https://gitlab.forge.berger-levrault.com/bl-drit/bl-avenir
Léame de GitLab: https://gitlab.forge.berger-levrault.com/bl-drit/bl-avenir/access-java-interop/msaccdll