Transaktionskontrolle (trxControl-Atttribut)

Über das Attribut trxControl kann einer der folgenden Modi für die Transaktionskontrolle für den Batch-Import ausgewählt werden:

Antwortverhalten (responsive-Attribut)

Dem Attribut responsive kann ein boolescher Wert zugewiesen werden, um im Kontext eines Funktionsaufrufs (s. Lobster_pro: Import (_data-Funktion)) zu entscheiden, ob die per Batch-Import verarbeiteten Objekte als Rückgabewert der Funktion ausgegeben werden sollen (true) oder nicht (false).

►HINWEIS◄ Falls der Batch-Import als Zielstruktur eines Profils definiert wird, ist dieses Attribut irrelevant.

Attribute für die Fehlerbehandlung

Eingangsagent (Phase 1)

Geeignete Quelldaten können zum Beispiel von www.geonames.org per Download bezogen werden. Die dort bereitgestellte Archivdatei beinhaltet Quelldaten im Textformat (Tab-getrennt, UTF-8), die gut zur Datenstruktur des City-Objekts von Lobster Data Platform / Orchestration passen, wie das im folgenden Abschnitt beschriebene Mapping verdeutlicht. Prinzipiell könnte die Quelldatei durch "Manuelles Hochladen" einem Importprofil zugeführt werden. Alternativ kann auch ein direkter Abruf per HTTP-CronJob eingerichtet werden, wie im folgenden Screenshot zu sehen:

• Im Format der hier angegebenen Datei "allCountries.zip" sind am angegebenen Ort auch spezifische Datenquellen für einzelne Länder erhältlich.

• Beim Download der Zip-Datei muss im Reiter "Basis-Daten" unbedingt die Option "Daten kommen komprimiert an" gesetzt sein:
  
  

  

• Da die Datei allCountries.zip umfangreiche Daten (siebenstellige Anzahl Zeilen) enthält, sollten diese abschnittweise (z. B. in Gruppen von 5000 Zeilen je Datenblatt) verarbeitet werden, um Speicherplatzproblem zu vermeiden. Zu diesem Zweck kann im Profil-Reiter "Basis-Daten" eine Vorverarbeitung der Daten durch einen speziellen "Preparser", den TokenFileSplitter, eingerichtet werden.
  

  

  
  
  Der Preparser wird über eine Konfigurationsdatei parametriert. Ausgehend von einer Vorlage sind hier nur die Parameter in den letzten beiden Zeilen anzupassen. Neben der Anzahl der Zeilen pro Datenblatt (rows) muss eine frei wählbare Markierungszeichenfolge (header) angegeben werden. Der header wird zwischen den echten Quelldatenzeilen an allen Stellen eingestreut, an denen ein neues Datenblatt starten soll.
  

  

  
  
  Das Mapping (s. u.) muss einen "passenden" Knoten (hier: newPage) verwenden, der die als header definierte Zeichenfolge per Satzarterkennung aufgreift und ein neues Datenblatt beginnt. Im Beispiel:
  

  

Parser (Phase 2)

Damit das Splitten der Eingangsdaten in handliche Datenmengen je Datenblatt auch auf die effektive Ausführung des Imports wirkt, müssen in Phase 2 des Profils die Optionen Pro Datenblatt Antwortwege ausführen und IU miteinbeziehen gesetzt sein:

Mit diesen Einstellungen erzeugt das Profil zur Laufzeit für jedes Datenblatt einen eigenständigen Batch-Import-Job, der maximal so viele batch-Knoten beinhaltet, wie per Parameter rows im tokenFileSplitter-Preparser spezifiziert.

Mapping (Phase 3)

Die Quellstruktur (1) muss ausgehend vom importierten Dateiformat aufgebaut werden. Der folgende Screenshot zeigt abwärts von einem city benannten Knoten die anzulegenden Felder mit Datentyp (inkl. Test-Daten). Jede Zeile liefert die Daten für genau ein zu erstellendes Orte-Datenobjekt.

Oberhalb des city-Knotens wurde hier der newPage-Knoten eingehängt, der zum Aufteilen der Quelldaten in Datenblätter dient (s. o.).

►HINWEIS◄ Für die Felder latitude und longitude wurde der Datentyp BigDecimal gewählt, für den in der Felddefinition außerdem eine passende Vorlage für die Umwandlung des Texts in Zahlenwerte gewählt werden muss.

Für den Aufbau der Zielstruktur bietet Lobster_data spezifische Vorlagen (s. Lobster_pro Vorlagen) für die Datenstrukturen von Lobster Data Platform / Orchestration an.

• Zunächst wurde die core:BatchImport-Vorlage (2) mit der Basisstruktur für einen Batch-Import geladen. Im Bild ist für die Transaktionskontrolle bereits der Typ BATCH als Fixwert eingetragen, da die eingelesenen Orte per Batch und nicht einzeln importiert werden sollen.

• Innerhalb des batch-Knotens (3) ist die Aktion CREATE als Fixwert eingetragen, da je eingelesene Zeile beim Import ein neues Orte-Datenobjekt erstellt werden soll. Der batch-Knoten ist mit dem city-Knoten der Quellstruktur per Pfad verbunden, damit er für jede eingelesene "City" wiederholt wird.

• Die Knoten eventStorge und search werden hier nicht benötigt und sind inaktiv gesetzt. Sie könnten auch gelöscht werden.

• Für den City-Knoten (4) wurde wiederum eine der Lobster_pro Vorlagen (base:City) verwendet, die mit der Option Keine Entity Attribute als Unterknoten zum batch-Knoten eingehängt wurde:
  

  

  
  Die Zuordnung der Quelldatenfelder zu den Zielfeldern im City-Knoten ergibt sich selbsterklärend aus den Beschriftungen.

• Die Feldeinstellungen für die "dezimalen" Zielfelder latitude und longitude sollten passend zum Dateninhalt so gewählt werden, dass nicht unbeabsichtigt Nachkommastellen abgeschnitten werden.

►HINWEIS◄ Die Konfiguration für Phase 4 entfällt. Die Phasen 5 und 6 werden wie unter Import nachzulesen eingerichtet. Hier sind keine spezifischen Einstellungen für den Batch-Import erforderlich.

Ergebnisse

Um die Wirkung des hier als Besonderheit eingesetzten tokenFileSplitter-Preparsers zu veranschaulichen, wurde der rows-Wert vorübergehend auf 5 eingestellt und ein Mapping-Test mit einem kleineren Datensatz (nur die "Orte" in Chile) ausgeführt:

• Die Quellstruktur (links) zeigt, dass Datenblätter mit jeweils (maximal) 5 City-Knoten erstellt werden.

• Der erste City-Knoten in der Quellstruktur entspricht dem ersten batch-Knoten in der Zielstruktur (rechts) expandiert und zeigt identische Daten.

Der Batch-Import-Job für das ersten Datenblatt (Record 1 in der Zielstruktur beim Mapping-Test) wäre wie folgt aufgebaut: