REDA Data Service : connecter vos formulaires

Un formulaire externe — formulaire de contact du site marketing, page de campagne ou microsite Webflow — peut alimenter REDA avec les coordonnées du prospect et les informations d’attribution. Le Data Service est le moteur de réception web inclus dans REDA : une intégration compatible transmet une requête, REDA vérifie les autorisations configurées, puis les correspondances de champs servent à créer ou à mettre à jour un enregistrement en arrière-plan. La connexion peut nécessiter un adaptateur côté serveur ; sa mise en place dépend de votre outil de formulaires. Ce guide s’adresse à l’administrateur ou au développeur web chargé de cette connexion. Il présente l’adresse de destination, l’authentification, le format des données, les champs préconfigurés pour les demandes web et le diagnostic des échecs. Comme il s’adresse aux intégrateurs, il conserve les adresses et paramètres techniques à utiliser.

Fonctionnement

Le Data Service reçoit la requête de votre formulaire, vérifie qu’elle est autorisée, puis la transmet au traitement qui construit l’enregistrement. L’acceptation et l’écriture sont deux étapes distinctes :

La réponse success signifie donc « requête acceptée », et non « enregistrement créé ». Vérifiez ensuite l’enregistrement attendu. Les erreurs interceptées pendant son écriture font l’objet d’une tentative de journalisation dans les journaux asynchrones ; consultez En cas d’échec.

Le délai dépend du traitement des événements et de la charge. Lors d’un pic de soumissions, par exemple après l’envoi d’une campagne, les enregistrements peuvent apparaître après les réponses d’acceptation. Cette réponse ne garantit ni un délai précis ni la réussite de l’écriture ; rapprochez les soumissions attendues des enregistrements et des erreurs disponibles.

Activation et contrôles d’accès

Avant qu’un formulaire puisse alimenter REDA, quatre contrôles doivent être satisfaits. Les requêtes GET et POST passent ces contrôles ; sur ce service, toutes deux servent à transmettre des données pour création ou modification, et non à lire des enregistrements :

La configuration du package examinée prévoit les demandes Platform, ou Lead dans Sales Cloud, avec GET, POST, création et modification activés et une clé configurée. La ligne des demandes de service, ou Case dans Sales Cloud, est présente avec ces quatre options désactivées. Vérifiez les valeurs effectivement installées avant tout raccordement. Le même mécanisme permet de configurer d’autres objets, comme expliqué dans Ajouter des objets et des sources au Data Service.

Adresse du service

L’adresse de destination désigne l’objet cible et la source de données : cette valeur regroupe les correspondances d’une famille de formulaires, indépendamment des autres sources. Le modèle d’adresse pour Platform est le suivant :

<Your Site URL>/services/apexrest/reda1/dataservice/<Record Type>/<Data Source>

Pour la réception web préconfigurée, l’objet Platform est reda1__Inquiry__c et la source Web. L’adresse se termine donc ainsi :

.../dataservice/reda1__Inquiry__c/Web

Le début de l’adresse est l’URL du site configuré par votre administrateur. Pour Sales Cloud, le chemin correspondant est /services/apexrest/reda/dataservice/Lead/Web. Une requête acceptée renvoie 200 avec une réponse contenant {"success": true}. Un contrôle de configuration ou d’opération peut produire une réponse 400 accompagnée d’un message ; un service désactivé renvoie également 400. Une clé incorrecte produit le code 401 indiqué ci-dessus.

Format de la requête

Utilisez une requête POST pour le formulaire. Son corps est une liste JSON de paires clé/valeur, à raison d’une entrée par champ transmis :

[
  {"key": "FirstName", "value": "Aisha"},
  {"key": "LastName",  "value": "Rahman"},
  {"key": "Email",     "value": "aisha@example.com"}
]

Si l’authentification est configurée, l’adaptateur côté serveur fournit la clé dans l’en-tête x-api-key. Une requête GET peut aussi transmettre les valeurs en paramètres d’URL lorsque cette méthode est autorisée. Elle déclenche le même mécanisme d’écriture : ce n’est pas une API de lecture. Privilégiez POST pour les formulaires.

La présence du paramètre recordId détermine si le contrôle d’autorisation exige la création ou la modification. Pour mettre à jour un enregistrement, ce paramètre doit en outre être associé au champ Id et contenir un identifiant valide et autorisé.

