Normalizer †
ひとこと要約 †
共通のフォーマットに合わせちゃえ。
要約 †
B2Bの統合において、異なるビジネスパートナーからメッセージを受け取ることは企業にとっては至極当然のこと。
- パートナーの内部システムや好みによって、同じ意味のメッセージでもフォーマットが異なってしまうことも。
- ペイパービューのプロバイダで1700超の提携企業を扱うのに、それらのほとんどが標準のフォーマットに従ってなかった。
意味的にはいっしょなんだけど、フォーマットの異なるメッセージの扱いってどうする?
技術的に最も簡単なのはすべての関係者に単一のフォーマットに従わせること。
- 大手企業でB2Bの取引やサプライのチャネルを持つようなところならできるかも。
- GMが注文状況の更新を共通のメッセージフォーマットで受け取りたければ、誰々さんのサプライヤー(Joe's Supplier)はGMのガイドラインに従うよね。
- 対して、多くのビジネスモデルは情報の「集約者(aggregator)」としてメッセージを受け取る立場にあり、各関係者と合意してることとしてはシステムの変更を最小限に抑える、というのがある。
- 集約者としては、EDIレコードやCSVファイルからXMLドキュメントや電子メールに添付されたExcelファイルに至るまでのあらゆるデータフォーマットを受け取って処理したいと。
多くのパートナーを取り扱うのに考慮すべき重要なことは、変更の割合。
- そもそもそれぞれの関係者は異なるデータフォーマットを求めるだけでなく、そのデータフォーマットがころころ変わったりする。
- 各パートナーが隔年でフォーマットを変更するしても、それら数十ものパートナーを扱うのに毎月あるいは毎週フォーマットを変える結果となることも。
- これらの変更は残りの部分の処理からは独立していることが重要。
入力メッセージフォーマットの多様性からシステムの残りの部分を分離させるのに、入力メッセージを共通のフォーマットに変換する必要がある。
各メッセージタイプを共通のフォーマットに合わせるのに、カスタムのMessage Translatorを通して配送するNormalizerを使う。
NormalizerはそれぞれのメッセージフォーマットをMessage Translatorに結びつけ、入力メッセージをMessage Routerを経由して適切なMessage Translatorへ転送する。
メッセージフォーマットの検出 †
適切なMessage Translatorへの転送は、Message Routerが入力メッセージのタイプを検出できるのを想定。
- 多くのメッセージングシステムは、メッセージタイプを表すフィールドをヘッダーに持つ。
- でも多くのB2Bシナリオでは、企業の内部システムに合ったメッセージが届くわけではなく、CSVやスキーマレスのXMLといった様々なフォーマットになる。
- タイプを表すフィールドを持つデータフォーマットの実装がベストプラクティスである一方、この世って完璧からは程遠いもんだよね。
- 結果として、入力メッセージのフォーマットを特定するのに、より一般的な方法を考える必要性が出てくる。
- スキーマレスのXMLの場合は、ルート要素の名前を正しいタイプとみなすことが一般的。
- もし複数のフォーマットが同じルート要素を使っていれば、XPathを使って特定のサブノードの有無で確定できる。
- 個々のビジネスパートナーはユニークな命名規則でファイルに名付けられる。
Message Routerで、同じ変換を複数のビジネスパートナーに使える。
- 複数のビジネスパートナーが同じフォーマットを使っているか、変換が複数のメッセージフォーマットを扱うのに十分一般的なものであれば有用。
- 例えばXPathは、ドキュメントがどんなフォーマットであれ、XMLから要素を見つけ出すのに非常によい。
Normalizerはメッセージングのソリューションでよく出てくるものなので、簡易表現のアイコンも作った。
担当者のつぶやき †
XPathはよく使ったなー。
ファイルやフォルダの話もあるあるネタ。