Сообщения, отправленные пользователем: Garland

Отправка производственных ВСД встала колом еще в 3 ночи
Сейчас вроде что-то ворочается, но примерно в 5% из 100 запросов. Каждая заявка (производство или транспорт) обрабатывается IN_PROCESS по 5 минут и более.

Это понятно. Но у нас уже давно написана интеграция. работает по другому она. и она работала нормально. и вдруг выясняется что нужно будет все переписать.

Что это у вас за "альтернативно одаренные" программисты сделали систему, которая не хранит данные о GUID партий, что вы их каждый раз из шлюза опрашиваете?

В документации же все написано русским языком:

Идентификатор версии записи складского журнала продукции.

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

На самом деле все работает, но только в 1% случаев из 100.
Я просто обернул этот запрос в вечный цикл и долблю сервер пока он не вернет ответ. Пока все ВСД через шлюз загружались до сегодняшнего дня.

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

В данном случае возникает ошибка:
При вызове веб-сервиса произошла ошибка. Ошибка вызова операции сервиса: {http://api.vetrf.ru/schema/cdm/registry/service}:EnterpriseServiceBindingQSService:GetEnterpriseByGuid()
по причине:
При вызове веб-сервиса произошла ошибка. Неизвестная ошибка. Ошибка проверки данных XDTO:
Значение: 'Производство мясопродуктов (полуфабрикатов). Убой КРС, разделка, производство мяса говядины в полутушах и четвертинах, производство жилованного блочного мяса говядины замороженного, производство субпродуктов говяжьих, производство полуфабрикатов мясных натуральных, жира-сырца животного. Хранение продукции животного происхождения.' не соответствует простому типу: {http://api.vetrf.ru/schema/cdm/base}String255
Несоответствие фасету MaxLength = '255'

А GUID этот пришел вместе с каким-то товаром от поставщика (поле "producerList")
В веб интерфейсе Меркурия показывается - ОАО “Березовский мясоконсервный комбинат” (Беларусь, Брестская область), номер в реестре BY415457

А вот еще из веселого:
даже попытка получить площадку через шлюз приводит к краху

GetEnterpriseByGuid(5351519f-af55-bbb3-2b17-3962f1a82150)

А что делать например с адресом предприятия?
Вот пришел в адресе guid для поля district "b78a1150-21ba-11e3-8f90-50e549251629"

При вызове веб-сервиса произошла ошибка. Ошибка вызова операции сервиса: {http://api.vetrf.ru/schema/cdm/registry/service}:IkarServiceBindingQSService:GetDistrictByGuid()
по причине:
При вызове веб-сервиса произошла ошибка. Ошибка SOAP сервера: Requested entity not found

Вот как вообще можно так испохабить нормальный КЛАДР...

Не поделитесь идеей, какой костыль использовать?

Столкнулся с такой проблемой:
1) получаю через шлюз Ветис.API список входящих ВСД
2) пытаюсь их разобрать в соответствии со схемой http://api.vetrf.ru/schema/cdm/mercury/vet-document
3) получаю ошибку!
Ошибка проверки данных XDTO: ... не соответствует простому типу: {http://api.vetrf.ru/schema/cdm/base}String255
Несоответствие фасету MaxLength = '255'

Начинаю разбираться - оказывается поставщик в веб интерфейсе Меркурия может внести в поле "specialMarks" простыню абсолютно любой длины, а шлюз и xsd схемы допускают только тип "string255"

Вот какой "альтернативно одаренный" программист делал этот Меркурий и шлюз? Почему схемы данных веб-интерфейса не соответствуют шлюзу?
И как собственно внедрять Ветис.API, если даже список входящих ВСД получить невозможно?

Кто еще сталкивался с похожей проблемой?

И мне пожалуйста отправьте документ на ХС fe33c7a0-218a-11e2-a69b-b499babae7ea, площадка 482d88da-d593-5d00-8c7d-e39bd4aa9d15