Split für die Systemweiche

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.

In der unten aufgeführten Service-Eigenschaft B3P_SPLIT_CATEGORY_PACKAGE wird die Ausprägung der Systemweiche konfiguriert. Ist diese Eigenschaft nicht gesetzt, wird das default-package genutzt. Diese Ausprägung ist ab dem 01.10.2017 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
  • Split erfolgt auf LIN-Segmentebene
  • Split würde für Filter balance_district NAD[1+0="ZEU"]+2+0 implementiert
IFTSTA
INVOIC
MSCONS
REMADV
  • Split erfolgt auf DOC-Segmentebene
  • Das Routing und Aggregation erfolgt auf Basis der Referenz auf INVOIC Rechnungsnummer
  • Berechnung der MOA Summe nach Aggregation
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)
org.b2bbp.dividing.network.actions.strategies.total
org.b2bbp.dividing.network.actions.strategies.mbs (deprecated)

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)
Im total-Paket wird immer die Extension B3P_CHANNEL_MAP verwendet.

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

 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)
SERVICESTART_LE_DTM_LE_SERVICEEND

Mit dieser Property wird konfiguriert, welche Meldepunktindex-Prüfung zum Vertragszeitraum durchgeführt wird. Mögliche Prüfungen sind:
Der Meldepunkt steuert das Routing, falls ServiceStart kleiner oder gleich DTM gilt.
Der Meldepunkt steuert das Routing, falls ServiceStart kleiner oder gleich DTM und DTM kleiner oder gleich ServiceEnde gilt.

nein

MSCONS_EXCLUDED_INCIDENTS

(leere Liste) (default)
13006, 13009, 13013, 13015, 13016

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)
INBOUND_CHANNEL_ERROR

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.
Beispiel:
System = P01, Mandant = 100
Dieser Eintrag würde mit dem regulären Ausdruck P01_100 oder P01 getroffen. Letzterer würde auch bei anderen Mandanten treffen.

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.
Beispiel:
System = P01, Mandant = 100
Dieser Eintrag würde mit dem regulären Ausdruck P01_100 oder P01 getroffen. Letzterer würde auch bei anderen Mandanten treffen. Ist zum Beispiel ein Meldepunkt mit anderem System im Meldepunktindex, so wird dieser ignoriert. Sind nur Einträge im Meldepunktindex, die den regulären Eintrag nicht treffen, so wird kein Eintrag ausgewählt.

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.
Diese Einstellung ist besondern wichtig, wenn Lieferant und Netz die gleiche B2B verwenden und beide eine Systemweiche bestizen. Beispiel:
System = P01, Mandant = 100
Dieser Eintrag würde mit dem regulären Ausdruck P01_100 oder P01 getroffen. Letzterer würde auch bei anderen Mandanten treffen. Ist zum Beispiel eine Referenz mit anderem System im Antwortindex, so wird dieser ignoriert. Sind nur Einträge im Antwortindex, die den regulären Eintrag nicht treffen, so wird kein Eintrag ausgewählt.

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.
Zusätzlich sollte an der SystemSplitAction die Eigenschaft SKIP_RESTART_WITHOUT_SPLIT gesetzt sein.
Die Eigenschaft verwendet man für den Neustart bereits gesplitteter Nachrichten, die den von der SystemWeiche gesetzten Clearing-Status DN1 haben. Dafür muss die SystemSplitAction auch im SPLIT-Channel hinzugefügt werden. Weiterhin muss eine ValidatorAction mindestens mit CONTRL-Validierung vor der SystemSplitAction für den Restart eingesetzt 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:
1. Suche nach Vertragsnummer RFF[1+0="Z01"]+1+1
2. Suche nach Gerätenummer {CCI[3+0="E13"]{CAV[1+0="Z30"]+1+3}}
3. Suche nach Adresse und Sektor: Straße, Hausnummer, Postleitzahl, Stadt, Sektor

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.

Beispielkonfiguration:

#Configuration of priorities for checks in systemsplit
default=res,mtr
11062=res,mtr,add,address_assignment
11063=res,mtr,balance_district
View Me   Edit Me