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

Николай Власов wrote:

NikoV wrote:

Николай Власов wrote:

NikoV wrote:Это как в советских автомобилях - 3 положения двери, ОТКРЫТА, ЗАКРЫТА и НЕ ЗАКРЫТА. Так и ФГИС Меркурий 3 состояния - РАБОТАЕТ, НЕ РАБОТАЕТ и В ШТАТНОМ РЕЖИМЕ.

Юмор Болотной площади ...
А вы вообще вдели-ли советские автомобили? Волгу 21-ю, например? Или шестерку первых выпусков? Или ЗИМ конца 60-х? Годочков - то вам сколько, милейший?

44 года уже. И певая машина у меня была - ВАЗ 2106. А у деда была 21 Волга. Помню хорошо. Я 26 лет в ИТ отрасли. Не одну информационную систему разработал и внедрил, пусть и не таких масштабов. Опыт есть немалый. А сколько Вы Николай Анатольевич в ИТ отрасли, раз взялись за такую ИС?

Как считать ... если от моего первого сисадминства, то оно было примерно с 86, если от первой работающей программки (программой то чудо на перфокарте я б сегодня не назвал), то по-моему, 88, если с первого програмного комплекса, то 2007. И я, кстати, сейчас не IT-шник и уж тем более не программист. У меня совсем другая работа.
И что все внедряемые вами системы сразу работали так, что и совершенствовать ничего не пришлось?

Все это напоминает разговор в мужской бане ........

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

1) Система построена не на объектной модели (либо псевдо объектной) иначе как объяснить разные результаты в ответах на разные запросы (Например GetVetDocumentByUuidOperation и GetVetDocumentChangesListOperation). (класс vetDocument имеет разные теги). Естественно на мой субъективный взгляд со стороны.
2) Синхронизация справочников Цербер и Меркурий хромает. В Веб интерфейсе Меркурий не находятся площадки которые через API активные и последнии (Active, Last=True).
3) Не реализованы спец. поля в API в записях журнала продукции для целей интеграции, а также поля примечания и верх не профессионализма Номер записи в веб интерфейсе.
В результате чего на заметку Разработчикам приходится долбить ресурс https://mercury.vetrf.ru/pub/operatorui?_action=checkVetDocument для парсинга этого номера. И это делают миллионы пользователей так как искать по GUID в веб интерфейсе нереально. Сами попробуйте вбить 36 символов ручками в указанный ресурс с печатной формы (на сколько вас хватит) чтобы найти номер в веб интерфейсе.
И мне лично пришлось заполнять несколько тысяч выписанных ВСД атакуя этот сайт. В результате я заметил увеличение APLM12 на запросы GetVetDocumentListOperation через API.
Т. е в моем понимании идет обращение к единой БД и приоритет у сайта выше.
Вот добавив Номер в ответ Вы реально уменьшите обращения к БД в разы если не в 10 раз.
4) Все запросы к БД должны были изначально содержать фильтры по ЛЮБЫМ поля выборки. Это принцип удачной универсальной системы. Чем больше Фильтров темь меньше выборка - тем быстрее ответ и меньше нагрузка на систему.
5) Подвисание запросов в статусе "В процессе" или некорректные ответы. При этом непонятен результат. Система должна работать четко.
1) Запрос - ответ об успешном получении запроса и возврат ID
2) Начало транзакции
3) Обработка запроса и получение результата
4) Формирование ответа по ID
5) Фиксация транзакции
6) Запрос на получение результата-отправка результата
6) Ошибки в системе должны быть информативны и понятны место возникновения ошибки, разгребать запрос в 1000 строк вобще не айс.
7) Отсутствуют транзакции прочих списаний остатков с журнала продукции (такие как розничные продажи, благотворительность, передача на собственные нужны и т.п.) – все эти списания Меркурий предполагает решать инвентаризаций, что не является правильным и усложняет процесс, так как при инвентаризации нужно полностью повторять весь состав аналитики записи журнала, в место того, чтобы указать Guid записи и количество списания.
8) Сложность заполнения данных инвентаризаций через Ветис.Api (по какой-то причине, именно инвентаризацию нужно заполнять, используя не Guid записи, а Uuid /– версия журнала продукции, которая меняется при каждом изменении записи журнала продукции/, при этом требуется повторить абсолютно всю имеющуюся информацию журнала).
9) Используя Api 2.0 на данный момент в инвентаризации невозможно указать разрешение на ввоз (это необходимо для начала введения учета и ввода остатков в Меркурий).
10) "Необходимо реализовать правильную тех. поддержу:
1) Заявка
2) Ответ ваша заявка принята номер обращения 15124342
3) По вашему обращению 15124342 получен следующий ответ
и т.д. по всем правилам Help Desk"

