Nicht jede Stammdatenausleitung ist Marktkommunikation.

Ein Energiedatenmanagement-System soll angebunden werden. Die Runde diskutiert Format und Übertragungsweg, und beides ist rasch geklärt, weil es die vertraute Hälfte der Aufgabe ist. Offen bleibt die andere Hälfte, also wann geliefert wird, woran die Strecke eine Änderung erkennt und wer den Fehler bearbeitet, der dabei entsteht.

Die zweite Ausleitung

Stammdaten verlassen das System auf zwei verschiedenen Wegen. Der erste ist der marktpartnerbezogene: Was ein anderer Marktteilnehmer braucht, geht in einem regulierten Format an eine bekannte Rolle, in einem Prozess mit festgelegtem Anlass und festgelegter Antwort, und dieser Prozess ist in jedem Zielbild eingezeichnet.

Der zweite Weg führt an fachliche Zielsysteme, an Energiedatenmanagement, Abrechnungsvorsysteme und Analytik. Auf der fachlichen Seite steht ein Energiedatenmanagement-System, im deutschen Netzbetrieb etwa BelVis EDM der KISTERS AG oder das vom Fraunhofer IOSB-AST entwickelte EMS-EDM PROPHET. Solche Systeme brauchen Zählpunkt-, Geräte-, Vertrags- und Bilanzierungsstammdaten in eigener Körnung und eigenem Format, und sie brauchen sie verlässlich wiederkehrend.

Der Kern ist auf beiden Wegen derselbe, das Regime darüber ist ein anderes. Für den ersten Weg gibt es ein Rahmenwerk, eine Rolle auf der Gegenseite und eine Erwartung, was bei einem Fehler geschieht; für den zweiten Weg steht eine Zeile in einer Liste, mit Quelle, Ziel und Format, und diese Zeile trägt keine dieser Festlegungen.

Dass die Zeile so schmal bleibt, hat einen nachvollziehbaren Grund. Auf dem ersten Weg sitzt eine Gegenseite mit einer Rolle, die widerspricht, wenn etwas fehlt, und dieser Widerspruch kommt schnell und an eine bekannte Adresse. Auf dem zweiten Weg sitzt ein System, das nimmt, was kommt; der Widerspruch erreicht das liefernde Haus erst über den Fachbereich, der mit den Daten arbeitet, und bis dahin sieht die Strecke aus, als trage sie.

Warum die Schnittstellensicht in die Irre führt

Eine Schnittstelle beschreibt einen Transport. Sie nennt Quelle und Ziel, dazu Format und Weg, und wenn diese Angaben stehen, gilt sie als spezifiziert. Ein Zielsystem, das Zählpunkt-, Geräte-, Vertrags- und Bilanzierungsdaten braucht, konsumiert aber dieselben Stammdaten wie der Markt, nur in anderer Körnung und in anderer Kadenz. Damit stellen sich vier Fragen, die auf dem fachlichen Weg keine Vorgabe beantwortet.

Der Wirksamkeitszeitpunkt bestimmt, mit welchem Datum ein Zählpunkt im Energiedatenmanagement ankommt; steht dort der Tag des Laufs und nicht der Tag des Wechsels, ordnet das System seine Werte der falschen Zeitscheibe zu.

Bei der Vollständigkeit geht es darum, ob ein fehlender Zählpunkt als Abgang zu lesen ist oder als zurückgehaltener Sachverhalt, denn das Zielsystem sieht nur, was angekommen ist, und kann beides nicht unterscheiden.

Zusammengehörigkeit heißt, dass ein Zählpunkt ohne seine Geräte- und Registerdaten besser gar nicht geliefert wird als halb, weil ein halber Sachverhalt dort trotzdem verarbeitet wird und ein Ergebnis erzeugt, das niemand als unvollständig erkennt.

Und der Nachweis ist die Frage, ob sich zu einem Stand, den der Fachbereich für falsch hält, noch sagen lässt, aus welchem Lauf er stammt und was dieser Lauf gelesen hat.

Auf dem marktpartnerbezogenen Weg beantworten Format und Prozessregeln diese vier Fragen. Wer in der Marktkommunikation gearbeitet hat, kennt sie deshalb als erledigte Arbeit und nicht als offene Punkte. Die Schnittstellensicht stellt keine von ihnen, weil sie den Transport beschreibt, und der Transport ist der Teil der Aufgabe, der ohnehin funktioniert.

