Код ошибки merc56117

Код ошибки — 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 wrote:Проверьте права пользователя на доступ к площадке запрашиваемой записи (через Меркурий.ХС в веб). Если делали работу с пользователями через АПИ, тогда обновите зоны ответственности для пользователя (нужно передать в запросе UpdateUserWorkingAreas все площадки на которые он имеет доступ).

Спасибо, результат все тот же.

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

А по UpdateUserWorkingAreas получаю такой ответ: <apl:error code=»MERC79386″>Роль пользователя не позволяет изменять зоны ответственности.</apl:error> хотя инициатор является администратором.

sergmercury wrote:Права доступа к площадке в веб есть и пробовали от разных пользователей отправлять у всех права есть, ошибка все та же.

А по UpdateUserWorkingAreas получаю такой ответ: <apl:error code=»MERC79386″>Роль пользователя не позволяет изменять зоны ответственности.</apl:error> хотя инициатор является администратором.

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

nmzn1 wrote:

sergmercury wrote:Права доступа к площадке в веб есть и пробовали от разных пользователей отправлять у всех права есть, ошибка все та же.

А по UpdateUserWorkingAreas получаю такой ответ: <apl:error code=»MERC79386″>Роль пользователя не позволяет изменять зоны ответственности.</apl:error> хотя инициатор является администратором.

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

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

sergmercury wrote:

nmzn1 wrote:

sergmercury wrote:Права доступа к площадке в веб есть и пробовали от разных пользователей отправлять у всех права есть, ошибка все та же.

А по UpdateUserWorkingAreas получаю такой ответ: <apl:error code=»MERC79386″>Роль пользователя не позволяет изменять зоны ответственности.</apl:error> хотя инициатор является администратором.

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

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

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

serg882 wrote:

sergmercury wrote:

nmzn1 wrote:

sergmercury wrote:Права доступа к площадке в веб есть и пробовали от разных пользователей отправлять у всех права есть, ошибка все та же.

А по UpdateUserWorkingAreas получаю такой ответ: <apl:error code=»MERC79386″>Роль пользователя не позволяет изменять зоны ответственности.</apl:error> хотя инициатор является администратором.

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

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

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

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

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

СНИЛС был прописан, а телефон вот старый стоял, поменял на новый, но и это не помогло))

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

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

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

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

nmzn1 wrote:

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

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

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

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

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

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

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

Мы разобрались в возникшей проблеме и отправили Вам ответ с рекомендациями по её решению.

Однако, позвольте прояснить следующее:

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

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

3. Уточните, пожалуйста, с какой целью вы отправляете в адрес технической поддержки письма одинакового содержания с частотой от получаса до минуты?

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

Мы разобрались в возникшей проблеме и отправили Вам ответ с рекомендациями по её решению.

Однако, позвольте прояснить следующее:

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

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

3. Уточните, пожалуйста, с какой целью вы отправляете в адрес технической поддержки письма одинакового содержания с частотой от получаса до минуты?

1. Какая разница куда я там позже обратился, куда раньше, следите и за почтой и за форумом, люди ищут здесь вашей помощи.

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

3. Столько писем я вам отправляю, потому что вы на них не отвечаете своевременно и не даете обратной связи. В прошлый раз вы ответили только через полгода. Я вас тормошу, чтобы вы там не забывали о моей проблеме. Более того я вам и звонил и в случае чего готов звонить по 500 раз, чтобы вы там шевелились.

И последнее, ответ меня ваш убил наповал, вам я отписал уже свое мнение об этой ситуации.

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

Ребята, это просто трэш :

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

Приносим извинения за причинённые неудобства.»

Слов нет.

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

С чем это связано вообще?

Ответ:

<?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.