SAP Business One: wenn der Integration Service ständig stoppt

Auf dem SAP Business One Integration Service setzen Dashboards, Ereignisweiterleitung und ein großer Teil aller Anbindungen an Business One auf. Fällt er aus, bricht selten etwas laut zusammen. Meistens passiert nichts mehr, und das fällt erst auf, wenn Zahlen fehlen. Der folgende Diagnoseweg stützt sich auf die SAP-Dokumentation und auf dokumentierte Fehlerbilder aus der SAP Community, nicht auf einen Kundenfall.

Welche Dienste stecken hinter dem Integration Service?

Der Integration Service ist kein einzelner Dienst, sondern eine Kette voneinander abhängiger Windows-Dienste: der Tomcat-basierte Integration Service, der Event Sender, das System Landscape Directory und mindestens zwei Dienste rund um den DIProxy. Wer nur den Dienst mit dem passenden Namen ansieht, sucht den Ausfall an der falschen Stelle.

Das SAP-Dokument DIProxy Configuration (Integration Framework for SAP Business One, SAP Global Roll-out, Oktober 2018, Autor Bo Zhao) trennt die beiden DIProxy-Dienste sauber. Der DI Proxy Service ist „the main service which is listening on port 2099 by default for the DI-API calls“. Daneben steht der DI Proxy Service Monitor, laut SAP „the daemon service used to restart the DI Proxy automatically when the process stopped unexpectedly“. Diese zweite Zeile ist der wichtigste Satz des Dokuments: SAP liefert einen Wachhund mit, weil unerwartete Abstürze eingeplant sind.

Dass diese Infrastruktur zum System gehört, formuliert SAP selbst: „The integration framework for SAP Business One is a Web browser-based solution to design integration flows for exchanging data between different systems“, schreibt Miriam Rieger, Product and Topic Expert im Global-Roll-out-Team der SAP, im zentralen B1if-Blog der SAP Community (14. August 2018, aktualisiert im Mai 2020, rund 96.100 Aufrufe).

Warum stoppt der Dienst wiederholt und nicht nur einmal?

Wiederholte Stopps sind bei Business One häufig kein Absturz, sondern ein konfigurierter Neustart. Der DIProxy bringt Parameter mit, die ihn planmäßig durchstarten, um mögliche Speicherlecks zu begrenzen. Wer das nicht weiß, sucht tagelang einen Fehler, den es nicht gibt.

• MAXDIERRORS: standardmäßig 50 in On-Premise-Installationen, 200 in Cloud-Installationen. Der Wert beziffert laut SAP „the count of DI-errors that may happen until the DIProxy will be restarted for the sake of potential memory leaking“.
• RESTARTPERIOD: standardmäßig 60 On-Premise und 0 in der Cloud. Der Wert ist die Zeit in Minuten bis zum nächsten planmäßigen Neustart, aus demselben Grund.
• MAXACCESES: standardmäßig 0, also unbegrenzt. SAP warnt, dass ein Herunterfahren des DIProxy bei sehr vielen gleichzeitigen Zugriffen „a very long time“ dauern kann. Genau das sieht der Administrator als Dienst, der auf „wird beendet“ hängt.

Für die Diagnose zählt deshalb die Frequenz, nicht der Stopp selbst. Stündlich kurz weg entspricht bei On-Premise-Standardwerten der Erwartung. Alle paar Minuten weg dagegen nicht.

Das Fehlerbild ist seit Jahren dokumentiert. Ein Anwender beschreibt es 2017 knapp: „sap business one integration service is stopping […] it repeats once in a while“. Ein Thread von 2011 schildert, dass beim Neustart „the service returns an error and status is ‚stopping‘ or ‚starting‘“ und der einzige verlässliche Ausweg ein Serverneustart sei. Beide Beiträge stehen bis heute ohne veröffentlichte Antwort (geprüft am 3. August 2026).

In welcher Reihenfolge diagnostizieren Sie den Ausfall?

Die Reihenfolge entscheidet, ob Sie die Ursache finden oder nur das Symptom wegdrücken. Der Neustart gehört ans Ende, weil er die Beweislage vernichtet.

• Erst die Dienstekette. Integration Service, Event Sender und beide DIProxy-Dienste einzeln prüfen. Ein zyklisch neu startender Hauptdienst bei laufendem Monitor-Dienst ist eine andere Lage als ein Dienst, der nicht mehr hochkommt.
• Log-Level gezielt hochdrehen. Gesteuert über DIProxylog.properties im DIProxy-Verzeichnis, Protokolle im Unterordner log. Voreingestellt sind Level SEVERE, 10.485.760 Byte je Datei und drei Dateien. SAP empfiehlt für die Fehlersuche „.level=FINER“ mit „java.util.logging.FileHandler.count = 10“. Im Standard ist die Ursache nach ein paar Tagen längst überschrieben.
• Adressierung vereinheitlichen. Der in der Community am häufigsten genannte Auslöser für „cannot connect to SAP Business One integration service“ ist gemischte Adressierung. Eine Antwort im entsprechenden Thread bringt es auf den Punkt: „Can you Check if you use the same hostname or ip address in SLD landscape directory and in integration service or event sender?“ Entweder überall der Hostname oder überall die IP-Adresse.
• Ports gegenprüfen. Der DIProxy hört standardmäßig auf 2099. Liegt er auf einem eigenen Server, muss der Port offen sein. Mehrere Instanzen brauchen je einen eigenen Port in diproxyserver.properties.
• Erst zum Schluss neu starten. Nach einem Wechsel des Systemprofils verlangt das Framework ohnehin einen Neustart des Integration Service.

