BizTalk 2013：スキーマ要素に別の名前空間を設定する

Question

BizTalkアプリケーションを開発して、サードパーティによって作成および管理されている多数のWebサービスを照会しています。スキーマ

基本的には、生成されたスキーマ内で名前空間と要素名がすべて間違っている（怠惰なC＃wsdl生成のため）ため、スキーマを自動的に生成することはできません。これは問題ありませんが、Webサービスのエンドポイントでは、スキーマ内の要素がすべて特定の名前空間で修飾されている必要がありますが、スキーマ全体の名前空間と一致するものはありません。

他の名前空間/スキーマを自分のスキーマにインポートする方法を知りましたが、要素の名前空間をデフォルト以外のものに変更する方法はわかりません。誰もこれを行う方法を知っていますか？

たとえば、Schemaルートには"http:/tempuri.org/"の名前空間が必要ですが、要素の1つに名前空間"http://schemas.datacontract.org/2004/07/ReadService.DTO.Inbound.Supplier"が必要ですが、BizTalk内ではその要素の名前空間を編集して変更することはできません。

はリクエストの1の本体は、次のようになります「。 『

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

「TEM」をこのケースであるhttp://tempuri.org/ COM』、 『COM1』と 『読み』、すべて異なる名前空間です、粗野が指摘したように、WCFプロジェクトのすべてのデフォルトの名前空間ですのBizTalkでWSDLから

の生成は、2つの問題作成します。いいえルートに適用

1. デフォルトの名前空間をteはtempuri.orgではありません（これがデフォルトとして認識されるため）。これはBiztalkの標準http：//..Folder.SchemaName名前空間です。これをtempuri.orgに変更すると、修正する必要があるエラーのカスケードが発生し、より大きな問題を解決することはできません。

2. WSDLが生成された方法により、ほとんどの場合、 "GetSupplierIdWithExternalId Request"のような名前が、スキーマが生成する関数の名前であるため、すべての名前が正しく指定されていません（GetSupplierIdWithExternalId）。要素の名前が適切に定義されていないため、エンドポイントでのプログラミングの遅延が原因です。これは単に生成プロセスによって想定されています。

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

   ：私がしようとすると、単一のフラットファイルスキーマを作成した場合、私はtempuri.orgに私を得ることを設定した場合

は、私は、ファイル全体のための単一の名前空間を定義し、することができます。 ..内部要素の名前空間が正しくないためにSOAP要求に失敗しました。

ありがとうございます！

Answer 1

"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スキーマでそれを変更しないでください。そうしないと、スキーマの不一致が発生します。

更新： 更新では、WSDLからスキーマを生成する際に2つの問題があります。

1. このスクリーンショットを貼り付けることはできますか？
2. GetSupplierIdWithExternalIdRequestは間違っていますか？その用語をWSDLで検索すると、それを見つけることができますか？ 操作の要求ラッパーと応答ラッパーは、通常、-Requestと-Responseという接尾辞が付いています。したがって、これは完全に正しいかもしれません。