Сообщения, отправленные пользователем: Алексей Тимофеев

lac_chb wrote:Коллеги из ВЕТИС, может вы нам сообщите что вы изменили сегодня в период с 13:00 до 14:30 и нам проще будет всем вместе разобраться в этой проблеме? Синхронизация перестала работать именно в это время с 13:00 до 14:30.

Изменений на стороне ВетИС не было, и проблема не связана с настройками серверов Меркурия. Решение проблемы зависит от используемого у вас программного обеспечения.

Ещё раз подробное описание причины:

ВетИС.Новости @vetrfru wrote:
⚠️ Ошибки подключения Peer certificate cannot be authenticated with given CA certificate

Сегодня к нам начали приходить сообщения о том, что некоторые пользователи при обращении к веб- и api- интерфейсам Меркурия получают ошибку вида "Peer certificate cannot be authenticated with given CA certificate" или подобное, в результате чего соединение не устанавливается и сервисы интерфейсы Меркурия для пользователя недоступны.
Это сообщение об ошибке означает что, полученный SSL-сертификат от сервера *.vetrf.ru не может быть проверен с использованием имеющегося у пользователя корневого SSL-сертификата.
Большинство клиентских систем, которые регулярно обновляются, уже используют новый корневой SSL-сертификат "USERTrust RSA Certification Authority" (действительный до 2038), эти пользователи с проблемами не столкнулись.
Если клиентская система (операционная система или веб-браузер) не получала обновления с 2015 года, то для проверки SSL-сертификата все еще используется устаревший корневой SSL-сертификат "AddTrust External CA Root certificate" срок действия которого закончился сегодня 30.05.2020. Этим пользователям необходимо срочно установить необходимые обновления операционной системы или браузера. Для этого рекомендуем обратиться к обслуживающим техническим специалистам.

Комментарий от разработчиков 1С, как одно из возможных решений:

https://its.1c.ru/db/metod8dev/content/5949/hdoc
В двух словах: нужно в файле C:\Program Files\1cv8\conf\conf.cfg добавить строчку
IgnoreServerCertificatesChainRevocationSoftFail=true
Для игнорирования проблемы

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

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

Для устранения, необходимо, чтобы технический специалист, обслуживающий вашу программную систему, установил актуальный сертификат безопасности.
Вот техническое описание проблемы и способа решения: https://calnetweb.berkeley.edu/calnet-technologists/incommon-sectigo-certificate-service/addtrust-external-root-expiration-may-2020

https://support.sectigo.com/articles/Knowledge/Sectigo-AddTrust-External-CA-Root-Expiring-May-30-2020

О предстоящем обновлении ИС Меркурий

В четверг 01 февраля 2018 в 18:00 запланировано обновление ИС Меркурий до версии 6.4 в продуктивном и пилотном контуре. Обновление посвящено преимущественно исправлению обнаруженных дефектов и коснётся как веб-интерфейса системы, так и универсального шлюза Ветис.API.
Обновление версии пройдёт без перерывов в работе системы, однако пользователям веб-интерфейса может потребоваться повторная аутентификация.
Список основных улучшений и исправлений опубликован по адресу: http://vetrf.ru/vetrf/news/24890.html

Открыт канал в Telegram с новостями ВетИС.API: https://t.me/vetisapi

О проведении планового технического обслуживания пилотной версии шлюза Ветис.API.

Сообщаем, что во вторник 30.01.2018 в 09:00 МСК состоится плановое техническое обслуживание на пилотном (тестовом) стенде универсального шлюза Ветис.API. Интерфейс подачи заявок будет недоступен в течение короткого промежутка времени. Сервисы получения данных реестров и справочников продолжат работу в штатном режиме.

