Skip to main content
Les fonctions logiques s’exécutent dans des processus Node.js isolés et de courte durée — une fois une exécution terminée, rien de ce qui était conservé en mémoire ne survit. Lorsque vous avez besoin de vous souvenir de quelque chose entre les exécutions (mettre en cache une réponse d’API coûteuse, stocker un curseur pour des synchronisations incrémentales, appliquer un anti-rebond, ou transférer l’état d’une fonction à une autre), conservez-le dans le magasin clé-valeur intégré. Chaque application dispose de son propre espace de noms isolé : les entrées sont associées à l’application authentifiée, de sorte que vos clés ne peuvent jamais entrer en collision avec celles d’une autre application, ni être lues par celle-ci.

Obtenir, définir, supprimer

Importez kv depuis twenty-sdk/logic-function. Les valeurs peuvent être n’importe quelle charge utile sérialisable en JSON.
src/logic-functions/sync-linear-issues.ts

Périmètres

Chaque entrée possède une portée, passée comme option à chaque appel. La valeur par défaut est WORKSPACE.
  • WORKSPACE (par défaut) — l’entrée est réservée à l’installation actuelle de votre application dans l’espace de travail. Chaque espace de travail qui installe l’application obtient son propre ensemble indépendant de clés. C’est ce qu’il vous faut pour les caches, les curseurs et l’état par espace de travail.
  • SERVER — l’entrée est partagée entre toutes les installations de votre application sur le serveur. Les entrées serveur se comportent comme des revendications : la valeur stockée est toujours le workspaceId qui a revendiqué la clé (omettre value lors de set pour revendiquer la clé pour l’espace de travail actuel), et seul cet espace de travail peut la remplacer ou la supprimer. N’importe quelle installation peut lire l’entrée.
Les revendications serveur existent pour le routage inter-espaces de travail. Un résolveur de route serveur s’exécute dans l’espace de travail propriétaire de l’enregistrement de l’application, mais un webhook entrant ne transporte généralement qu’un identifiant de compte externe — pas un workspaceId Twenty. Faites en sorte que chaque espace de travail revendique son identifiant externe au moment de la connexion, puis résolvez-le dans la route :
Comme une clé serveur ne peut être revendiquée que pour l’espace de travail de l’appelant et jamais écrasée par un autre, un espace de travail ne peut pas détourner un mappage appartenant à quelqu’un d’autre. kv.set lève une exception lorsque la clé est déjà revendiquée par un autre espace de travail.

Utilisez-le : mettez en cache un appel coûteux

Un cas d’utilisation typique consiste à mettre en cache une réponse tierce lente ou soumise à des limites de débit afin que les exécutions répétées la réutilisent au lieu d’en payer le coût à chaque fois.
src/logic-functions/getExchangeRate.logic-function.ts

Modèles et conseils

  • Espaces de noms. Préfixez les clés pour séparer les différentes préoccupations — sync-cursor:linear, cache:exchange-rate:USD:EUR, lock:nightly-report.
  • Expiration (TTL). Le store n’a pas d’expiration intégrée. Stockez un horodatage dans la valeur (comme dans l’exemple de cache) et vérifiez-le à la lecture, ou effacez les clés obsolètes à partir d’une fonction déclenchée par cron.
  • Que stocker. Toute valeur sérialisable en JSON — nombres, chaînes de caractères, tableaux, objets. Gardez les entrées petites ; ceci sert à la coordination et à la mise en cache, pas aux blobs volumineux ni aux fichiers. Pour les fichiers, utilisez un champ FILES et uploadFile.
  • Visibilité. Les entrées résident dans la base de données de l’instance, et non comme enregistrements d’espace de travail — elles n’apparaissent jamais dans l’interface utilisateur de l’espace de travail, ne font pas partie du modèle de données de votre application et ne nécessitent aucun droit ni aucune permission d’objet.

Alternative : un objet de stockage interrogeable

Le magasin intégré est délibérément opaque : les entrées ne sont pas des enregistrements, vous ne pouvez donc pas les parcourir dans l’interface utilisateur, les relier à d’autres objets, ni les filtrer avec des requêtes sur les enregistrements. Lorsque vous avez besoin de tout cela — par exemple un journal de synchronisation visible, ou un état par enregistrement — définissez plutôt un petit objet technique avec un champ key unique et un champ RAW_JSON value, puis interrogez-le via le client d’API typé. Consultez Objets pour la référence defineObject et Données → Index uniques pour faire appliquer l’unicité des clés.
  • Délimiter la portée à un enregistrement. Ajoutez une relation de l’objet de stockage vers l’objet cible plutôt que de coder l’identifiant dans la clé.
  • Visibilité et autorisations. Les lignes résident dans la base de données de l’espace de travail comme n’importe quel autre enregistrement, elles sont donc interrogeables via l’API et respectent le rôle de votre application. Pour garder le store hors de l’interface principale, ne l’ajoutez pas à votre menu de navigation.
Contrairement au magasin intégré, un objet personnalisé est toujours limité à un seul espace de travail — il ne peut pas partager des entrées entre installations comme le font les clés SERVER.