![]() ![]() ![]() ![]() ![]() ![]() | ![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
第1章
この章では、CM (コンテンツ管理)サブシステムの概要について紹介し、次のトピックについて説明します。
CMサブシステムでは、ドキュメントのリポジトリが提供され、ドキュメントの作成およびバージョニング、ドキュメントのセキュリティの管理、リポジトリの検索などが行えます。CMサブシステムには、スタイルおよびレイアウトの管理や、ドキュメントの公開および有効期限設定といったWeb CM機能が備わっています。
CM APIおよびCMS管理コンソールでは、Webコンテンツの管理に役立つCMサブシステムへのインタフェースが提供されています。他のフロントエンドアプリケーションでは、汎用なドキュメント管理システムとして、CMサブシステムを使用できます。たとえば、WebDAVアプリケーションおよびCMサブシステムを使用して、CADファイルや法律関係のドキュメントを管理することができます。
「コンテンツ」とはどのようなものでしょうか?コンテンツは、exteNd Directorアプリケーションのユーザによって表示またはダウンロードされる情報として定義されます。CMサブシステムにより管理されるコンテンツは、エンドユーザがexteNd Directorアプリケーションにアクセスする際に、ダイナミックに取得され、オンラインで表示したり、ダウンロードしたりできるようになります。
CMサブシステムには、デジタル化できる任意のタイプのコンテンツを保存できます。保存できる内容は、次のとおりです。
コンテンツがサポートされている、次のようなドキュメントも保存できます。
希望にあわせて、オンラインアプリケーションに適切な形式でコンテンツを保存できます。ドキュメントは、そのとおり表示されるような完全な項目である必要はありません。ドキュメントは、他のドキュメントと組み合わせて表示するデータであったり、データを取得できるコードリソースであったりします。たとえば、ドキュメントのコンテンツには、URL、URLのセット、SQLステートメント、段落、またはイメージを使用できます。
CMサブシステムの中心は、「ドキュメント」です。各ドキュメントは、データの定義または記述、つまりデータに関するデータである「メタデータ」のセットにより記述されます。CMサブシステムでは、ドキュメントは、コンテンツを維持するために必要なすべての情報によって構成されています。この情報には、ドキュメントのメタデータ、コンテンツ、バージョン、およびカテゴリ、表示、特徴、リンクされたドキュメント、アクセス制御などに対するすべての仕様が含まれます。
「チェックアウト/チェックイン」システムでは、ドキュメントを変更する際にドキュメントを保護し、「バージョニング」を使用して、コンテンツの変更履歴を維持できます。
ドキュメントを「発行」すると、特定のバージョンのドキュメントのコンテンツを選択して、パブリックにできます。バージョンを発行すると、一定のライフタイムを定義できます。このライフタイム後に、バージョンは「期限が切れ」、アーカイブ、削除できるようになります。
CMサブシステムで管理されるコンテンツのタイプと、Portalサブシステムで管理される「ページ」を区別することが重要です。ページは、ユーザがサイトを移動する際に役立つGUI (グラフィックユーザインタフェース)を定義し、アプリケーションの構造を構成します。ページには、exteNd Directorポータルアプリケーションの構成要素である「ポートレット」が含まれます。このポートレット内で、アプリケーション開発者はコードを作成して、ルールおよびリアルタイムなユーザの操作に応じて、CMサブシステムで管理されるコンテンツが検索、取得できるようにします。一般的に、ページはほとんど変化しませんが、コンテンツはよりダイナミックです。
CMサブシステムでは、コンテンツ構造、表示スタイル、バージョニング、カテゴリ、およびセキュリティを管理できるため、コンテンツを容易に取得し、アプリケーションのエンドユーザに示された情報の整合性を保持できます。Portalサブシステムでは、このコンテンツが示されているインタフェースおよびアーキテクチャを含む、実際のアプリケーションが管理されます。
ページおよびPortalサブシステムの詳細については、『ポータルガイド』のポータルの概念に関する節を参照してください。
CMサブシステムインフラストラクチャは、コンテンツを整理、表示、管理、および保護するための条件を確立します。「ドキュメント」という、コンテンツの基本単位をサポートする目的で設計されています。
インフラストラクチャには、次の2つのレベルがあります。物理レベルと論理レベルです。ドキュメントを作成する前に、物理インフラストラクチャを設定する必要があります。オプションとして、いつでも論理的インフラストラクチャを定義することもできます。
物理インフラストラクチャでは、物理メモリ内のドキュメント用の保存領域が整理されます。このインフラストラクチャは、次のコンポーネントで構成されています。
コンポーネント |
説明 |
---|---|
|
ルートフォルダ |
|
フォルダ |
|
ドキュメント |
フォルダとドキュメントには、次のような階層関係があります。
トップレベルのコンテナは、「ルートフォルダ」であり、1つまたは複数のフォルダを含むことができます。本質的に、ルートフォルダは、ペアレントを持たない特殊なタイプのフォルダです。一方、「フォルダ」には、1つまたは複数の「ドキュメント」や他のフォルダを含めることができます。各ドキュメントは、1つ(1つのみ)のフォルダに保存されます。
論理的インフラストラクチャではドキュメントが論理グループへと整理され、コンテンツのユーザビューを提供する際に使用できます。これには複数の要素があります。
ドキュメントタイプ、フィールド、および表示スタイルでは、ドキュメントの構造およびレイアウトを定義します(コンテンツの構造およびレイアウトの定義の説明を参照)。タクソノミおよびカテゴリでは、ドキュメントを分類して、検索および取得できるようにします(コンテンツの分類の説明を参照)。
ドキュメントを作成する前に、コンテンツの構造を定義する必要があります。ドキュメントを発行する前に、コンテンツの外観を定義して、Webサイトのユーザに情報がどのように表示されるか決定する必要があります。一般的に、これらのタスクは、コンテンツ管理者が前の論理的インフラストラクチャで説明したフィールド、ドキュメントタイプ、表示スタイル、フォルダ、およびカテゴリを開発することによって、管理しています。
コンテンツ開発者は、次の手順に従って、ドキュメントタイプおよび表示スタイルを作成したドキュメントに関連付けます。
ドキュメントタイプに基づいて作成するすべてのドキュメントには、ドキュメントタイプの表示スタイルで定義したコンテンツ構造およびスタイルが含まれます。
コンテンツ管理者は、任意の数のドキュメントタイプを作成できます。このドキュメントタイプは、ドキュメントの構造を示す情報のフィールドによって構成されます。
CMサブシステムでは、コンテンツ管理者がアクセスして、修正できるデフォルトのドキュメントタイプが提供されています。デフォルトのドキュメントタイプには、CM APIではDefaultという名前が、CMS管理コンソールでは_PmcSystemDefaultTypeという名前が付けられています。これらのドキュメントタイプは、コンテンツに対する企業標準を徹底したり、カスタムドキュメントタイプを使用せずにコンテンツを作成したりする際に使用できます。
CMサブシステムには、デフォルトの表示スタイルが備わっており、カスタム表示スタイルで上書きしない限り、すべてのドキュメントタイプに適用されます。
コンテンツ管理者は、カスタム表示スタイルを定義できます。このカスタム表示スタイルでは、外部エディタで開発された後、CMS管理コンソールにアップロードされた1つまたは複数のXSLスタイルシートが使用されています。各XSLスタイルシートでは、Microsoft Internet Explorer、Netscape Navigatorなどの特定のユーザエージェントに対して、コンテンツの表示方法が指定されます。
表示スタイルを適切に指定すると、CMサブシステムにより、リアルタイムで稼動しているユーザエージェントに希望のスタイルが自動的に適合されます。
コンテンツは、分類しなくても作成できますが、exteNd Directorアプリケーションで情報のカテゴリを選択できる場合、コンテンツ管理者がカテゴリを作成して、ドキュメントを論理的にグループ化することをお勧めします。その結果、ユーザがWebサイトを操作する際に指定したドキュメントに、ポートレットがさらに簡単にアクセスできます。
たとえば、exteNd Directorアプリケーション開発者が、特定のドキュメントにリンクするURLのリストを表示するようなポートレットを作成するとします。ドキュメントをカテゴリ別に分類すると、URLで渡されるcategoryというパラメータを参照することによって、ポートレットで特定のカテゴリのドキュメントすべてにリンクできます。
カテゴリとドキュメントには、次のような階層関係があります。
トップレベルのコンテナは、「ルートカテゴリ」であり、1つまたは複数のカテゴリを含むことができます。一方、「カテゴリ」には、1つまたは複数の「ドキュメント」や他のカテゴリを含めることができます。単一のドキュメントを任意の数のカテゴリに関連付けたり、まったく関連付けないこともできます。
CMサブシステムでは、すべてのドキュメントに関する変更の履歴が維持されます。ドキュメントのバージョン履歴は、次のようになります。
バージョンID |
MIMEタイプ |
コンテンツデータ |
サイズ |
Date |
更新者 |
コメント |
---|---|---|---|---|---|---|
3 |
text/html |
[content v3] |
47K |
6/16/00 |
bbrown |
新しい情報 |
2 |
text/html |
[content v2] |
45K |
6/11/00 |
bbrown |
詳細なコンテンツ |
1 |
text/html |
[content v1] |
24K |
6/10/00 |
ssmith |
作成 |
ドキュメントをチェックアウトすると、そのドキュメントはロックされます。従って、ドキュメントをチェックインするかチュックアウトをキャンセルしない限り、誰もそのドキュメントにチェックアウトできません。(例外:必要な場合は、CMサブシステムを使用することにより、管理者はドキュメントのロックを解除できます。
コンテンツが変更されたドキュメントをチェックインすると、そのコンテンツの新しいバージョンが作成されます。コンテンツは変更せずにメタデータを変更した場合は、ドキュメントをチェックインする際に新しいバージョンは作成されません。メタデータは変更されますが、バージョン化はされません。
ドキュメントが承認されると、そのドキュメントで公式にリリースされたバージョンとして、そのコンテンツを発行できます。アプリケーションによりドキュメントが要求された場合、提供されたものが発行されたバージョンになります。
ただし、発行されたバージョンが、常に最新のバージョンであるとはかぎりません。コンテンツ開発者は、最新バージョンのドキュメントをチェックアウトして、引き続き修正を行うことができます。ドキュメントを発行すると、パブリック用にそのドキュメントの安定したバージョンが作成されます。
CMサブシステムには、次の機能に対する組み込みサポートがあります。
機能 |
説明 |
詳細は次の項目を参照してください。 |
---|---|---|
コンテンツのキャッシュ |
異なる要素のキャッシュを設定できるCM機能。 |
|
タスク管理 |
ドキュメントの発行など、特定の操作のバックグラウンド実行を設定するCM機能。 |
|
コンテンツのインポートおよびエクスポート |
CMサブシステムとの間でコンテンツをインポートおよびエクスポートする機能。 |
次のような他のexteNd DirectorサブシステムとCMを統合できます。
関連サブシステム |
説明 |
詳細は次の項目を参照してください。 |
Search |
ドキュメントのコンテンツおよびメタデータを概念およびキーワードから検索する機能がサポートされています。 |
『Content Search Guide』の概念検索に関する章 |
Security |
CMサブシステム要素に安全にアクセスするために使用します。 |
|
ワークフロー |
ワークフローアプリケーションでCMドキュメントにアクセスするために使用します。 |
『ワークフローガイド』の コンテンツライフサイクルアプリケーションに関する章 |
Copyright © 2004 Novell, Inc. All rights reserved. Copyright © 1997, 1998, 1999, 2000, 2001, 2002, 2003 SilverStream Software, LLC. All rights reserved. more ...