В рамках работ запланирована миграция тестового контура на новую инфраструктуру, которая позволит обеспечить требуемый запас по производительности шлюза с учётом темпов роста количества пользователей пилотной зоны и существенного увеличения интенсивности обращений от каждого пользователя.
‎Кроме этого, версия шлюза Ветис.API v1.5 будет выведена из эксплуатации. Актуальные версии шлюза: v1.4 и v2.0.
Также обратите внимание на изменение внешнего IP-адреса сервера api2.vetrf.ru. В большинстве случаев это изменение прозрачно для пользователей, обращающихся к серверу Ветис.API по DNS-адресу. Если используется непосредственно IP-адрес или установлено ограничение по IP на исходящие соединения, проверьте настройки маршрутизации. Актуальный IP-адрес: 62.76.145.67, прежний адрес сервера будет поддерживаться до 05.02.2018.

ВАЖНО, что по завершении работ все заявки, отправленные до этого момента, будут перенесены в архив. Результат обработки архивных заявок недоступен для загрузки с помощью стандартного механизма, предусмотренного шлюзом Ветис.API (операция receiveApplicationResultRequest). В связи с этим, обслуживание будет происходить в несколько технологических этапов:
1. Отключение возможности подачи заявки (операция submitApplicationRequest). Получение результатов ранее отправленных заявок с помощью операции receiveApplicationResultRequest. Просьба убедиться в получении результатов заявок.
2. После того, как все ранее отправленные заявки будут обработаны, а результаты получены пользователем шлюза, доступ к системе обработки заявок будет закрыт полностью.
3. После выполнения необходимых работ по настройке, доступ к шлюзу будет возобновлен и открыт в полном объёме.

ВАЖНО, что реквизиты доступа к универсальному шлюзу, а также адреса доступа (endpoints) останутся прежними. Вся процедура по нашим оценкам займёт не более 15 минут с учетом времени ожидания обработки поступивших заявок на этапе №1.

При необходимости получения результатов обработки заявок, перенесенных в архив, а также в случае возникновения других вопросов, просьба обращаться в Службу технической поддержки на адрес электронной почты api@vetrf.ru или по телефону горячей линии: 8 (4922) 52-99-29.

Новости и объявления о работе универсального шлюза Ветис.API

dk wrote:
Проблема:
MERC14260 Количество упаковки в запросе отличается от указанного в ветеринарно-сопроводительном документе более чем на 10% без указания причины в акте несоответствия.

Количество упаковок не меняется, в данном случае упаковка - это 1 автоцистерна.

Принимаемая партия -- это то, что вы оставляете себе на складе, возвращаемая -- это то, что уезжает обратно отправителю. Это касается как объёма продукции, так и упаковки. В запросе вы указываете 1 автоцистерну и в сведениях о принимаемой партии, и в сведениях о возвратной.

dk wrote:
Поле cargoInspected является обязательным для заполнения.

Если его заполнить получаем ошибку:
APLM0007 Wrong application data format. Format validation failed due to XML Schema rules: Элемент 'cargoInspected' не предусмотрен.

Дело не в поле 'cargoInspected', обратите внимание на порядок полей в запросе и в примере в справочной системе. Положение элемента 'locationProsperity' неверное: должен идти последним после 'confirmedDate'.

Aiki wrote:
http://api.vetrf.ru/schema/platform/services/2.0-RC-last/ProductService_v2.0.wsdl - сдох, и запросы по этой схеме так и не получалось выполнять, пример - зарегистрировать SKU (productitem level)

Рабочая ссылка: http://api.vetrf.ru/schema/platform/services/2.0-RC-last/ProductService_v2.0_pilot.wsdl
Аналогичным образом адреса всех остальных WSDL заканчиваются суффиксом _pilot, дабы было очевиднее, какой эндпоинт внутри.

Aiki wrote:
3. теперь скачаем список вет. сертификатов, у меня так и не получилось поставить условие фильтра по vetDocumentType
 <ent:enterpriseGuid>a8c18281-66ce-4f22-9c0c-63ffb82a34d1</ent:enterpriseGuid>

