Ошибка MERC02462 - проблема на стороне Меркурия или разработчика ПО?

с учетом текущих возможностей Меркурия

Ссылка на официальные технические характеристики Меркурия есть?

Wastman wrote:

с учетом текущих возможностей Меркурия

Ссылка на официальные технические характеристики Меркурия есть?

текущие возможности (можно же считать это официальной информацией):

Николай Власов wrote:

NikoV wrote:После обновления 1С:УВС до версии 1.0.8.1 проблема с ошибкой MERC02009 исчезла. Осталось только ошибка MERC02462. Насколько я понимаю - проблема не в характеристиках сети интернет. Быстрый интернет проблему не снимет. А с настройкой "Получать файл ветеринарной справки при загрузке ВСД" поэкспериментируем. Но в любом случае это придумывание "костыля" надо решать проблему в целом. У нас небольшое предприятие, у крупных предприятий проблемы могут быть посерьезнее. И я не увидел ни одного комментария коллег по цеху. У кого - нибудь в час пропускает ФГИС до 700 документов или больше с одной площадки?

Конечно. До 40 тыс в час пропускает.

Это вилами по воде.
Считаю, вопрос топикстартера не решен.

serg882 wrote:текущие возможности (можно же считать это официальной информацией):

а это?

Сейчас ни кто ни чего не обновляет: мораторий на обновления уже действует.

Сейчас ни кто ни чего не обновляет: мораторий на обновления уже действует.

А это откуда цитата? Про обновления системы? Сейчас тестировал мультимодальные перевозки в исходящей транзакции во второй версии и обнаружил в ответе (раздел vetdocument) несколько новых тегов, которых раньше не было и в вики их нет (shipmentRoute.routePoint.enterprise.name и shipmentRoute.routePoint.location.address.addressView).

А про возможность 40 тыс в час, это конечно тест "маркетинговый" к реальной работе не относящийся (так везде делают, скорее всего все записи журнала были разные).

А это откуда цитата?

С РГ по ЭВС и слов НА.

Добрый день, Коллеги!
Увидев тему, решили провести эксперимент с выявлением ошибки указанной в теме на ПП "Визард:Интеграция с ФГИС Меркурий".

Параметры следующие:
700 транспортных транзакций отправляются в цикле поочередно.
Каждая транзакция содержит 15 партий продукции.
Отправляемые партии во всех транзакциях совпадают: идет списание с одних и тех же 15-ти партий продукции.

Результат следующий:
Все транзакции были успешно отправлены.
Время выполнения: 1 час 15 минут.

Тест проводился на обычном ПК на файловой БД: HDD, core i5.

Более подробно можете ознакомится с тестом тут: https://www.youtube.com/watch?v=X84DCq6XVLk&feature=youtu.be

Соответствует ли тестовый пример вашему случаю?

A.Balan wrote:
Результат следующий:
Все транзакции были успешно отправлены.
Время выполнения: 1 час 15 минут.

Тест проводился на обычном ПК на файловой БД: HDD, core i5.

Более подробно можете ознакомится с тестом тут: https://www.youtube.com/watch?v=X84DCq6XVLk&feature=youtu.be

Соответствует ли тестовый пример вашему случаю?

Интересное кино, это получается 2,3333 запроса в секунду. В проблемном ПО подход похоже неверный, в этом и проблема (там по логам видно, что они отрабатывают не особо шустро). Может там на второй версии тест был.

Интересное кино, это получается 2,3333 запроса в секунду. В проблемном ПО подход похоже неверный, в этом и проблема (там по логам видно, что они отрабатывают не особо шустро). Может там на второй версии тест был.

про 2,3333 не понял. Поясните, пожалуйста.

Получается так, если отправлять документы последовательно: 75 мин * 60 = 4500 сек; 4500 / 700 = 6,4 сек на одну транзакцию.

Также провели еще один эксперимент по скорости обработки Меркурия "атаки" в цикле в один поток:
1) Среднее время обработки транспортной транзакции с 15-ю партиями - 4-7 сек.
2) Среднее время обработки транспортной транзакции с 1-й партией - 3-5 сек.

Вот такая статистика...

