|
[Search] Поиск   [Recent Topics] Последние темы   [Hottest Topics] Горячие темы   [Members]  Список участников   [Groups] На главную страницу 
[Register] Регистрация / 
[Login] Вход 
Код ошибки MERC37387  XML
Индекс форума » Автоматизированная система МЕРКУРИЙ
Автор Сообщение
sergmercury


Зарегистрирован: 13/06/2018 10:11:32
Сообщений: 37
Оффлайн

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

Код ошибки - MERC37387 "Пользователь-инициатор запроса обязателен для заполнения"

В запросе инициатор указан, пример отправляемого запроса:
<soap-env:Envelope xmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/">
<soap-env:Body>
<ns0:submitApplicationRequest xmlns:ns0="http://api.vetrf.ru/schema/cdm/application/ws-definitions">
<ns0:apiKey>****</ns0:apiKey>
<ns1:application xmlns:ns1="http://api.vetrf.ru/schema/cdm/application">
<ns1:serviceId>mercury-g2b.service:2.1</ns1:serviceId>
<ns1:issuerId>****</ns1:issuerId>
<ns1:issueDate>2019-06-19T11:48:20.112000</ns1:issueDate>
<ns1:data>
<ns2:getStockEntryListRequest xmlns:ns2="http://api.vetrf.ru/schema/cdm/mercury/g2b/applications/v2">
<ns2:localTransactionId>al</ns2:localTransactionId>
<ns2:initiator>
<ns3:login xmlns:ns3="http://api.vetrf.ru/schema/cdm/mercury/vet-document/v2">****</ns3:login>
</ns2:initiator>
<ns4:listOptions xmlns:ns4="http://api.vetrf.ru/schema/cdm/base">
<ns4:count>1000</ns4:count>
<ns4:offset>0</ns4:offset>
</ns4:listOptions>
<ns5:enterpriseGuid xmlns:ns5="http://api.vetrf.ru/schema/cdm/dictionary/v2">****</ns5:enterpriseGuid>
<ns2:searchPattern>
<ns6:blankFilter xmlns:ns6="http://api.vetrf.ru/schema/cdm/mercury/vet-document/v2">NOT_BLANK</ns6:blankFilter>
</ns2:searchPattern>
</ns2:getStockEntryListRequest>
</ns1:data>
</ns1:application>
</ns0:submitApplicationRequest>
</soap-env:Body>
</soap-env:Envelope>


В ответ приходит такое сообщение:

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<receiveApplicationResultResponse xmlns="http://api.vetrf.ru/schema/cdm/application/ws-definitions">
<application xmlns="http://api.vetrf.ru/schema/cdm/application">
<applicationId>****</applicationId>
<status>REJECTED</status>
<serviceId>mercury-g2b.service</serviceId>
<issuerId>****</issuerId>
<issueDate>2019-06-19T11:48:20+03:00</issueDate>
<rcvDate>2019-06-19T09:54:01+03:00</rcvDate>
<prdcRsltDate>2019-06-19T09:54:02+03:00</prdcRsltDate>
<apl:errors xmlns:apl="http://api.vetrf.ru/schema/cdm/application">
<apl:error code="MERC37387">Пользователь-инициатор запроса обязателен для заполнения</apl:error>
</apl:errors>
</application>
</receiveApplicationResultResponse>
</soap:Body>
</soap:Envelope>

Может кто-то сталкивался и знает решение? Или у кого-то есть предположение, как это можно решить?
serg882


Зарегистрирован: 26/10/2017 11:52:09
Сообщений: 149
Оффлайн

Проверьте права пользователя на доступ к площадке запрашиваемой записи (через Меркурий.ХС в веб). Если делали работу с пользователями через АПИ, тогда обновите зоны ответственности для пользователя (нужно передать в запросе UpdateUserWorkingAreas все площадки на которые он имеет доступ).
sergmercury


Зарегистрирован: 13/06/2018 10:11:32
Сообщений: 37
Оффлайн

serg882 wrote:Проверьте права пользователя на доступ к площадке запрашиваемой записи (через Меркурий.ХС в веб). Если делали работу с пользователями через АПИ, тогда обновите зоны ответственности для пользователя (нужно передать в запросе UpdateUserWorkingAreas все площадки на которые он имеет доступ).


