PostgreSQL
Connic hört auf einen Postgres NOTIFY Channel und löst den Agenten aus, sobald eine Zeile eintrifft. Zusätzliche Polling- oder CDC-Infrastruktur ist nicht erforderlich: Die Datenbank wird zur Event-Quelle.
Überblick
PostgreSQL bringt einen Pub/Sub-Mechanismus mit: LISTEN/NOTIFY. Eine Trigger Function oder der Anwendungscode ruft pg_notify() auf einem Channel auf, und jede dort lauschende Verbindung erhält die Payload sofort. Die PostgreSQL-Verbindung hält eine persistente Verbindung zur Datenbank, abonniert den konfigurierten Channel und verwandelt jede Notification in einen Agent Run mit deren Payload.
Damit entfällt die übliche Infrastruktur für Reaktionen auf Datenänderungen: keine Polling-Schleife, die die Tabelle belastet, keine Change-Data-Capture-Pipeline und kein Worker-Dienst, der bereitgestellt und überwacht werden muss. Die Datenbank weiß bereits, wann sich eine Zeile ändert; die Verbindung leitet dieses Ereignis direkt an einen Agenten weiter.
So funktioniert es
Datenbank erreichbar machen
Der PostgreSQL Server muss aus dem Internet erreichbar sein. Alternativ verbindet die Connic Bridge Datenbanken in privaten Netzwerken.
NOTIFY Trigger hinzufügen
Erstelle für die zu überwachende Tabelle eine Trigger-Funktion mit pg_notify() oder sende Benachrichtigungen direkt aus dem Anwendungscode. Üblich ist eine JSON Payload mit den Zeilendaten.
Verbindung erstellen
Füge im Verbindungsdiagramm des Agenten eine PostgreSQL-Verbindung hinzu und trage Host, Port, Database, Username, Password, Channel Name und SSL-Einstellungen ein. Connic hört sofort auf dem Channel.
Muster für den Produktivbetrieb
Muster für den Produktivbetrieb, bei denen Connic Queues, Worker und Scheduler betreibt.
Neue Kundenzeile eingefügt
NOTIFY customers_insertDer Agent sucht das Unternehmen auf Clearbit, ergänzt Unternehmensmerkmale und schreibt das Ergebnis in die Kundenzeile zurück, bevor die Willkommens-E-Mail versendet wird.
Neue Kundenzeile eingefügt
NOTIFY customers_insertDer Agent sucht das Unternehmen auf Clearbit, ergänzt Unternehmensmerkmale und schreibt das Ergebnis in die Kundenzeile zurück, bevor die Willkommens-E-Mail versendet wird.
Bestellung aufgegeben
NOTIFY orders_insertDer Agent bewertet das Betrugsrisiko anhand des bisherigen Verhaltens, entwirft eine passende Follow-up-E-Mail und aktualisiert Bestandsprognosen anhand des Ereignisses zur neuen Datenbankzeile.
Bestellung aufgegeben
NOTIFY orders_insertDer Agent bewertet das Betrugsrisiko anhand des bisherigen Verhaltens, entwirft eine passende Follow-up-E-Mail und aktualisiert Bestandsprognosen anhand des Ereignisses zur neuen Datenbankzeile.
Nutzerinhalt gespeichert
NOTIFY content_insertDer Agent liest die neue Zeile, prüft auf Richtlinienverstöße und setzt eine Moderationsspalte, bevor andere Nutzer den Post sehen.
Nutzerinhalt gespeichert
NOTIFY content_insertDer Agent liest die neue Zeile, prüft auf Richtlinienverstöße und setzt eine Moderationsspalte, bevor andere Nutzer den Post sehen.
Datensatz eingefügt
NOTIFY records_insertDer Agent prüft die Zeile anhand definierter Geschäftsregeln und externer Quellen und schreibt Korrekturen oder Markierungen noch beim Einfügen. Der Batch Job am Dienstag erhält bereits bereinigte Daten.
Datensatz eingefügt
NOTIFY records_insertDer Agent prüft die Zeile anhand definierter Geschäftsregeln und externer Quellen und schreibt Korrekturen oder Markierungen noch beim Einfügen. Der Batch Job am Dienstag erhält bereits bereinigte Daten.
Verbindung und Zugangsdaten
Die Verbindung authentifiziert sich mit einem normalen Datenbanknutzer und Passwort. Dieser Nutzer benötigt nur die Berechtigung CONNECT für die Datenbank. Für NOTIFY Events sind weder Tabellenzugriff noch besondere Grants erforderlich, sodass ein dedizierter Nutzer mit geringen Rechten ausreicht. Der SSL-Modus ist konfigurierbar: disable, prefer oder require. Jede Verbindung hält pro Channel eine persistente Datenbankverbindung, was bei strengen Connection Limits relevant ist.
Jede Notification wird zu einem normalen Agent Run und erscheint in der Run History mit vollständigen Traces, Token- und Kosten-Tracking sowie denselben Guardrails und Approval-Regeln wie jeder andere Trigger.
Payload-Struktur und Limits
Der Agent erhält die Notification Payload und einen _postgres Metadatenblock mit Channel Name, Backend Process ID und Timestamp. Bei aktiviertem Parse JSON Payload (Standard) kommt eine JSON Notification als strukturiertes Objekt statt als String an. PostgreSQL begrenzt NOTIFY Payloads auf 8000 Bytes. Zuverlässiger ist es deshalb, nur IDs und wichtige Felder zu senden, über die der Agent den vollständigen Datensatz lädt. Separate Channels pro Event-Typ wie orders_created und users_updated halten das Routing übersichtlich. PostgreSQL-Dokumentation: Trigger und Payload-Format.
Informationen
- Publisher
- Von Connic
- Verbindungen
- Verbindungen
- Modi
- Inbound
- Dokumentation
- PostgreSQL Docs
Häufig gestellte Fragen
pg_notify() mit einer JSON Payload aufruft. Eine Connic PostgreSQL-Verbindung abonniert diesen Channel. Jeder Insert löst eine Notification aus, aus der die Verbindung einen Agent Run mit der Payload als Input erstellt. Updates und Deletes funktionieren ebenso mit einem AFTER UPDATE oder AFTER DELETE Trigger. Weitere Trigger-to-Agent Patterns zeigt der Leitfaden zu Verbindungsmustern.Beschreibe die Event-Quelle, die Struktur der Payload, das Ziel für die Ergebnisse und die Anforderungen an private Netzwerke oder Freigaben. Wir helfen, PostgreSQL mit dem passenden Verbindungsmodus, Deployment und Monitoring in Connic einzurichten.
Sprich mit Sales