Mustafa.
ende
Zurück zu allen Projekten

TechnoStore — Revenue Cloud Quote-to-Cash für den DACH-Markt

End-to-End-Quote-to-Cash-Demo für B2B-Elektronik auf Salesforce Revenue Lifecycle Management, Contract Lifecycle Management und Industries CPQ — orchestriert mit MuleSoft Anypoint über zehn externe Systeme.

Jahr
2025
Rolle
Salesforce Developer
Technologien
ApexRevenue Lifecycle ManagementContract Lifecycle ManagementIndustries CPQAgentforce Actions (@InvocableMethod)SAP OData v2 (CSRF, deep-insert)CAMT.053 / ISO 20022DATEV (EXTF / SKR04)Approval Processes (multi-tier)MuleSoft AnypointPlatform EventsNamed CredentialsSFDX (6 packages)Kevin O'Hara trigger frameworkOpenAPI 3.0arc42

Eckdaten

  • 10 externe Systeme via MuleSoft + Apex — inkl. SAP S/4HANA (OData v2: CSRF, Deep-Insert, CloudEvents) und dem deutschen Finanz-Stack (lexoffice + DATEV EXTF/SKR04)
  • Agentforce-ready Apex-Actions, Einstein-Copilot-aufrufbar (Umsatz-Summary + Zahlungserinnerungen)
  • CAMT.053- / ISO-20022-Kontoauszug-Parser für SEPA-Zahlungsabgleich
  • Mehrstufige Rabatt-Genehmigung (>30 % Finance Director, >50 % VP) + account-kontextbezogene Produktqualifizierung (Expression Sets)
  • Integration-Health-Observability: Correlation-IDs, Fehlerklassifizierung, zweischichtige Idempotenz, Slack-Eskalation + Dashboards
  • ~79 Apex-Klassen in 6 SFDX-Paketen; 33 ADRs (Nygard) + arc42-Solution-Blueprint
  • 50 STAR-Einträge programmatisch nach Notion publiziert
  • DACH-spezifisch: 19 % USt (Multi-Country-Fallback-Tabelle), DHL-Präferenz, DE/AT/CH-Adressparsing

Funktionen im Detail

Salesforce → Stripe, end to end

Der Payment-Flow in Anypoint Studio: Ein Salesforce Platform Event (On Invoice Payment Requested) triggert den Mule-Flow, der den Stripe-Body in DataWeave baut, eine Stripe-Checkout-Session erzeugt und die Payment-URL direkt zurück nach Salesforce schreibt. Darunter routet der stripe-webhook-flow den eingehenden Webhook nach Event-Typ. Die Konsole meldet die Anwendung als DEPLOYED — das läuft wirklich.

Anypoint Studio: the invoice-payment-requested flow — a Salesforce Platform Event triggers Mule, which builds the Stripe body and creates a Checkout session

Der Order-Fan-out — mit eingezeichneten Fehlerpfaden

Ein Choice-Router verzweigt über die Fulfillment-Flags (physical / digital / both). Jeder Zweig ruft Sendcloud innerhalb eines Try-Scopes auf, der einen eigenen Error-Handler und einen Sendcloud-GET-Fallback besitzt; danach legt ein Retry-Scope den Salesforce-Datensatz an und ein Logger hält das Ergebnis fest. Das ist die Integrations-Observability-Schicht aus der Fallstudie — Fehlerklassifizierung, Fallbacks und Idempotenz — sichtbar statt nur behauptet.

Anypoint Studio: the order fan-out — a Choice router branches on fulfillment flags, each branch wrapped in a Try scope with error handling, fallbacks and retry scopes

DataWeave — wo „DHL bevorzugt“ tatsächlich steht

Die Transformation Extract Preferred Carrier in DataWeave: Sie liest die Versandarten von Sendcloud, filtert auf DHL (die DACH-Carrier-Präferenz), fällt auf die erste verfügbare Methode zurück, wenn es keine gibt, und setzt auf jedes Feld einen Default. Die Zeile in der Fallstudie, dass der DACH-Carrier bevorzugt wird, ist keine Folie — sie sind diese sechs Zeilen Code.

DataWeave: the Extract Preferred Carrier transform filters Sendcloud shipping methods for DHL and defaults every field

SAP S/4HANA — wirklich abgefragt, nicht gemockt

Der SAP-Integrations-Flow: ein GET gegen SAP S/4HANA Cloud auf Business-Partner-Datensätze, die Antwort geloggt und diagnostiziert, die Datensätze in DataWeave extrahiert und eine finale Antwort zusammengesetzt. Das ist die OData-Schicht hinter der SAP-Aussage der Fallstudie — der Flow läuft, und die Konsole meldet die gelesenen Datensätze.

Anypoint Studio: the SAP S/4HANA Business Partner query flow with the DataWeave response transform

