THEMA: XML Quellstruktur mit mehreren Elementen

Guten Tag,

ich habe folgenden Fall im XML

<ARTICLE>
<SUPPLIER_AID>0815-1543</SUPPLIER_AID>
<ARTICLE_DETAILS>
<DESCRIPTION_SHORT>Artikelbeschreibung Kurz</DESCRIPTION_SHORT>
<EAN>1234567890123</EAN>
<ARTICLE_FEATURES>
<REFERENCE_FEATURE_SYSTEM_NAME>PROFICLASS-5.0</REFERENCE_FEATURE_SYSTEM_NAME>
<REFERENCE_FEATURE_GROUP_ID>AAA334c003</REFERENCE_FEATURE_GROUP_ID>
<FEATURE>
<FNAME>AAB996f001</FNAME>
<FVALUE>AAC713v001</FVALUE>
<FDESCR>Materialzusammensetzung</FDESCR>
<FVALUE_DETAILS>Kunstfaser</FVALUE_DETAILS>
</FEATURE>
<FEATURE>
<FNAME>AAB748f001</FNAME>
<FVALUE>Wert des zweiten Features</FVALUE>
<FUNIT>g/m²</FUNIT>
<FDESCR>Materialgewicht</FDESCR>
</FEATURE>
</ARTICLE_FEATURES>
</ARTICLE>

Es ist nicht immer so, dass ein <ARTICLE> genau zwei <FEATURE> hat. Er kann zwischen Null und 100 <FEATURE> haben (theoretisch). In einer ganzen XML sind dann auch natürlich viele <ARTICLE> und nicht nur einer.

Die Ausgabe soll so sein, dass in Excel in der ersten Spalte die Information aus <SUPPLIER_AID> steht. Damit kann ich wissen, zu welchem Artikel das Feature jetzt kommt. Und in den vier Folgespalten dann <FNAME>, <FVALUE>, <FUNIT> und <FDESCR>.

Beispielausgabe:

Artikel	Attributsnummer	Wert	Einheit	Attributsbeschreibung
0815-1543	AAB996f001	AAC713v001		Materialzusammensetzung
0815-1543	AAB748f001	Wert des zweiten Features	g/m²	Materialgewicht

Aktuell bekommen wir immer das <FEATURE>, das wir gemappt haben. Also bei zwei Attributen können wir das erste Mappen und bekommen dann auch im Ergebnis von jedem <ARTICLE> nur das erste Feature. Mappen wir das zweite, dann bekommen wir immer das zweite und so weiter. Aktuell behelfen wir uns, indem wir 7 Mappings haben. Also jeweils ein Mapping für das erste <FEATURE>, ein Mapping für das zweite <FEATURE> und so weiter. Die 7 Ergebnisse schmeißen wir dann zusammen und haben es. Aber ich glaube, so ist es nicht gedacht.
Was machen wir falsch?

Viele Grüße und schon mal vorab vielen Dank!

Manfred Scheunemann

Hallo Herr Scheunemann,

das ist machbar, aber es könnte eine Fleißarbeit werden Das Problem ist derzeit, dass der XML Adapter noch keine dynamischen XML (Unter)Strukturen/Knoten verarbeiten kann. In Ihrem Fall die XML Knoten ARTICLE_FEATURES 0 bis theoretisch 100.

Die Artikel Knoten können problemlos verarbeitet werden. Wenn Sie nun die Features verarbeiten möchten, müssen Sie derzeit im XML Adapter auf der READ Seite so viele Features Knoten anlegen wie Sie maximal verarbeiten möchten. Beim Auslesen der XML Struktur werden aus dem ersten Artikel Record alle verfügbaren Feature Konten automatisch in der Definition angelegt.

Ich habe Ihnen im Anhang dazu mal ein Beispiel aufbauend auf Ihre XML Datei erstellt. Hier werden 2 Artikel (dynamisch) mit jeweils 3 Features (statisch) ausgelesen. Das Problem ist jetzt, dass der FlowHeater diese Struktur pro Artikel als eine Zeile bzw. Datensatz verarbeitet. Damit die einzelnen Features als separate Zeilen/Sätze exportiert werden können ist im Anschluss ein weiterer Zwischenschritt notwendig.
Hinweis: Beim Lesen der XML Daten ignoriert der FlowHeater automatisch nicht vorhandenen Feature XML Unterknoten!

Zum Vorgehen)
Im ersten Step wird mittels des XML Adapters pro Artikel eine Zeile in eine CSV Datei Exportiert. In der letzten CSV Spalte landen alle Features mit Trennzeichen getrennt. Jedes Feature wird mit dem Ternnzeichen „|“ getrennt abgelegt. Die einzelnen Werte jedes Features werden hier mit dem Trennzeichen „#“ getrennt hinterlegt.

z.B. Feature1_Name#Feature1_Value|Feature2_Name#Feature2_Value|…

Hinweis: Die Werte werden mittels mehrerer String Append Heater zu einer Spalte zusammengefasst

