トランスフォーメーション・サービス 1 ∼BOマップ/リレーションシップ/インターフェース・マップ∼ WebSphere Process Server V6
by user
Comments
Transcript
トランスフォーメーション・サービス 1 ∼BOマップ/リレーションシップ/インターフェース・マップ∼ WebSphere Process Server V6
WebSphere Process Server V6 トランスフォーメーション・サービス トランスフォーメーション・サービス ∼BOマップ/リレーションシップ/インターフェース・マップ∼ 福増玲子 日本IBM SW事業 WebSphere テクニカル・セールス Copyright IBM Japan Co.,Ltd 2005 1 WebSphere Process Server V6 トランスフォーメーション・サービス Agenda 概要 はじめに トランスフォーメーション・サービスの必要性 マップの機能 マップの配置 トランスフォーメーション・サービスの位置付け 呼び出しの流れ ビジネス統合ソリューション作成 におけるマップ定義 ツールと定義 アーキテクチャー インターフェース・マップ z インターフェース・マップ アーキテクチャー z インターフェース・マップの変換機能 ¾ パラメーター・マッピング ビジネス・オブジェクト・マップ z ビジネス・オブジェクト・マップ アーキテクチャー z ビジネス・オブジェクト・マップの変換機能 リレーションシップ z リレーションシップ アーキテクチャー z 静的リレーションシップ z IDリレーションシップ 2 2 WebSphere Process Server V6 トランスフォーメーション・サービス 概要 3 3 WebSphere Process Server V6 トランスフォーメーション・サービス はじめに ∼企業のアプリケーションを統合するには∼ 財務 Finance 営業支援 SFA 人 事 HR サプライ・チェーン SupplyChane レガシー システム 理想の企業システムとは 全ての考えられうる適用業務について最前線のソ リューションを提供し、ほぼリアルタイムなインター フェースを用いて完璧に統合していること。 現実には 全てのビジネス業務・業界を満たす最前線のソ リューションを提供するには、１社のアプリケー ション・ソフトウェア・ベンダーには収まりきらな い。 その結果、ほとんどの企業は、ソフトウェ アを選定するにあたり、〝best-of breed〟すな わち、各分野において最良なパッケージ・ソフト ウェアをそれぞれ活用していくというアプローチ をとり、各システム間でインターフェースを使っ たデータ転送が必要になる。 そこで発生する課題は 元々他システムとの連携をデザインされていな いレガシーシステムと〝best-of breed〟なアプ リケーション。 これらのシステムを連携して稼働させるには、 どうすれば良いか？ 4 トランスフォーメーション・サービスに入る前に、背景を考えてみましょう。 実際の企業システムは、複数のアプリケーションが存在しているのが現実です。 −業務要件に最適のシステムを採用することによって、各組織の生産性を最大限に引き出したい −独自開発で実装されたレガシーシステムから、パッケージ・アプリケーションへ移行したい −企業内で独自アプリケーション・システム群の統合を必要としている −単独のソフトウェア・プロバイダー上に依存しない管理ポリシーがある 例として、まず、5つのアプリケーション・システムを持つ企業があったと過程します。 実際には、ほとんどの会社はこれよりもっと多数のシステムをお持ちでしょう。 いくつかのインターフェースが必要になってきます。 たとえば ・給与支払い情報を人事システムから会計システムへの転送 ・お客様情報をCRMから会計システムへ転送 ・サプライチェーンにおける在庫の増減を財務アプリへ記録 といった連携のためのインターフェースが考えられます。 それでは、組織が直面する2つ目のジレンマについて見ていきましょう。 4 WebSphere Process Server V6 トランスフォーメーション・サービス はじめに ∼従来の作り込みによる統合ソリューション∼ Point-to-point 財務 Finance 営業支援 SFA 人 事 HR 統合 nシステム接続 ⇒ n(n-1)本 アプリケーション間同士で、直接 データ変換 懸念事項 コストがかかる 拡張性が無い 実装・保守・アップグレードが難しい サプライ・チェーン SupplyChane レガシー システム 20インターフェース 5 従来の作り込みにより、統合を実現する方法を考えてみます。 アプリケーションが nシステムあるとします。 各アプリケーションが、他の全アプリケーションにそれぞれ1対1で接続し、相互にデータを送りあう方式を 仮定します。 必要なインターフェースの数は、n x ( n ‒ 1 )という算式ではじき出されます。 現実的には多数のアプリケーションが他の全アプリケーションと接続することは無いにせよ、あるアプリ ケーションから別のアプリケーションにそれぞれ複数インターフェースを使って接続する要件も出てくるは ずです。 たとえば、人事システムから営業支援システムへの接続は不要だったとしても、財務システムからサプラ イ･チェーンへは複数の接続が必要なケースも有り得ます。 よって、全体を見れば、概ね n x ( n ‒ 1 ) 本と算出することができます。 図の例では、5つのシステム同士を接続するのに20本ものインターフェースが必要であり、日次で保守・運 用が発生します。 さらに、アップグレードについて検討してみます。財務アプリケーションをアップグレードした場合、財務ア プリと他のアプリをつなぐ全インターフェースに影響が出てきます。この影響を少なく見積もってしまうと、 後々問題になります。なぜならインターフェースは、非常に変更・アップグレードするのは難しいからです。 では、これに対する、典型的なソリューションを、次に紹介します。 5 WebSphere Process Server V6 トランスフォーメーション・サービス はじめに ∼WebShere Process Server と汎用データ・モデル∼ 財務 Finance 営業支援 SFA 分散化、モジュール化された〝ハブ・アンド・ スポーク型〟のアーキテクチャを採用 アプリケーションから独立したビジネス・プロ セス コモン・オブジェクト・モデル 人 事 HR コンポーネント再利用 汎用 ビジネス・オブジェクト サプライ・チェーン SupplyChane レガシー システム ビジネスプロセス 統合モジュール 5インターフェース 汎用ビジネス・オブジェクト：Generic Business Objects(GBO) 6 前頁の例のように直接システム同士を20本のインターフェースでつなぐ代わりに、ハブ・アンド・スポーク型 システムを採用します。 アプリケーションは、どのアプリケーションからデータを要求されても、統合サーバーへデータを送りさえす れば良いのです。 図のシステムでは、５接続またはインターフェースがあれば要件が満たされます。 営業支援システムでお客様情報の変更が発生すると、まずそのデータは統合サーバーに転送されます。 そして、財務、レガシーシステム、そしてその他必要なシステムへと渡されます。 もし、営業支援システムがアップグレードされた場合には、営業支援に接続しているインターフェース（す なわち、アダプター）のみ変更すれば良いのです。 このハブ・アンド・スポーク型を最大限に活用するために、汎用ビジネス・オブジェクトという考え方がありま す。 中間層として各データ要素の最小公倍数的な項目を網羅した、どのシステムからも汎用的に参照できる データ型を共通オブジェクトとして定義します。そして直接アプリケーション同士でデータ変換をひもづけ るのではなく、この汎用ビジネス・オブジェクトを経由することにより、より一層再利用しやすく変更に強い システムとする設計です。 では、このようにハブ・アンド・スポーク型でつなぎ合わせるときに必要な機能として、トランスフォーメー ション・サービスについて見ていきましょう。 6 WebSphere Process Server V6 トランスフォーメーション・サービス トランスフォーメーション・サービスの必要性 一つの統合ソリューションを実装するには多数のコンポー ネント同士を連携する必要がある インターフェースのミスマッチは避けられない 同じモジュール内でのコンポーネント同士 異なるモジュール間でのコンポーネント同士 コンポーネントと外部サービス WebSphere Process Server EIS1 EIS1 エクスポート EIS2 ビジネス・プロセス EIS2 インポート 7 一つの統合ソリューションを実装するには、多数のコンポーネント同士を連携する必要があります。 どんな統合ブローカーでも、ソリューションとしてパズルのように多種多様な部品を統合していくためには、 各々のインターフェースに差異があろうとも接着しつなぎ合わせるメカニズムが実装されていることが必須 となります。 7 WebSphere Process Server V6 トランスフォーメーション・サービス トランスフォーメーション・サービスの必要性 （続き） 異なるインターフェース同士を統合するための機能 『エクスポート』と『インポート』 『インターフェース・メディエーション・コンポーネント』 実現するサービス 発信元の全オペレーションを宛先インターフェースのオペレーションへ仲介 パラメータ間の変換に、マップを利用 リレーションシップ維持のため、コンテキスト情報を提供 Web Service EIS WS エクスポート メディエーション コンポーネント ビジネス・プロセス メディエーション コンポーネント EIS インポート 8 インターフェース同士では多少なりとも差異が存在します。 図の例を見てみましょう。 WBIプログラミング・モデルと様々なEISベンダー固有のプログラミング・モデルとの間を結ぶ必要がありま す。 アプリケーションとの接点として、WebService側は『エクスポート』、EIS側は『インポート』のコンポーネント が使われます。 インターフェース・メディエーション・コンポーネントは、アプリケーション固有のプログラミング・モデルと SDOベースのデータ型であるビジネス・オブジェクトとの間に残るギャップをうめるための汎用的なアダプ ターとして機能します。 8 WebSphere Process Server V6 トランスフォーメーション・サービス マップの機能 WPSシステムを通して流れるフローについて、ビジネスオ ブジェクトをある型から別の型に変換する機能を担う 発生源と宛先のデータ間の変換ルールを定義 共通オブジェクト・モデルを実現 アプリケーションに依存しない方法でロジックを実行するプロセスを可能に 適用分野ごとに最良のアプリケーションを採用可能にする統合環境を提供 Web Service EIS WS エクスポート メディエーション コンポーネント ビジネス プロセス マップ メディエーション コンポーネント EIS インポート マップ 9 マップとは ・WPSシステムを通して流れるフローについて、ビジネスオブジェクトをある型から別の型に変換する機能 を担う ・発生源と宛先のデータ間の変換ルールを定義 ・アプリケーションから切り離した方法で、ロジックの実行を可能に ・”best-of-breed”で構築されたシステム同士をも統合する環境を提供 補足）best-of-breed システムを構築する際に、同一ベンダ、同一アーキテクチャの製品、あるいはスイート製品を使うのでは なく、各分野で最良のハードウェアやソフトウェアを選択し、その組み合わせでシステム構築を行うアプ ローチ。 データ・マッピングは異種アプリケーション間およびWPSシステムのコンポーネントを含めて、情報転送プ ロセスにおいて主要となる機能です。 アプリケーション固有のビジネスオブジェクト（ASBO)から汎用のビジネスオブジェクト（GBO)へデータを マッピングすることによって、WPS(WebSphere Process Server)のシステムは、よりモジュール化を促進し、 拡張性・マップの保守容易性を提供します。 9 WebSphere Process Server V6 トランスフォーメーション・サービス マップの配置 (1) 代表的なフローの例 代表的なフローでは、マッピング変換は3つ呼び出される イベント通知‥‥‥ 発信アプリケーション⇒WPS 要求‥‥‥ WPS⇒宛先アプリケーション 応答（戻）‥‥‥ 宛先アプリケーション⇒WPS 応答 イベント 通知 1 3 WebSphere Process Server EIS1 EIS2 2 要求 10 代表的なフローでのマップを見てみましょう。 ①アプリケーション固有のビジネス・オブジェクト（Application-Specific BO)が発信源のアプリケーション EIS1 から、汎用ビジネス・オブジェクト(Generic BO)に変換されます。 ②汎用ビジネス・オブジェクトが、宛先アプリケーション用のアプリケーション固有のビジネス･オブジェクト に変換され、要求処理に使用されます。 ③応答として、戻り値が格納されたアプリケーション固有のオブジェクトが汎用ビジネス・オブジェクトに変 換され、処理フローが完了します。 ④もし完全同期処理として、発信源のアプリケーションにも結果を戻す必要があれば、図にはありません が、①の逆向きとしてもう１回、汎用ビジネス・オブジェクトから、EIS１用のアプリケーション固有のビジネ ス・オブジェクトに変換されます。 10 WebSphere Process Server V6 トランスフォーメーション・サービス マップの配置 (2) 同期処理のケース 同期処理の構成 2システム間で各システムが発生源となるフローを構成し、同期を実現 ⇒2フロー 各ビジネス統合フローは3マップ必要（前頁） イベント通知処理で使ったマップは、もう一方のフローの応答処理で再利 用できる ∴ 2システム間の相互同期処理では4つのマップを用意 EIS1 WebSphere Process Server EIS2 11 前頁で、１フローには３マップが必要でした。 相互同期処理を行うには、それぞれのシステムが発生源となるため２フロー構成します。 単純に計算すると２フロー x ３マップ/フローあたり = ６マップになりますが、 イベント通知処理で用意したマップは、逆方向フローでは応答(戻)に再利用できますので、４マップ準備 することになります。 11 WebSphere Process Server V6 トランスフォーメーション・サービス WebSphere Process Server V6における トランスフォーメーション・サービスの位置付け サービス・ コンポーネント Business Business Processes Processes サポーティング ・サービス Interface Maps SOA コア Human Human Tasks Tasks Business Business State State Machines Machines Business Relationships Object Maps Service Component Architecture Business Objects Business Business Rules Rules Selectors Selectors Common Event Infrastructure WebSphere Application Server (J2EE Runtime) 12 実際にWebSphere Process Server Ver.6 でマップの機能は、トランスフォーメーション・サービスとして実 装されています。 トランスフォーメーション・サービスには、 ・インターフェース・マップ ・ビジネス・オブジェクト・マップ ・リレーションシップ の３機能が含まれます。 12 WebSphere Process Server V6 トランスフォーメーション・サービス 呼び出しの流れ インターフェース doOrder(Order) エクスポート doOrder BO (Order) インターフェース submitOrder(SAPOrder) インターフェース マップ Order ビジネス オブジェクト マップ OrderID リレーションシップ BO (SAPOrder) インポート submitOrderSAP SAPOrder SAPID 13 トランスフォーメーション・サービスの３機能を呼び出す流れを、図で説明しましょう。 それぞれ次のように呼び出されていきます。 ①発生源＝エクスポート doOrder からデータ（ビジネス・オブジェクト）Orderが生成され、オペレーション doOrder Order を要求される。 ②インターフェース・マップが受け取り、発生源のオペレーションを宛先のオペレーション SAPOrder に解 釈する。 ③インターフェース・マップから、ビジネス・オブジェクト・マップが呼び出され、BO Order から BO SAPOrderに変換される。 ④OrderIDとSAPIDは同じ意味の値であるが表現方式（キー）が異なるため、③のビジネス・オブジェクト・ マップからリレーションシップが呼び出され変換値が設定される。 ⑤宛先＝インポート submitOrderSAP に submitOrder(SAPOrder)が渡され処理される。 13 WebSphere Process Server V6 トランスフォーメーション・サービス ビジネス統合ソリューション作成におけるマップ定義 トップダウン RAD WID 定義＆実装 WID 定義 モジュール WID 定義 新規 コンポーネント WID ワイア WID 定義 BO ＆ インターフェース モジュール内の コンポーネント マッピング RAD WID 作成 WID テスト＆ デバッグ 既存資産の コンポーネント ボトムアップ モジュール＆ コンポーネント 14 開発の流れ全体は、後ほどWIDのセッションで登場します。 マップは、図の段階、すなわちコンポーネントが準備できた後に実装します。 14 WebSphere Process Server V6 トランスフォーメーション・サービス ツールと定義 (1) インターフェース・マップ…Interface mapping Editor インターフェースマップとは 2つの異なるインターフェースを 対応付け オペレーションにおける入力/出力 パラメーターの マッピングを定義 インターフェース・マップ・コンポー ネントを作成 パラメーター・マッピングは 4種類 Map setValue Move Java 15 インターフェース・マップ定義ツールとして、Interface mapping Editorを使います。 インターフェース・マップとは、２つの異なるインターフェースを関連付けるものです。（後述） まず、インターフェース・マップ・コンポーネントを作成します。 この中で、オペレーションにおける入力および出力パラメーターのマップを定義します。 パラメーター・マップは、以下の4種類で実装します。 ① Map --- マップ呼び出しとして、BOマップを使用 ② setValue --- 固定値を設定 ③ Move --- 値をそのままコピー ④ java --- Javaスクリプト呼び出し 15 WebSphere Process Server V6 トランスフォーメーション・サービス ツールと定義 (2) ビジネス･オブジェクト・マップ… Data Map Editor マップの単位 メッセージ内の項目 メッセージ全体 シンプルなマップ Move Extract Custom Join 等 複雑なマップ リレーションシップ 16 BOマップ定義ツールとして、Data Map Editorを使います。 BOマップは次の単位で実装できます。 ・メッセージのパーツレベル ・メッセージの全体レベル また、マッピング方法は、シンプルな場合、複雑な場合に大きく２つに分けられます。 (1) シンプルなメッセージのパーツをマッピングする Move（移動・コピー）, Extract（抽出）, Custom（カスタム）, Join（結合）, 等 (2) 複雑なメッセージのパーツをマッピングする リレーションシップ 16 WebSphere Process Server V6 トランスフォーメーション・サービス ツールと定義 (3) リレーションシップ…Relationship Editor リレーションシップには 2種類 静的リレーションシップ IDリレーションシップ 定義方法 リレーションシップ ロール 項目を特定 17 リレーションシップには、2種類あります。 ① 静的リレーションシップ めったに変更が無いデータ間の静的なクロスリファレンス（例：国コード） ② IDリレーションシップ フローを流していく中で、頻繁に追加・変更・削除が発生するデータ間の動的なクロスリファレンス（例： キー） リレーションシップはRelationship Editorで、次のように定義していきます。 ① リレーションシップにBOを追加する。BOは１Roleとして表現される ② 各Roleには、リレーションシップの参加者となるBOのエレメント（要素）を特定する ③ 各エレメントには、リレーションシップを定義する 17 WebSphere Process Server V6 トランスフォーメーション・サービス アーキテクチャー 18 18 WebSphere Process Server V6 トランスフォーメーション・サービス トランスフォーメーション・サービス インターフェース・マップ zオペレーション・マッピング zパラメーター・マッピング map move setValue BOマップ Move Extract Join Java Submap Custom Assign Custom Assign Custom Callout リレーションシップ ロール BO BO BO リレーションシップ 19 19 WebSphere Process Server V6 トランスフォーメーション・サービス インターフェース・マップ インターフェース・マップ zオペレーション・マッピング zパラメーター・マッピング BO変換 パス・スルー 値の設定 BOマップ Move Extract Join Java Submap Custom Assign Custom Assign Custom Callout リレーションシップ ロール BO BO BO リレーションシップ 20 20 WebSphere Process Server V6 トランスフォーメーション・サービス インターフェース・マップのアーキテクチャー インターフェース・マップとは インターフェース間での差異を解決し一致させる ソース・インターフェースとターゲット・インターフェースを１つずつ持つ（リファレンス) オペレーションとパラメータの組を変換する 宛先/ターゲットのコンポーネントを呼び出す 1インターフェース 1リファレンス インターフェース・マップ コンポーネント 次のインターフェースにおける不一致を解決する 同じモジュール内のコンポーネント間 異なるモジュール内のコンポーネント間 外部サービスとコンポーネント間 21 ビジネス統合コンテキストでは、インターフェース・マップ・コンポーネントはアプリケーション固有のビジネ ス・オブジェクト（ application-specific business object ）を汎用オブジェクトに変換する、あるいはその逆の マッピングの役割を担います。 21 WebSphere Process Server V6 トランスフォーメーション・サービス インターフェース・マップの変換機能 コンポーネント・インターフェースを経由し違いを一致 オペレーション・バインディング パラメーター・マッピング Operation1( in p1, in p2, map1 Operation2( in p1’, in p3, in p4, map2 in p2’, in p3’, in p5, out p6, fault f1) map3 in p4’, in p5’, out p6’, fault f1’) 22 インターフェース・マップでは、 ①オペレーション・バインディング ②パラメーター・マッピング を実装します。 22 WebSphere Process Server V6 トランスフォーメーション・サービス パラメーター・マッピング (1) BO変換 インターフェース・オペレーション間でインプット/アウトプット の互換性が無い場合に適用 BOマップを使って変換 sourceInterface.asboOperation( in ASBO1, out ASBO2 ) Request ASBO > GBO MAP1 GBO > ASBO MAP2 Response targetInterface.gboOperation( in GBO1, out GBO2 ) 23 インターフェース・マップにおける、パラメーター・マッピングの種類を見ていきます。 (1) BO変換 ソース・インターフェース（すなわち、アプリケーション固有のコンポーネント）中の１オペレーションを、ター ゲット・インターフェース（すなわち汎用コンポーネント）の１オペレーションに接続するときに、 1. 入力（要求）パラメーター ASBO1 は、MAP1変換に渡されます。 2. 入力パラメーターASBO1は入力パラメーターGBO1に変換された後、ターゲット・オペレーションに渡さ れます。 3. ターゲット・オペレーションはGBO2 出力パラメータを応答として返し、MAP2に渡されます。 4. 出力パラメーターGBO2は出力パラメーターASBO2に変換され、戻り値として要求（ソース）元オペ レーション に返されます。 23 WebSphere Process Server V6 トランスフォーメーション・サービス パラメーター・マッピング (2) パス･スルー インターフェース・オペレーション間でインプット/アウトプット の互換性がある場合に適用 オペレーションから別のオペレーションに、直接そのまま渡 す sourceInterface.bgOperation( in BG1, out BG2 ) Request Response targetInterface.bgOperation( in BG1, out BG2 ) 24 (2) パス･スルー ソース・インターフェース中の１オペレーションを、ターゲット・インターフェースの１オペレーションに接続 するときに、 1. 入力（要求）パラメータ BG1 は、ターゲット・インターフェース・オペレーションに、そのまま渡されます。 2. ソースとターゲット、双方の入力パラメータは同じ型を利用していることが条件です。 3. ターゲット・オペレーションは、出力パラメータBG2を戻り値として渡し、要求オペレーションに戻り値と してそのまま返されます。 4. ソースとターゲット、双方の出力パラメータは同じ型を利用していることが条件です。 24 WebSphere Process Server V6 トランスフォーメーション・サービス パラメーター・マッピング (3) 値を設定 インターフェース・オペレーション間でインプット/アウトプット の互換性が無い場合に適用 ソース入力引数が無い場合 sourceInterface.bgOperation( SetValue Literal out BG2 ) SetValue XPath Request Response targetInterface.bgOperation( in String, out BG1 ) 25 (3) 値を設定 ソース・インターフェース中の１オペレーションを、ターゲット・インターフェースの１オペレーションに接続 するときに、 1. ソース・インターフェース・オペレーションには、入力（要求）パラメータが定義されていません。 2. ターゲット・オペレーションが定義されていて、文字列の入力パラメータが必要。 3. ターゲット・オペレーションは出力パラメーターBG1を応答として返し、出力値BG2を抽出するために XPathプロセッサーに渡されます。 4. 出力パラメーターは、ソース・インターフェース・オペレーションにおける出力パラメーターBG2として戻 されます。 25 WebSphere Process Server V6 トランスフォーメーション・サービス パラメーター・マッピング (4) Java インターフェース・オペレーション間でインプット/アウトプット の互換性が無い場合に適用 引数にカスタム変換が必要な場合 sourceInterface.customOperation( in BG1 ) Request Custom Java targetInterface.customOperation( in BG2 ) 26 (4) Java ソース・インターフェース・コンポーネントの1オペレーションを、ターゲットの1オペレーションにひもづける 時に、 1. ソース・インターフェース・オペレーションでは、BG1という型の入力(要求)パラメーターを定義します。 2. ターゲット・オペレーションでは、BG2という型の入力パラメーターを定義します。 3. ソースの入力パラメーターBG1は、カスタムJava変換ユーティリティーに渡されます。 4. その結果、入力パラメーターBG2が算出されて、ターゲット・インターフェース・オペレーションに渡され ます。 26 WebSphere Process Server V6 トランスフォーメーション・サービス ビジネス・オブジェクト・マップ インターフェース・マップ zオペレーション・マッピング zパラメーター・マッピング BO変換 パス・スルー 値の設定 BOマップ Move Extract Join Java Submap Custom Assign Custom Assign Custom Callout リレーションシップ ロール BO BO BO リレーションシップ 27 次に、ビジネス・オブジェクト・マップについて、見てみましょう。 27 WebSphere Process Server V6 トランスフォーメーション・サービス ビジネス･オブジェクト・マップ アーキテクチャー ビジネス・オブジェクトおよびビジネス・グラフをサポート BO変換を必要とするいかなるコンポーネントから呼び出し 可能 次の機能をサポート 変更サマリー/イベントサマリーの変換 リレーションシップ・サービスの呼び出し ソース GBO ASBO ターゲット ASBO GBO Web Service EIS WS エクスポート ビジネス・プロセス EIS インポート ASBO > GBO GBO > ASBO マップ マップ 28 以下にマップに関する用語をあげます。 ・マップ定義 テンプレートであり、あるBOから別のBOへの変換ルールを設定したもの。 ・変換ルール ソースから宛先へオブジェクト/グラフを情報転送する方法。 ・サブマップ マップ定義は、変換ルールの呼び出しと同様に、別のマップを呼び出すことができる。 ・マップ定義に含まれる情報 Name Target namespace Source and destination Business Objects (or Business Graphs) Temporary variables Transformation rules ・マップ・インスタンス 実行時は、マップ・サービスからマップ・インスタンスが生成される ・コーリング・コンテキスト データの受け渡しは、コーリング・コンテキストで行われる ・呼び出しは、インターフェース・マップ⇒BOマップ⇒リレーションシップ の流れで行われる 28 WebSphere Process Server V6 トランスフォーメーション・サービス ビジネス･オブジェクト・マップの変換機能 Move （移動/コピー） Extract （分割） Join （結合） Submap （サブマップ） Custom （カスタム） Assign （値を設定） Custom Assign （カスタムアサイン） Custom Callout （カスタム呼び出し） Relationship （リレーションシップ） 29 ビジネス･オブジェクト・マップには、以下の9種類の変換タイプがあります。 ①Move （移動）– ソース属性値をターゲット属性に割り当てる（コピー）。 ②Extract（分割） – ソース属性値は文字列。ソース属性値の文字列の一部を、ターゲット属性に割り当て る。JavaのString.substring()メソッドと同じ役割。 ③Join （結合）- ２つ以上のソース属性値を１つに結合して、ターゲット属性に割り当てる。結合の結果は、 文字列になる。 ④Submap （サブマップ）- ソースおよびターゲットのデータ型はBO。呼び出すBOマップの入力および出 力は、ソースおよびターゲットと同じ型を持つ必要がある。 ⑤Custom （カスタム）- 特定のロジックをJavaコードで実装。 ⑥Assign （値を設定）- 固定値をターゲット属性に割り当てる。 ⑦Custom Assign （カスタムアサイン）- 入力を必要としないカスタム変換。Javaでロジックを実装して値を 割り当てる。ロジックはテキスト・エディターかビジュアル・エディターで設定。 ⑧Custom Callout （カスタム呼び出し）- 出力を必要としないカスタム変換。他の変換を実行する前の初 期化などに利用する。 ⑨Relationship （リレーションシップ）- リレーションシップを呼び出し、ソースからターゲットに変換する。 29 WebSphere Process Server V6 トランスフォーメーション・サービス リレーションシップ インターフェース・マップ zオペレーション・マッピング zパラメーター・マッピング BOマップ BOマップ パス・スルー 値の設定 Move Extract Join Java Submap Custom Assign Custom Assign Custom Callout リレーションシップ ロール BO BO BO リレーションシップ 30 続いて、リレーションシップについて、見ていきましょう。 30 WebSphere Process Server V6 トランスフォーメーション・サービス リレーションシップ アーキテクチャー リレーションシップ定義 リレーションシップ・ロールの論理的なグループ リレーションシップ・ロール 属しているビジネス・エンティティを表す リレーションシップ ロール EIS1_Customer Cust_ID FirstName LastName Status Customer EIS1Cust Cust_ID キー属性 EIS2_CUST EIS2Cust リレーションシップ リレーションシップ ロール CustomerId Name Status CreatedDate CustomerId 31 リレーションシップは複数のロールを保持します。 各リレーションシップ・ロールは、特定のビジネス項目とそれに付随した属性値と関連付けます。 つまり、リレーションシップは、関連づけられるキーとなるIDを含んだ属性値を ロール として定義しておき ます。（例：customer ID 属性） リレーションシップの定義： ・２つ以上の同じ意味を表すビジネス項目 ・リレーションシップにて、ビジネス項目を紐付け ・関連を決定づける属性値のセット リレーションシップ・ロールの定義： ・ビジネス項目がそのリレーションシップに対して、どのような形で参加／関係しているのかを記 述 ・構造をふまえて、ビジネス項目の要件を紐付け ・参加している各ロールについて、属性値のセットを持つ 31 WebSphere Process Server V6 トランスフォーメーション・サービス リレーションシップ アーキテクチャー （続き） 複数の異なるシステム（EIS）が一つの同じビジネス・エン ティティを表すのにそれぞれ別のIDを使っている場合 EIS1_Customer.Create EIS2_CUST.Create 108 3496 John Doe Active December 31, 2005 John Doe 0 12/31/2005 EIS1Cust Customer EIS2Cust リレーションシップ ロール定義 リレーションシップ ロール定義 OraCust SAPCust Oracle_Customer.Create SAP_CustomerMaster.Create 11527 TK421 John Doe Active 20052005-1212-31 リレーションシップ 定義 John Doe A 20051231 32 リレーションシップ・インスタンスとは、リレーションシップ定義が実行時にインスタンス化されたものです。 リレーションシップ・ロール・インスタンスとは、ロール定義が実行時にインスタンス化されたものです。 リレーションシップ・サービスは、リレーションシップおよびロールを実体化し保持します。また、同時に、実 行時においてリレーションシップ・インスタンスを管理し操作します。 ビジネス・オブジェクト・マップを通して、インターフェース・マップからリレーションシップへコーリング・コン テキストが渡されます。 （リレーションの呼び出しについては、2ページ前の図をもう一度参照してくださ い。） 32 WebSphere Process Server V6 トランスフォーメーション・サービス (1) 静的リレーションシップ 用途： 国コードのように通常ほとんど変更が発生しない データについて相互参照。フローの中では更新しない。 国 EIS1_Customer.Create 108 John Doe Active USA EIS1Ctry EIS2Ctry EIS1 国コード EIS2 国コード EIS2_CUST.Create 3496 John Doe 0 Data RIID China 1 RIID Data 1 01 France 2 2 02 Germany 3 3 03 Slovakia 4 4 04 USA 5 5 05 05 RIID: Relationship Instance ID 33 リレーションシップには2種類あります。 まず、1つ目が 静的リレーションシップ です。 リレーションシップでは、データベースに紐付けする表を保持しています。 静的リレーションシップでは、フローによって更新されることがない、ほぼ固定のデータを相互参照させる ことができます。 33 WebSphere Process Server V6 トランスフォーメーション・サービス (2) IDリレーションシップ （動的リレーションシップ） 用途： IDのように頻繁に変更・追加されるデータについて、 動的な相互参照。フローの中で更新をともなう。 Cust_ID RIID 106 107 108 109 110 40 41 42 43 44 RIID CustomerId リレーションシップ インスタンス 40 41 42 43 44 3494 3495 3496 3497 3498 EIS1Cust Customer EIS2Cust リレーションシップ・ロール インスタンス リレーションシップ・ロール インスタンス OraCust SAPCust customer_id RIID 11525 11526 11527 11528 11529 40 41 42 43 44 リレーションシップ インスタンス RIID MasterId 40 41 42 43 44 RB328 RN455 TK421 DD164 RB456 34 2つ目が、IDリレーションシップ（別名、動的リレーションシップ）と呼ばれるものです。 IDリレーションシップでは、フローの中で更新をともなうような、頻繁に追加・変更・削除が発生するような データについて 相互参照を実装します。 34 WebSphere Process Server V6 トランスフォーメーション・サービス 例）イベント・トリガー・フローにおけるリレーションシップ 例：典型的なイベント・トリガーのフロー リレーションシップを使用した３マップ リレーションシップは異なるコンテキストについて相互参照 を行う ソース・アプリケーション（図中EIS1）からWBIへ WBIから宛先アプリケーションへ 宛先アプリケーションからWBIへの戻り Verb Create（新規作成） Update（更新） Delete（削除） … 3 1 WebSphere Business Integration EIS1 EIS2 2 35 概要のところで使ったマップの一般例に、リレーションシップを組み合わせてみましょう。 各BOマップから、リレーションシップが呼び出され相互参照を行います。 35 WebSphere Process Server V6 トランスフォーメーション・サービス まとめ インターフェース・マップの定義： インターフェース・マップは: オペレーションとパラメーターの変換を実行する データ・マップを介して、リレーションシップの保守のためコンテキストを提供 ビジネス・オブジェクト・マップの定義: 1つのソース・インターフェースと1つのターゲット・インターフェース（リファレンス）を持つ ソース・インターフェースのオペレーションとターゲット・インターフェースのオペレーションを紐付け る パラメーター間の変換には、マップを使用 パラメーター属性値間での変換ルールを定義 他のマップをサブマップとして再起呼び出しできる 複数の入力/出力のビジネス・オブジェクト/グラフをサポート ビジネス・オブジェクト･マップは: ビジネス・オブジェクトのパラメーターをある型から別の型へと変換する インターフェース・マップから受け取ったコーリング・コンテキストを、リレーションシップに渡す 36 36