Siehe auch Abschnitte Datei für Struktur analysieren und XML to XSD.

DTD- bzw. XSD-Schemadateien können sowohl für die Erstellung der Quell- als auch der Zielstruktur herangezogen werden. Hinweis: Dieser Vorgang wirkt sich nur auf die Erstellung der Quell- oder Zielstruktur aus und nicht auf die Parser-Einstellungen.

images/download/attachments/169629427/489-version-1-modificationdate-1707457392184-api-v2.png

(1) Gibt den Element-Namen an, unterhalb dessen die Vorlage geparst werden soll. Hinweis: Sie können hier den Platzhalter data (klein geschrieben) verwenden, um das Root-Element der XML-Schema-Definition anzugeben. Das funktioniert aber nur, wenn es nur ein Root-Element gibt (was für ein wohlgeformtes XML auch so sein sollte), ansonsten müssen Sie explizit einen Element-Namen angeben.

(2) Folgende Optionen stehen zur Verfügung.

createGroupNode	Falls true, dann erstelle in der Struktur einen group-Knoten für choices und sequences in der XSD-Datei.
forceMinZero	Falls true, dann wird für die Eigenschaft "Minimum" der Wert 0 erzwungen.
ignoreEnums	Falls true, dann ignoriere simple XSD-Enums (enumeration).
ignoreFieldTypes	Falls true, dann ignoriere simple XSD-Datentypen, d. h. alle Felder werden als Typ String angelegt. Falls false, dann werden die in der Schema-Datei angegebenen Datentypen beachtet.
maxDuplicatedElementCount	Legt die Anzahl der maximal erlaubten Elemente mit selbem Namen fest. Damit kann man also auch die maximale Verschachtelungstiefe gleicher Elemente wie z. B. /Orders/Order/Order/Order... beschränken.
maxRecursionDepth	Legt die maximale Rekursionstiefe fest (also wenn ein Element sich selbst in seiner Definition verwendet). Default: 1. Wichtiger Hinweis: Bitte nur mit Vorsicht ändern, da es hier schnell zu einem Speicherüberlauf kommen kann!
noAttributes	Falls true, dann werden keine Attribute importiert.
noParsingRemarks	Falls true, dann werden keine remarks und allowed values zurückgegeben (ist bei großen XSDs sinnvoll).
skipNamespaceDefinition	Falls true, dann wird die Eigenschaft XML Namespace für Knoten und Felder nicht gefüllt.

(3) Ziehen Sie die XSD-Datei einfach in dieses Feld oder drücken Sie den Button, um eine Datei aus dem Dateisystem auszusuchen. Aus der Vorlage wird dann automatisch die Quellstrukur erstellt. Hinweis: Das Laden der Vorlage überschreibt eine bereits vorhandene Quellstruktur!

Beispiel

Gegeben sei folgende XSD-Datei.

<?xml version="1.0" encoding="UTF-8"?>
<s:schema xmlns:s="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified">
  <s:element name="person" minOccurs="0" maxOccurs="unbounded">
    <s:complexType>
      <s:choice>
        <s:element name="employee" type="s:string" minOccurs="0" maxOccurs="1"/>
        <s:element name="member" type="s:string" minOccurs="0" maxOccurs="1"/>
      </s:choice>
    </s:complexType>
  </s:element>
</s:schema>

Die entstehenden Quellstrukturen mit der Einstellung createGroupNode=false (4) bzw. createGroupNode=true (5) sind in der folgenden Abbildung zu sehen. Der Vorteil von createGroupNode=false ist, dass Die XML-Daten so 1:1 gemappt werden können.

images/download/attachments/169629427/491-version-1-modificationdate-1707457392181-api-v2.png

images/download/attachments/169629427/492-version-1-modificationdate-1707457392180-api-v2.png

DTD/XSD mit Referenzen auf andere Definitionsdateien

In DTD- und XSD-Dateien werden häufig andere DTD- bzw. XSD-Dateien referenziert. Damit diese Referenzen von Lobster_data aufgelöst werden können, müssen die referenzierten Dateien im Installationsverzeichnis ./ (wenn Importanweisung ohne Pfadangabe) bzw. relativ zu ./ (wenn Importanweisung mit Pfadangabe) abgelegt werden.

Das folgende Listing zeigt ein Beispiel für eine DTD-Datei, in der weitere DTD-Dateien referenziert werden. Damit die beiden Dateien von Lobster_data gefunden werden, müssen diese wie folgt abgelegt
werden.

Die Datei Schema1.dtd muss im Verzeichnis ./ liegen.
Die Datei Schema2.dtd muss im Verzeichnis ./dir2 liegen.

<!ENTITY % NMGLOBAL SYSTEM "Schema1.dtd">
<!ENTITY % NMGLOBAL SYSTEM "dir2/Schema2.dtd">

Das folgende Listing zeigt ein Beispiel für eine XSD-Datei, in der weitere XSD-Dateien referenziert werden. Damit die beiden Dateien von Lobster_data gefunden werden, müssen diese wie folgt abgelegt werden.

Die Datei Schema1.xsd muss im Verzeichnis ./../common liegen. Hinweis: Mit .. wird ins Oberverzeichnis gewechselt, also hier ins Oberverzeichnis des Installationsverzeichnisses.
Die Datei Schema2.xsd muss im Verzeichnis ./ liegen.

<xs:include schemaLocation="../common/Schema1.xsd"/>
<xs:include schemaLocation="Schema2.xsd"/>

Vorsicht mit Datentyp Timestamp

Wenn beim Strukturimport aus DTD/XSD die Datentypen beachtet werden, ist es empfohlen nachfolgend zu überprüfen, ob die Typen richtig übernommen wurden und insbesondere, ob gegebenenfalls erforderliche Formatvorlagen richtig übernommen wurden. Besonders Timestamp-Felder sollten Sie überprüfen.

Die native Darstellung eines Zeitstempels in Lobster_data ist yyyy-MM-dd HH:mm:ss.SSS. Bei abweichender Darstellung muss die Formatvorlage entsprechend angepasst werden. Die für XML empfohlene Darstellung als W3CDTF, die man an dem Großbuchstaben T zwischen Datum und Uhrzeit und der zwingend angefügten Zeitzone erkennt, kann in Lobster_data nur mit Funktionen gewandelt werden. Bitte ändern Sie in diesem Fall den Feldtyp zu String und führen Sie die Umwandlung mit der entsprechenden Funktion durch.

Hinweis: Bitte beachten Sie bei der Konzeption Ihrer EDI-Prozesse, dass eine Datums-/Zeitangabe ohne Zeitzone für eine überregionale Firma unzureichend ist. Beispiele für vollständige Zeitstempel-Daten wären z. B. die folgenden.

W3CDTF-Form	2013-04-20T14:30:00+02:00 mit Wandlung per Funktion, Feldtyp String.
Lobster_data	2013-04-20 14:30:00+0200 mit Vorlage yyyy-MM-dd HH:mm:ssZ, Feldtyp Timestamp.
SAP-Stil	20130420143000+0200 mit Vorlage yyyyMMddHHmmssZ. Der Wert muss in der Regel aus mehreren String-Feldwerten zusammengesetzt werden, also auch in der Funktion auf Zielseite.