サービスが本当に同一である場合は、ウィザードを使用してスキーマを 2 回インポートする必要はありません。最初のサービスの WSDL をインポートしてスキーマとポートの種類を作成し、新しい送信ポートを作成して*、それに応じてバインディングを変更します。 2 番目のサービス (つまり、特にサービス URL) を指すようにします。
この状況は通常、WCF サービスが を使用MessageContracts
して、複数のサービス呼び出しに対して同じメッセージ ペイロードを受け入れるか返す場合にも発生します (DataContract
通常、フォームの「一意の」ルート要素名を取得する必要があるxmlns#MyMethod
および とは対照的ですxmlns#MyMethodResponse
)。
この場合 (つまり common MessageContracts
)、basvo の回答に加えて、次のようにしてこの問題を回避することもできます。
- 消費されるすべての WCF サービスのすべてのアーティファクトを Visual Studio の BTS プロジェクトにインポートします。
- 各要求 (または応答スキーマ) の最初の「インスタンス」を保持し、VS のオーケストレーション ビューで、2 番目以降の各ポート タイプを調べて、ポート上の重複した要求または応答メッセージ (「操作メッセージ」) を削除します。タイプ。(各ポート タイプの下に、要求、応答、および障害メッセージ タイプが表示されます)
- 次に、削除した各メッセージ タイプを「編集」し、手動で行って、保持しているスキーマの元のインスタンスに変更する必要があります。
- また、インポートされたファイルから重複したメッセージ タイプを削除するか、ハッキングする必要がある場合もあり
.xsd
ます。
ただし、Web サービスが変更され、インポートされたスキーマを再度「更新」する必要がある場合、これは面倒です。インポート ウィザードが重複したスキーマを検出し、この方法でそれらをマージするように提案された場合、これは便利な機能です。
*
更新- 明確にするために、orch 設計で同じ論理送信ポートを再利用しますが、展開された BTS サーバー/クラスターに新しい送信ポートを作成し、必要なメッセージに送信ポートをサブスクライブし、2 番目の Orch を送信ポートにリンクします (直接バインディングを使用しているかどうかに応じて)、明らかにバインディングを 2 番目の URL に変更します。