Kurzfristige Handlungsmöglichkeiten bei Prüffehlern

Zielstellung

In der B2B gibt es die Möglichkeit durch Customizinganpassungen die Prüflogik bei Fehlern zu umgehen, damit Test nicht stillstehen oder fahlsch abgelehnte Nachrichten trotzdem verschickt werden. Im folgenden finden Sie Handlungsmöglichkeiten, wenn vermehrt negative CONTRL und APERAK erzeugt oder empfangen werden, die als nicht zulässig eingestuft werden bzw. einer Klärung bedürfen. Um den manuellen Kläraufwand zu minimieren bzw. zu automatisieren und keine Fristverletzungen zu provozieren bietet B2B einige Möglichkeiten um schnell zu reagieren. Diese werden in diesem Dokument beschrieben.

Restart mit speziellen Clearing Codes

Anwendungskategorie: Kurzfristige Handlung erforderlich

Anwendungsfall:

• Nicht zulässige negative CONTRL wird auf eingehende Nachricht generiert
• Nicht zulässige APERAK wird auf eingehende Nachricht generiert
• eingehende Nachricht wird wegen Prüffehler nicht ins Backendsystem eingespielt

Handlungsanweisung: Über definierte Clearingcodes kann mit Neustart zusätzlich eine oder mehrere hinterlegte Aktion(en) ausgeführt werden. Die speziellen Aktionen wären in diesem Fall

1) versende nach Neustart eine positive CONTRL (unabhängig vom Prüfergebnis)
2) überspringe die CONTRL-Prüfung 3) überspringe die APERAK-Prüfung

Das Vorgehen wäre in diesem Falle, die Nachricht (oder auch mehrere) auf den entsprechenden Clearingcode zu setzen und dann neu zu starten. Je nach Clearingcode wird dann die entsprechende Aktion ausgeführt. Vorgeschlagene Belegung (Clearingcodezahlen und Texte sind frei konfigurierbar, die passende Konfiguration findet man im nächsten Abschnitt):

Customizing in der B2B

Vorraussetzung: Zur Validierung werden folgende Actions verwendet:

ogr.b2bbp.runtime.action.internal.ContrlActionStandard
org.b2bbp.validation.aperak.AperakActionStandard

Sämtliche Konfiguration findet in der Extension “ClearingCodes“ statt. Anhand des oben vorgeschlagenen Beispiels (Tabelle 1) müsste folgendes konfiguriert werden:

601=Restart ohne CONTRL-Prüfung
602=Restart pos. CONTRL senden
603=Restart ohne APERAK-Prüfung  
604=Restart ohne APERAK-Prüfung und pos. CONTRL senden

Diese Konfiguration ist analog zum Anlegen eines neuen Clearingcodes. Zusätzlich können diesen Clearingcodes Aktionen, die ausgeführt werden mitgegeben werden. Dies erfolgt über spezielle Befehle, hinter denen die Clearingcodes aufgelistet werden, die diese Aktion ausführen sollen. Trennzeichen „;“ (Semikolon) bei Mehrfachaufführung von Clearingcodes. Die Befehle sind in folgender Tabelle beschrieben:

Die Clearingcodes werden dann nach folgenden Schema zu den Aktionen zugeordnet

<Aktion>=<Clearingcode>[;<Clearingcode>;…]

Um das empfohlene Beispiel aus Tabelle 1 abzubilden sieht die Konfiguration dann wie folgt aus (zusätzlich in der Extension „ClearingCodes“)

&SkipAperakCheck=603;604
&SkipContrlCheck=601;603
&ForcePositiveContrl=602;604

CONTRL/APERAK-Prüfung für definierte Anwendungsfälle dauerhaft unterdrücken (über ClearingErrorAction)

Fachliche Anwendung

Anwendungskategorie: Automatismus bei längerfristig anhaltenden (gleichartigen) Problemen Anwendungsfall:

• Nicht zulässige APERAK wird auf eingehende Nachricht generiert
• Nicht zulässige neg. CONTRL wird auf eingehende Nachricht generiert
• Zulässige APERAK wird auf eingehende Nachricht generiert, soll aber unterdrückt werden (und die Nachricht damit verarbeitet werden)
• Zulässige neg. CONTRL wird auf eingehende Nachricht generiert werden (und die Nachricht damit verarbeitet werden)
• Die oben genannten Fälle beziehen sich auf bestimmte Formate, Marktpartner, PRÜFIs, Fehlercodes

Handlungsanweisung: Im Customizing können Regeln definiert werden, wann CONTRL oder APERAKFehler ignoriert werden sollen. Die Kriterien können wie folgt definiert werden (auch in Kombination)

• Für welche Formate (spezielle Formate oder alle)
• Für welche Formatversionen (spezielle Formate oder alle)
• Für welche Marktpartner (spezielle Marktpartner oder alle)
• Für welche PRÜFIs (spezielle PRÜFIS oder alle)
• Für welche Fehlercodes (spezielle Fehlercodes oder alle)

Gibt es störende APERAK- oder CONTRL-Prüfungen, so können diese dauerhaft deaktiviert werden. Die Konfiguration nimmt in der Regel ein Administrator vor.

Customizing in B2B

Mit der ClearingErrorAction können verschiedene ErrorCleaner ausgeführt werden um Validierungsfehler anhand unterschiedlicher Kriterien zu entfernen. Um die Validierung basierend auf Format, Version, Marktpartner, Prüfi und ErrorCode zu deaktivieren eignet sich die Action EdiValidationResultErrorCleaner.