Спасибо, результат все тот же.
Права доступа к площадке в веб есть и пробовали от разных пользователей отправлять у всех права есть, ошибка все та же.
А по UpdateUserWorkingAreas получаю такой ответ: <apl:error code="MERC79386">Роль пользователя не позволяет изменять зоны ответственности.</apl:error> хотя инициатор является администратором.
nmzn1

[Avatar]

Зарегистрирован: 11/05/2017 09:25:20
Сообщений: 4035
Оффлайн

sergmercury wrote:Права доступа к площадке в веб есть и пробовали от разных пользователей отправлять у всех права есть, ошибка все та же.
А по UpdateUserWorkingAreas получаю такой ответ: <apl:error code="MERC79386">Роль пользователя не позволяет изменять зоны ответственности.</apl:error> хотя инициатор является администратором.

а в ветис-=паспорте не проверяли, есть ли у админа роль "управление зонами ответственности пользователей"
[WWW]
sergmercury


Зарегистрирован: 13/06/2018 10:11:32
Сообщений: 37
Оффлайн

nmzn1 wrote:
sergmercury wrote:Права доступа к площадке в веб есть и пробовали от разных пользователей отправлять у всех права есть, ошибка все та же.
А по UpdateUserWorkingAreas получаю такой ответ: <apl:error code="MERC79386">Роль пользователя не позволяет изменять зоны ответственности.</apl:error> хотя инициатор является администратором.

а в ветис-=паспорте не проверяли, есть ли у админа роль "управление зонами ответственности пользователей"


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


Зарегистрирован: 26/10/2017 11:52:09
Сообщений: 149
Оффлайн

sergmercury wrote:
nmzn1 wrote:
sergmercury wrote:Права доступа к площадке в веб есть и пробовали от разных пользователей отправлять у всех права есть, ошибка все та же.
А по UpdateUserWorkingAreas получаю такой ответ: <apl:error code="MERC79386">Роль пользователя не позволяет изменять зоны ответственности.</apl:error> хотя инициатор является администратором.

а в ветис-=паспорте не проверяли, есть ли у админа роль "управление зонами ответственности пользователей"


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


Самый простой способ проверить доступ: зайти в веб ХС на все площадки - Настройки - Настройки зон ответственности - выбрать пользователя - доступные площадки будут окрашены в зеленый цвет.
sergmercury


Зарегистрирован: 13/06/2018 10:11:32
Сообщений: 37
Оффлайн

serg882 wrote:
sergmercury wrote:
nmzn1 wrote:
sergmercury wrote:Права доступа к площадке в веб есть и пробовали от разных пользователей отправлять у всех права есть, ошибка все та же.
А по UpdateUserWorkingAreas получаю такой ответ: <apl:error code="MERC79386">Роль пользователя не позволяет изменять зоны ответственности.</apl:error> хотя инициатор является администратором.

а в ветис-=паспорте не проверяли, есть ли у админа роль "управление зонами ответственности пользователей"


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


Самый простой способ проверить доступ: зайти в веб ХС на все площадки - Настройки - Настройки зон ответственности - выбрать пользователя - доступные площадки будут окрашены в зеленый цвет.


Проверил и веб интерфейсе, с правами все в порядке, спасибо. Но ошибка возникает все равно, думаю все же проблема в другом.
serg882


Зарегистрирован: 26/10/2017 11:52:09
Сообщений: 149
Оффлайн

Возможно начали блокировать пользователей без СНИЛСА и телефона.
sergmercury


Зарегистрирован: 13/06/2018 10:11:32
Сообщений: 37
Оффлайн

serg882 wrote:Возможно начали блокировать пользователей без СНИЛСА и телефона.


СНИЛС был прописан, а телефон вот старый стоял, поменял на новый, но и это не помогло))
А так-то эти мастера могут подобное осуществить, даже не сомневаюсь, но думаю если бы забанили, то вообще ничего не отправлялось бы, а так одна на сотню вет. справка отправляется. Что вообще недоумение вызывает. Вчера вот с теми же данными, нормально работало. На прошлой неделе смена шлюза с 2.0 на 2.1 помогла исправить эту ошибку, теперь уже не работает и шлюз 2.1.

