Umsysteme an epilot anbinden: ERP, Abrechnung, Netzsysteme

Eine epilot Integration verbindet die Plattform mit den Systemen, die bei einem Energieversorger oder Netzbetreiber schon da sind: ERP und Abrechnung, Netzsysteme, weitere CRM-Systeme und eigene Datenbanken. Wer Umsysteme anbinden will, hat mehrere Wege zur Auswahl. Dieser Artikel zeigt, welche Wege epilot selbst anbietet, wann eine eigene Middleware sinnvoll ist und worauf es bei Datenhoheit, Fehlerbehandlung und Betrieb ankommt.

Ich bin Marcel R. G. Berger, Softwareentwickler und Softwarearchitekt mit mehr als 20 Jahren Erfahrung. Ich arbeite mit epilot als externer Consultant und Entwickler für Apps und Individualisierungen. Der Artikel richtet sich an IT-Verantwortliche bei Netzbetreibern, Stadtwerken und Energieversorgern.

Welche Wege gibt es für die epilot Integration von Umsystemen?

Es gibt zwei grundsätzliche Wege: die Integrationswerkzeuge, die epilot selbst mitbringt, und individuell entwickelte Schnittstellen, die zwischen epilot und einem Umsystem vermitteln. In vielen Projekten kommen beide zusammen.

epilot ist eine hervorragende No-Code- und Low-Code-Plattform, und das gilt auch für die Integration. Die Übersicht zu Integrationen in der epilot Entwicklerdokumentation nennt mehrere fertige Bausteine, die für unterschiedliche Aufgaben gedacht sind.

Eine individuelle Schnittstelle kommt dazu, wenn diese Bausteine allein nicht reichen. Das ist keine Schwäche der Plattform. Es liegt meist daran, dass ein Teil der Prozesse in anderen Systemen lebt und dort auch bleiben soll.

Was bietet epilot selbst für die Integration?

epilot bietet laut seiner Entwicklerdokumentation fünf Integrationswege an: das Integration Toolkit, die Batch API, 3rd Party Journeys, Webhooks und öffentliche APIs. Jeder Weg ist für einen anderen Zweck gedacht.

Integration Toolkit für ERP-Systeme

Das Integration Toolkit ist der Baustein von epilot für die Anbindung von ERP-Systemen. Die Dokumentation beschreibt standardisierte Schemas für Entitäten und Ereignisse, Zuordnungen auf Basis von JSONata und eine eigene Inbound API, über die Daten aus dem ERP in epilot ankommen.

In die andere Richtung gehen Ereignisse aus epilot laut Dokumentation per Webhook oder per Abfrage an das ERP. Dazu kommt ein zentrales Monitoring: Jedes Ereignis, das das Toolkit verarbeitet, wird als Monitoring-Ereignis festgehalten, mit Nachverfolgung, erneutem Senden und Alarmierung.

Batch API für viele Aufrufe auf einmal

Mit der Batch API lassen sich mehrere API-Aufrufe in einer einzigen HTTP-Anfrage ausführen. Die Dokumentation nennt eine Obergrenze von 100 Anfragen je Batch.

Fehlgeschlagene Einzelaufrufe beeinflussen laut Dokumentation die anderen Aufrufe im selben Batch nicht, und fehlgeschlagene Aufgaben werden bis zu drei Mal wiederholt. epilot empfiehlt die Batch API für Massenänderungen aus Middleware und für Umgebungen, in denen jede einzelne HTTP-Anfrage auf ein Nachrichtenkontingent angerechnet wird.

Webhooks für Ereignisse in Echtzeit

Webhooks in epilot melden Ereignisse aus dem eigenen Konto an eine konfigurierte Adresse. Tritt ein Ereignis ein, sendet epilot einen HTTP-POST an diese Adresse. Welche Ereignisse es gibt, beschreibt die Seite zu den Core Events; für eigene Attribute lassen sich zusätzlich Custom Events definieren.

Für die Absicherung nennt die Dokumentation zur Webhook-Sicherheit API-Key, Basic Auth und OAuth sowie Signaturen in den Headern webhook-id, webhook-timestamp und webhook-signature.

Öffentliche APIs und 3rd Party Journeys

Die öffentlichen APIs von epilot geben direkten Zugriff auf die Fähigkeiten der Plattform. Die Übersicht spricht von mehr als 50 REST-APIs, darunter Entity, Workflow, Document und Billing, jeweils mit einem TypeScript-Client. Jede Anfrage braucht ein Bearer-Token. Wie eine eigene Schnittstelle Daten aus Umsystemen über diese Wege liefert, zeigt der Artikel Daten per epilot API aus Umsystemen bereitstellen.