Beantwortet werden sie trotzdem, nur unausgesprochen und durch die erste Implementierung: durch die Stelle, an der die Selektion ihren Stichtag setzt, und durch die Prüfung, die einen Satz weglässt oder mitnimmt. Diese Antworten stehen in keinem Dokument, und deshalb kann sie später niemand nachlesen, auch nicht der Fachbereich, der die gelieferten Daten erklären muss.

Push per Datei oder Pull über Schnittstelle

Wenn ein fachliches Zielsystem Stammdaten braucht, stehen zwei Bauweisen offen. Der Sender erzeugt eine Datei und liefert sie, oder der Empfänger holt sich die Daten selbst, über OData oder über freigegebene CDS-Sichten. Die zweite Bauweise ist die richtige, wenn der Konsument selbst filtert, kleine Mengen zieht, interaktiv arbeitet und keinen fachlichen Konsistenzschnitt braucht. Für eine wiederkehrende Massenlieferung sprechen vier Punkte gegen sie.

• Der Konsistenzschnitt liegt beim Sender, weil nur er die Einheit der Gültigkeit kennt und die Regeln durchsetzt, nach denen ein unvollständiger Sachverhalt gar nicht erst hinausgeht.
• Ein Zug über die Leitung liefert keinen reproduzierbaren Stand, während eine erzeugte Datei genau derselbe Beleg bleibt, auch wenn sie später noch einmal gelesen wird.
• Die Änderungserkennung wandert zum Konsumenten, und mit ihr die Fachlogik, die entscheidet, was überhaupt als Änderung gilt.
• Die Ausleitung hängt betrieblich an anderen Läufen, und das braucht eine Steuerung, die auf beiden Seiten sichtbar ist und nicht nur im Zugriffsmuster des Empfängers.

Pull ist damit kein Fehler, sondern eine andere Verantwortungsteilung. Sie legt den fachlichen Schnitt beim Empfänger ab, und im Massenumfeld der Utilities liegt sie damit ungünstig, weil dort der Sender die Einheit kennt und der Empfänger sie nachbilden müsste.

Zustand oder Vorgang

Eine Ausleitung transportiert Zustände. Begründet wird ein Zustand aber durch den Vorgang, der ihn herbeigeführt hat, und der Standard verbindet beides bereits, indem fachliche Datenstände mit Objekttyp und Prozessdokumentnummer verankert werden.

Vier Fälle zeigen, dass der aktuelle Zustand nicht die ganze Wahrheit ist. Eine rückwirkende Änderung trifft eine Vergangenheit, die schon geliefert wurde. Ein Storno hebt einen bestätigten Vorgang auf, und der Zustand allein erzählt davon nichts. Eine Wirksamkeit in der Zukunft steht bereits im System, gehört aber noch nicht in jede Lieferung. Und konkurrierende Vorgänge auf demselben Zählpunkt lassen offen, welcher Stand der gültige ist.

Daraus folgen zwei Achsen, und sie werden getrennt entschieden. Der Auslöser beantwortet, wann geliefert wird. Die Änderungserkennung beantwortet, was in die Lieferung kommt. Verwechselt werden die beiden Achsen, weil ein Ereignis beides zugleich sein kann, der Anlass einer Lieferung und der Punkt, an dem eine Änderung sichtbar wird.

Beide sind frei kombinierbar, und der Normalfall einer periodischen Strecke ist ein terminbasierter Auslöser mit zustandsbasierter Erkennung. Für den Auslöser kommen drei Typen in Frage, der Vorgangsstatus, der Termin und die Änderung. Woran eine Strecke eine Änderung erkennt, ist die zweite Achse; sie ist Gegenstand eines weiteren Teils dieser Serie.

Die Landkarte

Für den marktpartnerbezogenen Stammdatenaustausch liefert der Standard ein Rahmenwerk. Das MDX-Framework erfasst Änderungen je Zählpunkt, bündelt sie, löst den Austausch aus und verfolgt den Status bis zur Rückmeldung; gebaut ist es für den Marktpartner, für die Granularität des Zählpunkts und für die Änderung als Anlass.

Prozessdokumente halten daneben fest, welcher Vorgang einen Datenstand herbeigeführt hat, und geben einem gelieferten Zustand damit eine Begründung. BPEM nimmt die Ausnahme auf und macht aus einer Meldung eine Aufgabe mit Kategorie, Bearbeiter und Lösungsprozess.

