Prüfschnittstellen
Wir arbeiten mit drei Arten von Validierungen: Syntaxprüfungen, Validierungsregeln
und
Subprozesse. Wir trennen diese Prüfungen, um ein möglichst präzises Feedback zu erstellen.
Syntaxprüfungen
Syntaxprüfungen beziehen sich auf
ein
einzelnes Segment oder die Struktur oder den Inhalt innerhalb eines Segments. Zum
Beispiel könnte ein obligatorisches Segment fehlen oder die maximale Länge eines
Feldes überschritten sein.
Fehlermeldungen
| Fehlermeldung | Beschreibung |
|---|---|
| Unbekanntes Segment | Dieses Segment ist nicht in der Struktur der Prüfschnittstelle bekannt. Normalerweise tritt dies auf, wenn es einen Tippfehler im Segmentnamen gibt. |
| Segment an falscher Position gefunden | Das Segment selbst existiert in der Prüfschnittstelle, aber nicht an dieser Stelle. Bitte überprüfen Sie die Reihenfolge der Segmente in der Testnachricht gegen die Spezifikation im Implementierungshandbuch. |
| Maximale Wiederholung des Segments überschritten | Das Segment ist an dieser Stelle in der Nachricht erlaubt, aber es existiert öfter als erlaubt. Bitte überprüfen Sie im Implementierungshandbuch, wie oft Sie das Segment wiederholen dürfen. |
| Segment fehlt | An der Stelle der Fehlermeldung hätte ein Segment mit dem Segmentnamen stehen sollen, der in der Fehlermeldung erwähnt wird. Bitte sehen Sie im Implementierungshandbuch nach obligatorischen Segmenten. |
| Obligatorisches Element nicht gefunden | Ein Element innerhalb eines Segments existiert nicht oder enthält keinen Inhalt. |
| Element enthält überlappende Datenelemente | Am Ende der definierten Struktur befinden sich weitere strukturelle Elemente, die dort nicht existieren sollten. Dies kann beispielsweise passieren, wenn ein Segmentabschlusszeichen fehlt oder wenn eine verschachtelte Datenstruktur nicht ordnungsgemäß geschlossen ist. |
| Element enthält Inhalt, darf aber nicht mit Daten gefüllt werden | Einige Datenaustauschstandards wie EDIFACT bieten mehr Elemente in einem Segment an, als der Benutzer dieser Standards benötigt. Es kann sogar Situationen geben, in denen er die eingehenden Daten nicht ordnungsgemäß verarbeiten kann, wenn ein bestimmtes Element gefüllt ist. Mit diesem Fehlercode kann der Datenempfänger angeben, dass dieses Element nicht gefüllt werden darf. |
| Feldinhalt ist nicht streng alphabetisch | Dieses Feld darf nur Buchstaben enthalten, keine Zahlen. |
| Feldinhalt ist nicht streng numerisch | Dieses Feld darf nur Zahlen enthalten, keine Buchstaben. |
| Falsches Feldmuster | Dieses Feld muss ein oder mehrere streng definierte Muster enthalten. Wenn beispielsweise nur 'ABC123' und 'XYZ456' erlaubt sind, wäre 'DEF789' ein Fehler. |
| Feldinhalt zu kurz | Die Mindestlänge wurde nicht erreicht. Bitte überprüfen Sie die Länge im Implementierungshandbuch. |
| Feldinhalt zu lang | Die maximale Länge wurde überschritten. Bitte überprüfen Sie die Länge im Implementierungshandbuch. |
| Falscher Dezimaltrenner | Es gibt unterschiedliche Dezimaltrenner in verschiedenen Ländern, aber der Datenempfänger erwartet einen bestimmten. Bitte überprüfen Sie das Implementierungshandbuch auf die erlaubten Dezimaltrennzeichen. |
Validierungsregeln
Validierungsregeln überprüfen logische Beziehungen zwischen mehreren Segmenten
innerhalb einer Nachricht. Der beste Weg, mit ihnen zu arbeiten, besteht darin, den
Regeltext sorgfältig zu lesen, die betroffenen Segmente zu überprüfen und sich mit den
Regelmechanismen vertraut zu machen.
Eine Regel lesen
Wenn eine Regel bestanden wurde, enthält sie nur ein grünes Häkchen und den Text
der Regel. Wenn die Regel jedoch fehlgeschlagen ist, wird das Regelelement erweitert und
zeigt Ihnen die Argumente, aus denen die Regel besteht. Außerdem sehen Sie, welche Art von
Fehler vorliegt:
- Keine Daten: Ein oder mehrere Argumente enthalten keine Daten. Entweder weil die Daten nicht in der Nachricht enthalten sind oder sich nicht an der richtigen Stelle befinden.
- Logikfehler: Argumenten sind vorhanden, entsprechen aber nicht den Bedingungen der Regel. Ein Beispiel: Wenn der Wert aus Argument 1 größer sein muss als der Wert aus Argument 2, würde es einen logischen Fehler geben, wenn der Wert aus 2 größer ist als der Wert in Argument 1.
Mit der
Markierungsschaltfläche können Sie überprüfen, wo sich die zu einem Argument
gehörenden Segmente in der Nachricht befinden. Wenn Sie darauf klicken,
erscheint ein roter Rahmen um die Segmente. Wenn das Argument nur ein Segment
enthält, springt der Benutzer durch Drücken der Markierungsschaltfläche
automatisch an die entsprechende Stelle innerhalb der Testnachricht.
Sie können auch andersherum
beginnen: Wenn Sie ein Segment öffnen, erhalten Sie einen Hinweis darauf,
welche Regeln mit diesem Segment verbunden sind. In den Segmentdetails sehen
Sie, welches Argument zu welchem Element des Segments gehört.
Gruppierungen
Eine einfache Regel bezieht sich nur auf zwei oder drei einzelne Segmente oder alle
Vorkommen eines Segments in der Nachricht. Bei komplexeren Regeln wird die Information
jedoch normalerweise gruppiert. Das bedeutet, dass die Regel auf alle Segmente angewendet
wird, die zu einer bestimmten Gruppe gehören.
Wenn
es mehrere Gruppen gibt, wird die Regel für alle einzeln ausgeführt. Wenn eine Gruppe
fehlschlägt, wird auch die gesamte Regel fehlschlagen, aber nur die fehlgeschlagene Gruppe
wird in der Fehlermeldung angezeigt.
Eine Gruppe kann durch ein Segment oder eine Kombination von Werten in der Nachricht
definiert werden.
- Gruppierung unter einem Segment: Stellen Sie sich ein Versandanweisungsdokument vor, in dem jede Position einer Sendung in einem Segment 'Position' enthalten ist. Wir könnten uns entscheiden, die Regel nach diesem Segment zu gruppieren und das Nettogewicht und das Bruttogewicht für jede Position vergleichen. Wenn das Nettogewicht größer als das Bruttogewicht ist, würde die Regel fehlschlagen. Wenn dies nur bei der letzten Position der Fall ist, würde nur diese Position dargestellt.
- Gruppierung unter einem oder mehreren Werten: Manchmal erlaubt die Nachrichtenstruktur nicht, die Daten in der Regel ordnungsgemäß zu gruppieren. Dies geschieht normalerweise, wenn das Gruppierungskriterium tief in der Nachrichtenstruktur festgelegt ist. In diesem Fall können wir die Regel nach Werten in den Segmenten gruppieren. Ein Beispiel: Eine Lieferscheinnummer wird auf einer tiefen Ebene in einer Lieferavis-Nachricht dargestellt. Wenn wir etwas überprüfen möchten, das mit dieser Nummer zusammenhängt, können wir die Regel nach der Lieferscheinnummer gruppieren, unabhängig von der Nachrichtenstruktur.
Erklärte Regelbeispiele
Es gibt einen Kern von Operationen, die in den Validierungsregeln durchgeführt
werden. Manchmal bilden diese Operationen allein eine Regel, manchmal werden sie für
komplexere Prüfungen kombiniert. Mit diesen Beispielen möchten wir Ihnen die häufigsten
Operationen zeigen und wie sie in den Regeln verwendet werden.
Berechnungen
Hier addieren, subtrahieren,
multiplizieren
oder dividieren wir zwei oder mehr Werte und vergleichen das Ergebnis mit einem anderen
Wert. Die Werte können entweder aus der Testnachricht stammen oder in der Regel fest
sein.
Beispielregel: "Berechnen von Steuerbeträgen". Entnommen aus einer
Validierungsschnittstelle für eine Rechnungsnachricht.
Regellogik: Wir gruppieren den Nachrichteninhalt nach den Steuersätzen. D. h.
TAX-Segmente mit Qualifikator 7 und deren Kindsegmente. Innerhalb jeder dieser Gruppen
multiplizieren wir den Steuersatz (im TAX-Segment selbst enthalten) mit dem steuerbaren
Betrag (im Kindsegment MOA mit Qualifikator 125 enthalten). Das Ergebnis muss dem
Steuerbetrag entsprechen (im anderen MOA-Kindsegment, diesmal mit Qualifikator 124
enthalten).
Die Regel wird in diesen Fällen
bestanden:
- Wenn für alle Gruppen der Steuerbetrag aus der Nachricht dem von uns berechneten Steuerbetrag entspricht.
Die Regel wird in diesen Fällen nicht
bestanden:
- Wenn der Steuerbetrag aus der Nachricht NICHT dem von uns berechneten Steuerbetrag für alle Gruppen entspricht.
- Wenn es in mindestens einer Gruppe keinen Steuersatz, Steuerbetrag oder steuerbaren Betrag gibt.
Bitte beachten Sie, dass die Regel
insgesamt nicht bestanden wird, wenn es mindestens eine falsche Gruppe gibt. Wir zeigen
Ihnen jedoch nur fehlgeschlagene Gruppen und nicht alle, um den Fokus auf das
Wesentliche
zu behalten. Sie sehen, während der Kern der Regel die Berechnung und den Vergleich von
Werten ist, gibt es Fälle, in denen sie ohne Berechnung bestanden oder nicht bestanden
wird.
Zusammenfassungen
Ist eine Variante einer
Additionregel: Hier addieren wir keine vorhandenen Werte, sondern erstellen einen Wert,
indem wir alle Vorkommen einer Information in einer Nachricht zusammenzählen.
Beispielregel: "Überprüfen der Darstellung von Innenverpackungen in
Außenverpackungen". Entnommen aus einer Prüfschnittstelle für eine
Lieferavis-Nachricht.
Regellogik: Wir gruppieren den Nachrichteninhalt nach den Außenverpackungen. D. h.
jene CPS-Segmentgruppen mit Qualifikator 3 und deren Kindsegmente. Innerhalb jeder
dieser Gruppen muss ein QTY mit Qualifikator 189 und ein oder mehrere GIN-Segmente mit
Qualifikator AW vorhanden sein. Aus dem QTY nehmen wir den Wert aus Feld 6060. Aus allen
GIN-Segmenten fassen wir die Anzahl der Einträge zusammen, die im ersten Feld in einem
C208-Composite-Datenelement gesetzt sind.
Die Regel wird in diesen Fällen
bestanden:
- Wenn die Summe aller Werte aus den GIN-Segmenten gleich dem Wert aus dem QTY-Segment in allen Gruppen ist.
- Wenn es kein CPS mit Qualifikator 3 in der gesamten Nachricht gibt (Wir haben möglicherweise keine Außenverpackungen, sondern nur einstufige Verpackungen wie einen Gitterkasten mit dem Material direkt gefüllt).
Die Regel wird in diesen Fällen nicht
bestanden:
- Wenn die Summe aller Werte aus den GIN-Segmenten NICHT gleich dem Wert aus dem QTY-Segment in mindestens einer Gruppe ist.
- Wenn es kein QTY- oder GIN-Segment in mindestens einer Gruppe gibt.
Sie sehen, während der Kern der Regel
die
Zusammenfassung und den Vergleich von Werten ist, gibt es Fälle, in denen sie ohne
Berechnung bestanden oder nicht bestanden wird.
Vergleiche
Wie der Name bereits sagt, vergleichen
wir den Inhalt von zwei oder mehr Argumenten in Vergleichsregeln. Als Operatoren
verwenden
wir größer als, kleiner als, gleich, ungleich, größer oder gleich, kleiner oder gleich.
Beispielregel: "Vergleichen des Bruttogewichts einer Sendung mit dem
Nettogewicht". Entnommen aus einer Prüfschnittstelle für eine Lieferavis-Nachricht.
Regellogik: Die Regel enthält das Bruttogewicht einer Sendung in einem Argument und
das Nettogewicht in einem anderen. Wir vergleichen einfach die beiden Werte. Wenn
mindestens ein Argument fehlt oder leer ist, wird die Regel ebenfalls bestanden. Dies
liegt daran, dass die Information in diesem Fall optional ist und wir nur die Beziehung
zwischen den beiden Werten überprüfen möchten, wenn sie vorhanden sind.
Abhängigkeitsprüfungen
Manchmal muss ein Segment nur in der
Nachricht enthalten sein, wenn eine Bedingung erfüllt ist. Dies bedeutet normalerweise,
dass ein bestimmter Wert in einem anderen Segment gesetzt ist oder dass ein bestimmtes
Segment überhaupt existiert. Wir prüfen, ob der abhängige Wert vorhanden ist, wenn die
Bedingung erfüllt ist.
Beispielregel: "Überprüfen der Übergabeadresse". Entnommen aus einer
Prüfschnittstelle für eine Transportauftragsnachricht.
Regellogik: Wenn der Wert '10' im Segment TDT gesetzt ist, muss ein
Segment NAD mit dem Qualifikator HA vorhanden sein. Innerhalb dieses Segments muss die
Übergabeadresse enthalten sein. Für jeden anderen Wert als 10 wird die Prüfung ebenfalls
bestanden, auch wenn kein NAD-Segment mit dem Qualifikator HA vorhanden ist.
Eindeutigkeitsprüfungen
Informationen wie Positionsnummern oder
Paket-IDs müssen in vielen Nachrichtentypen eindeutig sein. Dies können Sie mit
Eindeutigkeitsregeln überprüfen.
Beispielregel: "Überprüfen der CPS-Sequenznummern". Entnommen aus einer
Prüfschnittstelle für eine Lieferavis-Nachricht.
Regellogik: Aus allen CPS-Segmenten (Ein Segment zur Strukturierung der Anzeige von
Verpackungsdaten) nehmen wir die Sequenznummern. Die Regel wird bestanden, wenn alle
Sequenznummern eindeutig sind. Wir prüfen auch, ob sie aufeinanderfolgend ansteigen,
aber dies ist nicht unbedingt eine Bedingung bei einer Eindeutigkeitsprüfung.
Subprozesse
Viele Implementierungsanleitungen umfassen mehr als einen Geschäftsprozess. Oder es
gibt verschiedene Merkmale eines Geschäftsprozesses, die unterschiedliche Informationen
erfordern und daher einen anderen Nachrichteninhalt oder eine andere Zusammensetzung
erfordern. In solchen Fällen helfen Ihnen Unterprozesse, große Prüfschnittstellen in
Komponenten aufzuteilen, die einfacher zu verstehen und zu beherrschen sind.
Mehrere Unterprozesse für eine
Prüfschnittstelle teilen sich in der Regel die meisten Syntaxprüfungen und einige
Regeln. Darüber hinaus weichen einige strukturelle Spezifikationen vom Hauptprozess ab,
und
es gibt einige Regeln ausschließlich für diesen Prozess.
Indem Sie nur die Prüfungen anwenden, die der Datenabsender wirklich bestehen muss,
ersparen Sie ihm die Notwendigkeit, sich mit Syntaxprüfungen und Regeln zu befassen, die
niemals auf ihn zutreffen werden. Sie können sie auch verwenden, um verschiedene Arten von
Validierungsregeln während des Onboarding-Prozesses zusammenzufassen.
Beispiele
- Trennung nach Geschäftsprozess: Wenn eine Schnittstelle den Seefracht-, Luftfracht- und Straßentransport abdeckt, können Sie Unterprozesse für jeden von ihnen erstellen. Auf diese Weise können Sie die Regeln für jeden Transportmodus trennen.
- Trennung nach Validierungstyp: In einer Versandanweisung könnten Sie alle Prüfungen, die sich auf die Anzeige von Paketen beziehen, in einem Unterprozess zusammenfassen und alle Regeln für die versendeten Waren in einem anderen. Auf diese Weise können Sie das Bewusstsein Ihrer Partner für bestimmte Aspekte der Nachricht erhöhen.
- Trennung nach Partner: Wenn Sie verschiedene Partner haben, die dieselbe Schnittstelle verwenden, können Sie für jeden von ihnen einen Unterprozess erstellen. Auf diese Weise können Sie die Validierungsregeln für jeden Partner anpassen. Eine solche Einrichtung kann hilfreich sein, wenn Ihre Partner viel Spielraum haben, wie sie Ihre Schnittstellen implementieren. Typischerweise handelt es sich dabei um Kunden, die Bestell- oder Transportaufträge übertragen.
Eine Prüfschnittstelle öffentlich verfügbar machen
Sie können entscheiden, wer mit einer Prüfschnittstelle arbeiten darf: Nur Benutzer
mit einem Account im Rahmen eines Projekts oder jeder, der den Link hat. Wenn Sie sich
dafür entscheiden, eine Prüfschnittstelle öffentlich verfügbar zu machen, können Sie den
Link mit Ihren Partnern teilen, und sie können auf die Prüfschnittstelle zugreifen, ohne
sich registrieren zu müssen. Diese Funktion wird Offene Validierung genannt.
Voraussetzung
- Ihr Account hat die Rolle eines Mandantenbesitzers.
Steps
- Wechseln Sie zur Administrationsansicht, indem Sie in der oberen Leiste auf "Administration" klicken.
- Suchen Sie im Element "Schnittstellen" nach der Prüfschnittstelle, die Sie öffentlich verfügbar machen möchten.
- Klicken Sie in das Kontrollkästchen auf der rechten Seite des Eintrags der Prüfschnittstelle.