3rd Party Journeys sind laut Übersicht dafür gedacht, Daten aus externen Formularen und Frontends an epilot zu übergeben. Für die Anbindung von Umsystemen im Hintergrund spielen sie meist eine kleinere Rolle.

Wann reicht ein Bordmittel von epilot?

Ein Bordmittel reicht, wenn die Aufgabe genau dem Zweck entspricht, für den es gebaut wurde, und die Logik dazwischen überschaubar bleibt. Dann ist es fast immer der schnellere und wartungsärmere Weg.

Ein paar typische Fälle:

• Ein ERP-System soll Verträge, Zählerstände oder Kundendaten mit epilot abgleichen, und die Zuordnung lässt sich im Integration Toolkit sauber beschreiben. Diese Abläufe führt die Dokumentation ausdrücklich als Anwendungsfälle des Toolkits auf.
• Eine bestehende Middleware soll viele Datensätze auf einmal in epilot schreiben. Dafür ist die Batch API gedacht.
• Ein externer Dienst soll erfahren, dass sich in epilot etwas geändert hat, und braucht dafür nur die Daten des Ereignisses. Ein Webhook leistet das direkt.

Grundsätzlich gilt: Was sich in epilot sauber konfigurieren lässt, sollte dort bleiben. Warum das so ist, beschreibe ich ausführlicher im Artikel Wann reicht Low-Code bei epilot nicht mehr?.

Wann braucht es eigene Middleware für die epilot Schnittstelle?

Eigene Middleware braucht es, wenn ein Prozess über mehrere Systeme läuft und die Logik dazwischen mehr ist als eine Zuordnung von Feldern. Sie ist dann ein eigener Dienst, der Ereignisse empfängt, Daten übersetzt und Aktionen in anderen Systemen auslöst.

Die Signale dafür sind meist dieselben:

• Ein großer Teil eines Prozesses läuft außerhalb von epilot, in einem Fachsystem, das weiter im Einsatz bleibt.
• Ein Umsystem hat keine fertige Verbindung zu epilot und spricht ein eigenes Format oder eine eigene Schnittstelle.
• Daten kommen aus mehreren Quellen und müssen zusammengeführt, geprüft oder ergänzt werden, bevor sie weitergehen.
• Ein Ereignis in epilot soll eine Kette auslösen: ein Event in einem anderen System, eine Rückmeldung und am Ende eine Information zurück in epilot.

Ich baue solche Dienste als Mapper in Java mit Quarkus, in Containern, skalierbar und wartbar. Wie so ein Mapper aufgebaut ist und welche Regeln ihn im Betrieb stabil halten, steht im Artikel Mapper zwischen epilot und Umsystemen mit Quarkus.

Wichtig ist: Middleware ersetzt die Bordmittel nicht. Sie nutzt sie. Ein Mapper empfängt in der Regel Webhooks aus epilot und schreibt über die öffentlichen APIs oder die Batch API zurück.

Welcher Integrationsweg passt zu welcher Anforderung?

Die passende Lösung ergibt sich aus der Frage, wo die Logik liegt und wie viele Systeme beteiligt sind. Die folgende Tabelle ordnet die häufigsten Anforderungen ein.

Anforderung	Naheliegender Weg	Wann eigene Middleware dazukommt
ERP-Daten mit epilot abgleichen	Integration Toolkit	wenn weitere Systeme oder Regeln außerhalb des ERP beteiligt sind
Viele Datensätze auf einmal schreiben	Batch API	wenn die Daten vorher aus mehreren Quellen zusammengesetzt werden
Externen Dienst über Ereignisse informieren	Webhook	wenn das Ereignis eine Kette in anderen Systemen auslösen soll
Eigene Anwendung liest und schreibt epilot-Daten	öffentliche APIs	wenn Last, Wiederholungen und Protokoll eigene Logik brauchen
Daten aus externen Formularen übernehmen	3rd Party Journeys	selten nötig
Umsystem ohne fertige Verbindung	öffentliche APIs und Webhooks	in der Regel als eigener Mapper
Prozess läuft größtenteils außerhalb von epilot	Webhooks als Auslöser	Mapper, der den Prozess über Systemgrenzen steuert

Die Tabelle ist eine Orientierung, keine feste Regel. In der Praxis entscheidet das Gespräch über die konkreten Systeme.

Welche Umsysteme werden typischerweise angebunden?

Typischerweise werden vier Gruppen von Systemen angebunden: ERP und Abrechnung, Netzsysteme und Fachanwendungen, weitere CRM-Systeme sowie eigene Datenbanken mit Stamm- oder Altdaten. Jede Gruppe stellt andere Anforderungen.

ERP und Abrechnung

