ビジネス・オブジェクト定義が XML データ・ハンドラーの要件に適合することを確認するには、このセクションのガイドラインを使用します。ガイドラインは次から構成されます。
ビジネス・オブジェクト定義を正しく作成することにより、データ・ハンドラーがビジネス・オブジェクトと XML 文書との相互の変換を正しく行うことができます。XML データ・ハンドラーのビジネス・オブジェクトの作成方法の詳細については、DTD からのビジネス・オブジェクト定義の作成を参照してください。
DTD またはスキーマ文書を表すには、少なくとも以下の 2 つのビジネス・オブジェクト 定義が必要です。
この属性のアプリケーション固有情報には、type=pi タグの設定が必要です。
この属性には、タイプとして単一カーディナリティーのビジネス・オブジェクトを指定し、そのタイプが DTD またはスキーマ文書の root エレメントのビジネス・オブジェクト 定義である必要があります。 XML ODA は、この root エレメントの名前を Root ODA 構成プロパティーから取得します。 アプリケーション固有情報に、elem_name タグを使用してこのエレメントの名前がリストされている必要があります。
DTD またはスキーマ文書のビジネス・オブジェクト定義を使用して XML データ・ハンドラーにより処理されるビジネス・オブジェクトは、次の追加規則に準拠していることが必要です。
本書では、DTD およびスキーマ文書のビジネス・オブジェクト定義の構造について次の情報を提供します。
データ・モデル | 詳細 |
---|---|
文書タイプ定義 (DTD) | DTD のビジネス・オブジェクト構造 |
スキーマ文書 | スキーマ文書のビジネス・オブジェクト構造 |
ビジネス・オブジェクト定義により属性が定義されます。各属性には、その属性に関する情報を提供する各種のプロパティーがあります。このセクションでは、XML データ・ハンドラーがこれらのプロパティーの一部をどのように解釈するかについて説明するとともに、ビジネス・オブジェクト定義を変更するためにプロパティーを設定する方法について説明します。
各ビジネス・オブジェクト属性には、固有の名前を付ける必要があります。XML エレメントまたは XML 属性の名前は、常に elem_name または attr_name タグ内で指定されます。この場合、属性のアプリケーション固有情報 の elem_name (または attr_name) タグに指定された XML エレメント (または属性) の名前に特殊文字が含まれます。ただし、(これらの特殊文字を使用できない) ビジネス・ オブジェクト属性の名前では、特殊文字は省略されます。
各ビジネス・オブジェクト属性は、次のように、整数、ストリング、このオブジェクトに含まれる子ビジネス・オブジェクトのタイプなど、1 つのタイプを持っていることが必要です。
各ビジネス・オブジェクトには、1 つ以上の基本キー属性が必要です。基本キー属性は、属性に対する Key プロパティーを true に設定することにより指定されます。Foreign Key プロパティーの設定はオプショナルで、XML 文書の構造に依存します。このセクションでは、次に示す Key 属性および Foreign Key 属性のプロパティーに関連する情報について説明します。
以前のバージョンの XML ビジネス・オブジェクト定義生成ツール (XMLBorgen、Edifecs SpecBuilder、および XML ODA など) では、生成ツールが、ObjectEventId 属性を親 XML ビジネス・オブジェクトのキーとして指定していました。しかし、今回のリリースより、Business Object Designer Express では ObjectEventId 属性がキーとして指定されているビジネス・オブジェクト定義を保管できなくなりました。
この制限により、現行バージョンの XML ODA は次に示すアクションを行ないます。
XML ODA が生成する親ビジネス・オブジェクト定義にキーを指定するためには、ビジネス・オブジェクト定義を Business Object Designer Express に送り、そのビジネス・オブジェクト定義を分析して、キーとして指定する適切な属性を判別する必要があります。ビジネス・オブジェクト定義のキー属性の変更は、Business Object Designer Express でそのビジネス・オブジェクト定義を保管する前 に行なう必要があります。
本書では次の情報を提供すると共に、キーと「必須性」の関係についても説明します。
データ・モデル | 詳細 |
---|---|
文書タイプ定義 (DTD) | DTD のビジネス・オブジェクト属性プロパティー |
スキーマ文書 | スキーマ文書のビジネス・オブジェクト属性プロパティー |
このプロパティーが単一カーディナリティーの子ビジネス・オブジェクトを含む属性に対して指定されると、XML データ・ハンドラーは親ビジネス・オブジェクトにこの属性の子ビジネス・オブジェクトが含まれていることを要求します。Cardinality、Key、および Foreign Key 属性プロパティーは、属性の Required プロパティーの設定に影響を与えることがあります。
本書では、必須かどうかについて次の情報を提供します。
データ・モデル | 詳細 |
---|---|
文書タイプ定義 (DTD) | DTD のビジネス・オブジェクト属性プロパティー |
スキーマ文書 | スキーマ文書のビジネス・オブジェクト属性プロパティー |
Cardinality プロパティーは、ビジネス・オブジェクト定義をタイプとしている属性の場合に、許容される子ビジネス・オブジェクトの数を示します。このプロパティーの設定は、XML 文書およびそのエレメントの構造に依存します。また、この設定は、属性が必須であることを必要とするかどうか (Required プロパティーが true に設定されているかどうか) にも影響します。
本書では、カーディナリティーと「必須性」の関係について次の情報を提供します。
データ・モデル | 詳細 |
---|---|
文書タイプ定義 (DTD) | DTD のビジネス・オブジェクト属性プロパティー |
スキーマ文書 |
|
ビジネス・オブジェクト属性には 1 つの値があり、この値のタイプは、その属性の Type プロパティーと一致しています。さらに、属性は、次の 2 つの特別な値のいずれか 1 つを持つことができます。
XML データ・ハンドラーは、統合ブローカーからビジネス・オブジェクトを受け取ると、CxIgnore の値を持つ属性をすべて 無視します。これらの属性はデータ・ハンドラーに不可視の状態になります。したがって、データ・ハンドラーは、対応する XML エレメントを生成しません。つまり、データ・ハンドラーはこの属性に対して XML タグを作成しません (空のタグも作成しません)。XML データ・ハンドラーは、ビジネス・オブジェクト属性に対応する XML タグを持たない XML 入力を受け取ると、その属性に CxIgnore の値を割り当てます。
XML データ・ハンドラーは、統合ブローカーからビジネス・オブジェクトを受け取ると、CxBlank 属性値を、その属性の Type プロパティーに基づいて処理します。
XML データ・ハンドラーは、空のタグを持つ XML 入力を受け取ると、対応するビジネス・オブジェクト属性に CxBlank の値を割り当てます。
ビジネス・オブジェクト定義内のアプリケーション固有情報により、データ・ハンドラーにビジネス・オブジェクト定義を XML 文書に変換する指示が与えられます。アプリケーション固有情報により、データ・ハンドラーがビジネス・オブジェクトを正しく処理できるようになります。したがって、XML データ・ハンドラーに関して新しいビジネス・オブジェクトを作成するかまたは既存のビジネス・オブジェクトを変更する場合は、ビジネス・オブジェクト定義内のアプリケーション固有情報がデータ・ハンドラーが予期する構文規則に一致することを確認します。XML データ・ハンドラーは次の種類のアプリケーション固有情報を使用することができます。
本書では、アプリケーション固有情報について次の情報を提供します。
データ・モデル | 詳細 |
---|---|
文書タイプ定義 (DTD) | DTD の XML コンポーネントのアプリケーション固有情報 |
スキーマ文書 | スキーマ文書内の XML コンポーネントのアプリケーション固有情報 |
ビジネス・オブジェクトを XML 文書に変換する場合、XML データ・ハンドラーは動詞に関する XML を生成せず、また XML 文書をビジネス・オブジェクトに変換する際に動詞の設定も行いません。しかし、動詞の情報は次のいずれかの方法で保持されます。
次にビジネス・インテグレーション・システムの内容を作成して、動詞をビジネス・オブジェクト属性にコピーできます。その後データ・ハンドラーが動詞を XML エレメントに変換し、これにより動詞が XML 文書に保持されます。XML 文書が戻されると、ビジネス・インテグレーション・システムがビジネス・オブジェクト属性の値に従って動詞を設定できます。