Im zweiten Step wird diese CSV Datei dann so aufbereitet, dass die pro Feature Record eine separate Zeile in eine CSV Datei geschrieben wird. Um das zu erreichen wird der GroupOut Heater benötigt, sowie pro Feature Wert ein .NET Script Heater mit einem speziell angepassten Skript.
Der GroupOut Heater legt im Prinzip x identische Kopien der gerade aktiven CSV Zeile an, die dann nacheinander verarbeitet werden. Hier müssen Sie genau so viele Kopien anlegen wie Feature XML Konten in der ersten Definition angegeben wurden. Der AutoID Heater zählt nun welche Kopie aktuell bearbeitet wird. Die . NET Script Heater benötigen diesen Wert um aus der CSV Spalten mit allen Features das aktuell benötigte Feature zu extrahieren und der entsprechend Spalte zuzuweisen. Im Beispiel wurden im Skript Kommentare hinzugefügt um hier evtl. Änderungen vornehmen zu können.

Dieses Vorgehen müsste so jetzt pro weiteren Feature Knoten nach dem gleichen Schema angepasst werden

PS: Das von Ihnen gepostete XML Beispiel wies Fehler auf, das habe ich im Beispiel korrigiert.

Hallo Herr Stark, sie schreiben "Das Problem ist derzeit, dass der XML Adapter noch keine dynamischen XML (Unter)Strukturen/Knoten verarbeiten kann." Wird das kommen, bzw. ist das in Planung? Grüße J.Jakob

Hallo Herr Jakob,

die Entwicklung neuer Funktionen im XML Adapter ist stark abhängig von der der Nachfrage und wird dementsprechend auch priorisiert. Ich denke aber bis Ende des Jahres sollte das soweit sein.

Hallo Herr Stark, das gilt vermutlich auch für die angehängte Muster-XML? Dort soll sowohl der Bereich "Kopf", als auch "Positionen" eingelesen und nach csv übergeben werden. Mit einem Knoten funtioniert das jeweils, zusammen aber nicht (oder?) Grüße Jesco Jakob

Hallo Herr Jakob,

nicht ganz. Dafür müsste eine Vor- oder Nachgelagerte Definition ausgeführt werden. Das würde auch jetzt bereits funktionieren.

Das Problem ist, dass XML sehr komplex werden kann und der FlowHeater Satzbezogen arbeitet. Wenn wie in Ihrem Fall die Kopf/Header Daten sich in einem eigenen Knoten befinden ist es einfacher diesen separat auszulesen.

Die oben beschriebene Umsetzung geht davon aus, dass ausgehend von einem XML Knoten alle weiteren dynamisch gelesen werden so dass ein logischer Satz generiert werden kann.

Guten Morgen Herr Stark,
"Wenn wie in Ihrem Fall die Kopf/Header Daten sich in einem eigenen Knoten befinden ist es einfacher diesen separat auszulesen".
Das hieße aber auch, dass diese Inhalte dann in einer separaten csv ausgegeben werden würden, richtig? Ich bräuchte aber sowohl die "Kopf-", als auch die "Postitionen" Informationen in EINER csv. Ich kann ja aber imme nur einen Knoten in der XPath Eingabezeile setzen!?

Hallo Herr Jakob,

Sie können sich aber in der zweiten Definition die geschriebenen CSV Daten der ersten Definition laden und ausgeben.

Wenn es sich um XML Kopf bzw. Header Informationen handelt sollte die erste CSV Datei lediglich eine Zeile enthalten. Diese laden Sie in der zweiten Definition über den File Heater und fügen den Output einem Feld hinzu. Das ist der einfachste Fall wie Sie Daten aus mehreren läufen miteinander kombinieren können. Im Anhang finden Sie ein kleines Beispiel dazu.

Oder aber hier ein Beispiel wie mehrere Datenquellen miteinander kombiniert werden können: CSV und Excel Daten über SQLite Datenbank zusammenführen

