Wann reicht Low-Code bei epilot nicht mehr?

epilot Low-Code trägt bei Energieversorgern, Stadtwerken und Netzbetreibern sehr weit. Die Plattform deckt viele Abläufe über Konfiguration ab, ohne dass jemand eine Zeile Code schreiben muss. Dieser Artikel zeigt, an welchen Stellen klassische Softwareentwicklung trotzdem wieder nötig wird und wie sie sich mit epilot verträgt, statt dagegen zu arbeiten.

Geschrieben hat ihn Marcel R. G. Berger. Ich bin seit über 20 Jahren Softwareentwickler und Softwarearchitekt und arbeite mit epilot als externer Consultant und Entwickler für Apps und Individualisierungen. Der Artikel richtet sich an IT-Verantwortliche, die epilot einführen oder schon nutzen und vor der Frage stehen, ob eine Anforderung noch in die Konfiguration passt oder ob eine eigene Schnittstelle her muss.

Was leistet epilot als No-Code- und Low-Code-Plattform?

epilot ist eine hervorragende No-Code- und Low-Code-Plattform, die einen großen Teil der Abläufe eines Energieversorgers ohne Programmierung abbildet. Datenmodelle, Journeys, Automationen und Portale werden konfiguriert, nicht entwickelt.

Für viele Unternehmen ist das der schnellste Weg zu stabilen Prozessen. Eine Konfiguration ist leichter zu ändern als Code, sie lässt sich von Fachabteilungen nachvollziehen, und Updates der Plattform kommen ohne eigenen Aufwand.

Dazu bietet epilot selbst mehrere Integrationswege an. Laut der Übersicht zu Integrationen in der epilot Entwicklerdokumentation gehören dazu unter anderem das Integration Toolkit für ERP-Systeme, eine Batch API, Webhooks für Ereignisse in Echtzeit und öffentliche APIs für eigene Integrationen mit voller Kontrolle.

Die Frage ist also nicht, ob epilot integrieren kann. Die Frage ist, wann eine Integration so individuell wird, dass sie eigenen Code braucht.

Woran erkennen Sie, dass Low-Code an seine Grenze kommt?

Low-Code kommt an seine Grenze, wenn eine Anforderung Logik außerhalb der Plattform braucht, die sich nicht mehr sinnvoll konfigurieren lässt. In der Praxis zeigt sich das an wiederkehrenden Signalen.

• Ein Prozess läuft zu einem großen Teil außerhalb von epilot, zum Beispiel in einem Fachsystem, das weiter im Einsatz bleibt.
• Umsysteme wie weitere CRM-Systeme, Datenbanken, ERP, Abrechnung oder Netzsysteme sollen mit epilot Daten austauschen, und dafür gibt es keine fertige Verbindung.
• Daten müssen auf dem Weg zwischen zwei Systemen aufwendig umgewandelt, zusammengeführt oder geprüft werden.
• Ein Ereignis in epilot soll eine Aktion in einem anderen System auslösen, und das Ergebnis soll zurück nach epilot.
• Eine Anbindung muss Fehler sauber behandeln, wiederholbar sein und im Betrieb überwacht werden.

Trifft keines dieser Signale zu, ist Konfiguration fast immer die bessere Wahl. Trifft eines oder mehrere zu, lohnt sich der Blick auf eine eigene Schnittstelle.

Was tun, wenn Prozesse außerhalb von epilot laufen?

Wenn Prozesse außerhalb von epilot laufen, bleibt dieser Teil im Fachsystem, und eine Schnittstelle sorgt dafür, dass beide Seiten dieselben Daten sehen. epilot muss dafür nichts abbilden, was es nicht abbilden soll.

Genau diese Lage gibt es in meinem aktuellen Projekt bei einem Netzbetreiber in Hessen. Viele Prozesse sind dort nicht in epilot abgebildet, sondern laufen außerhalb der Plattform. Deshalb sind mehrere Drittsysteme über individuell entwickelte Schnittstellen an epilot angebunden. Wie das aufgebaut ist, beschreibt der Abschnitt Aus der Praxis auf der Startseite.

Wichtig ist dabei die Haltung: Es geht nicht darum, epilot zu umgehen. Es geht darum, epilot dort zu nutzen, wo es stark ist, und die übrigen Systeme so anzubinden, dass Abläufe über Systemgrenzen hinweg stabil laufen.

Welche Umsysteme müssen typischerweise angebunden werden?

