SAP Business One : quand l'Integration Service s'arrête sans cesse

Le SAP Business One Integration Service est au cœur des tableaux de bord, du transfert d'événements et d'une grande partie de toutes les connexions à Business One. Lorsqu'il tombe en panne, rien ne s'effondre bruyamment. La plupart du temps, plus rien ne se passe, et cela ne se remarque que lorsque des chiffres manquent. La démarche de diagnostic suivante s'appuie sur la documentation SAP et sur des schémas d'erreurs documentés issus de la SAP Community, et non sur un cas client.

Quels services se cachent derrière l'Integration Service ?

L'Integration Service n'est pas un service unique, mais une chaîne de services Windows interdépendants : l'Integration Service basé sur Tomcat, l'Event Sender, le System Landscape Directory et au moins deux services autour du DIProxy. Quiconque ne regarde que le service portant le nom correspondant cherche la panne au mauvais endroit.

Le document SAP DIProxy Configuration (Integration Framework for SAP Business One, SAP Global Roll-out, octobre 2018, auteur Bo Zhao) distingue clairement les deux services DIProxy. Le DI Proxy Service est « the main service which is listening on port 2099 by default for the DI-API calls ». À ses côtés se trouve le DI Proxy Service Monitor, selon SAP « the daemon service used to restart the DI Proxy automatically when the process stopped unexpectedly ». Cette seconde ligne est la phrase la plus importante du document : SAP fournit un chien de garde, car des plantages inattendus sont prévus.

Le fait que cette infrastructure fasse partie du système, SAP le formule elle-même : « The integration framework for SAP Business One is a Web browser-based solution to design integration flows for exchanging data between different systems », écrit Miriam Rieger, Product and Topic Expert au sein de l'équipe Global Roll-out de SAP, dans le blog central B1if de la SAP Community (14 août 2018, mis à jour en mai 2020, environ 96 100 vues).

Pourquoi le service s'arrête-t-il de manière répétée et pas une seule fois ?

Chez Business One, des arrêts répétés ne sont souvent pas un plantage, mais un redémarrage configuré. Le DIProxy intègre des paramètres qui le relancent selon un calendrier afin de limiter d'éventuelles fuites de mémoire. Qui l'ignore cherche pendant des jours une erreur qui n'existe pas.

• MAXDIERRORS : 50 par défaut dans les installations on-premise, 200 dans les installations cloud. Selon SAP, cette valeur indique « the count of DI-errors that may happen until the DIProxy will be restarted for the sake of potential memory leaking ».
• RESTARTPERIOD : 60 par défaut en on-premise et 0 dans le cloud. Cette valeur est le temps en minutes jusqu'au prochain redémarrage planifié, pour la même raison.
• MAXACCESES : 0 par défaut, donc illimité. SAP avertit qu'un arrêt du DIProxy peut prendre « a very long time » en cas de très nombreux accès simultanés. C'est exactement ce que l'administrateur perçoit comme un service bloqué sur « en cours d'arrêt ».

Pour le diagnostic, c'est donc la fréquence qui compte, pas l'arrêt en lui-même. Une brève disparition toutes les heures correspond à ce qui est attendu avec les valeurs par défaut on-premise. Une disparition toutes les quelques minutes, en revanche, non.

Ce schéma d'erreur est documenté depuis des années. Un utilisateur le décrit brièvement en 2017 : « sap business one integration service is stopping […] it repeats once in a while ». Un fil de discussion de 2011 explique que lors du redémarrage « the service returns an error and status is ‘stopping’ or ‘starting’ » et que le seul moyen fiable d'en sortir est un redémarrage du serveur. Les deux messages restent à ce jour sans réponse publiée (vérifié le 3 août 2026).

Dans quel ordre diagnostiquer la panne ?

L'ordre détermine si vous trouvez la cause ou si vous ne faites qu'écarter le symptôme. Le redémarrage doit venir en dernier, car il détruit les éléments de preuve.

• D'abord la chaîne de services. Vérifiez individuellement l'Integration Service, l'Event Sender et les deux services DIProxy. Un service principal qui redémarre cycliquement alors que le service de surveillance fonctionne est une situation différente d'un service qui ne redémarre plus du tout.
• Augmenter le niveau de journalisation de manière ciblée. Contrôlé via DIProxylog.properties dans le répertoire DIProxy, journaux dans le sous-dossier log. Par défaut : niveau SEVERE, 10 485 760 octets par fichier et trois fichiers. Pour le dépannage, SAP recommande « .level=FINER » avec « java.util.logging.FileHandler.count = 10 ». Avec les réglages par défaut, la cause est depuis longtemps écrasée au bout de quelques jours.
• Uniformiser l'adressage. Le déclencheur le plus souvent cité dans la communauté pour « cannot connect to SAP Business One integration service » est un adressage mixte. Une réponse dans le fil correspondant le résume bien : « Can you Check if you use the same hostname or ip address in SLD landscape directory and in integration service or event sender? » Soit le nom d'hôte partout, soit l'adresse IP partout.
• Vérifier les ports. Le DIProxy écoute par défaut sur le port 2099. S'il se trouve sur un serveur dédié, ce port doit être ouvert. Plusieurs instances nécessitent chacune leur propre port dans diproxyserver.properties.
• Ne redémarrer qu'en dernier recours. Après un changement de profil système, le framework exige de toute façon un redémarrage de l'Integration Service.

