Веб-сервис на стороне сервера Set10

Веб-сервис экспорта чеков (на стороне SetRetail10) - методы getNewPurchases(…) и getNewFullPurchases(…)

Оптимальное значение параметров:

• export.webservice.new.purchases.batch.size - 100

Настройка loyal.result.sending.toerpi

Поведение зависит от вызываемого WS-метода:

• getNewPurchasesByOperDay / getNewPurchasesByParams: настройка loyal.result.sending.toerpi не учитывается. Чеки возвращаются всегда, независимо от наличия транзакции лояльности.

  • Если транзакция лояльности к моменту запроса уже поступила, она будет приложена к чеку;

  • если нет, чек вернётся без неё (с null). Блокировки или пропуска чеков не происходит.

• getNewFullPurchasesByOperDay: настройка учитывается:

  • true: если у чека hasloytransaction = true, но транзакция лояльности ещё не поступила, чек исключается из ответа. Он будет возвращён при следующем запросе, когда транзакция появится.

  • false: все чеки возвращаются без ожидания транзакции лояльности. Поле hasloytransaction при формировании выборки игнорируется.

По умолчанию: false.

Алгоритм работает следующим образом:

1. Внешняя система обращается на один из методов getNewPurchases(…) и getNewFullPurchases(…) на сервер Set10 по SOAP.

2. Сервер Set10 проверяет статус чеков, есть ли чеки с отсутствием статуса отправки во внешнюю систему accepted_by_ws = false.

   1. Если у чека есть признак наличия транзакции лояльности hasloytransaction = true, но при этом самой транзакции лояльности в модуле ERPI ещё нет, чек в выборку не попадает.

3. Если неотправленные чеки найдены, сервер Set10 проверяет настройку export.webservice.new.purchases.batch.size.

4. Если настройка имеет значение 0, сервер отдаст в одной пачке все неотправленные чеки.

5. Если настройка имеет значение больше 0 (например, 100), сервер Set10 сформирует пачку с чеками до 100 в одной XML, затем отдаст следующую пачку по запросу от внешней системы.

Open

Веб-сервис на стороне ERP

Веб-сервис с обратной связью (совместимость с 1С)

Веб-сервис экспорта чеков (на стороне ERP) - метод processPurchases

Оптимальное значение параметров:

• export.set10wsclient.purchases.polling.interval.sec = 60

• export.set10wsclient.purchases.db.portion.size.records = 1000 (если требуется ускорить отправку, параметр можно увеличить вплоть до 5000).

• export.set10wsclient.purchases.catalog.size.records = 100 (если требуется ускорить отправку, параметр можно увеличить вплоть до 1000).

• export.set10wsclient.purchases.short.interval.ms = 5000 (если требуется ускорить отправку, параметр можно сократить вплоть до 10 мс).

• export.set10wsclient.purchases.request.timeout = 60000 (если внешняя система не успевает принять размер пачки за 60 секунд, параметр можно увеличить на необходимое значение).

Настройка loyal.result.sending.toerpi

Параметр loyal.result.sending.toerpi определяет, нужно ли дожидаться транзакции лояльности перед выгрузкой чека в ERP:

• true: чеки с признаком hasloytransaction = true, для которых транзакция лояльности ещё не получена, не включаются в очередь на отправку. Очередь не блокируется: такие чеки пропускаются, остальные продолжают выгружаться в штатном порядке (FIFO). Фильтрация выполняется на двух уровнях: на уровне SQL-запроса (условие p.hasloytransaction = FALSE OR loy.id IS NOT NULL) и дополнительно на уровне Java-кода. Как только транзакция лояльности поступит, чек попадёт в следующую выборку.

• false: все чеки выгружаются без ожидания транзакции лояльности. Чек отправляется в ERP сразу, как только он готов.

По умолчанию: false.

Алгоритм работает следующим образом:

1. Согласно параметру export.set10wsclient.purchases.polling.interval.sec, один раз в указанное количество секунд проверяется наличие очереди чеков на отправку.

2. При появлении чеков в очереди выполняется их выборка из базы данных и загружается в память, их количество не более чем указано в параметре export.set10wsclient.purchases.db.portion.size.records.

   1. Если у чека есть признак наличия транзакции лояльности hasloytransaction = true, но при этом самой транзакции лояльности в модуле ERPI ещё нет, чек в выборку не попадает.

3. Из выбранных чеков выполняется упаковка чеков в пакет для отправки по SOAP, размером не более, чем указано в параметре export.set10wsclient.purchases.catalog.size.records.

4. Отправка на указанный URL веб-сервиса выполняется раз в интервал, указанный в параметре export.set10wsclient.purchases.short.interval.ms.