Typischerweise werden Systeme angebunden, die schon lange im Unternehmen laufen und nicht ersetzt werden sollen. Bei Energieversorgern und Netzbetreibern sind das vor allem diese Gruppen.

• ERP-Systeme und Abrechnung
• Netzsysteme und weitere Fachanwendungen des Netzbetriebs
• weitere CRM-Systeme neben epilot
• eigene Datenbanken mit Stammdaten oder historischen Daten

Für ERP-Systeme bietet epilot mit dem Integration Toolkit einen eigenen, standardisierten Weg an. Die Dokumentation zum Integration Toolkit hält dazu ausdrücklich fest, dass das Toolkit Middleware nicht überflüssig macht, sondern die Schnittstelle zwischen epilot und dieser Zwischenschicht standardisiert.

Diese Zwischenschicht ist genau der Ort, an dem individuelle Entwicklung ansetzt. Je mehr Umsysteme beteiligt sind und je unterschiedlicher ihre Datenformate, desto mehr Logik sammelt sich dort.

Wie man ERP, Abrechnung und Netzsysteme Schritt für Schritt anschließt, beschreibt der Artikel Umsysteme an epilot anbinden.

Wann werden Datentransformationen zu komplex für Konfiguration?

Datentransformationen werden zu komplex für Konfiguration, wenn sie mehrere Quellen zusammenführen, fachliche Regeln enthalten oder nachweisbar korrekt sein müssen. Dann gehört die Logik in Code, der getestet, versioniert und geprüft werden kann.

Einfache Zuordnungen wie ein Feld hier, ein Feld dort lassen sich gut konfigurieren. Anders sieht es aus, wenn zum Beispiel ein Datensatz aus epilot erst mit Daten aus einer Datenbank angereichert, dann in das Format eines Fachsystems umgewandelt und vorher auf Vollständigkeit geprüft werden muss.

Ein Mapper erledigt genau diese Arbeit: Er ordnet Felder einander zu, wandelt Formate um, validiert die Daten und behandelt Fehler. Wie so ein Mapper aufgebaut ist, zeigt der Artikel Mapper zwischen epilot und Umsystemen mit Quarkus.

Wie lösen Ereignisse in epilot Aktionen in anderen Systemen aus?

Ereignisse in epilot lösen Aktionen in anderen Systemen über Webhooks aus. epilot sendet bei einem Ereignis einen HTTP-POST an eine konfigurierte Adresse, und ein eigener Dienst führt dann die nötigen Schritte in den Umsystemen aus.

Die Dokumentation zu den epilot Webhooks beschreibt das so: Über die Webhooks API abonnieren Sie Ereignisse in Ihrem epilot-Konto, und bei jedem Ereignis sendet epilot einen HTTP-POST an die hinterlegte URL. Als Beispiel für ein Ereignis nennt die Dokumentation entity:created.

Der empfangende Dienst prüft zuerst, ob die Anfrage wirklich von epilot kommt. epilot signiert jede Webhook-Anfrage, und die Seite zur Sicherheit der Webhooks empfiehlt ausdrücklich, Signaturen immer zu prüfen, bevor ein Payload verarbeitet wird.

Danach beginnt die eigentliche Arbeit: Daten übersetzen, ein Event in einem anderen System auslösen und das Ergebnis bei Bedarf als Information zurück in epilot schreiben. Diese Kette ist der typische Kern einer epilot Integration mit Umsystemen.

Worauf es beim Empfang dieser Anfragen im Detail ankommt, zeigt der Artikel epilot Webhooks sicher verarbeiten. Wie Daten in die andere Richtung fließen, beschreibt der Artikel REST-API Schnittstelle für epilot.

Warum braucht eine Integration Regeln für Last und Wiederholung?

Eine Integration braucht Regeln für Last und Wiederholung, weil jede API Grenzen hat und jedes Netzwerk gelegentlich ausfällt. Ohne diese Regeln gehen Daten verloren oder werden doppelt verarbeitet.

Die Seite zu Rate Limits in der epilot Dokumentation beschreibt, dass die API beim Überschreiten eines Limits mit HTTP 429 antwortet und im Header Retry-After angibt, wann es weitergehen kann. Für größere Datenmengen verweist epilot auf die Batch API und das Integration Toolkit.

In einer Konfiguration lässt sich so etwas nur begrenzt abbilden. In einem eigenen Dienst dagegen gehören diese Punkte zum Handwerk:

• Wiederholungen mit Wartezeit, die den Hinweis Retry-After beachten
• Idempotenz, damit ein wiederholter Aufruf keinen doppelten Datensatz erzeugt
• ein sauberes Protokoll, aus dem sich nachvollziehen lässt, welcher Datensatz wann wohin ging
• eine Überwachung, die meldet, wenn eine Anbindung stockt

