Le connecteur publie dans votre boutique le stock de la mauvaise société SAP Business One. La référence produit existe des deux côtés, les appels ne remontent pas d’erreur et l’entrepôt découvre la différence à la préparation. Dans un scénario fictif, le worker destiné à la société A retrouve 80 unités appartenant à B, au lieu des 10 attendues. La dernière session ouverte a remplacé celle que ce worker devait utiliser.
La clé du pool doit couvrir le profil de connexion, CompanyDB et l’utilisateur retenu. Un cookie valide pour Service Layer ne démontre pas que votre application l’a sélectionné pour le bon dossier. Lorsque plusieurs sociétés partagent un serveur et un connecteur, l’identité de la session doit rester attachée à l’intention métier, même après un renouvellement ou une réponse de connexion arrivée en retard.
Le diagnostic suit le parcours Login avec CompanyDB et les cookies retournés, puis distingue une session valide, une correspondance locale correcte et une opération ERP effectivement vérifiée. L’exercice reproduit une mauvaise sélection dans un dictionnaire fictif, avant de comparer une alternance A–B–A et plusieurs refus. Il n’appelle pas SAP et ne simule pas son protocole d’authentification.
Notre prestation d’intégration API relie cette isolation au traitement que votre application doit exécuter. Le raccordement SAP Business One se qualifie avec votre installateur ERP : sociétés autorisées, identité applicative, objets disponibles et preuve de lecture, avant de reprendre les publications de stock ou les écritures de commandes.
Pour qui : un connecteur Service Layer qui dessert plusieurs sociétés
Nommer le produit et le parcours d’authentification concernés
Le cas porte sur SAP Business One Service Layer et une connexion ouverte par Login avec CompanyDB. Il ne décrit pas toutes les interfaces SAP, ni le modèle d’accès d’un système S/4HANA. L’installateur confirme l’instance exposée, sa version et les mécanismes admis. Votre adaptateur conserve cette qualification au lieu de reconstruire un endpoint à partir du seul nom SAP.
Une application peut traiter plusieurs sociétés d’un même groupe ou plusieurs clients avec des installations différentes. Dans les deux cas, le profil de connexion doit identifier l’environnement réellement visé. Une société portant le même nom dans une copie de recette et en production ne constitue pas le même contexte. Le connecteur ne doit pas les réunir sous une clé limitée au libellé commercial.
Retrouver le contexte attendu par le travail en file
Le dossier métier fournit une société autorisée et une opération identifiable : consulter une référence produit, rechercher un client ou transmettre une commande. Le worker doit retrouver ce contexte depuis une configuration approuvée. Une propriété reçue dans un message externe ne suffit pas à autoriser l’accès à une autre base. L’association client–profil–société doit rester contrôlée par votre application.
Conservez ce contexte avec le travail mis en queue et la version de son mapping. Si le dossier change de société, cette modification reçoit une décision explicite. La présence d’un SKU commun aux deux entreprises ne rend pas leurs stocks interchangeables. Le contrôle porte donc sur l’origine de la lecture, pas seulement sur la réussite du rapprochement par référence produit.
Anatomie de la session : CompanyDB, B1SESSION et ROUTEID
Lire les rôles des propriétés dans la version actuelle
La référence Service Layer 10.0 décrit Login avec CompanyDB, UserName et Password. Après la connexion, B1SESSION doit accompagner les appels suivants de ce parcours. ROUTEID est optionnel et sert à l’affinité avec le serveur ; il ne remplace pas l’identité de la session.
Le document SAP 10.0, version 1.29 du 27 juillet 2026, confirme cette distinction. Un ancien manuel peut présenter les deux cookies comme obligatoires. La qualification doit donc noter le produit, sa version et la source utilisée, sans transporter une consigne historique vers toutes les installations actuelles.
| Propriété | Rôle dans le parcours | Ce qu’elle ne prouve pas |
|---|---|---|
| CompanyDB | Société demandée à Login | Le contexte choisi par un worker ultérieur |
| UserName | Utilisateur de cette connexion | Les droits sur tous les objets métier |
| B1SESSION | Cookie de session requis dans ce parcours | L’accord avec la société attendue par le dossier local |
| ROUTEID | Affinité serveur optionnelle | Une frontière entre sociétés ou utilisateurs |
| Génération locale | Révision de connexion gérée par l’adaptateur | Un champ natif de la réponse SAP |
Conserver les cookies avec la connexion qui les a produits
Les extraits ci-dessous montrent des valeurs fictives, non utilisables pour se connecter. La même affinité .node0 accompagne ici deux cookies différents. Une variable globale contenant le dernier B1SESSION peut suffire à provoquer la mauvaise sélection. Le composant ouvre A, puis B, et le travail prévu pour A réutilise la dernière valeur conservée. Le problème relève de l’adaptateur : la session sélectionnée peut être cohérente pour B alors que l’intention locale demeure A. Ajouter une relance ne rétablit pas cette correspondance.
Travail A — extrait fictif du champ HTTP :
Cookie: B1SESSION=session-fictive-A; ROUTEID=.node0
Travail B — extrait fictif du champ HTTP :
Cookie: B1SESSION=session-fictive-B; ROUTEID=.node0Lorsqu’un client HTTP utilise un stockage de cookies partagé, vérifiez également comment il répartit les valeurs entre ses contextes. Ne supposez pas que CompanyDB intervient automatiquement dans cette répartition. Le même serveur peut accueillir plusieurs sociétés ; la bibliothèque ne connaît pas nécessairement votre association métier. Une politique d’isolation doit donc être conçue et recettée au niveau du connecteur utilisé.
Construire une clé de pool qui suit le dossier métier
Séparer profil, société et principal applicatif
La clé interne réunit le profil de connexion qualifié, CompanyDB et le principal retenu pour l’opération. Le profil retrouve l’adresse, l’environnement et la version d’interface ; le principal identifie l’utilisateur utilisé par ce parcours. Une session de lecture ne doit pas être choisie depuis le cache d’un autre compte uniquement parce que les deux comptes consultent la même société.
Les secrets restent associés à cette configuration et à ses accès autorisés. Ils ne deviennent pas une propriété transportée dans chaque message du middleware. La révision de configuration permet de retrouver quel contexte avait été préparé pour un travail ancien. Le connecteur doit décider son traitement lors d’un changement d’utilisateur ou de société, plutôt que de lui appliquer silencieusement la connexion disponible.
Vérifier le lien avant de préparer la requête
L’entrée du composant de préparation réunit le contexte attendu, la session candidate et la génération courante. Sa sortie est une préparation REST rattachée au bon cookie ou un refus local. Le seuil d’arrêt est une divergence de profil, de CompanyDB ou d’utilisateur, une session déjà déclarée expirée ou une génération devenue ancienne. La journalisation conserve ce verdict avant l’envoi, sans exposer le cookie dans le dossier partagé.
Cette égalité locale ne certifie pas à elle seule le contenu d’un cookie ni l’instance effectivement jointe. L’association initiale doit être établie lors d’une connexion qualifiée et d’une recette ERP. Ne supposez pas qu’une réponse métier contiendra toujours CompanyDB pour vous permettre de reconstruire la preuve ensuite. Votre protocole doit prévoir comment reconnaître le bon périmètre avec l’installateur.
Empêcher une réponse de Login tardive de remplacer la bonne session
Attribuer une génération au renouvellement local
Par exemple, deux workers peuvent demander une connexion pour le même contexte pendant une interruption. La deuxième réponse peut arriver avant la première. Une affectation sans contrôle laisserait alors le résultat tardif remplacer la session que l’application vient de retenir. Le pool doit connaître la génération qu’il attend, puis refuser un résultat rattaché à une demande locale devenue ancienne.
Cette génération appartient à votre adaptateur et ne doit pas être présentée comme un numéro renvoyé par SAP. Elle permet de retrouver quelle tentative peut mettre à jour le cache du contexte. Le contrat précise la réservation de la génération et la mise à jour conditionnelle. Une implémentation concurrente doit ensuite recetter leur atomicité ; le dictionnaire pédagogique ne démontre pas cette propriété en environnement distribué.
Renouveler A sans invalider les travaux destinés à B
Le renouvellement de A met à jour le seul contexte concerné. La session de B garde son association et son état observé. Une purge globale de tous les cookies peut interrompre plusieurs clients pour réparer une seule connexion. Le support doit retrouver la société affectée et le motif de reprise avant de suspendre les autres travaux ou de fermer leurs sessions.
Une requête déjà envoyée garde cependant son historique. Si son résultat arrive après le changement de génération, l’adaptateur doit encore le rattacher à l’opération engagée ; le renouvellement ne prouve pas que cette requête n’a produit aucun effet. Pour une écriture, l’enquête conserve le document demandé, la société visée et les confirmations disponibles, sans déduire une absence de commande depuis le seul état du cache.
Distinguer une session expirée d’un contexte mal sélectionné
Lire l’expiration selon la configuration de l’installation
La référence SAP décrit une expiration par défaut après 30 minutes sans nouvelle requête, avec un délai configurable. Ce mécanisme d’inactivité ne doit pas être remplacé par l’hypothèse que toute session cesse exactement 30 minutes après sa création. Le partenaire confirme la configuration de l’instance ; votre surveillance conserve les derniers événements et les refus réellement observés.
Le connecteur peut prévoir une politique locale de revalidation, mais il doit la distinguer du comportement natif. Dans le banc, le marqueur observed_expired est une observation fictive déjà fournie. Le programme ne calcule pas une durée SAP depuis l’horloge et n’essaie aucun cookie distant. Il vérifie seulement que la préparation refuse une session dont l’expiration est déjà déclarée dans ce dossier.
Conserver l’origine du refus avant de relancer Login
Un défaut réseau, un refus d’un intermédiaire et une erreur native de session n’ont pas la même origine. Le support retrouve l’émetteur de la réponse avant de décider le renouvellement. Une session sélectionnée pour la mauvaise société demande la correction du pool, même lorsqu’elle reste valide ; une perte de réponse après une écriture demande également la recherche du résultat métier.
Le retry et son backoff suivent donc une décision qualifiée. Relancer tous les Login à chaque refus accroît la concurrence sur le cache et peut masquer le défaut initial. La journalisation conserve le contexte, le motif et la génération, avec des cookies masqués. Elle permet de distinguer l’attente d’une connexion et la reprise d’une commande, qui ne se ferment pas sur la même preuve.
Atelier : reproduire une mauvaise société puis isoler les sessions
Comparer le dernier cookie et un pool par contexte
Le programme local de sélection des sessions utilise deux sociétés fictives sur un profil de production fictif. Un dictionnaire associe leurs cookies pédagogiques à des marqueurs de société et aux quantités 10 et 80. Ces marqueurs ne sont pas des propriétés d’une réponse native SAP. Aucun Login, appel HTTP ou accès ERP n’est exécuté.
Exécutez python3 session_inventory.py avec Python 3.10 ou supérieur. La première séquence conserve uniquement le dernier cookie et retrouve B pour un travail destiné à A. La seconde sélectionne les sessions dans un pool séparé et retrouve les quantités 10, 80, 10 sur l’alternance A–B–A. Elle prouve ce choix local dans nos fixtures, sans certifier une lecture distante.
| Scénario fictif | Observation locale | Décision du banc |
|---|---|---|
| Dernier cookie partagé | A retrouve le marqueur et les 80 unités de B | Reproduction de la mauvaise sélection |
| Pool séparé, A–B–A | Quantités 10, 80, 10 | Correspondance locale retrouvée |
| Session d’une autre société | Contexte B fourni pour A | Revoir le périmètre avant l’appel |
| Autre profil de connexion | Recette fournie pour production | Revoir le profil |
| Autre utilisateur | Principal différent du contexte demandé | Revoir l’identité retenue |
| ROUTEID sans B1SESSION | Cookie de session absent | Refuser la préparation |
| Expiration déjà observée | Marqueur fictif déclaré | Refuser cette session |
| Réponse de connexion tardive | Ancienne génération de A après la nouvelle | Refuser son remplacement et conserver B |
Délimiter les vingt et un contrôles exécutés
Les 21 contrôles passent : inscription des deux sessions, reproduction de la mauvaise sélection, alternance des lectures fictives, refus des trois contextes divergents, absence de cookie, expiration déclarée et gestion des générations. Les vérifications finales conservent la session de B, autorisent le cas local sans ROUTEID et confirment que les entrées anciennes n’ont pas été modifiées.
Le résultat nominal porte le nom LOCAL_BINDING_READY_NOT_SAP_VALIDATED. Le dictionnaire ne traite ni certificat, ni permissions, ni authentification réelle et ne reproduit pas un protocole SAP. Le refus d’un ancien résultat est une politique de cache de cet exercice. Une implémentation multi-processus doit encore valider réservation et mise à jour atomiques, puis les opérations réelles dans son environnement de recette.
Recetter la société réellement lue avant de publier le stock
Choisir un témoin qui distingue les installations
En réalité, une session valide peut fournir une réponse cohérente pour B tout en contredisant le travail prévu pour A. Une référence produit commune ou une quantité égale ne suffit donc pas à reconnaître la société. L’installateur et l’équipe métier choisissent une lecture témoin prise en charge, ses valeurs attendues et le moyen de retrouver son origine dans le parcours utilisé.
Cette lecture reste limitée aux contextes autorisés de la recette. Le dossier conserve le profil, la société demandée, l’utilisateur et le retour observé, avec les traces non sensibles nécessaires. Si le témoin n’est pas disponible ou si son interprétation reste ambiguë, l’équipe qualifie une autre preuve avant d’étendre les publications. Elle ne choisit pas la réponse qui semble la plus vraisemblable pour faire repartir le stock.
Éprouver l’alternance et les renouvellements du connecteur réel
Jouez A–B–A dans l’adaptateur de recette et comparez les contextes retrouvés. Rejouez ensuite le renouvellement de A pendant un travail de B, une réponse de connexion tardive et un refus de session. Chaque sortie doit retrouver son intention initiale. Le test distant porte aussi sur les droits de lecture et sur le contrat de réponse effectivement exposé par l’installation.
Le seuil d’arrêt est atteint lorsqu’une réponse appartient à un autre contexte ou lorsque son origine ne peut plus être établie. La dernière quantité confirmée conserve son âge ; la politique de fraîcheur décide si elle peut encore alimenter la boutique. Le pool corrigé ne requalifie pas automatiquement les quantités publiées pendant l’incident. Elles restent à rapprocher avec leurs dossiers et leurs consommateurs.
Retrouver les effets engagés dans la mauvaise société
Séparer lecture contaminée et écriture déjà envoyée
Une quantité lue dans B peut avoir modifié une promesse de stock dans la boutique de A. Une commande envoyée avec la mauvaise session peut demander une autre enquête. Le middleware retrouve les dossiers, leurs références externes et les observations conservées. Il distingue les lectures utilisées par un consommateur et les transmissions dont un effet ERP a pu être engagé.
Le rapprochement ne doit pas commencer par une suppression globale des documents qui paraissent suspects. L’ADV et l’installateur qualifient la société, l’objet et son état avant de choisir la correction permise. Une annulation, une compensation ou un rejeu restent des décisions métier. Le changement de cookie ne démontre ni l’absence du premier document ni la réversibilité de son traitement.
Préserver l’intention et l’identité des commandes incertaines
L’idempotence d’une écriture concerne la commande et son périmètre, pas seulement la session qui transporte la requête. Le contrat conserve en entrée société, opération, référence et payload qualifié. Après un timeout, la recherche du résultat doit reprendre le contexte réellement utilisé lors de l’envoi. Chercher uniquement dans la société attendue peut laisser un document créé ailleurs sans décision.
Le journal relie ces observations à une corrélation interne, par exemple un correlationId. Les cookies, mots de passe et jetons restent masqués dans les traces partagées. Le runbook décrit les accès nécessaires à l’enquête et les responsabilités de correction. Le support peut ainsi retrouver l’intention, l’appel et le document observé sans demander une extraction improvisée de tous les secrets du connecteur.
Erreurs fréquentes : remplacer l’isolation par un indice rassurant
Utiliser le nœud serveur comme une identité de société
Deux sessions peuvent partager la même valeur d’affinité tout en appartenant à des contextes différents. Le banc utilise volontairement .node0 pour A et B afin que cette ressemblance ne serve pas au choix. ROUTEID ne devient pas la clé de société. Lorsqu’il est présent, conservez-le avec la session qui l’a fourni selon le parcours qualifié ; n’assemblez pas les cookies depuis deux connexions indépendantes.
Une autre erreur groupe toutes les connexions sous le nom de l’hôte ou sous le seul utilisateur integration-reader. Le même nom d’utilisateur peut participer à plusieurs contextes dans votre configuration. La clé doit retrouver le profil et CompanyDB. Si plusieurs comptes portent des responsabilités différentes, l’équipe doit également préserver leur distinction avant de déterminer leurs accès avec le partenaire ERP.
Vider tous les caches et considérer la réparation terminée
Une purge globale peut faire disparaître temporairement la mauvaise sélection sans corriger sa cause. Dès que deux sociétés se reconnectent, la variable partagée reproduit le mélange. Le correctif doit retrouver le lieu de stockage et les consommateurs qui l’utilisent. La recette couvre leur alternance et la concurrence sur le contexte, au-delà d’une connexion isolée réussie après redémarrage.
Un signal faible apparaît lorsque l’écart suit l’ordre des traitements ou le dernier client connecté. Un autre apparaît quand un incident revient seulement après le renouvellement des sessions. Le monitoring rapproche ces dossiers à leurs profils et à leurs générations locales. Une hausse de relances ne doit pas être interprétée comme une expiration native universelle lorsque les traces montrent surtout des contextes substitués.
Plan d’action : isoler les connexions et fermer les dossiers affectés
Inventorier les connexions et attribuer leurs consommateurs
Le mainteneur retrouve les profils, les sociétés et les utilisateurs utilisés par le connecteur. Il examine le stockage des sessions, le client HTTP et les workers qui préparent les appels. L’installateur ERP qualifie l’interface, les droits et une lecture témoin. L’équipe métier retrouve les stocks et les commandes dont l’origine doit encore être vérifiée après l’incident.
Le schéma de configuration décrit le contexte admis, les secrets associés et la politique de renouvellement. Le contrat d’échange précise comment ce contexte reste attaché au dossier en file. Le plan priorise la mauvaise sélection et la preuve de société, puis les dossiers déjà consommés. Les extensions vers d’autres clients attendent la recette de cette frontière, sans être financées depuis le seul taux de réponses reçues.
Fixer l’acceptation, la priorité de reprise et le repli
La priorité dépend du délai avant lequel une quantité ou une commande influence votre préparation. Une lecture de référence descriptive peut attendre davantage qu’une publication qui ouvre une vente. Le pilote doit couvrir A–B–A, une connexion tardive, une expiration observée et un contexte refusé. La procédure retrouve, pour chaque cas, le résultat attendu et les observations encore nécessaires à sa fermeture.
Le repli suspend les publications ou les écritures du périmètre affecté et conserve les dossiers engagés. Il garde les autres sociétés actives seulement lorsque leur isolation est établie. L’acceptation demande une origine explicable pour chaque sortie du pilote et une reprise réalisée avec les accès du remplaçant. Une session renouvelée ne ferme pas les commandes dont le résultat reste incertain.
- À retrouver : profil, CompanyDB, utilisateur et origine de la session sélectionnée.
- À valider : l’alternance des sociétés et la mise à jour conditionnelle des générations locales.
- À conserver : les opérations déjà envoyées et leur contexte effectif.
- À refuser : une publication dont la société source reste ambiguë.
Lectures complémentaires : périmètre ERP, contrat et investigation
Relier l’isolation au parcours vendu et à ses objets
Le dossier éditeur SaaS : connecter votre logiciel à l’ERP client prépare les responsabilités d’activation et le périmètre du connecteur. L’isolation des sessions complète ce parcours lorsqu’une même application dessert plusieurs clients ou sociétés, avec des configurations qui doivent rester séparées.
Le parcours Shippingbo et SAP Business One relie les objets ERP et logistiques avec l’installateur. Il traite les quantités et les pièces du parcours de livraison ; une session correctement sélectionnée ne remplace pas la qualification de ces objets et de leurs validations métier.
Retrouver une intention après une interruption
Le contrat d’échange ERP–e-commerce organise les correspondances et les reprises. Pour ce connecteur, la société doit rester une dimension du dossier et de la recherche du résultat, au lieu de disparaître derrière une référence de commande commune à plusieurs environnements.
Le runbook d’incident API structure les observations et la passation. Le support doit ici retrouver le contexte attendu, la session sélectionnée et le dernier effet confirmé, puis attribuer la correction sans purger les preuves nécessaires au rapprochement.
Conclusion : un cookie valide ne choisit pas la société de votre dossier
Le parcours Login définit une société et un utilisateur. L’adaptateur doit conserver cette association pour chaque travail, avec un profil de connexion qualifié. Le cookie d’affinité ne remplace pas cette identité et la dernière session ouverte ne devient pas le contexte de tous les workers.
La génération locale protège la mise à jour du cache contre une connexion devenue ancienne. Elle ne démontre pas le résultat d’un appel déjà envoyé. La recette retrouve la société effectivement lue et les opérations qui demandent encore leur propre rapprochement.
Les huit scénarios et 21 contrôles éprouvent notre sélection dans des données fictives, sans HTTP ni validation SAP. L’implémentation réelle doit encore établir ses associations, ses droits et son comportement concurrent avec l’installation du client.
Dawap accompagne le raccordement de vos logiciels par API avec votre partenaire ERP. Nous qualifions les contextes, les lectures et les reprises pour que vos équipes retrouvent la bonne société avant de publier son stock ou de transmettre une nouvelle commande.
