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

nsnt wrote:Система такого масштаба не имеет права обрушиться из-за случайно залетевшего дятла. Ни на какие интеграции нельзя сваливать вину за происходящее. Без вариантов.

Согласен, но я думаю дятлов тут целое стадо.

nsnt wrote:Да я Вам лично претензий не предъявляю. Это я в целом про разговоры на форуме. Это позиция Власова свалить свалить с больной головы на здоровую, но если каждый раз повторять про кривые интеграции, потихоньку привыкаешь, что сам козел.

Можно на форуме ерепениться, пока его не закрыли и хватает нервов, а по факту так и останется.

nsnt wrote:

TWAIN wrote:Да, это озвучено давно. Виноваты на 70% 1С, которые выпустили поддержку меркурий 15 июня.
Через 10 дней все запустили обновление списков и с 25 числа мы фиксируем проблемы.

Просто руки опускаются от таких заявлений. Полгода назад я этот форум в запрещенные сайты себе занесла, чтобы настроение не портить, ближе к 1 июля вернула. Опять, видимо, придется запретить.
Бедные разработчики Меркурия представить себе не могли, что все разом работать начнут. Разумеется, 1С виновата, что уложилась в озвученные сроки и выпустила типовое решение.
Даже если Вася Пупкин будет круглыми сутками списки грузить за последние три года, все равно это косяк системы, а не Васи Пупкина. Зачем вы повторяете про кривые интеграции? Это мы понимаем сарказм, а пользователи могут и поверить.

Я озвучиваю для тех кто не смотрел видео встреч, что говорили ОНИ.
И на что натолкнулись мы по факту 25 июня, когда загрузка ЭВСД встала.
Все остальное - Ваши домыслы.

nifor wrote:

leradata wrote:Добрый день.

Дошла информация , что на встрече от 23.07.2018, для получения списков ВСД и склада, было предложено следующее:

"рекомендуют запрашивать список, а потом выдергивать по транзакционно"

вопрос - что это за методы ?
которые выдают только список GUID/UUID транзакции (записи) без ее наполнения.
все существующие возвращают полную информацию о записи, в количестве указанном в count.

или это "испорченный телефон".

Рекомендовали больше данных в 1С хранить и остатки списывать из ответов транспортных партий,а не каждый раз по новой запрашивать. Так-же сказали что записана задача по запросу остатков конкретных СКЮ.

И все равно не поможет.
Мы сейчас получили функцию запроса ЭВСД по одному GUID.
Работает 3 минуты на одну запись. У нас их 400, отгружается за 5 часов.
А с такими лагами должно беспрерывно грузить 20 часов в сутки.
Это если все хорошо и не упадет.

У нас представители органов власти не считают что мы их кормим.
У них твердое убеждение, что раз они попали туда, это ИХ деньги и точка.
Они да, должны сколь-ко то пустить на дело, как милостыню кинуть.
А остальное - свое, честно заработанное.

Это я не применительно к меркурию, это я про систему в целом.

Объясню проще. Допустим у многих идет работа по расписанию.
Думаю, половина запускает раз в 15 минут, четверть раз в полчаса, четверть раз в час.
В результате в 12:00 к ним валится несколько тысяч запросов списков
от всех интеграторов и все получают дружную 12-ю ошибку.

с 1С не совсем так, но там тоже не все хорошо.

Vladimir2017 wrote:

TWAIN wrote:Пол встречи толкали разные продукты - шлюзы. Четверть встречи рассказывали, что виноваты во всем мы сами.

Кстати, я подозреваю что API просаживается именно от этих продуктов, которые они и толкают. Поскольку нетиповые решения занимают значительно меньшую часть рынка.

Да, это озвучено давно. Виноваты на 70% 1С, которые выпустили поддержку меркурий 15 июня.
Через 10 дней все запустили обновление списков и с 25 числа мы фиксируем проблемы.

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

TWAIN wrote:
1) Нам были перечислены нежелательные практики:
- Опрос истории изменений делать не чаще чем каждые 15 минут, а лучше реже.

А это - у кого как идут изменения. У кого-то один раз вечером все пришедшее погасить, а у кого-то постоянно идут исходящие, входящие и производственные! Или рассчитывали на 2 ларька на всю страну?

Ну, исходящие вы знаете ID и запрашиваете конкретно по ID, производственные - тоже.
Речь идет о синхронизации больших списков.

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

TWAIN wrote:
- Стараться в пределах минуты делать равномерную загрузку шлюза

Как как? Они там сугубо альтернативно-одаренные личности? У них не 2 источника запросов! О законе больших чисел никогда не слышали? Само равномеризуется, если источников много. Даже при синхронизации времени на источниках запросов по атомным часам и из интернета, все равно, разная пропускная способность и загрузка каналов между источниками запросов и шлюзом равномеризует нагрузку (в пределах секунд, конечно, а не суток).

