Content Enricher †
一言要約 †
送信先へ送る際に足りない情報を付与する
要約 †
あるシステムから別システムへメッセージを送信する際、ZIPコードだけじゃなく都市や州名など、顧客IDだけじゃなく名前や住所など元システムより多くの情報を必要とすることがよくある。
送信側が必要なデータ項目を持っていない場合どうやって他システムと通信するのか？
この問題はMessage Translatorの特別なケースなので検討すべき問題は似てるが、Message Translatorの例で示したケースとは若干異なる。
会計システムはスケジューリングシステムが提供しているものより多くの情報を必要とする
病院スケジューリングシステムが発行するメッセージには名前、患者ID、訪問日が含まれているが、会計システムには患者の氏名、保険会社、社会保障番号が必要となり、これらは顧客管理システムに含まれる。
強化問題の解決候補
候補A: スケジューリングシステムを修正し、追加情報を格納できるようにする。顧客情報が顧客管理システムにて変更されるとスケジューリングシステムにも変更を反映させる必要がある。この案は2つの重大な欠点がある。1つはスケジューリングシステムはパッケージ化されたアプリケーションであることが多いため修正することが難しい。2つ目は、何か変更があるたびにスケジューリングシステムを変更しなければならない(例: 患者に手紙を送りたい場合、メールアドレスを追加しなければならない)。
候補B: 訪問メッセージを送信する前に顧客管理システムからSSNとキャリアをリクエストする。この方法は最初の問題は解決されるが2つ目の問題は残ったまま(スケジューリングシステムがSSNとキャリアが必要だと知らなければならない)。疎結合システムは、あるシステムが次のシステムが何をするかを指示する必要はなく、代わりにEvent Messageを送って他システムが何をすべきかを決定させる。スケジューリングシステムが会計システムや顧客管理システムと結びついており、統合ソリューションを脆くさせよろしくない。
候補C: 会計システムの前に顧客管理システムにメッセージを送ることで依存関係をいくらか回避でき、スケジューリングシステムをメッセージの後続フローから切り離すことができる。しかしながら、患者が訪問した後に保険会社が請求書を受け取るビジネスルールを実装するには顧客管理システム内部を修正する必要があり、もしパッケージソリューションだった場合は難しい or 不可能。もし変更できたとしても顧客管理システムは請求メッセージを送る責務を間接的に持ってしまう。会計システムで必要なデータ項目が全て顧客管理システムで得られるのであれば問題ないが、他システムから取得する必要があると、はじめの状態に戻る。
候補D(図なし): 顧客IDのみ必要とし、顧客管理システムからSSNとキャリアを取得するよう会計システムを修正する。このアプローチは欠点が2つある。1つ目は会計システムと顧客管理システムが結びついてしまう。2つ目は、会計システムをコントロールすることが前提となっているが、ほとんどの会計システムはカスタマイズが限られたパッケージソリューション。
特殊な変換器であるContent Enricherを使って、不足情報を補強するために外部データソースにアクセスする
Content Enricherは外部ソースからデータを取得するため受信メッセージ内の情報(キーフィールドなど)を利用し、受信側のアプリケーションに応じて元情報が引き継がれたり必要としなかったりする。
Content Enricherによって注入された追加情報はシステム内のどこかで入手可能である必要がある。新しいデータの最も一般的なソースは以下の通り。
計算処理: Content Enricherは不足情報をアルゴリズムなどで算出可能であり、例えばZIPコードから都市と州の情報を得られたり、メッセージの合計サイズを計算したりできる。この場合は外部ソースを必要としないため、Message Translatorに非常に似ている。
環境: Content EnricherはOSから追加データを取得できる場合があり、タイムスタンプは典型的な例。
別システム: 最も一般的であり、別システムから不足データを取得し、データベースやファイル、LDAPディレクトリ、アプリケーション、ユーザ入力などがある。
多くの場合、外部ソースは別システムや企業の外側にあるので、Content Enricherとリソース間の通信がMessagingや別の通信機構を介して発生する。Content Enricherとデータソース間の疎通は同期(データが返るまでContent Enricherは送信できない)であるので、非同期メッセージングより同期プロトコル(HTTPやODBC接続など)がよいパフォーマンスを得られる。Content Enricherとデータソースは本質的に強く結びついているので、Message Channelsを通じて疎結合を実現しているのは重要ではない。
例に戻って、顧客管理システムから追加データを取得するためContent Enricherを間に挟むことで、スケジューリングシステムは上手く保険情報や顧客管理システムから切り離すことができ、ただ訪問メッセージを発行するだけでよい。
患者の例にEnricherを適用
Content Enricherは多くの場面で利用され、メッセージを小さく管理しやすい状態を保つために全データ要素を持ったオブジェクトではなく一意となるIDなどオブジェクトへの参照を渡すことがある。参照を元に必要なデータを取り出す必要がありContent Enricherがそのタスクを担うがいくつかのトレードオフがある。参照を使用すると元メッセージのデータ量は削減するが別途ルックアップが必要になる。参照の利用がパフォーマンスを向上させるかは、どれだけを参照として利用し、どれだけをContent Enricherを利用して元コンテンツを復元するかによる。最終的な受信者に到達する際に長い仲介リストを経るのであれば参照を用いてトラフィックを大幅に削減して、最後のステップでContent Enricherを挿入して不足情報をロードすることができる。もし持ち歩きたくないデータが含まれていればClaim Checkを用いてデータを格納し参照を得ることもできる。
例: 外部との通信
外部との通信をするにあたり特定のメッセージ標準(例: ebXML)に準拠する必要がある場合にContent Enricherが使われる。これらの標準のほとんどはデータの長いリストを持つ大規模なメッセージを必要とするので、内部メッセージをできるだけシンプルに保てば社内運用が楽になるので、組織外へメッセージを送信する際に不足メッセージを追加するContent Enricherを利用する。同様にContent Filterを使って受信メッセージから不要な情報を削除する。
外部と通信する際にContent EnricherやContent Filterを利用する
担当者のつぶやき †
みんなの突っ込み †
