SAP Business One: когда Integration Service постоянно останавливается

SAP Business One Integration Service лежит в основе дашбордов, пересылки событий и значительной части всех подключений к Business One. Когда он выходит из строя, редко что-то ломается с шумом. Чаще всего просто ничего больше не происходит, и это замечают только тогда, когда не хватает данных. Приведённый ниже путь диагностики основан на документации SAP и на задокументированных картинах ошибок из SAP Community, а не на случае конкретного клиента.

Какие службы стоят за Integration Service?

Integration Service — это не одна служба, а цепочка взаимозависимых служб Windows: Integration Service на базе Tomcat, Event Sender, System Landscape Directory и как минимум две службы, связанные с DIProxy. Тот, кто смотрит только на службу с подходящим названием, ищет причину сбоя не там.

Документ SAP DIProxy Configuration (Integration Framework for SAP Business One, SAP Global Roll-out, октябрь 2018, автор Бо Чжао) чётко разграничивает две службы DIProxy. DI Proxy Service — это «the main service which is listening on port 2099 by default for the DI-API calls». Рядом с ним есть DI Proxy Service Monitor, по данным SAP «the daemon service used to restart the DI Proxy automatically when the process stopped unexpectedly». Эта вторая строка — самое важное предложение документа: SAP поставляет сторожевого пса, потому что неожиданные сбои учтены заранее.

О том, что эта инфраструктура является частью системы, говорит сама SAP: «The integration framework for SAP Business One is a Web browser-based solution to design integration flows for exchanging data between different systems», — пишет Мириам Ригер, Product and Topic Expert в команде Global Roll-out SAP, в центральном блоге B1if SAP Community (14 августа 2018 года, обновлено в мае 2020 года, около 96 100 просмотров).

Почему служба останавливается повторно, а не всего один раз?

Повторные остановки в Business One часто являются не сбоем, а настроенным перезапуском. DIProxy имеет параметры, которые перезапускают его по расписанию, чтобы ограничить возможные утечки памяти. Тот, кто этого не знает, днями ищет ошибку, которой не существует.

• MAXDIERRORS: по умолчанию 50 в локальных установках, 200 в облачных установках. По данным SAP, это значение обозначает «the count of DI-errors that may happen until the DIProxy will be restarted for the sake of potential memory leaking».
• RESTARTPERIOD: по умолчанию 60 в локальных установках и 0 в облаке. Это значение — время в минутах до следующего планового перезапуска по той же причине.
• MAXACCESES: по умолчанию 0, то есть без ограничений. SAP предупреждает, что завершение работы DIProxy при очень большом числе одновременных обращений может занять «a very long time». Именно это администратор видит как службу, зависшую в состоянии «останавливается».

Для диагностики важна не сама остановка, а её частота. Кратковременное исчезновение раз в час соответствует ожиданиям при стандартных локальных значениях. А вот исчезновение каждые несколько минут — нет.

Эта картина ошибки задокументирована уже много лет. Один пользователь кратко описал её в 2017 году: «sap business one integration service is stopping […] it repeats once in a while». Ветка форума от 2011 года описывает, что при перезапуске «the service returns an error and status is ‘stopping’ or ‘starting’» и что единственный надёжный выход — перезапуск сервера. Обе записи до сих пор остаются без опубликованного ответа (проверено 3 августа 2026 года).

В каком порядке диагностировать сбой?

Порядок определяет, найдёте ли вы причину или просто уберёте симптом. Перезапуск должен быть в конце, поскольку он уничтожает доказательства.

• Сначала цепочка служб. Проверьте по отдельности Integration Service, Event Sender и обе службы DIProxy. Основная служба, циклически перезапускающаяся при работающей службе мониторинга, — это другая ситуация, чем служба, которая больше не запускается.
• Целенаправленно повысить уровень логирования. Управляется через DIProxylog.properties в каталоге DIProxy, журналы — в подпапке log. По умолчанию: уровень SEVERE, 10 485 760 байт на файл и три файла. Для поиска ошибок SAP рекомендует «.level=FINER» с «java.util.logging.FileHandler.count = 10». При стандартных настройках причина через несколько дней уже давно перезаписана.
• Унифицировать адресацию. Наиболее часто упоминаемая в сообществе причина ошибки «cannot connect to SAP Business One integration service» — смешанная адресация. Один ответ в соответствующей теме формулирует это прямо: «Can you Check if you use the same hostname or ip address in SLD landscape directory and in integration service or event sender?» Либо везде имя хоста, либо везде IP-адрес.
• Проверить порты. DIProxy по умолчанию слушает порт 2099. Если он находится на отдельном сервере, этот порт должен быть открыт. Каждому из нескольких экземпляров нужен собственный порт в diproxyserver.properties.
• Перезапуск — только в самом конце. После смены системного профиля фреймворк в любом случае требует перезапуска Integration Service.

