Взаимодействие с учетными системами хозяйствующих субъектов

fishsbones wrote:
Кто-нибудь знает, как это можно сделать?

текст запроса и ответа приводите, так то с этим не было проблем.

fishsbones wrote:Всем привет!
Тоже занимаюсь интеграцией с Меркурием

Сейчас существует две версии API - 1.4 и 2.0 - которые "слегка" между собой различаются.

Я работаю через 2 версию, но при этом на запрос ВСД приходят ВСД в формате версии 1.4 .
А хотелось бы получить ВСД в формате версии 2.0.

Кто-нибудь знает, как это можно сделать?

Это вообще нельзя сделать, если они оформлены в 1.4.: в них тогда вообще нет некоторых полей и взять эти данные неоткуда.

Lamer wrote:

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

Владимир Игнатов wrote:

vld wrote:Методом проб и ошибок получено, что запрос отрабатывает только
2. по ПЛ, правда пока не удалось получить непустой результат.

Вы точно там не внеземной космический аппарат изучаете???

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

Конечно правильно! Так же интереснее: творческая жилка стимулируется. Это полезно. А документацию у нас все одно ни кто не читает. Вы себя спросите - вы читали документацию на свою микроволновку?

Если это шутка, то совсем не смешная. Если это принцип работы такой - тогда всё понятно, никаких вопросов.
На самом деле, просто треш. Если какой-то метод не работает - неужели сложно написать в вики, что "метод пока не работает"? Нет, надо сначала потратить время на то, чтобы понять, что ты всё делаешь всё-таки верно и не работает именно на стороне Меркурия эта штука, потом прошерстить форум, чтобы найти таких же недоумевающих людей с тем же самым вопросом, на который к тому же ответа на форуме часто нет... Мало того, что баг на баге и багом погоняет, так ещё и нормальной коммуникации нет.
Сделайте, пожалуйста, по-нормальному - джиру (или что вы там для багтрекинга используете) предоставьте в публичный доступ, чтобы там можно было багрепорты заводить и отслеживать, когда, кто и что именно по данному конкретному багу предпринимает.

Сделаем, собственно уже начали коллектор делать: все будет видно - кто, что предложил, принято-не принято, очередь на разработку и т.д.

PS: шутка смешная - это я вам говорю. Просто у вас что-то с чуйством юмора...

Тогда тоже расскажу "анекдот"

Привозят представители Volkswagen на завод Шкоды новый двигатель и говорят, вот, мол, давайте, ставьте теперь его в свои октавии. Вот вам документация.
Берут инженеры шкоды документацию, открывают, а там написано: "Ну вот двигатель, работает на бензине, ставить в машины. точка"
Спрашивают они разработчиков двигателя: "а где посадочные размеры?, где допуски?, где остальные 1500 листов документации?"
А фольксвагеновцы и отвечают: "На кой черт вам эти инструкции, все равно же читать не будете. А так у вас хоть творческая жилка разовьется. Вы же не читаете инструкции к микроволновкам"
*звонит будильник, главный инженер шкоды просыпается.

Павел Большаков wrote:Тогда тоже расскажу "анекдот"

Привозят представители Volkswagen на завод Шкоды новый двигатель и говорят, вот, мол, давайте, ставьте теперь его в свои октавии. Вот вам документация.
Берут инженеры шкоды документацию, открывают, а там написано: "Ну вот двигатель, работает на бензине, ставить в машины. точка"
Спрашивают они разработчиков двигателя: "а где посадочные размеры?, где допуски?, где остальные 1500 листов документации?"
А фольксвагеновцы и отвечают: "На кой черт вам эти инструкции, все равно же читать не будете. А так у вас хоть творческая жилка разовьется. Вы же не читаете инструкции к микроволновкам"
*звонит будильник, главный инженер шкоды просыпается.

Молодец. Творчески...

Николай Власов wrote:
Сделаем, собственно уже начали коллектор делать

То есть его в принципе ещё нет? А как разработчики сейчас баги отслеживают? А когда запустится этот коллектор? Летом? В аккурат перед следующим переносом сроков полного перехода на электронную сертификацию?))

Lamer wrote:

Николай Власов wrote:
Сделаем, собственно уже начали коллектор делать

То есть его в принципе ещё нет? А как разработчики сейчас баги отслеживают? А когда запустится этот коллектор? Летом? В аккурат перед следующим переносом сроков полного перехода на электронную сертификацию?))

Без выделывания общаться еще не научились?

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

Lamer wrote:

Николай Власов wrote:
Сделаем, собственно уже начали коллектор делать

То есть его в принципе ещё нет? А как разработчики сейчас баги отслеживают? А когда запустится этот коллектор? Летом? В аккурат перед следующим переносом сроков полного перехода на электронную сертификацию?))

Без выделывания общаться еще не научились?

А где же Ваше знаменитое чувство юмора?)) Или просто по срокам информации нет?

vvche wrote:Техподдержка вчера прислала работающий образец для updateVeterinaryEventsRequest
</SOAP-ENV:Envelope>
Но предупредили:

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

На тестовом сервере оно сначала выдаёт:

Элемент 'expertiseID' не предусмотрен.
Элемент 'actualDateTime' не предусмотрен.

а после этого

MERC78510 Дата получения результата обязательна для заполнения.
MERC78507 Номер экспертизы обязательно для заполнения.

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

продуктивный сервер, запрос условий регионализации

