Single-Import
Der Single-Import stellt die einfachste Möglichkeit für den Import eines einzelnen Objekts pro "Job" dar. Im Unterschied dazu ermöglicht ein Batch-Import die Verarbeitung mehrerer Objekte in demselben "Job".
Die Seite Import bietet einen Überblick zum Zusammenspiel zwischen Lobster Data Platform / Orchestration und Lobster_data und den allgemeinen Aufbau eines Importprofils.
Nachfolgend werden nur die Details zur Konfiguration der Zielstruktur für den Import erklärt, die den Single-Import und den Batch-Import betreffen.
Die für den Single-Import verwendete Struktur entspricht exakt dem Inhalt eines einzelnen batch-Knotens beim Batch-Import. Die folgenden Ausführungen zu den Details in der Struktur gelten daher für beiden Import-Methoden.
In der Praxis kann man auch für den Import einzelner Objekte die Batch-Import-Struktur verwenden. Dann stehen bei Bedarf auch die ausschließlich für den Batch-Import verfügbaren zusätzlichen Funktionalitäten zur Verfügung.
Elemente der Zielstruktur für einen Single-Import
Beim Anlegen eines Importprofils für einen Single-Import wird die Zielstruktur idealerweise ausgehend von der Lobster Data Platform / Orchestration-Vorlage für das core:Import-Objekt erstellt (Details s. Lobster_pro Vorlagen).
Der folgende Screenshot zeigt eine aus der core:Import-Vorlage generierte Zielstruktur, in der - ausgehend vom Originalzustand - dem Feld action_attr der Fixwert CREATE zugewiesen wurde:
Überblick zu den Standardkomponenten der Importstruktur:
|
Komponente |
Typ |
Beschreibung |
Hinweise |
|
action_attr |
Feld/Attribut |
bestimmt die auszuführende Import-Aktion(s. Abschnitt "Import-Aktionen" unten) |
Pflichtangabe |
|
rememberAs_attr |
Feld/Attribut |
speichert eine Referenz auf das aktuelle Objekt unter dem als Textwert angegebenen Namen für einen späteren Zugriff per core:GetObjectFromBatch (Präprozessor) |
optional |
|
event_attr |
Feld/Attribut |
spezifiziert ein Eigenes Aktionsevent, das durch die Import-Aktion DISPATCH_EVENT per Import ausgelöst werden soll |
Pflichtangabe für |
|
eventStorage |
Knoten |
weist Ereignisvariablen im Kontext von DISPATCH_EVENT Werte zu (s. Abschnitt "Eigenes Aktionsevent auslösen" unten) |
optional für |
|
search |
Knoten |
definiert eine Suche, die - sofern überhaupt verwendet - eine eindeutig bestimmte Entität für die Ausführung des Imports liefern muss |
optional |
Definition der Objektstruktur
Die Vorlage enthält keinen Platzhalter für die "Nutzdaten" des Imports, die als zusätzlicher Unterknoten im Knoten "Import" erstellt oder eingefügt werden müssen. Auch dazu können Lobster_pro Vorlagen genutzt werden.
Nachfolgend wird der inhaltlich neutrale Begriff Objektstruktur für diesen Knoten und die enthaltene Teilstruktur verwendet, da sich der konkrete Knotenname in der Regel vom Typ der jeweiligen Entität ableitet.
►HINWEIS◄ Grundsätzlich kann die Zielstruktur eines Importprofils auch mehrere Objektstrukturen beinhalten, sofern sichergestellt ist, dass diese zur Laufzeit strikt alternativ gehandhabt werden. Wenn gewährleistet ist, dass immer nur genau eine der alternativen Objektstrukturen zur Laufzeit greift, können so - z. B. abhängig von Merkmalen der Eingangsdaten - unterschiedliche Entitätstypen auf der Basis desselben Importprofils adressiert werden.
Import-Aktionen
Für den Import muss der Name einer der folgenden Aktionen per Attribut "action" (Feld action_attr) spezifiziert werden:
|
Aktion (action_attr) |
Beschreibung |
|
CREATE |
Der Import soll ein neues Objekt erstellen. Die Angabe einer internen ID (id) innerhalb der Objektstruktur ist dabei optional.
►WICHTIG◄ Im Allgemeinen sollte es unterlassen werden, der neu zu erstellenden Entität explizit eine ID (id ) zuzuweisen, da dies die automatische Erzeugung einer internen ID aushebelt, was zu einem späteren Zeitpunkt Konflikte beim automatischen Zuweisen von IDs verursachen kann. |
|
UPDATE |
Der Import soll ein bestehendes Objekt aktualisieren, das durch explizite Angabe einer id oder durch die Definition einer Suche (search-Knoten) eindeutig identifiziert sein muss.
|
|
CREATE_OR_UPDATE |
Der Import soll das durch die Angabe einer internen ID (id) oder über eine Suche eindeutig identifizierte Objekt erstellen oder aktualisieren.
►WICHTIG◄ Im Allgemeinen sollte es unterlassen werden, der neu zu erstellenden Entität explizit eine ID (id ) zuzuweisen, da dies die automatische Erzeugung einer internen ID aushebelt, was zu einem späteren Zeitpunkt Konflikte beim automatischen Zuweisen von IDs verursachen kann. |
|
CREATE_OR_NOTHING |
Der Import soll ein neues Objekt erstellen, sofern nicht die Bedingung im für diese Aktion notwendigen search-Knoten bereits einen (eindeutigen) Treffer unter den bereits existierenden Objekten liefert.
►WICHTIG◄ Im Allgemeinen sollte es unterlassen werden, der neu zu erstellenden Entität explizit eine ID (id ) zuzuweisen, da dies die automatische Erzeugung einer internen ID aushebelt, was zu einem späteren Zeitpunkt Konflikte beim automatischen Zuweisen von IDs verursachen kann. |
|
UPDATE_OR_NOTHING |
Der Import soll ein bestehendes Objekt aktualisieren, das durch explizite Angabe einer id oder durch die Definition einer Suche (search-Knoten) eindeutig identifiziert sein muss.
|
|
DELETE |
Der Import soll das durch die Angabe einer internen ID (id) oder über eine Suche eindeutig identifizierte Objekt löschen.
|
|
DISPATCH_EVENT |
Anstelle einer generischen Import-Aktion soll ein Eigenes Aktionsevent ausgeführt werden.
|
Eigenes Aktionsevent auslösen
Ein Eigenes Aktionsevent kann per Importprofil mit und ohne Übergabe von Daten (über Variablen und/oder als Objektdaten) an das Event ausgelöst werden. Die unterschiedlichen Varianten werden hier anhand von Beispielen demonstriert:
Variante 1: Eigenes Aktionsevent ohne Übergabe von Daten auslösen:
Im einfachsten Anwendungsfall soll das Importprofil - etwa als Reaktion auf den Eingang einer bestimmten "Nachricht" an Lobster_data von einem anderen System - in Lobster Data Platform / Orchestration ein bestimmtes Eigenes Aktionsevent auslösen, ohne dass dabei Detaildaten ausgetauscht werden müssen.
In diesem Fall könnte die Zielstruktur des Profils so kompakt aussehen wie die folgende:
|
|
|
Das Beispiel ergibt die folgende Zieldatei (ohne Namespace-Deklarationen):
<?xml version="1.0" encoding="UTF-8"?><core:Import ... action="DISPATCH_EVENT" event="XF_TEST_EVENT"></core:Import>Variante 2: Eigenes Aktionsevent mit Übergabe von Daten in Variablen auslösen:
In einem anderen Fall soll demselben Ereignis über eine Variable "eventMode" ein bestimmter Schlüsselwert (hier: "SILENT") mitgegeben werden, auf den in Ereignisbehandlungen reagiert werden kann, z. B. um bestimmte Ausgabefunktionen (Mailversand usw.) zu unterdrücken.
|
|
►HINWEIS◄ Während die Vorlage die Felder key_val und value_val beinhaltet, muss in beiden Fällen das Feld type_attr für die erforderliche Typisierung der Daten ergänzt werden. Der Variablenname ist immer vom Typ xsd:string, für den Wert sind auch andere Typen (u. a. für komplexere Inhalte) Zusätzlich muss jeweils die Eigenschaft "XML Namespace" der Felder auf xsi gesetzt werden. Entscheidend ist, dass die Zieldatei die Daten so wiedergibt, wie sie üblicherweise im "storage" erscheinen. Entsprechende Strukturen können auch über Tests zusammengestellt und per Erstellen einer statischen Zielstruktur in die Zielstruktur überführt werden. |
Das Beispiel ergibt die folgende Zieldatei (ohne Namespace-Deklarationen):
<?xml version="1.0" encoding="UTF-8"?><core:Import ... action="DISPATCH_EVENT" event="XF_TEST_EVENT"> <eventStorage> <data> <entry> <key xsi:type="xsd:string">eventMode</key> <value xsi:type="xsd:string">SILENT</value> </entry> </data> </eventStorage></core:Import>Variante 3: Eigenes Aktionsevent mit Übergabe von Objektdaten auslösen
Wenn die Zieldatei eines Importprofils mit der Import-Aktion DISPATCH_EVENT Daten aus einer Objektstruktur enthält, gelten diese als "Eingabewert" (genauer: "Eingabeobjekt") für das Eigene Aktionsevent. Dann können Ereignisbehandlungen mit diesem Datenkontext arbeiten und u. a. die Typprüfung in der "Prüfenden Regel" nutzen.
Sofern die "Objektdaten" sich auf die ID (id) einer bestehenden Entität beziehen oder der search-Knoten eine Suche definiert, die ein eindeutiges Suchergebnis liefert, gilt die entsprechende Entität als Basis für diesen Datenkontext dem abweichende Inhalte aus der Objektstruktur wie bei einer Aktualisierung überlagert werden. Falls eine angegebene ID nicht existiert oder die Suche kein Ergebnis liefert, dann beinhaltet der Datenkontext nur die expliziten Zuordnungen aus der Objektstruktur. Falls eine durch das Eigene Aktionsereignis angestoßene Ereignisbehandlung die Aktion Änderungen später speichern ausführt, impliziert die DISPATCH_EVENT-Aktion damit quasi eine CREATE_OR_UPDATE-Aktion: Entweder wird eine eindeutig identifizierte existierende Entität aktualisiert oder eine neue angelegt.
►HINWEIS◄ Da die Objektstruktur den Entitätstyp für die im search-Knoten definierte Suche bestimmt, wird eine Suche nicht ausgeführt, wenn die Zieldatei keine Objektdaten beinhaltet. Objektdaten erscheinen aber nur in der Zieldatei, wenn mindestens einem Feld der Objektstruktur per Mapping oder statisch ein Wert zugewiesen wird. Ist dies unerwünscht, weil es die Daten der "gefundenen" Entität übersteuern könnte, sollte die Suche anderweitig, z. B. in einem Berechnungsknoten mit der Funktion Lobster_pro: SearchTask (_data-Funktion) ausgeführt werden, um dann die "gefundene" ID (id) als Wert für das id_attr-Feld der Objektstrukur zuzuweisen.
Beispiel
Der Versand einer bestimmten Nachricht an Lobster_data (von einem externen System) soll per Importprofil die Deaktivierung eines in der Nachricht per "Benutzername" (username) identifizierten Benutzers von Lobster Data Platform / Orchestration auslösen.
Technisch erfordert das eine Aktualisierung des Felds "Active" auf den Wert false für das Benutzerobjekt, dem der betreffende username zugeordnet ist. Dieser ist in Lobster Data Platform / Orchestration per Definition eindeutig.
Konfiguration:
|
|
|
Laufzeit-Beispiel:
Das Profil sendet die folgende Zieldatei an Lobster Data Platform / Orchestration, wenn eine Nachricht eingeht, die spezifiziert, dass ein Benutzer mit dem Benutzernamen TEST deaktiviert werden soll:
<?xml version="1.0" encoding="UTF-8"?><core:Import ... action="UPDATE"> <search> <core:SimplePropertySearch projection="username" compareType="==" stringValue="TEST"></core:SimplePropertySearch> </search> <base:User active="false"> </base:User></core:Import>Sofern ein Benutzer mit dem Benutzernamen TEST existiert, für den Schreibzugriff besteht, wird dieser deaktiviert.