Сравнение версий

Старая версия 2

changes.mady.by.user Парень Александр

Сохранено

по сравнению с

Новая версия Текущий

changes.mady.by.user Парень Александр

Сохранено

Ключ

  • Эта строка добавлена.
  • Эта строка удалена.
  • Изменено форматирование.

...

...

Оглавление

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-методов.

...

Если приходит код ответа не 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 сек., весь цикл отправки повторяется заново.

...