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

</tr> </tbody> </table> 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: ``=`` Die Systeminformationen setzen sich dabei wie folgt zusammen:

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. Für diese fest definierte Reihenfolge, siehe den Punkt Gültigkeit von Meldepunkten in der Dokumentation.

Das DTM kann vorgangsscharf für jeden Prüfi konfiguriert werden. Dies passiert über den genannten dynamischen Ausdruck, der eine Extension aufruft.

Im Beispiel wäre es die Extension B3P_ADDITIONAL_DIVIDING_NETWORK_DTM. Diese müsste angelegt werden mit z.B folgenden Einträgen:

RFF_Z13_MSCONS_13014=164

RFF_Z13_ORDERS=203

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.

</td

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

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[1+0=\"172\"]+2+0

add

Zusätzliche Filtermöglichkeit

balance_district

Prüfung von Bilanzkreisen gegen den Meldepunktindex: LOC[1+0=\"237\"]+2+0

address_assignment

Zuordnung Anhand der PLZ (NAD[1+0=\"DP\"]+8+0) in der EDIFACT-Nachricht (wenn kein LOC[1+0=\"172\"]+2+0 vorhanden ist)

balance_mtr

Filter zur Prüfung des Meldepunktindexes: LOC[1+0=\"172\"]+2+0 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[1+0=\"172\"]+2+0. 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.

cancellation

Filter zur Prüfung von Kündigungen gegen eine REST-Api. Definition der Api auf Anfrage.

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[1+0=\"172\"]+2+0. 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[1+0=\"172\"]+2+0 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).

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