Schnellstartanleitung für Talend ESB – Teil 3
Immer mehr Organisationen, die nach einer Alternative zu teuren, unzuverlässigen Point-to-Point-Integrationslösungen suchen, entscheiden sich für einen Enterprise Service Bus (ESB). Viele Unternehmen müssen eine große Anzahl von Anwendungen integrieren. Eine Infrastruktur, die auf einem Geflecht aus handcodierten Verbindungen basiert, ist schwer zu verwalten, fehleranfällig und bietet keine einfache Problemlösung, wenn eine Verbindung ausfällt. Ein ESB bietet eine ausgezeichnete Alternative zu diesem Spaghetticode.
Lesen Sie, wie wir unseren Dienst bereitstellen, den Lastenausgleich implementieren und unsere CRM-Integration in SoapUI testen.
In Teil 1 unserer Schnellstartanleitungs-Reihe für Talend ESB:
- haben wir die WSDL in Talend Open Studio for ESB importiert.
- den Dienst erstellt und definiert.
In Teil 2 unserer Schnellstartanleitungs-Reihe für Talend ESB:
- haben wir das XML-Mapping der CRM-Quelldaten aktiviert.
- unsere CRM-Datensätze per String-Bearbeitung in Talend Open Studio zusammengeführt.
In diesem dritten und letzten Teil der Schnellstartanleitungs-Reihe für Talend ESB beschreiben wir die Schritte zum Bereitstellen des Dienstes und implementieren anschließend einen Lastenausgleich mit Apache Camel, um die Sichtbarkeit am Endpunkt zu erhöhen. Auf diese Weise können wir dann einen SOAP-basierten Webdienstanbieter mit vollem Lastenausgleich testen, um die reibungslose Funktion unserer CRM-Integration sicherzustellen.
Tests in SoapUI
Der Dienst steht bereit und kann gestartet werden, um Tests in SoapUI auszuführen, einer Open-Source-Anwendung zum Testen von Webdiensten. Auf dem unten gezeigten Bildschirm können wir Dummy-Endpunkte oder -Dienste zu Testzwecken direkt in Studio aufrufen.
Als Nächstes öffnen wir SoapUI, starten ein neues SOAP-Projekt („New SOAP Project”) und rufen unsere WSDL auf, damit wir uns die Kundenprozesse in dieser Testumgebung ansehen können.
Unser „getCustomer“-Prozess befindet sich unter „Projects“ in SoapUI. Durch einen Klick auf „Request“ können wir einen Blick in den Prozess werfen und sehen unsere Payload für den Prozess. Diese enthält einen einzelnen Parameter, und zwar „custId“.
Dann gehen wir zurück in unsere CSV-Kundendatei mit den ursprünglichen Quellinformationen, anhand derer wir die Integration durchführen, und sehen, dass unsere Kunden-IDs je 10 Ziffern enthalten.
In SoapUI übergeben wir dem Dienst eine gültige 10-Ziffer-Kunden-ID, der Informationen zu Fred Flintstone zurückgibt. Die Antwort enthält den verketteten Namen und alle zugehörigen Details. Zur Überprüfung gehen wir zurück in die ursprüngliche CSV-Datei und sehen, dass die Daten übereinstimmen.
Wir öffnen wieder das Fenster von Talend Open Studio (siehe unten), um den Informationsfluss innerhalb des Dienstes anzuzeigen, der während des Tests stattgefunden hat. Es gab eine Anfrage (Request) und in der zugrunde liegenden Kundenressource waren fünf Kunden. Mit einem dieser Kunden gab es eine Übereinstimmung und wir erhielten eine Standardantwort. Wir sehen also, dass der Dienst bereitgestellt werden kann.
Dienstbereitstellung
Der erste Schritt im Rahmen der Bereitstellung besteht darin, den Dienst aus Talend Studio in unseren Laufzeitcontainer zu exportieren.
Links auf dem Bildschirm unseres Talend Open Studio for ESB finden wir „demoCustomer 0.1“ und „Export Service“. Die Warnmeldung „No Job Assigned“ wird angezeigt – sie weist darauf hin, dass einigen unserer Prozesse keine Implementierung zugewiesen ist. Dies ist jedoch kein Problem, weshalb wir auf „OK“ klicken.
In Teil 1 haben wir zwei Laufzeitcontainer gestartet. Jetzt möchten wir den Dienst mittels „Export Service“ in den primären Container exportieren, den wir erstellt haben:
Zum Validieren dieses Exports rufen wir den primären Container auf und geben „list“ ein. Wir sehen, dass der neue „demoCustomer 0.1“ gestartet wurde und verfügbar ist. Sehr gut!
Da der Port, an dem der primäre Container die Dienste bereitstellt (8090) nicht dem Port entspricht, den Talend Studio verwendet (8040), müssen wir testen, ob der Dienst ordnungsgemäß antwortet. Dazu öffnen wir wieder SoapUI, klicken auf „Add new endpoint“ und ändern „localhost:“ zu 8040. Dann führen wir die Anfrage in SOAP aus. Die Ergebnisse enthalten die erhofften Kundendaten. Dadurch wissen wir, dass die Dienstantwort funktioniert.
Integrationsmuster mit Lastenausgleich implementieren
Jetzt, da unsere Dienstantwort funktioniert, können wir im nächsten Schritt den Lastenausgleichs-Algorithmus implementieren und uns einige der verfügbaren Vermittlungs- und Routingfunktionen ansehen. Zum Starten des Lastenausgleichsprozesses exportieren wir wieder den Dienst („Export Service“), diesmal aber in den sekundären Laufzeitcontainer, den wir bisher noch nicht verwendet haben. Damit verfügen wir jetzt über das Framework für den Lastenausgleich: zwei funktionstechnisch gleichwertige Dienste, die in zwei verschiedenen Containern ausgeführt werden.
Nachdem wir den Dienst exportiert haben, werfen wir einen Blick in den zweiten Container und sehen, dass der „demoCustomer“ bereitgestellt wurde und am Standard-Port 8041 ausgeführt wird. Wie oben beim Testen der Dienstantwort gehen wir wieder in SoapUI und fügen einen weiteren Endpunkt hinzu. Diesmal ändern wir „localhost:“ zu 8041 und führen die Anfrage im zweiten Container über SOAP aus.
Wir rufen wieder unsere Oberfläche auf, in der die Inhalte des Containers angezeigt werden. Dort sehen wir den Kundendienst und wissen, dass wir Antworten erhalten, weil das Logging-Element, das wir in den Dienst eingebaut haben, die XML-Antwort direkt über die Standardausgabe protokolliert (unten im nachfolgenden Screenshot).
Letzter Schritt: Routing und Vermittlung
Wir öffnen wieder Talend Open Studio for ESB, um uns die Routing- und Vermittlungsfunktionen anzusehen und einen einfachen Lastenausgleichsproxy für unseren Kundenendpunkt zu erstellen. Dazu klicken wir oben rechts zunächst auf „Mediation“, dann auf „Resource“ und dann auf „Create New Resource“ und laden unsere „DemoCustomer“-WSDL hoch.
Als Nächstes erstellen wir über „Create New Route“ eine neue Route mit der Bezeichnung „proxycustomer“ und sehen, dass die Palette auf der rechten Seite keine Integrationskomponenten mehr enthält. Stattdessen werden zusammengefasste Funktionen von Apache Camel angezeigt. Dazu gehören „LoadBalancer“, „MessageRouter“, verschiedene Prozesse und Messaging-Endpunkte – dies sind alles Apache Camel-Features, mit denen wir unsere Routing- und Vermittlungsfunktionen erstellen können.
Wir starten unsere Routing-Implementierung mit dem Endpunkt „cCxF“ und ändern den Namen dann in „proxyCustomer“. Anschließend klicken wir auf die Registerkarte „Component“, um dieser Komponente einige Metadaten hinzuzufügen, mit denen wir angeben, wie dieser neue Dienstendpunkt als Route dargestellt werden soll. Wir geben dieser Route dieselbe vertraglich vereinbarte Schnittstelle wie den anderen Diensten in „DemoCustomer“ – nur dass dieser Proxyendpunkt an Port 8050 startet.
Jetzt möchten wir einen Lastenausgleich zwischen diesen zwei Kundendiensten ausführen, die wir bereits in den zwei Containern bereitgestellt haben. Zur Konfiguration ziehen wir zwei weitere „cCxF“ in die Mitte und weisen ihnen jeweils dieselbe vertraglich vereinbarte Schnittstelle zu. Wir wenden auf die Dienste jedoch abweichende Container-Ports an (8040, 8041).
Anschließend gehen wir im linken Navigationsbereich auf „Routing“ und wählen „cLoadBalancer“ aus. Dies ist der Standard-Lastenausgleich von Apache Camel, der es uns ermöglicht, Anfragen über die Proxyschnittstelle an unsere zwei funktionstechnisch gleichwertigen Endpunkte zu verteilen. Für die Verteilung der Last zwischen den beiden Containern verwenden wir einen standardmäßigen „Round Robin“-Algorithmus.
Dann führen wir diesen Vorgang direkt in Talend Studio aus, um den Ablauf der Bereitstellung zu beobachten. Wir starten im Grunde eine Proxyschnittstelle zum Demo-Kundendienst an Port 8050. Diese Route ist jetzt verfügbar und wartet auf die Anfrage. Wir rufen wieder SoapUI auf und öffnen einen weiteren neuen Endpunkt an Port 8050.
Wir überprüfen unseren primären und sekundären Container, um sicherzugehen, dass die Anfragen im Wechsel eingehen und zwischen den zwei Kundendienst-Endpunkten somit ein Lastenausgleich stattfindet. Offenbar wurde die Last soeben auf den primären Container verteilt – und auf den sekundären Container, um die Antwort des Dienstes zu unterstützen. Wir sehen also, dass der Lastenausgleich funktioniert.
Wir haben jetzt Dienste erstellt, verfügbar gemacht und in bestehende Ressourcen integriert und mit unserem Routing- und Vermittlungs-Framework zusätzlich einfache Lastenausgleichsmuster generiert.
Sie können die hier beschriebenen Schritte in Talend Open Studio for ESB selbst ausprobieren. Nutzen Sie den kostenlosen ESB von Talend und überzeugen Sie sich selbst davon, wie leicht sich das soeben demonstrierte Muster in Ihrem eigenen Netzwerk implementieren lässt. Testen Sie Talend Open Studio noch heute.
