Construire des interfaces n'est pas une activité facile. Respecter les quelques règles suivantes peut vous aider a éviterons beaucoup de déboires ensuite.

1. Privilégier le mode Delta au mode Full. En effet, dans un soucis de réduction des volumes de données. il est toujours préférable de n'envoyer que les données créées ou modifiées depuis la dernière exécution. En revanche, préférez renvoyer la donnée complète et non le delta du delta (seulement les champs modifiés). si toutefois, vous souhaitez n'envoyer que le delta des champs modifiés, prenez bien en compte qu'en cas de crash de l'interface, il sera nécessaire de réintégrer toutes les modifications dans le bon ordre, sous peine d'incohérences entre l'image actuelle et la réplication dans le système cible

2. Prévoir un mode test. Ce n'est pas obligatoire, mais croyez moi que cela vous fera gagner du temps lors des tests unitaires.

3. TOUJOURS prévoir un écran de lancement de l'interface permettant de modifier simplement certains paramètres

4. TOUJOURS prévoir un bon niveau de détail et de logs d'éxécution. Vous y gagnerez en temps lors d'analyses ultérieurs en cas de problémes. J'ai eu l'occasion de reprendre des interfaces où le seul détail fourni était "interface exécutée avec succès", ce qui oblige d'une part à débugger l'interface mais aussi à parcourir tous les idocs ou fichiers générés pour savoir si lors de l'exécution de l'interface, votre article ou votre commande a été envoyée. De la même façon, il est utile de rappeler dans le log d'exécution la valeur des paramètres de lancement.

5. TOUJOURS prévoir un mode manuel. Vous ne pouvez jamais être certains que votre interface ne va pas planter en raison d'une erreur de code ou d'un mauvais format de données. Il est essentiel d'avoir la main pour pouvoir relancer l'interface, voire être aussi capable d'utiliser l'interface pour initialiser des données vers le partenaire.

6. Privilégier l'utilisation d'un middleware, surtout dans un mode distribué ou les applications n'utilisent pas les memes technologies (ex : idoc et injection SQL)

7. Il n'y a pas de meilleur technologie meilleure qu'une autre. En revanche, il est important de veiller à construire une solution cohérente. Evitez donc à  tout prix, d'avoir pour un même partenaire, une interface flat file pour une donnée, un webservice pour une autre et de l'idoc pour une troisième. C'est juste l'enfer assuré, sans parler des problèmes de connaissances / compétences que vous allez devoir gérer.