|
[Search] Поиск   [Recent Topics] Последние темы   [Hottest Topics] Горячие темы   [Members]  Список участников   [Groups] На главную страницу 
[Register] Регистрация / 
[Login] Вход 
Сообщения, отправленные пользователем: Garland
Индекс форума » Профиль для Garland » Сообщения, отправленные пользователем Garland
Автор Сообщение
Спасибо за совет.
Переключили канал на запасного провайдера, оборудование Cisco. Запросы отправляли с того же компьютера.
MikroTik, который у нас на входе, проверили - он чистый.
Уже 30 минут, как ошибок не было. Есть большая вероятность что проблема не повторится.

Нам теперь того провайдера трясти? А может это где-то дальше по цепочке...
Что посоветуете нам дальше делать?
Загрузка ведется средствами 1С 8.3 через HTTP соединение на адрес "api.vetrf.ru", с указанием логина и пароля
Обращаюсь по ссылке http://api.vetrf.ru/schema/platform/services/2.0-last/ams-mercury-g2b.service_v2.0_production.wsdl
Из этой ссылки получаю все необходимое

В ответ со вчерашнего дня приходят ошибки двух типов (до этого таких проблем не было):
1) Ошибка при вызове конструктора (WSОпределения) по причине:
При создании описания сервиса произошла ошибка. URL сервиса: http://api.vetrf.ru/schema/platform/services/2.0-last/ams-mercury-g2b.service_v2.0_production.wsdl
Код ответа сервера: 403
2) Ошибка при вызове конструктора (WSОпределения) по причине:
Ошибка импорта схемы
по причине:
Ошибка доступа к файлу 'http://api.vetrf.ru/schema/platform/services/2.0-last/dictionary_v2.0.xsd'
по причине:
Ошибка работы с Интернет: Failure when receiving data from the peer

Вторая ошибка связана в первую очередь с тем, что этот файл блокируется антивирусом.
Последняя ошибка подобного рода была только что в 14.02 03.09.18
Чуть выше по тексту есть ответ вашего сервера на http://api.vetrf.ru/schema/platform/services/2.0-last/dictionary_v2.0.xsd
Там приходит ссылка на вредоносный JS.
У меня есть закешированные файлы с XSD схемами от 17.08.18 и размер dictionary_v2.0.xsd там 44kb, но никак не 577 байт, которые блокирует антивирусник.
Замечательное содержимое файлика Dictionary_v2
Служба поддержки что-то не торопится исправлять косяки

С 02.09.18 антивирус начал орать при закачке XSD схем с адреса http://api.vetrf.ru/schema/platform/services/2.0-last/
Говорит там некий JS/CoinMiner.BF троянчик

Что, своих 80 серверов для майнинга уже не хватает? Решили компы юзеров Меркурия заразить?

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

Интересует среднее время обработки 1 заявки, количество строк в заявке, пользуетесь ли вы незавершенным производством.
Вопрос достаточно актуальный, так как у нас например некоторые заявки висят IN_PROCESS по несколько часов и более (я полагаю ответ по ним не придет уже никогда).
А примерно в 3 часа ночи любые заявки вообще перестают обрабатываться.
Сарказм on
Это же штатный режим работы "для выравнивания нагрузки".
Сарказм off
Как человек, написавший с нуля уже второе глобальное интеграционное решение (сначала ЕГАИС, теперь Меркурий) я слегка в шоке от таких высказываний вроде бы должностного лица.
Сравните эту поделку с системой ЕГАИС - там и круглосуточная поддержка со стороны администраторов и операторов системы, и четкая методология, и законодательство.
И Антон Валерьевич пару раз отписывался с извинениями в темах (с описаниями ошибок), которые я создавал в техническом разделе форума.
А тут просто балаган. И абсолютно никаких реальных дел со стороны администрации "проекта".
80 серверов молотят воздух, а барьер в 4 млн. ВСД по всей стране так и остается непреодолим...
Ну там в ответе по одному requirement приходит один или несколько conditionGroup. Если conditionGroup только один, то берете все из этой группы.
А если таких 2, то можно взять по любому из них. Я если честно даже не пробовал указывать GUID из двух групп сразу - по идее это избыточно.
Попробуйте перед формированием ВСД в шлюзе выполнить checkShipmentRegionalizationRequest (по видам продукции и точкам маршрута).
Оттуда возьмите все необходимые GUID для блока r13nClause в исходящей ВСД.
Стыдно должно быть официальному лицу писать с таким чудовищным количеством грамматических / орфографических ошибок.
Вы сразу напоминаете шарлатана, торгующего на улице волшебными пилюлями.

А по делу - ограничение в пропускной способности шлюза API вы никак не обойдете. Посмотрите статистику по стране - все 80 серверов никак не могут пройти барьер в 4 млн. ВСД за сутки.
Один производственный документ находится в состоянии IN_PROCESS около 5 минут реального времени, если дольше 10 минут - то ответ вы уже не получите никогда.
Это хорошо если у вас маленькие предприятия или оптовики-перекупщики, которым нет необходимости оформлять много производственных документов.
Конечно для заведения остатков всегда можно обойтись банальной инвентаризацией, которая в шлюзе обрабатывается секунд 20-30.
А что вы делаете с исходящими ВСД, по которым получен ответ REJECTED, но которые загадочным образом зафиксировались в системе? Вручную дубли чистим?
Через веб интерфейс вы этого в явном виде не увидите, это только в Цербере видно
Ну или по запросу GetActivityLocationList
Ну бывает, Меркурий он такой
Воспользуйтесь функцией modifyActivityLocationsRequest и привяжите на всякий случай площадку к ХС

У нас похожая ситуация вчера была - создавали новый магазин с явным указанием owner, а площадка создалась без привязки
Ну разработчики откровенно признались что есть определенная квота запросов в секунду на всю страну.
Все кто не убрался в квоту автоматом получают APLM0012, размер запроса/ответа абсолютно неважен.

Веселее в этом ключе выглядит заявление представителей ТАНДЕРА, что им по звонку в россельхоз "Увеличивают квоту, и у них вся очередь прокачивается"
Если кому интересно - то заявили они это совершенно открыто на всю страну, а Власов сидел рядышком и важно кивал головой.
Вообще не стесняются - коррупция в верхах, типа неприкасаемые.
https://www.youtube.com/watch?v=CCsPt3uNvdg
с 1ч 24мин примерно
Оптимальнее всего использовать GetVetDocumentChangesListOperation
Интервал указывать начиная с последней загруженной ВСД

Ну и сам вопрос обернуть в "вечный цикл", выход из которого происходит только в том случае, если это не APLM0012
В связи с чрезвычайно долгим сроком обработки заявок попробовал сделать очередь в API двумя потоками
И что бы вы думали:
<apl:error code="MERC56462" xmlns:apl="http://api.vetrf.ru/schema/cdm/application">В запросе был указан идентификатор записи журнала, которая была обновлена одновременно с попыткой выполнения данной операции. Поэтому операция была отменена. Попробуйте выполнить операцию еще раз.</apl:error> </errors> </application> </receiveApplicationResultResponse>

То есть 150 магазинов, по 6-7 минут на 1 документ - это примерно 15 часов... и то если на каждый магазин только по 1 документу выписывается.
Отличная система
 
Индекс форума » Профиль для Garland » Сообщения, отправленные пользователем Garland
Перейти:   

Powered by JForum 2.1.8 © JForum Team