MongoDB-Einrichtung

Wichtiger Hinweis: Datenbanken und für den Zugriff auf Datenbanken verwendete JDBC-Treiber sind Produkte von Drittherstellern und werden weder von Lobster unterstützt, noch von Lobster zur Verfügung gestellt. Eine eventuell dennoch geleistete Unterstützung oder Beratung zu Datenbanken bzw. JDBC-Treibern durch den Lobster-Support ist freiwillig und impliziert in keinem Fall einen Übergang der Verantwortung auf diesen. Die Installation, der Betrieb und die Wartung von Datenbanken/JDBC-Treibern, bzw. durchgeführte Maßnahmen an diesen, unterliegen immer und ausnahmslos der Verantwortlichkeit des Kunden.

Der Lobster-Support unterstützt Sie natürlich gerne bei den nötigen inneren Konfigurationen zur Anbindung funktionierender Fremdsysteme.

Diese Anleitung beschreibt die Anbindung einer MongoDB-Datenbank. Diese deckt nicht die Einrichtung der MongoDB selbst ab. Bitte verwenden Sie dazu die MongoDB-Handbücher.

Grundlegende Voraussetzungen

Sie sollten den MongoDB-Treiber "mongo-java-driver.jar" bereits in Ihrem "./lib"-Verzeichnis haben. Ansonsten wenden Sie sich bitte an unsere Mitarbeiter im Support.

Konfigurationsdatei ./etc/mongodb.xml

images/download/attachments/201673282/Image_003-version-1-modificationdate-1746777344752-api-v2.jpg

Der Datenbank-Alias für das Logging muss den Namen _data haben. Ist das nicht der Fall, wird das Logging nicht auf die MongoDB umgestellt!

Pooling und Caching erfolgt durch den Treiber selbst. Die Option catalogName verweist auf die Datenbank mit den sogenannten Collections. Da MongoDB Cluster-Server unterstützt, können Sie mehrere Server unter einem Alias definieren. Folgend ein Beispiel.

Wichtiger Hinweis: Die folgende Konfigurations-Variante ist erst ab der Lobster-Integration-Version 4.6.5 gültig (davor gilt die alte Variante).

<Configure class="com.ebd.hub.services.nosql.mongo.MongoDBConnectionService">
	<Set name="verbose">False</Set>
	<Call name="initPool">
		<Arg>
			<New class="com.ebd.hub.services.nosql.mongo.MongoDBSettings">
				<Set name="alias">_data</Set>
				<Call name="addDatabaseEntry">
					<Arg>mongodb://[username:password@]host1[:port1][,...hostN[:portN]][/[defaultAuthDB][?options]]</Arg>
				</Call>
				<Set name="catalogName">dw</Set>
			</New>
		</Arg>
	</Call>
</Configure>

Also zum Beispiel:

...
 <Call name="initPool">
	<Arg>
		<New class="com.ebd.hub.services.nosql.mongo.MongoDBSettings">
			<Set name="alias">_data</Set>
			<Call name="addDatabaseEntry">
				<Arg>mongodb://mongouser:mongopassword@localhost/admin</Arg>
			</Call>
			<Set name="catalogName">dw</Set>
		</New>
	</Arg>
</Call> 
...

Das Passwort kann auch obfuskiert angegeben werden mit dem Platzhalter <password> (in escapter Form, exakt so, wie folgend gezeigt, wobei mongouser und myObfuscatedPassword natürlich noch ersetzt werden müssen) und einer zusätzlichen Zeile.

...
<Arg>mongodb://mongouser:&lt;password&gt;@localhost/admin</Arg>
<Arg>OBF:myObfuscatedPassword</Arg>
...

Auf Change Events reagieren

Es ist möglich auf Change Event in der MongoDB zu reagieren. Tritt ein definiertes Change Event auf, kann ein Makro getriggert werden. Das Makro muss dabei den Zugriffs-Typ “Jeder” haben und kann per ID oder Name angegeben werden. Die Angabe über den Namen ist dann hilfreich, wenn das Makro beim Start noch nicht vorhanden ist und erst später angelegt wird (und man die ID noch nicht kennt).

Hinweis: Listener sind auf einem Load-Balancing-System nur auf dem Node Controller aktiv. Sind auf einem Working Node Listener definiert und der Working Node wird zum Node Controller, werden diese Listener aktiviert.

Hinweis: Wird die Verbindung kurzzeitig unterbrochen (Fehlerfall), wird nach dem letzten empfangenem Event aufgesetzt (MongoDB spricht hier von “resumeAfter”). Dies gilt nicht für Server-Restarts oder Restarts des MongoDB-Services. In diesem Fall wird mit dem ersten Event nach dem Restart begonnen.

