この例では、DB2 Universal Database™ による SQL スクリプトを使用して、3 つのエンタープライズ・アプリケーション (Clarify、SAP、Siebel) からの 3 つのデータ・セットを持つ ID リレーションシップを照会します。
データは、IBM® Business Process Manager リレーションシップ・サービスにより関係付けられます。 各アプリケーションには、類似したカスタマー情報と、各アプリケーション間の情報を関係付ける ID リレーションシップが格納されます。
以下の 3 つの表に、各データベース内部に保管されるデータを示します。
表 1. Clarify カスタマー名 |
姓 |
自宅電話番号 |
ID |
Jessica |
Reed |
111 111 11111 |
clarify_1 |
Tara |
McLean |
333 333 33333 |
clarify_2 |
表 2. SAP カスタマー名 |
姓 |
自宅電話番号 |
ID |
Jessica |
Reed |
111 111 11111 |
sap_10 |
Tara |
McLean |
333 333 33333 |
sap_8 |
表 3. Siebel カスタマー氏名 |
自宅電話番号 |
ID |
Jessica Reed |
111 111 11111 |
siebel_6 |
Tara McLean |
333 333 33333 |
siebel_8 |
カスタマー・ビジネス・オブジェクト定義の名前およびエレメント (Integration Designer でデータベースごとに作成される) を次の表に示します。
表 4. 各データベースでのカスタマーのビジネス・オブジェクト定義ClarifyCustomer |
SapCustomer |
SiebelCustomer |
エレメント |
タイプ |
エレメント |
タイプ |
エレメント |
タイプ |
givenName |
string |
firstName |
string |
fullName |
string |
lastName |
string |
lastName |
string |
|
|
homePhone |
string |
homePhone |
string |
homePhone |
string |
clarifyId |
string |
sapId |
string |
siebelId |
string |
ID リレーションシップは、各データベース間の情報を関係付けるために定義されます。 このリレーションシップ (この例での呼び方は
ID) では、ビジネス・オブジェクト・エレメント
clarifyId、
sapId、および
siebelId を使用します。 これらのエレメントが使用される理由は、エレメントに各データベースの ID データが含まれており、そのデータがカスタマーごとに固有であるためです。 以下の表は、リレーションシップ内の異なるデータベースを、
IBM Business Process Manager で使用される共通 ID に関係付けるために使用されるロールについて説明しています。
表 5. ID リレーションシップの定義リレーションシップ名 |
ロール名 |
ビジネス・オブジェクト名 |
キー |
ID |
GenCustomer |
GenCustomer |
genId |
ClarifyCustomer |
ClarifyCustomer |
clarifyId |
SapCustomer |
SapCustomer |
sapId |
SiebelCustomer |
SiebelCustomer |
siebelId |
フル・リレーションシップ名は
http://CustomerModule/ID です。
フル・ロール名は以下のとおりです。
- http://CustomerModule/ClarifyCustomer
- http://CustomerModule/SapCustomer
- http://CustomerModule/SiebelCustomer
3 つのデータベースすべてに格納されているビジネス・オブジェクト内部のデータを、定義済みのリレーションシップを使用することによって互いに関係付けることができます。 各データベースのカスタマー ID データは、インスタンス ID を共有することにより、他のデータベースのカスタマー・データと関係付けることができます。 例えば、Tara McLean は Clarify では
clarify_3 ID で、SAP では
sap_8 で、Siebel では
siebel_8 で、それぞれ識別されます。 固有の ID は、
IBM Business Process Manager リレーションシップ・サービスによって生成されます。
ヒント: このビューを使用してリレーションシップ表の内容を表示することができます。
共通データベースで作成したビューを使用することにより、複数のリレーションシップ・インスタンスを定義できます。 (前述の命名規則を使用した) ビュー名からそれに対応するリレーションシップ・ロールへのマッピングは、共通データベースの
RELN_VIEW_META_T 表に取り込まれます。 以下の表に、
ClarifyCustomer、
SapCustomer、および
SiebelCustomer ロールのビュー名の例を示します。
表 6. RELN_VIEW_META_T 表VIEW_NAME |
RELATIONSHIP_NAME |
ROLE_NAME |
V_ID_CLARIFYCUSTOMER_098 |
http://CustomerModule/ID |
http://CustomerModule/ClarifyCustomer |
V_ID_SAPCUSTOMER_515 |
http://CustomerModule/ID |
http://CustomerModule/SapCustomer |
V_ID_SIEBELCUSTOMER_411 |
http://CustomerModule/ID |
http://CustomerModule/SiebelCustomer |
V_USASTATE_ABBREVIATION_DE8 |
http://CustomerModule/USASTATE |
http://CustomerModule/Abbreviation |
V_USASTATE_CODE_B32 |
http://CustomerModule/USASTATE |
http://CustomerModule/Code |
V_USASTATE_NAME_933 |
http://CustomerModule/USASTATE |
http://CustomerModule/FullName |
表 1 に説明されているビューの列定義には、以下のプロパティーと共に
ROLE_ATTRIBUTE_COLUMN が入ります。
表 7. ビューの列定義 列名 |
データ型 |
値 |
説明 |
KEY_ATTRIBUTE_NAME |
キー属性タイプにより異なる |
ヌル以外 |
これは、ロール・インスタンス・データの格納先です。
ID リレーションシップの場合、列の名前はキー属性の名前になります。 例えば、SAPCUSTOMER_SAPID では、キー属性名として sapid を使用し、ビジネス・オブジェクト名として sapcustomer を使用します。 キー属性ごとに 1 つの列を定義します。
静的リレーションシップの場合、列の名前は DATA になります。 |
以下の表では、ID リレーションシップの共通データベースでのビューを示します。
表 8. ビューの列定義Clarify ロールのビュー |
SAP ロールのビュー |
Siebel ロールのビュー |
INSTANCEID |
INSTANCEID |
INSTANCEID |
CLARIFYCUSTOMER_CLARIFYID |
SAPCUSTOMER_SAPID |
SIEBELCUSTOMER_SIEBELID |
STATUS |
STATUS |
STATUS |
LOGICAL_STATE |
LOGICAL_STATE |
LOGICAL_STATE |
LOGICAL_STATE_TIMESTAMP |
LOGICAL_STATE_TIMESTAMP |
LOGICAL_STATE_TIMESTAMP |
CREATE_TIMESTAMP |
CREATE_TIMESTAMP |
CREATE_TIMESTAMP |
UPDATE_TIMESTAMP |
UPDATE_TIMESTAMP |
UPDATE_TIMESTAMP |
ROLEID |
ROLEID |
ROLEID |
注: このビューの列名は、キー属性の列名を除き、すべて一致します。
ビューに対して SQL を実行し、ロール・インスタンス・データを操作するには、ロールのランタイム・テーブル・ビューの名前を知っておく必要があります。
以下の SQL スクリプトは、DB2 Universal Database の使用例を示しています。 この例では、各データベースのすべてのデータがリレーションシップ・データベースにコピーされていることが前提になっています。 データをコピーするには、
SELECT INTO SQL ステートメントを使用します。
// 3 つすべてのアプリケーションからの ID 値をカスタマーごとに保管する表を作成し、
// 固有のインスタンス ID を各カスタマーと関連付けます。 // この表を基本のソース表として使用し、
// リレーションシップ表にデータを取り込みます。
CREATE TABLE joint_t (instanceid INTEGER NOT NULL GENERATED ALWAYS AS IDENTITY,
clarify_id VARCHAR(10) NOT NULL,
sap_id VARCHAR(10) NOT NULL,
siebel_id VARCHAR(10) NOT NULL)
// 名前と自宅電話番号を 3 つのアプリケーション表にまたがって比較します。
// 一致する人物が見つかったら、その人物の ID 値を各アプリケーション表から
// joint_t 表に挿入します。 3 つの ID 値を固有 ID に関連付けます。この ID は、
// 後でリレーションシップ・インスタンス ID として使用します。
INSERT INTO joint_t (clarify_id,sap_id,siebel_id)
SELECT A.ID, B.ID, C.ID
FROM clarifycustomer A,sapcustomer B, siebelcustomer C
WHERE A.homephone=B.homephone AND
B.homephone=C.homephone, AND
B.givenname=C.firstname AND
B.lastname=C.lastname AND
A.fullname=C.firstname CONCAT ' ' CONCAT C.lastname
// 各アプリケーションのシーケンスを作成します。このシーケンスは、後で
// 各ロール表のロール ID として使用します。
CREATE SEQUENCE clarify_roleid MINVALUE 1 ORDER CACHE 100
CREATE SEQUENCE sap_roleid MINVALUE 1 ORDER CACHE 100
CREATE SEQUENCE siebel_roleid MINVALUE 1 ORDER CACHE 100
// CLARIFY ロールのロール・インスタンス表にデータを取り込みます。
INSERT INTO V_ID_CLARIFYCUSTOMER_098 (instanceid, roleid,
clarifycustomer_clarifyid, status, logical_state, logical_state_timestamp,
create_timestamp, update_timestamp)
FROM joint_t
// SAP ロールのロール・インスタンス表にデータを取り込みます。
INSERT INTO V_ID_SAPCUSTOMER_515 (instanceid, roleid, sapcustomer_sapid,
status, logical_state, logical_state_timestamp, create_timestamp,
update_timestamp)
SELECT instanceid NEXTVAL FOR sap_roleid, sap_id, 0, 0, current
timestamp, current timestamp, current timestamp
FROM joint_t
// SIEBEL ロールのロール・インスタンス表にデータを取り込みます。
INSERT INTO V_ID_SIEBELCUSTOMER_AFC (instanceid, roleid, siebelcustomer_siebelid,
status, logical_state, logical_state_timestamp, create_timestamp, update_timestamp)
SELECT instanceid, NEXTVAL FOR siebel_roleid, sap_id, 0, 0, current timestamp,
current timestamp, current timestamp
FROM joint_t
joint_t 表は、キー値を一時的に保管するために作成されます。 リソースの保存が終了したら、必要に応じて表を削除できます。 または、ビュー・テーブルまたは一時テーブルを作成することもできます。