Konfiguration/Basismodell

Das Konfiguration/Basismodell ist eine grundlegende Komponente deines DATAMIMIC-Projekts und dient als Grundlage für die Einrichtung und Konfiguration verbundener Systeme, einschließlich der Angabe systemweiter Einstellungen, Umgebungsdetails und eingebundener externer Dateien.

Beispiel-Konfigurationsmodell

Betrachte das folgende Beispiel eines DATAMIMIC-Konfigurationsmodells:

<setup>
    <database id="sourceDB" system="source_oracle" />
    <database id="targetDB" system="target_postgres" />
    <mongodb id="target_mongodb" />

    <include uri="1_select_subset.xml" />
    <include uri="2_obfuscate.xml" />
</setup>

In diesem Beispiel:

• werden <database>-Elemente verwendet, um Datenbankkonfigurationen für Quell- und Zielsysteme zu definieren, einschließlich "source_oracle" und "target_postgres".
• wird <mongodb> verwendet, um die MongoDB-Konfiguration zu definieren.
• verweisen <include>-Elemente auf externe XML-Dateien (1_select_subset.xml und 2_obfuscate.xml) zur Definition von Datengenerierungs- und Verarbeitungsaufgaben.

Dieses Konfigurationsmodell bereitet die Bühne für dein DATAMIMIC-Projekt und ermöglicht es dir, verschiedene Systeme zu konfigurieren und mit ihnen zu verbinden, Umgebungsdetails anzugeben und bei Bedarf externe Konfigurationen einzubinden.

Es ist wichtig, das 'Konfiguration/Basismodell' an deine spezifischen Projektanforderungen anzupassen und es auf die Systeme und Datenbanken abzustimmen, mit denen du arbeitest.

<setup>

Das <setup>-Element ist die Wurzel des Konfiguration/Basismodells und definiert das gesamte Setup für den Datengenerierungsprozess.

Attribute

• defaultSeparator: Definiert das Standard-Trennzeichen beim Lesen von Datenquellen (wie CSV). Gängige Werte sind "|", ";" oder ",". Standard ist "|".
• defaultDataset: Gibt das Standard-Dataset an (z. B. "DE", "US"). Standard ist "US".
• defaultLocale: Gibt die Standard-Locale an (z. B. "de", "en"). Standard ist "en".
• numProcess: Definiert die Anzahl der Prozesse für Multiprocessing, die an inkludierte <setup> und <generate> weitergegeben werden kann. Standard ist 1.
• defaultLineSeparator: Definiert den Standard-Zeilenumbruch (z. B. "\r\n", "\r", "\n"). Standard ist "\n".
• defaultSourceScripted: Gibt an, ob der Wert in einem beliebigen Element skriptbasiert ist (z. B. wird "{1 + 2}" als "3" ausgewertet). Standard ist "False".
• reportLogging: Gibt an, ob ein Zeit-Log des Generierungs- und Exportprozesses erstellt werden soll. Wenn du eine sehr große Anzahl von generate-Knoten hast, kann das Setzen dieses Wertes auf "False" die Verarbeitungszeit reduzieren. Standard ist "True".
• defaultVariablePrefix: Konfigurierbares Attribut, das das Präfix für die Variablensubstitution in dynamischen Zeichenketten definiert (Standard ist __).
• defaultVariableSuffix: Konfigurierbares Attribut, das das Suffix für die Variablensubstitution in dynamischen Zeichenketten definiert (Standard ist __).

Kindelemente

