Omnichannel-Integrationsframework — Praxisbeispiel
Eine Factory-Method-Grundlage für Slack, Teams, Google Chat und Webex bei Resolve Systems
Überblick
Kontext, Ansatz und Ergebnis.
Problem
Jeder Enterprise-Chat-Kanal — Slack, Microsoft Teams, Google Chat, Webex — begann als individuelle Integration. Wenn der Fulfillment-Code je nach Kanal verzweigt, pflegst du im Grunde N Produkte, die unter Zeitdruck auseinanderdriften.
Meine Rolle
Ich habe das auf dem Factory Method basierende Integrations-Framework und die gemeinsamen Testing-Utilities entworfen und implementiert, auf denen jeder Channel-Adapter aufbaut. Das ist das Rückgrat, gegen das jeder Kanal auf der Plattform geschrieben wird, inklusive Voice. Das Designziel war eine Schnittstelle, die nichts darüber aussagt, wann eine Antwort eintrifft: Die Chat-Kanäle sind asynchron, ein Telefonanruf ist synchron und blockierend, und beides sind Adapter hinter derselben Factory. Eine Abstraktion, die nur für Kanäle mit demselben Timing-Modell funktioniert, ist kein Integrations-Framework, sondern ein Chat-Framework.
Einschränkungen
- Kanäle unterscheiden sich in Authentifizierungsmodellen, Payload-Strukturen und Rate Limits — diese Unterschiede mussten innerhalb der Adapter bleiben.
- Bestehende Live-Integrationen mussten weiter funktionieren, während das Framework darunter ersetzt wurde.
- Secure-by-default-Patterns (Authentifizierung, MFA, Secrets-Handling) waren für Enterprise-Kunden Pflicht.
Architektur
Channel-Adapter normalisieren jede eingehende Nachricht in einen gemeinsamen Envelope; eine Factory Method instanziiert den richtigen Adapter pro Kanal; der Fulfillment-Code arbeitet mit Intents und Entities und verzweigt niemals nach Kanal. Gemeinsame Testing-Utilities liefern jedem neuen Adapter von Anfang an dieselbe Conformance-Suite.
Ergebnis
Slack, Microsoft Teams, Google Chat und Webex laufen alle auf einem Rückgrat, und jeder neue Kanal kostet weniger als der vorherige. Über zwei Jahre wurden keine kritischen Sicherheitslücken in diesen Enterprise-Integrationen festgestellt.
Was ich anders machen würde
Das gemeinsame Intent-Schema am ersten Tag definieren und wie eine API versionieren — divergierende Intent-Definitionen später zusammenzuführen ist der teure Weg. Den Adapter zuletzt bauen: zuerst den gemeinsamen Envelope und die Testing-Story richtig hinbekommen.
Erkenntnisse
Was ich mitnehme.
Der Fulfillment-Code darf nicht nach Kanal verzweigen. Der Adapter ist das Letzte, was du baust, nicht das Erste – sorge dafür, dass das gemeinsame Envelope- und Testkonzept stimmt, dann wird jeder neue Kanal günstiger.
Stack
Tools und Plattformen.
Verwandte Texte
Notizen aus diesem Projekt.
- Assembled Primitives vs. a PlatformI built a voice agent out of cloud primitives, and it worked. It has since been replaced by a purpose-built voice platform, and I think that was the right call.
- What I Learned Designing Omnichannel Backend IntegrationsShared intent schema, eventually-consistent conversation state, and why the channel should be the last thing your backend knows about.
Reden wir
Möchtest du über solche Arbeit sprechen?
Wenn du für ähnliche Backend-, AWS-, Voice- oder Integrations-Arbeit einstellst — oder einfach Architektur-Notizen vergleichen willst — melde dich direkt.