EDI-Typüberprüfung (Datenelementüberprüfung)
Die EDI-Empfangspipeline und die EDI-Sendepipeline führen die EDI-Überprüfung von Datenelementen im Transaktionssatz aus. Diese Überprüfung wird für alle Nachrichten von oder an eine bestimmte Partei über die Vertragseigenschaften dieser Partei auf der Seite Validierung konfiguriert (im Abschnitt Transaktionssatzeinstellungen für X12- oder EDIFACT-Vereinbarungen). Wenn die EDI-Typüberprüfungseigenschaft auf der Seite Validierung nicht ausgewählt ist, werden die in diesem Thema beschriebenen Datenüberprüfungen nicht durchgeführt.
Die EDI-Typüberprüfung wird sowohl für eingehende als auch für ausgehende Nachrichten aktiviert, indem Sie im Dialogfeld Vereinbarungseigenschaften auf der Seite Validierung der Bidirektionalen Vereinbarung auf der Seite Validierung die Eigenschaft EDI-Typüberprüfung auswählen. Diese Eigenschaft ist standardmäßig sowohl für eingehende als auch für ausgehende Nachrichten ausgewählt, sodass die EDI-Überprüfung standardmäßig aktiviert ist.
Überprüfungen
Bei der EDI-Überprüfung durch die EDI-Empfangspipeline oder die EDI-Sendepipeline wird Folgendes überprüft:
Die von den EDI-Eigenschaften des Schemas definierten Datentypen
Längeneinschränkungen
Leere Datenelemente und nachfolgende Trennzeichen
Hinweis
Bei dieser Überprüfung werden keine Codesätze (Enumerationen) und keine minimalen oder maximalen Vorkommen überprüft.
Zeichensätze
Zum Ausführen von EDI-Datenelementüberprüfungen muss für die EDI-Empfangspipeline und die EDI-Sendepipeline der Zeichensatz wie folgt festgelegt werden:
Für EDIFACT wird der Zeichensatz im Datenelement UNB1 der Seite Charset and Separators der Registerkarte One-Way Agreement des Dialogfelds Agreement Properties (Vereinbarungseigenschaften ) oder im Dialogfeld EDIFACT-Fallbackeinstellungen (sofern keine Vereinbarung getroffen wurde) eingerichtet.
Für KEDIFACT wird das Zeichen im Datenelement UNB1 der Seite Charset and Separators der Registerkarte One-Way Agreement des Dialogfelds Agreement Properties (Vereinbarungseigenschaften) auf der Seite Charset and Separators (Zeichensatz und Trennzeichen) wie für EDIFACT festgelegt. Der Wert für das UNB1.1-Element muss auf
KECA
festgelegt werden.Für X12 wird der Zeichensatz für die Nachricht in den Pipelineeigenschaften festgelegt.
Hinweis
Wenn die BizTalk-Laufzeit die EDI-Überprüfung einer Nachricht ausführt, wird der in den Pipelineeigenschaften ausgewählte X12-Zeichensatz verwendet. Die Überprüfung der Eigenschaften, die auf den Seiten des Dialogfelds Vereinbarungseigenschaften eingegeben werden, erfolgt jedoch mithilfe des Zeichensatzes, der auf der Seite Zeichensatz und Trennzeichen dieses Dialogfelds ausgewählt ist. Während der Laufzeit ignoriert die Pipeline den Wert der X12-Zeichensatzeigenschaft Charset und Trennzeichen des Dialogfelds Vereinbarungseigenschaften . Wenn diese beiden Einstellungen nicht identisch sind (d. h. die X12-Zeichensatzeigenschaft im Dialogfeld Vereinbarungseigenschaften ist auf Erweitert festgelegt, während die X12-Zeicheneigenschaft in den Pipelineeigenschaften auf Basic festgelegt ist), können Fehler bei der Nachrichtenüberprüfung auftreten.
Datentypüberprüfung
Für X12 werden im Schema die folgenden EDI-Datentypen mit Anmerkungen für die Überprüfung durch die Disassembler-/Assemblerkomponenten in den Empfangs- oder Sendepipelines versehen: "Numeric", "Decimal", "Identifier, "String", "Date", "Time", "Binary" und" Composite".
Für EDIFACT werden im Schema die folgenden EDI-Datentypen mit Anmerkungen für die Überprüfung durch die Disassembler-/Assemblerkomponenten in den Empfangs- oder Sendepipelines versehen: "Alphabetic", "Numeric", "Identifier", "String" und "Composite".
Längeneinschränkungen
Sowohl für X12 als auch für EDIFACT müssen Elemente oder Unterelemente auf die Längenanforderung (minimale und maximale Länge) überprüft werden. Die Länge ist als die Anzahl verwendeter Zeichenpositionen definiert. Für die Längendefinition werden keine Zeichen und Dezimalschreibweisen verwendet.
Hinweis
Für den Zeichenfolgendatentyp "X12_AN" werden führende Leerzeichen beibehalten, und nachfolgende Leerzeichen sind in jedem Segment zulässig, um die erforderliche Mindestlänge zu erzielen.
Für KECA wird die Länge als Anzahl von Bytes interpretiert. Wenn die Länge z. B. als drei definiert ist, kann das Element oder Unterelement entweder drei 1-Byte-Zeichen oder die Kombination von einem 2-Byte-Zeichen und einem 1-Byte-Zeichen enthalten.
Überprüfung von leeren Datenelementen und nachfolgendem Trennzeichen
Für X12 dürfen als obligatorisch markierte Datenelemente in einer Instanz nicht leer sein, wenn das Segment vorhanden ist. Wenn es sich um ein zusammengesetztes Datenelement handelt, muss mindestens ein Komponentendatenelement einen Wert enthalten.
Für EDIFACT können Datenelemente ohne Werte und bedingte Datenelemente (sowie Unterkomponenten) ausgeschlossen werden. Das Trennzeichen wird jedoch beibehalten.
Nachfolgende Trennzeichen sind weder für X12 noch für EDIFACT erforderlich, sie werden jedoch empfohlen.
Wenn die EDI-Typüberprüfung deaktiviert ist
Wenn Sie die EDI-Typüberprüfung deaktivieren, verarbeitet die EDI-Empfangspipeline oder die EDI-Sendepipeline Datenelemente, die durch die EDI-Typüberprüfung überprüfte Fehler enthalten, ohne die zu verarbeitende Nachricht anzuhalten.
Hinweis
Die strukturelle EDI-Überprüfung wird auch dann durchgeführt, wenn die EDI-Typüberprüfung deaktiviert ist. Ein Austausch, der die grundlegenden strukturellen Überprüfungen nicht besteht, wird angehalten, auch wenn die EDI-Typüberprüfung deaktiviert ist.
Nachfolgend werden einige der Fehler aufgeführt, die verarbeitet werden, ohne die Nachricht anzuhalten:
Ein unerwarteter/nicht definierter Transaktionssatz
Unerwartete/nicht definierte Daten auf Segment-/Schleifen- und Datenelementebene
Optionalität (minimale und maximale Vorkommen) auf Segment-/Schleifen- und Datenelementebene
Verletzung der Längeneinschränkung (minimale/maximale Länge) auf Datenelementebene (Daten, die die maximale Länge überschreiten oder die minimale Länge unterschreiten)
Datentypkonflikt auf Datenelementebene (mit Ausnahme des ID-Datentyps, der über eine eigene Steuerung verfügt)
Ungültige Enumerationsliste auf Datenelementebene
Wenn die XML-Datei Fehler enthält und die EDI-Typüberprüfung auf der Empfangsseite deaktiviert, auf der Sendeseite jedoch aktiviert ist, kann die EDI-Sendepipeline das von der Empfangspipeline erzeugte XML nicht erneut zu einer gültigen EDI-Datei verarbeiten. In diesem Fall generiert die Sendepipeline einen Fehler.
Wenn die EDI-Typüberprüfung deaktiviert ist, behandelt die EDI-Empfangspipeline oder -Sendepipeline Fehler wie folgt:
Unerwartete Daten | Aktion |
---|---|
Unerwarteter/nicht definierter Transaktionssatz | Die EDI-Empfangspipeline oder -Sendepipeline akzeptiert einen Transaktionssatz, auch wenn kein Schema für diesen bereitgestellt wurde. |
Unerwartetes Segment/unerwarteter Datensatz | Die Empfangspipeline generiert ein Tag mit dem entsprechenden Präfix: <UnexpectedSegment_%SegmentID%>. Die Sendepipeline verwendet die ersten ein bis drei Zeichen des XML-Tagnamens als Segmentnamen. |
Unerwartetes einfaches Datenelement | Die Empfangspipeline generiert ein XML-Tag mit einem Präfix, einem Segmentbezeichner und einem Index, der die Position des Datenelements im Segment darstellt: <UnexpectedDataElement_%FieldName%. |
Unerwartetes zusammengesetztes Datenelement | Die Empfangspipeline generiert xml-Tags mit Präfix, Segmentbezeichner und Index, die die Position des Datenelements im Segment darstellen: <UnexpectedCompositeDataElement_%FieldName%. |
Fehlende erforderliche Daten | Die Pipeline behandelt die Daten als optional. |
Verletzung der Längeneinschränkung des Datenelements | Die Pipeline behandelt die ungültige Datenelementlänge als gültig ("Min. Länge" = 0 und "Max. Länge" = "nicht gebunden"). |
Ungültiger Enumerationswert in der Instanz (anwendbar auf den ID-Datentyp) | Die Pipeline ignoriert den Fehler und setzt die Verarbeitung fort. |
Verletzung des maximalen Umfangs in der Instanz | Die Pipeline behandelt diese repetitiven Daten als gültig ("Min. Vorkommen" = 0 und "Max. Vorkommen" = "nicht gebunden"). |
Fehlerberichterstellung
Wenn die EDI-Typüberprüfung deaktiviert ist, meldet BizTalk Server keine Fehler im Ereignisanzeige, sondern eine Warnung. Außerdem meldet die Bestätigung an die Quellpartei "Akzeptiert", wobei in einer X12 997-Bestätigung AK501 und AK901 als "E" und in einer EDIFACT CONTRL-Bestätigung UCI.4, UCM.3 und UCF.4 als "7" festgelegt werden. Hierdurch wird jede Möglichkeit einer Korrektur in späteren Übertragungen ausgeschlossen. Empfänger der Nachricht haben jedoch die Möglichkeit, das Dokument durch manuellen Eingriff zu retten, statt die Nachricht zurückzuweisen oder anzuhalten. Außerdem wird die Edi.ErrorsInTransactionSet
Kontexteigenschaft höhergestuft, wenn einer dieser Fehler von der EDI-Empfangspipeline auftritt. Diese Eigenschaft wird als "True" höher gestuft, wenn EDI-Fehler oder Fehler bei der erweiterten Überprüfung auftreten. Wenn keine Fehler auftreten, wird die Eigenschaft als "False" höher gestuft.
Wenn in der Empfangs- oder Sendepipeline unerwartete Daten auftreten, wird der Fehler auf der übergeordneten Ebene gemeldet, und Fehler untergeordneter Ebenen werden ignoriert:
Unerwartete Daten | Aktion |
---|---|
Unerwarteter Transaktionssatz | Die Bestätigung meldet diesen Fehler und ignoriert nachfolgende Fehler auf Segment-/Schleifen- und Datenelementebene. |
Unerwartetes Segment/unerwartete Schleife | Die Bestätigung meldet diesen Fehler und ignoriert Fehler auf Datenelementebene. |
Unerwartetes Datenelement | Die Bestätigung meldet diesen Fehler und ignoriert zusammengesetzte Fehler in Bezug auf Eigenschaften wie ID, Länge, Vorkommen usw. sowie ggf. Fehler in Bezug auf Felder für zusammengesetzte Datenelemente. |