| Oracle® WebCenter Contentコンセプト・ガイド 11gリリース1(11.1.1) B66700-01 |
|
 前へ |
 次へ |
Oracle WebCenter Content: Records (Recordsシステム)は、各コンテンツ・アイテムのライフ・サイクルを決定する保存スケジュールに従って、コンテンツ・アイテムを効率的に管理します。
レコード管理の主眼は、履歴やアーカイブとして、または法的な目的でコンテンツを保持することに置かれる傾向がありますが、一方で保存管理も実行されます。保存管理の主眼は、コンテンツの保存にかかるコストが、保持することの価値を上回った場合に、スケジュールに従ってコンテンツを削除することに置かれる傾向があります。
Recordsシステムでは、レコード管理と保存管理が1つのソフトウェア・システムに統合されています。Oracle WebCenter Content: Recordsを使用すると、必要に応じたコンテンツの追跡および保存、または不要になったコンテンツの処分が可能になります。
この項の内容は次のとおりです。
Content Serverとの統合に使用するアダプタの詳細は、第2.6項「アダプタを使用した保存の管理」を参照してください。
Oracle WebCenter Content: Recordsの詳細は、次の各マニュアルに記載されています。
Oracle WebCenter Content Records管理者ガイド
Oracle WebCenter Content Recordsセットアップ・ガイド
Oracle WebCenter Content Recordsユーザーズ・ガイド
その他の情報は、Oracle WebCenter Contentのインストレーション・ガイドを参照してください。
自身のサイトにインストールするRecordsオプションを選択できます。特定のオプションを選択することにより、有効にして使用可能にするコンポーネントを決定します。次の構成を使用できます。
最小: 必要最小限の機能を使用できるようにし、いくつかの処理アクションおよび大半の製品機能を除外します。
標準: DoD構成、分類されたトピック、FOIA/PA（情報公開法/プライバシー法）トラッキングおよび電子メールを除くすべての機能とすべての処理アクションを使用できるようにします。このオプションは物理コンテンツ・マネージャ(PCM)を有効にします。
DoDベースライン: 標準インストールにDoD構成と電子メールを追加した機能を使用できるようにします。
DoD分類済: FOIA/PAを除くすべての機能を使用できるようにします。
カスタム: 使用可能にする各種機能を選択できます。一部の処理アクションは別のアクションに依存しています。あるアクションを選択すると、依存しているアクションも自動的に選択されます。
自身のサイトの保存要件に従って、特定の構成タイプを選択します。
組織がコンテンツの保存を必要とする理由は様々です。多くの組織は、一定期間の情報保存が要求される条例の対象となります(サーベンス・オクスリー法およびDoD 5015.2などの政府規制への準拠など)。訴訟に関連して効率的な保存管理を必要としている組織があるかもしれません。または、組織全体でコンテンツを取得および共有するための、統一性のあるインフラストラクチャを構築したいと考えている組織もあるでしょう。Oracle WebCenter Content: Recordsを構成およびカスタマイズすることで、これらすべてのビジネス・ニーズに適合できます。
内部コンテンツ(Content Serverに格納される電子アイテム)のほか、Recordsシステムでは外部コンテンツも管理できます。外部に保存されているコンテンツ・アイテムは、多様な物理フォーマットもしくは電子フォーマットである可能性があります。ソース・ファイルがContent Serverに格納されていなければ、それは外部コンテンツと見なされます。このソフトウェアを使用すると、処理スケジュールの管理、外部ファイルに関連付けられたメタデータの検索、および外部ファイルの電子レンディションの管理を実行できます。電子レンディションは、外部アイテムのプライマリ・ファイルとしてチェックインすることも、別ファイルとしてファイルに保存し、外部ファイルのメタデータへのリンクを設定することもできます。
Recordsシステムを使用して、不正な情報開示(米国の国家安全保障に抵触する情報が含まれる場合、または企業経営における重要事項である場合など)に対する保護を必要とする機密コンテンツを管理できます。構成時のオプションの選択により、システムのDoD 5015.2標準(4章を含む)への準拠を保証できます。このソフトウェアのDoD標準への準拠は、JITC(相互運用性テストコマンド)によって認定されています。
次の手順は、保存されたコンテンツの基本的なワークフローを示しています。
保存スケジューおよび必須コンポーネント(トリガー、期間、分類、およびカスタム・セキュリティまたはメタデータ・フィールドなど)が作成されます。
ユーザーによってアイテムが保存スケジュールにファイルされます。ファイルされたアイテムについては、割り当てられたカテゴリの処理スケジュールが前提となります。
定義された処理スケジュールに従って、処理ルールが実施されます。通常、これには保存期間が含まれています。システム駆動のトリガーまたはカスタム・トリガーによって処理が行われます。トリガーは、複数のアイテムに同時に作用できます。
(トリガーによる)処理イベントの実施ごとに、電子メール通知がイベント処理の責任者に送信されます。これは確認についても同様です。保留イベントおよび確認は、ユーザー・インタフェースの「保存割当」リンクからアクセスできるページに表示されます。
Records管理者または権限を持つユーザーが確認プロセスを実行します。これは手動プロセスとなります。
Records管理者は保留イベントのページで処理アクションを処理します。これは手動プロセスとなります。
多くの処理スケジュールは、予測可能なスケジュールに従った時間ベースのものになります。たとえば、ファイルされたコンテンツは、一定年数が経過した後に破棄されます。システムでは、影響のあるコンテンツの処理期日が追跡されます。通知メールが送信され、コンテンツは「保存割当」領域にルーティングされます。
その後、保留イベントおよび確認の責任者が適宜コンテンツを処理します。使用できるメニュー・アクションは、アイテムの状態に応じた状況依存のものになります。たとえば、保存フォルダ破棄の最終処理段階になると、破棄コマンドが使用できるようになりますがアーカイブコマンドは使用できなくなります。
一方、時間イベントおよびイベントベースの処理は、非システム駆動トリガー(特別なシナリオで定義されたトリガー)で発動させる必要があります。たとえば、保留中の法的案件の起訴が開始された場合、開始日程情報は外部となるので、Records管理者は、カスタム・トリガーを有効にして動作日を設定する必要があります。カスタム・トリガーにより、特別イベントの発生に基づいたイベント・ベースおよび時間イベント・ベースの処理アクションを定義できます。
次の図により、処理(処分)時まで保持されるレコードの標準ライフ・サイクルを示します。