Hallo Herr Stark, ich habe leider noch immer ein Verständnisproblem. Wir haben das XML nun etwas modifiziert (kopf und daten befinden sich nun auf der gleichen Ebene). Im Kern möchte ich gerne sowohl die Kopf ("kopf"), als auch die Positionen ("positionen/position")- diese sind variabel in der Anzahl- in eine csv überführen.
Aktuell funktioniert das perfekt mit den positionen. Hier bekomme ich, der Anzahl entsprechend, mehrere Zeilen untereinander. Sobald ich aber in den darüberliegenden Konten wechsle "kopf_posten_und_daten" und die Definition ausführe, bekomme ich lediglich eine Zeile ausgegeben (1.Position der "x"-Positionen). Stehe hier echt auf dem Schlauch ;-( Grüße J.Jakob

Hallo Herr Jakob,

das ist das was noch nicht geht, das der FlowHeater nicht dynamisch liest sondern das was im XML Adapter definiert wurde. In Ihrem Fall müssen das hier beschrieben vorgehen wählen. Also zuerst die XML Header/Kopf Informationen lesen und in eine CSV Datei zwischenspeichern und anschließend die Positionen verarbeiten und ggf. diese mit den CSV Daten anreichen, z.b. CSV Lookup

Hallo Herr Stark, ich hab`s nun verstanden um umgesetzt Etwas "unelegant", scheint aber zu funktionieren. Gibt es die Möglichkeit, den Namen der generierten csv Datei dynamisch zu vergeben? Viele Grüße J.Jakob

Dynamische Dateinamen über FlowHeater Parameter unterstützt sowohl der TextFile Adapter sowie der String Replace Heater .

z.B. C:\Temp\$IMPORT-FILE$.csv

Ein Beispiel finden Sie hier: Dateiname als Parameter

Guten Tag,

ich weiß nicht 100%ig, ob meine Frage in die gleiche Richtung geht. Ich nehme es aber an:

Ich habe einen Tag der mit IfThenElse Heatern aus einer XML ausgelesen werden. Die Logik ist ganz einfach:

Steht im Tag DOCUMENT_TYPE der Wert ABG so sende den Wert aus DOCUMENT_NAME an ein Feld auf der Read Seite (Bild 1)



Der Wert kann aber öfter in dem Tag vorkommen, jedoch dann mit unterschiedlichen Einträgen im Feld DOCUMENT_NAME. Aktuell trenne ich die Einträge mit einem Leerzeichen und es wir in das Feld Grafikfile auf der Write-Seite eingefügt.

Ich möchte nun aber die Werte nicht in einem Feld mit einem Leerzeichen getrennt stehen haben, sondern (sofern es mehrere Einträge gibt) diese dann weiter in Bild2, Bild3 eingefügt haben:

1. mal ABG --> Feld Grafikfile
2. mal ABG --> Feld Bild2
3. mal ABG --> Feld Bild3
usw.

Wie bekomme ich das am besten gelöst?

Vielen Dank im Voraus!

Hallo Herr Seiffert,

Sie können das mit Hilfe des AutoID Heater und aktivierter Option zum Zählen von gleichen Werten bzw. Eingangsparametern abbilden. Anschließend können über diesen gezählten Wert und einer weiteren IF-THEN-ELSE Bedingung die WRITE Felder gesetzt werden.

Wichtig ist nur, dass hier das Kriterium eindeutig ist. Es genügt nicht nur das Feld mit dem Inhalt „ABG“ zu verwenden. Im Anhang habe ich Ihnen ein kleines Beispiel erstellt. Hier wird zusätzlich zu dem Feldinhalt auch noch das Feld ID als eindeutiges Kriterium übergeben.

Weiterhin wurde im Beispiel eine zusätzliche Abfrage eingebaut, dass die Werte auch wirklich nur ausgegeben werden, wenn im Feld auch nur „ABG“ vorhanden ist.

Schauen Sie sich das Beispiel mal an, ich denke Sie sollten damit zurechtkommen.

Hallo Herr Stark,

das funktioniert nicht wirklich, da in dem von Ihnen erstellten Beispiel auf der Read Seite nur einmal der Wert steht. Ich habe diesen jedoch 26x auf der Read Seite. Ich habe nun versucht es wie folgt darzustellen (im Screenshot sind nur 2 Knoten mit dem möglich ABG Wert angesprochen):


Per E-Mail schicke ich Ihnen einmal die fhd und Beispieldaten.

Hallo Herr Seiffert,

das sind leider derzeit die Grenzen der XML Verarbeitung über den FlowHeater. Das geht aktuell nur mit einem C# Skript (siehe unten) und etwas Fleißarbeit.

Für Ihre Zwecke benötigen Sie 6x den .NET Script Heater und unten stehendes C# Skript. Im Skript müssen Sie lediglich den Bildindex ändern (siehe Kommentar im Skript) der verarbeitet werden soll.

Jeden .NET Script Heater müssen von jedem Knoten die Felder DOCUMENT_TYPE und DOCUMENT_NAME übergeben werden. Achtung Reihenfolge beachten!

Im Anhang finden Sie ein exemplarisches Beispiel dazu.

C# Skript
PS: Sie können etwas mehr Übersichtlichkeit erreichen, wenn Sie den XML  Import auf mehrere Verarbeitungsschritte aufteilen. z.B. zuerst die Basis Produktdaten in die Access Datenbank  importieren und anschließend über die Produkt ID (SUPPLIER_PID) die Bildinformationen per UPDATE aktualisieren.

Hallo Herr Stark,

die Fleißarbeit war jetzt nicht wirklich eine solche. Man kann glücklicherweise das Script mit den Verbindungen auf der Read Seite ja bequem kopieren und einfügen nachdem man es einmal erstellt und verbunden hat. Sieht dann auch nicht sooo unübersichtlich aus finde ich



Auf jeden Fall funktioniert es mit dem Script wunderbar. Vielen Dank dafür!