Nous avons mené ce projet pour déterminer la possibilité de contrôler une application Microsoft Access 2013 (ou des versions plus récentes) à partir d'un programme Java pour permettre sa migration.
Nous avons mis en place une approche en deux étapes :
- Une première étape pour permettre l'utilisation de l'interface de programmation d'applications (API) du logiciel Access.
- Ensuite, nous avons étudié l'API qui nous permet de manipuler l'application Access depuis un logiciel Access.
L'objectif final est de réaliser la conception de l'architecture présentée dans la figure ci-dessous. (Figure 1) possible.
Ingénierie inverse des DLL
La première étape a consisté à activer le contrôle du logiciel Access à partir de Java.. Le principal projet permettant de contrôler l'application Microsoft Office est " POI Apache ". Cependant, il ne supporte pas l'application MS Access. Le seul projet que nous connaissons permettant de manipuler Access depuis l'extérieur est le projet d'interopérabilité développé par Microsoft. Mais il a été développé pour le langage de programmation C# et non pour Java comme nous en avions besoin.
Ainsi, nous aurions pu suivre deux voies pour contrôler le logiciel d'accès à partir de Java :
- Faire le liaison en C# et l'utiliser avec Java
- Effectuer le reverse engineering de la DLL d'Access, la liaison C# et les réutiliser pour créer la même API en Java.
Pour contrôler l'application depuis Java et se rapprocher du contexte de migration sur lequel nous avons déjà travaillé (Powerbuilder, VB6, etc.), nous avons décidé de travailler sur le reverse engineering de la DLL.
La rétro-ingénierie des DLL est basée sur l'utilisation d'un outil d'exploration des DLL sous Windows, et d'une application existante (TLBCodeGenerator) générant le code Java pour appeler la DLL ActiveX.
Pour convertir l'API C# en Java, nous avons suivi ces étapes :
- Identification de la DLL ActiveX sur MS Access (MSACC.dll).
- Extraire le fichier de définition (.tlb) avec "Pirate des ressourcesOutil ". Par défaut, une DLL ActiveX prend son fichier de définition, mais elle ne l'expose pas.
- Utilisation de TBLCodeGenerator avec le fichier .tlb sur la DLL principale d'Access : cette étape générera du code Java avec des erreurs dans la DLL non incluse dans le projet Java.
- Chaque erreur indique l'adresse de base du registre Windows où se trouve la DLL dépendante. Nous la trouvons, grâce à l'outil de registre Windows.
- Relancez le processus pour chaque DLL manquante identifiée.
- S'il n'y a pas de DLL manquante, ajoutez la DLL nouvellement migrée au projet original comme dépendance Maven.
Ainsi, l'accès principal à la DLL et ses dépendances ont été migrés vers Java.
Nous avons parcouru ces étapes manuellement et cinq traitements de DLL ont été nécessaires pour obtenir une liaison utilisable et compilable. Bien qu'il soit concevable d'automatiser le processus pour les plus gros projets avec plus de DLL nécessaires.
Utilisation de Java JNI/JNA
Une fois que le reverse engineering de la DLL pour contrôler le logiciel MS Access a été fait, nous avons analysé l'interopérabilité des API pour extraire la méthode permettant de manipuler une application (Le logiciel Access n'est pas une application Access. C'est un IDE - Integrated Development Environment - pour développer une application Access).
Nous avons défini différentes contraintes à résoudre pour s'assurer qu'il est possible de manipuler une application :
- Lancer une application
a. Lancez une application MS Access à partir de Java
b. Lancer plusieurs fois la même application MS Access à partir de la même application Java - Appeler les fonctions de VBA (Virtual Basic for Application)
a. Lancer les fonctions de VBA sans argument
b. Lancer les fonctions de VBA avec des arguments simples (int, booléen, ...)
c. Lancer les fonctions de VBA avec des arguments complexes (Type défini par l'utilisateur)
d. Lancer la classe de fonctions VBA
Pour découvrir le fonctionnement de l'API, nous avons basé nos recherches sur la documentation Microsoft pour C# et Accès. Malgré quelques différences, il nous a permis de manipuler plus facilement la version Java obtenue par rétro-ingénierie.
Ce qui suit présente l'utilisation technique de notre fixation après son installation.
Lancer une application (et l'arrêter)
L'ouverture d'une application se fait en trois étapes :
1. Initialisation de la communication avec le protocole COM par le biais du fichier de définition STDOLE2.tbl
2. Création d'une instance d'application
3. Ouverture de la base de données
Une fois ces étapes franchies, il est possible de lancer les fonctions de VBA. (Note : lorsque plusieurs applications sont lancées ensemble, elles travaillent sur des espaces mémoire différents afin d'éviter tout conflit d'accès aux variables entre elles).
Pour arrêter l'application, différentes actions doivent être exécutées pour éviter l'apparition de processus "zombies" dans Windows.
Lancer les fonctions de VBA
De nos jours, nous avons lancé une partie des fonctions de VBA. Nous avons traité les fonctions de VBA sans arguments et avec des arguments simples. Dans les deux cas, les fonctions de VBA doivent être publiques (si une fonction est privée, elle peut facilement être convertie en fonction publique en ajoutant le modificateur Public avant le nom de la fonction).
Il est ensuite possible d'appeler une méthode en utilisant l'API de Java avec la méthode "Run".
La méthode prend en compte le nom de la fonction appelée et ses paramètres.
Pour résumer
Nous proposons une approche et un outil pour manipuler les applications Microsoft Access selon les contraintes suivantes :
- Les DLL de MS Access doivent être installées sur le système de l'outil d'utilisation.
- La version de MS Access doit être la version 2013 ou une version plus récente.
- Les points d'entrée de l'application Access doivent être représentés comme des méthodes publiques VBA
Possibilités futures
Il existe plusieurs possibilités pour poursuivre ce projet :
- Finalisez le travail sur les fonctions d'appel en incluant le traitement des classes VBA et le traitement des fonctions utilisant des arguments complexes.
- POC sur une petite application ou une application plus importante clairement séparée du reste de l'application.
- Étudier l'implémentation possible de notre approche sur des dockers (ou autre système d'implémentation) dans lesquels les DLL peuvent être placées différemment ou être absentes.
- De nos jours, nous utilisons des fichiers MS Access non compilés (.accdb), nous devrons nous assurer que nous pouvons les utiliser lors de l'implémentation.
- Pour finaliser le projet, nous devons traiter le contrôle de l'application et non le contrôle du logiciel d'accès. Il devrait être possible de le traiter manuellement à partir de notre travail mais la création d'un processus semi-automatisé d'application Java (Figure 1) serait une valeur ajoutée au travail de migration de l'interopérabilité. Une piste à suivre est de travailler sur les outils déjà développés au DRIT sur l'étude des applications MS Access (Santiago Bragagnolo, doctorant au DRIT, y travaille par sa thèse).
Ressources
GitLab : https://gitlab.forge.berger-levrault.com/bl-drit/bl-avenir
Readme de GitLab : https://gitlab.forge.berger-levrault.com/bl-drit/bl-avenir/access-java-interop/msaccdll
