Manche Produktideen beginnen nicht mit einer Roadmap, sondern mit einer sehr konkreten Frage aus dem Alltag. In einem Kundenfall ging es darum, kleine Informationen über mehrere Abläufe hinweg verlässlich festzuhalten: Zuordnungen zwischen Systemen, einen letzten Synchronisationsstand oder eine Einstellung, die beim nächsten Durchlauf wieder gebraucht wird.
Die naheliegende Antwort wäre ein zusätzliches Tool gewesen – ein externer Speicher, eine eigene Datenbank oder ein weiterer Dienst, der eingerichtet, verbunden und betrieben werden muss. Genau das wollten wir vermeiden. Denn wenn ein Konnektor schon eine Plattform für seine Laufzeit, seine Bindings und seine Deployments hat, sollte ein kleiner persistenter Speicher nicht wie ein Fremdkörper danebenstehen.
Deshalb entsteht der Neodaptic Key-Value Store direkt als Teil der Plattform. In einem Binding soll die Nutzung so schlicht sein wie die übrigen Runtime-Funktionen: Ein paar Zeilen im Skript genügen, um über ctx.store.kv einen Wert abzulegen oder wieder abzurufen. Für typische Fälle wie Mappings, Sync-Marker oder leichte Einstellungen entsteht so kein zusätzlicher Integrationsaufwand.
await ctx.store.kv.set("ZuordnungVorgangsnummer", "AKT-112554", "ID-88789")Der Speicher bleibt damit Teil des Bindings – genau dort, wo auch die fachliche Logik liegt. Er fühlt sich nicht wie ein zusätzliches System an, sondern wie eine weitere Fähigkeit des Konnektors.
Im Hintergrund kümmert sich Neodaptic um die technische Grundlage. Der Store wird kontrolliert für den jeweiligen Konnektor bereitgestellt und in die Runtime eingebunden. Damit Teams keine eigene Infrastruktur, keine Zugangsdaten und keine zusätzliche Betriebsstrecke verwalten müssen, bleibt der Fokus dort, wo er hingehört: bei der Logik des eigenen Use Cases.
Der Key-Value Store wird schon bald für unsere Kunden verfügbar sein. Wir möchten Plattformfunktionen nicht nur hinzufügen, sondern sie so integrieren, dass sie sich selbstverständlich anfühlen – als wären sie von Anfang an Teil des Konnektors gewesen.