Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Die EDI-Empfangspipeline und die EDI-Sendepipeline führen die EDI-Validierung für Transaktionsdatenelemente durch. Diese Überprüfung wird für alle Nachrichten von oder zu einer bestimmten Partei über die Vereinbarungseigenschaften dieser Partei auf der Seite " Überprüfung " konfiguriert (unter dem Abschnitt "Transaktionssatzeinstellungen" für X12- oder EDIFACT-Vereinbarungen). Wenn die EDI-Typüberprüfungseigenschaft nicht auf der Seite " Überprüfung " ausgewählt ist, werden die in diesem Thema beschriebenen Datenüberprüfungen nicht ausgeführt.
Die EDI-Typüberprüfung ist sowohl für eingehende als auch ausgehende Nachrichten aktiviert, indem Sie die Eigenschaft EDI-Typüberprüfung auf der Seite Validierung der Registerkarte für bidirektionale Vereinbarungen im Dialogfeld Vereinbarungseigenschaften auswählen. Für eingehende und ausgehende Nachrichten ist diese Eigenschaft standardmäßig aktiviert, sodass die EDI-Überprüfung standardmäßig aktiviert ist.
Überprüfungen
Wenn die EDI-Empfangspipeline oder die EDI-Sendepipeline DIE EDI-Überprüfung durchführt, überprüft sie Folgendes:
Datentypen gemäß der Definition der EDI-Eigenschaften des Schemas
Längenbeschränkungen
Leere Datenelemente und nachfolgende Trennzeichen
Hinweis
Bei dieser Validierung werden Kodesätze (Enumerationen) oder minimale und maximale Auftreten nicht geprüft.
Zeichensätze
Um EDI-Datenelementüberprüfungen durchzuführen, müssen die EDI-Empfangs- und Sendepipelinen den Zeichensatz wie folgt einrichten:
Bei EDIFACT wird der Zeichensatz im Datenelement UNB1 auf der Seite Zeichensatz und Trennzeichen der Registerkarte für die Einwegvereinbarungseigenschaften des Dialogfelds Vereinbarungseigenschaften oder im Dialogfeld EDIFACT-Fallbackeinstellungen festgelegt, falls keine Vereinbarung festgelegt wurde.
Für KEDIFACT wird das Zeichen im Datenelement UNB1 der Seite "Zeichensatz" und "Trennzeichen " auf der Einweg-Vereinbarungsregisterkarte des Dialogfelds " Vereinbarungseigenschaften " wie für EDIFACT festgelegt. Der Wert für das UNB1.1-Element muss auf
KECAgesetzt werden.Für X12 wird der Zeichensatz für die Nachricht in den Pipelineeigenschaften eingerichtet.
Hinweis
Wenn die BizTalk-Laufzeit die EDI-Überprüfung einer Nachricht durchführt, wird der in den Pipelineeigenschaften ausgewählte X12-Zeichensatz verwendet. Die Überprüfung der eigenschaften, die auf den Seiten des Dialogfelds "Vereinbarungseigenschaften " eingegeben wurden, wird jedoch mithilfe des zeichensatzes ausgeführt, der auf der Seite "Zeichensatz" und "Trennzeichen" dieses Dialogfelds ausgewählt ist. Während der Laufzeit ignoriert die Pipeline den Wert der X12-Zeichensatzeigenschaft auf der Seite Zeichensatz und Trennzeichen im Dialogfeld Vereinbarungseigenschaften. Wenn diese beiden Einstellungen nicht identisch sind (d. h. die X12-Zeichensatzeigenschaft im Dialogfeld "Vereinbarungseigenschaften " wird auf "Erweitert " festgelegt, während die X12-Zeicheneigenschaft in den Pipelineeigenschaften auf " Einfach" festgelegt ist), können Fehler bei der Nachrichtenüberprüfung auftreten.
Datentypüberprüfung
Für X12 werden die folgenden EDI-Datentypen im Schema für die Überprüfung durch die Disassembler- und Assembler-Komponenten in den Empfangs- oder Sendepipelines ausgewiesen: Numerisch, Dezimal, Bezeichner, Zeichenkette, Datum, Zeit, Binär und Verbund.
Für EDIFACT werden die folgenden EDI-Datentypen im Schema für die Überprüfung durch die Disassembler/Assembler-Komponenten in den Empfangs- oder Sendepipelines annotiert: Alphabetisch, Numerisch, Bezeichner, Zeichenkette und Zusammengesetzt.
Längenbeschränkungen
Für X12 und EDIFACT müssen Elemente oder Unterelemente für die Länge (Mindest- und Maximalanforderung) überprüft werden. Die Länge wird als die Anzahl der verwendeten Zeichenpositionen definiert. Die Länge enthält keine Zeichen und Dezimalnotationen.
Hinweis
Für den Datentyp X12_AN Zeichenfolgen werden führende Leerzeichen beibehalten, und nachfolgende Leerzeichen sind in jedem Segment zulässig, um die Mindestlängenanforderung zu erfüllen.
Bei KECA wird die Länge als Anzahl der Bytes interpretiert. Wenn z. B. die Länge als drei definiert ist, kann das Element oder das Unterelement entweder drei Bytezeichen oder die Kombination aus einem 1-Byte-Zeichen und einem Ein-Byte-Zeichen enthalten.
Leere Datenelemente und Validierung nachgestellter Trennzeichen
Bei X12 können datenelemente, die als obligatorisch gekennzeichnet sind, in einer Instanz nicht leer sein, wenn das Segment vorhanden ist. Wenn das Datenelement zusammengesetzt ist, muss mindestens ein Komponenten-Datenelement bewertet sein.
Für EDIFACT können nicht wertbezogene und bedingte Datenelemente (und Unterkomponenten) ausgeschlossen werden; Das Trennzeichen wird jedoch beibehalten.
Nachfolgende Trennzeichen sind für X12 oder EDIFACT nicht erforderlich, 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 mit von der EDI-Typüberprüfung festgestellten Fehlern, ohne die zu verarbeitende Nachricht auszusetzen.
Hinweis
Die EDI-Strukturüberprüfung wird auch dann durchgeführt, wenn die EDI-Typüberprüfung deaktiviert ist. Ein Austausch, der bei den grundlegenden strukturellen Überprüfungen fehlschlägt, wird suspendiert, auch wenn die EDI-Typüberprüfung deaktiviert ist.
Einige der Fehler, die verarbeitet werden, ohne dass die Nachricht angehalten wird, sind:
Unerwarteter/nicht definierter Transaktionssatz
Unerwartete/undefinierte Daten auf Segment-/Schleifen- und Datenelementebene
Optionalität (Min. und Max.) auf Segment-/Schleifen- und Datenelementebene
Längenverstöße (min/max) auf Datenelementebene (Daten mit Länge, die die maximale Oder unter der Mindeststufe überschreiten)
Datentypkonflikt auf Datenelementebene (mit Ausnahme des ID-Datentyps, der über ein eigenes Steuerelement verfügt)
Ungültige Enumerationsliste auf Datenelementebene.
Wenn die EDI-Typüberprüfung auf der Empfangsseite deaktiviert ist, aber auf der Sendeseite aktiviert ist, kann die EDI-Sendepipeline die von der Empfangspipeline erzeugte XML-Datei nicht in eine gültige EDI-Datei verarbeiten, wenn die XML-Datei Fehler enthält. Daher generiert die Sendepipeline einen Fehler.
Wenn die EDI-Typüberprüfung deaktiviert ist, behandelt die EDI-Empfangspipeline oder -Sendepipeline Folgende Fehler:
| Unerwartete Daten | Action |
|---|---|
| Unerwarteter/nicht definierter Transaktionssatz | Die EDI-Empfangs- oder Sendepipeline akzeptiert einen Transaktionssatz, auch wenn kein Schema dafür bereitgestellt wurde. |
| Unerwartetes Segment/Datensatz | Die Empfangspipeline generiert ein Tag mit dem entsprechenden Präfix: <UnexpectedSegment_%SegmentID%>. Die Sendepipeline verwendet die ersten bis drei Zeichen des XML-Tagnamens als Segmentnamen. |
| Unerwartetes einfaches Datenelement | Die Empfangspipeline generiert ein XML-Tag mit einem Präfix, Segmentbezeichner und Index, der die Position des Datenelements im Segment darstellt: <UnexpectedDataElement_%FieldName%. |
| Unerwartetes zusammengesetztes Datenelement | Die Empfangspipeline generiert eine XML-Tags mit Präfix, Segmentbezeichner und Index, die die Position des Datenelements im Segment darstellt: <UnexpectedCompositeDataElement_%FieldName%. |
| Fehlende erforderliche Daten | Die Pipeline behandelt die Daten als optional. |
| Verletzung der Länge des Datenelements | Die Pipeline behandelt die ungültige Datenelementlänge als gültig (min = 0 und max = unbegrenzt). |
| Ungültiger Enumerationswert in der Instanz (gilt für den ID-Datentyp) | Die Pipeline ignoriert den Fehler und führt die Verarbeitung fort. |
| "Max"-Wiederholungsverletzung in der Instanz | Die Pipeline behandelt solche mehrfach vorkommenden Daten als gültig (minimale Auftreten = 0 und maximale Auftreten = unbeschränkt). |
Fehlerberichterstellung
Wenn die EDI-Typüberprüfung deaktiviert ist, meldet BizTalk Server keine Fehler in der Ereignisanzeige, sondern meldet eine Warnung. Darüber hinaus meldet die Anerkennung ein "Akzeptieren" zurück an die Quellpartei, indem AK501 und AK901 als "E" in einem X12 997 festgelegt werden oder UCI.4, UCM.3 und UCF.4 als "7" in einer EDIFACT CONTRL gesetzt werden. Infolgedessen wird jede Chance auf Berichtigung in zukünftigen Übertragungen beseitigt. Empfänger der Nachricht haben jedoch die Möglichkeit, das Dokument über einen manuellen Eingriff zu retten, anstatt dass die Nachricht abgelehnt oder angehalten wird. Außerdem wird die Edi.ErrorsInTransactionSet Kontexteigenschaft höhergestuft, wenn eines dieser Fehler von der EDI-Empfangspipeline erkannt wird. Diese Eigenschaft wird als "True" höhergestuft, wenn EDI- oder erweiterte Gültigkeitsprüfungsfehler auftreten. Wenn keine Fehler auftreten, wird die Eigenschaft als "False" heraufgestuft.
Wenn bei der Empfangs- oder Sendepipeline unerwartete Daten auftreten, meldet es den Fehler auf der übergeordneten Ebene und ignoriert Fehler auf untergeordneter Ebene wie folgt:
| Unerwartete Daten | Action |
|---|---|
| Unerwarteter Transaktionsdatensatz | Die Bestätigung meldet diesen Fehler und ignoriert nachfolgende Fehler auf Segment-/Schleifen- und Datenelementebene. |
| Unerwartetes Segment/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, occours usw.) und Fehler im Zusammenhang mit zusammengesetzten Datenelementfeldern (falls zutreffend). |