ERP- und Abrechnungssysteme sind oft führend für Verträge, Kundennummern und alles, was mit Geld zu tun hat. Für diese Gruppe ist das Integration Toolkit von epilot ausdrücklich gedacht. Eigene Entwicklung kommt dazu, wenn Abläufe über das ERP hinausreichen oder Daten vorher angereichert werden müssen.

Netzsysteme und Fachanwendungen

Netzbetreiber arbeiten mit Fachanwendungen, die eng an technische Abläufe gebunden sind, etwa für Netzanschlüsse oder Messwesen. Diese Systeme bleiben meist im Einsatz und haben eigene Schnittstellen. Hier ist eine individuelle Anbindung häufig der einzige saubere Weg.

Weitere CRM-Systeme

Nicht jedes Unternehmen stellt alle Bereiche gleichzeitig auf epilot um. Läuft ein weiteres CRM parallel, müssen Kontakte und Vorgänge in beide Richtungen abgeglichen werden, ohne Dubletten zu erzeugen.

Eigene Datenbanken mit Stamm- oder Altdaten

Viele Unternehmen haben Datenbanken mit Stammdaten oder historischen Daten, die nicht vollständig nach epilot wandern sollen. Eine Schnittstelle kann diese Daten bei Bedarf abfragen und die relevanten Informationen in epilot bereitstellen.

Wie werden Netzanschlussprozesse in epilot mit Umsystemen verbunden?

Über Schnittstellen, die den Vorgang in epilot mit den Fachsystemen des Netzbetreibers verbinden. Antrag, Status und Kommunikation laufen dann über epilot, technische Prüfungen und Stammdaten bleiben in den Systemen, in denen sie heute schon liegen. So kommt ein Netzanschlussbegehren ohne doppelte Pflege durch alle Schritte.

Was epilot selbst dafür mitbringt, beschreibt der Beitrag Wie epilot Netzanschlussprozesse im Ausbau erneuerbarer Energien vereinfacht. Formulare für Netzanschlussbegehren sind dort Journeys, die die Angaben von Anlagenbetreibern oder Installateuren einholen. Individuelle Workflows stoßen danach die passenden Prozessschritte an, und alle Informationen, Kenndaten und Dokumente liegen in einer digitalen Bauakte. Die Netzverträglichkeitsprüfung kann laut epilot manuell oder über die Anbindung einer Drittlösung erfolgen, nach einer solchen Integration auch automatisiert, auf Knopfdruck im Mitarbeiterportal oder direkt in der Journey.

Für die Zusammenarbeit mit Installateuren gibt es das Installateurportal. Laut den Anwendungsfällen des Installateurportals im epilot Hilfe-Center richtet es sich an Netzbetreiber, die mit konzessionierten Installateuren zusammenarbeiten, und führt den Anmeldeprozess mit dem Prozess der Inbetriebnahme zusammen. Seine Konfiguration baut auf der des Kundenportals auf.

Umsysteme kommen dabei typischerweise an diesen Stellen ins Spiel:

• Die Netzverträglichkeitsprüfung läuft in einem Fachsystem, und ihr Ergebnis soll ohne Abtippen in den Vorgang in epilot zurückkommen.
• Daten zum Anschlussobjekt, zum Beispiel zu einem bestehenden Hausanschluss, liegen in einem Netzsystem und werden im Vorgang gebraucht.
• Folgeschritte wie Baumaßnahmen für einen neuen Hausanschluss oder die Inbetriebnahme laufen in anderen Systemen weiter. Notwendige Baumaßnahmen lassen sich laut dem Beitrag von epilot als separater Prozess starten.
• Angaben, die Installateure im Installateurportal machen, sollen dort ankommen, wo sie fachlich weiterverarbeitet werden.

Technisch ist das dieselbe Aufgabe wie bei jedem anderen Umsystem: Ein Ereignis im Workflow wird per Webhook gemeldet, ein Mapper übersetzt die Daten für das Fachsystem und stellt dessen Antwort als Information in epilot bereit. Vorher steht auch hier die Frage aus dem nächsten Abschnitt: Welches System ist für welche Daten des Anschlusses führend?

Wer ist für welche Daten führend?

Für jede Datenart muss feststehen, welches System sie anlegt und ändert und welche Systeme sie nur lesen. Diese Festlegung ist wichtiger als jede technische Entscheidung, denn ohne sie überschreiben sich Systeme gegenseitig.

In der Praxis hilft eine einfache Übersicht je Datenart: führendes System, lesende Systeme, Richtung des Abgleichs und Auslöser. Ein Beispiel für die Denkweise: Ist das Abrechnungssystem für Kundennummern führend, vergibt epilot keine eigenen, sondern übernimmt sie.

