Интеграция с 1С

ulgrad wrote:Задам еще вопрос,возможно, покажется смешным - но все-таки. А кто-нибудь пробовал формировать xml в 1с простым текстом и передавать в ветис (средствами 1с же)?Мне пока трудно даются все эти фабрики,пространства и пр.вещи,готовые куски программного кода,как правило,не работают,выдают ошибки типа

"{ОбщийМодуль.ОбменССистемойВетис.Модуль(354)}: Ошибка при вызове метода контекста (ПрочитатьXML)
MercAppDO = ФабрикаXD.ПрочитатьXML(ОтветXML, EnvelopeDO.Тип()).Body.submitApplicationResponse.application;
по причине:
Ошибка преобразования данных XDTO:
Чтение объекта типа: {http://schemas.xmlsoap.org/soap/envelope/}Envelope - [1,100]
"

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

Программную работу с Икаром вроде освоил-но там достаточно все просто,теперь же перешел к остаткам,входящим всд,погашениям-и чувствую что уперся в стену,через которую пока не могу прорваться.

Вот и возникла идея - у ветиса в хелпе есть образцы всех запросов и ответов на запросы к их системе. Так может использовать просто тексты самих запросов (с подставленными своими данными),не заморачиваясь погружением в хитросплетения фабрик,пространств и т.п.? Есть у кого такой опыт? Если да - не поделитесь примером отправки подобного текстового запроса в ветис из 1с и получением ответа на него (к примеру запрос об остатках, ну или любой другой)?

Боюсь не взлетит. Вопрос для какой отрасли вы собрались делать доработки? возможно для вас вполне подойдет вариант типовой интеграционки. Самостоятельная разработка это очень. очень, очень сложная задача. И начинать ее надо было как минимум пол года назад. С работой через текст, вероятность что взлетит есть, но крайне малая и исключительно при условии простого учета и назовем ее так "простой" продукции. Но при таких схемах, имхо проще потратиться на коробочное решение.
Пример одной из проблем. В меркурии для одной партии возможно указывать несколько заводов. При этом вы по факту получаете его в разделе batch.origin.producer. Если вы посмотрите внимательнее описание то увидите следующее ПРОИЗВОДИТЕЛЬ ПРОДУКЦИИ. (ТИП: dt

roducer [1..*]) Весь фокус в том, что если производитель занесен в виде текста, а не выбран из справочника, то Меркурий через апи вам вообще в batch.origin ветки .producer не вернет. Если там 1 предприятие, то это 1 ветка. А если список то это уже несколько. При этом это не просто конструкция <производитель>абвгд</производитель><производитель>ооо</производитель>, а конструкция со вложенной структурой вида <производитель><Имя>абвгд</Имя><ГУИД>4343434-34343</ГУИД></производитель> и т.п. И работать с такими вещами в неструктурированной форме, фактически нереально. Для этого и нужны все эти ФабрикиXDTO.
Часть разработчиков работает через HTTP-Соединение. Формирует XML и отправляет его. Получает в ответ другой XML и разгребает его либо последовательным чтением, что практически аналогично тому же текстовику, со всеми вытекающими. Либо десериализует его, с помощью преобразования, как вы приводите в своем коде. И тут как раз начинается конфликт типов. Тот же пример с производителем, если он 1 то это тип ОбъектXDTO, а если их несколько, то это уже тип СписокXDTO. И думаю те кто затачивал свой программный код на простую десериализацию, на таких примерах просто валятся по ошибкам. Если не права, пусть коллеги меня поправят.
Единственный более менее нормальный вариант чтения и обработки данных это работа не с HTTP-Соединением, а соединением получаемым через WSПрокси, т.е. полноценная работа с вэб сервисом. А тут уровень вашей квалификации как программиста должен быть очень и очень высоким. Весь фокус в том, что публикуемые xsd схемы и те схемы что вы получаете через wsdl ссылки, они абсолютно разные. Т.е. оперативного обновления xsd схем на сайте меркурия попросту нет. Разрабы добавляют новый объект, или меняют типы, никого об этом не информируют, xsd на сайте не обновляют и вы дружно всем отделом пытаетесь понять почему "ну вчера же работало". Единственный способ работать с более менее свежими ФабрикамиXDTO, это прогружать их через wsdl, причем не в структуру конфигурации. Но и тут не все так просто, 1С не в состоянии принять часть из этих библиотек и работать с ними, да к тому же внутри wsdl вы видите не все библиотеки что могли бы увидеть прогрузив xsd схемы напрямую в конфу. И в итоге вы долго возитесь с вопросом самостоятельной сборки пакета фабрикXDTO, по принципу, эти возьми с WSDL а эти локально с Фабрик в конфигураторе которые ранее подгружены были через xsd.
Дальше вы долго мучаетесь с типами, особенно с объектами которые вы не хотите передавать в ту или иную функцию в качестве параметра для отбора. Открываете документацию, видите что такая то операция может работать с фильтрацией данных, хотите, указываете, хотите, не указываете. У вас задача получить данные все, без наложения фильтра. И опа... не работает. И дальше вы начинаете раскуривать принципы построения xsd, типы. Текст самой xsd. И ручками!!! ручками!!! в xml редакторе правите схемы xsd. Чтобы просто, эта фигня заработала. Та же фигня была и с WSDL в свое время у меня, когда чтобы 1С прогрузила данные, скачивалась WSDL локально и правилась, ручками, ручками. И подключение уже шло через локальную схему, которая лежит на диске, в папке. И вот, часть заработала, но один фиг, вы упираетесь в другую проблему и решение которое вы искали буквально методом научного тыка несколько недель, уходит в небытие. И вы начинаете искать альтернативный вариант.
Нормальной документации по меркурию нет. Нормальной документации по работе в 1С с фабрикамиXDTO и WSПрокси, десериализацией XML и т.п. фактически нет, в том числе нормального описания тех или иных методов в самом Синтаксис-помощнике.
Если вы в состоянии объяснить человеческим языком как работать с типами, да еще и написать работающий кусок кода основываясь на этом:

ФабрикаXDTO (XDTOFactory)
Тип (Type)
Вариант синтаксиса: По имени и URI пространства имен
Синтаксис:
Тип(<URIПространстваИмен>, <Имя>
Параметры:
<URIПространстваИмен> (обязательный)
Тип: Строка.
URI пространства имен запрашиваемого типа.
<Имя> (обязательный)
Тип: Строка.
Имя запрашиваемого типа.
Описание варианта метода:
Получение типа XDTO по имени и URI пространства имен.
Вариант синтаксиса: По расширенному имени XML
Синтаксис:
Тип(<ИмяXML>
Параметры:
<ИмяXML> (обязательный)
Тип: РасширенноеИмяXML.
Расширенное имя XML.
Описание варианта метода:
Получение типа XDTO по расширенному имени XML.
Вариант синтаксиса: По типу данных XML
Синтаксис:
Тип(<ТипДанных>
Параметры:
<ТипДанных> (обязательный)
Тип: ТипДанныхXML.
Тип данных XML, по которому запрашивается тип XDTO.
Описание варианта метода:
Получение типа XDTO по типу данных XML.
Возвращаемое значение:
Тип: ТипЗначенияXDTO; ТипОбъектаXDTO; Неопределено.
Описание:
Получение типа XDTO.
Доступность:
Тонкий клиент, сервер, толстый клиент, внешнее соединение, мобильное приложение(клиент), мобильное приложение(сервер).

Поздравляю, вы один из нас.
Одним словом. Если ваша жизнь кажется вам чрезвычайно скучной, вы хотите эротического экстрима. Вступайте в наш занимательный кружок "ребят кто сталкивался? что за неописанная фигня в схеме? для чего она тут?". Как говорится: "Велкам!"

ANIT, Встал и аплодирую.

Sergey-Chelny wrote:ANIT, Встал и аплодирую.

Поддерживаю =)

Sergey-Chelny wrote:ANIT, Встал и аплодирую.

Дружно скандируем: Фа-бри-ка !!! Мер-ку-рий!!! Де-се-ре-али-за-ция !!!
з.ы.
при десериализации правильной фабрикой ориджин может быть как объектом, так и списком, с этой стороны всё норм
но фабрику действительно приходится собирать по кускам - отредактированным схемам, иначе то xml c неправильным порядком тегов, то вовсе типы теряются

lalex23 wrote:

Sergey-Chelny wrote:ANIT, Встал и аплодирую.

Дружно скандируем: Фа-бри-ка !!! Мер-ку-рий!!! Де-се-ре-али-за-ция !!!
з.ы.
при десериализации правильной фабрикой ориджин может быть как объектом, так и списком, с этой стороны всё норм
но фабрику действительно приходится собирать по кускам - отредактированным схемам, иначе то xml c неправильным порядком тегов, то вовсе типы теряются

Если правильной фабрикой, то список и объект не путаются

ANIT wrote:И ручками!!! ручками!!! в xml редакторе правите схемы xsd. Чтобы просто, эта фигня заработала. Та же фигня была и с WSDL в свое время у меня, когда чтобы 1С прогрузила данные, скачивалась WSDL локально и правилась, ручками, ручками.

Чувствуется рука опытного сварщика!
ЗЫ: тоже задолбался xsd и wsdl править - самое неприятное что ответ меркурия не по его же xsd схеме постоянно выпрыгивает на самых нервных клиентах. (я, например, про табуляции в полях NText или пустые uuid)

Добрый день. Задам глупый вопрос по фабрикам. Пожалуйста пните в нужную сторону.
Делаю что-то типа

producer = Объект.certifiedConsignment.batch.origin.producer.Получить(0);
origin.producer.Добавить(producer);
consignment.origin = origin;
delivery.consignment.Добавить(consignment);
processIncomingConsignmentRequest.delivery = delivery;

И при этом Объект у меня создан по 1 фабрике, а processIncomingConsignmentRequest по другой, так как УП. Естественно получаю вот это:
" Тип '{http://api.vetrf.ru/schema/cdm/dictionary/v2}Producer' не соответствует типу '{http://api.vetrf.ru/schema/cdm/dictionary/v2}Producer' Тип свойства не соответствует типу значения"

Понимаю, что это из-за того что объекты созданы не от одной фабрики. Но как это обойти это в управляемом приложении? Ведь Фабрику я создаю на сервере и естественно она исчезает. И передать на клиент созданную фабрику не могу, понятно почему. Или мой вариант разбирать весь объект до простых типов? Это единственный вариант? Может можно как-то сформировать фабрику 1 раз и использовать ее? Пните меня в правильную сторону! Спасибо.

ZDmitry wrote:Понимаю, что это из-за того что объекты созданы не от одной фабрики. Но как это обойти это в управляемом приложении? Ведь Фабрику я создаю на сервере и естественно она исчезает. И передать на клиент созданную фабрику не могу, понятно почему. Или мой вариант разбирать весь объект до простых типов? Это единственный вариант? Может можно как-то сформировать фабрику 1 раз и использовать ее? Пните меня в правильную сторону! Спасибо.

Формировать текст xml на сервере нет возможности? Данные для формирования можно отдать на сервер, а сервер вернет готовый текст на клиент, если требуется

rty wrote:

ZDmitry wrote:Понимаю, что это из-за того что объекты созданы не от одной фабрики. Но как это обойти это в управляемом приложении? Ведь Фабрику я создаю на сервере и естественно она исчезает. И передать на клиент созданную фабрику не могу, понятно почему. Или мой вариант разбирать весь объект до простых типов? Это единственный вариант? Может можно как-то сформировать фабрику 1 раз и использовать ее? Пните меня в правильную сторону! Спасибо.

Формировать текст xml на сервере нет возможности? Данные для формирования можно отдать на сервер, а сервер вернет готовый текст на клиент, если требуется

Есть конечно. Я рассматриваю вариант, когда делаю транспортную операцию. То есть я делаю запрос на получение записи журнала, потом нужно часть этих данных использовать в запросе на транспортную операцию. И сейчас понимаю, что полученные данные нужно разбирать до простых типов, а не присвоить часть объекта другому объекту XDTO. А если бы объекты были созданы одной фабрикой, но так не получится видимо, потому что фабрика будет жить только пока выполняется серверная процедура.

ZDmitry wrote:

rty wrote:

ZDmitry wrote:Понимаю, что это из-за того что объекты созданы не от одной фабрики. Но как это обойти это в управляемом приложении? Ведь Фабрику я создаю на сервере и естественно она исчезает. И передать на клиент созданную фабрику не могу, понятно почему. Или мой вариант разбирать весь объект до простых типов? Это единственный вариант? Может можно как-то сформировать фабрику 1 раз и использовать ее? Пните меня в правильную сторону! Спасибо.

Формировать текст xml на сервере нет возможности? Данные для формирования можно отдать на сервер, а сервер вернет готовый текст на клиент, если требуется

Есть конечно. Я рассматриваю вариант, когда делаю транспортную операцию. То есть я делаю запрос на получение записи журнала, потом нужно часть этих данных использовать в запросе на транспортную операцию. И сейчас понимаю, что полученные данные нужно разбирать до простых типов, а не присвоить часть объекта другому объекту XDTO. А если бы объекты были созданы одной фабрикой, но так не получится видимо, потому что фабрика будет жить только пока выполняется серверная процедура.

Как вариант сохранить в xml ту часть объекта XDTO, которую нужно присвоить своему объекту, и этот xml прочитать своей фабрикой и присвоить потом
Но не уверен в работоспособности и правильности такого подхода =)

rty wrote:

ZDmitry wrote:

rty wrote:

ZDmitry wrote:Понимаю, что это из-за того что объекты созданы не от одной фабрики. Но как это обойти это в управляемом приложении? Ведь Фабрику я создаю на сервере и естественно она исчезает. И передать на клиент созданную фабрику не могу, понятно почему. Или мой вариант разбирать весь объект до простых типов? Это единственный вариант? Может можно как-то сформировать фабрику 1 раз и использовать ее? Пните меня в правильную сторону! Спасибо.

Формировать текст xml на сервере нет возможности? Данные для формирования можно отдать на сервер, а сервер вернет готовый текст на клиент, если требуется

Есть конечно. Я рассматриваю вариант, когда делаю транспортную операцию. То есть я делаю запрос на получение записи журнала, потом нужно часть этих данных использовать в запросе на транспортную операцию. И сейчас понимаю, что полученные данные нужно разбирать до простых типов, а не присвоить часть объекта другому объекту XDTO. А если бы объекты были созданы одной фабрикой, но так не получится видимо, потому что фабрика будет жить только пока выполняется серверная процедура.

Как вариант сохранить в xml ту часть объекта XDTO, которую нужно присвоить своему объекту, и этот xml прочитать своей фабрикой и присвоить потом
Но не уверен в работоспособности и правильности такого подхода =)

Только что сам про это подумал. Уже проверяю)) Спасибо.