Einrichtung

Eine neue Action in der B2B anlegen. Anzugebende Klasse:
org.b2bbp.runtime.actions.clearing.error.collection.ClearingErrorAction

Folgende Actionproperties (Eigenschaften) definieren:

Position im Channel: Diese Action immer direkt hinter der ValidatorAction (Action, die die Prüfung ausführt) und vor die CONTRL und APERAK-Action einfügen.

Pflege der Regeln: Die Regeln werden in der Extension ERROR_CLEANING_RULES definiert.

Regeldefinition: Die Regeln, wann ein Fehler aus dem Prüfergebnis herausgenommen werden soll, werden wie folgt definiert.
1) Pro Regel wird eine Zeile definiert. Diese werden nacheinander abgearbeitet. Hinweis: allgemeine Regeln überschreiben die speziellen! 2) Die Regeln genügen folgender Syntax ____

Wobei folgende Platzhalter verwendet werden:

Hinweis: Wichtig ist die Trennung durch den Unterstrich „_“.

Hinweis: Es können auch mehrere Werte mit Komma „,“ getrennt zwischen den „_“ angegeben werden.

Hinweis: Ein Stern „*“ kann als Wildcard genutzt werden:

Beispiele

1) UTILMD_5.1B_9999999999999_12345_13 mit dieser Regel werden Fehler aus UTILMD 5.1B entfernt, wenn der Marktpartner die ILN 9999999999999 hat, der PRÜFI 12345 ist und der Fehlercode 13 ist.

2) UTILMD_5.1B_9999999999999_12345_12,13 Analog zu Beispiel 1) nur wird hier wird auf die Fehlercodes 12 und 13 geprüft.

3) UTILMD_*_9999999999999 _ *_Z29 Diese Regel entfernt Validierungsfehler für alle Formatversionen und alle Prüfis, die vom Partner 9999999999999 kommen und Fehlercode Z29 enthalten.

CONTRL/APERAK-Prüfung für nicht konforme Nachrichten oder Fehler, die spezielle Qualifier betreffen deaktivieren (über ClearingErrorAction)

Fachliche Anforderungen

Anwendungskategorie: Automatismus bei längerfristig anhaltenden (gleichartigen) Problemen.

Anwendungsfall:

• Nicht marktkonforme Nachrichten sollen die CONTRL/APERAK-Prüfung passieren können, zum Beispiel bei:
  o hausinternen Qualifiern
  o Sperrtools
• CONTRL-Prüfung moniert Qualifier, die aber eigentlich erlaubt sind.

Handlungsanweisung: Im Customizing können Regeln definiert werden, wann CONTRL oder APERAKFehler ignoriert werden sollen. Die Kriterien können wie folgt definiert werden:

• Für welche Formate (spezielle Formate oder alle)
• Für welche Fehlercodes (spezielle Fehlercodes oder alle)
• In welchen Segment/Composite/Datenelement finde ich den Qualifier
• Welche Qualifier sollen zusätzlich erlaubt sein.

Gibt es störende APERAK- oder CONTRL-Prüfungen, so können diese dauerhaft deaktiviert werden. Die Konfiguration nimmt in der Regel ein Administrator vor.

Customizing in der B2B

Mit der ClearingErrorAction können verschiedene ErrorCleaner ausgeführt werden um Validierungsfehler anhand unterschiedlicher Kriterien zu entfernen. Um die Validierung basierend auf Format, Version, Marktpartner, PRÜFI und ErrorCode zu deaktivieren eignet sich die Action EdiValidationResultErrorCleaner.

Einrichtung

Eine neue Action in der B2B anlegen. Anzugebende Klasse:

org.b2bbp.runtime.actions.clearing.error.collection.ClearingErrorAction

Folgende Actionproperties (Eigenschaften) definieren:

Position im Channel: Diese Action immer direkt hinter der ValidatorAction (Action, die die Prüfung ausführt) und vor die CONTRL und APERAK-Action einfügen.

Hinweis: Kann zusammen mit der Action aus Kapitel 4 verwendet werden.

Pflege der Regeln: Die Regeln werden in der Extension ERROR_CLEANING_RULES definiert.

Regeldefinition: Die Regeln, wann ein Fehler aus dem Prüfergebnis herausgenommen werden soll, werden wie folgt definiert.

Die Definition der Regel setzt sich immer aus dem Regelname (definiert unter registeredRules) und dem Platzhalter aus Tabelle 6 zusammen, getrennt durch einen Punkt.

<RULE_NAME>.<PLATZHALTER>=<WERT>

Ausgewählte APERAK-Prüfungen Aktivieren/Deaktiviere

** Anwendungskategorie:** Kurzfristige Handlung erforderlich
Anwendungsfall:

• Nicht zulässige APERAK wird auf eingehende Nachricht werden generiert
• Erweiterte APERAK-Prüfungen sollen aktiviert werden
• Die APERAK-Prüfung prüft strikt nach AHB, obwohl Werte im MIG erlaubt wären

Handlungsanweisung: Die APERAK-Prüfung kann an einigen Stellen beeinflusst werden. Die folgende Tabelle gibt die Möglichkeiten an. Die Konfiguration übernimmt in der Regel ein Administrator.