... 
<Call name="initPool">
	<Arg>
		<New class="com.ebd.hub.services.nosql.mongo.MongoDBSettings">
			<Set name="alias">some_alias</Set>
			<Call name="addDatabaseEntry">
				<Arg>mongodb://mongouser:mongopassword@localhost/admin</Arg>
			</Call>
			<Set name="catalogName">myDB</Set>
			<!-- Change event listener -->
			<Call name="addListener">
				<Arg>
                    <New class="com.ebd.hub.datawizard.app.listener.MongoDBMacroListener">
                        <Arg>myDB</Arg> <!--database -->
                        <Arg>events</Arg> <!-- collection -->
                        <Arg><![CDATA[[{"$match": {"operationType": {"$in": ["update", "replace"]}}}]]]></Arg> <!-- aggregate pipeline -->
                        <Arg>Macro MongoDBEvent</Arg> <!-- macro name or id
                        <Arg type="integer">-577739628</Arg> macro id -->
                        <Arg>-1</Arg> <!-- client id -->
                        <Arg type="boolean">false</Arg> <!-- report full document (true) or only _id  (false) -->
                        <Set name="logging">true</Set> <!-- show result of macro in log -->
                    </New>
                </Arg>
            </Call>
		</New>
	</Arg>
</Call>
...

Parameter	Beschreibung
database	Die Database.
collection	Die Collection.
aggregate pipeline	Hier wird definiert, auf welche Events reagiert wird. In diesem Fall auf “update” und “replace”.
macro name or id	Angabe des Makros per Name oder ID des Makros.
client id	Der Mandant (ID) für den der Listener gilt. Hier -1 für den Default-Mandanten.
report full document or only id	Bei false wird nur die _id des Dokument an das Makro gegeben, bei true das gesamte Dokument.
show result of macro in log	Bei true wird das Ergebnis des Makros geloggt.

Ein weiteres Beispiel, bei dem auf Events vom Typ "update/insert" und "replace" mit jeweils einem anderen Makro regiert wird:

...
<Call name="addListener"><Arg>
	<New class="com.ebd.hub.datawizard.app.listener.MongoDBMacroListener">
		<Arg>myDB</Arg> <!--database -->
		<Arg>events</Arg> <!-- collection -->
		<Arg><![CDATA[[{"$match": {"operationType": {"$in": ["update", "insert"]}}}]]]></Arg> <!-- aggregate pipeline -->
		<Arg>Macro MongoDBEvent for UPDATE and INSERT</Arg> <!-- macro name -->
		<Arg>-1</Arg> <!-- client id -->
		<Arg type="boolean">false</Arg> <!-- report full document (true) or only _id  (false) -->
		<Set name="logging">true</Set> <!-- show result of macro in log -->
		</New>
	</Arg>
</Call>
<Call name="addListener"><Arg>
	<New class="com.ebd.hub.datawizard.app.listener.MongoDBMacroListener">
		<Arg>myDB</Arg> <!--database -->
		<Arg>events</Arg> <!-- collection -->
		<Arg><![CDATA[[{"$match": {"operationType": {"$in": ["replace"]}}}]]]></Arg> <!-- aggregate pipeline -->
		<Arg>Macro MongoDBEvent for REPLACE</Arg> <!-- macro name -->
		<Arg>-1</Arg> <!-- client id -->
		<Arg type="boolean">false</Arg> <!-- report full document (true) or only _id  (false) -->
		<Set name="logging">true</Set> <!-- show result of macro in log -->
	</New>
	</Arg>
</Call>
...

Konfigurationsdatei ./etc/factory.xml

Aktivieren Sie den folgenden Abschnitt in der Konfigurationsdatei ./etc/factory.xml oder fügen Sie ihn hinzu (gleich nachdem Sie den MongoDBConnectionService hinzugefügt haben).

<Call name="addService">
	<Arg>com.ebd.hub.services.nosql.mongo.MongoDBConnectionService</Arg>
	<Arg>etc/mongodb.xml</Arg>
</Call>

Nächste Jobnummer

Die nächste verfügbare Jobnummer kann mit zwei Methoden verwaltet werden. Verwenden des internen Speicherdienstes oder einer Datenbank. Wenn Sie eine MongoDB verwenden, müssen Sie die Datenbank verwenden. Wichtiger Hinweis: Wenn die Datenbank keine Jobnummer zurück liefert (z. B. weil die Datenbank "hub" nicht erreichbar ist), dann wird Lobster Integration beendet. Hinweis: Beispiele finden Sie in Datei./conf/samples/db_sequence.sql

Beispiel für MySQL

