複合ドキュメント
FileNet® P8 複合ドキュメントとは、階層構造で編成したコンポーネント・ドキュメントのグループであり、これを統合して単一のドキュメントとして扱うことができます。階層の最上位のルート・ドキュメントは親コンポーネントと呼ばれます。このコンポーネントは、0 個以上の、子コンポーネントと呼ばれるサブコンポーネントを持つことができます。子コンポーネント自体も別の複合ドキュメントの親コンポーネントになることができます。複合ドキュメントは、子コンポーネントを共有することもできます。
Content Engine の Java™ API および .NET API は、複合ドキュメントの機能を、ComponentRelationship クラスおよび Document クラスのプロパティーを介して開示しています。ComponentRelationship オブジェクトには、複合ドキュメントを構成する手段が用意されています。各 ComponentRelationship オブジェクトは、親コンポーネント (ParentComponent プロパティー) として指定したドキュメントと、子コンポーネント (ChildComponent プロパティーまたは URIValue プロパティー) として指定した別のドキュメントとの間の関係を確立します。複数の ComponentRelationship オブジェクトを使用することにより、さまざまなドキュメントの構造を構築することができます。
ComponentRelationship クラスには、次の操作をサポートするプロパティーが含まれています。
- 子と親の関係のタイプを指定する (以下の「コンポーネント間の関係タイプ」を参照)。
- 既存の親ドキュメント・バージョンに関する子コンポーネント関係構造のすべてまたは一部を次のバージョンの親にコピーする必要があるかどうか、またはまったくコピーする必要がないかを指定する。詳細とコード例については、親のバージョン管理を参照してください。
- バインドの候補を、子ドキュメントの最新バージョン (メジャーまたはマイナー) にするか、最新のメジャー・バージョンのみにするかを指定する (VersionBindType プロパティーを使用するコード例については、動的なコンポーネント関係の生成を参照)。
- 動的なラベル・ベースのバインド・メカニズムをサポートするラベルを指定する。詳細については、ラベル・ベースのバインドを参照してください。
- 子ドキュメントのソート順序を指定する (ComponentSortOrder プロパティーの使用例については、「静的なコンポーネント関係の作成」を参照)。ソート順序を指定すると、例えば、書籍の章を正しい順序で構成できます。
- 子コンポーネント・ドキュメントのバージョン・シリーズを取得する (ChildVersionSeries プロパティー)。
- 親ドキュメントの削除時に子コンポーネントを削除する、あるいは親ドキュメントの削除を禁止する、または、親が存在している場合の子ドキュメントの削除を禁止する、または親ドキュメントと子ドキュメントの両方の削除を禁止する。詳細とコード例については、コンポーネントの削除を参照してください。
Document クラスには、次の操作をサポートする複合ドキュメント関連のプロパティーが含まれています。
- 親ドキュメントにバインドされた子の Document オブジェクトを特定する (ChildDocuments プロパティー)。
- 子コンポーネントのすべての親ドキュメントを特定する (ParentDocuments プロパティー)。
- ドキュメントを親コンポーネント・ドキュメントとして参照する ComponentRelationship オブジェクトをすべて取得する (ChildRelationships プロパティー)。
- ドキュメントを子コンポーネント・ドキュメントとして参照する ComponentRelationship オブジェクトをすべて取得する (ParentRelationships プロパティー)。
- ドキュメントを複合ドキュメントの親として分類する (CompoundDocumentState プロパティー)。ComponentRelationship オブジェクトがドキュメントを親コンポーネントとして参照するためには、そのドキュメントを複合ドキュメントとして分類する必要があります。
さらに、アドオン Document プロパティーである ComponentBindingLabel は、ComponentRelationship オブジェクトの LabelBindValue プロパティー値と照合する値を指定します。詳細については、ラベル・ベースのバインドを参照してください。
コンポーネント間の関係タイプ
API には、STATIC、DYNAMIC_CR、および DYNAMIC_LABEL_CR の 3 つのドキュメントをバインドするメカニズムが組み込まれています。これらのメカニズムは、(ComponentRelationshipType プロパティーを使用して) ComponentRelationship オブジェクトに指定できるコンポーネント間の関係タイプです。したがって、各コンポーネント間の関係には異なるタイプを指定できます。複合ドキュメント全体で、1 つのタイプにする必要はありません。ドキュメントをバインドすると、自動的に子コンポーネント・ドキュメントのバインドされたバージョン (ChildComponent プロパティーで指定) が親ドキュメントの子ドキュメント・コレクションに追加されます。
- STATIC 関係の場合、明示的に指定された子ドキュメント・バージョンが常にバインドされます。
- DYNAMIC_CR 関係の場合、有効なバージョン・バインド・ルール (VersionBindType プロパティーで指定) に応じて、子ドキュメントの最新のバージョンまたは最新のメジャー・バージョンがバインドされます。
- DYNAMIC_LABEL_CR 関係の場合、バージョン・バインド・ルールとラベル値のマッチングで、バインドされる子ドキュメント・バージョンが決定されます (ComponentRelationship オブジェクトの LabelBindValue プロパティーの値と Document オブジェクトの ComponentBindingLabel プロパティーの値で決定)。
コンポーネント関係には、URICR という 4 番目のタイプがあります。このタイプは、親 Document オブジェクトと子 URI ドキュメント (URIValue プロパティーで指定) との間にコンポーネント関係が存在できるようにします。厳密には、この場合にはドキュメントはバインドできません。子ドキュメントが Document オブジェクトではなく、親の子ドキュメント・コレクションに格納できないためです。
ラベル・ベースのバインド
コンポーネント関係は、動的なラベル・ベースのバインド・メカニズム (DYNAMIC_LABEL_CR) をサポートしています。この種のコンポーネント関係では、子コンポーネントの特定のバージョンへのバインドは、バージョン・バインド・ルール (LATEST_VERSION または LATEST_MAJOR_VERSION) とラベル・バインド値 (LabelBindValue プロパティーの値と照合する値を指定する子ドキュメントの ComponentBindingLabel プロパティー) に基づいて行われます。
Document クラスの ComponentBindingLabel プロパティーは、Content Engine の Document 基本クラスのプロパティーではありません。 このプロパティーは、オブジェクト・ストアの作成時にインストールされる Base Content Engine Extensions アドオンの一部として Document クラスに追加されます。したがって、Content Engine の Java API では、このプロパティーに関するアクセス機能メソッド (set_ComponentBindingLabel および get_ComponentBindingLabel) が開示されておらず、Content Engine の .NET API では、このプロパティーが開示されていません。子ドキュメントの Properties コレクション・オブジェクトのメソッドを使用して、このプロパティーの値を設定および取得してください。
循環参照
複合ドキュメント定義のトップダウン方向では、循環コンポーネントの関係は排除されません。例えば、ある ComponentRelationship オブジェクトがドキュメント X を親、ドキュメント Y を子として指定し、別の ComponentRelationship オブジェクトがその逆を指定することもできます。X は Y の親でありかつ子でもある (逆も同様) ことになります。または、X を Y の親、Y を別のドキュメント Z の親、Z を X の親として指定できます。参照の循環チェーンに存在する複合ドキュメントは、これを再帰的に処理する試みが決して終了しなくても、複合ドキュメントと見なされます。
ユース・ケース例
例えば、書籍は、各子コンポーネントに章のテキストを含む複合ドキュメントとして実装することもできます。書籍全体を表すルートの親コンポーネントには、テキストは関連付けられません。各章に対応する子コンポーネントは、それ自体が複合ドキュメントである場合があり、(複合ドキュメントの統合中に) 章見出しに含めるためのロゴを子サブコンポーネントとして持つこともあります。
例えば、書籍の第 1 章と第 2 章のコンポーネントがロゴの子コンポーネントを共有することもできます。すなわち、ある ComponentRelationship オブジェクトでは、第 1 章のドキュメントを親コンポーネントとして指定し (ParentComponent プロパティーで指定)、ロゴ・ドキュメントを子コンポーネントとして指定する (ChildComponent プロパティーまたは URIValue プロパティーで指定) ということです。さらに、別の ComponentRelationship オブジェクトでは、第 2 章のドキュメントを親、同じロゴ・ドキュメントを子として指定します。したがって、第 1 章ドキュメントは複合ドキュメントの親コンポーネントであり、第 2 章ドキュメントも同様です。この 2 つの複合ドキュメントはロゴ・ドキュメントを子コンポーネントとして共有します。各章から子コンポーネントを切り離して管理することにより、それぞれの章見出しにロゴを取り込むタスクが簡潔になります。
別の例として、法律条項が各州ごとに異なる生命保険証書について考えてみましょう。このような証書の主要な複合ドキュメントは、次の 4 つのコンポーネントから構成することもできます。
- ルートの親コンポーネント - テキストは関連付けられておらず、証書全体を表す。
- 第 1 の子コンポーネント - 法律関係の条項以前のすべてのテキストを含む。
- 第 2 の子コンポーネント - 法律関係の条項を表す別の複合ドキュメントの親コンポーネント。
- 第 3 の子コンポーネント - 法律関係の条項以降のすべてのテキストを含む。
このように複合ドキュメントを構成すると、テキストを解析して法律関係の条項を検索する必要がなくなります。特定の州向けに保険証書を統合する作業は、第 2 の子コンポーネントを適切な法律関係のテキストで置き換えることと、3 つの子コンポーネントをマージすることから成ります。
この例で、基本複合ドキュメントの第 2 の子コンポーネントは、法律関係のテキストを表す複合ドキュメントに対する親となっています。この親コンポーネントに対して、DYNAMIC_LABEL_CR 関係をそれぞれに指定した 50 の子ドキュメントを設定することもできます。各ドキュメントには、特定の州向けのテキストを格納し、アリゾナ州なら「AZ」のように、ラベル値を設定します。例えば、アリゾナ州向けの保険証書を生成するには、コンポーネント関係オブジェクトのラベル値を「AZ」と設定します。設定すると、親ドキュメントの子ドキュメント・コレクションに、予期したとおりのドキュメントであるアリゾナ州向けドキュメントが表示されます。したがって、正しいテキストで置き換える作業が、ラベル値の設定と、子ドキュメント・コレクションに対する反復処理により実現されます。