Daraus folgen klare Regeln für die Schnittstelle. Sie schreibt nur in die Richtung, die festgelegt ist, und sie erkennt Konflikte, statt sie stillschweigend aufzulösen. Für Netzbetreiber, die regulatorische Anforderungen erfüllen müssen, ist diese Nachvollziehbarkeit besonders wichtig.

Wie gehen Sie mit Fehlern und Last um?

Fehler und Last werden in einer guten Integration bewusst behandelt: mit Wiederholungen, Idempotenz, Protokoll und Überwachung. Jedes Netzwerk fällt gelegentlich aus, und jede API hat Grenzen.

Die Seite zu Rate Limits in der epilot Dokumentation beschreibt, dass die API bei überschrittenem Limit mit HTTP 429 antwortet und im Header Retry-After angibt, wie viele Sekunden bis zum Zurücksetzen des Kontingents bleiben. Für große Datenmengen verweist epilot auf die Batch API und die ERP Integration API.

Auf der epilot-Seite hilft das Webhook-Monitoring. Jeder Webhook-Aufruf wird laut Dokumentation als Ereignis mit Erfolg oder Fehler protokolliert, standardmäßig vier Wochen lang aufbewahrt und kann erneut gesendet werden.

In der eigenen Middleware gehören dazu:

• Wiederholungen mit Wartezeit, die Retry-After beachten
• Idempotenz, damit ein doppelt gesendetes Ereignis keinen doppelten Datensatz erzeugt
• ein Protokoll mit eindeutiger Kennung je Nachricht über alle Systeme
• eine Überwachung, die meldet, wenn eine Anbindung stockt

Wer betreibt die Integration später?

Die Integration betreibt entweder Ihr eigenes Team oder ich im Rahmen eines Wartungsvertrags. Beides ist möglich, weil der Code Ihnen gehört.

Auf Wunsch übergebe ich den Code in Ihr eigenes Repository. Dann kann Ihr Team die Schnittstellen selbst weiterentwickeln und betreiben. Warum diese Frage gerade für Netzbetreiber wichtig ist, erklärt der Artikel Wem gehört der Integrationscode?.

Daten bleiben in Europa, die Verarbeitung erfolgt nach DSGVO, und wo nötig wird ein Auftragsverarbeitungsvertrag geschlossen. Vertragspartner ist die DigitalFreedom Global LLC; deutsches Recht ist auf Wunsch für Netzbetreiber möglich. Einzelheiten stehen im Abschnitt Vertragspartner auf der Startseite.

Wie sieht das in der Praxis bei einem Netzbetreiber aus?

Bei einem Netzbetreiber in Hessen laufen viele Prozesse außerhalb von epilot, und mehrere Drittsysteme sind über individuell entwickelte Schnittstellen angebunden. Der Name des Unternehmens bleibt vertraulich.

Für diese Anbindungen habe ich individuelle Mapper-Tools in Java mit Quarkus entwickelt. Sie laufen in Containern, sind skalierbar und wartbar. Zu den typischen Aufgaben solcher Mapper gehören Webhooks, REST-Aufrufe an Umsysteme, das Auslösen von Events in anderen Systemen und das Bereitstellen von Informationen in epilot.

Das Beispiel zeigt die typische Aufteilung. epilot bleibt die Plattform für Kundenprozesse und Konfiguration, die Mapper übernehmen die Logik zwischen den Systemen. Mehr Einblicke gibt der Abschnitt aus der Praxis auf der Startseite.

Ich arbeite dabei mit epilot zusammen und ergänze das Consulting-Team von epilot, ich ersetze es nicht. Für Einführung und Standardumfang bleibt epilot Ihr Ansprechpartner.

Wie starten Sie die Anbindung Ihrer Umsysteme?

Sie starten mit einem kostenlosen Erstgespräch, in dem wir Ihre Systeme und Abläufe durchgehen. Danach ist klar, welche Bordmittel von epilot reichen und wo eine eigene Schnittstelle sinnvoll ist.

1. Erstgespräch: kostenlos und unverbindlich, 30 Minuten über Microsoft Teams.
2. Individuelles Angebot: zugeschnitten auf Ihre Umsysteme, Datenformate und Anforderungen an den Betrieb.
3. Umsetzung: Die Schnittstellen werden entwickelt, getestet und mit Ihren Systemen in Betrieb genommen.

Alle Leistungen biete ich auf Basis eines individuellen Angebots an. Die Abrechnung erfolgt in Euro, für Geschäftskunden in der EU nach Prüfung der USt-IdNr. über VIES im Reverse-Charge-Verfahren, und eine Berufshaftpflichtversicherung besteht. Antworten auf weitere Fragen finden Sie in den häufigen Fragen auf der Startseite, einen Termin können Sie direkt im Buchungskalender wählen.