Не до конца понял, что именно не получилось. Если вопрос по пространству имён (префиксу) элемента, то корректно использовать префикс vd, который у вас объявлен для пространства имён http://api.vetrf.ru/schema/cdm/mercury/vet-document/v2

Aiki wrote:
4. Теперь попробуем просто добавить сток на площадке. тут начинается прыгание с фасовкой и упаковкой.
Зачем упаковка на стоке? - она может измениться на отгрузке.

Партия приходуется на сток с той упаковкой, которая была во входящем сертификате. Упаковка по умолчанию "наследуется" из стока при формировании исходящего сертификата. Кроме того, упаковка содержит сведения о маркировке, по которой в том числе можно сопоставить физическую партию с записью в системе. При этом в момент отгрузки (оформления исходящего сертификата) сведения об упаковке можно изменить.

Aiki wrote:
кто сделал GUID/UUID справочник к типам упаковки и потребовал его в схеме. как его скачать?

Справочник упаковки размещен на странице в wiki: http://help.vetrf.ru/wiki/PackingForm. Идентификатор упаковки -- это GUID, который необходимо указать при обращении к 2.0.

Aiki wrote:
в примере блок - packageList - вообще по логике лишний, но может быть. я думаю, он не нужен для стока.

Не лишний, именно в packageList указываются сведения об упаковке для стока. С другой стороны, упаковка опциональна -- каждый решает сам, задавать её или нет.
К слову, элемент productItem/packaging -- это фасовка, которая также необязательна. И если вы ссылаетесь GUID'ом на зарегистрированный SKU, фасовка в запросе будет проигнорирована, а использоваться будет та, что указана при регистрации SKU.

Aiki wrote:
интересно, что можно изменить атрибутику партии (к примеру сроки годности) для GUID запаса.

Раз уж разрешено создавать сток с указанием срока годности, то запрещать изменение этих атрибутов нет никакого смысла. Хотя, конечно, подобное необоснованное изменение, равно как и злоупотребление созданием стока через инвентаризацию, будет расцениваться как нарушение.

Aiki wrote:
Теперь вет. сертификат
сразу скажу, создать его просто. Но тут начинается упаковка.
Если ее указывать, начинает ругаться

В заявке может быть указана только упаковка содержащаяся в записи складского журнала продукции

упаковка запаса должна совпадать, почему?????? (тут много эмоций).

Это рудимент, пришедший из 1.x -- там такой контроль упаковки был. Ошибка уже исправлена, обновление запланировано на 07.09.

Павел Большаков wrote:
Но например, если эту проблему разрабы нам починят, то не столкнемся ли мы с очередной проблемой что он начнет и с маркировками брыкаться.

С маркировкой проблем не будет. Вообще в 2.0 решено было отказаться от контроля упаковки и маркировки в том числе.

В версии 2.0 изменились пространства имён, добавился суффикс версии. Пространство http://api.vetrf.ru/schema/cdm/mercury/applications из примера соответствует версии 1.x.
Пространства имён версии 2.0 объявлены в http://api.vetrf.ru/schema/platform/services/2.0-RC-last/mercury_g2b_applications_v2.0.xsd, см. targetNamespace.

T.Grakhov wrote:Уважаемые разработчики!

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

Даже Google с Фейсбуком не публикуют такой информации

Версия 1.4 -- последняя в ветке 1.x, возможны только багфиксы. Просуществует на бою, как минимум, до марта 2018.
Версия 1.5 -- по сути является версией 2.0-alpha. С выходом 2.0 отмечена как deprecated, сопровождаться не будет. На пилотном стенде просуществует ещё какое-то время (до последнего клиента), на бой публиковаться не будет.
Версия 2.0 -- опубликована на пилотном сервере 03.08.2017 в статусе beta, документация размещена в справочной системе. В сентябре 2017 планируется публикация 2.x на бой, совместно с 1.4. В настоящее время на пилотном сервере 1.4 и 2.0 работают с единым хранилищем в точно такой конфигурации, которая планируется на бою в сентябре. Так что есть возможность оттестировать совместную работу с 1.4 и 2.0.

