Сообщения, отправленные пользователем: Vsevolod_Omsk

TWAIN wrote:
Делается 100 попыток с приличными интервалами (100 попыток занимает 23 минуты), и все равно хрен.
Окно 500 - прошло только одно окно из 10. Окно 250 - пока получено только два окна, висит по 10 минут на обработке одного окна.

Немного вам завидую, у вас работает по 250.
у меня окно 100 работает относительно стабильно (штук 20 aplm0012, 1 раз сработает), приходится сидеть на стабильном окне в 50 штук, чтобы по ночам часто не будили.
и это окно в listoptions.count = 50 у меня с 20 чисел июня. Последний раз сработавшее окно в 1000 видел 15 июня (не июля, а имено июня). Наверное. Может еще раньше...

Но логика работы несколько другая. Если ответ aplm0012 или таймаут, то следующий запрос я посылаю через 5 секунд. Обновление списка входящих эвсд - каждые 5 минут.

Более того, у меня есть ХС, в котором 3 (три) входящих ВСД в сутки. Так aplm0012 и таймауты есть и там, и количество - не сильно меньше, чем на основном.

Николай Власов wrote:А объем этой информации весьма большой - до сотен мегабайт по одному запросу, например на историю изменений журнала по всем видам продукции года за три. Обработка таких потоков (совершенно нетипичная для штатного режима, что показывает своей работой 1.4.) роняет производительность шлюза (определяемую по числу обработанных запросов). В связи с этим на стартовый период мы ввели искусственное ограничение на общее количество запросов такого типа. Если сторонняя системе утыкается в это ограничение, то она получает APLM0012.

Рад, что хоть кому-то ответили. Рискну задать свой вопрос.

У нас интеграция была сделана до 01.07. ВСЮ необходимую информацию получили, клиентам по 4 уровню отправляли, aplm0012 были, но не так чтобы много, пусть 10 штук в день. Могу говорить с уверенностью, т.к. с 18.06.18 веду полный лог общения со шлюзом ветис, включая сообщения со статусом "in_process". Сообщения отправляем/получаем по очереди, размер <listOptions xmlns="http://api.vetrf.ru/schema/cdm/base"> <count>50</count> <offset>0</offset> </listOptions>, т.е. что входящие ВСД, что журнал читаем партиями по 50 штук (в середине июня и по 1000 работало). Интервал между повторными запросами 5 секунд.

За текущие сутки, (с 04.07.2018 12:00 МСК по 05.07.2018 12:00 МСК) шлюз ветис апи 2.0 хоть как-то адекватно работал примерно с 04.07.2018 16:20 мск, по 05.07.2018 04:15 МСК. В это время ошибки были. но они измерялись единицами. Все остальное время - aplm0012 и другие. Причем ситуация, когда я пытаюсь получить входящие документы запросом даже с ограничением дат типа
<updateDateInterval xmlns="http://api.vetrf.ru/schema/cdm/base">
<beginDate>2018-07-05T09:07:40</beginDate>
<endDate>2018-07-05T09:14:00</endDate>
</updateDateInterval>
и получаю до 20 aplm0012 подряд. С паузой между запросами.. С моей точки зрения попахивает абсурдом. Мне надо загрузить ОДИН входящий документ в модуль, чтобы проставить соответсвия по 4 уровню - и не могу. И когда в итоге приходит xml из 35 строк - я не могу понять, почему это для Меркурия было так сложно.
То же самое - со складскими остатками. Инвентаризируем десять позиций, отправляем их через шлюз примерно в 08:00 мск. Веб интерфейс видит через минуту, через шлюз удачный запрос getStockEntryChangesListRequest смог получить данные только в 16:00 мск.
Естественно, задержки с отправкой машин, транзакции по 1 накладной могли оформляться минутами.
Естественно - претензии от клиентов. Работать было невозможно. пришлось часть накладных отправлять по 3 уровню через веб интерфейс.

Скажите, с точки зрения разработчиков системы, что мы делали не так?

На текущий момент порции по 50 штук оставил, один поток оставил, все паузы убрал. Да, я буду долбится на сервер за своими данными каждую секунду в случае ошибок, я буду создавать нагрузку, но так хоть какой-то шанс, что получу нужную информацию. Aplm0012 - плевать, буду сразу же запрашивать то же самое. Превышено время ожидания - плевать, запрашиваю заново. Любая ошибка - плевать, запрашиваю заново.
Вот в таком режиме можно хоть как-то работать, все остальные варианты приводят только к нервам работников и проблемам с отгрузкой.
Причем я не уверен, что шлюз начал справляться с нагрузкой полноценно, возможен вариант, что просто ушла нагрузка в виде молочных продуктов и рыбных пресервов / салатов.

И еще. На адрес техподдержки mercury@fsvps.ru с 20.06 по 05.07 было отправлено 8 писем. Ответа не было ни на одно. Ни одна попытка дозвониться из 4 успехом не завершилась, так.... Занято, или музыку в трубке по межгороду послушали.