Здравствуйте! Кто-нибудь сталкивался с тем, что при получении предприятия на 2.0 через GetEnterpriseByGuid приходит полупустой объект предприятия, в котором свойства "activityList" и "type" пустые?

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

Вопрос по разрешению на ввоз/вывоз продукции.
При оформлении транспортного ВСД через веб интерфейс среди связанных документов есть тип "Разрешение ветеринарного управления субъекта на ввоз/вывоз продукции".
В описании связанных документов API 2.0 (http://help.vetrf.ru/wiki/DocumentType_v2.0) среди возможных значений DocumentType v2.0 такого типа нет:
Значение Описание
1 Товарно-транспортная накладная
2 Конасамент
3 CMR
4 Авианакладная
5 Транспортная накладная
6 ТОРГ-12
7 Ветеринарное разрешение на импорт продукции на территорию ТС
8 Разрешение ветеринарного управления субъекта страны ТС на ввоз продукции
9 Акт отбора пробы на исследование
10 ТОРГ-13
11 Ветеринарный сертификат на перемещение внутри РФ
12 Ветеринарный сертификат третьих стран на ввоз продукции на территорию РФ
13 Ветеринарный сертификат страны ТС на ввоз продукции на территорию РФ
14 Ветеринарный сертификат РФ на вывоз продукции на территорию стран ТС
15 Ветеринарный сертификат РФ на вывоз продукции на территорию третьих стран
16 Заказ
17 Паспорт гражданина РФ
18 Паспорт иностранного гражданина
19 Паспорт гражданина Республики Казахстан
20 Паспорт гражданина Республики Беларусь
21 Паспорт гражданина Республики Армения
22 Паспорт гражданина Республики Киргизия

Как указать номер разрешения в ВСД? Сейчас приходится указывать в особых отметках...

Спасибо.

gni, я так думаю вам лучше переговорить с тех.поддержкой. Может этот документ в АПИ обозвали по другому.
P.S. Не исповедимы пути ..... Меркурия.

Добрый день!
2.0 GetVetDocumentChangesList не возвращает название маркировки (в тексте ответа её нет (<d4p1:productMarks class="UNDEFINED"/> )), но при заполнении из сервиса конкретной эВСД getVetDocumentByUuid (<d4p1:productMarks class="UNDEFINED">ООО "Фалёнки-Агро"</d4p1:productMarks> ) заполняется.
Как-нибудь боретесь с этим?