Что должно входить в мониторинг, чтобы вы увидели сбой раньше пользователя?

Мониторинг из коробки довольно скудный, поэтому сбои долго остаются незамеченными. Согласно Log Maintenance in Integration Framework (SAP Global Roll-Out, январь 2019, автор Нидхи Сингх), журнал сообщений в профиле «Productive System» по умолчанию не активен. SAP рекомендует для продуктивных систем не выше самого низкого уровня «Infoset».

Стандартное значение с самыми серьёзными последствиями находится в обработке ошибок: для асинхронных транзакций в обоих профилях действует «Retrial after 1 minute and stop processing of following messages». Из-за этого одно-единственное некорректное сообщение останавливает всю очередь. Служба продолжает работать, а интеграция стоит на месте. Это состояние, при котором мониторинг служб сообщает «зелёный» статус, хотя данные не поступают вообще.

• Следить за очередью, а не за статусом службы. Queue Monitor доступен по умолчанию. Очередь, которая не разгружается, — самый ранний честный сигнал.
• Подробные журналы — только на ограниченное время. SAP формулирует это однозначно: «We do not recommend enabling detailed logging for an extended period, because it generates large log files for each transaction.» Включить, воспроизвести ошибку, экспортировать, выключить.
• Оценить размер базы данных. SAP предоставляет запрос подсчёта по BZSTIDXH и BZSTIDXP в схеме IFSERV. Если преобладает тип записи com.sap.b1i.system.xc.iodata, это указывает на постоянно повторяющиеся транзакции, то есть на застрявшую очередь.

Что это значит для workflow в n8n, Power Automate и RPA?

Workflow автоматизации не должен полагаться на то, что Integration Service работает. Три меры предосторожности стоят немного, если их предусмотреть с самого начала.

• Сообщать об ошибках, а не замалчивать их. Ветка, которая при ошибке отправляет сообщение человеку, ценнее записи в журнале, которую никто не читает. В NordFlux мы встраиваем именно такую ветку в каждое подключение к Business One вместе с регулярным тестовым вызовом интерфейса.
• Повторять попытки с задержкой. Единственная попытка неизбежно натыкается на очередной минутный перезапуск, а ограниченное число повторов с паузой позволяет его пережить.
• Строить идемпотентно. Если выполнение прерывается посреди обработки и позже запускается заново, второй документ возникнуть не должен. Для этого нужен бизнес-ключ для сверки.

Правильный способ подключения рассматривается в статье Подключение SAP Business One: сравнение Service Layer, OData и RFC-middleware. Связанный с этим вопрос лицензий и инструментов рассматривается в статье RPA или SAP Process Automation. Рамки для эксплуатации вы найдёте на нашей странице про консалтинг по SAP Business One.

Часто задаваемые вопросы

Почему SAP Business One Integration Service постоянно останавливается?

Повторные остановки часто являются настройкой, а не дефектом. По данным SAP, DIProxy перезапускается через заданное время (RESTARTPERIOD, по умолчанию 60 минут в локальной установке) или после заданного числа ошибок DI (MAXDIERRORS, по умолчанию 50 в локальной установке и 200 в облаке). Сначала проверьте частоту остановок относительно этих двух значений.

Перезапускается ли DIProxy автоматически после сбоя?

Да, при условии, что работает вторая служба. Для этого SAP устанавливает DI Proxy Service Monitor, который, согласно документации, представляет собой «the daemon service used to restart the DI Proxy automatically when the process stopped unexpectedly». Если эта служба не работает, аварийно завершившийся DIProxy остаётся неработающим постоянно.

Где найти файлы журналов DIProxy?

В подпапке log каталога DIProxy, управляется через DIProxylog.properties. По умолчанию: уровень SEVERE, 10 485 760 байт на файл и три файла. Для поиска ошибок SAP рекомендует уровень FINER с десятью файлами, а затем возврат к исходным настройкам.

Служба работает, но данные не поступают. В чём причина?

Обычно причина — остановленная очередь. Для асинхронных транзакций по умолчанию действует настройка «Retrial after 1 minute and stop processing of following messages»: одно-единственное некорректное сообщение блокирует все последующие. Загляните в Queue Monitor и в раздел ошибок журнала сообщений, а не в окно служб.