fb
WSO2 Enterprise Integrator 6 Minuten

Data Service VS DBReport – Wie lassen sich Daten am besten in eine Datenbank einfügen?

Rob Blaauboer
Rob Blaauboer
Integration Consultant & WSO2 Trainer
Data Service VS DBReport
Scrollen

In meinen WSO2-Schulungen sage ich meinen Schülern oft, dass es auch eine andere Möglichkeit gibt, etwas zu tun. In einer Reihe von Blogs werde ich mich mit den Alternativen beschäftigen, die WSO2 Enterprise Integrator bietet.

Die Alternativen erfüllen das gleiche funktionale Ziel. Der Unterschied ist hauptsächlich technischer Natur und manchmal nur eine Frage der Vorliebe oder des Umsetzungsstils. Möglicherweise hat die eine Alternative einen Vorteil gegenüber der anderen. Es gibt Situationen, in denen der eine Weg typischerweise besser ist als der andere, und es gibt auch Situationen, in denen es trotz der Möglichkeit nicht empfehlenswert ist, ihn auszuführen. 

Hier in diesem Blog werde ich einen Daten-Service mit dem DBReport- und DBLookup-Mediator als eine Möglichkeit, Daten in eine Tabelle einzufügen, vergleichen.

Unterschiede zwischen Daten-Service und DBReport- und DBLookup-Mediator

Für den Vergleich dieser Funktionen beginnen wir mit einem einfachen Setup, bei dem wir Inhalte in einer Datenbank generieren. Wir verfügen über zwei Mediatoren, und zwar den DBReport- und den DBLookup-Mediator, mit denen wir eine Verbindung zu einer Datenbank herstellen werden. Alternativ dazu können wir einen Daten-Service verwenden, d. h. einen speziellen Service, den Sie entweder über die Verwaltungsoberfläche des Enterprise Integrator oder über Integration Studio definieren.

Ein Daten-Service kann auf Basis einer vorhandenen Datenquelle generiert oder manuell komplett neu definiert werden. Der Assistent in der Management-Oberfläche kann verwendet werden, um automatisch eine Reihe von Operationen zu entwickeln, mit denen Sie auf die Daten der Datenquelle zugreifen können. Es wird also ein Endpunkt mit einer Reihe von Operationen generiert, die davon abhängen, ob die Tabelle einen Primärschlüssel hat. 
Nehmen wir also an, dass Sie eine Datenbank mit 10 Tabellen haben. Die Generierung des Daten-Service wird tatsächlich eine oder mehrere sogenannte Daten-Service-Dateien erstellen, die Ihnen das Einfügen, Lesen, Aktualisieren und Löschen von Daten in diesen Tabellen ermöglichen. 

Also, wie einer meiner alten Freunde zu sagen pflegte: „Derjenige, der meine Arbeit macht, ist mein Freund“. In diesem Fall ist der Generierungsassistent mein Freund, da er den Prozess beschleunigt und Ihnen etwas zur Verfügung stellt, das Sie dann modifizieren und/oder manipulieren können. 

Wenn Sie etwas einfügen müssen, können Sie es genauso gut generieren und dann die Feineinstellungen vornehmen.

Wenn Sie lediglich einen Datensatz in eine Datenbank einfügen oder sie aktualisieren oder abrufen müssen. Dann gibt es natürlich den DB-Report und den DB-Lookup-Mediator. DB-Lookup-Mediator ist, wie der Name schon sagt. Eine einfache Möglichkeit, die Daten aus einer Datenbank zu holen. Der DB-Lookup-Mediator liefert einen Wert aus der Datenbank, z. B. eine Summe oder etwas anderes. Wenn Sie einen Datensatz aktualisieren möchten, müssen Sie den DB-Report-Mediator verwenden, um ihn zu aktualisieren, einzufügen oder etwas anderes zu tun.

Technology Stack

Ich erstelle einen Daten-Service, der Datensätze in eine MySQL-Datenbanktabelle einfügt. Vergessen Sie nicht, den MySQL JDBC-Connector zum Verzeichnis [EI-HOME]/lib hinzuzufügen. 

Ich generiere die Daten-Services nicht, wenn ich das getan hätte, hätte ich etwas wie das hier bekommen:

Data Service VS DBReport 1

Ich werde die „Create“-Funktionalität verwenden, um den Daten-Service über die Management-Konsole einzurichten. Wählen wir zunächst die Option Erstellen.

Data Service VS DBReport 2

Geben Sie einen Namen ein und klicken Sie auf Weiter.

Data Service VS DBReport 3

Als nächstes müssen wir eine DataSource hinzufügen, klicken Sie auf „Add New Datasource“.

Data Service VS DBReport 4

Ergänzen Sie die Details wie dargestellt und testen Sie die Verbindung.

Data Service VS DBReport 5

Ich habe einige Standard-Anmeldeinformationen für die Verbindung mit meiner Testdatenbank verwendet. Sie können diese für Ihre Situation entsprechend ändern. Klicken Sie auf Speichern und danach auf Weiter.

Data Service VS DBReport 6

Klicken Sie auf Neue Abfrage hinzufügen.

Data Service VS DBReport 7

Ergänzen Sie die Angaben im SQL-Feld und klicken Sie auf die darunter liegende Schaltfläche „Generate Input Mappings“.

Data Service VS DBReport 8

