AWS SQS

Von Connic

Connic pollt die konfigurierte SQS Queue, führt die verknüpften Agenten für jede Nachricht aus und löscht sie erst, wenn alle Runs abgeschlossen sind. Fehler werden nach dem Visibility Timeout gemäß der DLQ Policy erneut zugestellt; Connic betreibt die Worker.

InboundOutbound

Leg los Dokumentation

Überblick

Die Verbindung benötigt eine Queue URL, eine Region und eingeschränkte IAM-Zugangsdaten. Connic übernimmt damit das Long Polling. Jeder Message Body wird als JSON geparst und mit Queue-Metadaten unter _sqs an die verknüpften Agenten gesendet: Message ID, Receipt Handle, Queue URL, Receive Count und Sent Timestamp. Die Nachricht wird erst gelöscht, wenn die Runs aller verknüpften Agenten abgeschlossen sind. Schlägt ein Run fehl, bleibt sie in der Queue und wird nach dem Visibility Timeout erneut sichtbar.

Connic übernimmt den Betrieb der gesamten Worker-Flotte. Polling-Intervall, Batch-Größe und Visibility Timeout sind Verbindungseinstellungen statt Code. Das Retry-Verhalten folgt dem bekannten SQS-Verhalten: fehlgeschlagene Nachrichten werden erneut verarbeitet, wiederholte Fehler landen in der in AWS konfigurierten Dead-Letter Queue.

So funktioniert es

1

Queue und IAM User erstellen

Verwende eine Standard- oder FIFO-Queue und gewähre dem IAM-Nutzer darauf sqs:ReceiveMessage, sqs:DeleteMessage, sqs:ChangeMessageVisibility und sqs:GetQueueAttributes. Ausgehende Verbindungen benötigen stattdessen sqs:SendMessage und sqs:GetQueueAttributes für die Ziel-Queue.

2

Verbindung erstellen

Füge im Verbindungsdiagramm des Agenten eine AWS-SQS-Verbindung im Inbound-Modus hinzu und trage Queue URL, Region und AWS-Zugangsdaten ein. Konfiguriere Max Messages (1 bis 10 pro Poll), Wait Time (Long Polling bis zu 20 Sekunden) und Visibility Timeout (standardmäßig 300 Sekunden).

3

Agenten verknüpfen und optional Ergebnisse veröffentlichen

Connic beginnt mit dem Polling und sendet jede Nachricht an alle verknüpften Agenten. Eine ausgehende Verbindung für eine andere Queue ermöglicht die nachgelagerte Verarbeitung abgeschlossener Run-Ergebnisse.

Muster für den Produktivbetrieb

Muster für den Produktivbetrieb, bei denen Connic Queues, Worker und Scheduler betreibt.

Trigger

Bestellung landet in der Queue

sqs://orders-queue

Agent-Aktion

Der Agent lädt die Kundenhistorie, bestätigt den Bestand, wählt einen Versanddienstleister und schreibt einen Fulfillment Job in die nächste Queue, ohne das 200-ms-Budget der Checkout API zu überschreiten.

Trigger

Bestellung landet in der Queue

sqs://orders-queue

Agent-Aktion

Der Agent lädt die Kundenhistorie, bestätigt den Bestand, wählt einen Versanddienstleister und schreibt einen Fulfillment Job in die nächste Queue, ohne das 200-ms-Budget der Checkout API zu überschreiten.

Lies die Dokumentation zu AWS SQS

Message-Lifecycle und Retries

Nachrichten werden per Long Polling (standardmäßig 20 Sekunden) abgerufen, um leere Antworten und API Calls zu reduzieren. Eine Nachricht wird erst aus der Queue gelöscht, wenn die Runs aller verknüpften Agenten abgeschlossen sind. Bei einem fehlgeschlagenen Run bleibt sie bestehen, wird nach dem Visibility Timeout erneut sichtbar und wiederholt. Während Runs aktiv sind, verlängert Connic die Visibility automatisch, damit lange Runs nicht zu einer verfrühten erneuten Zustellung führen. Für wiederholt fehlschlagende Nachrichten wird in AWS eine Dead-Letter Queue zur Prüfung und erneuten Verarbeitung konfiguriert.

Jede Nachricht wird zu einem normalen Agent Run mit vollständigen Traces, Token- und Kosten-Tracking sowie denselben Guardrails und Approval-Regeln wie jeder andere Trigger. Wenn eine Nachricht immer wieder zurückkehrt, zeigt die Run History genau warum.

Ergebnis-Payloads und FIFO Queues

Ausgehende Verbindungen veröffentlichen für jeden abgeschlossenen Run ein JSON-Ergebnis: run_id, agent_name, status, output, error, Timestamps und token_usage. Bei FIFO Queues hält eine Message Group ID die Reihenfolge innerhalb einer Gruppe ein; die Deduplication ID wird auf die Run ID gesetzt, sodass ein Ergebnis nie doppelt in die Queue gelangt. SQS-Dokumentation: Payloads und IAM-Richtlinien.

Informationen

Publisher: Von Connic
Verbindungen: Verbindungen
Modi: Inbound, Outbound
Dokumentation: AWS SQS Docs

Häufig gestellte Fragen

Dazu wird eine AWS-SQS-Verbindung im Inbound-Modus mit Queue URL, Region und IAM-Zugangsdaten erstellt und mit einem Agenten verknüpft. Connic pollt die Queue per Long Polling, führt den Agenten für jede Nachricht aus und löscht sie nach erfolgreicher Verarbeitung. Ein eigener Consumer Service oder eine eigene Worker-Flotte ist nicht erforderlich. Einen größeren Überblick bieten die gängigen Verbindungsmuster.

Vorübergehend fehlgeschlagene Modellanfragen und konfigurierte Operationen werden ab dem fehlgeschlagenen Aufruf wiederholt, ohne bereits abgeschlossene Agent-Arbeit erneut auszuführen. Schlägt der Run trotzdem fehl, wird die Nachricht nicht gelöscht: Nach dem Visibility Timeout kehrt sie in die Queue zurück; wiederholt fehlschlagende Nachrichten landen in der AWS Dead-Letter Queue.

Ja, sowohl Standard- als auch FIFO Queues funktionieren. Für ausgehende FIFO Queues wird eine Message Group ID konfiguriert, damit Ergebnisse derselben Gruppe in Reihenfolge zugestellt werden; die Message Deduplication ID entspricht der Run ID.

Plane einen Agenten-Workflow mit AWS SQS und Connic

Beschreibe die Event-Quelle, die Struktur der Payload, das Ziel für die Ergebnisse und die Anforderungen an private Netzwerke oder Freigaben. Wir helfen, AWS SQS mit dem passenden Verbindungsmodus, Deployment und Monitoring in Connic einzurichten.

Sprich mit Sales

Weitere Verbindungen

Entdecke den Marketplace

Slack

Agenten auslösen und Ergebnisse in Slack senden

E-Mail (SMTP/IMAP)

Postfächer lesen und Antworten senden

WebSocket

Tokens über einen Live Socket streamen

PostgreSQL

Per LISTEN/NOTIFY auf neue Zeilen reagieren

Cron-Scheduler

Agenten nach einem Cron-Ausdruck ausführen

MCP Server

Agenten als MCP Tools bereitstellen