Was keines der drei abdeckt, ist die wiederkehrende Lieferung eines fachlichen Sachverhalts an ein System, das kein Marktpartner ist. Diese Lücke ist keine Werkzeuglücke, sondern eine Frage der SAP-Utilities-Architektur: das Zielsystem steht in keinem Marktmodell, und deshalb steht die Lieferung an es in keinem Rahmenwerk. Auffällig wird sie nicht, solange die Lieferung als Zulieferung eines Vorhabens geführt wird und nicht als Prozess mit einem Verantwortlichen; auffällig wird sie, wenn im Zielsystem ein Stand steht, den niemand erklären kann.

Vier Entscheidungen am Anfang

Vier Entscheidungen fallen am Anfang einer solchen Strecke, und sie fallen auch dann, wenn niemand sie ausspricht. Sie sind die Antwort auf die vier Fragen, die eine Schnittstellenbeschreibung offen lässt, eine Entscheidung je Frage. Schwer zu ändern sind sie später nicht deshalb, weil eine Änderung technisch schwierig wäre, sondern weil jede von ihnen an mehreren Stellen zugleich verankert ist, und genau deshalb gehören sie in den Entwurf und nicht in die Stabilisierung danach. Die Aufstellung ist bei der Arbeit an einer fachlichen Ausleitung in einem S/4HANA-Utilities-Greenfield bei einem Verteilnetzbetreiber entstanden.

Selektion und Ausgabe trennen, oder in einem Durchlauf bauen. Getrennt heißt, dass zuerst ein Stand ermittelt und festgeschrieben wird und erst danach daraus ausgegeben wird. Das ist zugleich eine Entscheidung über die Prüfbarkeit, denn nur ein festgeschriebener Stand lässt sich einem Lauf zuordnen und unverändert erneut ausgeben. Bleibt sie ungesagt, entsteht ein Durchlauf, bei dem sich hinterher nicht mehr sagen lässt, welcher Lauf welchen Stand geliefert hat.

Die Einheit der Gültigkeit setzen. Sie bestimmt, was zusammen ankommen muss, damit ein Sachverhalt im Zielsystem deutbar ist, und was gemeinsam zurückgehalten wird, wenn ein Teil davon fehlt. Wird sie nicht gesetzt, liefert die Strecke das geänderte Objekt und lässt den Rest des Sachverhalts stehen, und der Empfänger hält einen halben Sachverhalt für einen ganzen.

Auslöser und Delta-Kriterium als zwei Achsen führen. Der Auslöser gehört in den Betrieb, das Delta-Kriterium in die Fachlichkeit, und zusammen bestimmen sie, was eine Lieferung überhaupt bedeutet. Ohne diese Trennung wird der Auslöser zum Nebenprodukt der Einplanung, und die Bedeutung der Lieferung ist im Nachhinein nicht mehr erklärbar.

Den Adressaten des Fehlers bestimmen. Ein zurückgehaltener Sachverhalt braucht eine Stelle, die ihn bearbeitet, eine Fälligkeit und einen Weg zurück in den nächsten Lauf. Unterbleibt die Festlegung, ist das Protokoll die Adresse, und ein Protokoll bearbeitet niemand. Wie ein verworfener Sachverhalt einen Bearbeiter und einen Nachweis bekommt, behandelt der Auftakt dieser Serie.

Die fachliche Ausleitung liegt im kritischen Pfad des Go-live, ohne dort als Risiko geführt zu werden. Wer sie als Schnittstelle führt, trifft die vier Entscheidungen nicht, sondern erbt sie aus der ersten Implementierung. Sie später zu korrigieren ist kein Konzeptthema mehr. Die Einheit der Gültigkeit steckt dann in der Selektion, das Delta-Kriterium in der Fortschreibung. Der Fehlerkanal steckt in der Protokollierung und der Auslöser in der Ablaufsteuerung. Ein Wechsel greift damit in vier Bausteine statt in ein Kapitel, und er berührt Entwicklung, Betrieb und Fachbereich gleichzeitig, weil sich mit dem Auslöser auch die Bedeutung der gelieferten Daten ändert und neu abgenommen werden muss. Steht Ihre fachliche Ausleitung im Integrationszielbild oder in einer Schnittstellenliste?

Ausblick

Damit gehört die fachliche Ausleitung in das Integrationszielbild und nicht in eine Liste von Übergaben. Wer sie dort führt, entscheidet die vier Fragen bewusst, die sonst die erste Implementierung entscheidet.