Может заблокировали, но не до конца или такой ошибкой пытаются свои тупники скрыть, типа это у вас проблемы, а не у нас.
nmzn1

[Avatar]

Зарегистрирован: 11/05/2017 09:25:20
Сообщений: 4035
Оффлайн

sergmercury wrote:На прошлой неделе смена шлюза с 2.0 на 2.1 помогла исправить эту ошибку, теперь уже не работает и шлюз 2.1

может опять попробовать 2.0
[WWW]
sergmercury


Зарегистрирован: 13/06/2018 10:11:32
Сообщений: 37
Оффлайн

nmzn1 wrote:
sergmercury wrote:На прошлой неделе смена шлюза с 2.0 на 2.1 помогла исправить эту ошибку, теперь уже не работает и шлюз 2.1

может опять попробовать 2.0


Да уж пробовали и 2.1. и 2.0 и без цифр и в латинской, и в русской, и в китайской раскладке и даже в запросе писали: "умоляем отправься во славу великого Меркурия" - ничего не меняется. Поддержка отвечает, что разбираются... Сами не знают, что у них там вообще происходит. Бардак, как обычно.
sergmercury


Зарегистрирован: 13/06/2018 10:11:32
Сообщений: 37
Оффлайн

Ты точно хотя бы раз в жизни слышал словосочетание «ретроградный Меркурий», но вряд ли знаешь, что это такое. Объясняем!

Три раза в год примерно три недели Меркурий находится в ретроградном движении. Это значит, что он двигается в зодиаке обратно. Если просто, то Меркурий останавливается, а потом поворачивает назад и начинает двигаться в противоположном направлении.


Думаю дело в этом...

Это сообщение было редактировано 1 раз. Последнее обновление произошло в 19/06/2019 13:57:08

Егорова Ирина

[Avatar]

Зарегистрирован: 31/08/2015 11:57:04
Сообщений: 294
От: ФГБУ ВНИИЗЖ
Оффлайн

Здравствуйте!

Мы разобрались в возникшей проблеме и отправили Вам ответ с рекомендациями по её решению.
Однако, позвольте прояснить следующее:
1. Вы обратились в техническую поддержку позже, чем на форум
2. В изначальном сообщении вы не прислали ни единого идентификатора, по которому можно было бы опознать запрос и найти его в логах.
3. Уточните, пожалуйста, с какой целью вы отправляете в адрес технической поддержки письма одинакового содержания с частотой от получаса до минуты?
аналитик отдела внедрения
Федерального центра охраны здоровья животных, г. Владимир
sergmercury


Зарегистрирован: 13/06/2018 10:11:32
Сообщений: 37
Оффлайн

Егорова Ирина wrote:Здравствуйте!

Мы разобрались в возникшей проблеме и отправили Вам ответ с рекомендациями по её решению.
Однако, позвольте прояснить следующее:
1. Вы обратились в техническую поддержку позже, чем на форум
2. В изначальном сообщении вы не прислали ни единого идентификатора, по которому можно было бы опознать запрос и найти его в логах.
3. Уточните, пожалуйста, с какой целью вы отправляете в адрес технической поддержки письма одинакового содержания с частотой от получаса до минуты?



1. Какая разница куда я там позже обратился, куда раньше, следите и за почтой и за форумом, люди ищут здесь вашей помощи.
2. В ответном сообщении я отправил необходимую вам информацию. И на ваше письмо я ответил спустя 3 минуты после того как получил ваше письмо. А вашего ответа не получил, ни по времени ожидания, ни подтверждения о получении письма. Научитесь вести обратную связь, а не отмалчиваться.
3. Столько писем я вам отправляю, потому что вы на них не отвечаете своевременно и не даете обратной связи. В прошлый раз вы ответили только через полгода. Я вас тормошу, чтобы вы там не забывали о моей проблеме. Более того я вам и звонил и в случае чего готов звонить по 500 раз, чтобы вы там шевелились.

