Problématiques des interfaces entre applications

Ce blog est destiné à traiter de sujets de modélisation, et plus particulièrement de la modélisation de systèmes d’information complexes. Nous commencerons par traiter d’un sujet au coeur de la décomposition de systèmes informatiques complexes : les interfaces.

La première définition que nous pouvons donner est la suivante « Limite commune à deux systèmes, permettant des échanges entre ceux-ci » (Larousse). Cette définition précise qu’il s’agit donc d’éléments communs à deux applications qui permettent des échanges, dans notre cas, principalement d’informations ou de demande d’exécution d’ordre.

Nous limiterons ce billet aux interfaces d’échanges d’information, en opposition aux interfaces d’interrogation (par exemple via des web-services) et aux diffusion large de type publish-and-subscribe.

Les éléments constitutifs d’une interface

Au delà de la définition théorique d’une interface entre deux applications, il nous faut définir sa décomposition en éléments identifiables qui porteront les exigences, et qui auront des représentations physiques tout au long de la vie de l’interface : spécifications, programmes de traitements, fichiers de données.

Un premier niveau d’analyse logique d’une interface dans le contexte d’un SI se focalise principalement sur les données qui y transitent, sur ses dépendances, en terme de données de référentiel ou d’autres données transitant dans des interfaces, ainsi que sur les éléments déclencheurs : critère horaire, déclenchement à la demande d’un utilisateur ou sur l’apparition d’un évènement interne à l’application ou externe.

Au niveau technique, une interface peut se décomposer suivant les éléments suivants :

  • Un ou plusieurs traitements d’extraction qui permettent de transformer les données d’un format propre à l’application émettrice dans un format intelligible
  • Un ou plusieurs mécanismes de transport. Ceux-ci ne modifient pas les données mais sont chargés de déplacer physiquement les données d’une machine (serveur, poste utilisateur …) à un autre.
  • Un ou plusieurs traitements intermédiaire qui sont chargés de transformer le format émit par l’application source dans un format compatible avec les traitements de chargement de l’application destinataire.
  • Des données transportées d’une application à une autre, matérialisées par un format (schéma XML, description de champs pour un fichier plat …)
  • Un ou plusieurs traitements de chargement qui ont pour rôle de charger les données émises afin que les traitements propres à la logique de l’application destinataire puisse les utiliser.

Cette décomposition est évidemment maximaliste et vise à décrire les cas les plus complexes. Nous verrons plus tard les intérêts et les problèmes posés par la mise en place de pivots, mais la mise en place de traitements intermédiaire n’a de sens que dans un tel cas.

Les données de référentiel

Les données de référentiel sont les données auxquels font référence les objets transportés dans une interface. Elles ont en général une durée de vie plus longue et une fréquence de mise à jour plus faible que les données de transaction.

D’un certain point de vue, les données de référentiel sont des données comme les autres et font l’objet d’interface entre les applications maîtresses de leurs mises à jour et les applications qui les utilisent. Cependant, ces données ont un rôle important puisque c’est sur celles-ci que reposent les données de transaction qui portent les informations opérationnelles : factures, écritures comptables, commande d’achat … Cette importance se traduit dans une question qui revient souvent lors de la conception d’interfaces dans un système d’information : doit-on faire transiter les données de référentiel avec les données de transaction ou faire des interfaces séparées ?

Les données de référentiel utilisées par une interface doivent en général faire l’objet d’interfaces à part pour plusieurs raisons :

  • Le cycle de vie des interfaces de référentiel et de transaction n’est pas le même
  • Les interfaces de référentiel sont en général de bons candidats à la réutilisation, surcharger ces interfaces avec des données spécifiques à certaines applications peut nuire à cette réutilisation en augmentant la complexité de l’interface
  • La séparation de ces flux facilite une mise en oeuvre ultérieure d’une concentration des données référentielles dans une application dédiée à leur gestion.

Cependant, certaines situations rendent la séparation en différentes interfaces trop complexe ou coûteuse pour l’intérêt que cela représente :

  • Des interfaces particulièrement simples : le format et les traitements utilisés sont simples et stables. Par exemple, créer une interface supplémentaire uniquement pour transférer les libellés d’objets n’est pas nécessairement judicieux.
  • Un référentiel très lourd dont peu d’objets sont utilisés et qui ne sont pas identifiables à priori.
  • Des besoins de fraîcheur de données très importants : les données de référentiel sont très souvent modifiées et que l’utilisation des données les plus fraîches est indispensable (problèmes en cas de désynchronisation des applications)
  • Un référentiel pauvre ne gérant pas les données à date pour permettre leur accrochage avec les données de transaction.

Ces cas peuvent amener à charger des données de référentiel dans des interfaces initialement prévues pour transférer des transactions. Chaque référence faite par celles-ci est alors remplacées dans le format d’extraction par les informations utiles à l’application cible.

La réutilisation des interfaces : les formats pivots

Lors qu’il est question d’interfaces dans un SI, le terme de format pivot est une question centrale. Le principe de fonctionnement est le suivant : pour chaque interface on fait l’effort d’extraire les données dans un format pivot ou de les y transformer et ensuite de le re-transformer dans le format de chargement dans l’application cible ou de l’y charger directement.

La thèse est que la réutilisation permise par ce mode de fonctionnement est supérieure au surcout engendré par la complexité supplémentaire de chaque interface.

Ce mode de fonctionnement ne peut être indépendant des frontières posées entre les applications : les gains engendrés par une réutilisation sont plus importants si une partie des transformations intermédiaires peut être partagée entre les différentes applications.

