Votre site B2B transmet ses commandes à Business Central depuis plusieurs années. Le connecteur appelle un service SOAP publié sur une page Microsoft ; une évolution de version suffit désormais à remettre ce parcours en question. Le risque dépasse une erreur de connexion : les comptes clients, les lignes commerciales et les confirmations envoyées au site peuvent dépendre d’un contrat que personne n’a relu depuis sa création.
Pour Business Central 29, Microsoft retire la publication en SOAP de ses pages d’interface utilisateur. Ce changement précis ne signifie pas que tous les services SOAP disparaissent simultanément. Il oblige à identifier la nature des objets exposés avant de choisir une migration. Remplacer une URL par un endpoint REST ressemblant serait insuffisant si les validations, les champs personnalisés ou les effets attendus diffèrent.
La bonne décision consiste à retrouver les opérations métier réellement consommées, puis à qualifier leur interface de remplacement avec votre partenaire Business Central. Une lecture de référentiel, une création de commande et une opération portée par une codeunit demandent des réponses différentes. Le transport évolue ; l’engagement sur les données et les pièces produites doit rester explicite.
Notre accompagnement en intégration API cadre cette transition du connecteur jusqu’au système qui consomme la réponse. Pour l’ERP, Dawap coordonne son expertise d’intégration Business Central avec l’installateur du client : interfaces disponibles, correspondances, recette des opérations et continuité des échanges, sans présenter une substitution technique comme une migration métier déjà réussie.
Identifier ce que Business Central 29 retire réellement
Retrouver l’objet derrière le nom du service
La documentation Microsoft sur les services SOAP distingue la dépréciation générale du protocole et le retrait particulier des pages Microsoft dans la vague 2026 release wave 2, version 29. Elle rappelle aussi le mécanisme de désactivation introduit en version 26. Le périmètre documenté constitue le point de départ ; votre environnement et ses objets déterminent les services effectivement concernés.
Demandez au partenaire ERP la liste des services publiés, avec type d’objet, identifiant, origine Microsoft ou extension, nom exposé et société. Un nom comme CustomerSync ne renseigne pas l’origine de la page. Une copie personnalisée, une page standard et une codeunit peuvent avoir des noms commerciaux presque identiques, alors que leur statut dans cette évolution n’est pas le même.
Éviter un calendrier de migration fondé sur une supposition
Rapprochez cette liste des URLs présentes dans les configurations, les journaux d’appel et les traitements planifiés. Une publication encore visible dans l’ERP peut être inutilisée ; un service oublié peut alimenter un export mensuel indispensable. Le responsable de chaque flux confirme sa dernière exécution et son prochain usage attendu, notamment pour les clôtures ou les reprises de commandes différées.
Ne concluez pas qu’une codeunit est définitivement pérenne parce qu’elle sort du retrait spécifique des pages Microsoft. La dépréciation SOAP reste un chantier distinct à planifier. À l’inverse, n’engagez pas une refonte de tous les échanges sur la seule lecture de l’annonce : traitez d’abord les dépendances identifiées, puis les autres contrats selon leur risque et leur fréquence réelle.
Inventorier les échanges qui portent encore une décision commerciale
Décrire une opération plutôt qu’un simple endpoint
Pour chaque service consommé, écrivez l’opération attendue en termes observables : reconnaître un client, enregistrer une commande, modifier une adresse de livraison ou retrouver un document créé. Associez les données entrantes, la réponse exploitée et les effets de bord. Une application peut utiliser un champ de réponse pour lancer son prochain traitement ; ce champ fait alors partie du contrat même s’il semble secondaire.
Conservez la version du connecteur et le sens du transfert dans l’inventaire. Deux consommateurs peuvent appeler le même service avec des comportements différents. Le site commande immédiatement, tandis qu’un import nocturne regroupe les demandes ; leur politique de reprise et leur tolérance à l’attente ne sont pas interchangeables. Un changement accepté par le traitement nocturne peut encore bloquer le parcours commercial interactif.
| Échange à décrire | Preuve à retrouver | Question avant migration |
|---|---|---|
| Lecture d’un client | Champs utilisés et société interrogée | Le consommateur dépend-il d’un champ personnalisé ou calculé ? |
| Création d’une commande | Référence externe et document finalement créé | Quelles validations ERP participent à la création ? |
| Modification d’une ligne | Clé de ligne et réponse relue après écriture | Une modification concurrente doit-elle empêcher l’écrasement ? |
| Traitement par codeunit | Opération publiée et effets constatés | Existe-t-il une action cible équivalente, vérifiée par le partenaire ? |
Faire apparaître les dépendances moins visibles
Un premier signal faible apparaît lorsque la même référence client existe dans plusieurs sociétés ERP. Les réponses semblent cohérentes en recette, mais le périmètre demandé n’est pas représentatif. Un second apparaît quand le connecteur ignore un champ absent et poursuit sa création avec une valeur par défaut. La migration peut produire moins d’erreurs HTTP tout en dégradant les conditions commerciales appliquées.
Le coût caché se retrouve dans les corrections : recherche de la pièce, échange avec l’ADV, modification autorisée et nouvelle confirmation au site. Mesurez les dossiers repris et leur durée constatée au lieu d’estimer un gain à partir du seul nombre d’appels modernisés. Le volume technique reste utile pour dimensionner le flux ; il ne décrit pas la conformité de ses documents.
Choisir entre API standard, API personnalisée et OData
Commencer par la couverture fonctionnelle disponible
Les API standard sont le premier candidat lorsque leurs objets, champs et opérations couvrent votre contrat. Leur présence ne suffit pas : comparez les réponses attendues par le connecteur et la manière dont l’ERP valide les écritures. Un lecteur de clients n’a pas les mêmes exigences qu’un import de commandes comportant tarifs particuliers, unités de vente ou références externes imposées par le commerce.
Microsoft documente les pages et requêtes AL de type API : les pages servent à la lecture et à l’écriture, tandis que les requêtes API exposent des lectures, notamment jointes ou agrégées. Ces objets ne s’étendent pas actuellement comme une page d’interface classique. Un champ manquant demande donc une décision de conception, pas l’ajout supposé d’un paramètre au connecteur.
Préférer un contrat adapté à une ressemblance de représentation
Une API personnalisée peut exposer les données nécessaires avec un contrat indépendant de l’écran. Le partenaire Business Central qualifie les objets AL, les validations et leur maintenance. Le connecteur conserve sa responsabilité de transformation, de journalisation et de rapprochement. Séparez la demande métier de son implémentation : « obtenir la référence commerciale approuvée » est plus durable que « recopier la réponse de telle page ».
OData peut répondre à certains besoins après vérification de l’objet publié et de ses opérations. La comparaison officielle des interfaces Business Central recommande les API REST pour les intégrations et explique les autres modes d’exposition. Choisissez selon le contrat constaté ; un changement de XML vers JSON n’établit aucune équivalence sur les règles commerciales ou les actions exécutées.
Préserver société, identifiant ERP et référence du consommateur
Éviter une correspondance construite sur les seuls libellés
Le chemin de l’ancienne URL, le numéro de client renvoyé et l’identifiant de l’API cible peuvent porter des informations différentes. Construisez une correspondance explicite par environnement et société, puis par objet. Le numéro affiché reste une information métier importante, mais son format ne prouve pas qu’il constitue la bonne clé technique dans toutes les interfaces.
Une référence externe doit conserver sa portée : boutique, système émetteur et type de document si ces dimensions distinguent deux opérations. Inventoriez les normalisations déjà pratiquées par le middleware. Retirer les espaces ou les zéros d’une référence pour faciliter la migration peut supprimer la différence qui permettait précisément de reconnaître deux commandes, deux établissements ou deux séries de pièces.
Le mapping peut conserver une entrée normalisée : société qualifiée, référence client et référence externe de commande. Le payload suivant est un exemple de contrat interne, pas un schéma Microsoft. L’adaptateur assure sa validation puis résout l’identifiant attendu par l’endpoint cible ; un champ obligatoire non couvert arrête le dossier avant création et conserve sa trace dans la file de reprise.
{
"source": "boutique-b2b",
"company": "societe-nord-qualifiee",
"customerReference": "FR-00042",
"externalOrderReference": "WEB-1048",
"commercialSegment": "revendeur-agree"
}Une synchronisation reconnue retrouve ensuite la correspondance du document créé ; elle ne considère pas chaque transport comme une nouvelle intention. L’idempotence du connecteur porte cette reconnaissance, indépendamment d’un retry réseau. Le pipeline conserve la demande d’entrée, l’identité de la pièce de sortie et le motif d’attente, afin que la journalisation relie une relance technique à son effet commercial possible.
Réutiliser les documents déjà connus du connecteur
Avant toute écriture cible, exportez les correspondances dont dépend la reprise : demande source, document ERP, état de traitement et dernière réponse confirmée. Une commande créée avant la bascule reste un dossier ouvert après celle-ci. Sa future livraison ne doit pas déclencher la création d’une commande de remplacement parce que le nouveau connecteur ne reconnaît plus son identifiant.
Paradoxalement, conserver temporairement l’ancienne référence de transport dans le journal reste utile après adoption de la nouvelle API. Elle sert à retrouver l’historique et à expliquer les reprises. Cette conservation n’autorise aucun nouvel appel au service retiré ; elle préserve une preuve de correspondance pendant que les applications adoptent leurs nouvelles clés.
Retrouver les validations avant de remplacer les écritures SOAP
Comparer les résultats visibles dans Business Central
Un test de migration doit relire la pièce produite : client, adresse, devise, unités, prix et lignes conservées. N’utilisez pas uniquement le statut de la réponse comme oracle. Une API peut accepter une donnée qui sera complétée, recalculée ou refusée lors d’une opération ultérieure. L’ADV et le partenaire ERP définissent à quel moment le résultat devient suffisamment stabilisé pour confirmer la commande au site.
Une opération historique portée par une codeunit peut regrouper plusieurs décisions. La remplacer par une succession d’écritures indépendantes change potentiellement la frontière transactionnelle et les états intermédiaires visibles. Demandez quelles validations doivent rester dans l’ERP et quelles transformations appartiennent au middleware. Ne reproduisez pas les règles comptables dans le connecteur pour masquer l’absence d’une action serveur équivalente.
Attribuer le rejet à la bonne étape
Conservez une différence entre demande refusée avant création, document créé avec traitement incomplet et réponse perdue après une écriture possible. Ces états commandent des reprises différentes. Après une interruption, relire un document reconnu par sa correspondance est souvent préférable à répéter sa création. Cette décision exige toutefois une clé de rapprochement effectivement disponible et qualifiée dans votre installation.
Éprouvez aussi les droits du compte d’application sur la société et les objets utilisés. Un parcours réussi avec le compte de l’administrateur ne valide pas le connecteur d’exploitation. La recette utilise l’identité prévue pour le service, et le partenaire ERP vérifie ses permissions. Un refus d’accès doit rester visible ; il ne devient pas un client absent ni une autorisation de création de secours.
Pour les traitements sans utilisateur présent, Microsoft documente l’authentification applicative OAuth 2.0. Le token identifie l’application ; les permissions Business Central déterminent ensuite ce qu’elle peut faire. Qualifiez ces deux niveaux dans la recette du contrat, avec une entrée autorisée et une entrée refusée. La responsabilité du compte, du renouvellement et de la journalisation demeure attribuée lors de la bascule.
Exercice : orienter six contrats sans convertir tous les services de la même manière
Les six contrats suivants sont fictifs et servent à préparer une revue avec le partenaire Business Central. Ils ne constituent ni des objets Microsoft garantis ni un catalogue d’endpoints prêts à appeler. Le choix dépend de l’origine de l’objet, du sens de l’échange et de la couverture démontrée. Lorsque cette couverture manque, la décision reste une qualification à terminer avant de lancer des écritures.
| Contrat | Constat fourni | Décision de préparation |
|---|---|---|
| A — lecture client | Page Microsoft ; champs requis couverts par une API standard | Recetter l’API standard sur la société et les références attendues |
| B — segment commercial | Page Microsoft ; champ spécifique absent de l’API envisagée | Qualifier une exposition AL dédiée avec le partenaire ERP |
| C — état de stocks agrégé | Lecture seule ; couverture standard non démontrée | Étudier une requête API ou une lecture OData adaptée |
| D — validation métier | Codeunit SOAP ; plusieurs effets regroupés | Qualifier une action équivalente ; garder un chantier SOAP distinct |
| E — service personnalisé | Page d’extension ; provenance et maintenance connues | Vérifier son statut et planifier sa migration propre |
| F — export oublié | Origine de l’objet inconnue ; consommateur encore actif | Suspendre le choix d’interface et compléter l’inventaire |
Contrôler une décision reproductible
Le classificateur Python de préparation accompagne cette matrice. Il traite les six descriptions et vérifie des cas incomplets supplémentaires ; il ne dialogue pas avec un ERP. Son intérêt est de refuser une sélection automatique lorsqu’une origine ou une couverture n’est pas qualifiée. Le résultat local doit rester séparé de la recette des endpoints, des permissions et des documents effectivement créés dans l’environnement client.
Par exemple, la revue peut commencer par le contrat A, parce que les conditions fournies rendent l’essai comparable. B exige d’abord une décision sur le champ absent. D demande une lecture de l’action métier, et F interdit de considérer l’inventaire comme terminé. Le nombre de services déplacés n’est donc pas la mesure de réussite ; cherchez les contrats dont la nouvelle exécution produit une réponse explicable.
Dans le contrat B, le seuil d’acceptation de l’API standard est la couverture démontrée de chaque champ obligatoire. Si le segment commercial manque, alors la préparation choisit une spécification dédiée et aucune création n’est autorisée par ce seul résultat. Ce refus conserve la donnée attendue au lieu de déplacer son absence vers une correction après commande.
Dans le contrat F, le seuil préalable est la qualification de l’origine de l’objet. Par exemple, remplacer une origine inconnue par « page Microsoft » pour terminer l’inventaire ferait disparaître précisément l’incertitude à résoudre. Le classificateur maintient donc INVENTORY_REQUIRED lorsque cette origine manque, même si une couverture standard a été déclarée ailleurs ; une hypothèse de compatibilité ne vaut pas une identification de service.
Organiser la coexistence sans laisser deux producteurs créer la même commande
Comparer en lecture avant de changer le producteur d’écriture
La coexistence est utile pour les lectures comparatives, à condition de rapprocher des états pris dans un intervalle maîtrisé. Si le client est modifié entre deux lectures, un écart peut provenir du temps plutôt que du mapping. Conservez le moment des observations et les champs qui doivent être identiques ; examinez séparément les valeurs calculées, les différences de représentation et les changements métier réels.
Pour les écritures, désignez un producteur autorisé par périmètre. L’ancien et le nouveau connecteur ne doivent pas créer simultanément une pièce afin de « comparer » leurs résultats en production. Le candidat peut préparer une demande sans l’exécuter ; une recette séparée permet ensuite de vérifier les effets. La bascule transfère l’autorité d’écriture seulement après fermeture ou attribution des demandes en cours.
Reconnaître la fin d’un transfert d’autorité
Définissez une borne de reprise consultable : dernière demande acceptée par l’ancien flux, demandes encore en attente, première demande confiée au nouveau et correspondances héritées. Une simple heure de déploiement ne suffit pas si les files retardent des opérations. Le support doit pouvoir retrouver qui était autorisé à agir sur une commande au moment où elle a été traitée.
La procédure de retour à l’ancien connecteur n’est valable que si son interface existe encore dans la version concernée. Après retrait du service, revenir au binaire précédent peut laisser la panne intacte. Préparez plutôt l’arrêt des nouvelles écritures, la conservation des demandes et une reprise contrôlée sur l’interface encore disponible. Évaluez ce choix avant la montée de version, avec le responsable ERP.
Recetter les dossiers qui mettent la migration en défaut
Construire des exemples dont la réponse attendue est connue
Retenez des données représentatives autorisées ou anonymisées et fixez leurs résultats avec l’équipe métier. Par exemple, une commande standard teste le raccordement initial ; elle ne couvre pas un tarif particulier ou un compte bloqué. La recette associe chaque entrée à une réponse attendue, puis à une pièce relue dans Business Central. Un exemple sans résultat décidé ne peut pas arbitrer un écart entre les interfaces.
- Un client homonyme existe dans deux sociétés, mais une seule doit recevoir la commande.
- Une information spécifique est obligatoire pour le métier et absente du contrat standard envisagé.
- Une ligne n’est pas admissible alors que les autres données de la commande sont valides.
- La réponse disparaît après une écriture possible et le consommateur réclame une nouvelle tentative.
- Une demande ouverte avant la bascule reçoit une modification après le changement de connecteur.
- Le compte de service perd un droit et le refus doit interrompre l’écriture concernée.
Fermer un écart depuis sa pièce et sa correspondance
Attribuez les écarts de validation au partenaire ERP et les écarts de transformation au responsable du connecteur, sans empêcher une investigation commune. Le journal associe demande, identité de l’application, société et pièce observée. Évitez d’y recopier systématiquement des documents clients complets : les références et les valeurs nécessaires à l’explication suffisent souvent au diagnostic de migration.
Un dossier se ferme quand le résultat attendu est constaté ou lorsque son refus est reconnu comme conforme. Un compteur de réponses réussies ne remplace pas cette décision. Gardez la liste des exceptions connues au démarrage et leur propriétaire : elle permet de distinguer une limitation approuvée d’une anomalie découverte après ouverture du nouveau flux.
Erreurs fréquentes qui transforment la migration en incident commercial
Confondre présence de l’API et équivalence du contrat
Un objet clients disponible dans une API standard ne garantit pas le champ particulier dont dépend votre segmentation tarifaire.
Copier les noms de propriétés et supprimer ce qui manque peut produire une fiche techniquement valide mais commercialement incorrecte. Rendez les absences visibles et faites décider leur traitement avant la migration, plutôt que de remplacer silencieusement les valeurs par des défauts.
Redonner les droits du compte humain au service
Élargir les permissions pour faire disparaître les refus accélère parfois la démonstration et fragilise l’exploitation.
Le connecteur doit conserver un périmètre attribué, compatible avec les sociétés et opérations réellement prises en charge. Faites recetter le refus attendu autant que le parcours autorisé ; un service incapable de s’arrêter proprement n’est pas prêt à traiter des pièces commerciales.
Rejouer une création dont le résultat reste inconnu
Une réponse perdue n’est pas un refus certain de Business Central.
Sans rapprochement, une nouvelle tentative peut créer un document supplémentaire ou déplacer la difficulté vers les contrôles ERP. Préservez la référence source, recherchez l’effet possible et attribuez l’incertitude. La recette doit montrer comment le support tranche ce scénario, y compris lorsque l’interface ne permet pas une recherche suffisamment fiable.
Prévoir un retour vers une interface déjà retirée
Le retour applicatif et le retour fonctionnel sont deux possibilités distinctes.
Restaurer l’ancienne version du middleware ne restaure pas un service absent de Business Central 29. La procédure de continuité doit nommer l’interface disponible, les demandes retenues et les écritures suspendues. Une maintenance annoncée au commerce vaut mieux qu’un redémarrage qui reproduit indéfiniment la même erreur.
Plan d’action : traiter un contrat ERP avant d’étendre la migration
Prioriser par conséquence et disponibilité de la solution
Commencez par les services Microsoft SOAP encore consommés et par les échanges dont l’arrêt bloque la vente ou l’ADV. Parmi eux, choisissez un contrat dont les champs et les effets sont connus. Le responsable ERP fournit la qualification de l’interface cible ; l’équipe d’intégration prépare la transformation et les correspondances. Une démonstration rapide sur un objet mal identifié ne réduit pas le risque de bascule.
Différez les agrégats et les champs spécifiques tant que leur exposition n’est pas décidée. Refusez une création automatique si la reprise ne sait pas retrouver une pièce potentiellement produite. Ces décisions peuvent réduire le périmètre initial sans réduire l’exigence : mieux vaut un premier flux explicable qu’une couverture annoncée de toutes les commandes avec des exceptions impossibles à attribuer.
Mesurer ce que les équipes doivent encore reprendre
Le suivi associe demandes reçues, dossiers reconnus dans l’ERP, refus métier, effets incertains et corrections manuelles. Les seuils d’ouverture dépendent de votre activité ; ils doivent être fixés par les responsables du commerce et de l’ERP avant la recette. Le nombre d’appels REST ne devient pas, par changement de vocabulaire, une preuve de réduction des ressaisies.
Chiffrez la maintenance complète : objet AL éventuel, raccordement, permissions, mise à jour des consommateurs, surveillance et assistance au démarrage. Répartissez clairement la propriété du code et des transformations. La disparition d’une publication SOAP peut faire émerger une dépendance personnalisée ; son coût doit être visible au moment du choix de contrat, pas découvert lors de la prochaine évolution ERP.
Guides complémentaires : objets ERP, contrats et reprise
Retrouver les objets et les notifications Business Central
La présentation des objets et webhooks Business Central aide à délimiter les responsabilités des clients, articles et commandes.
Utilisez cette lecture pour organiser les échanges après qualification de la migration ; les notifications complètent le parcours, sans remplacer le contrôle des données qui autorisent l’écriture.
Conserver un contrat de données lisible par les consommateurs
La méthode de contrat API précise comment documenter les données attendues et les refus exploitables.
Appliquez cette discipline aux différences réellement constatées entre SOAP et la cible : clés, champs spécifiques, validations et réponses utilisées par le système externe.
Préparer la reprise lorsque le transport ne dit pas ce qui a été écrit
Le diagnostic d’un flux API bloqué prolonge la préparation opérationnelle.
Il sert notamment lorsque le nouveau connecteur rencontre une interruption : retrouver la demande, localiser son effet ERP et décider de la reprise avant de déclencher une nouvelle écriture.
Conclusion : moderniser le transport sans perdre le contrat ERP
Business Central 29 impose une décision ciblée sur les services SOAP publiés depuis les pages Microsoft. La première étape est l’identification des objets et de leurs consommateurs. Cette précision évite autant une migration trop étroite, qui oublie un flux utilisé, qu’une refonte générale engagée sur une lecture excessive du retrait annoncé.
Le contrat de remplacement se juge sur les documents et décisions qu’il produit. Les champs spécifiques, la société ERP, les correspondances existantes et les validations doivent être reconnus avant la bascule. Une API disponible devient une solution lorsque sa couverture et sa reprise sont effectivement qualifiées avec le partenaire Business Central.
Le classement des six contrats fictifs prépare cette revue ; il ne certifie aucun environnement client. Une première recette sur un périmètre commercial représentatif donne des preuves plus solides qu’un remplacement systématique des URLs. La continuité reste attribuée : producteur d’écriture, demandes en attente, effets incertains et procédure d’arrêt après retrait de l’ancienne interface.
Dawap accompagne l’intégration API de vos logiciels et de votre ERP pour retrouver ces contrats, adapter les transformations et rendre les reprises vérifiables. Nous travaillons avec votre installateur Business Central sur les objets et règles ERP, afin que l’évolution du connecteur conserve la traçabilité des clients, des commandes et des pièces déjà engagées.
