Comment créer un connecteur

Vue d'ensemble

Les connecteurs permettent d'intégrer des systèmes et des bases de données externes. Pour plus d'informations, voir "Qu'est-ce qu'un connecteur?

Comment créer un nouveau connecteur

La création d'un nouveau connecteur ne nécessite pas de connaissances approfondies en matière d'API ou de bases de données, mais il est utile d'être familiarisé avec les types de connexion.

Pour créer un connecteur, accédez à la page Connecteurs sous Apps. Cliquez sur + Créer un connecteur dans le coin supérieur droit. Vous pouvez sélectionner un connecteur de bibliothèque existant ou cliquer sur Créer un connecteur personnalisé.

Configuration d'un nouveau connecteur

Informations de base

1. Ajoutez un nom et une description à votre connecteur. Ces informations peuvent être modifiées à tout moment.
2. Sélectionnez un type de connecteur. Il n'est pas possible de le modifier après la création du connecteur.
3. [Activer les sous-domaines personnalisés vous permet de configurer des sous-domaines uniques pour chaque fonction, ce qui facilite l'intégration avec des architectures de services plus complexes.

Par exemple, si l'adresse du serveur est tulip.co, la première fonction peut utiliser community.tulip.co et la deuxième fonction peut utiliser support.tulip.co.

Lorsque les sous-domaines personnalisés sont activés, un sous-domaine par défaut doit être fourni pour vérifier l'état du connecteur.

Exécuté sur : Hôte du connecteur

Sélectionnez l'hôte du connecteur qui exécutera vos demandes. L'hôte du connecteur cloud, fourni par Tulip, effectue les requêtes via Tulip Cloud. Tout hôte de connecteur sur site enregistré sur votre compte apparaîtra également. Plus d'informations sur les Connector Hosts sont disponibles ici.

:::(Warning) (Capacités des hôtes connecteurs) Certains hôtes connecteurs ne supportent pas certaines fonctionnalités. Ces hôtes seront désactivés ou cachés dans la liste déroulante des hôtes connecteurs :: :

Configuration du connecteur HTTP

Des informations sur la configuration des fonctions du connecteur HTTP sont disponibles ici : Comment créer et configurer une fonction de connecteur HTTP

Autoriser un sous-domaine personnalisé

Lorsque cette option est activée, des sous-domaines peuvent être ajoutés au niveau de la fonction. Lorsque cette option est activée, il faut ajouter un sous-domaine par défaut qui sera utilisé pour vérifier l'état en ligne du connecteur.

Par exemple, mon serveur est acme.co, et certaines fonctions interrogent sales.acme.co, d'autres s'adressent à shipping.acme.co, etc.

Adresse du serveur

Spécifier l'adresse réseau, c'est-à-dire un nom d'hôte ou une adresse IP, à laquelle Tulip se connecte.

TLS

Transport Layer Security (TLS) est un protocole cryptographique conçu pour fournir une communication sécurisée sur un réseau informatique. Il garantit la confidentialité et l'intégrité des données en chiffrant les données transmises entre les parties. TLS est le successeur de Secure Sockets Layer (SSL) et est largement utilisé pour sécuriser les connexions internet.

Port

Votre serveur écoute les requêtes sur un port réseau spécifique fourni par votre fournisseur de serveur. Le port 443 est le plus courant pour les services HTTPS, et le port 80 est le plus courant pour les services HTTP.

Authentification

:::(Warning) (Version de l'hôte du connecteur) Pour le flux OAuth Client Credential, Cloud Connector Host ou On Prem Connector Host de la version LTS13 ou plus récente doit être utilisé.
:: :

Type

• No Auth - Aucune authentification n'est nécessaire, ou l'authentification est contenue dans d'autres en-têtes de requête comme x-auth-token.
• Basic Auth - Authentification de base, qui met en œuvre le nom d'utilisateur et le mot de passe.
• OAuth 2.0 (Bearer token) - Les Bearer tokens sont le principal type de jeton d'accès utilisé. Il s'agit d'une chaîne de caractères opaque, qui n'est pas censée avoir une signification pour les clients qui l'utilisent.
• OAuth 2.0 (User Credentials) - Généralement utilisé pour les clients qui ont besoin d'accéder à un ensemble limité de ressources au nom d'un utilisateur, comme une application mobile qui a besoin d'accéder aux contacts ou aux événements du calendrier d'un utilisateur. L'utilisateur doit explicitement donner son autorisation.
• OAuth 2.0 (Client Credentials) - le client credentials est un type de permission utilisé par Tulip pour obtenir un jeton d'accès en s'authentifiant auprès du serveur d'autorisation à l'aide des informations d'identification du client (ID client et secret client), généralement pour accéder à des ressources en son nom propre plutôt qu'au nom d'un utilisateur.
• OAuth 2.0 (compte de service) - Utilisé pour les clients qui ont besoin d'accéder à un plus grand nombre de ressources ou de fonctions administratives. Ce rôle accorde un accès étendu au compte et aux ressources de l'utilisateur, comme la gestion des paramètres du compte, la création ou la suppression de ressources, ou l'exécution de tâches administratives.
• OAuth 1.0 - Version antérieure d'OAuth qui gère principalement les flux de travail sur le web.

Plus d'informations sur OAuth sont disponibles ici.

En-têtes (facultatif)

Les en-têtes assurent l'authentification de l'origine des données, l'intégrité des données et la protection contre la rediffusion. Ces en-têtes seront ajoutés à chaque fonction du connecteur.

Extension des autorités de certification

Des fichiers au format.pem peuvent être téléchargés pour étendre les autorités de certification TLS par défaut de Node.js. Ce champ met à jour le champ ca dans la bibliothèque TLS de Node.js.

"Il est possible de remplacer les certificats d'autorité de certification approuvés. La valeur par défaut est de faire confiance aux autorités de certification bien connues sélectionnées par Mozilla. Les autorités de certification de Mozilla sont complètement remplacées lorsque les autorités de certification sont explicitement spécifiées à l'aide de cette option. La valeur peut être une chaîne ou un tampon, ou un tableau de chaînes et/ou de tampons. Toute chaîne ou mémoire tampon peut contenir plusieurs AC PEM concaténées ensemble. Le certificat de l'homologue doit être chaînable à une autorité de certification approuvée par le serveur pour que la connexion soit authentifiée. Lors de l'utilisation de certificats qui ne sont pas chaînables à une autorité de certification bien connue, l'autorité de certification du certificat doit être explicitement spécifiée comme étant de confiance, faute de quoi la connexion ne sera pas authentifiée. Si l'homologue utilise un certificat qui ne correspond pas à l'une des autorités de certification par défaut ou qui ne peut être chaîné à l'une d'elles, utilisez l'option ca pour fournir un certificat d'autorité de certification auquel le certificat de l'homologue peut correspondre ou être chaîné. Pour les certificats auto-signés, le certificat est sa propre autorité de certification et doit être fourni. Pour les certificats encodés PEM, les types pris en charge sont "TRUSTED CERTIFICATE", "X509 CERTIFICATE" et "CERTIFICATE". Voir aussi tls.rootCertificates".

Un exemple d'autorité de certification valide devrait ressembler à ceci :

-----BEGIN CERTIFICATE----- MIIDXTCCAkWgAwIBAgIJALaEfh0WW6ZcMA0GCSqGSIb3DQEBCwUAMEUxCzAJBgNV BAYTAlVTMRYwFAYDVQQIDA1TYW4gRnJhbmNpc2NvMRIwEAYDVQQHDAlTYW4gSm9z ZTEPMA0GA1UECgwGQ29tcGFueTAeFw0xNzA1MjUyMDE2NDRaFw0xNzA2MjQyMDE2 NDRaMEUxCzAJBgNVBAYTAlVTMRYwFAYDVQQIDA1TYW4gRnJhbmNpc2NvMRIwEAYD VQQHDAlTYW4gSm9zZTEPMA0GA1UECgwGQ29tcGFueTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBAK9b+GVsTsmP7z9T2sh79uI/57pI1DBYNyOlwC0lfn8S ebVKRg0qAsaF3V4rQ/RPZFGkTb2G7IKnWQZ6VB8AFLF6A9xuGe7vSG9ZcJ1AKM2u OwYXzWQNWRFiW1XPOEIOXB+N7kMFTF6ZzE6RkV68hVqVn7Kx4s0RYAKM4ESJIMyF 64IHo5Rf6k3UtrOzy6M3LXM3axgUPHkHZh6/Pi3hecaF7w0qDhlS8UJLA4Gn1I6n rFt1URVd7aSIEiOQhs7wAGDzCjNYMEQK9ih0GLd9ybCm0flYo5fJqfOhWiCFm2z3 SuGH9MSnVdrzxY6x23J/gE3spPvBopF6bRjQl0qiw1ZAgMBAAGjUDBOMB0GA1Ud DgQWBBRZtdl2jSWpITThx8JZL4Jx0zCBdTAfBgNVHSMEGDAWgBRZtdl2jSWpITTh x8JZL4Jx0zCBdTAMBgNVHRMEBTADAQH/MA0GCSqGSIb3DQEBCwUAA4IBAQARzA8y dRMOfbU0QLOEp9V4B6nO8XBpe9uvtYwQjmb5ZX1bR2/P71bzeJwHK6v4RZl6V5fw GzFdsMFI8JAlLJChM1BpsU7a5R+U/X6XJpCzjErhZ68Z3G+TQ4Bk9LhRlQTH5ld9 lR8aWpVPvPIqMtkJhbvWn9P4ysc8q3WYfILy9m9J8Hz3i3AaAE

Configuration du connecteur SQL

| Champ | Description | --- | | | Adresse du serveur | L'adresse IP ou le nom d'hôte du serveur de base de données. Il s'agit de l'endroit où la base de données est hébergée et accessible. | Le numéro de port sur lequel le serveur de base de données est à l'écoute. Les numéros de port courants sont 3306 pour MySQL, 5432 pour PostgreSQL et 1433 pour SQL Server. | SSL | Spécifie si SSL (Secure Sockets Layer) est utilisé pour crypter la connexion au serveur de base de données. Il comprend généralement des paramètres pour le mode SSL et les certificats. | Le nom de la base de données spécifique sur le serveur à laquelle vous souhaitez vous connecter. C'est là que résident vos données. | Nom d'utilisateur - Le nom d'utilisateur requis pour s'authentifier et accéder à la base de données. Cet utilisateur doit disposer des autorisations nécessaires pour effectuer des opérations sur la base de données. | Le mot de passe associé au nom d'utilisateur, utilisé pour authentifier l'utilisateur auprès de la base de données. Cela permet d'assurer un contrôle d'accès sécurisé. |

Configuration du connecteur MQTT

Des informations sur la création de connecteurs MQTT sont disponibles ici : Comment créer votre premier connecteur MQTT