Добрый день.
Есть веб сервис на стороне SAP (сгенерирован на основе ФМ), обращение к нему идет из 1С. На входе таблица и переменная, соответственно от 1С приходит xml подобного вида:

SAP не может определить строки таблицы по тегу <m:item> и соответственно таблица оказывается пустой. Если руками исправить <m:item> на <item>, все работает нормально.

Вопросов собственно три:
1. Зачем 1С добавляет ссылку на пространство имен к тегу <m:item>?
2. Что можно сделать на стороне SAP для нормального анализа постпупающих данных?
3. Если у кого есть опыт по работе с SAP - 1С, какие еще сюрпризы готовит 1С?

P.s. И еще вопрос, как сообщить веб-сервису SAP что к нему прийдут данные со ссылкой на пространство имен? Т.е. как добавить атрибут elementFormDefault = «qualified» для элемента xsd:schema в WSDL SAP?

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

По опыту, 1С вообще очень своеобразно работает с XDTO и веб-сервисами.
На моей памяти был, например, случай, когда 1С почему-то воспринимала структуру с параметром и таблицей внутри просто как два отдельных параметра.

Элементы у меня 1С тоже нэймспэйсами любила метить. Лечил с помощью указания "Qualify schema - Elements" при определении типа данных в ESR. По поводу RFC-сообщения - не скажу, не сталкивался.

Типы данных для вызова из 1С как получаете, создаете ws-ссылку по wsdl c описанием сервиса? Или как-то еще?

Мы, намучившись с подобными вещами, пришли к решению:
создаем описания типов данных и сообщений на стороне 1С, загружаем их в ESR как External Definition и берем как типы сообщений для интерфейса 1С. Потом генерируем wsdl и создаем по нему ws-ссылку в 1С. Ну а в PI мэппинг из структуры 1С в структуру RFC и обратно.

В таком виде проблем пока не было.

Добрый день.
У нас для решения этой проблемы было создано xslt преобразование, которое исправляет пространство имен сразу при получении xml.

Здравствуйте! Да, пытаемся работать по "нормальному" варианту. Мы видимо еще не намучались, и в поисках своего решения
Просто интересно очень стало, ведь явно проблема работы на стороне 1С, неужели им никто не собщил и они не предпринимают никаких попыток решить проблему?
Не совсем понятно в какой момент вызывать преобразование? У меня веб сервис на базе ФМ, на входе данные и на выходе данные, доступа к xml нету.

Так вы PI-то используете или напрямую веб-сервис вызываете?

Насчет сообщить 1С: народ на форумах воет по поводу ругани 1С на теги "wsp:Policy" при импорте wsdl, начиная с 8.1. На дворе уже 8.3 - воз и ныне там.

Мы внедрились в один из методов класса CL_SOAP_HTTP_EXTENSION через расширения. Этот класс вызывается при приеме xml и xml в нем доступен и его можно обработать.

Я поэтому и спрашиваю, используется ли PI. Тогда и внедряться никуда не надо.

Вызываем напрямую, т.к. в идеале операции должны выполняться под разными пользователями, т.е. Иванов вызвал создание поставки и она создалась именно под Ивановым. Ну и еще пара причин не очень весомых.
Всё лишнее в т.ч. и policy обрезали при генерации wsdl в soamanager, пока работаем без них. Как то вы.. жестоко )))

Зато все работает стабильно уже года три, а 1с-ники так ничего и не исправили.

А что мешает из 1С пользователя передавать?
Просто, если у вас PI есть, логичнее его такими вещами нагрузить, там и способов побольше всякие камушки подводные обходить.

У нас есть SAP BC. Уже пробовали, все работает. Только у SAP не во всех модулях можно на входе подать имя пользователя, создавшего документ. А вызов метода в SAP в этом случае будет в любом случае по одним техническим пользователем.

Тоже были проблемы с использованием нашего сервиса со стороны 1С, когда тип сообщения для стороны 1С (т.е. используемый в WSDL) был задан как Message Type.
Дело было тоже в нэймспейсах. Пришлось вместо Message Type делать External Definition и прописывать там Qualified.

Например: <xsd:element name="year" type="xsd:string" minOccurs="0" form="qualified" xmlns:xsd="http://www.w3.org/2001/XMLSchema">

А можно чуть подробнее где изменяли (SAP, wsdl, 1C?) и как это повлияло на структуру запроса?

Изменения были в SAP PI.
В 1С ничего не изменилось. В wsdl изменилось автоматически.

В SAP PI был канал типа SOAP Sender - то есть мы предоставили веб-сервис, чтоб его вызывали из 1C. Отдали им wsdl-файл для вызова сервиса.
То есть был синхронный вызов: SOAP (вызов веб-сервиса из 1C) -> SAP PI -> SAP ERP и обратно ответ.
Вроде бы ситуация такая же, как у вас.

Внутри SAP PI типы сообщений для интерфейсов, участвующих в обмене, были сформированы с помощью объекта Message Type.
При тестировании веб-сервиса оказалось, что когда поступает сообщение с элементами такого вида:

то этот узел не преобразуется в мэппинге, то есть полностью игнорируется.

Причем нормально всё работало, если узел приходил с префиксом, например, ns0, вот так:

Но разработчики со стороны 1С сообщили, что повлиять на это не могут.

Пришлось в определении интерфейса, обслуживающего SOAP-вызов, тип сообщения задавать не с помощью Message Type, а с помощью External Definition, чтобы самостоятельно можно было создать xsd-файл и вписать туда дополнительные атрибуты.
Нужно было вписать elementFormDefault="qualified":

И для входящего интерфейса, и для исходящего.
После этого мэппинги работали корректно.

Вот выше вам пишут, что вроде бы можно установить свойство Qualify schema в типах данных, но у меня в SAP PI 7.0, видимо, такого нету.

Один-в-один и у нас такое же было. 1С напрочь отказывалась ставить префикс.