Que faut-il inclure dans la surveillance pour détecter la panne avant l'utilisateur ?

La surveillance est réduite à sa plus simple expression à la livraison, ce qui explique que les pannes passent longtemps inaperçues. Selon Log Maintenance in Integration Framework (SAP Global Roll-Out, janvier 2019, autrice Nidhi Singh), le journal des messages n'est pas actif par défaut dans le profil « Productive System ». SAP recommande au maximum le niveau le plus bas, « Infoset », pour les systèmes de production.

La valeur par défaut aux conséquences les plus lourdes se trouve dans la gestion des erreurs : pour les transactions asynchrones, les deux profils appliquent « Retrial after 1 minute and stop processing of following messages ». Un seul message erroné bloque ainsi toute la file d'attente. Le service continue de fonctionner, mais l'intégration est à l'arrêt. C'est l'état dans lequel la surveillance des services indique vert alors qu'aucune donnée n'arrive.

• Surveiller la file d'attente plutôt que le statut du service. Le Queue Monitor est disponible par défaut. Une file d'attente qui ne se vide pas est le signal honnête le plus précoce.
• Journaux détaillés uniquement de manière limitée dans le temps. SAP le formule sans ambiguïté : « We do not recommend enabling detailed logging for an extended period, because it generates large log files for each transaction. » Activer, reproduire l'erreur, exporter, désactiver.
• Évaluer la taille de la base de données. SAP fournit une requête de comptage sur BZSTIDXH et BZSTIDXP dans le schéma IFSERV. Si le type d'enregistrement com.sap.b1i.system.xc.iodata domine, cela indique des transactions qui se répètent constamment, autrement dit une file d'attente bloquée.

Qu'est-ce que cela signifie pour les workflows n8n, Power Automate et RPA ?

Un workflow d'automatisation ne doit pas partir du principe que l'Integration Service fonctionne. Trois précautions coûtent peu à mettre en œuvre si elles sont prévues dès le départ.

• Signaler les erreurs plutôt que les avaler. Une branche qui envoie un message à une personne en cas d'erreur vaut plus qu'une entrée de journal que personne ne lit. Chez NordFlux, nous intégrons systématiquement cette branche dans chaque connexion à Business One, avec un appel de test régulier vers l'interface.
• Réessayer avec un temps d'attente. Une tentative unique échoue à chaque redémarrage d'une minute ; un nombre limité de nouvelles tentatives avec une pause permet de le contourner.
• Construire de manière idempotente. Si une exécution s'interrompt en cours de traitement et redémarre plus tard, un deuxième document ne doit pas être créé. Cela nécessite une clé métier pour la comparaison.

Le bon chemin d'accès à utiliser est présenté dans Connecter SAP Business One : Service Layer, OData et middleware RFC comparés. La question des licences et des outils qui en découle est traitée dans RPA ou SAP Process Automation. Vous trouverez le cadre d'exploitation sur notre page consacrée au conseil SAP Business One.

Questions fréquentes

Pourquoi le SAP Business One Integration Service s'arrête-t-il sans cesse ?

Des arrêts répétés sont souvent configurés et ne constituent pas un défaut. Selon SAP, le DIProxy redémarre après un délai défini (RESTARTPERIOD, 60 minutes par défaut en on-premise) ou après un nombre défini d'erreurs DI (MAXDIERRORS, 50 par défaut en on-premise et 200 dans le cloud). Vérifiez d'abord la fréquence des arrêts par rapport à ces deux valeurs.

Le DIProxy redémarre-t-il automatiquement après un plantage ?

Oui, à condition que le second service fonctionne. SAP installe à cet effet le DI Proxy Service Monitor, qui selon la documentation est « the daemon service used to restart the DI Proxy automatically when the process stopped unexpectedly ». Si ce service ne fonctionne pas, un DIProxy planté reste durablement hors service.

Où trouver les fichiers journaux du DIProxy ?

Dans le sous-dossier log du répertoire DIProxy, contrôlé via DIProxylog.properties. Par défaut : niveau SEVERE, 10 485 760 octets par fichier et trois fichiers. Pour le dépannage, SAP recommande le niveau FINER avec dix fichiers, puis de revenir en arrière ensuite.

Le service fonctionne, mais aucune donnée n'arrive. Quelle en est la cause ?

En général, la file d'attente bloquée. Pour les transactions asynchrones, le réglage par défaut est « Retrial after 1 minute and stop processing of following messages » ; un seul message erroné bloque tous les suivants. Consultez le Queue Monitor et la section des échecs du journal des messages, pas la fenêtre des services.