Не работает меркурий

Унашев wrote:пол ляма на интеграцию? Мы купили от визарда решение за 30 тыр, остальное допилили силами своих программистов. Даже премию им не выдали, это же их работа. Внедрили на 2 птицефабирках и 2 мясокомбинатах.

Под 1С и покупать ничего не надо, готовые компоненты есть и бесплатно. Там где бизнес начинается от небольших ERP, за 500к.р. к вам разработчики приедут только кофе попить

Vladimir2017 wrote:

Shadasp wrote:Давайте разбираться какие были проблемы:
1. Сервер Меркурия несколько раз уходил в данун по часу, и были небольшие перегрузки по 15 минут. - тут мы ничего не сделаем, разве что сможем заранее выписать практически все сертификаты и оставшиеся дожать, через вебку. Такие проблемы в течение дня возможны, но при этом не смертельны.

После старта сервер Мерка не работал фактически сутками, потому что назвать то работой невозможно. 95% запросов уходили в ошибки. В первые дни приходили документы не отвечающие схемам.

2. Меркурий тормозит и выдает ошибку APLM0012 - по сути это блокировка при высоких нагрузках, которую создают горе интеграторы и крупные компании не намерено, а некоторые намерено.

Вы самого главного не говорите. Ошибка12 выдавалась не по объему нагрузки от конкретного пользователя, она выдавалась всем, как говорил Власов "когда некий общий объем запросов исчерпан". Даже тем, кто специально делал решения с минимальной нагрузкой на Мерк.

Давайте, так я не политик поэтому могу говорить открыто.

1. Такого не было чтобы Меркурий не работал сутками... Максимум, что было это что он не работал ночью несколько часов и днем 2-4 часа, это максимальные простои которые были.
Как только меркурий ложится, нас засыпают сообщениями, а кто знает мой номер звонят утром

.

Я у меня на это очень четкий индикатор.

2. В первый день все работали, да подтормаживало - все жаловалось, что тормозит.
По мойму мнению (не знаю точную историю):

2.1 Разработчики попытались выключить блокировки вообще, и ночью 3 или 4 - все просто летало как реактивная ракета, клиенты были в шоке.
2.2 После меркурий засыпали запросами и он днем лег с 10:30 до 14:00 - пока разработчики не решили сбросить заявки и перегрузится;
2.3 После вернули блокировки и начали вводить ограничения на тяжелые запросы, я думаю это правильное решение - я слышал, что ЕГАИС в начале тоже вводил, что мол можно только несколько раз в день запрашивать остатки (точную информацию не знаю, взял и слов ИТ директора одной из компаний).

2.4 Фактически документы все регались, но чтобы выполнять тяжелые запросы типо - запроса остатков из меркурия, нужно было отправить примерно 5 заявок чтобы получить свои остатки.

Да, сложно, но возможно. Далее мы начали все кешировать. Сейчас есть кое, где проблемы с логикой кеширования, занимаемся решение этих вопросов.

2.5 Сейчас тяжелые запросы иногда проходят сразу, иногда только с 5 попытки - мы этот процесс автоматизировали и фактически пользователи видят, только легкие торможения при кеширование данных.

Основные запросы регистрации документов ВСД, всегда отрабатывали корректно, редко выходят блокировки. - если упираться на это высказывание, то меркурий отрабатывал 95% всех запросов, но согласен если упираться на цифры, то это лукавство.

Vladimir2017 wrote:

Унашев wrote:пол ляма на интеграцию? Мы купили от визарда решение за 30 тыр, остальное допилили силами своих программистов. Даже премию им не выдали, это же их работа. Внедрили на 2 птицефабирках и 2 мясокомбинатах.

Под 1С и покупать ничего не надо, готовые компоненты есть и бесплатно. Там где бизнес начинается от небольших ERP, за 500к.р. к вам разработчики приедут только кофе попить

вот видите есть решения, про них и нужно говорит.

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

Но работать, можно и это все равно, быстрее чем забивать вручную или печатать бланки, а потом их подписывать.

Shadasp wrote:Давайте, так я не политик поэтому могу говорить открыто.

И сразу начинаете как политик? Ай-яй-яй

1. Такого не было чтобы Меркурий не работал сутками...

Тут один мастер лингвистического жонглирования тоже утверждал что Меркурий то оказывается работает! Это только АПИ не работает и только версии 2.0. Прям как российского телевидения послушал.

Максимум, что было это что он не работал ночью несколько часов и днем 2-4 часа, это максимальные простои которые были.

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

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

Не надо рассказывать про высокий моральный дух коллектива человеку имеющему доступ к логам прокси (с) У меня логи Мерка ведутся с апреля, я ради интереса могу написать простенький анализатор что бы посмотреть как и что работало. Но мне это нафиг не нужно потому что работу Мерка в старт я наблюдал в онлайне.

Да, сложно, но возможно. Далее мы начали все кешировать. Сейчас есть кое, где проблемы с логикой кеширования, занимаемся решение этих вопросов.

У меня с начала разработки все кешировалось, ответы на мои запросы редко превышали 300к, почему я поимел проблем?

2.5 Сейчас тяжелые запросы иногда проходят сразу, иногда только с 5 попытки - мы этот процесс автоматизировали и фактически пользователи видят, только легкие торможения при кеширование данных.

Мерк не оценивает толщину запроса. Он рубит запросы когда они превышают общий лимит.

