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

Отчет по гашению тут: https://www.youtube.com/watch?v=A0UDPd_K4fA&feature=youtu.be
Многопоточная отправка запросов проявила себя наилучшим образом.
Такую технику применили теперь на всех типах хоз. операций.
Результат впечатляет.

A.Balan ты получил ЭВСДшки?

Частично погасил.
Сегодня добью все остальное и отпишусь о результатах.

A.Balan ты получил ЭВСДшки?

Да, как проведу тест, отпишусь о результатах.

Мне инн нужен. 1С:УВС не дает искать по guid

ИНН: 6924002730
КПП: 694901001

В целом соответствует, но на видео видно начало процесса, окончания нет. Давайте проведем тестирование, я скину продукцию на вашу площадку, а вы мне ее потом вернете. Замерим время в одну сторону и в обратную. Интересно такое предложение?

Да, согласен с вами, не совсем понятно где конец. Завершение можно отследить по выводу сообщения в конце "Финиш".
По тестированию предложение интересно.
Данные в тестовом сервере для отправки:
guid ХС: fcd343ba-218a-11e2-a69b-b499babae7ea
guid Площадки: eb25985a-3eea-4c6c-8df8-ac930874eed7
Как отправите, сообщите, пожалуйста.

я думаю "расщеплять" документы на строки, из этих строк формировать потоки, и они уже будут отправляться. Я заметил, что только первый запрос уходит с задержкой, остальные довольно шустро проходят, так что возможно этот подход будет верным.

Мы проводили эксперимент. Транзакция с одной партией проходит 3-5 сек, а с 15-ю - 5-8 сек. Чтобы не выполнить более 5 транзакций в секунду, Вам нужно делать не более 5-ти потоков параллельно. Нужно опять же экспериментировать. Будет ли более производительной отправка транзакций с одной партией, сравнивая с отправкой транзакций с вашим среднестатистическим составом накладной. На мой взгляд ответ не очевиден сразу.

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

Вариант. Мы такой тоже рассматриваем для применения.
На текущий момент останавливает то, что при формировании партий через инвентаризацию непонятно как правильно указать сведения о ВСД, по которому была принята продукция. Без этого мы полностью теряем прослеживаемость.
Разработчики Меркурия дали ответ следующий: указать данные сведения возможность есть, но на Вики это пока не описано. Документацию обещали обновить в ближайшее время.
Как только появится. Мы будем думать и над "автоинвентаризацией под отгрузку".

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Добрый день, Коллеги!

Мы предлагаем простой и доступный способ автоматизации обмена ветеринарной документацией между ГИС «Меркурий» и существующей у Вас учетной системой.

Нами был разработан модуль «Визард:Интеграция с ГИС Меркурий») в 2 версиях, различающихся по своей функциональности ("ПРОФ" и "КОРП").

Функции модуля интеграции:
• создание заявок на передачу сведений в ГИС «Меркурий» на основании первичных документов, введенных в действующую базу;
• выгрузка подготовленных данных в ГИС «Меркурий»;
• получение обратной связи от ГИС «Меркурий».

Перечень операций, производимых модулем:

1) Переработка/производство
2) Перевозка
3) Инвентаризация
4) Гашение входящего ВСД
5) Весь функционал работы с нормативно-справочной информацией, предоставляемый разработчиками API ГИС Меркурий

ПО ВСЕМ ВОПРОСАМ, СВЯЗАННЫМ С ПРОДУКТОМ И ЕГО ПРИОБРЕТЕНИЕМ, Я К ВАШИМ УСЛУГАМ:

Балан Александр Юрьевич
Телефон: 8-920-166-33-90
E-mail: a.balan@wizard-c.ru