Автор |
Сообщение |
|
Всем добрый день !
В справке http://help.vetrf.ru/wiki/Категория:Ветис.API IncomingOperation 2.0 нет.
Пытаюсь отправить XML на "http://api.vetrf.ru/schema/cdm/mercury/g2b/applications/v2"
и получаю "APLM0002 Unsupported application data format".
Сообщение очень информативное ) Что делать, куда копать ?
Текст запроса:
|
 |
|
Нашел причину.
Адрес ресурса теперь не "platform/services/ApplicationManagementService", а
"platform/services/2.0/ApplicationManagementService"
Чтобы запустить Меркурий, приходится использовать метод "научного тыка".
На сайте Россельхознадзора не нашел нужной информации
|
 |
|
polet wrote:Коллеги, добрый день. получилось ли у Вас добиьтся ответа разработчиков ответа об ошибки "Неверно указана иерархия месторасположения"? или Вы как то ее решили?
У меня проблема решается двумя способами (и оба "кривые"):
1. если есть несколько адресных объектов одного типа с одним наименованием (но с разными GUID), то перебираешь все,
пока не "повезет".
2. Не указывать полную иерархию, а только верхние уровни. Остальную информацию текстовой строкой
занести, например, в дом.
|
 |
|
Вот что не так, получаю в ответ на запрос ошибку: "APLM0002 Unsupported application data format" ?
Мой запрос (изменено содержимое apiKey и login):
А это пример, размещенный на сайте Россельхознадзора: http://help.vetrf.ru/wiki/GetVetDocumentChangesListOperation_v2.0 :
|
 |
|
Чтобы при формировании XML из 1С исключить "символы непонятные (d7p1):", нужно после записи начала элемента
установить соответствия пространства имен, например так:
ТелоXML.ЗаписатьСоответствиеПространстваИмен("ent", ""http://api.vetrf.ru/schema/cdm/cerberus/enterprise");
Rinat wrote:
anig99 wrote:Покажите результирующий запрос в xml. И какую версию api используете?
api 1.4 использую, а запрос в итоге вот такой получается, только там какие символы непонятные приписываются(например d7p1):
|
 |
|
Добрый день.
Проблема появилась 30 июня 2017 на тестовом сервере.
Работающие раньше функции работать перестали.
Даже простая функция GetUnitList(ListOptions) вызывает сообщение об ошибке "Удаленный узел не прошел проверку".
И самое интересное, что не всегда ! Из десяти вызовов один может быть успешным (а может и не быть),
остальные с ошибкой. Или несколько подряд вызовов успешны, потом череда ошибок.
Клиентский программный код, который вызывает ошибку, не менялся с 20 июня по 3 июля,
логины/пароли для авторизации - тоже.
Что могло случиться, не могу понять. Никто не сталкивался с похожей ситуацией ?
...
Разобрался. Клиентская программа использовала незащищенное HTTP соединение. И раньше всё успешно
отрабатывало. А 30-го стало работать через раз, причем часть ответов отрезалась.
После изменения подключения через защищенное соединение, всё заработало.
|
 |
|
|
|