CREATE TABLE `seq_jobnr_dw` (
  `val` bigint(16) unsigned NOT NULL
)
SET GLOBAL log_bin_trust_function_creators = 1;
delimiter //
create function getNextJobNr() returns bigint
begin
update hub.seq_jobnr_dw set val=last_insert_id(val+1);
RETURN last_insert_id();
end
//

Fügen Sie dann die folgende Option in der Konfigurationsdatei ./etc/startup.xml hinzu.

<Set name="sequenceProcedureCall">select getNextJobNr()</Set>

Beispiel für MSSQL

create sequence getNextJobNr as BIGINT start with 1 increment by 1;

Fügen Sie dann die folgende Option in der Konfigurationsdatei ./etc/startup.xml hinzu.

<Set name="sequenceProcedureCall">SELECT NEXT VALUE FOR getNextJobNr</Set>

Beispiel für Oracle

CREATE SEQUENCE GetNextJobNr
START WITH     1
INCREMENT BY   1;

Fügen Sie dann die folgende Option in der Konfigurationsdatei ./etc/startup.xml hinzu.

<Set name="sequenceProcedureCall">SELECT GetNextJobNr.NEXTVAL FROM dual</Set>

Archivoption in ./etc/startup.xml

Mit einer MongoDB können Sie veraltete Log-Einträge von Jobs in eine andere Collection verschieben. Fügen Sie dazu den folgenden Eintrag ein.

<Call name="setLongTimeArchive"><Arg type="int">30</Arg><Arg type="int">900</Arg></Call>

In diesem Beispiel werden alle Logeinträge, die älter als 30 Tage sind, in die Archiv-Collection verschoben und dort nach 900 Tagen gelöscht. Bei der Anforderung von Logeinträgen, die älter als 30 Tage sind, wird in der Archiv-Collection statt in der normalen Collection gesucht.

Auf das Archiv wird zugegriffen, wenn unter Control Center → Logs → Übersicht ein Zeitraum innerhalb des Archivs angefragt wird.

Log-Migration

Wenn Ihr System erfolgreich gestartet wurde, können Sie Ihre alten Log-Meldungen der SQL-Datenbank in der MongoDB zusammenführen. Die Migration wird im Hintergrund durchgeführt. Stoppen Sie den Server also nicht, bis der Job beendet ist!

Öffnen Sie die Admin-Konsole und navigieren Sie zu “Ausführung von Klassen”. Geben Sie com.ebd.hub.datawizard.log.mongodb.TransferLogEntries als Klassennamen ein und den Datenbank-Alias des normalen Loggings (normalerweise ist das hub). Optional können Sie (falls konfiguriert) den DataCockpit-Alias eingeben. Führen Sie die Klasse aus und überprüfen Sie Datei ./logs/wrapper.log unter Windows oder ./hub.txt unter Unix-/Linux-Systemen. Sie werden eine Nachricht wie Finished, overall time is XXXs am Ende vorfinden. Nur die Tabelle dw_log_sum wird zur MongoDB migriert. Wenn Sie alte Details-Logs benötigen, müssen Sie diese aus der alten dw_log-Tabelle abfragen.

MongoDB und DataCockpit

Wenn Sie eine MongoDB und DataCockpit benutzen, fügen Sie bitte eine Eintrag wie den folgenden in Konfigurationsdatei ./etc/startup.xml ein

<Call name="addApplication"><Arg>
		<New class="de.lobster.webmon.apps.WebMonitor">
			<Set name="alias">hub</Set>
			<Set name="remoteHost"></Set>
			<Set name="remotePort">8020</Set>
			<Set name="mailSender">first.last@lobster.de</Set>
			<Set name="retainHeaderLogs">999</Set>
			<Set name="cleanUpTime">2</Set>
			<Set name="serverName">Main Server</Set>
		</New>
	</Arg></Call>

und zudem in Konfigurationsdatei ./etc/mongodb.xml.

<Call name="initPool">
	<Arg>
		<New class="com.ebd.hub.services.nosql.mongo.MongoDBSettings">
			<Set name="alias">_data</Set>
			<Call name="addDatabaseEntry">
				<Arg type="String">mongodb://localhost:27017</Arg>
			</Call>
			<Set name="catalogName">dw</Set>
		</New>
	</Arg>
</Call>
 
<Call name="initPool">
	<Arg>
		<New class="com.ebd.hub.services.nosql.mongo.MongoDBSettings">
			<Set name="alias">hub</Set>
			<Call name="addDatabaseEntry">
				<Arg type="String">mongodb://localhost:27017</Arg>
			</Call>
			<Set name="catalogName">dw</Set>
		</New>
	</Arg>
</Call>