Ich will über den Schnittpunkt von Telecom-Billing, Java EE, GWT und Salesforce.com reden — eine Kombination, die so durch-und-durch 2013 ist, dass sie ein Moodboard von Flat Design-Launch und endlosen Debatten, ob Responsive CSS ein Fad sei, verdienen würde. Aber hier ist die Sache: Ich habe in diesem Stack echte Software für echte Telecom-Anbieter geshippt, die echtes Geld verarbeiteten. Und ein nicht triviales Maß von dem, was ich in dieser Umgebung gelernt habe, ist heute noch anwendbar, weil die zugrundeliegenden Probleme strukturell sind, nicht technologisch.
BluLogix baute die Cloud Innovation Suite — eine Cloud-Billing-Plattform für Telecom-Anbieter. Meine Aufgabe: Backend-Entwicklung, Frontend-Supervision, BPMN-Workflow-Design und, am aufschlussreichsten, die Integration von CIS mit Salesforce.com über Talend ETL. Diesen letzten Teil will ich in diesem Post am meisten besprechen, weil da das Engineering wirklich interessant wurde.
Wie Telecom-Billing wirklich aussieht
Bevor du verstehen kannst, warum Salesforce-Integration für ein Telecom-Billing- System schwer ist, brauchst du ein grobes Modell davon, was Telecom-Billing eigentlich ist.
Telecom-Billing ist keine Rechnung. Es ist ein System, das kontinuierlich Events bewertet — Anrufe, Datensitzungen, SMS-Nachrichten, API-Aufrufe, Cloud- Ressourcenverbrauch — gegen einen Produktkatalog, Preisregeln und Rabatte anwendet, Abonnementstatus verwaltet, Zyklusmitte-Änderungen handhabt (Plan- Upgrades, anteilige Abrechnung, Add-ons), wiederkehrende Gebühren auf Billing-Zyklen ausführt, regulatorisch konforme Rechnungen erstellt, Zahlungen verarbeitet, Streitigkeiten behandelt und Umsatz-Assurance-Reporting produziert. Der Billing-Zyklus für einen einzelnen Enterprise-Kunden könnte Dutzende Millionen Usage-Events umfassen, einen Produktkatalog mit Hunderten von Tarifen, mehrere Währungen und Steuerjurisdiktionen über mehrere Länder.
Deshalb gibt es Telecom-Billing-Systeme als spezialisierte Softwarekategorie. Das geht nicht in einer Tabellenkalkulation. Das geht nicht in QuickBooks. Das Datenmodell unterscheidet sich grundlegend von allgemeiner Finanzsoftware.
GWT — Google Web Toolkit — war 2013 die Art, wie man Rich-Web-Interfaces in Java baute, wenn man wollte, dass der UI-Code typsicher, testbar und von Java-Engineers geschrieben ist, die kein gutes JavaScript können mussten. Man schrieb Java, GWT kompilierte es zu JavaScript, und der Typchecker der IDE arbeitete über den gesamten Stack. 2013, bevor TypeScript existierte und bevor moderne Frontend- Frameworks gereift waren, war das ein vernünftiger Trade. Das Output-JavaScript war verbose und der Debug-Zyklus war langsam, aber die Developer Experience für Java-zentrierte Teams war besser als die Alternative: rohes JavaScript, das Java-Engineers mit derselben Begeisterung begegnet wären wie PHP. GWT ist jetzt tot. Das ist in Ordnung. 2013, in einem Java-EE-Shop, der Enterprise-Software baute, war es das richtige Tool.
Warum Salesforce dein Billing-System hasst
Salesforces Datenmodell ist rund um eine CRM-Abstraktion gebaut: Accounts, Contacts, Opportunities und Products. Dieses Modell funktioniert hervorragend für Verkaufsprozesse. Es passt miserabel zu Telecom-Billing.
Ein konkretes Beispiel. In Salesforce ist ein Account ein Unternehmen. Eine Opportunity ist ein potentieller Verkauf. Ein Product ist etwas, das du verkaufst. Sobald die Opportunity abgeschlossen ist, wird sie zu einem Order, und die Products werden Teil dieses Orders.
In einem Telecom-Billing-System könnte ein “Kunde” mehrere Accounts haben (einen pro Tochtergesellschaft), jeder mit mehreren Abonnements, jedes Abonnement potenziell aus mehreren Service-Bundles bestehend, jedes Service-Bundle mit mehreren bewerteten Komponenten mit verschiedenen Billing-Zyklen und Preisstufen. Die Beziehung zwischen “was das Vertriebsteam verkauft hat” und “was das Billing-System bewertet und berechnet” ist many-to-many auf Arten, die Salesforces Standard-Objekte einfach nicht repräsentieren.
Wenn man gebeten wird, diese zwei Systeme zu integrieren — CIS auf der einen Seite, Salesforce auf der anderen — ist die erste Phase der Arbeit nicht technisch. Sie ist taxonomisch. Man verbringt Wochen damit, Salesforce-Konzepte auf CIS-Konzepte zu mappen und zu dokumentieren, wo es kein Mapping gibt, wo die Konzepte nur annähernd äquivalent sind und wo der Mismatch so fundamental ist, dass man Custom Objects auf einer oder beiden Seiten braucht.
Konkret bei BluLogix nutzten wir Talend Open Studio für die ETL-Schicht. Talend ist ein visuelles ETL-Tool: man baut Datenflüsse als gerichtete Graphen von Transformationskomponenten, und Talend generiert den zugrundeliegenden Java-Code. Das visuelle Modell ist nützlich für Stakeholder, die die Integrationslogik verstehen und genehmigen müssen. Der generierte Code ist das, was tatsächlich läuft. Der Mismatch zwischen “was der Stakeholder im visuellen Modell genehmigte” und “welche Edge Cases der generierte Code um 3 Uhr morgens am ersten Tag des Billing-Zyklus trifft” — da verdient man sein Gehalt.
BPMN für Billing-Workflows
Die CIS-Plattform nutzte BPMN für ihre Business-Process-Definitionen — nicht zufällig dasselbe Workflow-Modell, das ich später bei Talentera mit Camunda verwenden würde. Telecom-Billing hat komplexen bedingten Zustand: ein Abonnement kann aktiv sein, suspendiert (Nichtzahlung), suspendiert (Kundenanfrage), terminiert, portiert, transferiert. Übergänge zwischen Zuständen haben Geschäftsregeln: ein terminiertes Abonnement kann nicht reaktiviert werden; Suspendierung wegen Nichtzahlung löst einen anderen Reaktivierungsflow aus als freiwillige Suspendierung. Diese Regeln unterscheiden sich nach Jurisdiction und Produkttyp.
BPMN ist die richtige Modellierungssprache dafür. Die Alternative ist hartcodierte State-Machine-Logik im Billing-Engine, was bedeutet, dass jede Regeländerung ein Code-Deployment ist. Mit BPMN ist eine Änderung des Suspendierungs-zu- Reaktivierungs-Workflows für einen bestimmten regulatorischen Markt ein Process- Definition-Deployment, kein Code-Deployment. Das Compliance-Team kann das BPMN-Diagramm direkt reviewen statt Java zu lesen. Das ist kein theoretischer Vorteil — Compliance-Review-Timelines werden in Wochen gemessen, und “wir müssen den Billing-Engine neu deployen, um diesen Workflow zu aktualisieren” fügt Wochen zu jeder Compliance-Änderung hinzu.
Die Spring-Security-Schicht handhabte Access Control über die internen Services der Billing-Plattform. Spring WS deckte die SOAP-Service-Interfaces — 2013 war SOAP noch die Lingua Franca für Enterprise-Integration, und die größeren Telecom- Anbieter, die man adressierte, hatten Middleware, die SOAP sprach und WSDL erwartete. Das GWT-Frontend redete mit Spring-MVC-Endpunkten. Das war Standard- Java-EE-Architektur der Zeit. Langweilig by Design.
Die ETL-Arbeit, die wirklich zählte
Die Talend-basierte Salesforce-Integration hatte eine Kernanforderung: Wenn ein Sales-Deal in Salesforce abgeschlossen wurde (Opportunity zu Closed Won), musste das entsprechende Abonnement und die Billing-Konfiguration in CIS ohne manuelle Dateneingabe erstellt werden. Manuelle Dateneingabe im Telecom-Billing ist, wo Umsatz-Leakage passiert. Eine verpasste Rabatt-Konfiguration, ein falsches Billing-Zyklus-Datum, ein falsch konfiguriertes Produkt-Bundle — das sind keine Bugs, die die Software zum Absturz bringen. Sie verursachen falsche Rechnungen. Falsche Rechnungen erzeugen Streitigkeiten. Streitigkeiten kosten Zeit und erodieren das Kundenvertrauen. Im Telecom, wo Enterprise-Verträge auf Millionen Dollar jährlich laufen, ist falsche Rechnungsstellung existenziell.
Der Talend-Job, der das handhabte, lief nach einem Zeitplan, pollte Salesforce über sein SOAP-API (später REST-API, als Salesforce seine API-Oberfläche erweiterte), zog Opportunities im Closed-Won-Zustand, die noch nicht in CIS bereitgestellt wurden, transformierte die Opportunity- und zugehörigen Produktdaten in CIS-Abonnementobjekte, erstellte die Billing-Konfiguration und markierte den Datensatz als bereitgestellt. Das Error Handling war komplexer als der Happy Path: Partielle Fehler mussten retryable sein, ohne doppelte Abonnements zu erstellen. Salesforces Concurrency-Modell für Bulk-Operationen musste respektiert werden. Das CIS-Transaktionsmodell musste Atomizität über die Abonnement-Erstellung und Billing-Konfiguration sicherstellen.
Der Teil, den mir niemand vorher gesagt hatte: Salesforces Datenmodell ist variabler als seine API-Dokumentation vermuten lässt. Verschiedene Salesforce-Orgs, von verschiedenen Admins über verschiedene Perioden konfiguriert, haben verschiedene Feld-Layouts, Custom Fields, Validierungsregeln. Eine Integration, die perfekt gegen eine Org funktioniert, muss gegen jede Org, in der sie deployed wird, neu verifiziert werden. Wir bauten einen Validierungsschritt in den Talend-Job ein, der die Quelldatenform verifizierte, bevor eine Transformation versucht wurde — sodass Fehler als Datenqualitätsfehler oberflächen und nicht als korrumpierte CIS-Datensätze. Dieser Validierungsschritt rettete uns ungefähr einen Data-Incident pro Deployment.
Das Ding mit dem Shippen an zahlende Telecom-Kunden
Es gibt eine Kategorie von Engineering-Erfahrung, die man nur bekommt, indem man an Kunden shippt, die einen anrufen, wenn etwas schiefläuft. Nicht ein Ticket eröffnen. Anrufen. Telecom-Anbieter haben Operations-Center. Wenn Billing kaputt ist, weiß jemand in diesem Operations-Center das, und dieser Jemand weiß, wen er anrufen soll, und er ruft an.
Die Verantwortlichkeit, die das erzeugt, ist klärend. Man shippt keine spekulative Infrastruktur. Man shippt keine Dinge, die man nicht monitoren kann. Man baut die operativen Tooling vor dem Feature, weil man weiß, dass jemand anrufen wird und man in zehn Minuten eine Antwort geben können muss. Der Sorgfaltsstandard im Telecom-Billing ist deutlich höher als in den meisten SaaS-Kategorien, weil die Kosten des Falschliegen-Könnens auf den Dollar quantifizierbar sind.
Ich habe echte Telecom-Billing-Events verarbeitet. Ich habe eine Integration geshippt, die echte Kundendaten zwischen einem Billing-System und einem CRM bewegte. Ich habe es in GWT und Java EE und Talend und BPMN gemacht, mit Spring Security und Spring WS und einer XML-schweren Welt, die heute antik wirkt.
Die Welt sieht nicht so anders aus. Salesforce hat immer noch dieselben Datenmodell-Mismatches mit jedem spezialisierten System, das es zu integrieren versucht. Billing-Systeme sind immer noch event-driven State-Machines unter der Haube. BPMN ist immer noch das richtige Tool für Compliance-getriebene Workflows. Der Technologie-Stack hat sich geändert. Die Probleme sind dieselben.
Ich kenne den alten Stack. Ich weiß, warum er die Entscheidungen traf, die er traf. Das ist seltener als es klingt.