0

コンテキスト： XMLベースのAPIがあります。このAPIを使用してリクエストを受け取ります。次に、このリクエストをサードパーティ固有のAPIに変換するトランスフォーマーがあります。次に、変換されたオブジェクトを使用してWebサービス呼び出しを実行し、APIオブジェクトに変換して戻す応答を取得します。

一行でそれは次のようになります：

MY_API_REQ -> 3RD_PARTY_API_REQ -> WS-CAL -> 3RD_PARTY_API_RES -> MY_API_RES

とてもシンプル。

問題： ここで、応答で要求の一部をエコーバックしたいと思います。

それで、私のリクエストAPIに、レスポンスにも存在しなければならないEchoコンポーネントがあるとしましょう。最も簡単な解決策は、リクエストをサードパーティのAPIに変換する前に、このEchoコンポーネントをどこかに（たとえば、セッションスコープのヘッダープロパティに）格納することです。次に、応答ブランチでこのEchoコンポーネントを取得し、応答オブジェクトに設定します。

一行でそれは次のようになります：

MY_API_REQ -> Store parts -> 3RD_PARTY_API_REQ -> WS-CAL -> 3RD_PARTY_API_RES -> MY_API_RES -> Retrieve and set stored parts

懸念事項：このソリューションでは、可能な限り最高のソリューションを使用しているようには感じません。部分的に原因私は、フローの実行中に、私が気付いていないコピーメカニズムがあり、パフォーマンスについて心配しているのではないかと心配しています...

私はこれらすべてを同期的に行っているので、ずっと同じスレッドにいる必要があるので、おそらく私の懸念にはこれまで何の根拠もありません。ただし、パフォーマンステストやプロファイリングを行う前に、これについて皆さんにお聞きしたいと思います...

怠惰は半分の健康です。;）よろしくお願いします：T

4

1 に答える 1

1

2つの異なるアプローチがあります（最初のアプローチを使用しています）。

  • 保持したい情報をプロパティに保存し、アウトバウンドインタラクションでペイロードを応答に置き換え、その後、保存された情報をプロパティから取得します。この保存された情報をフロー間で共有する必要がない場合は、セッションプロパティの代わりにフロー変数を使用することをお勧めします。
  • 元のペイロードを目的の応答に変換し、この「エコー」値を伝播して、メッセージエンリッチャーを使用してアウトバウンドサービスと対話します。アウトバウンドインタラクションが実際に応答を強化することである場合、これは意味的に明確になる可能性があります。
于 2012-07-18T16:56:13.613 に答える