Обновление 6.8

Слышали новость
http://vetrf.ru/vetrf/news/27290.html

а также сведения о связанных с записью журнала ВСД, то есть в ответе не будут элементы <vd:laboratoryResearch>…</vd:laboratoryResearch> и <vd:vetDocument> …</vd:vetDocument> будут отсутствовать.

Ну лабораторные исследования может и не нужны. Хотя это виднее разработчикам систем которые УЖЕ РАЗРАБОТАНЫ.

Но убирать теги <vd:vetDocument> …</vd:vetDocument>
ЭТО ВЕРХ БЕЗГРАМОТНОСТИ. ПРИ ЭТОМ СООБЩАЮТ ЗА 1 ДЕНЬ до ОБНОВЛЕНИЯ.

Разработчики МЕРКУРИЯ Вы вообще раньше когда либо, что нибудь разрабатывали???????????????????????????????

Удаление объектов в любых системах (особенно связанных с миграцией данным между 1000 систем) сложная, ответственная задача.
За 1 день её решить невозможно.
Вы подумали об разработчика (ВАШИХ КОЛЛЕГАХ МЕЖДУ ПРОЧЕМ) интеграционных решений.

СРОЧНО ОТМЕНЯЙТЕ ЭТО РЕШЕНИЕ пока РОССИЯ не ВСТАЛА В ПРОБКЕ ПОД НАЗВАНИЕ МЕРКУРИЙ.

В пятницу 13-е самое то

Э!! вы чо там тварите! я дежурный на этой неделе.. Итак уже пол второго ночи, а я отправляю ВСД. То регионализация, то нет РСХН, то срачка, то болячка...

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

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

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

"Уважаемые" разработчики, а почему эти изменения было не сделать в новой версии API, скажем 2.2? И ограничить срок действия протоколов 2.0,2.1 несколькими месяцами/кварталами.

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

Фармакс wrote:А сейчас, вы дали 24 часа для доработки, отладки и внедрения!!!

а как вы собираетесь отлаживать, если запросы ещё обрабатываются по-старому, а после обновления сразу будут приходить ответы по-новому?

hawksib wrote:

Фармакс wrote:А сейчас, вы дали 24 часа для доработки, отладки и внедрения!!!

а как вы собираетесь отлаживать, если запросы ещё обрабатываются по-старому, а после обновления сразу будут приходить ответы по-новому?

"Рабочие" выходные никто не отменял.

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

Но если следовать логике оптимизации, так они бы убрали из запроса погашения ВСД все, кроме uuid ВСД, в случае полного согласия!
Там запрос уменьшился бы на 2-3 порядка.

И по списку измененных уже посылали бы только guid'ы измененных, чтобы уж совсем "оптимизировать"!
А всё-равно дополнительный запрос делать, так зачем столько инфы выдавать?

Путь бы на все запросы кроме примитивных возвращались только идентификаторы.
А чего? нагрузка на сервера сразу бы упала в ноль.
Тогда бы сделали нормальную распределенную систему. Примитивные запросы к справочникам идут на одни сервера.
А запросы application на другие и они бы никак не пересекались. Вообще бы нагрузка упала

Фармакс wrote:

hawksib wrote:

Фармакс wrote:А сейчас, вы дали 24 часа для доработки, отладки и внедрения!!!

а как вы собираетесь отлаживать, если запросы ещё обрабатываются по-старому, а после обновления сразу будут приходить ответы по-новому?

"Рабочие" выходные никто не отменял.

у нас в выходные отгрузка не прекращается

Ай молодцы!
-100500 к карме

ТОГДА УЖ ПЕРЕНОСИТЕ СТАРТ
ВЕРНИТЕ "БУМАЖКИ"!!!!

Алексей Баранов wrote:И по списку измененных уже посылали бы только guid'ы измененных, чтобы уж совсем "оптимизировать"!

+ хорошая тема
видимо решили совсем уж не шокировать

Добрый день, коллеги.
Являюсь разработчиком решений для обмена данными с ЕГАИС и теперь с Меркурием. По ЕГАИС конечно тоже были сложности в начале, и достаточно спорных решений в проектировке системы. Тоже его разработчиков школьниками называли за непродуманную реализацию проекта в рамках страны. Но это как оказалось были цветочки. Сейчас на фоне Меркурия ЕГАИС просто конфетка, хоть и отрабатывает запросы в среднем по 3-5 минут, но отрабатывает. И логика какая-то есть. А здесь в этих версионированных справочниках и партиях, куче разновидностей ошибок и их далеко не сразу понятного содержания, можно просто с ума сойти.
В целом системы очень похожи между собой, так почему нельзя было проанализировать опыт коллег и сделать нормальное решение, а не усложнять систему настолько, что сами справиться теперь с ней не могут. Одна из главных претензий конечно гашение - это целый аттракцион безумия - все поля надо в точности передать в ответе, иначе не погасится.
В ЕГАИС все просто - принимаем продукцию - отправляем ИД ТТН и тэг Accepted, не принимаем - Regected - все просто и понятно и мимнимальная нагрузка на сервер. При расхождениях - номера строка (в Меркурии сделать ИД ВСД) и реальное количество. Все, остальное должен сделать сервер, посчитать разницу и вернуть отправителю. А XML файл Меркурия километровой длины надо же еще разобрать, проанализировать, сравнить с данными в ВСД и выслать ошибку пользователю.
Про пользователей и роли я вообще молчу, зачем так все усложнили не понятно.
В общем, в такой ИС как Меркурий считаю работать на данном этапе просто недопустимо, нужно переделывать глобально архитектуру хранения данных и общения с пользователями. Создайте экспертный совет, проконсультируйтесь с разработчиками ЕГАИС, других больших ИС, и сделайте систему, отвечающую текущим стандартам разработки. Наладьте общение с пользователями - выходит ошибка с ролью пользователя, решить можно только через техподдержку, которая просто не отвечает, а пользователь сам ничего сделать не может. Непрофессионально. Точка.

Uncore wrote: Непрофессионально. Точка.

Добро пожаловать в сообщество интеграторов меркурия, думаю многие в первом сообщении подобное пишут

Uncore wrote: Непрофессионально. Точка.

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

Даже не пытайтесь - тут Вас, к кому Вы обращаетесь, не услышит. А если и услышит, ничего не будет менять! Как Вы не поймёте, в государственной системе обратного хода не бывает.