Le principal piège tient au fait que la description d’un format pivot ne fait pas tout. En effet, en plus de son format, une interface est décrite par ses dépendances externes (référentiels associées, codifications), son mode de fonctionnement (par exemple transfert de toutes les données ou uniquement des données modifiées) et ses conditions de déclenchement. S’il y a besoin de faire la combinaison de toutes ces possibilités, l’interface pensée comme générique devient vite un cas particulier pour chaque application partenaire.

Dans certains cas, la définition et l’usage d’interfaces standards d’intégration (définies par un format et les caractéristiques mentionnées précédemment) des applications présentent des avantages en terme d’efficacité de travail. Par exemple la diffusion de référentiels et les interfaces proposées par une application proposant des services centraux utilisés par différentes applications (par exemple une application comptable qui recueille l’ensemble de les factures afin de les comptabiliser) sont de bons candidats. La mise en place de ces interfaces standards autour d’applications structurantes dans le SI permet ensuite de cadrer l’intégration de nouvelles applications en offrant un certain nombre de points d’entrée partagés.

Nous ne faisons ici qu’effleurer le sujet des formats pivots, dont les intérêts et inconvénients sont souvent mal compris. Nous l’approfondirons donc dans un prochain billet.

La réutilisation des interfaces : les composants techniques

Dans une même optique que le partage des formats, il est envisageable de partager entre les différentes interfaces et différentes applications un certain nombre de composants techniques.

Les éléments les plus évidents à partager sont les middleware : ils sont par définition agnostiques des données qu’ils manipulent et sont souvent structurés afin de pouvoir gérer des contextes et des projets différents. Il s’agit d’outils de transfert de données (transfert de fichier, middleware orienté message …), de traitement (ETL, EAI/ESB, EDI …) ou de stockage des données (Bases de données …) ou d’outils utilisés par les applications en dehors du strict domaine des interfaces comme un ordonnanceur.

En poussant la réflexion, on se rend compte qu’il est possible de partager à l’intérieur de ces outils des éléments : code source, paramétrage … Ceci permet de constituer un framework autour duquel est capitalisé le travail réalisé sur les différentes interfaces. Dans le cas d’un middleware de traitement de données, on peut donner comme exemple des formats de fichier ou des traitements génériques (changement de codification des données, de format techniques ou d’encodage des fichier).

Enfin, certains services annexes sont utiles pour la plupart des applications mais relèvent presque d’une logique applicative, on peut alors imaginer le développement d’un tel outil partagé. Par exemple, la gestion des rejets dans une interface demande des écrans permettant aux utilisateurs de voir des données, éventuellement les corriger voire de relancer l’interface. L’assemblage des différents services partagés peuvent former un véritable service d’intégration, mais ceci sera le sujet d’une prochaine note sur ce blog.

Cette partie technique est aujourd’hui plus mure et permet ainsi d’espérer des gains de productivité plus importants que la mise en place d’une approche fondée sur des formats pivots.

Les frontières de responsabilités entre les applications

La création d’interfaces entre applications demande de définir la propriété de certaines données, ce qui nécessite de délimiter les périmètres de responsabilité des différentes applications. Il est donc important de faire ces attributions avant de mettre en place les interfaces.

Nous partons ici du principe qu’une interface entre deux applications nécessite forcément des modifications sur les informations transportées, que ce soit des changements sur les données elles-même (transcodification …) ou des traitements techniques (changement d’encodage des caractères, de formats de dates …). En effet, la question de l’adaptation ne se pose pas sinon.

La solution par défaut lors de la mise en place d’une nouvelle application est souvent de dire que toutes les adaptations seront réalisées par celle-ci. Cette position vient du fait que la nouvelle application est en cours de projet et que, par conséquent, elle a un budget alloué et des équipes présentes et qu’il est plus simple de gérer les modifications localisées à un seul projet.

Il convient ainsi de prendre plusieurs facteurs en considération :

  • « La norme » : quelle est l’application qui a le comportement le plus spécifique ? Car si une des applications doit s’adapter à l’autre c’est alors celle-ci.
  • Cycle de vie : si une application est en fin de vie, c’est à elle de s’adapter : ces spécificités disparaîtront alors avec son décomissionnement au lieu de perdurer et de constituer un standard de fait au sein de l’entreprise.
  • Capacité d’adaptation : si une application a des contraintes qui l’empêchent de s’adapter (pauvreté des mécanismes d’intégration disponibles, application hébergée en ASP, indisponibilité des équipes, etc.), le travail devra être fait par l’autre application concernée
  • Les besoins de données externes : si les modifications réalisées ont besoin de données appartenant à une des applications alors les adaptations doivent y être faites.
  • Présence de d’interfaces standard (formalisés ou de fait) : si l’interface qui est mise en place correspond à une interface déjà existante avec une autre application alors c’est la nouvelle application qui doit s’adapter.

Les questions et difficultés que nous avons mentionnées sont également présentes dans l’intégration inter-système d’information (client-fournisseur ou SI partenaires) mais sont rendues plus aiguës par la distance introduite entre les équipes et les différences de conception des interfaces (vocabulaire, principes de partage …).

Conclusion

Cette note de sensibilisation nous a permis d’aborder un certain nombre de problématiques rencontrées dans la mise en place d’interfaces entre les différentes applications d’un système d’information classique. Elle laisse volontairement de côté les aspects de techniques et d’urbanisme qui sont des sujets à part entière et qui mériteront des notes de blog dédiées.

Les différents objets mentionnés ainsi que leurs propriétés constituent une première présentation d’un modèle logique des interfaces entre applications.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *