2016-05-20 4 views
1

Я разрабатываю приложение BizTalk для запроса ряда веб-сервисов, которые были написаны и поддерживаются третьей стороной, и у меня возникли проблемы с получением пространств имен прямо на Schemas.Biztalk 2013: настройка различного пространства имен на элементах схемы

В принципе, я не могу использовать wsdl для автоматического создания схем, потому что имена пространств имен и имен элементов являются неправильными в сгенерированных схемах (из-за ленивого поколения C# wsdl), поэтому мне приходится писать их с нуля. Это было бы хорошо, но конечные точки веб-службы требуют, чтобы элементы внутри схемы были квалифицированы с конкретными пространствами имен, и ни одно из них не соответствовало пространству имен общей схемы.

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

Например, корень схемы должен иметь пространство имен "http:/tempuri.org/", но для одного из элементов требуется пространство имен "http://schemas.datacontract.org/2004/07/ReadService.DTO.Inbound.Supplier", но в BizTalk я не могу изменить пространство имен этого элемента, чтобы изменить его.

Тело одного из запросов выглядит следующим образом: «.„

<tem:GetSupplierIdWithExternalId> 
    <tem:request> 
     <com:Header> 
      <com1:Username></com1:Username> 
      <com1:Locale></com1:Locale> 
     </com:Header> 
     <read:ExternalSupplierId></read:ExternalSupplierId> 
    </tem:request> 
    </tem:GetSupplierIdWithExternalId> 

«ПЭМ» в данном случае является http://tempuri.org/ ком“,„com1“и„читать“все разные пространства имен, которые, а Грубый отметил, все пространства имен по умолчанию для проектов WCF

Создание из WSDL в BizTalk создает 2 проблемы:.

  1. пространство имен по умолчанию, примененные к корню нет te не tempuri.org (поскольку он распознает это как значение по умолчанию), это стандартное пространство имен Biztalk http: //..Folder.SchemaName. Изменение этого параметра на tempuri.org вызывает каскад ошибок, которые необходимо устранить, и он не разрешает более серьезную проблему:

  2. Из-за того, как функции WCF, сгенерированные WSDL, записаны , имена основных элементов (GetSupplierIdWithExternalId) указаны неправильно - в большинстве случаев что-то вроде «GetSupplierIdWithExternalId Request», потому что это имя функции, с которой генерируется схема. Опять же, это связано с ленивым программированием на конечных точках, потому что имя элемента не определено должным образом, оно просто предполагается процессом генерации.

Если я пытаюсь создать единую схему плоский файл, можно определить только одно пространство имен для всего файла, и если я установил, что tempuri.org я получаю:

<ns0:GetSupplierWithExternalId xmlns:ns0="http://tempuri.org/"> 
    <Header> 
    <Username>Username_0</Username> 
    <Locale>Locale_0</Locale> 
    </Header> 
    <ExternalSupplierId>ExternalSupplierId_0</ExternalSupplierId> 
</ns0:GetSupplierWithExternalId> 

. .. который не выполняет запрос SOAP, потому что пространства имен на внутренних элементах неверны.

Заранее благодарен!

+0

Можете ли вы дать больше информации о том, почему вы не можете автоматически генерировать схемы? Почему вы говорите, что имена и имена элементов не так? Что они и чего вы ожидаете от них? Просьба привести примеры, только пару полей, чтобы передать точку? – Gruff

+0

@gruff Yep будет делать, как только вернусь на правильную клавиатуру! –

+0

"из-за ленивого поколения C# wsdl"? Что именно вы подразумеваете под этим? C# wsdl - это не то, что у нас есть в BizTalk? –

ответ

2

Вам нужно будет определить элемент с пространством имен «http://schemas.datacontract.org/2004/07/ReadService.DTO.Inbound.Supplier» в его собственном файле схемы и импортировать его в корневой каталог схемы и составить корень таким образом. Элемент будет содержать пространство имен, которое было определено как.

Глядя на пространство имен "http://schemas.datacontract.org/2004/07/ReadService.DTO.Inbound.Supplier", кажется, что это пространство имен по умолчанию, которое WCF присваивает контракту данных, потому что оно явно не определено.(Пространство имен CLR класса - ReadService.DTO.Inbound.Supplier) Когда DataContractSerializer сериализует сообщение при отправке запроса, он будет сериализовать его с этим пространством имен. Вы не должны пытаться изменить его в схеме BizTalk, иначе будет несоответствие схемы.

ОБНОВЛЕНИЕ: В своем обновлении вы указываете 2 проблемы при создании схемы из WSDL.

  1. Можете вставить скриншот об этом?
  2. Уверены, что GetSupplierIdWithExternalIdRequest? Если вы ищете в WSDL на этот срок, можете ли вы его найти? Операторы запроса и оболочки ответа обычно получают суффикс -Request и -Response, поэтому это может быть совершенно правильно.
+0

Хммм. Если я сгенерирую образец XML с использованием схемы и попытаюсь отправить этот запрос с помощью SOAPUI, я получаю целую волну ошибок из-за проблем пространства имен. Вы говорите, что этого не произойдет, если я отправил запрос с использованием порта BizTalk, потому что внутренние механизмы определяли, какие пространства имен применяются по умолчанию? –

+0

Да, мой совет состоял бы в том, чтобы не пытаться изменять пространства имен в схемах, которые генерируются мастером схемы. Затем используйте Fiddler для контроля того, что адаптер BizTalk WCF на порт отправки действительно отправляет по кабелю. – Gruff

Смежные вопросы