Для доступа к 2.0 в ближайшее время (одна-две недели) будут опубликованы форматы данных (XSD) и WSDL, включая адреса endpoint'ов. Просьба набраться терпения.
Доступ к 2.0 можно запросить (по почте) и сейчас, если есть желание включиться в beta-тестирование.

alpsmirnov wrote:Вам повезло, что пришел ответ ACCEPTED. У меня вообще возвращает просто текст моего запроса, когда я пытаюсь отправить его в терминах версии 2.0.

alpsmirnov wrote:Интересно, у кого-нибудь, на фоне тотального молчания со стороны разработчиков "Меркурия", получилось сделать хоть один успешный запрос в версии 2.0?

alpsmirnov wrote:Любопытно, удалось ли кому-то получить ответ по запросу в сервисе v2.0?

alpsmirnov wrote:Есть подозрение, что 1.5 колбасит

Алексей, не нагнетайте, пожалуйста. Никакого тотального молчания нет, по ошибкам при составлении запросов к 2.0 в скайпе вам написал. По ошибке в 1.5 с актуальной версией записи складского журнала разбираемся.

Залкинд Дмитрий wrote:<apl:error code="APLM0002" xmlns:apl="http://api.vetrf.ru/schema/cdm/application">Unsupported application data format</apl:error>
Вопрос: что именно я делаю не так, и формат ЧЕГО не нравится парсеру?

Техподдержка получает просто бесконечное количество подобных вопросов. Чтобы сэкономить друг другу время, просьба валидируйте XML по схеме. Это можно сделать, например, с помощью SoapUI или любым другим XML-редактором.
Конкретно в данном случае ошибка в следующем. Application data, т.е. то, что находится внутри тэга <data> заявки, не распознано шлюзом. Т.е. или пространство имён или наименование корневого элемента для содержимого заявки указано некорректно.
Имеем в запросе корневой элемент {http://api.vetrf.ru/schema/cdm/mercury/applications}prepareOutgoingConsignmentRequest, сервис <app:serviceId>mercury-g2b.service</app:serviceId>, т.е. версия форматов 1.4 (по умолчанию). В ХSD для версии 1.4 (http://api.vetrf.ru/schema/platform/mercury/g2b/applications_v1.4.xsd) нет элемента prepareOutgoingConsignmentRequest, корректное название -- prepareOutcomingConsignmentRequest.

papiroca wrote:И еще один вопрос - после того как я подал заявку, как быстро я могу запросить по ней результат и как часто это можно делать в случае если заявка еще не обработана? (я могу бомбить ваш сервер по 1000 раз в секунду, но это уже терроризм).

С одной стороны, есть ограничение сверху: 5 запросов в секунду от одного клиента (логина). Причем, это ограничение общее для всех запросов к шлюзу, не только receiveApplicationResultRequest. С другой стороны, нет смысла 5 раз в секунду опрашивать сервер в надежде получить результат операции, которая выполняется 2 минуты, к примеру.
Поэтому рекомендации здесь такие: для каждого типа заявки (операции) определить время ожидания перед первым receiveApplicationResultRequest равное минимальному времени обработки заявки. И далее повторять опрос с интервалом 2 секунды.

Да, в POSTMAN в поле URL вбивать нужно не адрес WSDL-описания, а адрес endpoint'а (значение service/port/address/@location из WSDL). Для EnterpriseService на пилотном сервере этот адрес будет таким: https://api2.vetrf.ru:8002/platform/cerberus/services/EnterpriseService

В сервисе ApplicationManagementService нет операции ws:getRussianEnterpriseListRequest. Для получения списка предприятий воспользуйтесь сервисом EnterpriseService: http://api.vetrf.ru/schema/platform/cerberus/services/EnterpriseService_v1.4_pilot.wsdl