<checkShipmentRegionalizationRequest xmlns="http://api.vetrf.ru/schema/cdm/mercury/g2b/applications/v2">
<localTransactionId>
1e8b0dc6-da51-48bd-83a0-520dbb851c1e
</localTransactionId>
<initiator xmlns:d7p1="http://api.vetrf.ru/schema/cdm/mercury/vet-document/v2">
<d7p1:login>
*****
</d7p1:login>
</initiator>
<cargoType xmlns="http://api.vetrf.ru/schema/cdm/dictionary/v2">
<guid xmlns="http://api.vetrf.ru/schema/cdm/base">
8563650a-c1e1-11e8-e641-179e41a60918
</guid>
</cargoType>
<cargoType xmlns="http://api.vetrf.ru/schema/cdm/dictionary/v2">
<guid xmlns="http://api.vetrf.ru/schema/cdm/base">
efc608f8-8a1e-4a17-82ff-51162babfc5e
</guid>
</cargoType>
<cargoType xmlns="http://api.vetrf.ru/schema/cdm/dictionary/v2">
<guid xmlns="http://api.vetrf.ru/schema/cdm/base">
bb694dcd-4d7e-3cae-f932-ab17f81d2e7b
</guid>
</cargoType>
<cargoType xmlns="http://api.vetrf.ru/schema/cdm/dictionary/v2">
<guid xmlns="http://api.vetrf.ru/schema/cdm/base">
bf8a6e6b-8ae1-d5d9-9867-34f04047d09f
</guid>
</cargoType>
<cargoType xmlns="http://api.vetrf.ru/schema/cdm/dictionary/v2">
<guid xmlns="http://api.vetrf.ru/schema/cdm/base">
78e61b56-bab2-4a4b-b2a7-c87de0395be3
</guid>
</cargoType>
<cargoType xmlns="http://api.vetrf.ru/schema/cdm/dictionary/v2">
<guid xmlns="http://api.vetrf.ru/schema/cdm/base">
1064ca2c-d39d-4625-9bdf-7e7360bb667e
</guid>
</cargoType>
<shipmentRoute xmlns="http://api.vetrf.ru/schema/cdm/mercury/vet-document/v2">
<routePoint>
<enterprise xmlns:d9p1="http://api.vetrf.ru/schema/cdm/dictionary/v2">
<guid xmlns="http://api.vetrf.ru/schema/cdm/base">
6984304b-9c88-4963-880f-5d75ceb83d35
</guid>
</enterprise>
</routePoint>
<routePoint>
<enterprise xmlns:d9p1="http://api.vetrf.ru/schema/cdm/dictionary/v2">
<guid xmlns="http://api.vetrf.ru/schema/cdm/base">
40e1cabb-1f5b-421a-b772-f568c1df00b3
</guid>
</enterprise>
</routePoint>
</shipmentRoute>
</checkShipmentRegionalizationRequest>

ответ

при всём при этом что предприятие находится по guid, активно
запросы на прочие предприятия - таких проблем пока не вызывали

timur.lt wrote:

vvche wrote:Техподдержка вчера прислала работающий образец для updateVeterinaryEventsRequest

Но предупредили:

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

Спасибо

Еще вопрос в тему, если пользователь ошибся и включил неправильный показатель, как его потом удалить?
откорректировать вероятнее всего можно по гуиду, а вот удалить непонятно как.

Удалить нельзя и это правильно, ошибочно добавленный необходимо изменить установив researchResult = "Не проводилось.". Только проблема в том, что редактировать добавленные записи не получается. Согласно справке для редактирования необходимо передавать тег <vd:ID> который сгенерировался при первой отправке, но это не работает, в результате вместо редактирования данные добавляются.

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

fishsbones wrote:Всем привет!
Тоже занимаюсь интеграцией с Меркурием
Сейчас существует две версии API - 1.4 и 2.0 - которые "слегка" между собой различаются.
Я работаю через 2 версию, но при этом на запрос ВСД приходят ВСД в формате версии 1.4 .
А хотелось бы получить ВСД в формате версии 2.0.

Кто-нибудь знает, как это можно сделать?

Это вообще нельзя сделать, если они оформлены в 1.4.: в них тогда вообще нет некоторых полей и взять эти данные неоткуда.

Пардон, были праздники

То есть если отправитель оформляет ВСД через 1.4, то я через 2 что должен получить?

На какую версию API лучше закладываться при разработке интеграционного решения?

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

Нормировано ли максимальное время ответа для receiveApplicationResultRequest? Если есть, укажите, пожалуйста, ссылку на документацию. Хотелось бы представить предельный порядок величин задержек при получении результатов.

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

P.S.

Спрашивают они разработчиков двигателя: "а где посадочные размеры?, где допуски?, где остальные 1500 листов документации?"

Смех смехом, а слышал я байку, что когда французы приехали на АЗЛК обсуждать техническую возможность установки на Москвич двигателя F3R, им показали готовый прототип с уже установленным двигателем. Занавес.

Данила Икрянников wrote:Здравствуйте.

Нормировано ли максимальное время ответа для receiveApplicationResultRequest? Если есть, укажите, пожалуйста, ссылку на документацию. Хотелось бы представить предельный порядок величин задержек при получении результатов.

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

В официальном письме с реквизитами для доступа к продакшн-мерверу есть такой текст: "Интервал опроса на готовность результата заявки (вызов операции receiveApplicationResultRequest) рекомендуем установить в диапазоне от 5 сек до 1 минуты."
И это, на мой взгляд, жесть)) Минута, Карл!))

fishsbones wrote:

На какую версию API лучше закладываться при разработке интеграционного решения?

Когда я в прошлом году звонил в поддержку, мне ответили, что на вторую, и что вторая будет на продакшене с 1-го января сего года (ха-ха-ха). Я пилю под 2.0, но проблема в том, что там много чего не работает (по крайней мере на тестовом сервере), поэтому толком не протестить. А когда оно заработает - никто не знает. А если знает, то почему-то молчит.