アプリケーション固有のビジネス・オブジェクトには、コネクター・エージェントと特定のアプリケーション間でやり取りされるデータが含まれます。そのため、各アプリケーション固有のビジネス・オブジェクト定義には、それぞれのアプリケーションのデータ・モデルおよびコネクター・エージェントのアクセス方式が反映されます。
2 つのアプリケーション固有のビジネス・オブジェクトが類似のアプリケーション・エンティティーを参照する場合でも、属性の編成方法やアプリケーション固有情報に相違が現れます。
アプリケーションは、同一の情報を異なる方法で編成することがよくあります。例えば、アプリケーション A は連絡先用に電話番号と FAX 番号を 4 つのフィールドに格納していますが、アプリケーション B はこれらの番号を 2 つのフィールドに格納しています。
アプリケーション A ビジネス・オブジェクトとアプリケーション B ビジネス・オブジェクトのビジネス・オブジェクト定義は、この差異を反映して異なる属性を持ちます。
アプリケーション固有のビジネス・オブジェクトが異なるのは、各ビジネス・オブジェクトにコネクター・エージェントのための処理命令 (アプリケーション固有情報) を任意で組み込むことができるためでもあります。アプリケーション固有情報は、コネクター・エージェントがビジネス・オブジェクトを処理するために必要なあらゆる情報から構成されます。
ビジネス・オブジェクト定義には、ビジネス・オブジェクト全体、各属性、および各動詞に適用されるアプリケーション固有情報を含めることができます。ビジネス・オブジェクト定義内のアプリケーション固有情報が表示される各場所で、コネクターがアプリケーションとの対話に使用する情報が提供されます。
ビジネス・オブジェクトのアプリケーション固有情報は、コネクター・エージェントがビジネス・オブジェクト全体を処理するときに使用する情報を提供します。
属性に適用するアプリケーション固有情報は、アプリケーション内での属性値の位置を示すことがよくあります。コネクター・エージェントがアプリケーションへの API 呼び出しを構築して属性値を検索または入力するときに、この情報を使用します。
アプリケーション固有情報は、アプリケーションごとに異なる形式をとります。コネクター・エージェントは、アプリケーションの形式およびフィールド名によって属性の位置を参照できる場合もありますが、参照がより複雑になる場合もあります。
表 4 は、Customer
ビジネス・オブジェクトのアプリケーション固有情報の 2 つの例を示しています。
属性 | サンプル・アプリケーション 1 のアプリケーション固有情報 | サンプル・アプリケーション 2 のアプリケーション固有情報 |
---|---|---|
Customer ID | CUST:CID | cust:site_id::3:: |
Customer name | CUST:CNAM | cust:name::3:: |
Status | CUST:CSTAT | cust:status::1:0:Status |
Industry | CUST:CIND | cust:industry_type::3::Industry |
値には次の意味があります。
table:field:relation:type:default-value
ここで、type は、1 (int)、2 (float)、または 3 (string) を表します。
例外的に、属性のアプリケーション固有情報が必要ない場合があります。例えば、アプリケーションの中にはデータ単位の指定が直接的で使いやすいものがあります。アプリケーションが表 5
に示すようなサンプル・フィールドを識別することを考えてください。
属性 | 値を持つフィールドのアプリケーション ID
|
---|---|
Customer ID | XCustomerID |
Customer name | XCustomerName |
Status | XStatus |
Industry | XIndustry |
表 5 に示した例では、変換規則が規則的 (X を追加するか除く) なので、コネクター・エージェントが属性と アプリケーションの ID を容易に関連付けられます。このため、このアプリケーションのビジネス・オブジェクトの属性は、アプリケーション固有情報を 必要としないこともあります。
ビジネス・オブジェクト定義には、サポートされている動詞のアプリケーション固有情報を含めることができます。アプリケーション固有情報は、動詞がアクティブな場合、ビジネス・オブジェクトを処理する方法をコネクター・エージェントに指示します。