Intégration avec des clients dynamiques

Question

J'ai une question de conception architecturale. Notre société a récemment apporté un COTS (produit basé sur .NET) pour la gestion de cas. Ce produit dispose d'un module d'intégration sophistiqué qui crache une information XML complète sur une MQ à chaque action de l'utilisateur. Chaque élément XML possède un Add, Edit & Delete flags pour savoir quel élément a été modifié.

Nous devons écrire une application qui traite ces événements séquentiellement à mesure qu'ils arrivent et les envoie à plusieurs partenaires externes conditionnellement à ce qui a changé. L'interface avec chaque partenaire externe est distincte en termes de données dont ils ont besoin, de représentations (XML, String, json, etc.) et de protocoles (SOAP, REST, MQ, DB-call, etc.).

Des suggestions sur la façon dont quelqu'un pourrait concevoir un système comme celui-ci et quelles technologies peuvent être utilisées? (FYI, notre pile technologique existante Java/JEE, Weblogic).

PS. Le principal problème que j'ai eu avec ceci est que si l'un des partenaires est en panne, nous ne devrions pas nous en tenir à d'autres partenaires. En même temps, aucun partenaire ne devrait perdre une seule notification.

Merci.

Answer 1

Une approche possible:

• COTS a mis des messages sur les événements d'application dans le Message Queue.
• Un composant de générateur de messages écoute la file d'attente de messages et interroge un DB partenaire sur les partenaires actuellement connus. Pour chaque message COTS, un message d'événement sera généré pour chaque partenaire informant de ce qui s'est passé. L'événement aura également un drapeau "livré". Donc, fondamentalement, vous transformez la file d'attente de messages remplie par COTS en N files d'attente de messages, une pour chaque partenaire. Vos événements doivent être des objets immuables, vous pouvez les stocker dans un DB relationnel ou une base de données NoSQL ("Message DB" dans l'image).
• Vous avez au moins N composants de point de terminaison qui s'exécutent sur votre serveur d'applications. Quand ils arrivent une demande, ils vont demander un composant commun ("Common Data Retrieval Concerns" dans l'image) pour les nouveaux messages. Le composant commun interroge le DB de message, transmet les messages en tant que liste d'objets java et le composant de noeud final se soucie de la sérialisation. Le composant commun peut également se préoccuper de l'autorisation, en utilisant les informations de la base de données partenaire.

Attention: La composante commune devrait uniquement les messages de drapeau tel que publié, si elles ont été livrées avec succès. Vous pourriez vouloir attendre un accusé de réception provenant d'un composant partenaire. Comme vous ne pouvez pas garantir une atomicité transactionnelle au cours de ce processus, vos clients partenaires doivent être robustes contre les doublons. Votre logiciel de serveur, ainsi que chaque client doit gérer pour chaque événement un ID de message (UUID):

• Votre travail consiste à se soucier de générer un identifiant unique par message d'événement

• Le travail de votre Les partenaires maintiennent une table de recherche pour vérifier s'ils ont déjà traité un evenet avec un certain ID.