Основные запросы регистрации документов ВСД, всегда отрабатывали корректно, редко выходят блокировки.[/b] - если упираться на это высказывание, то меркурий отрабатывал 95% всех запросов, но согласен если упираться на цифры, то это лукавство.

Тут вы правы, но когда мы говорим Мерк работает мы предусматриваем что он работает весь, а не всасывает заявка как черная дыра.

Shadasp wrote:
вот видите есть решения, про них и нужно говорит.

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

Но работать, можно и это все равно, быстрее чем забивать вручную или печатать бланки, а потом их подписывать.

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

Vladimir2017 wrote:

Shadasp wrote:
вот видите есть решения, про них и нужно говорит.

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

Но работать, можно и это все равно, быстрее чем забивать вручную или печатать бланки, а потом их подписывать.

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

согласен на 1с сложно обрабатывать большие объемы, но пока мы сделали на нем + делаем вставки Python чтобы ускорить процессы.

пока тестировали на 200 000 всд в день на одной конфе в один поток.

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

Коллега, если мы говорим про большой бизнес, то внедрение меркурия позволила в месяц сэкономить от 100 000 до 900 000 рублей.

одна справка в среднем стоила 30 рублей, выписать нужно на каждую точку доставки их порядка 1 000, итого получаем, что предприятие тратило 30 000 рублей в день и на 22 рабочих дня, это составляет 660 000 рублей.

Сейчас эта цифра будет примерно 100 000 - 200 000 рублей.

И вы не хотите тратить сэкономленные деньги на двух дополнительных операторов по 40 000 рублей на месяца или заплатите вет.станции они будут просто счастливы дополнительному заработку, а прибыль всеравно будете получать.

В такой ситуации я считаю, это больше управленческий просчет.

В ближайший месяц придется подстраиваться и программистам не спать, это уже такая участь.

А из технической части, перечитайте мой предыдущий пост.

Ошибка APLM0012 - теперь может выдаваться, когда не корректно заполнен документ на отправку, и нужно все перепроверить, как могли цели реализации измениться, могли номенклатуру в вебке подправить и не перезаписать.

Вариантов куча, если у вас постоянно сыпится данная ошибка, у вас есть скорее всего есть ошибка в запросе или изменилась структура заполнения, а вы это еще не отразили.

Это я Вам по человечески советую.

Shadasp wrote:В такой ситуации я считаю, это больше управленческий просчет.

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

В ближайший месяц придется подстраиваться и программистам не спать, это уже такая участь.

Сегодня праздник у разрабов,
ликует программерия,
бессонную ночь нам устроил опять
Николай Анатольевич Власов.

Shadasp wrote:Ошибка APLM0012 - теперь может выдаваться, когда не корректно заполнен документ на отправку, и нужно все перепроверить, как могли цели реализации измениться, могли номенклатуру в вебке подправить и не перезаписать.

Буквально пару дней назад Власов говорил обратное. Можете подтвердить свои слова?

Vladimir2017 wrote:

Shadasp wrote:Ошибка APLM0012 - теперь может выдаваться, когда не корректно заполнен документ на отправку, и нужно все перепроверить, как могли цели реализации измениться, могли номенклатуру в вебке подправить и не перезаписать.

Буквально пару дней назад Власов говорил обратное. Можете подтвердить свои слова?

Не знаю как для вас это сделать.

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

Если запрос регистрацию документа заполнен корректно, то он практически всегда проходит регистрацию.

Shadasp wrote:

В ближайший месяц придется подстраиваться и программистам не спать, это уже такая участь.

А кушать можно? И в туалет отлучаться позволите?

kofeinik wrote:

Shadasp wrote:

В ближайший месяц придется подстраиваться и программистам не спать, это уже такая участь.

А кушать можно? И в туалет отлучаться позволите?

В туалет нельзя! А вдруг вы там GetStockEntryChangesListOperation за три года вызовите?

Vladimir2017 wrote:

kofeinik wrote:

Shadasp wrote:

В ближайший месяц придется подстраиваться и программистам не спать, это уже такая участь.

А кушать можно? И в туалет отлучаться позволите?

В туалет нельзя! А вдруг вы там GetStockEntryChangesListOperation за три года вызовите?

А почему не вызвать то ? Процедура доступна, ограничений ни в документации ни при попытке вызова сервером не накладывается.
аналогично почему я должен кешировать остатки в базе ? Есть же способ получить их заведомо акутальные и корректные из Меркурия. Нужно мне получение записей журнала делать 200 раз в минуту почему не делать то ? Запрета на такие действия нет.
Что Меркурий не справляется с нагрузкой так надо или разработчика Меркурий приводить в состояние что бы справлялся или официально менять требования к нагрузке.

benzol45 wrote:А почему не вызвать то ? Процедура доступна, ограничений ни в документации ни при попытке вызова сервером не накладывается.
аналогично почему я должен кешировать остатки в базе ? Есть же способ получить их заведомо акутальные и корректные из Меркурия. Нужно мне получение записей журнала делать 200 раз в минуту почему не делать то ? Запрета на такие действия нет.
Что Меркурий не справляется с нагрузкой так надо или разработчика Меркурий приводить в состояние что бы справлялся или официально менять требования к нагрузке.

В нормальной, классической реализации соглашусь, в случае с Меркурием отмечу что уже полгода назад стало ясно что надо делать кэширование.