Übersicht
Die Action AperakConsumerAction analysiert eine APERAK Nachricht auf die zu korrelierenden Referenznummern. Es werden eingehende APERAK Nachrichten zu den dazugehörigen versendeten Nachrichten zugeordnet, oder auch die ausgehenden APERAK Nachrichten zu den erhaltenden Nachrichten (reverse-Fall). Hierbei ist zu beachten, dass die B2B nur auf Dateiebene arbeitet und somit nicht ersichtlich ist, ob die APERAK sich auf einzelne Vorgänge oder alle Vorgänge bezieht. Daher wird empfohlen, APERAK Nachrichten ans Backend weiterzuleiten, sodass dort die exakte Zuordnung stattfinden kann.
Nachrichten mit mindestens einer positiven und bisher keiner negativen APERAK erhalten den Bestätigungsstatus “APP” (APERAK Positiv). Dieser Status wird durch negative APERAKs (Status “APC”) überschrieben, wenn eine Ablehnung vorliegt. Der negative Status wird nicht mehr durch den positiven Status überschrieben. Der Status “APP” sagt somit nichts darüber aus, wie viele Vorgänge/Nachrichten in der Datei eine positive APERAK erhalten haben. Bei Erhalt einer positiven APERAK wird keine Überprüfung der Sparte und des Datums durchgeführt.
Im Standard Customizing wird die Klasse AperakConsumerAction in zwei Actions verwendet.
- APERAK zuordnen (Inbound) korreliert eingehende APERAK Nachrichten an versendete Nachrichten
- APERAK zuordnen (Outbound) korreliert ausgehende APERAK Nachrichten an erhaltende Nachrichten
Einrichtung
Die Action muss in der Administration wie in den folgenden Screenshots angelegt werden:
Klassenpfad: org.b2bbp.runtime.actions.internal.AperakConsumerAction
Konfigurationsmöglichkeiten
| ActionProperty / Eigenschaften | Beschreibung | Werte |
|---|---|---|
| B3P_REVERSE_ACKNOWLEDGEMENT | Zu setzen bei vom Standard abweichender Verarbeitungsrichtung (Standard ist eingehende APERAK); true setzen bei ausgehender APERAK |
true, false (Default false) |
| B3P_CORRELATE_AGGREGATED_APERAK | Ordent die Aperak ebenfalls aggregierten Nachrichten zu. | true, false (Default false) |
| EDIPATH_TO_CORRELATION_RFF | Falls die Referenz auf die Ursprungsnachricht in der APERAK nicht im Standardsegment RFF+ACE steht, kann hier ein anderer EdiPath gesetzt werden. | Beispiel: RFF[1+0="ACW"]+1+1 |
| NO_CORRELATION_ID | Wird mit Wert true eingesetzt, wenn die Aperak die Referenznummer der Orginalnachricht, sondern ihre eigene erhalten soll. Achtung: Diese Eigenschaft kann durch die Global Property B3P_SHOW_CONTRL_AND_APERAK_REFERENCENO global überschrieben werden. | true, false (Default false) |
| USE_ONLY_MAX_STARTED_FOR_SET_ACKNOWLEDGEMENT | Falls gesetzt wird nur die neuste durch die Aperak referierten Nachricht auf der Datenbank gesucht. Die neueste Nachricht ist eventuell nicht die tatsächlich empfangene Nachricht, falls es Duplikate, Splitnachrichten oder Nachrichtenduplizierung für verschiedene Backendsysteme gibt. Dies ist im Allgemeinen etwas performanter, muss aber für die gleichzeitige Zuordnung von Splitnachrichten (lokal) ausgeschaltet werden. Achtung: Diese Eigenschaft kann auch durch die gleichnamige GlobalProperty global ausgeschaltet werden. | true, false (Default true) |
| SET_ACKNOWLEDGEMENT_TO_SPLIT_MESSAGES | Von den gefundenen Nachrichten, denen die APERAK zugeordnet werden könnte aufgrund von Dateiaustauschreferenz, Sender- und Empfänger-MPID, wird sie nur allen denen zugeordnet, bei denen ebenfalls BGM-, UNH- und gegegenfalls Vorgangsreferenz übereinstimmen. Dabei wird bei Mehrfachfunden, wie z.B. bei Splitnachrichten, die APERAK allen gefundenen und passenden Nachricht zugeordnet. Durch die mögliche Verarbeitung von Mehrfachtreffern und schärfe Prüfung, kann eine APERAK der Originalnachricht und der Splitnachricht, auf die sie antwortet zugeordnet werden. (Achtung: Hierzu muss auch die Eigenschaft USE_ONLY_MAX_STARTED_FOR_SET_ACKNOWLEDGEMENT = false gesetzt werden) | true, false (Default false) |