各アプリケーション固有のビジネス・オブジェクトには、データ、そのデータに対して実行されるアクション (動詞)、そのデータに関する情報 (アプリケーション固有の情報) が格納されます。コネクター・メソッドの多くは、アプリケーション固有のビジネス・オブジェクトを引き数として渡します。以下に例を示します。
コネクター、データ・ハンドラー、およびコネクター/データ・ハンドラーによってサポートされるアプリケーション固有のビジネス・オブジェクトの間の関係の設計は、コネクターおよびデータ・ハンドラーの開発の一環として実行される作業です。アプリケーション固有のビジネス・オブジェクトの設計では、コネクター開発処理に統合する必要のある、コネクターおよびデータ・ハンドラーのプログラミング・ロジックに関する要件が生成されることがあります。したがって、コネクター、データ・ハンドラー、およびアプリケーション固有のビジネス・オブジェクトの開発者は、これらのコンポーネントに関する仕様を共同で作成する必要があります。アプリケーション固有のビジネス・オブジェクトのレイアウトと設計は、そのオブジェクトを処理するコネクターまたはデータ・ハンドラーにより決定する必要があります。
このセクションの内容は次のとおりです。
ビジネス・オブジェクト定義には、以下の情報が含まれています。
ビジネス・オブジェクト定義の内容 | 説明 | 詳細情報の参照先 |
---|---|---|
ビジネス・オブジェクトの構造 | アプリケーション固有のビジネス・オブジェクトの構造は、コネクターまたはデータ・ハンドラーがそのアプリケーションと対話するレベル (表レベル、API レベル、または API 内の各種のレベルなど) で、アプリケーション・エンティティー (データ構造) に確実に対応するように設計するのが一般的です。 | "アプリケーション固有のビジネス・オブジェクトの構造" |
属性プロパティー | 属性には、アプリケーション・エンティティーの内部にある個々のデータが含まれています。属性には、そのほか、データのタイプ、カーディナリティー、デフォルト値などの情報を提供するプロパティーも含まれています。
属性プロパティーは、同様にその属性が必須属性であるかどうか、キー属性であるかどうかについても指定します。 | "アプリケーション固有のビジネス・オブジェクトの属性" |
アプリケーション固有の情報 | アプリケーション固有のビジネス・オブジェクトの定義には、ビジネス・オブジェクトのアプリケーション内での表現方法や、処理方法をコネクターに通知するためのテキスト・ストリングが組み込まれることもあります。 | "ビジネス・オブジェクトのアプリケーション固有の情報" |
コネクターまたはデータ・ハンドラーがビジネス・オブジェクトを処理する方法は、そのコネクターまたはデータ・ハンドラーがサポートしているビジネス・オブジェクトの構造によっても左右されます。アプリケーション固有のビジネス・オブジェクトの構造を設計するときには、どの構造により特定のアプリケーション・エンティティーを最も適切に表すことができるか、その構造がコネクターおよびデータ・ハンドラーのロジックの設計にどのような影響を及ぼすか、あるいはその構造が既存のコネクターまたはデータ・ハンドラーによってどのように処理されるかを判断する必要があります。
コネクターおよびデータ・ハンドラーの設計の目標の 1 つは、コネクターまたはデータ・ハンドラーが変更なしで新しいビジネス・オブジェクトや変更されたビジネス・オブジェクトを処理できるように、コネクターまたはデータ・ハンドラーをコーディングすることです。しかし、どんなビジネス・オブジェクトでも処理可能なコネクターやデータ・ハンドラーを作成することは困難です。
一般に、コネクターまたはデータ・ハンドラーは、自身のビジネス・オブジェクトの構造、親ビジネス・オブジェクトと子ビジネス・オブジェクトの間の関係、およびビジネス・オブジェクトのアプリケーション表現に関して、なんらかの前提事項を基に設計されています。既存のコネクターまたはデータ・ハンドラー向けのビジネス・オブジェクトを設計する場合は、このような仮定を把握し、それに基づいて設計を行う必要があります。
アプリケーション固有のビジネス・オブジェクトの構造については、まず次のことを考慮する必要があります。
単一または複数のアプリケーション・エンティティーを表現できるビジネス・オブジェクトの構造について詳しくは、"ビジネス・オブジェクトの構造の判別"を参照してください。
属性には、アプリケーション・エンティティーの個々のデータが保持されます。アプリケーション固有のビジネス・オブジェクトの属性を定義するときには、次の点に留意してください。
原則として、ビジネス・オブジェクトの構造を、対応するアプリケーション・エンティティー (データベース表や DTD など) の構造と同じになるように維持する必要があります。ビジネス・オブジェクトが大きい (多数の属性が含まれている) 場合は、ビジネス・オブジェクトを設計するビジネス・プロセスで使用される属性のみを定義してください。ただし、ビジネス・オブジェクトが小さい場合は、将来使用できるよう、すべての属性を定義してください。定義する属性の数は、ビジネス・オブジェクトのサイズとビジネス・オブジェクト間の関係の複雑さによって異なります。
ビジネス・オブジェクト内に属性として存在すべきアプリケーション・エンティティーを識別するだけでなく、ビジネス・プロセスを調べて追加の属性が必要かどうか判断することも必要とされます。ビジネス・プロセスの分析の一環として、ビジネス・オブジェクトの要件を特定します。ビジネス・プロセスを段階を追って分析していくことにより、ビジネス・オブジェクトがどのように処理され、必須属性がどのように使用されるかがわかります。ビジネス・プロセスおよび例外処理のバリエーションにより、ビジネス・オブジェクトの処理に必要な追加属性が特定されることがありますが、これらの追加属性は、アプリケーション内で検索または更新されるデータに必ずしも対応するとは限りません。
例えば、次のような属性が必要になる場合が考えられます。
アプリケーション固有のビジネス・オブジェクト定義の構造、およびビジネス・オブジェクト定義に含まれる属性のセットを定義し終えると、InterChange Server Express から受け取った要求の処理を可能にするにはビジネス・オブジェクトをどのように処理すべきかについての追加の情報が、コネクターまたはデータ・ハンドラーに必要とされるかどうか判断できるようになります。ビジネス・オブジェクト定義では、この追加情報をアプリケーション固有の情報に組み込むことができます。
コネクターおよびデータ・ハンドラーは、アプリケーション固有の情報に、ビジネス・オブジェクトの処理方法に関するアプリケーション依存の命令を提供します。ビジネス・オブジェクトとコネクターの関係を設計するときには、コネクターのアプリケーションやデータ・ソースとの対話を容易にするための情報が、ビジネス・オブジェクト定義に格納されているように設計してください。 このような情報は、メタデータと呼ばれ、各ビジネス・オブジェクトのアプリケーション固有の情報、ビジネス・オブジェクト属性、およびビジネス・オブジェクト動詞に指定できます。
アプリケーション固有の情報は、ビジネス・オブジェクト設計時に入力されるストリングで、実行時にコネクターまたはデータ・ハンドラーが読み取ります。コネクターまたはデータ・ハンドラーは、ビジネス・オブジェクト定義内のメタデータを使用してビジネス・オブジェクトのインスタンスを処理します。コネクターまたはデータ・ハンドラーは、サポートされているビジネス・オブジェクト定義に実行時にアクセスできるため、特定のビジネス・オブジェクトの処理方法を動的に決定できます。
ビジネス・オブジェクト設計時にアプリケーション固有の情報を使う場合、次のような利点と制限があります。
ビジネス・オブジェクト定義内のアプリケーション固有の情報には、表および列の名前、処理命令、コネクターが呼び出す関数の名前、またはアプリケーション内でのデータの処理方法に関するその他の情報を組み込むことができます。
各アプリケーション固有のビジネス・オブジェクトにはその処理に必要なすべての情報が格納されているため、コネクターのソース・コードを変更する必要なしに、コネクターは新しいビジネス・オブジェクトまたは変更したビジネス・オブジェクトを処理することができます。特定のビジネス・オブジェクトを処理するロジックがハードコーディングされていない 1 つのビジネス・オブジェクト・ハンドラーを使用して、汎用的な方法でコネクターを作成することができます。
関数呼び出しまたは SQL ステートメントは、コネクターが処理するビジネス・オブジェクトおよび動詞のために、アプリケーション・データベース内での必要な変更を実行します。
アプリケーションとそのプログラミング・インターフェースによっては、ビジネス・オブジェクト内のアプリケーション固有の情報によってコネクターがほぼ全面的に駆動されるように、そのコネクターおよびビジネス・オブジェクトを設計できる場合があります。その場合、コネクターがビジネス・オブジェクトをアプリケーション処理要求に変換するために必要とするビジネス・オブジェクト・ハンドラーは 1 つのみになります。
ただし、ビジネス・オブジェクトごとに完全に異なる処理ロジックを使わなければならない、アプリケーション・インターフェースの制約があるアプリケーションもあります。この場合、複数のビジネス・オブジェクト・ハンドラーを実装する必要があります。このようなアプリケーションの場合に可能なインプリメンテーション形態は、部分的にメタデータ主導型のインプリメンテーションか、完全にデータ主導型でないインプリメンテーションに限られます。
ビジネス・オブジェクトが格納するアプリケーション固有情報の量は、アプリケーションによって異なります。ただし、ほとんどのアプリケーション固有のビジネス・オブジェクトは、コネクターまたはデータ・ハンドラーによるビジネス・オブジェクト処理を容易にするなんらかの情報を格納するように設計できます。
アプリケーション固有の情報を定義するときには、名前と値のペアの構文を使用することをお勧めします。この構文では、プロパティーの名前と対応する値を等号 (=) で区切って指定します。
name1=value1;name2=value2
例えば、「表名」プロパティーは、名前と値のペアで定義されます。
TN=TableName
名前と値のペアを使うと、値をランダムな順序で指定できます。コネクターは、値を解釈する前に各パラメーターの名前を評価します。名前と値のペアはペアごとに区切り文字で区切ることをお勧めします。区切り文字は次のようになります。
表 7 に、属性のアプリケーション固有の情報に含めることの可能なパラメーターの例を示します。これらのパラメーターは、データベース表内のデータを表すビジネス・オブジェクトにのみ適用されます。
表 7. 属性のアプリケーション固有情報の名前と値のパラメーターの例
パラメーター | 説明 |
---|---|
TN=TableName | データベース表の名前です。 |
CN=col_name | この属性に対応するデータベース列の名前です。 |
FK=[..]fk_attributeName] | Foreign Key プロパティーの値によって親子関係が定義されます。 |
UID=AUTO | このパラメーターは、ビジネス・オブジェクトに対応する一意の ID を生成してその値をこの属性にロードするようコネクターに指示します。 |
CA=set_attr_name | Copy Attribute プロパティーは、1 つの属性の値を別の属性にコピーすることをコネクターに指示するために使用します。set_attr_name を現在の個別のビジネス・オブジェクト内にある別の属性の名前に設定すると、コネクターは、指定された属性の値を使ってこの属性の値を設定してから、Create 処理時にデータベースにビジネス・オブジェクトを追加します。 |
OB=[ASC|DESC] | Order By パラメーターに値が指定されていて、その属性が子ビジネス・オブジェクト内にある場合、コネクターは、検索照会の ORDER BY 文節にある属性の値に基づいて、子ビジネス・オブジェクトを昇順または降順のどちらで検索するかを決定します。 |
UNVL=value | コネクターが、値が null の属性を持つビジネス・オブジェクトを検索するときに、null を表すために使用する値を指定します。 |
1 つの属性のアプリケーション固有の情報を、上に例として挙げたパラメーターと組み合わせて使用することもできます。この例では、パラメーターを分離する区切り文字としてセミコロン (;) が使用されています。
TN=LineItems;CN=POid;FK=..PO_ID
この例のアプリケーション固有の情報は、表の名前と列の名前を指定し、現在の属性が子ビジネス・オブジェクトを親にリンクする外部キーであることを指定します。
アプリケーション固有の情報の内容は、複雑さによって大幅に変わります。以下にいくつかの例を紹介します。
ビジネス・オブジェクト定義にアプリケーション固有の情報が組み込まれていて、コネクターがそれを使用する設計になっている場合、コネクターは、ビジネス・オブジェクト定義からアプリケーション固有の情報の内容を抽出し、それを処理に使用することができます。
コネクターがアプリケーション固有の情報を処理する方法の例として、作成中のアプリケーションが表をベースとしていて、顧客情報を格納するためのアプリケーション表 CURRENTCUST を扱う場合を考えます。この表には、CSTName および CSTCity という 2 つの列があります。
ビジネス・オブジェクトのヘッダーの AppSpecificInfo プロパティーには、表名を格納できます。各属性の AppSpecificInfo プロパティーには列名を格納できます。さらに、このアプリケーション向けのコネクターでは、データベースとの対話に SQL ステートメントを使用するため、SQL 動詞とキーワードが保持されるように動詞のアプリケーション固有の情報を設計できます。図 18 に、この Customer ビジネス・オブジェクト定義の概念図を示します。
図 18. ビジネス・オブジェクト定義におけるアプリケーション固有の情報
メタデータ主導型コネクターは、InterChange Server Express からこのビジネス・オブジェクトのインスタンスを受け取ると、ビジネス・オブジェクト定義にあるアプリケーション固有の情報のプロパティーから表名および列名を抽出し、続いてビジネス・オブジェクトのインスタンスから属性および動詞の値を抽出します。動詞のアプリケーション固有の情報内の表名、列名、属性値、および SQL キーワードを使用して、コネクターは SQL ステートメントを作成することができます。
このタイプの処理の例を 図 19 に示します。コネクターは、ビジネス・オブジェクト定義から動詞処理命令、表名、および列名を抽出します。続いて、ビジネス・オブジェクト・インスタンスから属性値を取得します。この情報を使用して、コネクターは、CURRENTCUST 表を新しい情報で更新するための SQL INSERT ステートメントを作成します。
図 19. アプリケーション固有の情報を使用して Create 処理のための SQL ステートメントを作成する方法
既に述べたように、ビジネス・オブジェクト定義には、ビジネス・オブジェクト全体とその属性および動詞についての AppSpecificInfo テキストを組み込むことができます。ここからは、ビジネス・オブジェクトのこれらコンポーネントにおけるアプリケーション固有の情報の使用について詳しく説明します。
重要 |
---|
アプリケーション固有の情報の長さは、1000 文字までという制約があります。 |
図 5 では、属性レベルの AppSpecificInfo プロパティーを使用して Invoice サブフォームの名前と属性内の対応フィールドの名前を格納しています。この例では、情報の指定には名前と値のペアを使用しています。
コネクターのメタデータ主導型動作が最大になるようにビジネス・オブジェクトを設計する場合は、ビジネス・オブジェクト定義へのアプリケーション固有情報の格納に関して、次の一般的な推奨事項に従ってください。
AppSpecificInfo プロパティーを慎重に使用すれば、コネクターはさまざまなビジネス・オブジェクトを同じ方法で処理することができます。アプリケーション全体でデータ処理の取扱方法について整合性が取れていて、コネクターが実行するすべてのデータ処理についてタスクが一致している場合、ビジネス・オブジェクトは、完全にメタデータ主導型コネクターを使えるように設計できます。
既存のコネクターまたはデータ・ハンドラー用にアプリケーション固有のビジネス・オブジェクトを設計する際には、まずそのアダプター・ユーザーズ・ガイドを参照して、アプリケーション固有の情報の指定とビジネス・オブジェクト・ハンドラーの使用に関する要件を確認してください。既存のコネクターまたはデータ・ハンドラー用にビジネス・オブジェクトを設計する際には、以下の点を念頭に置いてください。
重要 |
---|
サンプルのビジネス・オブジェクトは、IBM ではサポートされていませんが、ビジネス・オブジェクトの設計の開始点としては大変役立ちます。 |
アプリケーション固有のビジネス・オブジェクトを設計する際には、データ・ソース内のエンティティーのモデル化こそがその基本的な役割であることを念頭に置いてください。また、対応するコネクターまたはデータ・ハンドラーでそのオブジェクトの処理がどのように扱われるのか、そのオブジェクトが参加するビジネス・プロセスの要件がどのようなものであるのかを明確にすることも重要です。