Keine Secrets im Quellcode

Die Configuration XML: der Salesforce-Connector, der Webhook-HTTP-Listener und die Stripe- / Slack- / Sendcloud-Request-Configs. Jede Credential wird über einen Property-Placeholder aufgelöst — ${salesforce.password}, ${stripe.host}, ${sendcloud.secret} — nie als hartkodierter Wert. Die Secrets liegen außerhalb des Repositories: der Unterschied zwischen einer Demo und etwas, das man wirklich deployen könnte.

Anypoint Studio Configuration XML: Salesforce, HTTP listener, Stripe, Slack and Sendcloud configs — all credentials as property placeholders

Das Problem

DACH-Enterprise-Salesforce-Rollen (T-Systems, Allianz Technology, Mercedes-Benz.io, BMW Group IT, SAP Industries Practice) verlangen konsequent dieselbe Kombination: Revenue Cloud + Industries CPQ auf Salesforce-Seite plus echte MuleSoft- + Payment- + Logistik- + E-Signature-Integration auf der Orchestrierungsseite. Die meisten Portfolio-Projekte zeigen eines von beiden, fast keines spiegelt deutsche Marktspezifika wie Mehrwertsteuer, DHL-Präferenz oder mehrsprachiges Adressparsing wider.

Architektur

Vertriebsmitarbeiter arbeiten mit einem account-kontextbezogenen Industries-CPQ-Katalog. Bundle-Konfiguration triggert einen asynchronen attributbasierten Pricing-Service. Bei Auftragsaktivierung fächert der OrderTriggerHandler parallel zu fünf Downstream-Systemen aus: JIRA (direkter Apex-Callout) für Bestandstickets, Slack #warehouse (Platform Event → MuleSoft) für Kommissionierung, DocuSign (Apex + Named Credential) für die Vertragsdose, Stripe (MuleSoft Outbound) für Zahlung und eine gebrandete Rechnungs-Mail. Der Stripe-Webhook trifft MuleSoft, wird HMAC-SHA256 verifiziert und streut zurück nach Salesforce (Status Paid), Slack #payments-team und einen Choice-Router für Fulfilment — Sendcloud/DHL für physische Ware, Lizenzschlüssel-Generierung für digitale. Der DocuSign-Connect-Webhook landet auf einer Salesforce Site, publiziert ein Platform Event, um die Guest-User-FLS-Limits zu umgehen, und ein Autolaunched Flow erstellt das Asset. Querschnittlich fädelt eine Integration-Health-Schicht Correlation-IDs von Salesforce → MuleSoft → Provider, klassifiziert Fehler (Auth / Validierung / Timeout / Downstream), eskaliert 5xx nach Slack und erzwingt zweischichtige Idempotenz; Umsatz- und Zahlungserinnerungs-Logik ist zudem als Agentforce-ready Apex-Actions (Einstein-Copilot-aufrufbar) verfügbar.

Der Ansatz

Der Code ist in sechs SFDX-Pakete aufgeteilt (force-app + controllers + services + handlers + actions + tests), sodass Architekturgrenzen schon auf Dateisystem-Ebene sichtbar sind — eine Service-Klasse, die ApexPages aufruft, fiele im Code-Review sofort auf. Alle Trigger erben vom Kevin-O'Hara-TriggerHandler mit Rekursionsschutz und Bypass-Mechanismus. Jeder externe Aufruf nutzt eine Named Credential und ist in einen idempotenten Service verpackt: Der Stripe-Webhook prüft Order.Status vor dem Mutieren, DocuSign nutzt eine Platform-Event-Indirektion für den Guest-User-Kontext, JIRA bleibt im direkten Apex, weil der Flow synchron und volumenarm ist — während Stripe über Mule geht wegen Retry und Queueing. Die 50-teilige Notion-Doku ist selbst Feature: NotionPublishService.publishEnterprise() orchestriert sechs API-Calls pro Eintrag, um Notions Zwei-Ebenen-Nesting-Limit zu umgehen.

Das Ergebnis

Eine zusammenhängende zwölfminütige Quote-to-Cash-Story über zehn externe Systeme, bereit sowohl für Portfolio-Interviews als auch für kundennahe Lösungsgespräche. Dokumentiert als 33 Architecture Decision Records im Nygard-Format, arc42-Solution-Blueprint, OpenAPI-3.0-Specs für eingehende Webhooks und eine 17-Request-Postman-Collection. Gemessene End-to-End-Latenz: 2–6 Sekunden. Die DACH-Ausrichtung — Mehrwertsteuer-Formeln, DHL-Präferenz, DE/AT/CH-Adressparsing — ist das Detaillevel, das deutsche Enterprises erwarten, nicht generisches Salesforce-Wissen.

Externe Integrationen

GitHub & Notion — privat, Walkthrough auf Anfrage