Was gehört ins Monitoring, damit Sie den Ausfall vor dem Anwender sehen?

Das Monitoring ist im Auslieferungszustand dünn, und deshalb bleiben Ausfälle lange unbemerkt. Laut Log Maintenance in Integration Framework (SAP Global Roll-Out, Januar 2019, Autorin Nidhi Singh) ist das Message Log im Profil „Productive System“ standardmäßig nicht aktiv. SAP empfiehlt für Produktivsysteme höchstens die niedrigste Stufe „Infoset“.

Der folgenreichste Standardwert steht in der Fehlerbehandlung: Für asynchrone Transaktionen gilt in beiden Profilen „Retrial after 1 minute and stop processing of following messages“. Eine einzige fehlerhafte Nachricht hält damit die gesamte Warteschlange an. Der Dienst läuft weiter, die Integration steht. Das ist der Zustand, in dem die Dienstüberwachung grün meldet und trotzdem keine Daten ankommen.

• Warteschlange statt Dienststatus überwachen. Der Queue Monitor liegt im Standard vor. Eine Warteschlange, die nicht leerläuft, ist das früheste ehrliche Signal.
• Detailprotokolle nur befristet. SAP formuliert es unmissverständlich: „We do not recommend enabling detailed logging for an extended period, because it generates large log files for each transaction.“ Einschalten, Fehler reproduzieren, exportieren, ausschalten.
• Datenbankgröße auswerten. SAP liefert eine Zählabfrage über BZSTIDXH und BZSTIDXP im Schema IFSERV. Dominiert der Datensatztyp com.sap.b1i.system.xc.iodata, deutet das auf ständig wiederholte Transaktionen hin, also auf die stehende Warteschlange.

Was heißt das für n8n-, Power-Automate- und RPA-Workflows?

Ein Automatisierungs-Workflow darf sich nicht darauf verlassen, dass der Integration Service läuft. Drei Vorkehrungen kosten in der Umsetzung wenig, wenn sie von Anfang an eingeplant sind.

• Fehler melden statt schlucken. Ein Zweig, der im Fehlerfall eine Nachricht an einen Menschen schickt, ist mehr wert als ein Protokolleintrag, den niemand liest. Wir bauen bei NordFlux in jede Business-One-Anbindung genau diesen Zweig ein, zusammen mit einem regelmäßigen Testaufruf gegen die Schnittstelle.
• Wiederholen mit Wartezeit. Ein einmaliger Versuch scheitert an jedem einminütigen Neustart, ein begrenzter Wiederholungsversuch mit Pause überbrückt ihn.
• Idempotent bauen. Bricht ein Lauf mitten in der Verarbeitung ab und startet später erneut, darf kein zweiter Beleg entstehen. Dafür braucht es einen fachlichen Schlüssel zum Abgleich.

Welcher Zugriffsweg der richtige ist, ordnet SAP Business One anbinden: Service Layer, OData und RFC-Middleware im Vergleich ein. Die Lizenz- und Werkzeugfrage dahinter behandelt RPA oder SAP Process Automation. Den Rahmen für den Betrieb finden Sie auf unserer Seite zur SAP Business One Beratung.

Häufige Fragen

Warum stoppt der SAP Business One Integration Service immer wieder?

Wiederholte Stopps sind oft konfiguriert und kein Defekt. Der DIProxy startet laut SAP nach einer festgelegten Zeit neu (RESTARTPERIOD, On-Premise standardmäßig 60 Minuten) oder nach einer festgelegten Zahl von DI-Fehlern (MAXDIERRORS, standardmäßig 50 On-Premise und 200 in der Cloud). Prüfen Sie zuerst die Frequenz der Stopps gegen diese beiden Werte.

Startet sich der DIProxy nach einem Absturz automatisch neu?

Ja, sofern der zweite Dienst läuft. SAP installiert dafür den DI Proxy Service Monitor, laut Dokumentation „the daemon service used to restart the DI Proxy automatically when the process stopped unexpectedly“. Läuft dieser Dienst nicht, bleibt ein abgestürzter DIProxy dauerhaft unten.

Wo finde ich die Logdateien des DIProxy?

Im Unterordner log des DIProxy-Verzeichnisses, gesteuert über DIProxylog.properties. Voreingestellt sind Level SEVERE, 10.485.760 Byte je Datei und drei Dateien. Für die Fehlersuche empfiehlt SAP Level FINER bei zehn Dateien und danach das Zurückstellen.

Der Dienst läuft, aber es kommen keine Daten an. Woran liegt das?

Meist an der angehaltenen Warteschlange. Für asynchrone Transaktionen gilt die Voreinstellung „Retrial after 1 minute and stop processing of following messages“, eine einzelne fehlerhafte Nachricht blockiert alle nachfolgenden. Schauen Sie in den Queue Monitor und in den Failure-Bereich des Message Log, nicht in das Dienste-Fenster.