"Кто не знает цену времени, тот не рожден для славы."
Люк де Клапье

Увы не про Меркурий на данный момент.

oneal13 wrote:Не долго мы радовались( снова запросы не возвращаются!

Вроде тоже работает.

and1024 wrote:

atitov wrote:Коллеги, есть информация о том, что вроде версия API 1.4 работает и корректно отвечает (по крайней мере получилось получить входящие ВСД).
Кто-нибудь подтвердите / опровергните.

У нас 1.4 работает. Но тоже своя интеграция.

Запрос на список ВСД работает??????? в 1.4

Аналогично...
Список ВСД так уже давно.

Вроде как заработало около 15-00.

Запрос на список ВСД также как и все последнии месяцы APLM12
Остальные работают сейчас.

Эта ошибка стала выскакивать очень часто в инвентаризации именно после обновления на 6.7
И стабильно, т.е у меня есть запросы которые НИКОДА не выполняются и ВСЕГДА "[APLM0012] An unexpected error has occurred while invoking target service operation."

Тех. поддержка в курсе.

Т.е решения нет ни какого.

Как строить интеграцию в таких случаях?

При добавление 1 записи через инвентаризацию API 2.0 такая ошибка почти всегда после обновления на 6.7.

Разработчики когда решиться проблема с
[APLM0012] An unexpected error has occurred while invoking target service operation.

??????????????????????????????????????

Тех. поддержка ни чего внятного сказать не может.
"Проблема с нашей стороны"
"Передано разработчика"
"Не знаю? что ответить"

Это перед запуском обязательной сертификации.

Проблема началось после обновления на 6.7

Работали с 01.01.2018 проблемы этой не было.

v.isaev wrote:Мало ли что в новостях пишут) Обновления разработчики делают по своему усмотрению

Информируем вас о предстоящем плановом обновлении системы Меркурий до версии 6.7 и обновлении интеграционного шлюза ВетИС.API до версии 2.1, которое состоится 7 июня 2018 г. в 17:00 (МСК).

в продуктиве Меркурий 6.7
В новостях было что обновление будет одновременно с 6.7.

Коллеги не работают ссылки на официальном сайте для Api2/1.
Это специально дабы не чего там делать.

Например.
http://api.vetrf.ru/schema/platform/services/2.1-last/application_v1.1.xsd

А мы хотели бы.

Yoreg07 wrote:по 7-ми заявкам уже час нет ответа о выполнении ... IN_PROCESS постоянно

Подтверждаю проблема сегодня появилась.
Мы отправляем каждые 5 мин запрос на измененные записи журнала.
Которые изменились с момента предыдущего запуска.

Cейчас опять опять повисли на IN_PROCESS
с 16.05.2018 12:23:24

Сейчас удалил повисшие запросы и новые прекрасно отработали.

работаем с начала года были похожие проблемы раза 2-3

Сегодня начались вновь.

Gmix wrote:

Yoreg07 wrote:Сейчас все мои заявки в статусе IN_PROCESS уже более часа ... опять тестируют что-то

У нас кстати тоже с 16.05.2018 11:13:02

В новостях ни чего не было.

Сейчас отправили вновь запросы, ответы пришли.

Что-то было в 11:10 версия Меркурия вроде не изменилась.

Yoreg07 wrote:Сейчас все мои заявки в статусе IN_PROCESS уже более часа ... опять тестируют что-то

У нас кстати тоже с 16.05.2018 11:13:02

В новостях ни чего не было.

hawksib wrote:целый день пытаюсь получить список ВСД за интервал дат, все время одно и то же

Ошибка при получении сертификатов за интервал дат: за 15 минут не был получен ответ по applicationId 77f307c9-f49b-408b-b032-2cab2be4982d

кароче незачёт

Это было в период тестирования?
Если да, то не факт, что не зачет.
Предупреждали, что будут валить систему

Вопросы к разработчикам.
Хотелось бы получить информацию по результатам тестирования.

1) Справились или нет сервера?
2) Если нет, то будет ли увеличение мощности (распараллеливание работы)?
3) Соизмерялись ли кол запросов с реальными данными за период?
4) Если ли запас производительности?

Ну и другие подробности интересны.