5. При отправке сервер выжидает таймаут ожидания ответа по приёму пачки чеков от внешней системы, указанный в параметре export.set10wsclient.purchases.request.timeout (в миллисекундах). При достижении указанного времени сервер Set10 разрывает соединение и пытается повторно отправить ту же пачку чеков.

Open

Веб-сервис без обратной связи (совместимость с SAP)

Веб-сервис экспорта чеков (на стороне ERP) - метод processPurchasesWithTI

Оптимальное значение параметров:

• export.set10wsclient.purchases.polling.interval.sec = 60

• export.set10wsclient.purchases.db.portion.size.records = 1000 (если требуется ускорить отправку, параметр можно увеличить вплоть до 5000).

• export.set10wsclient.purchases.catalog.size.records = 100 (если требуется ускорить отправку, параметр можно увеличить вплоть до 1000).

• export.set10wsclient.purchases.short.interval.ms = 5000 (если требуется ускорить отправку, параметр можно сократить вплоть до 10 мс).

• export.set10wsclient.purchases.request.timeout = 60000 (если внешняя система не успевает принять размер пачки за 60 секунд, параметр можно увеличить на необходимое значение).

Настройка loyal.result.sending.toerpi

Параметр loyal.result.sending.toerpi определяет, нужно ли дожидаться транзакции лояльности перед включением чека в группу на отправку:

• true: чеки с hasloytransaction = true, для которых транзакция лояльности отсутствует, исключаются из выборки. Они не попадают ни в одну группу (магазин + операционный день) до получения транзакции. Остальные чеки группируются и отправляются в штатном режиме. Фильтрация выполняется на двух уровнях: на уровне SQL-запроса и дополнительно на уровне Java-кода.

• false: фильтрация по транзакции лояльности отключена. Все чеки включаются в группы и отправляются без ожидания транзакции лояльности.

По умолчанию: false.

Примечание: поведение аналогично секции 2 (1С), с той разницей, что здесь чеки предварительно группируются по магазину и операционному дню. Фильтрация по loyal.result.sending.toerpi применяется до группировки, исключённые чеки не влияют на состав групп.

Алгоритм работает следующим образом:

1. Согласно параметру export.set10wsclient.purchases.polling.interval.sec, один раз в указанное количество секунд проверяется наличие очереди чеков на отправку.

2. При появлении чеков в очереди выполняется их выборка из базы данных и загружается в память, их количество не более чем указано в параметре export.set10wsclient.purchases.db.portion.size.records.

   1. Если у чека есть признак наличия транзакции лояльности hasloytransaction = true, но при этом самой транзакции лояльности в модуле ERPI ещё нет, чек в выборку не попадает.

3. Из полученных чеков составляется список группировки по ключу магазин+опер.день.

   1. Таким образом в одной пачке XML с чеками может быть только один магазин и только за один операционный день.

4. Из выбранных чеков выполняется упаковка чеков в пачки для отправки по SOAP.

   1. Если в очереди из пачки в 1000 чеков было выбрано только 30 чеков на один магазин за один операционный день, именно они и будут упакованы для отправки. На другие магазины чеки будут отправлены в отдельных пачках.

   2. Если экспорт идёт с сервера Centrum, и/или было выбрано чеков из очереди на магазин за опер.день больше, чем размер пачки export.set10wsclient.purchases.catalog.size.records, отправка будет разбита на несколько пачек.

5. Отправка на указанный URL веб-сервиса выполняется раз в интервал, указанный в параметре export.set10wsclient.purchases.short.interval.ms.

6. При отправке сервер выжидает таймаут ожидания ответа по приёму пачки чеков от внешней системы, указанный в параметре export.set10wsclient.purchases.request.timeout (в миллисекундах). При достижении указанного времени сервер Set10 разрывает соединение и пытается повторно отправить ту же пачку чеков.

Open

Резюме

• Веб-сервис на стороне сервера Set10 (методы getNewPurchases / getNewFullPurchases): pull-модель. FIFO-очередь, без группировки по магазину/опер.дню. Размер пачки управляется export.webservice.new.purchases.batch.size (рекомендация 100).

• Веб-сервис на стороне ERP с обратной связью (совместимость с 1С, метод processPurchases): push-модель. Polling + выборка порциями из БД + упаковка + отправка. Без группировки по магазину/опер.дню.

• Веб-сервис на стороне ERP без обратной связи (совместимость с SAP, метод processPurchasesWithTI): push-модель + обязательная группировка по ключу «магазин + опер.день». В одной XML-пачке только один магазин и только один операционный день.

• Во всех трёх режимах фильтрация по наличию транзакции лояльности управляется настройкой loyal.result.sending.toerpi (по умолчанию false - фильтрация отключена.