ビジネス・オブジェクトのスキーマ
ビジネス・オブジェクトには要素があります。要素は、メンテナンス・オブジェクト表の1つにあるフィールドおよび列の論理ビューです。ビジネス・オブジェクトの構造はXMLスキーマを使用して定義します。スキーマの主な目的は、ビジネス・オブジェクトに含まれているメンテナンス・オブジェクトからすべての要素を識別し、それらを対応するメンテナンス・オブジェクトのフィールドにマップすることです。ビジネス・オブジェクト・スキーマの各要素は、メンテナンス・オブジェクトのいずれかの場所に格納されている必要があります。ビジネス・オブジェクトでは導出された要素の定義は行いません。
主表または言語表(管理オブジェクトの場合)の要素を定義する場合、スキーマの物理表の名前を定義する必要はありません。この情報はシステムによって推測されます。次に、スキーマのスニペットを示します。
<schema>
<migrationPlan mapField="MIGR_PLAN_CD" suppress="true" isPrimeKey="true"/>
<bo mapField="BUS_OBJ_CD" fkRef="F1-BUSOB"/>
<customizationOwner mapField="OWNER_FLG" suppress="input"/>
<version mapField="VERSION" suppress="true"/>
<description mapField="DESCR"/>
<longDescription mapField="DESCRLONG"/>
…多くのメンテナンス・オブジェクトには子表のコレクション(パーソンの名前のコレクションやアカウントのパーソンのコレクションなど)があります。要件に応じて、ビジネス・オブジェクトでは、ユーザーがグリッドの情報を保守するような完全なコレクションを定義できます。ただし、フラット化レコードを単一要素として処理できるように、スキーマでも子表のフラット化レコードがサポートされます。次に、それぞれの例を示します。
子表の例。これは、移行計画ビジネス・オブジェクトの指示コレクションのスニペットです。リスト属性によって子表が定義され、子表内のすべての要素がその表の該当する列にマップされていることが分かります。
<migrationPlanInstruction type="list" mapChild="F1_MIGR_PLAN_INSTR">
<migrationPlan mapField="MIGR_PLAN_CD" suppress="true"/>
<sequence mapField="PLAN_INSTR_SEQ" suppress="true"/>
<instructionSequence mapField="INSTR_SEQ"/>
<instructionType mapField="INSTR_TYPE_FLG"/>
<parentInstructionSequence mapField="PARENT_INSTR_SEQ"/>
<businessObject mapField="BUS_OBJ_CD" fkRef="F1-BOMO"/>
...単純なフラット・フィールドの例。ステータス事由のビジネス・オブジェクトには「使用」とよばれる要素が含まれており、これによってタイプF1–SRUSGの事前定義済特性にマップにマップされます。行では、どの子表をフラットにするかと、行を一意に識別する子内の行の属性が定義されます。
<usage mdField="STATUS_RSN_USAGE" mapField="CHAR_VAL">
<row mapChild="F1_BUS_OBJ_STATUS_RSN_CHAR">
<CHAR_TYPE_CD is="F1-SRUSG"/>
<SEQ_NUM is="1"/>
</row>
</usage>フラット行の例。アカウントのビジネス・オブジェクトには、パーソン・コレクションの単一行が含まれており、請求対象顧客の主要顧客のみが定義されます。「accountPerson」属性はその行(パーソンID)の1つのフィールドを定義し、そこに行情報のフラット化基準が含まれます。さらに、同じ行(「accountRelType」)の2番目のフィールドが定義されます。フラット化基準を繰り返すかわりに、「rowRef」属性によってフラット化を含む要素が識別されます。
<accountPerson mapField="PER_ID">
<row mapChild="CI_ACCT_PER">
<MAIN_CUST_SW is="true"/>
<FIN_RESP_SW default="true"/>
</row>
</accountPerson>
<accountRelType mapField="ACCT_REL_TYPE_CD" rowRef="accountPerson" dataType="string"/> フラット・リストの例。税金請求タイプのビジネス・オブジェクトには、有効な請求完了のアルゴリズムのリストが含まれています。シーケンスとアルゴリズムをリストに示します。リスト要素では子表が識別され、「rowFilter」では共通のリストに関する情報が識別されます。
<taxBillCompletion type="list" mapChild="C1_TAX_BILL_TYPE_ALG">
<rowFilter suppress="true" private="true">
<TAX_BILL_TYPE_SEVT_FLG is="C1BC"/>
</rowFilter>
<sequence mapField="SEQ_NUM"/>
<algorithm mapField="ALG_CD" fkRef="F1-ALG"/>
</taxBillCompletion> さらに、多くのメンテナンス・オブジェクトではエンティティ内のXML構造フィールドがサポートされます。これらのフィールドのデータ型はCLOBまたはXMLです。1つ以上のビジネス・オブジェクト要素をメンテナンス・オブジェクトのXML構造フィールドにマップできます。これらの要素は、ビジネス・ルールに何が適合するかに応じて、ビジネス・オブジェクト・スキーマの様々な論理的な場所に定義できます。メンテナンス・オブジェクトを更新する場合、システムではXML構造にマップして1つの列にそれを格納するすべての要素を含むXMLドキュメントのタイプが作成されます。次に、XML列にマップされる要素の例を示します。
<filePath mdField="F1_FILE_PATH" mapXML="MST_CONFIG_DATA" required="true"/>
<characterEncoding mdField="F1_CHAR_ENCODING" mapXML="MST_CONFIG_DATA"/> 一部のビジネス・オブジェクトには子表がある場合があり、XML構造フィールドにデータを格納できます。スキーマ言語では、ユーザーのスキーマにもあるフィールドからの要素の定義がサポートされています。
メンテナンス・オブジェクトの適切な表/フィールドの場所に対する物理的な要素のマッピングに関する情報が含まれる他に、スキーマでは、次を含む基本的な検証とデータ操作ルールを定義できる追加の構文がサポートされます。
-
レコードの主キーまたはリスト内の行の主キーの特定。
-
レコードの追加または変更時に必要な要素の識別。
-
「追加」に対して何もデータが入力されない場合のデフォルト値。
-
参照値の要素の場合、参照を指定して要素の値が有効な参照値であるかを検証できます。
-
要素が別の表に対する外部キーである場合、データの検証に外部キー参照を指定できます。
システムではスキーマ定義に基づいてデータの有効性がチェックされ、この検証をチェックするための特殊なアルゴリズムは必要ありません。
さらに、スキーマ言語にはユーザー・インタフェースのレコードのビューを自動レンダリングするために使用するいくつかの属性(抑制属性など)が含まれています。詳細は、「ビジネス・オブジェクトによるユーザー・インタフェースの定義」を参照してください。
ビジネス・オブジェクトのスキーマには、メンテナンス・オブジェクトで定義されているフィールドと表のサブセットを含めることができます。これには、次の2つの理由があります。
-
フィールドまたは表は、ビジネス・オブジェクトが管理するレコードのタイプに適用できない場合があります。たとえば、ガスに固有のフィールドは、電気メーターに固有の「設備」ビジネス・オブジェクトに含まれていません。
-
情報はビジネス・オブジェクト経由で保守されるのではなく、個別に保守されます。たとえば、多くのビジネス・オブジェクトベースのメンテナンス・オブジェクトにはログ表が含まれています。ログ表のレコードは、ビジネス・オブジェクトから個別に表示および保守されるため、通常はビジネス・オブジェクトに含まれていません。