Le commercial renseigne une zone de préparation dans la fiche client SAP Business One. Le responsable logistique la voit dans SAP, mais le connecteur transmet une fiche sans cette zone au logiciel de préparation. Le champ est donc ressaisi à la main, parfois sur le mauvais client. Le blocage persiste alors que les échanges HTTP continuent de réussir.
En pratique, « le champ existe dans SAP » ne dit pas à quel endroit l’intégration le perd. La propriété peut manquer dans la réponse lue, être retirée par le décodeur du SDK ou ne jamais entrer dans le mapping métier. Créer un deuxième champ dans l’ERP avant d’avoir comparé ces étapes peut rendre le problème plus difficile à comprendre.
Nous suivons un scénario entièrement fictif : la société A possède un partenaire C-FICTIF-42, avec une propriété utilisateur nommée U_ExportZone dont la valeur est A2. Le connecteur doit conserver cette information sous preparation_zone. Ces noms et cette règle appartiennent à l’exemple ; ils ne désignent pas des champs standard que toutes les installations SAP possèdent.
Notre accompagnement en intégration API commence par cette preuve de circulation de la donnée. Pour un raccordement SAP aux logiciels métier, Dawap examine le Service Layer et le middleware avec votre installateur ERP, qui confirme la définition et l’usage des personnalisations de votre société.
Pour qui : un champ utilisateur connu du métier manque dans l’export
Partir d’un partenaire et d’une valeur vérifiables
Choisir une fiche précise vaut mieux que demander l’export de tous les champs. Dans notre cas, l’équipe retrouve le partenaire fictif et la valeur A2, puis identifie la société et l’environnement utilisés par le connecteur. Une capture de la fiche aide à décrire le symptôme, mais elle ne remplace pas la définition technique du champ et la lecture de l’objet concerné.
Le diagnostic convient lorsqu’une donnée existante a déjà un consommateur identifié : zone de préparation, qualification commerciale ou référence nécessaire à un raccordement. Il n’autorise pas l’aspiration de toutes les personnalisations de SAP. Le propriétaire métier doit expliquer ce que le logiciel destinataire décide à partir de la valeur, et ce qui arrive lorsqu’elle manque.
Distinguer une UDF d’un élément affiché par une extension
Un libellé visible à l’écran peut correspondre à plusieurs réalités dans une installation personnalisée. Avant de parler de champ utilisateur, faire confirmer son origine par l’installateur : propriété persistée, donnée calculée, information portée par un autre objet ou élément d’interface ajouté. Le diagnostic doit suivre l’objet réel, pas une ressemblance entre deux libellés.
Si l’information n’a aucune interface de lecture qualifiée pour le projet, la suite devient une étude d’accès aux données. Ce n’est plus une correction de mapping. Cet arrêt explicite évite de livrer un adaptateur qui consulte une propriété inventée ou de promettre qu’un écran SAP garantit automatiquement une propriété équivalente dans chaque API.
Séparer le libellé métier, la propriété API et sa définition
Le nom visible ne constitue pas une clé technique
Dans l’exemple, « Zone de préparation » est un libellé choisi pour les utilisateurs. La propriété attendue par le connecteur est U_ExportZone. SAP documente le préfixe U_ pour les UDF. Transformer le libellé affiché en nom de propriété, retirer ce préfixe ou le reconstituer par traduction introduirait une convention que l’interface n’a pas fournie.
Le contrat du middleware conserve le nom exact observé et le sens métier validé. Si le libellé change sans modification de la propriété technique, le connecteur ne devrait pas changer de donnée par simple recherche de texte. À l’inverse, deux champs portant un libellé voisin peuvent répondre à des usages différents ; l’accord du responsable métier reste nécessaire.
Ne pas confondre définition du champ et valeur d’une fiche
La référence officielle expose UserFieldsMD pour les métadonnées des champs. Ses lectures utilisent notamment TableName et FieldID pour une définition ; les propriétés décrivent le champ. Cela ne constitue pas la valeur du partenaire C-FICTIF-42. Le dossier doit donc conserver séparément la définition inspectée et l’objet métier qui porte la valeur à transmettre.
Cette séparation permet une conversation utile avec l’installateur : « voici la définition attendue, voici la société et voici la fiche lue ». Elle évite une demande imprécise du type « ajoutez le champ à l’API », alors que le champ peut déjà être exposé et perdu plus loin. Le diagnostic commence en lecture ; aucune création ou suppression de personnalisation n’est nécessaire pour comparer les preuves.
Localiser la première étape où la valeur disparaît
La grille suivante décrit notre chaîne fictive. Chaque ligne correspond à une frontière observable. Les contrôles doivent porter sur le même partenaire et la même version de sa donnée. Comparer une réponse ancienne avec une fiche modifiée après coup produirait un désaccord artificiel.
| Étape | Preuve cherchée | Si elle manque |
|---|---|---|
| Contexte | Installation, société et partenaire attendus | Arrêter la comparaison |
| Métadonnées | Propriété du bon objet | Revoir la définition avec l’installateur |
| Réponse source | Clé présente et valeur lue | Examiner la lecture et sa projection |
| Objet décodé | Clé et valeur conservées | Examiner le SDK ou le DTO |
| Mapping cible | Valeur associée au bon partenaire | Corriger la règle de conversion |
Une absence ne se transforme pas automatiquement en valeur nulle
Une propriété absente du payload ne dit pas qu’un utilisateur a effacé sa valeur. Une propriété présente avec null et une chaîne vide sont également deux observations distinctes. Notre exercice local les classe séparément avant toute décision métier. Il ne leur attribue pas une signification universelle valable pour toutes les personnalisations SAP.
La politique de synchronisation choisit ensuite quoi préserver, bloquer ou envoyer. Pour notre zone obligatoire fictive, l’absence déclenche une exception et aucune valeur n’est préparée pour remplacement. Cette règle est un choix de contrat. Elle protège le logiciel de préparation d’un effacement silencieux, sans prétendre imposer le comportement natif de SAP pour toutes les UDF.
Garder une preuve avant chaque transformation
Le développeur compare une copie autorisée de la réponse source, l’objet produit par son décodeur et la projection métier sortante. Les noms des étapes doivent correspondre au code réellement utilisé. Une trace prise seulement après le mapping ne permet pas de savoir si SAP a omis la valeur ou si le connecteur l’a déjà retirée.
En production, limiter la collecte aux informations nécessaires et aux personnes autorisées. La preuve de diagnostic n’a pas besoin de reproduire une fiche client complète. Une recette synthétique facilite la comparaison ; les traces d’un incident réel suivent les règles d’accès et de conservation du client. Les secrets de session n’ont aucune place dans cette copie.
Relire les métadonnées de la société effectivement connectée
Un schéma d’une autre société peut être techniquement valide
La documentation SAP précise que les métadonnées varient avec les personnalisations de la base société ; les UDF figurent dans leur définition depuis 9.1 PL05. La lecture de $metadata doit donc être rattachée au contexte concerné. Le nom d’un serveur commun ne prouve pas que deux sociétés possèdent les mêmes propriétés.
Notre modèle local refuse d’ailleurs une observation issue de B lorsque l’attente vise A, même si le nom du champ est identique. En exploitation, le contexte de la requête doit être établi par le connecteur et sa configuration autorisée. Une étiquette « société A » ajoutée dans un journal ne prouve pas que l’appel source a effectivement utilisé cette société.
Qualifier le cache et le modèle généré du client
Si le SDK a été généré avant l’ajout du champ, comparer son modèle à la définition actuelle. Un objet de transfert contenant seulement les propriétés connues peut laisser tomber les nouvelles clés. Le symptôme devient alors très précis : la réponse source contient A2, mais l’objet décodé ne contient plus U_ExportZone. Ce constat appartient au décodeur testé, pas à tous les SDK SAP.
La clé de cache retenue par le projet doit distinguer les environnements et sociétés qu’il dessert. Enregistrer aussi la révision du modèle utilisée lors d’un traitement facilite la reprise. Invalider tous les caches du portefeuille pour corriger un seul client agrandit inutilement le rayon d’impact ; la responsabilité de cette invalidation relève de l’équipe qui exploite le connecteur.
Examiner la projection de lecture avant de modifier SAP
Une réponse volontairement réduite peut exclure le champ
SAP documente des schémas utilisateur qui limitent les propriétés renvoyées, sélectionnés notamment par B1S-Schema. Pour notre diagnostic, relever la requête réellement envoyée et la projection active est donc plus utile qu’une nouvelle capture d’écran. Le contrôle porte sur le contrat de lecture choisi pour ce flux.
Si une lecture de recette qualifiée contient la valeur et que la lecture du connecteur ne la contient pas, comparer leurs paramètres et leur contexte. Ne pas supprimer en bloc les restrictions pour « retrouver tous les champs ». Une projection réduite peut répondre à des contraintes légitimes ; il faut ajouter seulement l’information nécessaire, avec l’équipe responsable de cette configuration.
Tester la chaîne exacte, pas un autre client HTTP
Une lecture manuelle réussie avec un outil de test confirme ce parcours-là. Elle ne certifie pas le SDK, le compte ou les paramètres du middleware. Le développeur doit rejouer la lecture depuis l’adaptateur de recette concerné, puis comparer les mêmes points de passage. Sans cette discipline, l’incident alterne entre « cela marche dans Postman » et « cela manque dans le connecteur ».
Un signal faible mérite attention : le champ est présent après un contournement manuel, puis disparaît au traitement planifié suivant. Rechercher quel chemin de lecture et quelle révision de modèle ce traitement emploie. La persistance d’un ancien worker, d’un ancien mapping ou d’une projection distincte fournit des hypothèses à vérifier ; aucune ne doit être présentée comme cause sans observation correspondante.
Expérience : suivre U_ExportZone sans interroger SAP
Un laboratoire qui sépare les frontières de perte
Le fichier udf_projection_inventory.py s’exécute avec Python 3.9 ou plus récent et sa bibliothèque standard. Il utilise des dictionnaires locaux représentant une réponse, un objet décodé et un mapping. Les métadonnées sont un ensemble de noms fourni au modèle ; aucun document natif n’est téléchargé ni interprété par le programme. Le verdict « non déclaré » concerne seulement cette liste fournie. Une liste incomplète ou une ancienne interface doit être qualifiée séparément avant toute conclusion sur la disponibilité native du champ.
Les 36 contrôles vérifient notamment le mauvais contexte, la propriété absente, null, la chaîne vide, la perte dans le DTO et la transformation de la valeur. Le modèle conserve aussi le partenaire attendu à chaque étape. Une valeur A2 identique sur deux fiches ne suffit pas à démontrer que le connecteur traite la bonne fiche.
python3 udf_projection_inventory.py
# 36 local checks passed. Native SAP reads: 0;
# HTTP calls: 0; ERP writes: 0.Lire la différence entre donnée omise et donnée transformée
Exemple concret du laboratoire : la réponse contient CardCode=C-FICTIF-42 et U_ExportZone=A2, mais le DTO ne garde que CardCode. Le verdict dropped_by_decoder désigne cette perte. Si le DTO garde la propriété en remplaçant A2 par a2, le verdict devient changed_by_decoder. La distinction compte lorsqu’une zone logistique sensible à la casse ne doit pas être normalisée sans accord.
Le programme refuse également un mapping qui associe la bonne zone au partenaire C-FICTIF-43 au lieu de C-FICTIF-42. Il produit un reçu local de comparaison incluant installation, société, objet, partenaire et valeur source. Ce reçu ne vaut ni autorisation d’accès, ni clé d’idempotence SAP, ni confirmation d’écriture dans le logiciel cible.
Décider les conversions avec le propriétaire de la donnée
Ne pas convertir toute valeur personnalisée en texte libre
La règle de notre zone fictive accepte une chaîne non vide et conserve exactement ses caractères. Elle ne convient pas automatiquement à une date, un montant, un indicateur ou un code à valeurs autorisées. Le contrat doit préciser le type observé, le type cible et la règle de conversion nécessaire. Une conversion implicite ne devient pas correcte parce qu’elle évite une exception.
Le second signal faible est la réussite du flux alors que des préparations sont mal routées. Une normalisation de casse, un espace supprimé ou une valeur par défaut peuvent rendre la donnée syntaxiquement acceptable tout en changeant sa portée métier. La recette doit inclure une valeur qui révélerait cette modification, plutôt que tester uniquement une chaîne que toutes les transformations laissent inchangée.
Choisir qui peut corriger l’information source
Le connecteur ne devrait pas devenir un second écran de paramétrage SAP sans décision explicite. Le responsable métier valide la zone attendue ; l’installateur confirme sa définition et les usages existants ; l’équipe d’intégration adapte la lecture et le mapping. Cette répartition évite qu’une correction du flux change une personnalisation utilisée par d’autres applications.
Paradoxalement, accepter davantage de valeurs peut dégrader le service si les exceptions deviennent invisibles. Le coût caché se mesure alors en préparations orientées vers le mauvais circuit et en corrections manuelles. Il vaut mieux mettre en attente une fiche dont la zone obligatoire est indéterminée que lui attribuer une zone supposée normale uniquement pour terminer le batch.
Recetter la correction sur la version et les objets concernés
Conserver les différences de version dans le dossier technique
La documentation courante décrit des annotations de métadonnées OData V4 à partir de 10.0 FP2608, notamment pour rapprocher libellés et propriétés. Elle comporte aussi une réserve de compatibilité sur ces fonctions. Les traiter comme une aide de diagnostic versionnée, sans en faire un prérequis universel du connecteur ni une extension imposée aux anciennes installations.
Pour le projet, relever la version effectivement installée, l’interface utilisée et le périmètre approuvé avec l’installateur. Un exemple trouvé pour un autre produit SAP ou une autre génération d’API peut employer un modèle différent. Le résultat attendu reste la preuve de la propriété sur l’objet du client ; la nouveauté documentaire ne remplace pas cette vérification.
Choisir un jeu de recette qui révèle une régression
Préparer au minimum des observations distinctes : champ présent, champ absent de la réponse, valeur vide, valeur modifiée par le décodeur et mauvaise fiche cible. Ce sont des scénarios de notre contrat, à adapter au périmètre réel. Ajouter les cas d’un champ porté par un autre objet si le projet les rencontre ; ne pas généraliser une règle de partenaire à toutes les lignes de documents.
La journalisation relie l’entrée source, la révision du mapping et la sortie proposée. Le runbook indique le responsable de l’écart et le seuil qui suspend l’export. Pour notre zone obligatoire, toute perte ou transformation inexpliquée bloque la mise en service du flux concerné. Un rollback du connecteur conserve les preuves pour comprendre quelles fiches ont déjà circulé et quelles reprises restent nécessaires.
Plan d’action : corriger le premier endroit qui perd le champ
- Qualifier la personnalisation et le partenaire témoin. Le référent métier décrit l’usage de la zone et retrouve une fiche de recette. L’installateur SAP confirme la définition technique, l’objet porteur et la société. Le développeur relève la connexion utilisée par son adaptateur. Cette étape doit produire une attente vérifiable : une propriété précise, une valeur connue et un partenaire identifié. Différer toute demande de création de champ tant que l’équipe n’a pas distingué donnée absente, donnée non exposée et donnée perdue dans le connecteur.
- Comparer les trois représentations sans écrire dans SAP. L’intégrateur conserve une réponse source autorisée, l’objet décodé et le mapping préparé pour le logiciel destinataire. Il localise la première différence, y compris sur l’identité du partenaire. L’exploitant vérifie que les traces proviennent de la même révision et du même environnement. Si les éléments ne sont pas comparables, refaire la collecte plutôt que choisir une cause probable. La correction doit viser une frontière observée, avec une responsabilité technique clairement attribuée.
- Corriger et préparer une reprise limitée. Modifier la projection, le décodeur ou le mapping selon le diagnostic établi. Recetter les valeurs normales et les cas qui doivent bloquer, puis comparer les sorties avant et après correction. Le responsable métier valide le sens des conversions. L’exploitant prépare le rollback et la liste des fiches concernées ; il conserve les résultats déjà transmis pour éviter qu’un retry général masque des effets antérieurs. Aucun lot élargi ne part sur la seule réussite du partenaire témoin.
- Contrôler le résultat dans le circuit de préparation. L’équipe destinataire confirme que la zone reçue appartient au bon partenaire et produit la décision attendue. Le dossier distingue les fiches corrigées, celles déjà conformes et les exceptions à traiter. Le monitoring suit les pertes de propriété par révision de connecteur et l’ancienneté des fiches bloquées. La clôture exige une comparaison métier, une procédure de reprise praticable et un interlocuteur pour les nouvelles personnalisations, afin que le prochain champ ajouté ne disparaisse pas silencieusement.
Erreurs fréquentes : réparer SAP alors que la donnée a déjà été reçue
Créer un doublon ou élargir inutilement les permissions
La référence expose aussi des opérations de création, modification et suppression sur UserFieldsMD. Leur existence ne justifie pas de les utiliser pour résoudre un export incomplet. Un champ supplémentaire peut créer deux sources concurrentes pour la même information. Toute modification de définition relève du projet ERP et de ses dépendances, avec l’installateur responsable.
Accorder davantage de droits au compte du connecteur sans diagnostic ne répare pas non plus un DTO qui retire la propriété après réception. Si les octets du champ sont déjà dans la réponse observée, rechercher d’abord la transformation suivante. Une anomalie de permissions reste possible dans d’autres cas, mais elle demande sa propre preuve et une décision d’accès adaptée.
Fermer l’incident sur un statut de transport
Un HTTP 200 peut accompagner une réponse volontairement limitée aux propriétés sélectionnées. Le contrôle métier doit donc vérifier ce que le connecteur a reçu et ce que le destinataire a conservé. Il ne faut pas davantage traiter un statut d’échec comme la preuve que rien n’a été appliqué après un timeout ; l’issue dépend de l’opération réellement engagée.
Le laboratoire joint ne fait que lire ses propres structures en mémoire. Il n’applique aucune mutation et ne propose pas une politique universelle de retry. Dans un raccordement réel, la reprise d’une écriture suit le contrat de l’API cible, avec rapprochement des effets et idempotence lorsque cette capacité a été qualifiée. La correction d’un champ perdu ne dispense pas de ce contrôle.
Sources et guides complémentaires pour qualifier le raccordement
Les références SAP et les limites du laboratoire
La documentation officielle Working with SAP Business One Service Layer documente les métadonnées, les schémas utilisateur et les UDF. La référence Service Layer précise les ressources et leurs opérations. Les versions courantes ont été consultées le 15 octobre 2026.
Les 36 contrôles Python ne prouvent ni la disponibilité d’une UDF chez un client, ni ses droits de lecture, ni la compatibilité de son SDK. Ils vérifient uniquement un contrat fictif à chaîne non vide et des structures fournies localement. La recette réelle doit examiner les définitions, les valeurs et les interfaces autorisées de l’installation concernée avant toute livraison.
Relier l’identité de la société aux objets transportés
Lorsqu’une lecture provient du mauvais contexte, le diagnostic SAP Business One et isolation des sessions par société traite la sélection de connexion. Pour un flux logistique, le raccordement Shippingbo et SAP Business One examine la filiation entre documents et quantités. Ces deux questions restent distinctes de la conservation d’une propriété personnalisée dans un décodeur.
Le choix du projet doit suivre le résultat attendu : rendre la donnée existante lisible, conserver sa valeur dans le connecteur et démontrer son usage dans l’application cible. Ajouter des objets ou une synchronisation bidirectionnelle sans besoin identifié augmente la surface de maintenance. Une correction ciblée et mesurable peut suffire à supprimer la ressaisie qui avait motivé le diagnostic.
Conclusion : prouver où le champ est conservé, puis corriger sa perte
La présence d’une zone dans une fiche SAP ne garantit pas sa présence dans le logiciel destinataire. Il faut retrouver sa propriété technique, la société et le partenaire concernés, puis comparer réponse source, objet décodé et mapping. La première différence observée donne une base concrète pour choisir l’intervention.
Notre priorité serait de relire ces preuves avant de toucher à la personnalisation ERP. Si la valeur est déjà reçue, la correction appartient au connecteur. Si elle manque dès la lecture, la définition et la projection doivent être qualifiées avec l’installateur. L’absence, null et la chaîne vide restent des états distincts jusqu’à une décision métier explicite.
Une zone conservée mais rattachée à un autre partenaire reste une anomalie. La recette doit donc contrôler ensemble l’identité et la valeur, puis vérifier leur effet dans le circuit de préparation. Cette exigence permet de fermer le dossier sur une suppression réelle de la ressaisie, plutôt que sur un nouvel export qui semble complet.
Dawap vous accompagne pour examiner cette intégration API entre SAP Business One et vos logiciels métier, qualifier les pertes dans le middleware et préparer une recette avec votre équipe et votre installateur ERP. L’accompagnement peut rester limité au flux concerné, avec des preuves de conservation de la donnée et une reprise compréhensible par les personnes qui l’exploitent.
