Ajouter des objets et des sources au Data Service
Le Data Service est préconfiguré pour les demandes web, mais son moteur peut aussi alimenter d’autres objets ou séparer plusieurs familles de formulaires par source. La réception repose sur une ligne de configuration par objet et des correspondances de champs ; le raccordement du formulaire, les conversions de valeurs ou la résolution de contacts peuvent nécessiter une intégration complémentaire. Ce guide explique comment préparer un objet, définir ses correspondances et valeurs par défaut, choisir une source et tester la connexion avant utilisation. Il suppose que vous avez lu Connecter vos formulaires, qui présente l’adresse du service, le format des requêtes et l’authentification.
Droits nécessaires. La modification requiert les autorisations Salesforce de gestion des métadonnées concernées et dépend de la possibilité de modifier chaque enregistrement du package. Vérifiez les droits effectifs de l’administrateur ; l’accès à une application REDA ne suffit pas à établir ces droits.
Les trois éléments de configuration
Le Data Service utilise les trois types d’enregistrements suivants. Vérifiez d’abord l’activation générale, puis préparez la configuration de l’objet et ses correspondances :
| Élément | Organisation | Type de métadonnées personnalisées | Fonction |
|---|---|---|---|
| Interrupteur général | Un paramètre d’activation pour l’organisation | Data Service Config | Active le service avec IS_ENABLED = 1. Vérifiez sa valeur dans votre environnement avant de tester. |
| Configuration de l’objet | Une ligne à maintenir par objet cible | Data Service Setup | Définit l’objet et les méthodes Requête GET et Requête POST autorisées, les options Créer un enregistrement et Modifier l’enregistrement, ainsi que la Clé d’authentification. Sur ce service, GET et POST transmettent tous deux des données pour écriture ; GET n’est pas une opération de lecture. |
| Correspondances de champs | Une ligne par champ et par source | Data Service Mapping | Associe chaque paramètre reçu à un champ de l’objet, avec une éventuelle valeur par défaut. |
Le traitement applique d’abord les valeurs par défaut, puis les valeurs reçues pour les paramètres configurés, et tente l’écriture. Sans correspondance pour l’objet et la source demandés, le traitement en arrière-plan échoue. Une erreur interceptée entraîne l’annulation de l’écriture et une tentative de journalisation dans les journaux asynchrones. La réponse initiale d’acceptation ne confirme pas la création de l’enregistrement ni celle d’un journal.
Étape 1 — Préparer la configuration de l’objet
La ligne Data Service Setup autorise l’accès au service pour un objet. Créez une ligne pour un nouvel objet ou préparez la ligne existante si elle est désactivée, comme celle des demandes de service dans la configuration du package examinée. Utilisez le nom d’API de l’objet, et non un type d’enregistrement Salesforce (RecordType).
x-api-key . Gardez-la côté serveur et activez uniquement les opérations nécessaires. Étape 2 — Nommer la source de données
Une source de données regroupe les correspondances d’une famille de formulaires. C’est le dernier segment de l’URL. Le même objet peut ainsi accepter plusieurs jeux de clés et valeurs par défaut. La réception web préconfigurée utilise Web ; vous pouvez également employer Web pour votre première famille, puis une autre valeur pour une campagne ayant des besoins différents.
Choisissez le nom de la source avant de créer les correspondances et utilisez-le de façon cohérente dans leurs lignes et dans l’URL. Les formulaires qui partagent clés et valeurs par défaut peuvent utiliser la même source. Ceux qui nécessitent une configuration différente doivent disposer de leur propre groupe.
Étape 3 — Définir les correspondances
Créez une ligne Data Service Mapping pour chaque champ à alimenter, avec les informations suivantes. Les libellés Platform sont indiqués ; les différences Sales Cloud sont précisées :
| Champ de configuration | Valeur à renseigner |
|---|---|
| Source de données | Le nom choisi à l’étape 2, repris dans le dernier segment de l’URL. |
| Nom d’API de l’objet | Le même objet que dans Data Service Setup. Dans Sales Cloud, le libellé est Nom de l’API de l’objet. |
| Paramètre du champ | La clé envoyée par le formulaire, par exemple subject. Dans Sales Cloud : Paramètre de champ d’objet. |
| Nom d’API du champ | Le champ modifiable de l’objet à alimenter, avec le préfixe approprié. Dans Sales Cloud : Nom de l’API du champ d’objet. N’utilisez pas un champ calculé. |
| Valeur par défaut du champ (facultative) | Valeur appliquée d’abord, puis remplacée si la requête fournit le paramètre correspondant. Choisissez une valeur compatible avec le champ. |
Deux usages sont utiles. Les valeurs par défaut de provenance peuvent indiquer l’origine d’une création : la réception de demandes Web utilise par exemple Web. Cette valeur n’est toutefois pas immuable, car un paramètre reçu peut la remplacer. Ajoutez une correspondance recordId uniquement pour des mises à jour autorisées : associez recordId au champ Id et activez Modifier l’enregistrement. L’adaptateur doit contrôler l’identifiant et le droit de modification. La présence de recordId déclenche le contrôle de modification même si sa correspondance est absente ; elle ne garantit pas une mise à jour.
Étape 4 — Tester la connexion
Dans l’environnement de test, vérifiez le parcours avant de raccorder le formulaire utilisé par vos visiteurs :
.../dataservice/<Object API Name>/<Your Source> avec l’en-tête x-api-key contenant la nouvelle clé, depuis l’adaptateur côté serveur. Exemple : formulaire de signalement
Meridian Properties souhaite un formulaire public « Signaler un problème » sur son site marketing, distinct du parcours authentifié du portail des résidents, pour créer une Demande de service. La ligne de configuration existe déjà, mais les champs et la résolution de la personne doivent être préparés avant activation :
| Étape | Préparation par Meridian |
|---|---|
| Préparer la ligne de configuration | Définir une nouvelle clé, puis autoriser Requête POST et Créer un enregistrement sur la ligne de l’objet. Laisser les opérations inutiles désactivées. |
| Nommer la source | Choisir Web pour cette famille de formulaires. Ce nom de source de correspondances n’impose pas la valeur du champ Source de la demande de service. |
| Ajouter les correspondances | Associer subject à reda1__Request_Subject__c et description à reda1__Request_Description__c dans Platform. Pour email, prévoir la résolution du contact ou un champ modifiable spécialement configuré : reda1__Contact_Email__c est calculé depuis le contact et ne peut pas être alimenté directement. La liste Source fournie accepte Email, Phone, Portal ou Other, pas Web ; choisir une valeur admise et adaptée. Les champs de Case dans Sales Cloud doivent être vérifiés séparément. |
| Tester | Envoyer un exemple valide et vérifier la demande créée. Tester ensuite un cas réellement refusé par votre configuration, par exemple un champ obligatoire manquant, puis vérifier l’absence d’écriture et le journal d’erreur disponible. |
Après validation de ces étapes, le formulaire public peut alimenter les demandes de service. Son authentification et ses contrôles restent distincts de ceux du portail des résidents ; le partage d’un objet cible ne leur donne pas le même parcours.
Pour aller plus loin
- REDA Data Service : connecter vos formulaires — moteur, URL et correspondances web préconfigurées.
- Comprendre les journaux asynchrones REDA — rechercher et analyser les erreurs de traitement.
- Demandes web et demandes de visite — autre parcours de réception des demandes.
Questions fréquentes
Les correspondances doivent désigner à la fois le bon objet et la source demandée dans l’URL. Vérifiez les noms d’API et le groupe de source, ainsi que la présence des lignes dans le bon environnement. Cette erreur intervient en arrière-plan ; une réponse d’acceptation peut l’avoir précédée.
La clé est stockée dans chaque ligne Data Service Setup. Le service n’impose pas qu’elles soient toutes différentes, mais utiliser une clé distincte par objet permet de la remplacer sans modifier les autres intégrations. Ne réutilisez jamais une valeur de démonstration en production.
Les règles de validation actives et applicables s’exécutent lors de l’écriture. Elles ne remplacent pas tous les contrôles d’une intégration publique, et les contraintes d’un formulaire écran ne sont pas toutes des règles de données. La conversion de valeurs, la résolution de contacts ou le contrôle des mises à jour peuvent nécessiter un traitement complémentaire. Testez un refus attendu et sa journalisation avant l’ouverture du service.
Utilisez POST, qui transporte la liste de valeurs dans le corps JSON. GET passe aussi les contrôles et peut déclencher une écriture sur ce service lorsqu’il est activé : il ne sert pas ici à consulter les enregistrements.
Cet article vous a-t-il été utile ?