GetBlock ЭТРАН: обрыв загрузки большого списка вагонов

Когда GetBlock ЭТРАН обрывается на большом списке вагонов, я сначала сравниваю его с небольшим запросом той же справки. Если короткий список проходит, а полный заканчивается ошибкой при получении данных, настройка подключения — уже не единственное направление проверки. Ниже разбираю загрузку дислокации через АСУ–АСУ и разделение списка на отдельные запросы.

Речь о чтении справки 14, а не о создании или подписании перевозочных документов. Способ подходит для интеграции, в которой воспроизводится зависимость сбоя от объёма запроса. Он не устанавливает общий лимит вагонов для ЭТРАНа и не заменяет действующий регламент обмена вашей организации.

Как выглядит обрыв GetBlock ЭТРАН

В клиенте 1С ошибка может возникать на вызове GetBlock. Вложенное сообщение выглядит так:

Ошибка работы с Интернет:
Failure when receiving data from the peer

По одной этой строке нельзя доказать ни неисправность сервера РЖД, ни ошибку провайдера, ни конкретный таймаут платформы. Для описанного способа важен дополнительный признак: получение той же справки с меньшим списком завершается, а большой запрос — нет.

Если от ЭТРАНа пришёл полноценный XML с объяснением отказа, сначала читаю его. Это другая ветка диагностики: коды errorCode и errorStatusCode в ответах АСУ–АСУ нельзя подменять сообщением транспортного клиента.

Что проверяю до изменения загрузчика

Сохраняю исходные настройки интеграции и версию обработки. Для сравнения использую один адрес подключения, одного системного пользователя и одинаковые параметры справки; меняю только список вагонов. В журнале отмечаю число запрошенных вагонов, начало и окончание вызова, наличие полного ответа и текст ошибки. Пароль и содержимое перевозочных документов в диагностический журнал не копирую.

Сначала проверяю небольшой список, затем делю проблемный список на две непересекающиеся части и проверяю каждую отдельно. Если обе части проходят, появляется основание оставить пакетную загрузку. Если одна из них по-прежнему обрывается, одного деления недостаточно: нужно выяснить, зависит ли отказ от размера части или от конкретных данных.

Перед сравнением проверяю, что номера скопированы без лишних символов. Для этой отдельной задачи есть проверка контрольной цифры номера вагона. Правильный номер сам по себе не подтверждает право получать по нему сведения.

Решение: загружаю список частями

Практический обход такого обрыва — несколько запросов вместо одного большого. Фиксированное число вагонов в пакет не подставляю: его подбираю по результатам сравнения в конкретном подключении и с учётом выданных ограничений.

1. Фиксирую исходный список для одного цикла загрузки. У каждого пакета сохраняю свой состав, чтобы при повторе не потерять часть номеров и не запросить другую выборку.
2. Отправляю части последовательно, соблюдая разрешённую частоту обмена. Само разделение не даёт права увеличить число запросов или запустить их одновременно.
3. Сохраняю результат каждого вызова отдельно: получен ответ, возвращён отказ либо произошёл обрыв. Не отмечаю весь цикл успешным после первого удачного пакета.
4. Разбираю каждый корректный ответ и добавляю извлечённые записи в общий набор данных. Два XML-документа не склеиваю простым сложением строк: у каждого свой корневой элемент, служебные поля и результат обработки.
5. При повторной попытке обрабатываю только неудавшийся пакет. Успешно загруженные записи не должны добавляться второй раз; способ обновления выбираю по структуре данных самой интеграции.

Для справки 14 в схеме ASOUP_SC.xsd из комплекта от 27 мая 2022 года предусмотрены массив строк reference14ASU/row, количество объектов amount и отдельный результат returnCode. В этой схеме 0 означает успешное завершение, 4 — отсутствие данных, 12 — ошибку входных параметров. Проверять нужно ответ каждого пакета, а не только факт завершения вызова GetBlock. Для действующего обмена сверяю поля с выданной организации версией схем.

Почему не ограничиваюсь увеличением таймаута

Сравнение с SoapUI полезно, но результат одного клиента нельзя автоматически переносить на другой. Если после изменения времени ожидания SoapUI получает справку, а клиент 1С продолжает обрываться, это ещё не объясняет, на каком участке теряется ответ.

В 1С предусмотрена настройка таймаута операций для WSПрокси и WSОпределения, поэтому утверждение «таймаут в 1С вообще не настраивается» неверно. Но конкретный параметр, единицы измерения и доступный синтаксис проверяю в справке установленной платформы. Произвольное огромное число из чужого примера не заменяет измерение длительности запроса.

Как принимаю результат

После изменения загрузчика проверяю полный цикл, а не одну удачную часть. Для каждого пакета должен быть сохранён результат, а все номера исходного списка — учтены в отправленных запросах. При этом число строк ответа может отличаться от числа запрошенных вагонов: отсутствие данных нужно зафиксировать отдельно, а не скрыть отметкой «загружено».

Ещё одна проверка — повторная обработка уже полученного ответа: она не должна создавать дубли в базе. Если пропущен пакет, потерян ответ или появились повторные записи, загрузку нельзя считать исправленной, даже когда сообщение об обрыве больше не показывается.

Для меня смысл разделения — получить контролируемую загрузку: видно, что отправлено, что вернулось и какую часть нужно повторить. Если перестал проходить даже небольшой запрос, возвращаюсь к диагностике подключения и фактического ответа, а не уменьшаю пакет бесконечно.