Si vous envoyez recordId alors que Modifier l’enregistrement est désactivé, ou demandez une création alors que Créer un enregistrement est désactivé, REDA répond "DML Operation not supported.". L’opération demandée n’est pas autorisée dans la ligne de configuration. La simple présence de recordId ne garantit pas qu’une mise à jour sera réalisée : vérifiez sa correspondance et sa valeur.

Correspondances web préconfigurées

Une correspondance relie une clé du formulaire à un champ REDA. La configuration Web examinée comprend 21 paramètres couvrant les coordonnées, la provenance et l’attribution marketing. Les clés reconnues alimentent les champs configurés si leurs valeurs sont valides. Deux champs ont une valeur par défaut : les valeurs par défaut sont appliquées d’abord, puis remplacées par les valeurs reçues pour les paramètres correspondants.

Il n’est pas nécessaire d’envoyer les 21 paramètres : transmettez ceux que le formulaire recueille, en satisfaisant les champs obligatoires et les règles de votre organisation. La source Web regroupe ces correspondances ; une autre famille de formulaires peut utiliser une autre source et ses propres clés pour le même objet.

En cas d’échec : journaux asynchrones

L’écriture intervient après la réponse d’acceptation. Vérifiez donc l’enregistrement attendu et, en cas d’absence, les journaux asynchrones. Lorsqu’une erreur d’écriture est interceptée — champ obligatoire manquant ou règle de validation, par exemple — le traitement annule l’écriture et tente de créer un journal d’erreur. Une absence de journal ne constitue pas une preuve de réussite.

Un journal d’échec créé par ce traitement indique l’objet et la source, le nombre d’échecs, la requête et les détails de l’exception. Utilisez ces éléments pour corriger le formulaire ou les données, puis soumettez à nouveau après avoir vérifié qu’aucun enregistrement n’a déjà été créé. Le traitement ne prévoit pas de nouvelle tentative automatique. Pour comprendre les journaux, l’indicateur d’attention et les alertes administrateur, consultez Comprendre les journaux asynchrones REDA.

Exemple : une page de campagne

Meridian Properties utilise une page de campagne de location estivale. Lorsqu’un prospect soumet le formulaire, l’adaptateur côté serveur envoie la requête suivante à .../dataservice/reda1__Inquiry__c/Web, avec la clé de Meridian dans l’en-tête x-api-key :

[
  {"key": "FirstName",    "value": "Aisha"},
  {"key": "LastName",     "value": "Rahman"},
  {"key": "Email",        "value": "aisha@example.com"},
  {"key": "utm_source",   "value": "google"},
  {"key": "utm_campaign", "value": "summer-lease"},
  {"key": "gclid",        "value": "..."}
]

REDA renvoie 200 {"success": true} pour l’acceptation. Si l’écriture aboutit, une demande Aisha Rahman apparaît ensuite, avec la source Web, la campagne et l’identifiant de clic Google. Vérifiez ces données dans l’enregistrement avant de considérer le test comme réussi.

Pour mettre à jour. Si Aisha transmet ensuite son téléphone, l’intégration peut ajouter {"key": "recordId", "value": "<her inquiry's id>"}. Après contrôle du droit à modifier cette demande, et avec la correspondance vers Id et l’option de modification activées, le traitement met à jour l’enregistrement existant si les données sont valides.

En cas d’échec. Si un champ obligatoire manque et que l’écriture est refusée, le traitement tente de créer un journal contenant la requête et l’erreur. Consultez ce journal pour corriger le formulaire ; si vous ne trouvez ni enregistrement ni journal, poursuivez le diagnostic avec l’administrateur.

Pour aller plus loin

1. Ajouter des objets et des sources au Data Service — connecter un autre objet ou séparer les familles de formulaires.
2. Demandes web et demandes de visite — comprendre l’autre parcours de réception depuis les annonces REDA.
3. Comprendre les journaux asynchrones REDA — lire les détails des erreurs de traitement.
4. Accéder aux données REDA avec les API Salesforce — découvrir les API de lecture et d’écriture authentifiées.
5. Rechercher et fusionner les demandes en double — traiter les doublons lorsqu’un prospect soumet plusieurs formulaires.

Questions fréquentes