Фиксированное значение свойства в XDTO

Форум Программирование Интеграция и обмен данными, конвертация данных (Обмен)

Платформа 1С v8.3

1. PythonJ 117 13.04.18 10:43 Сейчас в теме

Не получается задать фиксированное значение свойства в фабрике XDTO.
Предыстория такая. Пытаюсь увязать ГИС ЖКХ с фабрикой XDTO в 1С.
В статье на хабре был описан способ это сделать, в общем-то ничего сложного.
Статья писалась давно и в ней есть такой момент

импорт XDTO не обрабатывает аттрибут fixed

Начиная с версии платформы 8.3.10 этот атрибут стал обрабатываться, но при этом 1С не сохраняет XDTO пакет, ругается вот так (на примере импорта файлов ГИС ЖКХ)

Ошибка проверки модели XDTO: xdto-objectType-3.9.1 (определение анонимного типа) свойство: exportOrgRegistryRequest пакет: http://dom.gosuslugi.ru/schema/integration/organizations-registry-common/
Неоднозначное определение свойства 'version'

Я вычистил пакеты и оставил только элемент, который вызывает проблему.
Собственно вопрос - каким образом заставить 1С понять, что это атрибут из указанного пространства имен и при этом имеет фиксированное значение?
Пусть даже вручную. Как вообще задавать фиксированные значения в XDTO?
При необходимости можно будет потом перед импортом поправить исходные xsd, главное, чтобы потом на выходе получился правильный XML.
Во вложениях исходная схема XSD, вычищенная схема XSD (только с проблемой) и конфигурация в которую импортирован вычищенный вариант. Но обновить базу не получается из-за указанной проблемы. Импортировать в 1С надо файл hcs-organizations-registry-common-types.xsd

Прикрепленные файлы:

original_XSD.zip
clean_XSD.zip
1Cv8.dt

По теме из базы знаний

Вознаграждение за ответ

Сумма: 5 $m

Добавили:
PythonJ (5.00 $m)

Показать полностью

Ответы

Подписаться на ответы Инфостарт бот

Свернуть все

2. rujiy_kot 11 13.04.18 11:48 Сейчас в теме

Попробуйте удалить определение типа для свойства "exportOrgRegistryRequest", в свойствах этого свойства "exportOrgRegistryRequest" задайте Тип "String", Фиксированное = Истина, По умолчанию, например, "10.0.2.1".

3. PythonJ 117 13.04.18 11:57 Сейчас в теме

(2) В итоге в свойстве "exportOrgRegistryRequest" должен быть атрибут "version = 10.0.2.1". Само свойство "exportOrgRegistryRequest" не фиксированное. Тут еще надо вспомнить недобрым словом тех кто эту XSD рисовал изначально (разработчики ГИС ЖКХ). Потому что вообще-то "exportOrgRegistryRequest" - это не свойство. В итоговом XML это элемент с вложенными элементами. Вот правильный результат:

<organizations-registry-common:exportOrgRegistryRequest Id="signed-data-container" base:version="10.0.2.1">
	<organizations-registry-common:SearchCriteria>
		<organizations-base:OGRN>1231231231231</organizations-base:OGRN>
	</organizations-registry-common:SearchCriteria>
</organizations-registry-common:exportOrgRegistryRequest>

При этом в "base:version="10.0.2.1" ссылка на пространство имен "base" обязательна.

4. rujiy_kot 11 13.04.18 14:22 Сейчас в теме

(3) А если в "exportOrgRegistryRequest" в определении типа "{http://dom.gosuslugi.ru/schema/'... убрать признак "Фиксированный" и "По умолчанию", а вот в самом пакете base, где задаётся version - там поставить "Фиксированный" и "По умолчанию "10.0.2.1"?
В этом случае конфа сохраняется и обновляется. А вот при формировании пакета, происходит заполнение как Вам нужно?

5. PythonJ 117 16.04.18 14:10 Сейчас в теме

(4) Так, конечно, работает, но это не решает проблемы. Беда в том, что свойство "version" есть у многих других свойств со ссылкой на пакет "base". И фиксированное значение в разных случаях разное.

6. rujiy_kot 11 16.04.18 16:46 Сейчас в теме

(5) Думаю, что платформа не позволит это сделать. Если фиксированное значение для определенного типа, то оно для всех мест, где это используется.
Возможно, следует в программном коде обходить этот вариант? И программным кодом заполнять разные "version".
Либо написать на v8@1c.ru

7. PythonJ 117 17.04.18 06:50 Сейчас в теме

Так и заполняю пока, программным кодом. Придется написать разработчикам, наверное, не знаю, будет ли от этого толк. Насколько я могу судить, это все-таки проблема платформы. Другие SOAP-клиенты, тот же SoapUI прекрасно понимает, чего от него требуется. Самое неприятное заключается даже не в программном заполнении поля, это как раз может быть даже лучше, лишняя проверка на совместимость версий. Грабли в том, что в перспективе мне было бы удобнее динамически создавать WSСсылки в коде по ссылке на WSDL и уже оттуда использовать ФабрикуXDTO. Если не установить для конфигурации режим совместимости, то ссылка просто не работает, так как платформа считает XSD некорректным.

8. johnnyshut23 71 30.04.18 21:40 Сейчас в теме

Отличный пример, спасибо!

Внимание! Тема сдана в архив