|
[Search] Поиск   [Recent Topics] Последние темы   [Hottest Topics] Горячие темы   [Members]  Список участников   [Groups] На главную страницу 
[Register] Регистрация / 
[Login] Вход 
Не работает меркурий  XML
Индекс форума » Компонент МЕРКУРИЙ
Автор Сообщение
serega2671


Зарегистрирован: 02/07/2018 06:59:46
Сообщений: 58
Оффлайн

dbelyaev_orb wrote:to Lem
Через API Складской журнал иногда выдает ошибку APLM 12, входящие эВСД всегда ошибка


Иногда Примерно так каждый раз
Николай Власов

[Avatar]

Зарегистрирован: 24/06/2009 08:32:34
Сообщений: 1186
Оффлайн

Lem wrote: Сам себе отвечу. Запросы по формату 2.0 ВЫДАЮТ ошибку, а по 1.4 вроде РАБОТАЕТ. Может кто-нибудь прокомментировать с технической т.з.?


Может.
ВетИС.API 1.4. и ВетИС.API 2.0 - это РАЗНЫЕ шлюзы к одной и той же системе.

1.4. используется в основном теми, кто давно готовится к ЭВС. Большинство из них имеет уже отлаженные параметры и давно работающие и потому полные базы данных со стороны сторонней системы.
Среди тех, кто работает в 2.0. очень много (подавляющее большинство) тех, кто только сейчас начинает работать. У них параметры не оптимизированы и локальной информации нет.

Неоптимизированность запросов (например слишком ранние запросы после получения тикета) порождает повторные запросы, что дополнительно нагружает систему.

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

Постепенно ситуация стабилизируется и сама по себе (в результате оптимизации и завершения процесса массовых выгрузок), но и мы поможем ситуации, сделав некоторые усовершенствования и альтернативные возможности.
Lugano


Зарегистрирован: 12/12/2017 15:19:54
Сообщений: 57
Оффлайн

serega2671 wrote:
dbelyaev_orb wrote:to Lem
Через API Складской журнал иногда выдает ошибку APLM 12, входящие эВСД всегда ошибка


Иногда Примерно так каждый раз


Система Меркурий работает штатно, включая ее web-интерфейс, замедлений в работе не зафиксировано. В интеграционном шлюзе остается ограничение для выравнивания нагрузки в виде ответов с кодом APLM0012.

http://www.fsvps.ru/fsvps/news/27188.html
tihohod


Зарегистрирован: 22/09/2017 10:56:12
Сообщений: 3
Оффлайн

А получение входящих ВСД как на это влияет?
Всего 12 магазинов на одном ХС запрос вы требуете по каждому предприятию отдельно. Но APLM0012 сервер
возращает постоянно, в лучшем случае только с 5-6 попытки получаем входящие ВСД.
user100000


Зарегистрирован: 05/06/2018 08:26:50
Сообщений: 163
Оффлайн

плять, опять клиенты виноваты, видите ли неправильные запросы кидают
иди работай, нефик на форуме штаны просиживать
dimas940


Зарегистрирован: 19/06/2018 12:31:17
Сообщений: 5
Оффлайн

Они включили борьбу с DDOS атаками и банят всех атакующих
Sky_nnov


Зарегистрирован: 14/06/2017 15:09:53
Сообщений: 112
Оффлайн

Николай Власов wrote:Сам себе отвечу.

Спасибо за разъяснения. Я на полном серьезе. Понимание ситуации снимает лишние вопросы.
Все на нервах вы уж нас тоже поймите.

Это сообщение было редактировано 1 раз. Последнее обновление произошло в 05/07/2018 10:38:53

serega2671


Зарегистрирован: 02/07/2018 06:59:46
Сообщений: 58
Оффлайн

Sky_nnov wrote:
Николай Власов wrote:Сам себе отвечу.

Спасибо за разъяснения. Я на полном серьезе. Понимание ситуации снимает лишние вопросы.
Все на нервах вы уж нас тоже поймите.


не поймет
max_01

[Avatar]

Зарегистрирован: 29/08/2017 16:05:49
Сообщений: 44
Оффлайн

Не ходят документы.
Как исполнять закон?
Blizkij


Зарегистрирован: 07/12/2017 13:31:24
Сообщений: 375
Оффлайн

max_01 wrote:Не ходят документы.
Как исполнять закон?


Только пользоватся п.10 ст. 2.3 Закона о ветеринарии. А больше хз как.....
Vsevolod_Omsk


Зарегистрирован: 05/07/2018 12:12:02
Сообщений: 2
Оффлайн

