Integration mit dynamischen Clients

Question

Ich habe eine architektonische Frage. Unser Unternehmen hat kürzlich ein COTS (.NET basiertes Produkt) für das Case Management eingeführt. Dieses Produkt verfügt über ein ausgeklügeltes Integrationsmodul, das bei jeder Benutzeraktion eine vollständige XML-Fallinformation an einen MQ ausgibt. Jedes XML-Element hat ein Hinzufügen, Bearbeiten & Löschen Sie Flags, um zu wissen, welches Element geändert wurde.

Wir müssen eine Anwendung schreiben, die diese Ereignisse der Reihe nach verarbeitet und an mehrere externe Partner unter bestimmten Bedingungen sendet. Die Schnittstelle zu jedem externen Partner unterscheidet sich hinsichtlich der benötigten Daten, Repräsentationen (XML, String, JSON, usw.) und Protokollen (SOAP, REST, MQ, DB-Aufruf usw.).

Irgendwelche Vorschläge, wie jemand solch ein System entwerfen könnte und welche Technologien verwendet werden könnten? (FYI, unser vorhandener Technologie-Stack Java/JEE, Weblogic).

PS. Das Hauptproblem, das ich damit hatte, ist, wenn einer der Partner nicht da ist, sollten wir andere Partner nicht zurückhalten. Gleichzeitig sollte kein Partner eine einzige Benachrichtigung verlieren.

Vielen Dank.

Answer 1

Ein möglicher Ansatz:

• COTS stellen Nachrichten über Anwendungsereignisse in die Message Queue.
• Eine Nachrichtengeneratorkomponente überwacht die Nachrichtenwarteschlange und fragt eine Partner-DB nach derzeit bekannten Partnern. Für jede COTS-Nachricht wird für jeden Partner eine Ereignisnachricht generiert, die darüber informiert, was passiert ist. Das Ereignis wird auch eine "Geliefert" -Flagge haben. Sie transformieren also die Nachrichtenwarteschlange, die von COTS gefüllt wird, in N Nachrichtenwarteschlangen, eine für jeden Partner. Ihre Ereignisse sollten unveränderliche Objekte sein, Sie könnten sie in einem relationalen DB oder NoSQL DB ("Message DB" im Bild) speichern.
• Sie haben N oder weniger Endpunktkomponenten, die auf dem Anwendungsserver ausgeführt werden. Wenn sie eine Anfrage erhalten, werden sie eine gemeinsame Komponente ("Common Data Retrieval Concerns" im Bild) nach neuen Nachrichten fragen. Die allgemeine Komponente fragt die Nachrichten-DB ab, übergibt Nachrichten als Java-Objektliste und die Endpunktkomponente kümmert sich um die Serialisierung. Die gemeinsame Komponente könnte sich auch um die Autorisierung kümmern, indem sie Informationen aus der Partner-DB verwendet.

Achtung: Die gemeinsame Komponente sollte nur Flag-Nachrichten als veröffentlicht, wenn sie wurden erfolgreich übermittelt. Eventuell möchten Sie auf eine Bestätigung von einer Partnerkomponente warten. Da Sie während dieses Vorgangs keine transaktionale Transaktion garantieren können, müssen Ihre Partnerclients robust gegen Duplikate sein. Ihre Server-Software sowie jeder Kunde sollte eine Nachrichten-ID (UUID) für jedes Ereignis verwalten:

• Ihre Aufgabe ist es zu erzeugen, eine eindeutige ID pro Ereignismeldung

• Der Auftrag Ihrer Pflege partners pflegt eine Nachschlagetabelle, um zu prüfen, ob sie bereits ein evenet mit einer bestimmten ID verarbeitet haben.