Navigieren Sie unten auf dem Bildschirm zu Speichern. Klicken Sie auf Weiter, um zum letzten Schritt zu gelangen.

Data Service VS DBReport 9

Klicken Sie auf Neue Operation hinzufügen.

Data Service VS DBReport 10

Geben Sie wieder die Details ein, wie im Screenshot gezeigt.

Data Service VS DBReport 11

Klicken Sie auf Speichern und im nächsten Fenster auf Fertig stellen.

Data Service VS DBReport 12

Prüfen Sie, ob der Daten-Service hinzugefügt wurde, indem Sie die Liste der Services öffnen (siehe linkes Menü in der Management-Konsole) und auf „Try this service“ klicken.

Data Service VS DBReport 13
Data Service VS DBReport 14

Nachdem wir einige Prüfdaten eingegeben und auf „Senden“ geklickt haben, können wir in unserer Datenbank überprüfen, ob der Datensatz eingefügt wurde.

Data Service VS DBReport 15

Die Einrichtung ist zwar einfach und kann schnell durchgeführt werden, erfordert aber mehrere Schritte. Betrachten wir nun die Alternative, bei der wir die Mediatoren verwenden werden.

Verwendung eines DBReport  Mediators

Wenn ich dies auch mit dem DBReport-Mediator tun möchte, wechsle ich zur WSO2 Integration Studio IDE und erstelle einen neuen Proxy oder eine API. Dort können Sie den Mediator einfach auf die inSequence des Proxys oder der API ziehen und ihn konfigurieren.

Data Service VS DBReport 16
Data Service VS DBReport 17

Mit einem Dbreport-Mediator sieht der Quellcode so aus: 

<dbreport>
   <connection>
      <pool>
         <driver>com.mysql.jdbc.Driver</driver>
         <url>jdbc:mysql://localhost:3306/active</url>
         <user>root</user>
         <password>root</password>
       </pool>
   </connection>
   <statement>
      <sql><![CDATA[insert into records (DATE) values (?)]]></sql>
      <parameter expression="get-property('DATE')" type="CHAR"/>
   </statement>
</dbreport>

Bei diesem Beispiel habe ich die Datenbankdetails direkt im Quellcode definiert, aber ich hätte auch eine Datenquelle in der Konfiguration des Enterprise Integrators definieren und im DBReport-Mediator darauf verweisen können. Noch einfacher sind die Inline-Details.

Wie Sie sehen können, ist es weniger Arbeit als der Daten-Service. Aber es stellt sich die Frage … was ist besser?

Mediator oder Daten-Service, was ist besser?

Gibt es einen klaren Gewinner? Betrachten wir es zunächst aus der näheren Perspektive dieses Beispiels. Ein Daten-Service kann relativ einfach wiederverwendet werden, da es sich um einen Service mit einem Endpunkt handelt, der von jedem Ort aus adressiert werden kann. Außerdem kann er mit einem einfachen zusätzlichen Schritt zu einer API gemacht werden. Es ist jedoch auch ein weiteres Artefakt, das wir neben dem Proxy oder anderen Artifacts, die wir entwickeln, einsetzen. In diesem Beispiel haben wir eine SQL-Anweisung definiert, aber wir können in einem Daten-Service viele weitere definieren, wie wir im Bild mit dem generierten Code gesehen haben. Wir können auch weitere Dinge tun, wie z. B. Werte validieren, die im Daten-Service gespeichert werden, oder die resultierende Struktur just-in-time transformieren, bevor wir sie an den Client zurückgeben.

Als Alternative gibt es zwei Mediatoren, den DBReport-Mediator, der in eine Tabelle schreibt, und den DBLookup-Mediator, der eine Eigenschaft eines Feldes aus einer Zeile in einer Ergebnismenge setzen kann. Er kann keine mehreren Zeilen zurückgeben, dafür benötigen Sie einen Daten-Service.

Auf der anderen Seite bedeutet das Aufrufen des Daten-Service, dass wir die inSequence verlassen, um den Service aufzurufen und zurückzugeben, was auch mehr Zeit benötigt als das einfache Ausführen eines Mediators. Es muss zusätzliche Fehlerbehandlungslogik programmiert werden, um verschiedene Fehler zu behandeln, wo wir uns bei den Mediatoren nur auf die FaultSequence verlassen können, um Fehler zu behandeln.

Ein Aspekt, der aus dieser engen Perspektive nicht zur Sprache kommt, ist, dass der Daten-Service auch die Aktualisierung anderer Datenquellen wie eine CSV-Datei, XLS-Datei oder sogar eine benutzerdefinierte Datenquelle ermöglicht. 

Ein Daten-Service ist deutlich vielseitiger, erfordert aber mehr Arbeit beim Aufrufen. Gibt es einen klaren Gewinner? Ich würde sagen, wenn Sie einfach nur Daten in eine Tabelle innerhalb Ihrer Integration einfügen müssen, dann funktioniert der DBReport-Mediator gut. Dasselbe gilt für den DBLookup-Mediator. Ein einfacher Lookup für einen Feldwert aus einer Datenbank kann einfach mit dem DBLookup-Mediator durchgeführt werden. Bei komplexeren Setups oder wenn Sie Ihre Daten mehreren Verbrauchern zur Verfügung stellen müssen, ist eine Integration mit dem Daten-Service der richtige Weg. Der Daten-Service bietet eine höhere Flexibilität mit einer breiteren Anwendbarkeit.