Николай Власов 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 успехом не завершилась, так.... Занято, или музыку в трубке по межгороду послушали.


Vladimir2017

[Avatar]

Зарегистрирован: 02/10/2017 14:31:03
Сообщений: 362
Оффлайн

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


Я запросы на документы делаю по дате последнего документа, то-есть в диапазон попадает менее суток. Склад получаю только не пустые позиции, опять же копейки. Но получаю сотнями 0012 за сутки. Т.е. вы балансируете не дропом объемных запросов, вы дропаете запросы по типу, не обращая внимания на их вес, что, как мне кажется, не совсем правильно. Тяжелые запросы будут выполнятся с такой же частотой как и легковесные, ситуацию это не исправит.
mznp


Зарегистрирован: 04/07/2018 06:39:40
Сообщений: 7
Оффлайн

Между тем в интеграционном шлюзе остается ограничение для выравнивания нагрузки в виде ответов с кодом APLM0012. По словам замруководителя Россельхознадзора Николая Власова решение проблемы ожидается в течение 1-2 недель. Эту информацию он озвучил на официальном форуме системы "Меркурий", передает The DairyNews.

Также Николай Власов напомнил, что штрафов опасаться не следует тем, кто не намеренно (по неопытности, необученности, недостатку информации) ошибается и тем, кто пытается сделать, но по тем или иным причинам не может (все попытки фиксируются). Тем кто будет пытаться жулить в этой обстановке опасаться их следует, подчеркнул чиновник.

- Ожидаем, что за 1-2 недели проблема будет решена, - ответил в беседе с пользователями форума Николай Власов.

Подробнее читайте на © DairyNews.ru http://www.dairynews.ru/news/reshenie-problem-s-integratsionnym-shlyuzom-merkur.html

На 2-3 недели запасаемся попкорном, шлюз работать не будет )))))

Это сообщение было редактировано 1 раз. Последнее обновление произошло в 05/07/2018 13:23:30

Владимир Игнатов


Зарегистрирован: 02/08/2017 09:19:30
Сообщений: 581
Оффлайн

И мои 5 копеек, ув. Н.А.

За истекшие пару дней пользователями совокупно было создано ок. 100000 штук записей о номенклатуре. Я пытаюсь их забрать через API 2.0, GetProductChangesList не весь справочник, а начиная со вчера. 2 запроса в секунду - не очень много? По 60 перезапросов блоков по 512 записей (вдвое меньше максимума, указанного разработчиками) - и безрезультатно. 60 ошибок подряд на одном блоке - это система работает или уже нет?

Видимо, для нас и Вас есть некоторая разница в понятиях "работает"/"не работает". Для нас (ничего, что я за всех говорю?) "работает" - это если через API всех версий, которые заявлены как поддерживаемые, и через веб-фейс можно выполнять действия, указанные в документации. Получать справочники, получать списки ВСД и журналы хранения, оформлять и гасить эВСД и т.д.
"Все работает, а вот тут немножко не работает" - это "не работает".
В списке упаковки тип ХХ отсутствует, а в приходящих ВСД он есть - это "не работает".
Получение списка предприятий - есть предприятия, которые никак и никогда нельзя получить, сколько попыток не делай (у меня есть конкретные номера смещений, если забирать весь справочник "от начала времен") - это "не работает".
и т.д.

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

Это сообщение было редактировано 2 раз. Последнее обновление произошло в 05/07/2018 13:31:11

mevgenym


Зарегистрирован: 19/05/2017 14:03:42
Сообщений: 312
Оффлайн

Николай Власов wrote:до сотен мегабайт по одному запросу, например на историю изменений журнала по всем видам продукции года за три.


Vsevolod_Omsk wrote:
т.е. что входящие ВСД, что журнал читаем партиями по 50 штук (в середине июня и по 1000 работало).

Тут трактовать можно по разному, три года это период выборки запроса. Вот как готовится ответ непонятно. То ли сразу делается запрос к ИБ на весь период в параметрах операции и складывается где то в кеше, пока не прийдет запрос со смещением, то ли только на окно выборки в вашем случае - 50. Во втором случае, объем выборки данных всегда ограничен окном (максимальное окно = 1000). Если окно маленькое, то увеличится количество запросов, вот что более критично объем данных или количество запросов? Вообще мы как пользователи не должны были задаваться такими вопросами. Система не отрабатывает свои задачи.
https://github.com/mevgenym/1c_vetis.api_v1.1
https://github.com/mevgenym/1c_vetis.api
 
Индекс форума » Компонент МЕРКУРИЙ
Перейти:   

Powered by JForum 2.1.8 © JForum Team