Из этих данных можно сделать примерный расчет скорости работы системы, если разбить массив документов на 4 (к примеру, можно и больше) параллельных потока.
На мой взгляд производительность будет удовлетворительной для наибольшего количества ХС.

Правда нужно учесть, что транзакции, содержащие одни и те же партии, нельзя "параллелить", а нужно выставлять в одну очередь.

A.Balan wrote:
про 2,3333 не понял. Поясните, пожалуйста.

Это я просчитал, если отдельно каждую строку отправлять. Забыл, что в транзакции можно указать несколько consigment. 700 документов за 1 час это много. Там скорее всего были параллельные потоки и из-за этого возникали ошибки.

A.Balan wrote:
Правда нужно учесть, что транзакции, содержащие одни и те же партии, нельзя "параллелить", а нужно выставлять в одну очередь.

Там очередь и была, результат 16 часов + все равно были ошибки. А в очередь весь документ целиком? В разных документах могут быть разные повторяющиеся номенклатуры, это получится последовательная отправка, в потоки будет уходить немного документов, а в вашем тестовом примере параллельных потоков не будет (там все документы одинаковые, это если ошибка MERC02462 проявляется при одновременном проведении разных транзакций).

А в очередь весь документ целиком?

Да, изначально предполагал именно так.

В разных документах могут быть разные повторяющиеся номенклатуры

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

Если у Вас "+/-" именно такой пример. Тогда действительно, вероятность запустить несколько потоков параллельно будет крайне мала.

Для этого кейса можно предложить иной подход: Не делать производственные транзакции заранее, а в момент оформления транспортной транзакции. Таким образом у вас для каждой "накладной будут свои партии и можно создать любое количество потоков, сколько только нам разрешат разработчики ФГИС "Меркурий".

Схематически будет выглядеть так:
Документ отгрузки информационной системы -> Выпуск продукции на объем указанный в накладной -> Отправка только что сформированных партий клиенту.
И так по каждой накладной.
А сырье списывать можно в рамках производственной транзакции.
Таким образом вписываемся в концепцию Меркурия, увеличиваем производительность при текущих реалиях и бонусом ко всему избавляемся от отдельного ведения производства в Меркурии.
У нас эта схема называется "Перевозка с автовыпуском". На практике довольно большого количества предприятий могу сказать, что она работает довольно успешно.

Если у Вас кейс другой, опишите, пожалуйста.

Под номенклатурой имел ввиду партии. Производства нет, готовый товар приходит от поставщика. У меня лично пока нет этой проблемы, разработка на стадии завершения, но ожидается, что будет около 800-900 заявок по одной из площадок, так что придется как-то оптимизировать процесс отправки, что довольно непросто, учитывая ограничения на количество запросов в секунду и долгую отработку одиночных запросов (из-за постоянной авторизации в каждом запросе). И это пока в тестовом контуре, что будет в рабочем сложно предсказать.

Под номенклатурой имел ввиду партии. Производства нет, готовый товар приходит от поставщика. У меня лично пока нет этой проблемы, разработка на стадии завершения, но ожидается, что будет около 800-900 заявок по одной из площадок, так что придется как-то оптимизировать процесс отправки, что довольно непросто, учитывая ограничения на количество запросов в секунду и долгую отработку одиночных запросов (из-за постоянной авторизации в каждом запросе). И это пока в тестовом контуре, что будет в рабочем сложно предсказать.

И тут в Вас есть большая вероятность того, что в 800-900 заявок будут попадать одни и те же партии в таком количестве, что не получиться организовать хотя бы два потока? (что уже решило бы вашу проблему).

Обычно все заказывают одно и то же, партий будет немного (1-3), в документах может быть от 5 до 40 строк. Здесь можно будет инвентаризацией "плодить" партии, если не получится нормально сделать и тогда потоки будут.

serg882 wrote:Обычно все заказывают одно и то же, партий будет немного (1-3), в документах может быть от 5 до 40 строк. Здесь можно будет инвентаризацией "плодить" партии, если не получится нормально сделать и тогда потоки будут.

Генерировать партии под отгрузку - это возможное, но крайнее и, конечно, временное решение. Коллега, можете написать ваш сценарий, а мы попробуем его прогнать на тестовом сервере в разных вариантах? Результатами также поделимся.