Тут тоже понятно что хотят. В 1С все задания любят сбрасываться на 1 секунду.
30 регламентных заданий, а запускаются все одновременно.

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

TWAIN wrote:
- По старым заявкам просят ничего не запрашивать, через три дня они уже уходят в архив и недоступны для запроса.

О! Наконец-то озвучено время, которое заявка может быть in_progress!

Уже второй раз озвучена. Сначала было 10 минут. Потом увеличили до часа, кажется. Сейчас - полчаса.
Мы и сами эмпирически получали и они сказали.

Обещали дать возможность погасить документы которые не гасятся, а потом синхронизировать правила:
сейчас выписать дает, а погасить - нет.
Про строковые названия не говорили.

sup wrote:Своей слабой реализацией они добились того что нагрузка на базу идет паразитная (без конечного результат), которой могло бы и не быть.
Я гарантирую что если я буду делать 1 запрос в день у меня он не отработает, даже 2 запроса в день, где балансер в этом случае находится?
Прально нигде ибо его нет.
А то что мы во всем виноваты это конечно, у них 20 кратный запас прочности был а в итоге и в 2 раза не смогли увеличить поток документов.

Ну, это все видели, что что вы ждете от поколения майкрософт.
Хотя нет, это уже дети андроид. Избыточность видна любому, у кого есть глаза и желание.

Это они новый конвейер обработки тяжелых запросов тестируют.
Готовьтесь, работать будет от силы неделю - две, потом встанет окончательно.

sup wrote:

TWAIN wrote:Не было такого. Там другой смысл был. Рабочая рекомендация была и есть одна, сканировать на входе qr код и по нему запрашивать. А там говорили что списки надо запрашивать реже. Окна запрашивать последовательно, между запросами паузы.

Реже не реже, запрашиваю пока не получу ответа т.к. первые 10 запросов а то и более могут с ошибкой вывалить сразу и это после простоя 3х-8и часового.
Окна так и так последовательно, паузы есть но это не влияет особо т.к. отлупы получаешь спонтанно.

Всю ночь бились - перепробовал окна 1000, 500, 250, 100, приходят одинаково.
Или не идут вовсе, или проходят за 2-3 минуты. С 2-х ночи
ночи начали ходить нормально, до этого 2 дня не ходили.

Не было такого. Там другой смысл был. Рабочая рекомендация была и есть одна, сканировать на входе qr код и по нему запрашивать. А там говорили что списки надо запрашивать реже. Окна запрашивать последовательно, между запросами паузы.

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

Пол встречи толкали разные продукты - шлюзы. Четверть встречи рассказывали, что виноваты во всем мы сами.
Четверть встречи - вопросы, но ответы на них были слабенькие.
Раньше у меня конспект занимал несколько листов, а сейчас два абзаца.

1) Нам были перечислены нежелательные практики:
- Опрос истории изменений делать не чаще чем каждые 15 минут, а лучше реже.
- Подбор записей журнала перед отгрузкой делать не из меркурия, а из своего регистра остатков.
- Стараться в пределах минуты делать равномерную загрузку шлюза
(регламентные задания у некоторых сваливаются все на одну секунду в запросах).
- Результат по заявке запрашивать через определенный интервал и с определенной периодичностью,
некоторые долбят сразу после отправки по 15 раз в секунду.
- По старым заявкам просят ничего не запрашивать,
через три дня они уже уходят в архив и недоступны для запроса.
- Сохранять у себя ответ по заявке, не запрашивать результат раз по 30
- Следить за объемом записей в ответе, не запрашивать новые смещения до бесконечности
- Не злоупотреблять объединениями записей и инвентаризацией,
некоторые дообъединялись до того что у них диапазон срока годности охватывают период до года.
- Анализировать системные ошибки и исправлять схему работы
- Анализировать ошибки в бизнес-логике и исправлять схему работы
- Запрет на интеграцию через автоматизацию веб-сервиса.

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

Начиная с ноября месяца начнутся проводиться проверки нашей работы в Меркурий, со всеми вытекающими.

Готовится кнопка блокировки получения товара/возврата от поставщиков с пониженным компартментом,
а также от тех, кто работает в интерфейсе 1.4.

Все остальное - больше похоже на отмазки.

Побывали вчера на конференции разработчиков, прониклись какие мы все неумехи, не можем запросы писать по бест-практис,
а оказывается с 4 часов ночи на 23 число вообще перестали приходить входящие ЭВСД. Окно 1000 (раньше работало) не проходит.
Делается 100 попыток с приличными интервалами (100 попыток занимает 23 минуты), и все равно хрен.
Окно 500 - прошло только одно окно из 10. Окно 250 - пока получено только два окна, висит по 10 минут на обработке одного окна.
Но окон должно быть 20!
Понятно, когда такие "архитекторы", которых нам вчера представили, странно что оно вообще взлетело.