Основные рекомендации экспорта чеков по топологиям:

• Set Centrum (в центральном офисе) ↔ Кассы (в магазинах)
• Set Centrum (в центральном офисе) ↔ Set Retail (в магазинах) ↔ Кассы (в магазинах)

Web-сервис на стороне SetRetail10

(Сервер - Клиент): SetRetail10-сервер и ERP-клиент.

Процесс:

• ERP запрашивает данные в SetRetail10 по набору параметров.
  • Например: все чеки за операционный день, или все чеки по конкретному магазину за операционный день.
• Набор параметров описан в отдельном разделе.
• Можно запрашивать только не выгруженные чеки, то есть, те чеки, которые ещё не отправлялись в ERP или все чеки, имеющиеся в SetRetail10 по заданным параметрам.

Web-сервис на стороне ERP

(Клиент - Сервер): SetRetail10-клиент и ERP-сервер.

Процесс:

• SetRetail10 с заданной периодичностью формирует пакет с чеками в формате XML и вызывает метод на стороне EPR, передавая в качестве параметра эту XML. в данном случае передаются только не отправленные в ERP чеки, т.е. новые.
• Большинство клиентов (торговых сетей) используют этот вариант для получения чеков и других документов.
• В некоторых ERP организуется проверка полноты загрузки данных в ERP.
  • Например: при получении в конце операционного дня всех Z-отчётов (закрытых кассовых смен) делается сверка по сумме и по количеству чеков из Z-отчётов, с суммами и количеством чеков полученных методом экспорта чеков.
• Если суммы не совпадают, то ERP может перезапросить все чеки за указанную смену используя 2-й вариант экспорта (Web-сервис на стороне SetRetail10), указав в качестве параметров:
  • операционный день;
  • магазин;
  • кассу;
  • номер смены.

Гарантированная доставка

Оба варианта экспорта данных работают через HTTP-протокол с использованием вызова SOAP-методов.

Во 2-ом типе экспорта, когда отправляются чеки в Web-сервис на стороне ERP есть 2 варианта получения ответа:

Устанавливается настройкой в SetRetail10: Справочники → Внешние процессинги → добавляется Протокол Set Retail 10: выгрузка данных в веб-сервис на стороне ERP → в настройках протокола вкладка Адрес веб-сервиса → установите переключатель Веб-сервис с обратной связью или Веб-сервис без обратной связи (совместимость с SAP).

• Вариант 1 - получать от сервера код ответа response HTTP = 200 при успешной обработке пакета
  • В случае с кодом HTTP = 200, гарантия доставки обеспечивается на уровне HTTP-протокола, то есть, по кодам ответов на вызов метода между сервером и клиентом.
• Вариант 2 - дожидаться ответа response в заданном WSDL-формате XML: <result>true</result>
  • В формате xml дожидаемся ответ со значениями true или false. На основе ответа значения делается вывод получил ли сервер наш пакет или нет. Если нет повторяем выгрузку.

При успешном завершении обработки пакета от SetRetail10, сервер (ERP) присылает ответ HTTP = 200 - значит пакет он принят успешно.

Если приходит код ответа не 200, или ответ не получен в заданный таймаут, то это ошибка, и тогда выгрузку этого пакета будет повторяться.

Пример кейса

1. Между серверами SetRetail10 и ERP настройкой устанавливается таймаут соединения - 60 сек (настройка в базе данных set → таблица sales_management_properties → export.set10wsclient.purchases.request.timeout).
2. На сервер SetRetail10 с касс отправляется 150 чеков. Их идентификаторы помещаются в очередь в таблицу на сервере в БД.
3. SetRetail10 раз в минуту (настройка в базе данных set → таблица sales_management_properties → export.set10wsclient.purchases.polling.interval.sec) формирует XML из 100 чеков (настройка в базе данных set → таблица sales_management_properties → export.set10wsclient.purchases.catalog.size.records), и запоминает их идентификаторы (в памяти).
4. SetRetail10 вызывает метод getPurchase на стороне ERP и передаёт XML-данные с чеками.
5. В ERP-обработчике этого метода должно быть реализовано сохранение этого пакета в свою базу (или иная обработка).
6. Если сохранение прошло успешно за 1 минуту, то при стандартном завершении метода Web-сервиса сервер отправит клиенту код ответа HTTP = 200.
7. SetRetail10 при получении кода ответа HTTP = 200 удаляет идентификаторы чеков из очереди запомненные на этапе 3, и сразу формирует пакет по оставшимся чекам в очереди (без задержек).
   1. Если сохранение произойдет не корректно, внутренняя база данных не будет доступна, или произойдёт ошибка при разборе пакета, то сервер (ERP) может отправить в ответ код ответа HTTP = 5xx.
   2. Если сохранение не произойдёт за 1 минуту, то и сервер и клиент поймут что XML-данные не сохранились. Клиент уже не будет дожидаться ответа по этому запросу.
8. SetRetail10, не дождавшись в заданный период ответа, или получив от сервера код ответа не HTTP = 200:
   1. Записывает в лог ошибку, полученную от сервера или ошибку таймаута,
   2. Удаляет из памяти идентификаторы недоставленных чеков, тем самым, оставляя их в очереди на отправку в БД.
   3. "Замирает" на заданную паузу (60 сек).
9. Через 60 сек., весь цикл отправки повторяется заново.

Проблему в передаче данных можно определить либо по неубывающей очереди новых чеков, либо по логам с ошибками с помощью отдельных инструментов, например датчики в системе Zabbix.