CAFIII - ビジネスオブジェクト*1モデラ アラカルト
ブロガー: マリオ ヘルガー (Mario Herger)
2004/1/26 pm7:26
翻訳： 古澤 昌宏
2004/11/2
これはCAF コンポジットアプリケーションフレームワークについての3つめのブログです。最初のブログコンポジットアプリケーションフレームワークとはなにか？、2つめのブログCAFII - どのツールをSAPは提供するのか?も、どうぞご覧下さい。.
始めに
オブジェクトレイヤ*1は各アプリケーションの基本ツールとなる。このレイヤにはパーシステンシの定義とライフサイクルメソッドが生成され格納されている。どのようにデータが格納されアクセスされるかはデータのタイプやデータの履歴、ビジネスニーズに依存する。
メニュー - シェフの見方から
このオブジェクトレイヤ*2というヤツを、ファンシーなレストランのシェフが彼のキッチンにいる状況と比較してみよう。
本日、おもてなしさせていただくのは私たちの最上の喜びですが、そのお客様から"filet mignon*3"の御注文をいただきました。焼き方はミディアム・レア。赤ワインソース添えです。サイドディッシュにはライスとヴェジタブルとフレンチフライに、目玉焼きをサニー・サイド・アップでトッピングしたものを用意します。お客様はおいしい食事がなによりお好きですから、御注文は上等のフランス産ワインで締めくくります。
さて、シェフがしなければならないことは? 'Filet mignon'ということは、彼が冷蔵庫へ行き、それを開けて、肉を取り出さなければならないことを意味している。同じ保存エリアには、卵と野菜とがやはり冷蔵庫の同一の引き出しにある。米は袋にあり、それはキッチンの反対側の乾燥ロケーションに保存してある。同じことがポテトについても言える。ほんの少しの違いは、ポテトは暗所に保存されるべきだということだ。小麦粉、塩、オイル、スパイスなどは、キッチンの棚の上にあるビン、カン、コップや他のケースに保存されている。ソース用の赤ワインは、通常、階下で一定の温度や湿度に保たれたワインセラーにある。
肉は今やラップが解かれ、卵の殻は割られ、米は袋から取り出されてライスクッカーに入れられ、野菜は水洗い。ジャガイモの皮は剥かれ、赤ワインのボトルは開栓されてソースを作るためにポットに注がれている。
メニュー - 開発者の見方から
お腹が空いた? じゃ、これを噛み砕いて、新型翻訳機"xApp-フィッシュ"にかけて、キッチンでの会話からオブジェクト*4レイヤの会話に翻訳してみよう。
本日、おもてなしさせていただくのは私たちの最上の喜びですが、そのユーザからデータの御所望がありました。基準は、フランスのセールス地域において状態が「ペンディング」になっている全セールスデータです。追加情報として、顧客情報、製品ドキュメント、そして営業が獲得した商談と、商談ごとの利益率、特定商談についての社内関係者からのコメントをトッピングしてほしいとのご要望です。また、ユーザは素晴らしいアイディアがなによりお好きですから、当該地域における今期のセールス予測もついでに付けておきましょう。
この要求に答えるには、異なるフォームに収められて分散したエリアに格納されているデータが必要だ。セールスと顧客情報は、CRMシステムのようなものから引っ張ってくる。製品情報は、それが構造化されていることが条件ではあるが、R/3システムのようなものから来る。ただし、PDFやイメージファイルのような製品情報はコンテンツ管理システムにある。利益率とコメントは、既存機能に対する拡張が必要なことを表し、従って、それらは xApp 自身に格納されているものから検索され算出される必要がある。セールス予測はデータウェアハウスから来る。
これは「単純な」例ではあるが、アーキテクチャとツールの課題を端的にあらわしている。既存の格納領域とアプリケーションが使われるべきだし、新しい格納領域とアプリケーションも作られてメニュー(- read: applications)として登録されなければならない。
ビジネスオブジェクト*5モデラ
ここで、シェフが新しいメニューおよび新しい材料と格闘しているところを想像して欲しい。複数種類の材料を格納する場所を探す。格納場所の開け方はどうしよう。それらを一緒のところに保存するのは難しい。特に、我がシェフ殿は、お客様それぞれがメニューを所望した場所にある沢山のレストランのひとつで働いているので。
もっと想像してみよう。我がシェフ殿は、実は沢山の格納場所の間を走り回らなくてもいいのだ。各格納場所の開け方や求められた材料をどうやって持ってくるのか（ええと、冷蔵庫のドアの開け方はこうで、缶の開け方はこう。ワインのビンの開け方は、卵の殻の割り方は、米袋の紐の解き方はこうで、プラスチック製のバッグの切り方は..）異なるツールと道具の使い方について、なども知る必要はないのだ。その代り、特別な召使が、材料を彼のところまで命令したとおりの量と状態で持ってきてくれる。我がシェフ殿がしなければならないことは、召使に言葉で伝えることだけだ。そして、召使どもへの言語と文法は同じだ：「卵黄２つ、どうぞ」「水5カップ」「肉1枚」。
ただ、こういうのはダメだ：「2つの卵の殻を割って、卵白から卵黄を分離させ、卵黄だけをこちらへ持ってきなさい」とか「蛇口をひねって水を出して水5カップを軽量しろ」とかね。
これは我がシェフ殿、言い換えれば「開発者」に何を意味しているのだろう。もう一度 "xApp-フィッシュ"で翻訳してみよう。
ここで、開発者が新しいアプリケーションと格闘しているところを想像して欲しい - どこにデータが格納され、それらデータを引き出してくるためにどんなAPI群を呼ぶ必要があるのか、それらをどうやって加工するか、という難しいものだ。特に、我が開発者殿は、お客様のために働くのだ。そのお客様といえば、最初のうちはデフォルト設定のまま使える、と正しいことを考えるものの、次第に重い改変を始めてしまうのだ。
さて、我が開発者殿が、次に挙げるようなことを勉強しなくても済むとしたらどうだろう。R/3-BAPIを、コンテンツマネジメントAPIを、データベースなどをどうやってコールするか。必要なデータを集めるやり方。異なる多数のプログラミング言語やマッピングツール、それにメタデータストレージなど、など。
素敵じゃないか！コンテンツマネジメントが、この製品IDに関係したすべての伝票を集めて届けてくれたら？また、同じツールが関連するお客様データをも持ってきてくれたら？でもって、こっちが「召使」すべてに対して命令するために知らなければならないことが、同じ言語で、単一インタフェースとして知られた同じ構造だったとしたら？