• <database>: Definiert Verbindungen zu relationalen Datenbanken.
• <mongodb>: Definiert MongoDB-Verbindungen.
• <include>: Bindet externe Dateien oder Konfigurationen ein.
• <memstore>: Definiert einen In-Memory-Speicher, der für die temporäre Datenspeicherung zwischen Generierungsaufgaben nützlich ist.
• <execute>: Führt externe Skripte oder Befehle aus.
• <echo>: Gibt Text oder Variablen im Log aus, nützlich für das Debugging (-> DATAMIMIC Datendefinitionsmodell – Kernelemente.
• <variable>: Definiert Variablen, die bei der Datengenerierung verwendet werden (-> Datendefinitionsmodell - Fortgeschrittene Elemente .
• <data-warehouse>: Definiert Data-Warehouse-Konfigurationen.
• <kafka-exporter>: Definiert Kafka-Producer-Verbindungen.
• <kafka-importer>: Definiert Kafka-Consumer-Verbindungen.
• <object-storage>: Definiert Object-Store-Konfigurationen.

---

<database>

Das <database>-Element wird verwendet, um Datenbankverbindungen innerhalb des DATAMIMIC-Konfigurationsmodells zu definieren.

Attribute

• id: Gibt den eindeutigen Bezeichner für die Datenbankverbindung und die ID der konfigurierten Systemumgebung an.
• system: Gibt den Namen deiner Datenbank-Umgebungskonfiguration auf der Plattform an. Wenn dieses Attribut nicht definiert ist, verwendet das System die ID als Systemnamen.

Beispiel

<database id="sourceDB" />

<mongodb>

Das <mongodb>-Element definiert MongoDB-Verbindungen innerhalb des DATAMIMIC-Konfigurationsmodells.

Attribute

• id: Gibt den eindeutigen Bezeichner für die MongoDB-Verbindung und die ID der konfigurierten Systemumgebung an.
• system: Gibt den Namen deiner MongoDB-Umgebungskonfiguration auf der Plattform an. Wenn dieses Attribut nicht definiert ist, verwendet das System die ID als Systemnamen.

Beispiel

MongoDB-Datenbank einrichten

<mongodb id="mongodb" system="mongodb"/>

Daten in MongoDB einfügen

<generate name="mongo_func_test" target="mongodb" count="100">
    <key name="user_id" generator="IncrementGenerator"/>
    <key name="user_name" values="'Bob', 'Frank', 'Phil'"/>
</generate>

Daten aus MongoDB mit einem Selektor laden

<generate name="load_mongodb" source="mongodb" selector="find: 'mongo_func_test', filter: {'user_name': 'Bob'}}"/>

Wichtig: Wenn du Daten aus MongoDB laden und als JSON exportieren möchtest, musst du die Daten ohne '_id' auswählen (da ObjectId kein regulärer Datentyp von JSON ist).

<generate name="json_mongodb" source="mongodb" 
          selector="find:'mongo_func_test', filter:{'user_name':'Bob'}, projection:{'_id':0}" 
          target="JSON"/>

MongoDB-Daten aktualisieren

<generate name="mongo_update" type="mongo_func_test" source="mongodb" target="mongodb.update">
    <key name="addition" values="'Addition 1', 'Addition 2', 'Addition 3'"/>
</generate>

MongoDB mit upsert true aktualisieren

<generate name="mongo_upsert" source="mongodb"
          selector="find: 'mongo_func_test', filter: {'user_name': 'Mary'}"
          target="mongodb.upsert">
    <key name="addition" values="'addition_value1', 'addition_value2', 'addition_value3'"/>
    <key name="second_addition" values="'value1', 'value2', 'value3'"/>
    <key name="other_addition" values="'other_value1', 'other_value2', 'other_value3'"/>
</generate>

mongo_func_test Collection leeren

<generate name="delete" source="mongodb" selector="find: 'mongo_func_test', filter: {}" target="mongodb.delete"/>

Hier ist eine überarbeitete und detailliertere Version der Dokumentation für das <include>-Element, die dynamische Include-Beispiele und Erklärungen enthält:

---

<include>

Das <include>-Element wird verwendet, um DATAMIMIC-Modelldateien oder -Konfigurationen in das DATAMIMIC-Konfigurationsmodell einzubinden. Dies ermöglicht die Modularisierung großer Setups durch dynamisches oder statisches Referenzieren externer Konfigurationen.

Attribute

• uri: Gibt die URI (Uniform Resource Identifier) der einzubindenden externen Datei an. Die URI kann ein statischer Pfad sein oder dynamisch mithilfe von Variablen aus der Konfiguration generiert werden.

Beispiel 1: Statische Includes

In diesem Beispiel werden zwei statische XML-Dateien, 1_select_subset.xml und 2_obfuscate.xml, in das Setup eingebunden:

<setup>
    <include uri="1_select_subset.xml"/>
    <include uri="2_obfuscate.xml"/>
</setup>

• Das <include>-Element lädt hier einfach den Inhalt von 1_select_subset.xml und 2_obfuscate.xml in die Konfiguration. Dies ist nützlich, wenn du wiederverwendbare Konfigurationen in separaten Dateien gespeichert hast.

Beispiel 2: Dynamische Includes mit Variablen

Dieses Beispiel zeigt einen fortgeschritteneren Anwendungsfall, bei dem Includes dynamisch auf Basis von Daten aus einer externen CSV-Datei bestimmt werden.

Konfiguration

<setup>
    <generate name="ctrl" source="data/control.ent.csv">
        <include uri="{model}"/>
    </generate>
</setup>

CSV-Datei (data/control.ent.csv)

id|count|target|model
1|10|output1|include_generate.xml
2|20|output2|include_generate.xml

• Erklärung:
  • Die Konfiguration lädt dynamisch den Wert des model-Feldes aus data/control.ent.csv und ersetzt {model} durch den in jeder Zeile gefundenen Wert. In diesem Fall wird include_generate.xml für beide Einträge in der CSV-Datei eingebunden.
  • Der generate-Block liest Zeilen aus der CSV-Datei, und für jede Zeile bindet er die entsprechende Datei ein, die in der model-Spalte angegeben ist (include_generate.xml).

Diese dynamische Einbindung ist nützlich, wenn verschiedene Setups oder Konfigurationen basierend auf externen Datenquellen eingebunden werden müssen, was das Setup sehr flexibel und an verschiedene Szenarien anpassbar macht.

Beispiel 3: Verwendung mehrerer Includes mit dynamischen Zielen

<setup>
    <generate name="dynamic_include" source="data/control.ent.csv">
        <key name="id" script="control.id"/>
        <key name="count" script="control.count"/>
        <key name="target" script="control.target"/>
        <include uri="{model}"/>
    </generate>
</setup>

• In diesem Setup:
  • Jede Zeile aus data/control.ent.csv wird verarbeitet, und die entsprechende model-Datei wird basierend auf dem Wert von {model} eingebunden.
  • Dies ermöglicht es dir, den Datengenerierungsprozess zu modularisieren, indem du verschiedene Konfigurationen für verschiedene Zeilen einziehst, was das Setup flexibel je nach Inhalt der CSV-Datei macht.

Best Practices für die Verwendung von <include>

1. Modularisierung: Verwende <include>, um große Konfigurationen in kleinere, überschaubare Dateien aufzuteilen. Dies hilft bei der Organisation komplexer Setups und der Wiederverwendung gängiger Konfigurationen über verschiedene Modelle hinweg.

2. Dynamische Includes: Kombiniere <include> mit dynamischen Variablen, um externe Konfigurationen bedingt auf der Grundlage von Eingabedaten (z. B. aus einer CSV, Datenbank oder API) zu laden.

3. Fehlerbehandlung: Stelle sicher, dass die Dateipfade oder URIs im uri-Attribut korrekt sind, da fehlende oder falsch angegebene Dateien zu Fehlern beim Laden der Konfiguration führen können.

4. Dokumentation und Benennung: Halte deine Include-Dateien gut dokumentiert und verwende aussagekräftige Namen, um sicherzustellen, dass die Absicht hinter jedem Include klar und wartbar ist.

---

<memstore>

Das <memstore>-Element definiert einen In-Memory-Speicher zur Verwendung im DATAMIMIC-Konfigurationsmodell. Es ist besonders nützlich, um Daten temporär zwischen verschiedenen Datengenerierungsaufgaben zu speichern, ohne den Zugriff auf eine externe Datenbank oder ein Dateisystem zu benötigen. Der memstore dient als temporäres Repository für generierte Daten und ermöglicht es dir, Daten über mehrere Aufgaben hinweg zu teilen oder dasselbe Dataset innerhalb eines einzigen Setups wiederzuverwenden.

Attribute

• id: Gibt den eindeutigen Bezeichner für die memstore-Instanz an. Dieser Bezeichner wird verwendet, um den In-Memory-Speicher in anderen Teilen der Konfiguration zu referenzieren.

Beispiel 1: Einfacher In-Memory-Speicher

In diesem Beispiel wird ein einfacher memstore erstellt und während der Datengenerierung referenziert:

<setup>
    <memstore id="mem"/>

    <generate name="product_list" count="15" target="mem">
        <key name="id" generator="IncrementGenerator"/>
        <key name="name" values="'Product A', 'Product B', 'Product C'"/>
    </generate>
</setup>

• Erklärung:
  • <memstore id="mem"/> definiert eine In-Memory-Speicherinstanz mit der ID "mem".
  • Der generate-Block generiert 15 Datensätze mit Produktdaten und speichert sie im Memory-Store. Auf diese Daten kann später in derselben Konfiguration verwiesen werden.

Beispiel 2: Wiederverwendung von Daten aus dem memstore über mehrere Aufgaben hinweg

<setup>
    <memstore id="mem"/>

    <generate name="product_list" count="15" target="mem">
        <key name="id" generator="IncrementGenerator"/>
        <key name="name" values="'Product A', 'Product B', 'Product C'"/>
    </generate>

    <generate name="sales_data" count="30" type="product_list" source="mem" target="CSV">
        <key name="order_id" generator="IncrementGenerator"/>
        <key name="product_id" script="id"/>
        <key name="product_name" script="name"/>
        <key name="quantity" generator="IntegerGenerator(min=1,max=10)"/>
    </generate>
</setup>

• Erklärung:
  • Der erste generate-Block erstellt einen Satz von Produktdaten und speichert ihn im memstore.
  • Der zweite generate-Block ruft die Produktdaten aus dem memstore ab und verwendet sie, um Verkaufsdatensätze zu generieren, wobei neue Schlüssel wie quantity hinzugefügt werden.

Beispiel 3: Dynamische Datenverarbeitung mit memstore

<setup>
    <memstore id="mem"/>

    <generate name="customer_list" count="20" target="mem">
        <key name="customer_id" generator="IncrementGenerator"/>
        <key name="customer_name" values="'Alice', 'Bob', 'Charlie'"/>
    </generate>

    <generate name="order_list" count="50" type="customer_list" source="mem" target="CSV">
        <key name="order_id" generator="IncrementGenerator"/>
        <key name="customer_id" script="customer_id"/>
        <key name="customer_name" script="customer_name"/>
        <key name="order_total" generator="FloatGenerator(min=10, max=500)"/>
    </generate>
</setup>

• Erklärung:
  • Die erste Aufgabe generiert Kundendaten und speichert sie im memstore.
  • Die zweite Aufgabe ruft die Kundendaten aus dem Speicher ab, um entsprechende Bestellungen zu generieren, und verknüpft die Bestellungen dynamisch mit den im Speicher abgelegten Kunden.

Beispiel 4: Kombination von memstore mit Bedingungen

<setup>
    <memstore id="mem"/>

    <generate name="employee_list" count="10" target="mem">
        <key name="employee_id" generator="IncrementGenerator"/>
        <key name="employee_name" values="'John', 'Jane', 'Doe'"/>
    </generate>

    <generate name="performance_reviews" count="10" type="employee_list" source="mem" target="CSV">
        <key name="review_id" generator="IncrementGenerator"/>
        <key name="employee_id" script="employee_id"/>
        <key name="employee_name" script="employee_name"/>
        <key name="performance_rating" generator="IntegerGenerator(min=1, max=5)"/>

        <condition>
            <if condition="performance_rating == 5">
                <key name="promotion_recommended" constant="Yes"/>
            </if>
            <else>
                <key name="promotion_recommended" constant="No"/>
            </else>
        </condition>
    </generate>
</setup>

• Erklärung:
  • Dieses Setup generiert Mitarbeiter und speichert die Daten im Speicher.
  • Bei der Generierung von Leistungsbeurteilungen wird eine bedingte Prüfung auf die performance_rating angewendet, und eine Beförderungsempfehlung wird basierend auf der Bewertung generiert.

Beispiel 5: Temporäre Speicherung für die zwischenzeitliche Datenverarbeitung

<setup>
    <memstore id="temp_memstore"/>

    <generate name="product_list" count="10" target="temp_memstore">
        <key name="product_id" generator="IncrementGenerator"/>
        <key name="product_name" values="'Laptop', 'Mouse', 'Keyboard', 'Monitor'"/>
    </generate>

    <generate name="order_list" count="20" type="product_list" source="temp_memstore" target="CSV">
        <key name="order_id" generator="IncrementGenerator"/>
        <key name="product_id" script="product_id"/>
        <key name="product_name" script="product_name"/>
        <key name="quantity" generator="IntegerGenerator"/>
    </generate>

    <generate name="order_summaries" count="5" type="product_list" source="temp_memstore" target="ConsoleExporter">
        <key name="summary_id" generator="IncrementGenerator"/>
        <key name="product_summary" script="product_name + ' summary'"/>
    </generate>
</setup>

• Erklärung:
  • Dieses Setup zeigt, wie der memstore verwendet werden kann, um Zwischendaten (z. B. Produkte) zu speichern, die in nachfolgenden Generierungsaufgaben (z. B. Bestellungen und Bestellzusammenfassungen) wiederverwendet werden.
  • Der temp_memstore wird verwendet, um Daten über mehrere Generierungsaufgaben hinweg temporär zu speichern und zu referenzieren, ohne zwischen den Schritten in einen externen Speicher schreiben zu müssen.

Best Practices für die Verwendung von <memstore>

1. Temporäre Datenspeicherung: Verwende memstore, um temporäre Daten zu halten, die über verschiedene Aufgaben oder Schritte in der Konfiguration wiederverwendet werden müssen.

2. Effiziente Datenverarbeitung: Nutze memstore für die In-Memory-Verarbeitung, wenn du Datensätze wiederverwenden musst, ohne in eine Datei oder Datenbank zu schreiben, was die Verarbeitungsgeschwindigkeit in Datenpipelines verbessert.

3. Organisierter Datenfluss: Definiere mehrere memstore-Instanzen, wenn du mit verschiedenen Datensätzen arbeitest, um die Daten organisiert zu halten und Datenvermischungen zwischen nicht zusammengehörigen Aufgaben zu vermeiden.

4. Dynamische Datenhandhabung: Kombiniere memstore mit dynamischen Variablen, Bedingungen und anderen Elementen, um komplexe Datenflüsse und Szenarien zu handhaben, wie z. B. bedingte Datengenerierung oder hierarchische Strukturen.

Hier ist eine erweiterte Version der Beschreibung des <execute>-Elements mit zusätzlichen Syntax- und Anwendungsfallbeispielen:

---

<execute>

Das <execute>-Element wird verwendet, um externe Skripte oder Befehle innerhalb des DATAMIMIC-Konfigurationsmodells auszuführen. Dies ist besonders nützlich, wenn du Datenbanken einrichten, SQL-Skripte ausführen oder externe Skripte (z. B. Python-Skripte) vor oder während des Datengenerierungsprozesses ausführen musst.

Attribute

• uri: Gibt die URI oder den Pfad der auszuführenden Skriptdatei an. Dies kann ein SQL-Skript, ein Python-Skript oder ein anderer externer Skripttyp sein.
• target: Gibt das Ziel an, auf dem das Skript ausgeführt werden soll. Dies ist typischerweise eine Datenbank-ID (z. B. dbPostgres) für die Ausführung von SQL-Skripten oder kann für andere Arten von externen Skripten weggelassen werden.

Beispiel 1: Ausführen von SQL-Skripten auf einer Datenbank

<setup>
    <database id="dbPostgres" system="postgres"/>

    <execute uri="script/backup.sql" target="dbPostgres"/>

    <variable name="table_name" constant="public.db_postgres_types5"/>

    <generate name="generate_selector"
              source="dbPostgres"
              selector="SELECT * FROM __table_name__" target="ConsoleExporter">
    </generate>

    <generate name="variable_selector" count="20" target="ConsoleExporter">
        <variable name="query" source="dbPostgres" selector="SELECT id, text FROM __table_name__" />
        <key name="id" script="query.id"/>
        <key name="name" script="query.text"/>
    </generate>
</setup>

In diesem Beispiel:

• wird das <execute>-Element verwendet, um ein externes SQL-Skript (backup.sql) gegen eine PostgreSQL-Datenbank auszuführen.
• Das Skript wird vor der Datengenerierung ausgeführt, um sicherzustellen, dass die Datenbank gesichert ist, bevor mit der Datengenerierung fortgefahren wird.

Beispiel 2: Ausführen mehrerer Skripte (SQL und Python)

<setup>
    <database id="dbPostgres" system="postgres"/>

    <execute uri="script/setup_test_variable_source_with_name_only.sql" target="dbPostgres"/>

    <execute uri="script/my_python.src.py"/>

    <variable name="db_postgres_test_variable_source_with_name_only" source="dbPostgres" distribution="ordered"/>

    <generate name="user" count="10" target="ConsoleExporter">
        <key name="id" script="db_postgres_test_variable_source_with_name_only.id"/>
        <key name="name" script="db_postgres_test_variable_source_with_name_only.text"/>
        <key name="number" script="db_postgres_test_variable_source_with_name_only.number"/>
    </generate>
</setup>

In diesem Beispiel:

• werden zwei Skripte ausgeführt – ein SQL-Skript zur Einrichtung der Datenbank und ein Python-Skript zur Handhabung zusätzlicher benutzerdefinierter Logik.
• Nach dem Ausführen der Skripte werden Daten aus der Datenbank geholt und zur Generierung von Ausgabedatensätzen verwendet.

Beispiel 3: Verwendung von <execute> mit einem komplexen DB-Mapping-Szenario

<setup>
    <include uri="conf/base.properties"/>
    <memstore id="mem"/>

    <database id="mapping" environment="environment"/>

    <include uri="1_prepare.xml"/>

    <execute uri="script/lib_glob.scr.py"/>

    <include uri="2_mapping.xml"/>
</setup>

In diesem Fall:

• lädt das <execute>-Element ein globales Skript (lib_glob.scr.py) in den Kontext, um zusätzliche Logik oder Dienstprogramme bereitzustellen, die für den Generierungsprozess benötigt werden.
• Das 1_prepare.xml-Skript richtet das Datenbankschema und die Tabellen ein.

Beispiel 4: Ausführen eines Python-Skripts für benutzerdefinierte Logik

<setup>
    <database id="sourceDB" system="postgres"/>

    <execute uri="scripts/prepare_database.sql" target="sourceDB"/>

    <execute uri="scripts/my_custom_logic.py"/>

    <generate name="user_data" source="sourceDB" target="CSV">
        <key name="user_id" generator="IncrementGenerator"/>
        <key name="user_name" script="random.choice(['Alice', 'Bob', 'Charlie'])"/>
    </generate>
</setup>

In diesem Beispiel:

• richtet ein SQL-Skript (prepare_database.sql) die Datenbank ein.
• Anschließend wird ein Python-Skript (my_custom_logic.py) ausgeführt, das möglicherweise benutzerdefinierte Logik oder Vorverarbeitungsschritte einführt.
• Daten werden aus der Datenbank generiert und als CSV exportiert.

Best Practices für die Verwendung von <execute>

1. Verwendung für externes Setup oder Logik: Das <execute>-Element ist ideal für die Vorbereitung von Datenbanken, das Laden externer Skripte oder die Einführung benutzerdefinierter Logik, die vor oder während der Datengenerierung ausgeführt werden muss.
2. Reihenfolge der Ausführung: Stelle sicher, dass Skripte in der richtigen Reihenfolge ausgeführt werden, insbesondere wenn Abhängigkeiten zwischen ihnen bestehen (z. B. Vorbereitung eines Datenbankschemas vor der Datengenerierung).
3. Zielauswahl: Gib für SQL-Skripte immer das korrekte Datenbank-target an, auf dem das Skript ausgeführt werden soll.
4. Benutzerdefiniertes Skripting: Nutze Python oder andere Skriptsprachen, um die Funktionalität und Logik des Datengenerierungsprozesses durch das Einbinden externer Skripte zu erweitern.

---

<data-warehouse>

Das <data-warehouse>-Element definiert Data-Warehouse-Konfigurationen innerhalb des DATAMIMIC-Konfigurationsmodells.

Attribute

• id: Gibt den eindeutigen Bezeichner für das Data Warehouse und die ID der konfigurierten Systemumgebung an.

Beispiel

<data-warehouse id="warehouse1" />

<kafka-exporter> und <kafka-importer>

Das <kafka-exporter>-Element definiert Kafka-Producer-Verbindungen innerhalb des DATAMIMIC-Konfigurationsmodells. Das <kafka-importer>-Element definiert Kafka-Consumer-Verbindungen innerhalb des DATAMIMIC-Konfigurationsmodells.

Gemeinsame Attribute

• id: Gibt den eindeutigen Bezeichner für den Kafka-Producer an.
• bootstrap_servers: Gibt die Kafka-Bootstrap-Server (Cluster-Knoten) an, die für die Verbindung zum Kafka-Cluster erforderlich sind.
• topic: Gibt den Topic-Namen an, unter dem Nachrichten produziert werden sollen.
• format: Gibt das Format der zu produzierenden Nachrichten an.
• security_protocol: Definiert das Sicherheitsprotokoll, das für die Kommunikation verwendet werden soll (z. B. PLAINTEXT, SSL, SASL_SSL).
• system: Definiert den Systemtyp des Kafka-Producers.
• environment: Definiert die Umgebung des Kafka-Producers.
• schema: Gibt das Schema an, das zur Serialisierung von Nachrichten verwendet wird.
• registry.url: Gibt die URL der Schema-Registry an.
• partition: Gibt die Partitionsnummer an, an die Nachrichten gesendet werden sollen.
• allow.auto.create.topics: (True/False) - Gibt an, ob die automatische Erstellung von Topics erlaubt werden soll, wenn sie nicht existieren.
• request.timeout.ms: Gibt die maximale Wartezeit für den Abschluss einer Anfrage an.
• client.id: Gibt einen Namen für diesen Client an.
• send.buffer.bytes: Die Größe des TCP-Sendepuffers (SO_SNDBUF), der beim Senden von Daten verwendet wird.
• receive.buffer.bytes: Die Größe des TCP-Empfangspuffers (SO_RCVBUF), der beim Lesen von Daten verwendet wird.
• max.in.flight.requests.per.connection: Anfragen werden an Kafka-Broker bis zu dieser maximalen Anzahl von Anfragen pro Broker-Verbindung weitergeleitet.
• reconnect.backoff.ms: Die Zeit in Millisekunden, die gewartet wird, bevor versucht wird, eine Verbindung zu einem bestimmten Host wiederherzustellen.
• reconnect.backoff.max.ms: Die maximale Zeit in Millisekunden, die beim Wiederverbinden mit einem Broker, der wiederholt keine Verbindung herstellen konnte, gewartet wird.
• connections.max.idle.ms: Gibt an, dass inaktive Verbindungen nach der Anzahl der Millisekunden geschlossen werden.
• retry.backoff.ms: Gibt die Wartezeit vor dem erneuten Versuch einer fehlgeschlagenen Anfrage an (in Millisekunden).
• metadata.max.age.ms: Gibt den Zeitraum in Millisekunden an, nach dem wir eine Aktualisierung der Metadaten erzwingen.
• metrics.num.samples: Gibt die Anzahl der Stichproben an, die zur Berechnung von Metriken geführt werden.
• metrics.sample.window.ms: Gibt das maximale Alter in Millisekunden von Stichproben an, die zur Berechnung von Metriken verwendet werden.
• api.version: Gib an, welche Kafka-API-Version verwendet werden soll. Wenn nicht definiert, versucht der Client, die Broker-Version durch Überprüfen verschiedener APIs abzuleiten. Unterschiedliche Versionen ermöglichen unterschiedliche Funktionalitäten. (z. B. 0.10.2)
• api.version.auto.timeout.ms: Gib die Anzahl der Millisekunden an, nach denen eine Timeout-Exception vom Konstruktor ausgelöst wird, wenn die Broker-API-Version geprüft wird. Gilt nur, wenn api_version nicht definiert ist.
• ssl.key.password: Gibt das Passwort für den SSL-Schlüssel an.
• ssl.truststore.location: Gibt den Speicherort des SSL-Truststores an.
• ssl.truststore.password: Gibt das Passwort für den SSL-Truststore an.
• ssl.truststore.type: Gibt den Typ des SSL-Truststores an.
• ssl.truststore.certificate: Gibt die Zertifikate für den SSL-Truststore an.
• ssl.protocol: Gibt das SSL-Protokoll an (z. B. TLSv1.2, TLSv1.3).
• ssl.keystore.location: Gibt den Speicherort des SSL-Keystores an.
• ssl.keystore.type: Gibt den Typ des SSL-Keystores an.
• ssl.keystore.key: Gibt den Schlüssel für den SSL-Keystore an.
• ssl.keystore.password: Gibt das Passwort für den SSL-Keystore an.
• ssl.cipher.suites: Gibt die Liste der Ciphers für SSL-Verbindungen an (z. B. DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA:ECDHE-ECDSA-AES128-GCM-SHA256).
• sasl.mechanism: Gibt den SASL-Mechanismus an, der für die Authentifizierung verwendet wird (z. B. PLAIN, SCRAM-SHA-256).
• sasl.jaas.config: Gibt die JAAS-Konfiguration für SASL an.
• sasl.kerberos.service.name: Gibt den Kerberos-Dienstnamen für den SASL-Mechanismus-Handshake an.

---

<kafka-exporter> Attribute

• encoding: Gibt die Kodierung der Nachrichten an.
• acks: Gibt die Anzahl der Bestätigungen an, die der Producer vom Leader erhalten muss, bevor eine Anfrage als abgeschlossen betrachtet wird (z. B. 0, 1, all).
• compression.type: Gibt den Komprimierungstyp für alle vom Producer generierten Daten an (z. B. gzip, snappy, lz4, None).
• retries: Gibt die Anzahl der Wiederholungsversuche bei fehlgeschlagenen Sendevorgängen an (Standard ist 0).
• batch.size: Gibt die Batch-Größe in Bytes an.
• linger.ms: Gibt die Wartezeit vor dem Senden eines Batches an.
• buffer.memory: Gibt die Gesamtmenge an Speicher in Bytes an, die der Producer zum Puffern von Datensätzen verwenden soll, die auf das Senden an den Server warten.
• max.request.size: Gibt die maximale Größe einer Anfrage an.
• max.block.ms: Gibt die maximale Blockierzeit beim Senden einer Nachricht an.

---

<kafka-importer> Attribute

• pageSize: Gibt die Seitengröße für das Abrufen von Nachrichten an.
• decoding: Gibt die Dekodierung der Nachrichten an.
• enable.auto.commit: (True/False) - Wenn True, wird der Offset des Consumers regelmäßig im Hintergrund committet.
• auto.offset.reset: Gibt die Offset-Reset-Richtlinie an (z. B. earliest, latest).
• group.id: Gibt die Consumer-Gruppen-ID an.
• heartbeat.interval.ms: Gibt das Intervall zwischen Heartbeats an den Kafka-Broker an (in Millisekunden).
• auto.commit.interval.ms: Gibt die Anzahl der Millisekunden zwischen automatischen Offset-Commits an.
• check.crcs: (True/False) - Gibt an, ob die CRCs der konsumierten Datensätze überprüft werden sollen.
• fetch.max.bytes: Gibt die maximale Anzahl von Bytes an, die in einer einzigen Anfrage abgerufen werden.
• fetch.max.wait.ms: Gibt die maximale Wartezeit für das Abrufen von Datensätzen an (in Millisekunden).
• fetch.min.bytes: Gibt die minimale Anzahl von Bytes an, die in einer einzigen Anfrage abgerufen werden sollen.
• max.partition.fetch.bytes: Gibt die maximale Anzahl von Bytes an, die pro Partition in einer einzigen Anfrage abgerufen werden.
• max.poll.records: Gibt die maximale Anzahl von Datensätzen an, die in einem einzigen Poll zurückgegeben werden.
• max.poll.interval.ms: Gibt das maximale Intervall zwischen Polls an, bevor der Consumer als tot betrachtet wird (in Millisekunden).
• exclude.internal.topics: (True/False) - Ob Datensätze von internen Topics (wie Offsets) dem Consumer zugänglich gemacht werden sollen. Wenn auf True gesetzt, ist der einzige Weg, Datensätze von einem internen Topic zu erhalten, das Abonnieren dieses Topics.
• session.timeout.ms: Das Timeout, das zur Erkennung von Ausfällen bei der Nutzung der Gruppenverwaltungsfunktionen von Kafka verwendet wird. Der Consumer sendet periodische Heartbeats, um seine Liveness dem Broker anzuzeigen. Wenn vor Ablauf dieses Session-Timeouts keine Heartbeats vom Broker empfangen werden, entfernt der Broker diesen Consumer aus der Gruppe und initiiert ein Rebalance. Beachte, dass der Wert im zulässigen Bereich liegen muss, wie in der Broker-Konfiguration durch group.min.session.timeout.ms und group.max.session.timeout.ms konfiguriert.
• consumer.timeout.ms: Die Anzahl der Millisekunden, die während der Nachrichteniteration blockiert wird, bevor StopIteration ausgelöst wird.

Beispiel

<kafka-exporter id="kafkaSsl" system="kafkaSsl" environment="environment"
                client.id="kafka-client-datamimic" acks="1" compression.type="gzip"
                retries="1" batch.size="16384" linger.ms="0" buffer.memory="33554432"
                request.timeout.ms="30000" receive.buffer.bytes="32768" send.buffer.bytes="131072"/>

<kafka-importer id="kafka_importer" system="kafkaSsl" environment="environment" 
                client.id="kafka-client-datamimic" enable.auto.commit="False" auto.offset.reset="earliest"
                group.id="datamimic" decoding="UTF-8" request.timeout.ms="30000" 
                send.buffer.bytes="131072" receive.buffer.bytes="32768"/>

---

<object-storage>

Das <object-storage>-Element definiert Object-Store-Konfigurationen innerhalb des DATAMIMIC-Konfigurationsmodells.

Attribute

• id: Gibt den eindeutigen Bezeichner für den Object Store und die ID der konfigurierten Systemumgebung an.

Beispiel

<object-storage id="azure" />

<generate name="external_source_1" exportUri="/static_dir/static_file.json" container="test-datasource"
              storageId="azure"
              target="ConsoleExporter, JSON" count="3">
    <key name="id" generator="IncrementGenerator"/>
    <key name="name" generator="GivenNameGenerator"/>
    <key name="email" generator="EmailAddressGenerator"/>
</generate>

<generate name="external_source_2"
              container="test-datasource"
              storageId="azure"
              target="ConsoleExporter,
              JSON, CSV, TXT, XML" count="3">
    <key name="id" generator="IncrementGenerator"/>
    <key name="name" generator="GivenNameGenerator"/>
    <key name="email" generator="EmailAddressGenerator"/>
</generate>

<object-storage id="aws" />

<generate name="external_source_xml" bucket="datamimic-test-01" sourceUri="test-datasource/book.template.xml"
              source="aws" target="ConsoleExporter"/>