И последнее, ответ меня ваш убил наповал, вам я отписал уже свое мнение об этой ситуации.
И ниже для других пользователей привожу ответ, чтобы в случае чего остальные могли быстро найти проблему.
Ребята, это просто трэш :
"Причиной ошибки является наименование имя префикса ns0. Как временное решение техническая поддержка рекомендует сменить его на любое другое, например, на apl. В этом случае проблема уйдёт. Данные об инциденте переданы разработчикам.
Приносим извинения за причинённые неудобства."
Слов нет.

Год мы нормально отправляли запросы с этим ns0 и не знали проблем, это надо же было так умудрится исправить систему, что она стала некорректно реагировать на этот ns0.
С чем это связано вообще?
kuzmin


Зарегистрирован: 09/07/2019 11:31:10
Сообщений: 13
Оффлайн

Здравствуйте.
Аналогичная проблема с ns0, только помимо указанного выше метода(методы Журнала Продукции), проявляется еще и на методе GetVetDocumentByUuidOperation:
<?xml version='1.0' encoding='UTF-8'?>
<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
<S:Body>
<ns0:submitApplicationRequest xmlns:ns0="http://api.vetrf.ru/schema/cdm/application/ws-definitions" xmlns:ns2="http://api.vetrf.ru/schema/cdm/application">
<ns0:apiKey>*****</ns0:apiKey>
<ns2:application xmlns:ns1="http://api.vetrf.ru/schema/cdm/base" xmlns:ns6="http://api.vetrf.ru/schema/cdm/base/ws-definitions" xmlns:ns5="http://api.vetrf.ru/schema/cdm/mercury/vet-document/v2">
<ns2:serviceId>mercury-g2b.service</ns2:serviceId>
<ns2:issuerId>*****</ns2:issuerId>
<ns2:issueDate>2019-07-05T17:05:38.046+03:00</ns2:issueDate>
<ns2:data>
<ns4:getVetDocumentByUuidRequest xmlns:ns4="http://api.vetrf.ru/schema/cdm/mercury/g2b/applications/v2" xmlns:ns3="http://api.vetrf.ru/schema/cdm/dictionary/v2">
<ns4:localTransactionId>*****</ns4:localTransactionId>
<ns4:initiator>
<ns5:login>*****</ns5:login>
</ns4:initiator>
<ns1:uuid>*****</ns1:uuid>
<ns3:enterpriseGuid>*****</ns3:enterpriseGuid>
</ns4:getVetDocumentByUuidRequest>
</ns2:data>
</ns2:application>
</ns0:submitApplicationRequest>
</S:Body>
</S:Envelope>

Ответ:

<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<receiveApplicationResultResponse xmlns="http://api.vetrf.ru/schema/cdm/application/ws-definitions">
<application xmlns="http://api.vetrf.ru/schema/cdm/application">
<applicationId>*****</applicationId>
<status>REJECTED</status>
<serviceId>mercury-g2b.service</serviceId>
<issuerId>*****</issuerId>
<issueDate>2019-07-05T17:05:38+03:00</issueDate>
<rcvDate>2019-07-09T11:41:43+03:00</rcvDate>
<prdcRsltDate>2019-07-09T11:41:44+03:00</prdcRsltDate>
<apl:errors xmlns:apl="http://api.vetrf.ru/schema/cdm/application">
<apl:error code="MERC29222">Идентификатор ветеринарно-сопроводительного документа (UUID) обязателен для заполнения.</apl:error>
</apl:errors>
</application>
</receiveApplicationResultResponse>
</soap:Body>
</soap:Envelope>

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

В ходе переписки, тоже предлагали следующие решения:
1. Заменить ns0 на любое другое имя. Уж точно не решение, а обходной путь.
2. Проявляется только на тестовом контуре. Странно, но тот кто разрабатывает все с нуля, то логично, что нужно все проводить на тестовом сервере.

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


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

PS:
Как долго будет обрабатываться инцидент?
Почему бы не поставить в известность техподдержку о существующей проблеме? Чтобы не создавать инцидентов по каждому обращению, а они, я так понимаю, - есть.
Конечно, есть и положительные моменты, особенно в работающих методах, при чем, как ни странно в них проходит ns0.

 
Индекс форума » Автоматизированная система МЕРКУРИЙ
Перейти:   

Powered by JForum 2.1.8 © JForum Team