Für Netzbetreiber ist dieser Teil oft wichtiger als die eigentliche Datenzuordnung. Ein Prozess, der über Systemgrenzen läuft, ist nur so stabil wie seine schwächste Verbindung.

Low-Code oder klassische Entwicklung: was passt wofür?

Low-Code passt für Abläufe innerhalb von epilot, klassische Entwicklung für Logik zwischen epilot und anderen Systemen. Die folgende Übersicht hilft bei der Einordnung.

Anforderung	Low-Code in epilot	Klassische Entwicklung
Ablauf liegt vollständig in epilot	passt in der Regel	meist nicht nötig
Umsystem mit fertiger Verbindung	passt, wenn der Standard reicht	wenn der Standard nicht reicht
Umsystem ohne fertige Verbindung	stößt an Grenzen	eigene Schnittstelle
Daten aus mehreren Quellen zusammenführen	stößt an Grenzen	Mapper mit Tests
Ereignis soll Aktion in anderem System auslösen	Webhook konfigurieren	Dienst, der den Webhook empfängt und handelt
Nachweisbare Fehlerbehandlung im Betrieb	eingeschränkt	Logging, Wiederholungen, Überwachung

Die Tabelle ist keine starre Regel. Sie zeigt aber, dass die Grenze selten bei epilot selbst liegt, sondern fast immer an der Stelle, an der Daten die Plattform verlassen oder in sie hineinkommen.

Wie viel Logik sollte in epilot bleiben?

So viel wie möglich. Alles, was sich in epilot sauber konfigurieren lässt, sollte dort bleiben, denn Konfiguration ist für Fachabteilungen sichtbar und wird mit der Plattform weiterentwickelt.

In die eigene Schnittstelle gehört nur, was zwischen den Systemen passiert: die Übersetzung der Daten, die Kommunikation mit den Umsystemen und die Fehlerbehandlung. Diese Trennung hält beide Seiten schlank. epilot bleibt übersichtlich, und der Integrationscode bleibt klein genug, um ihn zu verstehen, zu testen und zu warten.

Eine gute Faustregel lautet: Wenn eine Regel nur für epilot gilt, gehört sie nach epilot. Wenn sie nur gilt, weil ein anderes System etwas anders erwartet, gehört sie in den Mapper.

Ersetzt ein Entwickler das Consulting-Team von epilot?

Nein. Ein Entwickler ersetzt das Consulting-Team von epilot nicht, er ergänzt es. Für die Einführung und den Standardumfang bleibt das Consulting-Team von epilot Ihr Ansprechpartner.

Ich setze dort an, wo der Standard von epilot endet: bei Schnittstellen zu Ihren eigenen Systemen und bei individuellen Erweiterungen. Ich arbeite dabei mit epilot zusammen, als externer Consultant und Entwickler für Apps und Individualisierungen. Arbeiten an der epilot-Plattform selbst erfolgen nur in Zusammenarbeit mit epilot.

Für Sie bedeutet das eine klare Aufteilung. epilot verantwortet die Plattform und ihre Konfiguration, die individuelle Integration verantwortet die Seite, die sie entwickelt. Welche Leistungen dazu gehören, steht im Abschnitt Was ich für epilot-Kunden mache.

Wie starten Sie, wenn Sie an eine Grenze stoßen?

Sie starten mit einem kurzen Gespräch über Ihre Systeme und Abläufe. Daraus ergibt sich, ob Konfiguration reicht oder ob eine eigene Schnittstelle sinnvoll ist.

1. Erstgespräch: kostenlos und unverbindlich, 30 Minuten über Microsoft Teams.
2. Individuelles Angebot: Nach dem Gespräch erhalten Sie ein Angebot, das auf Ihre Systeme zugeschnitten ist.
3. Umsetzung: Schnittstellen oder App werden entwickelt und mit Ihren Systemen in Betrieb genommen.

Wie diese Schritte im Einzelnen aussehen, beschreibt der Artikel zum Ablauf eines epilot Integrationsprojekts beim Netzbetreiber.

Der Code gehört dabei Ihnen. Warum das gerade für Netzbetreiber wichtig ist, erklärt der Artikel Wem gehört der Integrationscode?. Antworten auf weitere Fragen finden Sie in den häufigen Fragen auf der Startseite, einen Termin können Sie direkt im Buchungskalender wählen.