Privilegierte Schnittstelle: Marktkommunikation

Die privilegierte Schnittstelle Schleupen.CS.MK_Marktkomunikation besteht aus mehreren Microservices und Geschäftsprozesskomponenten zur Umsetzung der sogenannten Marktkommunikation zwischen verschiedenen Marktteilnehmern. Sie bildet die gesetzlichen Anforderungen des deutschen Energiemarktes ab. Diese Prozesse (MaBis, WiM, GPKE, GeLi Gas, u.v.m.) sind fachlich sehr genau durch Formate des BDEWs und den Prozessbeschreibungen der Bundesnetzagentur definiert und entsprechend in Schleupen.CS implementiert. Diese Prozesse sind z.T. sehr umfangreich und beinhalten eine komplexe Geschäftslogik.

Aus technischer Sicht findet hier eine Informationsübertragung mit fest definierten Datenformaten statt (UTILMD, ORDER, MSCONS, etc.). Stark vereinfachend ist die Marktkommunikation eine B2B-Schnittstelle nach außen zur Anbindung an Schleupen.CS. Diese arbeitet prozessorientiert und im folgenden Diagramm ist für den Baustein Schleupen.CS.mlf.gwd_Geraetewechsel  (= 'Marktrolle Lieferant.Gerätewechsel durchführen') dargestellt, wie dieser als "Nahtstelle" an Schleupen.CS 3.0 Core orchestrierend fungiert. Weiter "außen" sind die Länder, Provinzen und GP-Komponenten angesiedelt, die die Nachrichten vom "Markt" entgegennehmen und geeignet routen. Exemplarisch hierfür sind die Länder Schleupen.CS.AP.MKP_Marktkommunikationspartner und Schleupen.CS.AP.MP_Marktpartner dargestellt.

Die Marktkommunikation selber (d.h. ohne die 'Nahtstellen'-Prozesskomponenten) besteht aus folgenden Bausteinen / Unterbausteinen:

• CS.AP.MKP - Land Marktpartner Kommunikation - beinhaltet insbesondere die Marktpartnerverwaltung
• CS.AP.MKP.ZKP - Provinz Zentrale Kommunikationspartner -  Katalog für Marktpartner
• CS.AP.MK - Land Marktkommunikation - Marktmeldung, Anwendungsfehlerprüfung
• CS.AP.MK.EDI - Provinz EDI - Transformation zu Marktmeldungen
• CS.AP.MK.UEB - Provinz Übertragung - Syntaxprüfung, Übertragung der EDI-Nachrichten
• CS.AP.MPM - Land Marktprozessmeldung - beinhaltet Prozessmeldungen, Marktprozesse inkl. der Provinzen mit den konkreten spezifischen Prozessmeldungen (CS.AP.MPM ist der Baukasten für die Marktkommunikation)

Der Schnitt der Bausteine wird im Folgenden erläutert.

• Um Katalogdaten wie den Katalog für Marktpartner bereitzustellen wurde u.a. die Provinz CS.AP.MKP.ZKP ausgeprägt, die im Standard auf Ebene des Systemkatalogs der Systemstruktur operiert.
• Durch den BDEW ist eine Codeliste von Artikelnummern und Artikel-IDs veröffentlicht, die standardisieren, worauf sich die Geschäftsvorgänge beziehen. Da diese Informationen unabhängig von Gesellschaften oder Werken sind, werden diese auf Ebene des Systemkatalogs durch CS.AP.MK.EDI verwaltet.
• CS.MK.UEB führt ein Dispatching durch und da man die Übertragungen übergreifend sehen und verwalten möchte, ist CS.MK.UEB dem Werkskatalog zugeordnet.
• CS.AP.MKP, CS.AP.MK, CS.AP.MPM beinhalten keine übergreifenden Informationen und werden deshalb der Mandanten-Ebene zugeordnet.

Die Bausteine verteilen sich in der Systemstruktur im Standard also wie folgt:

Um das Zusammenspiel dieser Bausteine zu verstehen, betrachten wir als Beispiel die dynamische Sicht auf die Marktkommunikation für den sogenannten Empfang. Der Versand erfolgt analog in umgekehrter Richtung. Der Empfang ist grob in der nachfolgenden Abbildung dargestellt:

Die obige Darstellung ist sehr vereinfacht und zeigt nicht die Geschäftsprozesskomponenten, die den Ablauf steuern. Zudem ist CS.mlf.gwd nur ein Beispiel für eine Adapter-GP-Komponente.

1. Den E-Mail-Server erreicht eine E-Mail mit EDIFACT-Nachrichten. 
2. Ein CS 3.0-Job prüft den E-Mail-Server auf angekommene Nachrichten. Diese werden zunächst temporär im Dateisystem und dann insbesondere in der Dateiablage von CS 3.0 abgelegt. 
3. Anschließend wird eine sogenannte Übertragung in CS.MK.UEB erstellt, die alle notwendigen Informationen über den Dateiempfang enthält.
4. Mithilfe von CS.MK.EDI wird die EDIFACT-Nachricht nach XML in eine sogenannte Marktmeldung konvertiert, die eine 1:1-Repräsentation darstellt. Dabei wird z.B. eine Syntaxprüfung durchgeführt.
5. Im nächsten Schritt wird eine Prozessmeldung erstellt, die eine für den CS 3.0-Kontext maßgeschneiderte Nachricht darstellt. Dabei wird die sogenannte Anwendungsfehlerprüfung durchgeführt, die inhaltliche Prüfschritte enthält, die sicherstellen, dass die Transformationen durchgeführt und Prozessmeldungen weiterverarbeitet werden können. 
6. Die Prozessmeldung wird über eine GP-Komponente verarbeitet, die als Adapter an CS 3.0 fungiert und Serviceaufrufe in die einzelnen Länder durchführt.