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

nifor wrote:

Vladimir2017 wrote:

BFT wrote:Да, свое. Размер последнего отета сейчас посмотрел 4,5Мб.

Возможно это значительный фактор, у нас алгоритм работы примерно такой - раз в минуту запрашиваются данные по складам и документам на всех площадках, временной диапазон - дата последнего документа/записи. Раз в час запрашиваются все непустые складские записи. Помимо этого документы и записи получаем после создания через опрос по ApplicationID. Механизм избыточен, но нам важна точность. Максимальный объем документа получается чуть больше 2 мб. За сегодня 8 ошибок HTTP/500 и не одного APLM12.

*Update - про APLM12 соврал, не туда посмотрел. Сейчас проверил и насчитал около 300. Но работе это не помешало.

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

Основные рекомендации разработчиков с семинара интеграторов:
http://меркурий-россельхознадзор.рф/блог/рекомендации-разработчиков-бизнес-с/

Вопросы и ответы часть №1:
http://меркурий-россельхознадзор.рф/блог/команда-россельхознадзора-отвечает/

Shadasp wrote:
Вопросы и ответы часть №1:
http://меркурий-россельхознадзор.рф/блог/команда-россельхознадзора-отвечает/

Все готовы — приходите, я сколько раз говорил? Я же и предлагал делать службу поддержки, чтобы все как положено. Ну нет если у нас ресурсов…

Верните разработчиков на форум! На форуме куча вопросов без ответов и самопомошь.

У нас изначально валидации не было, потом мы ее сделали

Интересный подход к разработке.

nifor wrote:На встрече последней с разработчиками меркурия это(запросы остатков ежеминутно) было названо плохой практикой и как я понял будет грозить аудитом (сроки не ясны) и какими-то карами я полагаю ))

Много запросов, которые в 80% случаев не выдают никаких данных, систему не грузят там тупой перебор индекса и практически моментальный пустой ответ. Систему грузят запросы всего склада до создания документа и после. Если я по их требованиям сделаю интервал в 15 минут, то я оставлю один запрос, но не диапазон от последней записи, а на весь склад, что будет грузить систему реже но стабильней и больше.

Shadasp wrote:
Основные рекомендации разработчиков с семинара интеграторов:
http://меркурий-россельхознадзор.рф/блог/рекомендации-разработчиков-бизнес-с/

Вопросы и ответы часть №1:
http://меркурий-россельхознадзор.рф/блог/команда-россельхознадзора-отвечает/

Опять во всем виноваты разработчики?

Давайте разберем эту жалкую попытку перевесить на нас свою вину:

По мнению Алексея, оптимальное значение периода- это запрос за сутки, не более.

А если я смотрю по последнему документу/складской записи? А она у меня на этой площадке была месяц назад? Запрос к БД власовцев в этом случае будет моментальный и ответ пустой, нагрузки никакой.

По мнению Алексея, оптимальное значение периода- это запрос за сутки, не более.

А тут я беру другую площадку по которой у меня, к примеру, 15000 документов входящих и даю власовцам запрос по их же рекомендациям, каждые 15 минут, но с начала суток.

Что из этого выходит? Власовцы не знают как работает их система.

Следующий момент- определение страниц. Размер страниц сейчас ограничен 1000 записями. Это зависит от характеристик каждого предприятия, от общего объема документов, которые содержатся в базе, от интенсивности оформления, которые существуют для каждой определенной площадки.
...
Рекомендации: эмпирически подбирать это значение.

Я предлагаю эмпирически подбирать власовцам зарплату. Берем 100% от трудового договора и начинаем уменьшать по 10%, пока не снизится APLM12 И HTTP/500.

Общая рекомендация: тонко настраивать по каждому конкретному случаю.

Капитан Очевидность спешит на помощь.

Тестируют несколько вариантов доп. операций, функционал по получению историй изменений, в том числе до возможного варианта истории загрузки в виде архива.

Это особенно обрадует разработчиков которые реализовывали работу через SOAP, а будут вынуждены писать парсер для xml.

Опрос истории изменений каждую минуту / 5 минут.
То есть история запросов каждую минуту происходит по одной площадке. Для чего не понятно с учетом того, что любой запрос который приводит к изменению в системе — возвращает актуальные сведения, которые можно сохранить.

Внезапно - для актуальности данных. Данные получаются часто, но крохами. Загрузки на сервер никакой, если власовцы не забыли создать индексы по тем полям, по которым у них можно фильтровать запрос.
Кстати, а что мне сделать с полученной час назад XML? Эти данные закэшированы, но актуальность свою потеряли примерно через 5 минут после получения.

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

А те сведения не возвращаются. Запрос по ApplicationID висит в IN_Process двое суток и все. Я больше данных этих не получу нигде.

Подбор записи журнала перед отгрузкой

Хоть где-то попали пальцем в проблему. Но впрочем, хорошая система должна выдерживать и некорректную работу клиентов.

Повторное получение результата заявки.Наблюдают повторное получение результата. Зачем?

А не пытались у хозов узнать? Возможно у них заявка в статусе ин_прогресс.

Количество систем которые будут интегрированы в финале с Меркурием и достигнет примерно сотни тысяч систем в не отдаленном будущем.

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

О том, как эти же ошибки решает ЗАО АСП рассказал в своем интервью Сергей Барышев ген. директор.

Ну и традиционное "Покупайте наших слонов". Бессмысленных и беспощадных.

Vladimir2017,
+100500 по всем пунктам

Shadasp wrote:

nifor wrote:

