La première intégration des solutions de détaxe & paiement de Global Refund (qui a changé de nom par la suite en Global Blue) commence en avril 2008, lorsque j'ai repris le projet v1 développé par MxData, mon principal client distributeur de Retail PRO. Ceux-ci n'avaient plus les compétences en interne pour poursuivre le développement de plugins RP, et avaient déjà pris l'habitude de me sous-traiter tous leurs projets de ce type.
Initialement il s'agissait d'une dll qui gérait l'intégralité de la détaxe, intégrée dans RP8. La dernière version de la solution (v3.3), pour Retail Pro 9, est d'une technologie complêtement différente car il faut alors intégrer le dialogue avec un middleware Java qui fournit les services de détaxe et de paiement électronique. La dernière livraison date de novembre 2015, le support étant encore intense en 2016.
8 années de dur labeur, qui ont vu s'enchainer les versions de dll, de middleware, de Retail Pro, et in-fine de plugin. Pendant toute cette période, j'avais carte blanche pour choisir l'architecture, le design et le paramétrage de l'intégration, tant que je répondais aux besoins successifs. J'avais la pleine responsabilité de la gestion du code et ses versions, de la documentation technique, et du support/maintenance de dernier niveau en production. Au départ donc, j'ai du porter la solution v1 de RP8 vers RP9, qui changait donc radicalement d'API d'intégration, et de version de Delphi (10 ans séparent les deux environnements), tout en conservant l'interface utilisateur et le dialogue avec la solution de détaxe.
Ensuite, il a fallu intégrer la solution de paiement dans le plugin RP8 et RP9, qui passait par le dialogue TCP/IP avec le middleware. Ce fut la V2, très riche en versions (dernière mouture v2.8.2 de novembre 2014). Assez rapidement la V2 a intégré la gestion du TFS par le middleware, qui pouvait donc fonctionner avec la même interface utilisateur sur deux solutions radicalement différentes (dll locale vs serveur centralisé), ou hybride (TFS local + Paiement via middleware). La complexité du paramétrage a vite explosé, historiquement basé sur des fichiers .INI hérités de la v1.
Les difficultés fonctionnelles n'avaient cependant rien à voir avec les difficultés techniques liés à la nécessité d'avoir un code commun entre les deux plugins pour RP8 et RP9. Mon expérience du développement Cross-Plateform m'a bien aidé à découper l'application en modules communs et modules spécifiques (à API commune), notemment concernant l'accès aux données de RP 8 & 9 en créant une couche d'abstration. .
Cela ne suffisait pas cependant, il y avait trop d'age entre les deux IDE, et le basculement d'un environnement à l'autre générait des upgrade de code automatique d'un côté, et des plaintes concernant des éléments inconnus de l'autre. J'ai donc du faire un petit programme qui modifie le code entre les deux environnements, et surtout les resources de design d'écran, afin de lisser les différences à ce niveau.
Un autre moyen d'assurer une compatibilité et un comportement commun était la création de bibliothèques utilitaires riches et compilées dans les deux environnements. Ainsi, la gestion des logs hiérachiques et son application LogViewer, formidable outil en support/production car il permettait en un coup d'oeil de déceler une erreur (codée en rouge) et remonter jusqu'à sa cause.
Au niveau fonctionnel, on notera l'utilisation d'un moteur d'impression sur tickets (pour le paiement et le bordereau de détaxe), dérivé de notre système Ticket-Marketing (intégré dans la bibliothèque commune), qui permettait de s'adapter efficacement à tout types de matériels, tout en exploitant les capacités graphiques, ce que personne ne faisait dans le cadre d'une application de caisse aussi vastement déployée (les drivers Windows étant souvent trop lents et misérables pour la mise en page sur 512 pixels de large).

La dernière phase de ce projet fut d'intégrer la dernière version du middleware d'interface Tax Refund & Paiement dans RP9, qui changeait notemment de protocole. Il fallait donc recommencer à zéro, et on abandonnait le support de toute autre solution (la dll). On abandonnait aussi le support RP8, ce qui me permettait de passer intégralement sous Delphi XE sans avoir à me soucier de rétro-compatibilité du code avec une très ancienne version de Delphi.
Fort de l'expérience précédente, et notemment de la complexité du paramétrage et déploiement de la solution, j'ai décidé de tout passer en base de données, et d'utiliser en interne un paramétrage arborescent en XML.
Ce paramétrage gère aussi une notion d'héritage sur 3 niveaux : Défaut, Magasin, Caisse. Chaque noeud et feuille peut hériter sa valeur du niveau précédent, ou redéfinir la valeur pour ce niveau. On peut passer d'un niveau à l'autre pour afficher l'arbre de paramètre correspondant et ainsi bien voir ce qu'il y a à chaque niveau. Une couleur différente du texte indique clairement si ce paramètre est défini ici ou hérité (ou invalide).
L'arborescence même, les valeurs par défaut, et les niveaux acceptés pour modifier ces paramètres (par exemple les paramètres d'imprimantes ne peuvent être définis qu'au niveau Caisse) sont définis par un fichier XML livré avec la solution. C'est le seul endroit hors DB où se trouvent des données de paramétrage. En principe jamais modifié, il permet de rajouter facilement des options d'une version à l'autre sans que le plugin s'affole avec les données précédentes en base, ou même faire cohabiter plusieurs versions sur le même serveur, les version anciennes seront alors capables d'ignorer les paramètres qui ne les concernent pas et de ne pas les afficher. Egalement, pour certains déploiements, il est possible de cacher certaines options.
Hormis ce paramétrage arborescent, hérité, et définit dynamiquement, le plugin gère un grand nombre de tables de paramètres, dont le contenu est envoyé par le serveur TFS de GB. C'est la partie 'Automatic Configuration', que le plugin vérifie régulièrement pour faire face par exemple à des changements de réglementation pour le pays concerné.
Enfin, le plugin gère un certain nombre de tables pour tracer tout ce qui se passe concernant la solution de détaxe ou de paiement. Chaque message envoyé et reçu au serveur GB est stocké avec un ID interne d'opération, et les logs hiérarchiques du traitement sont liés à cette opération. De même que les données de la transaction finale. Il y a donc un contrôle total sur ce qui se passe dans le système.
Ceci n'est qu'un aperçu des caractéristiques techniques nouvelles employées par ce plugin. Pour un détail de ses fonctionalités, architecture et interface, un bon document (qui plus est très illustré) est mieux qu'un long discours. Voici 67 pages de doc technique en anglais.

Documentation Technique - GB RP9 Plugin v3