ConnXL Docs

Construire

Connexions

Une connexion dirige l'agent vers l'une de vos sources de données. ConnXL fournit des connecteurs pour vingt-neuf types de sources répartis en huit catégories — bien plus que les bases de données et REST — et l'agent résout chaque identifiant au moment de l'exécution, à l'intérieur de votre réseau.

6 min de lecture

Le catalogue de connecteurs

Créez des connexions depuis la page Connexions du tableau de bord, limitées à votre environnement.

Bases de données relationnelles

Requêtes SQL, paramétrées.

  • Postgres
  • MySQL
  • MariaDB
  • SQL Server
  • Oracle
  • Azure Synapse
  • Amazon Redshift
  • TimescaleDB
  • Supabase
  • AWS Athena
  • Google BigQuery

Document et NoSQL

Requêtes et recherches sur documents.

  • MongoDB
  • DynamoDB
  • Azure Cosmos DB

HTTP et API

Requête/réponse et flux en direct.

  • REST
  • GraphQL
  • OData
  • Microsoft Graph
  • Server-Sent Events
  • WebSocket

Recherche et métriques

Recherche plein texte et séries temporelles.

  • Elasticsearch
  • OpenSearch
  • Prometheus

Messagerie

Consomme une fenêtre de messages récents.

  • Kafka
  • NATS
  • MQTT

Fonctions cloud

Calcul serverless déclenché par HTTP.

  • AWS Lambda
  • Azure Functions
  • Google Cloud Functions

Fichiers distants

Analysés en CSV, JSON ou JSONL.

  • HTTP(S) URL
  • S3 (and compatible)
  • SFTP
  • FTP
  • Azure Blob
  • Google Cloud Storage

Cache / clé-valeur

Lectures rapides depuis un cache partagé.

  • Valkey

Authentification avec les références secret://

Les identifiants ne vivent jamais en clair dans le tableau de bord. Au lieu d'un mot de passe, vous stockez une référence secret://, et l'agent résout la valeur réelle au moment de l'exécution en utilisant sa propre identité ambiante — jamais une clé par connexion figée dans la configuration. Une référence peut être un champ entier ou incorporée au milieu d'une chaîne :

connection secrettext
secret://env/DB_PASSWORD
secret://aws-sm/prod/orders-db?key=password
secret://azure-kv/my-vault/orders-db
secret://gcp-sm/my-project/orders-db
  • secret://env/NAME — une variable d'environnement sur l'hôte de l'agent (via sa chaîne keyring → env).
  • secret://aws-sm/… et secret://aws-ps/… — AWS Secrets Manager et SSM Parameter Store.
  • secret://azure-kv/… — Azure Key Vault.
  • secret://gcp-sm/… — GCP Secret Manager.

Les valeurs résolues ne sont jamais persistées ni journalisées

Le backend ne stocke que la référence. L'agent met brièvement en cache les valeurs résolues en mémoire et les garde hors des journaux — une erreur nomme la référence, jamais le secret.

Exemples concrets

Une API REST. Créez une connexion de type HTTP API, définissez l'URL de base (par ex. https://api.internal.example.com/v1), et choisissez l'authentification qu'utilise votre API — None pour un endpoint ouvert, ou un bearer token / une API key stockés comme une référence secret://. Laissez Allow private networks désactivé pour un endpoint public ; activez-le pour atteindre une API sur votre réseau interne. Les fonctions construites par-dessus utilisent ensuite des chemins relatifs comme /products ou /products/{'{{'}id{'}}'}.

Une base de données sur l'hôte de l'agent. Créez une connexion PostgreSQL pointant vers l'endroit où l'agent atteint la base de données — pour une base de données qui s'exécute sur le même hôte que l'agent, c'est l'hôte 127.0.0.1, le port 5432, plus le nom de la base, le nom d'utilisateur et le mot de passe. Ne désactivez Require SSL que si la base n'a pas de TLS, et activez Allow private networks afin que l'agent puisse composer une adresse privée/de bouclage. Le mot de passe est stocké chiffré (ou comme une référence secret://) et n'est jamais résolu que sur l'agent au moment de l'appel.

Parce que c'est l'agent — et non le backend — qui compose la connexion, l'hôte que vous saisissez doit être résoluble depuis le réseau de l'agent, pas depuis ConnXL.

Connecter Supabase

Supabase héberge du Postgres standard, donc le connecteur Supabase parle le protocole Postgres directement avec la base de données de votre projet. Deux choses diffèrent d'un Postgres auto-hébergé :

  • Hôte et utilisateur. Pour une connexion directe, utilisez db.<project-ref>.supabase.co, port 5432, utilisateur postgres. En passant par le pooler de connexions de Supabase, l'utilisateur devient postgres.<project-ref> et le port 6543 — le pooler est le bon choix quand de nombreuses répliques de l'agent partagent un même projet.
  • Mode SSL. Supabase exige TLS mais sa CA n'est pas dans les magasins de confiance standard, donc le connecteur utilise require par défaut (chiffré, certificat non vérifié). Si vous installez le certificat CA de Supabase sur l'hôte de l'agent, vous pouvez passer à verify-full.

Le mot de passe de la base de données se trouve dans votre tableau de bord Supabase sous Project Settings → Database ; stockez-le comme une référence secret:// comme tout autre identifiant.

Pour atteindre le même projet via l’API REST de Supabase, avec la Row-Level Security appliquée par utilisateur Excel connecté, voyez Sécurité au niveau des lignes (échange de jeton).

Tester une connexion

Utilisez Tester la connexion dans le tableau de bord pour vérifier qu'une source est accessible. La sonde s'exécute sur l'agent, depuis l'intérieur de votre réseau — une requête HTTP, un SELECT 1 SQL ou un balayage de cache. Le backend n'appelle jamais lui-même vos sources de données, cela fonctionne donc pour des sources qui ne sont pas accessibles depuis l'internet public. Les familles de sources sans sonde en direct signalent « enregistrée non testée » plutôt que d'échouer.

Vous pouvez gérer les connexions depuis la page Connexions de votre complément une fois un complément sélectionné.

Sur cette page