Vladimir2017 wrote:

BFT wrote:Да, свое. Размер последнего отета сейчас посмотрел 4,5Мб.

Возможно это значительный фактор, у нас алгоритм работы примерно такой - раз в минуту запрашиваются данные по складам и документам на всех площадках, временной диапазон - дата последнего документа/записи. Раз в час запрашиваются все непустые складские записи. Помимо этого документы и записи получаем после создания через опрос по ApplicationID. Механизм избыточен, но нам важна точность. Максимальный объем документа получается чуть больше 2 мб. За сегодня 8 ошибок HTTP/500 и не одного APLM12.

*Update - про APLM12 соврал, не туда посмотрел. Сейчас проверил и насчитал около 300. Но работе это не помешало.

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

Основные рекомендации разработчиков с семинара интеграторов:
http://меркурий-россельхознадзор.рф/блог/рекомендации-разработчиков-бизнес-с/

Вопросы и ответы часть №1:
http://меркурий-россельхознадзор.рф/блог/команда-россельхознадзора-отвечает/

Вопросы и ответы часть №2:
http://меркурий-россельхознадзор.рф/блог/команда-россельхознадзора-отвечает-2/

Доброго дня! Уже больше суток не можем ни получить ВСД, ни обновить записи складского журнала - APLM0012
У кого то такая же свистопляска?

Волгоград.
Висим с 6 утра.
Ни входящие, ни транспортные, НИЧЕГО.
APLM00012

max_01 wrote:Волгоград.
Висим с 6 утра.
Ни входящие, ни транспортные, НИЧЕГО.
APLM00012

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

Обысчно это запрос остатков и входящих всд - на этом все.

У нас, на данный момент вроде сильных подвисаний запроса остатков нет.

Ezhik_v_Tanke159rus wrote:Доброго дня! Уже больше суток не можем ни получить ВСД, ни обновить записи складского журнала - APLM0012
У кого то такая же свистопляска?

интересно для статистики, какой город ? и сколько примерно складкских записей у вас сейчас ?

Ezhik_v_Tanke159rus wrote:Доброго дня! Уже больше суток не можем ни получить ВСД, ни обновить записи складского журнала - APLM0012
У кого то такая же свистопляска?

Петрозаводск. С утра запрос складских остатков с примерно 15 попытки пролетел.
Техподдержка рекомендовала делать запрос за период не более суток, количеством записей не более 500 и не чаще раза в 15с.
Все выполнялось, кроме количества запрашиваемых записей (была 1000).
Урезали до 100, и что? Опять APLM0012.
На складе подотчетной продукции буквально единицы записей.

Техподдержка обещает исправление "в следующем релизе", который должен выйти "в первой половине августа".

milker wrote:
Урезали до 100, и что? Опять APLM0012.

Практика показывает, что урезание до 1 тоже не помогает.

max_01 wrote:

milker wrote:
Урезали до 100, и что? Опять APLM0012.

Практика показывает, что урезание до 1 тоже не помогает.

в конце этой неделе, начале следующей уже протестируем работу протокола 2.1 - описание схем много обещающее, надеюсь там будем счастье.

Всем доброго времени суток! Вот и закончился первый месяц "эксплуатации" системы Меркурий.
Как по мне, так лучше бы назвали систему "Нибиру", это такая планета, которая по мнению некоторых конспирологов вращается вокруг Солнца на расстоянии, примерно соответствующем орбите Земли, но в "противофазе", т.е из-за Солнца мы её никогда не увидим... но она таки есть! Я это к тому, что подобную систему могли выдумать только злые пришельцы с этой самой Нибиру, про которую нам периодически рассказывает Прокопенко на известном канале РенТВ.
Так вот... оптовая контора, для которой я писал интеграцию с Меркурием, 1 июля удачно "соскочила" с темы, благодаря тому, что был введен "уточненный перечень готовой продукции не подлежащей сертификации в Ветис".
После этого я только читал форумы, часто крестился (хотя вроде бы атеист), и покрывался холодной испариной от мысли, что и меня могла "не минуть чаша сея...".
Честно говоря было с чего... сообщения на форумах напоминали события июля 1941 года: тут прорвали фронт, тут очередная армия попала в "котел", а войска неприятеля стальным катком катятся к Днепру... всё пропало и мы все умрем. Причем новыми "танковыми клиньями" информационного агрессора командует вовсе не Гудериан... а всё тот же генерал Власов (Совпадение? Не думаю...). Сюрреализм.
Меня интересует один вопрос, и не важно кто мне на него соизволит ответить:
- Это порождение недружественного нам разума всё же перенесут на 1 июля 2019 года? Или это уже раз и навсегда - как НДС 20% и "пенсионная реформа"? Вопрос не праздый, потому как уверен, что как только изнасилованные АРI Ветис программисты-интеграторы найдут способ "слегка дружить" с данной системой, список расширится на всю "готовую продукцию и молочку" изначально выброшенные из списка... и кошмар возобновится в новых зловещих декорациях глобального Апокалипсиса. Потому Важно понять - уже сейчас следует купить белый саван и подвывая медленно ползти в сторону кладбища... либо есть надежда на альтернативные варианты развития событий?

Vlad74ru wrote:
- Это порождение недружественного нам разума всё же перенесут на 1 июля 2019 года?

на эту волнительную тему есть другая ветка форума! даже две.

Потому Важно понять - уже сейчас следует купить белый саван и подвывая медленно ползти в сторону кладбища... либо есть надежда на альтернативные варианты развития событий?

однозначно. мы фсе умрем.