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 |
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.
Filterkonfiguration
Zusätzlich kann die Action bei Nutzung des total-Paketes über die Extension B3P_ADDITIONAL_DIVIDING_NETWORK_CONFIGURATION vorgangsspezifisch konfiguriert werden, sowie eine default-Reihenfolge angegeben werden.
Filter |
Beschreibung |
res |
Filter zur Prüfung des Antwortindexes |
mtr |
Filter zur Prüfung des Meldepunktindexes: LOC+172, bzw. LOC+Z15, LOC+Z16, LOC+Z17 in Strom UTILMD |
add |
Formatspezifische zusätzliche Filtermöglichkeit. Bei UTILMD wird gegen die zusätslichen Spalten im Meldepunktindex geprüft: device_number, postcode, customer_number_old (Befüllung über den CSV-Import) |
balance_district |
Prüfung von Bilanzkreisen gegen den Meldepunktindex: ORDERS, MSCONS LOC[1+0="237"]+2+0, TSIMSG und UTILMD CCI+Z19, ALOCAT NAD[1+0="ZEU"]+2+0, IMBNOT NAD[1+0="ZEU"]+2+0. (Befüllung über den CSV-Import / Webservice) |
address_assignment |
Zuordnung Anhand der PLZ (NAD[1+0="DP"]+8+0) in der EDIFACT-Nachricht (wenn kein LOC+172, LOC+Z15, LOC+Z16, LOC+Z17 vorhanden ist). (Befüllung über den CSV-Import / Webservice) |
balance_mtr |
Filter zur Prüfung des Meldepunktindexes: LOC+172, LOC+Z15, LOC+Z16, LOC+Z17 und Bilanzierungsdatum. Im Meldepunktindex sind Meldepunkte mit "startBalanceTime" und "endBalanceTime" notwendig (Beispiel siehe in Systemweiche Webservice). |
mtr_minus_oneday |
Filter zur Prüfung des Meldepunktindexes: LOC+172, LOC+Z15, LOC+Z16, LOC+Z17. Im Gegensatz zum Filter mtr wird hier noch ein Datum aus dem jeweiligen Edifact DTM Segment akzeptiert, was einen Tag vor dem Start Datum aus dem Index liegt. |
mtr_plus_oneday |
Filter zur Prüfung des Meldepunktindexes: LOC+172, LOC+Z15, LOC+Z16, LOC+Z17. Im Gegensatz zum Filter mtr wird hier nur ein Datum aus dem jeweiligen Edifact DTM Segment akzeptiert, was einen Tag nach dem Start Datum aus dem Index liegt. Filter ist erst ab 10.2023 in release.(Problemlosung, wenn 55002(mit Indexierung) vor der 55037 einkommt) |
cancellation |
Filter zur Prüfung von Kündigungen gegen eine REST-Api. Definition der Api auf Anfrage. Einer der unterstützen Webservices wird durch ContractDB / Addressindex bereitgestellt. Gesucht wird dabei in dieser Reihenfolge: |
mtr_inclusive_endtime |
Filter zur Prüfung des Meldepunktindexes: LOC+172, LOC+Z15, LOC+Z16, LOC+Z17. Im Gegensatz zum Filter mtr wird hier ein Datum aus dem jeweiligen Edifact DTM Segment akzeptiert, was <= serviceEnde ist (bei ServiceEnde 23:59:59 wird 1 Sekunde addiert, so dass serviceEnde = 00:00:00 /24:00:00 ist) . |
mbs |
Filter zur Prüfung von Kündigungen gegen MyBusinessSupplier. Die Konfiguration des Hosts und der Zugangsdaten werden in der Extension MBS_CONNECTION_CONF hinterlegt. Bei einer positiven Rückmeldung vom MBS wird per default in den Channel IN_MBS ausgesteuert. Dieser Channel kann über die Extension B3P_CHANNEL_MAP noch auf einen anderen Channel geändert werden. |
extension_mapping |
Filter zur Prüfung von Informationen aus dem MessageContext oder der Edifact, zu hinterlegen in der Extension SYSTEMSPLIT_EDICONDITION_DISTRIBUTION. Die Syntax in der Extension ist die der ChannelDistribution EdiConditionDistribution syntax. |
mtr_malo |
Filter zur Prüfung des Meldepunktindex: LOC+172, LOC+Z15, LOC+Z16, LOC+Z17. Im Gegensatz zum Filter mtr wird hier nur die MALO berücksichtigt. Eine MALO ist immer 11 stellig und numerisch. Es wird nur ein Meldepunkt pro Vorgang kontrolliert. |
mtr_max_service_and_balance_timeslice |
Filter zur Prüfung des Meldepunktindexes: LOC+172, LOC+Z15, LOC+Z16, LOC+Z17 und zeitlich späterliegendes ServiceStart- oder BalanceStart-Datum. Im Gegensatz zum Filter mtr wird hier späteres Datum (ServiceStart oder BalanceStart) aus dem Index genommen, kontrolliert.Im Meldepunktindex sind Meldepunkte mit "startBalanceTime", "endBalanceTime" als auch "startTime", "endTime" notwendig (XML Beispiel (addBalancedMeteringLocation) siehe in Systemweiche Webservice). |
mtr_without_timeslice |
Filter zur Prüfung des Meldepunktindexes ohne Zeitscheibenprüfung: LOC+172, LOC+Z15, LOC+Z16, LOC+Z17 |
device_number |
Zuordnung Anhand der Gerätenummer ({CCI[3+0="E13"]{CAV[1+0="Z30"]+1+3}}) in der EDIFACT-Nachricht (Für 11016). Mit Zeitscheibenprüfung. (Befüllung über den CSV-Import / Webservice) |
agk_number |
Zuordnung anhand der Konfigurations-ID (RFF[1+0="AGK"]+1+1) in der EDIFACT-Nachricht (z.B. Für 13017, 55002, 55117, 55013). Mit Zeitscheibenprüfung. (Befüllung über den CSV-Import / Webservice) |
mtr_check |
Filter zur Prüfung des Meldepunktindexes mit Zeitscheibenprüfung: LOC+172, LOC+Z15, LOC+Z16, LOC+Z17. 1. Prüfung ob Meldepunkt in Nachricht ist. 2. Bei der Prüfung im Index werden die gefundenen Channel nur während der Verarbeitung des Incident im MessageContext SYSTEMSPLIT_MTR_CHECK gespeichert, was dann mit dem Filter "extension_mapping" abgefragt werden kann: "IN_MULTY_LIEF" <== $messagecontext.SYSTEMSPLIT_MTR_CHECK == "CHANNEL2" 3. Dieser Filter hat selbst keine Aussteuerung. (erst ab 07.2023) |
mtr_check_exact_time |
Filter zur Prüfung des Meldepunktindexes: LOC+172, LOC+Z15, LOC+Z16, LOC+Z17. Im Gegensatz zum Filter mtr_check wird hier nur ein Datum aus dem jeweiligen Edifact DTM Segment akzeptiert, was exact an Zeit grenze liegt(Treffer auf genau den Systemgrenzen: DTM == serviceStart || DTM == ServiceEnde). 1. Prüfung ob Meldepunkt in Nachricht ist. 2. Bei der Prüfung im Index werden die gefundenen Channel nur während der Verarbeitung des Incident im MessageContext SYSTEMSPLIT_MTR_EXACT_TIME_CHECK gespeichert, was dann mit dem Filter "extension_mapping" abgefragt werden kann: "IN_MULTY_LIEF" <== $messagecontext.SYSTEMSPLIT_MTR_EXACT_TIME_CHECK == "CHANNEL2" 3. Dieser Filter hat selbst keine Aussteuerung. Filter ist erst ab 04.2024 in release. |
malo_ref_of_tech_resource |
Filter zur Prüfung des Meldepunktindexes: RFF+Z16 "Referenz auf die der Technischen Ressource zugeordneten Marktlokation". Filter ist erst ab 10.2024 in Release. |
Beispielkonfiguration:
#Configuration of priorities for checks in systemsplit default=res,mtr 11062=res,mtr,add,address_assignment 11063=res,mtr,balance_districtView Me Edit Me