Le middleware reçoit un identifiant de compte Salesforce, mais l’application métier ne retrouve ensuite aucun compte derrière ce lien. Le journal affiche pourtant une création réussie. Relancer immédiatement risque de mélanger une tentative annulée, une correspondance déjà valide et une nouvelle création. Le premier contrôle consiste à retrouver la demande Composite complète, plutôt qu’à transformer chaque identifiant aperçu dans sa réponse en référence utilisable par l’ERP.
En pratique, success=true à l’intérieur d’une réponse ne suffit pas toujours à établir qu’un compte a été conservé. Salesforce documente une interaction entre le paramètre allOrNone global de Composite et celui d’une sous-requête sObject Collections. Dans une combinaison précise, une création annoncée comme réussie est ensuite annulée avec l’ensemble. Le connecteur doit qualifier ces deux niveaux avant de rendre son lien disponible.
La recette suivie est fictive : deux comptes attendus côté ERP, une collection de créations et une seconde sous-requête indépendante. Un programme Python exécute 52 contrôles, puis conserve ses observations et ses correspondances dans des fichiers SQLite temporaires. Il distingue identifiant observé, création retenue, annulation et issue à examiner. Il n’exécute aucune requête Salesforce et ne modifie aucun compte CRM ou ERP.
Notre accompagnement en intégration API entre vos logiciels qualifie ces résultats jusqu’à leur utilisation métier. Une intégration Salesforce avec votre ERP permet de revoir le contrat du connecteur, les références conservées et les conditions de reprise avec les équipes qui administrent le CRM.
Pour qui : un lien CRM–ERP pointe vers un compte introuvable
Revenir à la création qui a fourni l’identifiant
Le diagnostic concerne une création d’Account par sObject Collections à l’intérieur de Composite REST. Il devient utile lorsque le connecteur a mémorisé l’identifiant d’une ligne positive sans examiner le résultat des autres opérations. Le coût caché apparaît ensuite dans les associations refusées, les dossiers retenus par l’ERP et le temps passé à rechercher un compte que le suivi avait déclaré créé.
Commencer par la bonne organisation, le compte technique, la version d’API et la demande envoyée. Un identifiant lu dans une sandbox ne prouve rien dans une autre organisation. Une lecture infructueuse peut aussi dépendre du chemin utilisé ou des droits. Il faut donc rapprocher le résultat transactionnel de cette tentative avant de conclure que Salesforce a perdu une fiche.
Séparer le contrat de création du parcours commercial complet
Retrouver un Account ne signifie pas que le client est facturable, que son contact est complet ou que son dossier peut être ouvert dans l’ERP. Ces conditions dépendent du processus de l’entreprise. Le contrôle proposé porte sur l’admission d’une correspondance d’identité ; il n’autorise aucune commande, facturation ou fusion de clients à partir du seul succès technique.
Un job Bulk, une action Apex, une création Tree et un graphe Composite possèdent d’autres frontières. La vue d’architecture Salesforce, middleware et reprise aide à identifier le canal réellement utilisé. Le nom du SDK ne suffit pas : examiner la ressource appelée et la forme de la réponse que le composant remet au mapper.
Lire les deux paramètres allOrNone avant de retenir un compte
Identifier le niveau qui peut annuler la création
La référence allOrNone dans Composite et Collections explique l’interaction : un paramètre global vrai impose le comportement atomique aux collections incluses. S’il est faux, chaque collection suit son propre paramètre. L’exemple documenté montre notamment un résultat interne positif qui ne survit pas à l’annulation globale.
Il faut retrouver ces valeurs dans la demande conservée. Chercher uniquement le mot « rollback » dans un message reçu laisse dépendre la décision d’une formulation de diagnostic. Si un paramètre a été omis, retrouver sa valeur effective dans le contrat de la version utilisée. Le profil local exige une décision explicite sur ces valeurs ; il ne tente pas de deviner un réglage disparu.
Décider si des créations partielles ont un sens métier
Accepter quelques comptes d’un lot peut être utile si chacun reste exploitable indépendamment. Si leur création doit accompagner d’autres opérations obligatoires, il faut définir l’unité qui doit réussir ensemble. Cette décision appartient au contrat métier ; réduire le nombre d’appels REST ne justifie pas de publier un lien dont les dépendances attendues ont échoué.
À l’inverse, rendre atomique tout un ensemble de dossiers indépendants peut élargir inutilement une reprise. Le choix ne se résume donc pas à « vrai est plus sûr ». Il faut préciser quelle conséquence produit une erreur sur un compte, sur la collection et sur les autres sous-requêtes. La recette doit rendre ces différences visibles avant l’augmentation des volumes.
Rattacher les résultats au plan envoyé et aux références ERP
Conserver deux niveaux de correspondance
Le referenceId rapproche une sous-réponse de sa sous-requête ; il n’identifie pas durablement le client. À l’intérieur d’une création par Collections, les SaveResult suivent l’ordre des enregistrements envoyés, selon la référence de création sObject Collections. Le plan doit donc conserver aussi la référence ERP associée à chaque position de cette collection.
Notre profil local nomme les deux sous-requêtes accounts et independent, puis ordonne CLI-A et CLI-B pour les comptes. Ces noms sont inventés pour l’exercice. Les références ERP restent dans le plan du connecteur ; leur présence dans le registre ne crée aucun champ personnalisé dans Salesforce. Une inversion des sous-réponses externes ne change pas leur association lorsque leurs identifiants sont rapprochés correctement.
Contrôler les champs au niveau où ils existent
Dans les formes retenues, les erreurs d’un SaveResult portent statusCode, tandis qu’une erreur de sous-requête Composite porte errorCode. Un résultat en échec peut omettre id. Le lecteur ne doit pas remplacer cette absence par une identité de repli, ni demander systématiquement ce champ à toutes les lignes avant d’examiner leur état.
Le programme refuse une quantité de résultats différente du plan, un referenceId inconnu et un identifiant de sous-requête répété. Il refuse aussi une réussite dépourvue d’identité ou accompagnée d’erreurs. Ces refus maintiennent les liens en revue ; ils ne prouvent pas que la création native a échoué. Le profil attend une forme finale précise, pas tous les formats possibles d’un client Salesforce.
Enregistrer une observation sans publier tous ses identifiants
Séparer la trace reçue de la correspondance active
Deux tables SQLite remplissent des fonctions différentes. La première conserve l’identité de l’observation, les empreintes du plan et du résultat local, ainsi que la décision par référence ERP. La seconde contient uniquement les correspondances admises. Un identifiant candidat peut ainsi rester visible dans une observation annulée sans devenir une cible utilisable pour un prochain échange.
Les empreintes portent sur les valeurs décodées de notre laboratoire, pas sur les octets HTTP originaux. Elles détectent la réutilisation d’un nom d’observation avec une autre entrée ; elles n’authentifient aucune réponse. Les objets Python sont fabriqués dans le programme. Le client réel doit encore vérifier le transport, l’origine des réponses et leur décodage avant de confier un résultat à son propre contrôle.
Garder les anciennes correspondances lorsque la nouvelle tentative échoue
Une annulation de cette tentative n’autorise pas à effacer un lien établi auparavant. Un autre envoi peut déjà avoir créé le compte, ou le dossier peut posséder une correspondance indépendante. Dans l’exercice, une observation annulée conserve le lien précédent intact. L’examen de son état actuel dans Salesforce appartient à une étape distincte de réconciliation.
Le registre distingue aussi deux périmètres d’organisation déclarés localement. Les mêmes références ERP peuvent y posséder des liens séparés. Ce libellé n’est pas un identifiant d’organisation découvert auprès de Salesforce : son attribution reste à vérifier dans une intégration réelle. La contrainte un-à-un du laboratoire est également un choix de profil ; certains modèles métier demandent une autre cardinalité.
Exercice corrigé : quatre combinaisons, un seul premier lien conservé
Exécuter le registre sur des réponses fabriquées
Le programme Python complet utilise la bibliothèque standard, crée ses bases temporaires puis les supprime en fin d’exécution. Il reçoit des objets déjà décodés, avec des libellés comme crm-A qui ne sont pas des identifiants Salesforce valides. La seconde sous-requête est déclarée indépendante : les dépendances d’un graphe réel ne sont pas analysées par ce profil.
python3 composite_link_inventory.pyDans le scénario de matrice, le second compte est toujours refusé. Le premier porte un résultat positif lorsque le paramètre interne est faux ; lorsque celui-ci est vrai, sa fixture porte une erreur d’annulation. La sous-requête indépendante réussit dans les variantes globales fausses et porte PROCESSING_HALTED dans les variantes globales vraies. Les attentes sont fixées avant l’exécution.
Comparer le candidat reçu au lien effectivement présent en base
| Paramètres du scénario local | Premier compte et liens actifs |
|---|---|
| Composite faux ; Collection faux | crm-A retenu ; un lien actif |
| Composite faux ; Collection vrai | Annulation de collection ; aucun lien |
| Composite vrai ; Collection faux | crm-A observé mais annulé ; aucun lien |
| Composite vrai ; Collection vrai | Annulation globale ; aucun lien |
Les lectures par de nouvelles connexions SQLite retrouvent respectivement un, zéro, zéro et zéro lien actif. La troisième ligne expose le défaut recherché : l’identifiant est présent dans l’observation, mais absent des correspondances autorisées. Il ne suffit donc pas de compter les valeurs non vides. Le résultat du stockage doit être rapproché de la décision qui autorisait leur admission.
Les 52 contrôles vérifient aussi le cas entièrement réussi sous les quatre combinaisons, l’échec ultérieur d’une sous-requête indépendante et les refus de corrélation. Une erreur ultérieure peut laisser les comptes admis lorsque le paramètre global est faux. Cela ne termine pas pour autant un dossier métier qui exigeait davantage que ces seuls comptes.
Retenir une issue inconnue et refuser une correspondance contradictoire
Rendre la revue durable sans inventer un échec natif
Une réponse absente ou un transport déclaré incomplet produit une observation locale en revue, sans nouveau lien actif. La même décision s’applique lorsque la forme reçue sort du profil. Un code intermédiaire n’est pas accepté comme résultat final. Ces états disent que notre lecteur n’a pas qualifié la sortie ; ils n’affirment pas que Salesforce n’a effectué aucune opération.
Un nom d’observation réutilisé avec les mêmes entrées retrouve la décision conservée sans ajouter de correspondance. S’il porte un autre plan ou résultat, le registre refuse son remplacement. Une observation ultérieure doit rester identifiable séparément. Cette idempotence locale ne rend pas une nouvelle requête CRM idempotente et ne justifie pas de fabriquer une nouvelle clé pour contourner un conflit.
Annuler l’écriture locale lorsqu’un deuxième lien contredit l’existant
Le scénario de conflit tardif propose d’abord une nouvelle référence, puis un lien différent pour une référence déjà connue. La transaction SQLite a commencé, mais le second rapprochement provoque son refus. Après réouverture, la première insertion et la nouvelle observation ont disparu ensemble ; les lignes antérieures restent identiques. La portée des transactions SQLite concerne ce stockage local.
Ce rollback n’annule aucune création Salesforce ni aucun appel ERP effectué ailleurs. Le seuil de publication retenu par le laboratoire exige des références expliquées et l’absence de conflit avec sa table active. Une production doit encore définir qui recherche les effets distants, qui valide le rapprochement et quelle action suit un désaccord. Le simple retour d’une ancienne version du middleware ne répare pas ces effets.
Erreurs fréquentes qui transforment une réponse partielle en faux succès
Conserver tous les identifiants non vides. C’est précisément la faute révélée par la troisième combinaison. La trace d’un candidat et la table de correspondance doivent rester distinctes. Un compteur utile sépare créations annoncées, créations qualifiées et liens admis. Un premier signal faible est un nombre de liens publiés égal au nombre d’identifiants reçus malgré une annulation expliquée dans le même dossier.
Aplatir les deux niveaux de résultat. Un mapper commun à plusieurs connecteurs peut ne garder qu’un booléen et un message. Le second signal faible est alors la disparition des paramètres et des sous-requêtes dans les traces, tandis que le support retrouve encore le résultat brut. Les retries ne corrigent pas cette perte de contexte ; ils peuvent seulement multiplier les tentatives à rapprocher.
Effacer un lien antérieur pour forcer une recréation. Une observation annulée décrit sa tentative, pas toute l’histoire du client. Retrouver la correspondance existante avant d’autoriser une nouvelle création. L’analyse Salesforce, contrats, commandes et factures prolonge cette distinction lorsque le rapprochement entraîne des effets opérationnels ou financiers.
Transposer une frontière depuis une autre ressource. Composite Batch, Composite Graph et les changesets OData ne partagent pas le même contrat. Le diagnostic des groupes refusés dans un lot SAP Business One traite des unités MIME et de Content-ID. Il ne fournit pas un parseur applicable aux tableaux SaveResult de Salesforce.
Plan d’action : remettre les liens CRM–ERP sous contrôle avant la reprise
Faire relire une demande complète par les bons responsables
Choisir une exécution dont un compte reste introuvable après réception d’un identifiant. L’administrateur Salesforce retrouve l’organisation, le rôle et les règles de validation concernées. L’intégrateur fournit la version d’API, le payload effectivement envoyé, les deux paramètres, les sous-requêtes et leurs références. Le responsable ERP indique à quel moment le lien a été rendu disponible et quels traitements l’ont déjà utilisé. Une capture de statut isolée ne remplace aucun de ces éléments.
Reconstituer ensuite la transformation depuis les réponses vers le mapping. La journalisation doit relier l’entrée, son plan, les résultats ordonnés et les décisions de sortie. L’observabilité distingue erreur de transport, refus de création, annulation et conflit de correspondance. La responsabilité de chaque reprise doit être nommée, avec les dépendances métier qui autorisent une admission partielle. Différer les relances automatiques tant que le connecteur ne sait pas expliquer pourquoi il a conservé la référence litigieuse.
- Identifier la ressource réellement appelée et conserver la demande avec ses paramètres transactionnels explicites.
- Rapprocher chaque sous-réponse de son referenceId, puis les résultats de collection des références ERP envoyées.
- Rejouer en recette les quatre combinaisons, une réponse incomplète et une erreur dans une opération indépendante.
- Comparer les identifiants observés aux seuls liens admis, avec une lecture du stockage après réouverture.
- Rechercher les correspondances et effets déjà présents avant de choisir une nouvelle création ou un rattachement.
- Fixer le seuil de reprise, les exceptions encore ouvertes et l’équipe autorisée à élargir le périmètre.
Recetter le retour arrière et la libération des dossiers retenus
Le runbook précise qui suspend la sortie des liens, qui bloque la queue concernée et comment reprendre les dossiers qualifiés. Un rollback de configuration restaure une combinaison compatible de producteur, SDK et mapping. Il conserve les observations et ne supprime pas les preuves pour rendre le prochain passage plus simple. Si un retry a déjà été envoyé, son résultat reste un dossier séparé à rapprocher avec la même identité métier.
Le passage suivant exige des décisions expliquées sur la cohorte choisie, pas seulement une baisse du nombre d’erreurs. L’équipe métier doit retrouver les comptes attendus dans le bon périmètre et distinguer ceux qui restent en revue. Le budget de correction et les seuils de retard se mesurent sur ces dossiers, sans déduire une économie commerciale de notre expérience locale. L’élargissement attend une procédure praticable pour les exceptions qui subsistent.
Sources et parcours Salesforce à vérifier avec le connecteur
Confronter les paramètres au contrat de la ressource utilisée
Le corps de requête Composite décrit les paramètres, les références et les dépendances explicites. Le simple ordre affiché dans un fichier ne remplace pas une dépendance déclarée. La version et les options doivent être vérifiées sur le client installé ; notre registre n’émule ni le regroupement des sous-requêtes ni l’exécution des automatismes de l’organisation.
La présentation officielle des API de données distingue notamment Batch et Collections. Pour Composite Graph, la frontière atomique porte sur chaque graphe, avec des graphes indépendants. Ces distinctions empêchent d’appliquer notre profil à toute ressource dont le nom contient Composite.
Séparer création, extraction et traitement sous charge
Une table de liens correcte ne démontre pas qu’un export a lu tous les comptes. L’analyse du total Salesforce comparé aux pages réellement reçues examine cette autre rupture. Elle aide à retrouver une sortie incomplète sans attribuer automatiquement ses absences à une création annulée.
Lorsque le problème concerne plutôt les imports massifs ou les changements courants, le diagnostic Salesforce sous charge, Bulk, CDC et Pub/Sub replace ces flux dans leurs engagements. Une augmentation de concurrence n’apporte aucune information sur l’issue d’une ancienne création. Il faut d’abord qualifier cette issue, puis mesurer le transport et la capacité réellement nécessaires.
Conclusion : admettre une correspondance après avoir qualifié son résultat
Paradoxalement, conserver moins d’identifiants peut rendre le suivi plus utile : l’observation garde le candidat reçu, tandis que la table active expose seulement les liens admis. Le support peut alors expliquer la différence au lieu de poursuivre une référence comme si sa création était acquise. Le paramètre global et celui de la collection doivent rester attachés à cette décision.
Les 52 contrôles locaux retrouvent un seul premier lien actif dans la matrice d’échec, protègent les anciennes correspondances et annulent une écriture locale contradictoire. Ils vérifient une politique sur des fixtures inventées. Ils ne remplacent ni la lecture autorisée des comptes réels ni la qualification des effets produits par une nouvelle demande Salesforce.
Commencer avec une exécution retrouvable, ses références ERP et son résultat complet. Notre expertise en connecteurs Salesforce et échanges avec le SI permet de cadrer le rapprochement avec vos équipes CRM, ERP et exploitation, avant de libérer les dossiers encore retenus.
Pour vos raccordements Salesforce, Dawap propose un accompagnement en intégration API avec vos applications métier, de la lecture des résultats à la reprise des correspondances. Le développement du connecteur peut inclure une recette des cas partiels, une conservation exploitable des observations et une procédure de correction adaptée aux dossiers que vos équipes doivent traiter.
