À propos des functions

Une function est un court morceau de TypeScript qui s'exécute sur l'infrastructure d'OmniLab. Vous l'écrivez dans OmniLab Studio, OmniLab la compile, et la plateforme l'exécute ensuite pour vous — soit lorsqu'un événement se produit dans une campagne, soit à un point de décision précis, par exemple l'inscription d'un contact.

Vous n'avez besoin d'aucun serveur, d'aucun endpoint et d'aucun déploiement de votre côté.

Les functions se configurent dans les Paramètres de l'Entreprise, ce qui exige un rôle Admin avec l'organisation globale sélectionnée — vérifiez que vous disposez de cet accès avant de planifier des travaux, car l'onglet reste invisible sans lui.

Comment cela fonctionne

Vous stockez un fichier TypeScript unique comportant un gestionnaire exporté. À la compilation, OmniLab transforme ce fichier en module WebAssembly et conserve la version compilée. Chaque invocation la charge ensuite dans un environnement isolé neuf et appelle votre export.

import type { PlatformEventHandler } from "./omnilab";

export const onPlatformEvent: PlatformEventHandler = (event) => {
  console.log("Il s'est passé quelque chose : " + event.type);
};

Votre gestionnaire atteint l'extérieur par les appels fournis par OmniLab : lire une valeur de configuration, lire un secret, émettre une requête HTTP vers un hôte que vous avez autorisé, lire un contact et écrire ses champs personnalisés. Cet ensemble est volontairement restreint — c'est ce qui permet à OmniLab d'exécuter votre code sur sa propre infrastructure en toute sécurité, et cela suffit à la plupart des travaux d'intégration.

Chaque invocation est indépendante. Rien de ce que vous définissez lors d'un appel ne se transmet au suivant : ce que vous devez conserver va donc dans les champs personnalisés d'un contact, ou vers votre propre système via HTTP.

Function ou webhook ?

Les deux permettent de réagir à ce qui se passe dans OmniLab. La différence tient à l'endroit où votre code s'exécute et à sa capacité à modifier l'issue.

Un webhook informe vos systèmes qu'un événement s'est produit, après qu'OmniLab a déjà tranché. Une function s'exécute dans OmniLab et — pour l'un des deux types — au cœur de la décision elle-même : elle peut donc refuser une inscription, normaliser un e-mail avant son enregistrement, ou envoyer un message de vérification via votre propre fournisseur.

Choisir un type

Chaque function relève de l'un de deux types, et ce type détermine le moment où elle s'exécute et ce qu'elle peut influencer. Il est fixé à la création, faites donc ce choix avant de commencer à écrire.

Commencez par une function d'événement lorsque les deux conviendraient. Elle ne peut rien casser dans le parcours d'un client : le coût d'une erreur est un effet de bord manquant, pas une inscription en échec.

Du brouillon à l'exécution

L'enregistrement et la compilation sont volontairement dissociés. Enregistrer stocke votre code et en vérifie les types ; cela ne change jamais ce qui tourne. Seule une compilation produit une nouvelle version compilée.

Le statut affiché dans la liste est l'un de ceux-ci : Draft, Building, Ready, Build failed ou Deleted. Seule une function Ready s'exécute.

Les deux issues possibles depuis Building méritent attention. Une function qui n'a jamais été compilée avec succès passe en Build failed. Une function déjà en ligne dont la recompilation échoue revient en Ready et continue de servir la version précédente : une recompilation défaillante ne met donc jamais hors ligne une function qui fonctionnait.

Le cadre dans lequel votre code travaille

Deux règles prennent souvent les équipes au dépourvu. Les secrets ne figurent jamais dans votre source : vous les stockez dans un bundle, associez le bundle à la function et lisez les valeurs par leur nom à l'exécution. Et les clés de champs personnalisés commençant par system. ou feature. sont réservées : les écritures y sont rejetées.

Les valeurs complètes, les codes d'erreur et les contrats figurent dans la référence du SDK.

Pour aller plus loin