SystemSplitAction
Klasse: org.b2bbp.dividing.network.actions.SystemSplitAction
Diese Action verteilt die Nachrichten anhand der zur Verfügung stehenden Informationen auf die verschiedenen Systeme, berücksichtigt werden hierbei Antwort- und Meldepunktindex. Dabei werden die Nachrichten zunächst mithilfe der nachrichtenformat-spezifischen Splitstrategie zerlegt und die einzelnen Teile den Systemen zugeordnet: Nachrichten,
- die nicht eindeutig zugeordnet werden können, werden in einen CLEARING-Channel zur manuellen Nachbearbeitung geroutet.
- mit mehreren Belegen auf Belegebene analysiert.
- welche eindeutig zugeordnet werden konnten, werden danach wieder aggregiert und zusammen ans zugeordnete Backend geschickt.
Enthält eine Nachricht technische Contrl-Fehler, so kann diese i. A. nicht geplittet werden. Besteht eine Nachricht die fachliche Aperakt-Prüfung nicht, so werden nur die (falls vorhanden) validen Teile bei der Zuordnung der Systeme berücksichtigt.
Diese Action muss in allen Channels enthalten sein, in denen eine Zielsystem-bezogene Verteilung der Nachrichten nötig ist.
deprecated, also als veraltet markiert. Bei der Benutzung wird ein Systemfehler erzeugt. Diese Variante der Systemweiche kann weiter benutzt werden, sie wird nicht aus der B2B by Practice entfernt. Die Variante ist als deprecated markiert, da wir uns vorbehalten, Weiterentwicklung daran umzusetzen. Sollte ein Wechsel vom default-package auf das total-package angestrebt werden, sollte vorher eine Anforderungsanalyse durchgeführt werden und geprüft werden, welche Anforderungen durch die im Einsatz befindliche Systemweiche aktuell abgedeckt werden.Aktuelle Splitstrategien
Im folgenden werden die aktuell implementieren Splitstrategien aufgelistet :
| Format | Beschreibung |
| ALOCAT | |
| IMBNOT |
|
| IFTSTA | |
| INVOIC | |
| MSCONS |
|
| REMADV |
|
| TSIMSG | |
| UTILMD | |
| COMDIS |
Customizing
Folgende Action-Properties können konfiguriert werden
Eigenschaft |
Wert |
Beschreibung |
Kontext überschreiben |
B3P_SPLIT_CATEGORY_PACKAGE |
org.b2bbp.dividing.network.actions.strategies (default, unadvised) |
Java-package der Split-Logik: Das empfohlene total-Paket benutzt die Daten aus der Nachrichtenvalidierung (aktuelle Implmentierung der Systemweiche). Das (noch) Defaultpaket benutzt eine veraltete und nicht mehr unterstützte Systemweichenlogik. Auch das mbs-Paket (MyBusinessSupplier) ist veraltet und kann durch das total-Paket ersetzt werden. |
Nein |
B3P_DIV_NETWORK_CLEARING_CHANNEL |
<Channel-Name> (Wert muss konfiguriert werden) |
Name des Channels, in den die nicht zuordbaren Nachrichten geschoben werden |
Ja |
B3P_MAP_CHANNEL |
“true” oder “false” (Default: false) |
Ist dieser Wert auf „true“ gesetzt werden die Channelnamen anhand der Extension B3P_CHANNEL_MAP ermittelt |
Ja |
B3P_STOP_AFTER_SPLIT |
„true“ oder „false“ (Default: false) |
Ist dieser Wert auf „true“ gesetzt wird die Channelverarbeitung nach dieser Action gestoppt. Andernfalls wird der Channel mit der Originalnachricht weiter ausgeführt. |
Nein |
RESTART_MESSAGE |
„true“ oder „false“ (Default: false) |
Diese Property kann nur genutzt werden, wenn alle Nachrichten nur einen Vorgang haben. Wenn die Property auf "true" gesetzt wird, wird die Nachricht neugestartet, anstatt eine neue Nachricht zu erstellen. Die Eigenschaft B3P_BASE_CHANNEL wird auf den Zielchannel der Weiche gestellt. |
Nein |
DTM_QUALIFIER |
Das Property verursacht einen Fehler, wenn in einer Nachricht unterschiedliche Prüfi enthalten sind. Bitte löschen Sie das Property! Die Extension wird weiterhin in der Verarbeitungsphase verwendet. aus Extension gelesener DTM Qualifier (z.B 164 oder 163), Beispiel: ${loadExtensionProperty(B3P_ADDITIONAL_DIVIDING_NETWORK_DTM, ${context(RFF_Z13_${template(&(this.FORMAT.type))}_${substring(${edipath(RFF[1+0="Z13"]+1+1)},0,5)})}, true)} |
Hier kann definiert werden, wenn bestimmte Formate oder Prüfis anhand individuell definierter DTM Segmente über den Meldepunktindex gesteurt werden sollen und nicht nach der default Reihenfolge. In dieser Eigenschaft kann ein einzelner Wert oder eine Liste über Komma separiert angegeben werden. Für diese fest definierte Reihenfolge, siehe den Punkt Gültigkeit von Meldepunkten in der Dokumentation. Das DTM kann auch vorgangsscharf für jeden Prüfi konfiguriert werden. Das kann in der Extension B3P_ADDITIONAL_DIVIDING_NETWORK_DTM angegeben werden über folgende Syntax:. Die Extension B3P_ADDITIONAL_DIVIDING_NETWORK_DTM kann z.B mit folgenden Einträgen angelegt werden: RFF_Z13_MSCONS_13014=164 RFF_Z13_ORDERS=203 RFF_Z13_IFTSTA=76,469 Damit würde bei MSCONS mit dem Prüfi 13014 auf das DTM 164 geprüft werden und bei ORDERS allgemein auf 203. Für alle anderen Formate und Prüfis gilt dann weiterhin die default Reihenfolge. Zudem kann anstatt eines DTMs auch ein edipath hinterlegt werden, wenn nicht auf das erste DTM mit einer bestimmten Nummer, sondern auf das zweite oder dritte in einem Incident geprüft werden soll: RFF_Z13_EDIPATH_MSCONS_13002={LIN[1]{DTM[1+0="9"]+1+1}} |
Ja |
EDIPATH_TO_DTM_INVOICE_ENDDATE(nur im default-Paket) |
DTM[1+0="156"]+1+1 (default) DTM[1+0="155"]+1+1 |
Hier ist in Dynamische Ausdruck 155 einzutragen, falls eine INVOIC anhand ihres DTM+155 über den Meldepunktindex gesteuert werden soll.(Das empfohlene total-Paket hat verbesserte Variante: DTM_QUALIFIER. Das (noch) Defaultpaket benutzt eine veraltete und nicht mehr unterstützte logik.) |
nein |
MSCONS_MPI_DATE_RULE |
SERVICESTART_LE_DTM (default) |
Mit dieser Property wird konfiguriert, welche Meldepunktindex-Prüfung zum Vertragszeitraum durchgeführt wird. Mögliche Prüfungen sind: |
nein |
MSCONS_EXCLUDED_INCIDENTS |
(leere Liste) (default) |
In der Property kann eine Komma-separierte Liste von Prüfindikatoren angeben werden. Die Logik der Systemweiche wird nicht angewandt, wenn der Prüfindikator des Vorgangs hier hinterlegt ist. Stattdessen wird in einen Channel ausgesteuert, vgl Property MSCONS_CHANNEL_FOR_EXCLUDED_INCIDENTS. |
nein |
MSCONS_CHANNEL_FOR_EXCLUDED_INCIDENTS |
(ohne default) |
Hier ist ein Channelname anzugeben. Falls eine Nachricht durch die Property MSCONS_EXCLUDED_INCIDENTS ausgeschlossen wird, wird sie in diesen Channel ausgeteuert. Diese Property muss in diesem Fall konfiguriert sein. |
nein |
B3P_SPLIT_CLEARING_MSGS (nur im total-Paket) |
„true“ oder „false“ (Default: true) |
Nachrichten, welche nicht zugeordnet werden können, werden in den Clearingchannel ausgesteuert. Dies passiert vorgangsweise. D.h. für jeden Vorgang, der nicht zugeteilt werden konnte, wird eine Nachricht im Clearingchannel erzeugt. Dies kann durch setzen dieser Property auf "false" unterbunden werden. Vorgänge, die nicht zugeordnet werden können, werden dann aggregiert in den Clearingchannel verschoben. (Beispielszenario: Alle Nachrichten, welche nicht ausgesteuert werden können, sollen an ein festgelegtes Backend.) |
Ja |
SKIP_RESTART_WITHOUT_SPLIT |
„true“ oder „false“ (Default: false) |
Nachrichten, welche nicht gesplittet werden müssen, können mit dieser Eigenschaft im bisherigen Channel weiter verarbeitet werden. Die SystemSplitAction hat dann keinen Einfluss. |
Nein |
B3P_CHANNEL_SUFFIX |
zum Beispiel "_SPLIT" (Default: leer) |
Mit diesem Suffix wird an die von der Systemweiche ermittelten Channel eine Erweiterung, wie zum Beispiel "_SPLIT" angehangen. |
Nein |
STOP_WORKFLOW |
„true“ oder „false“ (Default: true) |
Mit dieser Einstellung kann konfiguriert werden, dass an der SystemSplitAction die Verarbeitung der Nachricht nicht abgebrochen wird, sofern ein Fehler passiert ist. In jedem Fall wird der Fehler an der Action protokolliert. |
Nein |
MSCONS_EXTRA_NAD_DP_SPLIT |
„true“ oder „false“ (Default: false) |
Mit dieser Einstellung kann konfiguriert werden, dass Mscons BGM+Z24 (13013) auf NAD+DP-Segmentebene gesplietet wird. BGM+Z24 wird als eine einzelne UNH-Nachricht erwartet. Falls dies nicht der Fall ist, verwenden Sie bitte vorher eine andere UNH Split-Aktion. Funktion können Sie erst ab Februar Release 2025 benutzen |
ja |
B3P_STOP_MESSAGE |
„true“ oder „false“ (Default: true) |
Mit dieser Einstellung kann konfiguriert werden, dass an der SystemSplitAction die Verarbeitung der Action nicht abgebrochen wird, sofern ein Fehler passiert ist. Standardmäßig wird, wenn STOP_WORKFLOW = false gesetzt ist, die SystemSplitAction als fehlerhaft dargestellt, wenn ein Fehler auftritt. |
Nein |
B3P_BACKEND_PRIORITY_MTR |
Regulärer Ausdruck fürs Backend-System |
Mit dieser Einstellung kann konfiguriert werden, welches Backendsystem für den Meldepunktindex bevorzugt werden soll, wenn im Meldepunktindex mehrere Meldepunkte mit unterschiedlichen Backends gefunden werden. |
ja |
B3P_BACKEND_FILTER_MTR |
Regulärer Ausdruck fürs Backend-System |
Mit dieser Einstellung kann konfiguriert werden, nach welchem Backendsystem für den Meldepunktindex gefiltert werden soll. |
ja |
B3P_BACKEND_FILTER_RES |
Regulärer Ausdruck fürs Backend-System |
Mit dieser Einstellung kann konfiguriert werden, nach welchem Backendsystem für den Antwortindex gefiltert werden soll. |
ja |
RESTART_PARTIAL_MESSAGE_CC |
z.B.: DNR (ohne default) |
Mit dieser Eigenschaft kann man Nachrichten, die vollständig oder teilweise falsch verarbeitet wurden (zum Beispiel ans falsche Backend gesendet), neu starten. Wenn der Grund für das Fehl-Routing behoben worden ist, werden beim Neustart nur die fehlerhaft gesplitteten Vorgänge neu verarbeitet, und an das richtige System geroutet. Der beim Neustart gesetzte Clearing Status muss mit dem Wert von RESTART_PARTIAL_MESSAGE_CC identisch sein. |
Nein |
USE_VALIDATION_RESULT_FOR_SPLITTING |
„true“ oder „false“ (Default: true) |
Durch Festlegung des Wertes auf "false" in dieser Einstellung ist es möglich, die SystemSplitAction so zu konfigurieren, dass gemäß den BDEW ALF ein EDIFACT-Splitting erfolgt, ohne dass eine Validierung durchgeführt wird. Diese Implementierung wird voraussichtlich im kommenden Release im September 2023 ausgeliefert. |
ja |
Ist der Wert B3P_MAP_CHANNEL auf „true“ gesetzt muss zusätzlich eine Extension B3P_CHANNEL_MAP angelegt werden. Hier muss angegeben werden, wie die Zielchannels (mit Ausnahme des Clearingchannels – dieser ist fest in der Action gesetzt) heißen, in die die Nachrichten auf Grundlage der Systeminformationen verschoben werden sollen. Die Extension ist als Schlüssel-Wert-Paar aufgebaut:
<Systeminformation aus Antwort oder Meldepunktindex>=<Channelname>
Die Systeminformationen setzen sich dabei wie folgt zusammen:
Index |
Systeminformation (immer in Großbuchstaben!) |
Antwortindex |
<Wert aus Feld system_s>_<Wert aus Feld mandant_s> |
Meldepunktindex |
<Wert aus Feld system>_<Wert aus Feld mandant> |
Bespiel: Steht im Antwortindex im Feld system_s der Wert SAP1 und im Feld mandant_s der Wert 100, setzt sich der Schlüssel wir folgt zusammen: SAP1_100
Sollen alle Nachrichten, die diesem System automatisch zugeordnet werden können, in den Channel INBOUND_LIEF geroutet werden, muss in der Extension B3P_CHANNEL_MAP der Eintrag
SAP1_100=INBOUND_LIEF
gepflegt werden.