この章では、Oracle WebCenter Content: Recordsでの処理スケジュールの設定および管理について説明します。処理とは、コンテンツに対して実行されるアクションです。通常は、現在の業務を行うためには必要なくなったアイテムに対して実行されます。この章では、処理を開始できるトリガー、処理を停止できる凍結の設定方法も説明します。最後に、処理アクションの実行について説明します。
この章では、以下のトピックについて説明します。
トリガーは、トリガー・イベントの発生時に、処理手順の実行を開始します。トリガーは、保存カテゴリの処理ルールに関連付けられています。トリガー・イベントは、コンテンツ・アイテムの状態の変化、先行処理アクションの完了、保存期間のカットオフ、カスタム・トリガーなどにできます。
処理の実行を開始する2種類のトリガーが用意されています。システム導出トリガーは、定義済イベントに基づく組込みトリガーです。カスタム・トリガーは、管理者が作成して固有のイベントを定義できます。
トリガーを使用するには、次の権限が必要です。
管理.レコード・マネージャ: この権限があると、トリガーに関する情報を表示できます。
管理.トリガー: トリガーに関する情報の表示に加えて、この権限があると、トリガーを作成(追加)、編集および削除できます。
セキュリティ・グループを使用して、トリガーへのアクセスをブロックできます。たとえば、「管理.トリガー」権限を持っているユーザーがトリガーを編集および削除できないようにするには、セキュリティ・グループを使用して、これらの機能へのアクセスを制限できます。トリガーに割り当てられたセキュリティ・グループへのアクセス権限を持っているユーザーのみがそのトリガーを編集および削除できます。
この項では、次の項目について説明します。
システム導出トリガーは、次の組込みイベントを使用します。
保存期間のカットオフは、保存期間で指定された時間単位の終わりにカットオフ・アクションを発生させます。カットオフ後、コンテンツ・アイテムは、処理ルールで指定された保存期間保持されます。たとえば、保存期間のカットオフがトリガー・イベントとして使用され、3カレンダ年の保存期間が指定された場合、現在の年の終わりにカットオフが行われ、影響を受けるコンテンツは、年末のカットオフの後の3年間保持されます。
トリガー保存期間は、AllowRetentionPeriodWithCutoff
変数が有効の場合に使用できます。これはデフォルトで有効になっています。
負の保存期間を使用できるのは、次の変数がrecords_management_environments.cfg
ファイルで有効になっている場合のみです。
AllowRetentionPeriodWithoutCutoff=1
。これが有効の場合、保存期間は、カットオフおよび先行アクションのデフォルトのトリガー・イベントに加えて、他のトリガー・イベントでも許可されます。
dDispPeriod:allowSignedInteger=1 dDerivedMonthDelay:allowSignedInteger=1 dDerivedDayDelay:allowSignedInteger=1
これが有効の場合、負の保存期間をトリガーに指定できます(カットオフおよび先行アクションを除く)。
例:
Triggering Event =Contract Ended Retention Period =-1 month Disposition Action =Notify Authors Triggering Event =Preceding Action Retention Period =3 months Disposition Action =Archive
処理手順シーケンスの先行アクションが処理を完了すると、次に続くルールが開始されます。システムはいつ先行アクションが完了するかを追跡し、処理シーケンスの次のステップを自動的にトリガーします。
アイテムまたはフォルダの状態に基づくシステム導出のグローバル・トリガーは、アイテムまたはレコード・フォルダの暗黙的または明示的変更の影響を受ける可能性があります。暗黙的変更の例は、アイテムが将来に設定されたアクティブ化日を持っている場合です。システムは、将来のアクティブ化日を認識し、指定された日にアイテムをアクティブ化し、アイテムの状態を自動的にアクティブに変更します。レコード管理者は、将来のアクティブ化日を指定すること以外には明示的なアクションを実行する必要はありません。状態の明示的変更の例は、管理者が特定のアイテムを手動で取消しまたは期限切れにする場合です。コンテンツが別のトリガー依存の状態である場合、関連する処理ルールがアイテムに対して動作します。
カスタム・トリガーは、管理者によって明示的に定義されます。カスタム・トリガーは、コンテンツの状態に基づくシステム導出トリガーよりも包括的で詳細です。システム導出トリガーは、保存カテゴリ内の1つのコンテンツ・アイテムが指定された状態の唯一のアイテムである場合があるため、これのみに影響する場合がありますが、カスタム・トリガーは指定された保存カテゴリ内の該当するすべてのコンテンツに影響を与えることができます。
3種類のカスタム・トリガーを定義できます。
グローバル・トリガー。これは管理者が定義したときに発生します。
カスタム直接トリガー。これはメタデータ・フィールドをトリガー・イベントとして使用します。
カスタム間接トリガー。これは、監査イベントに基づいて定期的に発生します。
トリガーは、「処理ルール」ページの「トリガー・イベント」リストに表示されます。
トリガーの作成、編集およびトリガーに関する情報の表示へのアクセスは、セキュリティ設定で制御できます。ACLセキュリティが有効の場合、グループおよびユーザー権限によってトリガーへのアクセスを制限できます。デフォルトのセキュリティが使用される場合、トリガーをセキュリティ・グループに割り当て、ファイル作成者を指定できます。
注意:
メタデータ・フィールドdReleaseDate
およびdCreateDate
を移入するインデクサ・プロセスは、ライフサイクルの再計算をトリガーできないため、これらのフィールドをトリガー日として使用することはできません。
グローバル・トリガーにはアクティブ化日があります。アクティブ化日は、過去、現在または将来の日付にできます。ユーザーは、トリガーを作成し、トリガーのアクティブ化をアクティブ化が必要になるまで無期限延期できます。本質的にこれは休止状態のトリガーで、これにはアクティブ化日が含まれていません。
ユーザーは、すぐにアクティブになるトリガーを作成するか、特定の日時にトリガーをアクティブにするか、またはトリガーのアクティブ化をアクティブ化が必要になるまで無期限延期できます。
カスタム直接トリガーは、製品に組み込まれシーンの背後で動作するグローバル・トリガーに加えてカスタマイズしたトリガー機能を作成するために使用します。カスタム直接トリガーは、コンテンツの状態、コンテンツまたはレコード・フォルダの日付フィールドのみに基づくシステム導出トリガーです。これらのトリガーはグローバル・トリガーではありません。これらは、指定の状態を満たすアイテムのみに影響します。標準(グローバル)トリガーやイベント(間接)トリガーと異なり、アクティブ化日はカスタム直接トリガーには明示的に設定されず、これは有効になっていません。カスタム直接トリガーは、作成されると、常にアクティブで使用する準備ができています。
日付フィールドまたはフォルダ日付フィールド、あるいは両方を備えたカスタム直接トリガーを作成できます。コンテンツとフォルダ日付フィールドの間には論理ANDの関係はありません。複数のフィールドが指定された場合、コンテンツ・フィールド間またはフォルダ・フィールド間には論理ANDの関係があります。このフィールドはコンテンツのトリガーをアクティブ化するために使用され、フォルダ・フィールドはフォルダのトリガーをアクティブ化するために使用されます。
標準(グローバル)トリガーと異なり、間接トリガーにはライフサイクルがあります。承認の監査は組込み間接トリガーです。このトリガーは監査イベントに基づいています。これは、コンテンツ・アイテムをチェックインするときに「監査に従う」が選択されていて、チェックイン・ページの「監査」リストで監査期間が選択されている必要があります。
間接トリガー機能は、定期的に繰り返すトリガーを設定して維持する時間を節約します。レコード管理者は、1年間のトリガー・リストを移入する必要があります。
次の各項で説明するように、トリガーの管理にはいくつかのタスクが関係します。
注意:
このアクションを実行するには、「管理.トリガー」権限が必要です。この権限は、デフォルトでレコード管理者およびレコード・オフィサ・ロールに割り当てられます。
デフォルト・ロールよりも大まかなセキュリティ設定をトリガーに割り当てるには、ACLセキュリティ設定が有効になっていて、ユーザーがロールおよびすべてのグループ権限のエイリアスに割り当てられていることを確認します。
間接トリガーを作成するとき、間接トリガーの基になるコンテンツ・フィールドは「構成マネージャ」ユーティリティにすでに作成されている必要があります。また、間接トリガー期間の期間オプション・リストを移入する必要があります。
カスタム・トリガーは、通常、トリガーの「PCM」フィールドを使用して作成されません。トリガーの「PCM」フィールドを使用するには、まず使用するフィールドを作成する必要があります。このフィールドには接頭辞「x」を付ける必要があります(たとえば、xPhysicalDateField
)。同様のフィールドを「構成マネージャ」に同じ名前で接頭辞を付けずに作成する必要があります(たとえば、PhysicalDateField
)。フィールドを作成した後、このフィールドをトリガーで使用するために選択できます。
カスタム・フィールドの作成の詳細は、「「基本カスタム・セキュリティ」フィールドの作成」を参照してください。
トリガーを作成するには、次のようにします。
既存のトリガーを変更するには:
トップ・メニューから「レコード」→「構成」を選択します。
「ページ」メニューで、「保存」、「トリガー」の順に選択します。
「トリガーの構成」ページで、編集するトリガーの種類を選択します(グローバル、カスタム直接または間接)。
編集するトリガーのアイテムの「アクション」メニューから「編集」、「トリガーの編集」の順に選択します。
トリガー・タイプの作成ページまたはトリガー・タイプの編集ページで、該当するフィールドを変更します。
「更新の送信」をクリックします。
トリガーが正常に更新されたことを示すメッセージが表示されます。
「OK」をクリックします。
注意:
このアクションを実行するには、「管理.トリガー」権限または「管理.レコード・マネージャ」権限のいずれかが必要です。「管理.トリガー」権限はデフォルトでレコード管理者ロールおよびレコード・オフィサ・ロールに割り当てられ、「管理.レコード・マネージャ」権限はレコード管理者ロールに割り当てられます。
トリガー情報を表示するには:
注意:
トリガーへの参照を表示するには、「管理.トリガー」権限または「管理.レコード・マネージャ」権限のいずれかが必要です。「管理.トリガー」権限はデフォルトでレコード管理者ロールおよびレコード・オフィサ・ロールに割り当てられ、「管理.レコード・マネージャ」権限はレコード管理者ロールに割り当てられます。
トリガーへの参照(定義でトリガーを使用する処理ルール)を表示するには:
注意:
このアクションを実行するには、「管理.トリガー」権限が必要です。この権限は、デフォルトでレコード管理者ロールおよびレコード・オフィサ・ロールに割り当てられます。また、トリガーのセキュリティ・グループの削除権限(D)も必要です。レコード・オフィサ・ロールには、デフォルトではこの権限はありません。
トリガーが使用中の場合、トリガーへのすべての参照を削除してからトリガーを削除する必要があります。トリガーは、処理ルールでトリガー・イベントによって参照されます。
トリガーを削除するには:
複数のトリガーを削除するには、トリガー・チェック・ボックスを選択し、「表」メニューで「削除」を選択します。
注意:
このアクションを実行するには、「管理.トリガー」権限が必要です。この権限は、デフォルトでレコード・オフィサ・ロールおよびレコード管理者ロールに割り当てられています。
承認の監査間接トリガーは、使用可能な唯一の組込み間接トリガーです。作成するあらゆる間接トリガーに対して同じ手順を使用します。トリガー名を選択し、同じステップを実行してこれらのトリガーを移入します。
必要な日付を指定するには:
注意:
このアクションを実行するには、「管理.トリガー」権限が必要です。この権限は、デフォルトでレコード管理者およびレコード・オフィサ・ロールに割り当てられます。
間接トリガーの日付エントリ(トリガー期間)を削除するには:
この項では、次のトリガーの例を示します。
この例ではグローバル・トリガーを作成します。アクティブ・トリガーは、アクティブ化されていて、アクティブ化日に遅延なしですぐに有効になるトリガーです。この例では、アクティブ化日がわかっているイベント・トリガーが作成されます。
将来のアクティブ化日を指定したグローバル・トリガーを作成できます。トリガーのアクティブ化は、指定した日時まで延期されます。ユーザーは、トリガーのアクティブ化を前の日付にできます。これを行うには、グローバル・トリガーを作成するときに将来のアクティブ化日を使用します。
アクティブ化日を入力するまで遅延されるアクティブ化日を指定したトリガーを作成できます。これは、休止している非アクティブ・トリガーです。休止トリガーは、イベントが発生することはわかっているが正確な日付がわからないイベント・トリガーの場合に便利です。システム処理のオーバーヘッドを回避するには、トリガーを有効にしないでください。
休止グローバル・トリガーを作成するには、トリガー作成時にアクティブ化日を入力せず、これを後で入力します。
無効になっている休止トリガーは、将来のアクティブ化日を設定せずにアクティブ化できます。これを行うには、トリガーを編集し、アクティブ化日を入力します。
この例では、従業員の退職日に基づくカスタム・フィールドのカスタム直接トリガーを作成します。コンテンツ情報更新フォームに従業員の退職日を入力した後、直接トリガーおよびアイテムは、その処理を開始します。
「構成マネージャ」ユーティリティを使用して、従業員の退職日のカスタム・フィールドを作成します。
「管理」メニューから「管理アプレット」を選択します。
「管理アプレット」のリストから、「構成マネージャ」を選択します。
「構成マネージャ」ユーティリティで「情報フィールド」タブをクリックし、「追加」をクリックします。
カスタム情報フィールドの追加ページで、「フィールド名」としてEETermDate
と入力し、「OK」をクリックします。
「編集」ページで、「フィールド・キャプション」として従業員の退職日
と入力します。
「フィールド・タイプ」リストで、「日付」を選択します。
「必須」が選択されていないことおよび「ユーザー・インタフェース」と検索インデックスが選択されていることを確認します(通常これがデフォルト)。
「OK」をクリックします。
「データベース設計の更新」をクリックします。
日付フィールドに基づくカスタム直接トリガーを作成します。
トップ・メニューから「レコード」、「構成」、「トリガー」の順に選択します。
「トリガーの構成」ページで、「カスタム・トリガー」領域の「追加」をクリックします。
トリガー・タイプの作成ページまたはトリガー・タイプの編集ページで、「トリガー名」としてEE Term Date
と入力します。
「簡単な説明」として従業員の退職日
と入力します。
「コンテンツ日付フィールド」リストで、EETermDateをクリックします。
フィールドにxEETermDate
が移入されます。
「作成」をクリックします。
カスタム直接トリガーが正常に作成されたことを示すメッセージが表示されます。
このカスタム・トリガーによってアクティブ化される処理手順を設定します。この処理手順は、従業員の退職日が入力されるとカットオフを実行し、アイテムを3年間保持し、その後レコードを破棄します。この例では、Employeesという名前のカテゴリの処理ルールを作成します。カテゴリおよび処理手順を作成するには:
「コンテンツの参照」、「保存スケジュール」の順に選択します。
保存スケジュールの検索ページの「ページ」メニューで「作成」、「保存カテゴリの作成」の順に選択します。
「保存カテゴリの作成」ページまたは「保存カテゴリの編集」ページで、「保存カテゴリ識別子」としてEE-RC-1
と入力します。
「保存カテゴリ名」としてEmployees
と入力します。
「保存カテゴリの説明」として、従業員の保存カテゴリ
と入力します。
(米国政府機関では必須)処理の当局のコードとしてEE-RC-1
と入力します。
「作成」をクリックします。「処理手順」ページで、最初のルールを作成します。
「追加」をクリックします。
「処理ルール」ページの「トリガー・イベント」リストでEE Term Dateという新しいカスタム直接トリガーを選択します。
「処理アクション」リストで、「カットオフ」を選択します。
「OK」をクリックします。
2番目のルールを作成します。
「追加」をクリックします。
「処理ルール」ページの「トリガー・イベント」リストで「先行アクション」を選択します。
「保存期間」フィールドで、3
と入力し、「カレンダ年」をクリックします。
「処理アクション」リストで、「破棄」を選択します。
「OK」をクリックします。
「更新の送信」をクリックします。
処理のサマリーを含むメッセージが表示されます。
「OK」をクリックします。
このトリガーをテストするには、テスト従業員のコンテンツ・アイテムの有効期限を「情報更新フォーム」に入力します。ここには、コンテンツ情報ページの「アクション」メニューの「更新」オプションでアクセスできます。アクセスできます。コンテンツ・アイテムは、カットオフ日に処理を開始します。コンテンツ・アイテムのライフ・サイクルを確認すると、処理の日付がすでに設定されていることがわかります。
凍結(動的保留と呼ばれることもある)は、アイテムの処理を禁止します。これは、法的要件または監査要件に準拠するために使用できます(情報に関して法的保留を行う必要がある場合など)。様々なタイプの凍結を定義して、組織で必要な凍結/保留処理を調整できます。
法的処理中の「フェデレーテッド凍結」の使用の詳細は、「フェデレーテッド検索および凍結の使用」を参照してください。
注意:
カスタム処理アクションの作成には、Oracle WebCenter Contentの詳細な技術的知識が必要となります。カスタム処理アクションを定義するには、コンサルティング・サービスに問い合わせてください。
アイテムが凍結されると、そのアイテムのすべてのリビジョンが凍結されます。凍結されるリビジョンは直接凍結され、その他のリビジョンは凍結を継承します。選択したコンテンツのアイテムに対して繰り返し凍結をスケジュールすることも可能です。
次のタスクが凍結の管理に含まれます。
凍結を編集する手順は、次のとおりです。
トップ・メニューから「レコード」→「構成」を選択します。
その後、「保存」→「凍結」を選択します。
凍結の構成ページで、凍結の「アクション」メニューから「編集」、「凍結の編集」の順に選択します。
「凍結の作成」ページまたは「凍結の編集」ページで、必要に応じて変更を行い、完了したら「更新の送信」をクリックします。
凍結情報を含む凍結が正常に更新されたことを示すメッセージが表示されます。
「OK」をクリックします。
注意:
このタスクを実行するには、「管理.記録マネージャ」権限が必要です。この権限は、デフォルトでレコード管理者ロールに割り当てられています。
このページには、次のアクションを実行するメニュー・オプションもあります。
編集: 現在の凍結の編集、凍結の解除または通知の変更に使用します。
削除: 現在の凍結を削除するために使用します。
注意:
コンテンツ・アイテムに現在適用されている凍結は削除できません。削除しようとすると、エラー・メッセージが表示されます。
情報: 次の検索を実行するために使用します。
凍結されたコンテンツのスクリーニング: 現在の凍結で凍結されたコンテンツ・アイテムのリストを表示します。このリストには、凍結ステータスを親レコード・フォルダから継承している休止コンテンツは表示されません。
凍結されたコンテンツすべてのスクリーニング: 現在の凍結で凍結されたすべてのコンテンツ・アイテムのリストを表示します。このリストには、凍結ステータスを親保存フォルダから継承している休止コンテンツもすべて表示されます。
凍結されたフォルダのスクリーニング: 現在の凍結で凍結されたフォルダのリストを表示します。このリストには、凍結ステータスを親フォルダから継承している休止フォルダは表示されません。
凍結されたフォルダすべてのスクリーニング: 現在の凍結で凍結されたすべてのフォルダのリストを表示します。このリストには、凍結ステータスを親フォルダから継承している休止コンテンツもすべて表示されます。
注意:
「...スクリーニング」オプションは、「管理.スクリーニング」権限がある場合のみ使用できます。
注意:
このアクションを実行するには、「管理.記録マネージャ」権限が必要です。この権限は、デフォルトでレコード管理者ロールに割り当てられています。凍結のセキュリティ・グループの削除権限(D)も必要です。
凍結が現在任意のアイテムに適用されている場合、この凍結は削除できません。凍結を削除するには:
複数の凍結を削除するには、凍結チェック・ボックスを選択し、凍結の構成ページの「表」メニューで「削除」を選択します。
注意:
このタスクを実行するには、「管理.記録マネージャ」権限が必要です。この権限は、デフォルトでレコード管理者ロールに割り当てられています。
フォルダ、コンテンツ・アイテムまたはフォリオを凍結するには:
注意:
このタスクを実行するには、「管理.レコード・マネージャ」権限が必要です。この権限は、デフォルトでレコード管理者ロールに割り当てられています。
特定の凍結で現在凍結されているフォルダまたはコンテンツ・アイテムをすべて凍結解除するには:
注意:
このタスクを実行するには、「管理.記録マネージャ」権限および「管理.スクリーニング」権限が必要です。これらの権限は、デフォルトでレコード管理者ロールに割り当てられています。
特定の凍結で現在凍結されているコンテンツ・アイテムまたはフォルダを検索するには:
注意:
このタスクを実行するには、「管理.記録マネージャ」権限が必要です。この権限は、デフォルトでレコード管理者ロールに割り当てられています。
凍結に電子メール通知が設定されると、通知電子メールは凍結が作成されるときに初めて送信されます。通知は、凍結が作成されたときに定期的に送信できます。
凍結に関する電子メール通知を再送信するには(たとえば、凍結実装の変更に関係のある人に通知するには):
通知は、凍結を検索することによって設定することもできます。「凍結情報」ページで、「編集」、「再通知」の順にクリックします。
この例では、企業の訴訟に起因する凍結を作成します。この凍結は2016年2月20日まで有効です。
Litigation
と入力します。XYZ社との訴訟
と入力します。2/20/2016
を指定します。これには、入力するか、「カレンダ」アイコンを使用します。訴訟手続きが完了するまで凍結解除しないでください
と入力します。処理アクションは、記憶装置または連邦記憶センターへの転送、永続的なコンテンツの米国国立公文書館(NARA)への転送、一時コンテンツの処理、コンテンツの更新情報への置換え、分類の調整などのアクティビティを含むことができます。
処理は、コンテンツのライフサイクルの3つの段階(作成/受信、使用およびメンテナンス、処理)の最後の段階です。処理は、処理手順で定義されます。処理手順は、通常次のように構成されます。
処理手順は、保存カテゴリ内で作成されます。すべての子レコード・フォルダおよびコンテンツ・アイテムは通常、その親保存カテゴリから処理を継承しますが、処理ルールを特定のレコード・フォルダのみに適用することもできます。
アクセス制御リスト(ACL)は、処理の実行中にユーザーがどのアイテムにアクセスできるかに影響を与えることができます。たとえば、ユーザーがカテゴリのACLに入っていない場合、そのユーザーは、適切なエイリアス・グループに入っていて適切な権限を持っているとしても、保留中の処理にアクセスできません。常にカテゴリで使用中のACLを確認して、そのカテゴリで行われるアクションに対する効果が何かを確認します。
この項では、次の項目について説明します。
イベント処理は、イベント発生時にアイテムを処理するタイミングを表します。指定したイベントの発生時またはその直後、アイテムは処理の対象になります。イベント自体は、発生のカットオフまたはクローズとして動作します。イベント処理は、保存期間を持たず、「リビジョンの削除」または「すべてのリビジョンの削除」のようなアクションを使用します。イベント処理手順の一般的な例は、「廃止時に破棄」または、分類されたコンテンツの場合には「分類解除後10年間保持」です。処理アクションは様々です。
DoD目的で追跡されるコンテンツは、「破棄」や「保存」などのアクションを使用し、アイテムの状態はそれぞれ「廃止」および「分類解除」です。
非DoDコンテンツは、「リビジョンの削除」や「すべてのリビジョンの削除」のようなアクションを使用します。
イベント処理を作成する手順を追った例を表示するには、「イベント処理」を参照してください。
分類を使用している場合(DoD 5015.2仕様の第 4章の要件に準拠することも保証済であるオプションのセキュリティ機能)、イベント処理を設定して、特定の日にコンテンツを分類解除したり、特定に日に分類をダウングレードしたりできます。
まとめると、イベント処理は、保存期間を持たず、暗黙的なシステムで導出されたカットオフを持ちます。
図14-1 イベント処理
時間処理は、固定保存期間を持ち、ユーザー定義のファイル・カットオフで始まります。保存期間は、処理手順がコンテンツ・アイテムでアクションを実行する前に発生する必要があります。一般的な例を次に示します。
(会計年度またはカレンダ年の)年末にカットオフ
3年間保持してから破棄
分類解除時にカットオフし、10年間保持してから破棄(DoD分類アイテム)
時間処理を作成する手順を追った例を表示するには、「時間処理」を参照してください。
まとめると、時間処理は、保存期間および明示的に定義したカットオフを持ちます。
図14-2 時間処理
時間イベント処理は、指定したトリガー・イベントで始まる処理手順です。イベント発生後、フォルダまたはコンテンツ・アイテムがカットオフされ、保存期間が適用されます。時間イベント処理手順の一般的な例は、「訴訟終結の5年後に破棄」です。時間イベント処理を作成する手順を追った例を表示するには、「時間イベント処理」を参照してください。
まとめると、時間イベント処理は、明示的に定義したイベント、カットオフおよび保存期間を持ちます。
図14-3 時間イベント処理
カテゴリ・ルールのレビュー機能を有効にしてから処理を一般使用できるようにする必要があります。この機能を使用するには、次の構成変数を設定する必要があります。
保存設定の構成ページのカテゴリ処理のレビューの有効化を選択します。
CategoryDispositionWorkflowContentType: カテゴリ処理のデフォルトのワークフローは、保存カテゴリのコンテンツ・タイプで実行されます。必要に応じて、この構成変数を別のコンテンツ・タイプに変更します。
UpdateDispositionTableOnWorkflowApproval: ワークフローが処理されて承認されるときに、システムによる処理表の更新を許可します。デフォルトはtrueです。falseに設定すると、コンテンツ・アイテムが解放されるときに表が更新されます。最終リビジョンが削除されると前のリビジョンが現在のリビジョンになり、そのリビジョンが解放されると処理表が更新されます。
ワークフローを設定して、処理ルールのレビューを有効にする必要があります。ワークフローを有効にして、ワークフロー・プロセスを開始します。有効にすると、アイテムはワークフローに進みます。アイテムがワークフロー・プロセスを終了する前にプロセスを無効にすると、プロセスが再度有効になるまでアイテムがワークフローに留まり、完了しなくなる場合があります。
この機能を有効にした後、処理は使用前に承認のワークフローに入ります。処理を作成した後、処理がワークフローにあり承認待ち中であることを示すメッセージが表示されます。
処理手順は、トリガー・イベント発生時にアクティブ化されます。次のタイプのトリガー・イベントが発生できます。
先行アクション・トリガー・イベント: 次のようなアクションがイベントを引き起こすイベント。
保存期間のカットオフ: このイベントは、処理プロセスをカットオフし、保存期間を適用します。これは、時間処理または時間イベント処理に基づくシステム導出のトリガー・イベントに使用できます。
ボリューム付き期間カットオフ: このイベントは、処理プロセスをカットオフしてボリュームにし、保存期間を適用します。
コンテンツの状態トリガー・イベント: 次のようなコンテンツ・ステータスがトリガーを設定するイベント。
取消: このイベントは、関連コンテンツまたはレコード・フォルダが取り消されたときにアクティブ化します。
削除が承認されました: このイベントは、関連コンテンツまたはレコード・フォルダの削除が承認されたときにアクティブ化します。
期限切れ: このイベントは、関連コンテンツまたはレコード・フォルダが期限切れになったときにアクティブ化します。
廃止: このイベントは、関連コンテンツまたはレコード・フォルダが廃止としてマークされたときにアクティブ化します。
廃止と削除が承認されました: このイベントは、関連コンテンツまたはレコード・フォルダが廃止としてマークされ、削除が承認されたときにアクティブ化します。
廃棄: このイベントは、関連コンテンツまたはレコード・フォルダが廃棄されたとき(つまり、法令制定当局のために無効にされたとき)にアクティブ化します。
差替え: このイベントは、関連コンテンツが差し替えられたとき(つまり、新しいまたは向上したコンテンツに置き換えられたとき)にアクティブ化します。
注意:
アイテムをリンクして差し替える必要があります。
最新のリビジョンでない: このイベントは、関連コンテンツのリビジョンが最新リビジョンではなくなったとき(新しいリビジョンがリポジトリにチェックインされたとき)にアクティブ化します。このトリガーでは、ユーザーはルールを作成して古いリビジョンのコンテンツの自動処理を起動できます。これは、最新リビジョンのコンテンツのみを保持し、古いリビジョンの処理を自動化する場合に特に便利です。
2回差替え: このイベントは、関連する差替えコンテンツが再度差し替えられたときにアクティブ化します。コンテンツ・アイテムAがコンテンツ・アイテムBに差し替えられ、その後コンテンツ・アイテムCに差し替えられると、このトリガーはコンテンツ・アイテムAに対してアクティブ化します。
最新のレコードが追加されました: このイベントは、関連アイテムがレコード・フォルダに追加された最新アイテムである場合にアクティブ化します。これを使用すると、ユーザーはフォルダのアクティビティを追跡でき、アクティビティ・レベルに基づいてフォルダの使用状況を最適化する際に便利です。たとえば、指定した期間アクティビティがないフォルダを削除(または、そうでない場合には処理)する場合です。
スケジュールされた分類解除日: このイベントは、関連コンテンツまたはレコード・フォルダが特定の日に分類解除されるようにスケジュールするとアクティブ化します。このトリガーは、ClassifiedEnhancementsコンポーネントが有効な場合にのみ使用できます。
スケジュールされたダウングレード日: このイベントは、関連コンテンツまたはレコード・フォルダが特定の日にセキュリティ分類のダウングレードが行われるようにスケジュールするとアクティブ化します。このトリガーは、ClassifiedEnhancementsコンポーネントが有効な場合にのみ使用できます。
分類解除日: このイベントは、関連コンテンツまたはレコード・フォルダが特定の日に分類解除されたときにアクティブ化します。このトリガーは、ClassifiedEnhancementsコンポーネントが有効な場合にのみ使用できます。
間接トリガー: イベントは、関連コンテンツまたはレコード・フォルダが監査時に承認されたとき(組込みの承認の監査間接トリガーを使用)にアクティブ化します。
カスタム・トリガー: カスタム・トリガーの詳細は、「トリガーのタイプ」を参照してください。
保存期間は、トリガー・イベント後に処理アクションが実行されるまで待機する時間です。いくつかの組込み期間単位(カレンダ年、会計年度四半期、月、週など)を使用できますが、カスタム期間も作成できます。
保存期間は、すべてのトリガー・イベントに対して指定でき、ユーザーはコンテンツの処理ルール(たとえば、最新のリビジョンがチェックインされた3か月後にすべての古いリビジョンを削除)を作成できます。
保存期間の例を次に示します。
5カレンダ年
2会計年度四半期
6か月
4週
処理アクションは、トリガー・イベントの発生および保存期間(ある場合)の経過の後に行うことを定義します。次の組込み処理アクションがサポートされています。次の組込み処理アクションに加えて、ユーザーはカスタム処理アクションを定義できます。
次のアクションについて説明します。
注意:
デフォルトの処理アクションは、常に管理者の承認が必要です。カスタム処理アクションを構成して、承認を自動的に実行できます。一部のアクションは、システムがアクションが行われたかどうか認識できないため、個々の「完了としてマーク」手順を備えています。
たとえば、物理レコードの破棄または移動の完了はソフトウェアでは判定できないため、誰かがアクションの完了をマークする必要があります。宛先がソフトウェアを使用して定義され、アイテムの物理的移動がソフトウェアの管理下にない場合の転送、登録および移動のアクションもすべて同じことが当てはまります。
分類解除: このアクションは、コンテンツを分類解除するときが来たことを示します。
分類のダウングレード: このアクションは、アイテムのセキュリティ分類を階層の次に低いセキュリティ分類に下げるときが来たことを示します。
分類のレビュー: このアクションは、アイテムのセキュリティ分類のステータスをレビューするときが来たことを示します。
分類のアップグレード: このアクションは、アイテムのセキュリティ分類を階層の次に高いセキュリティ分類に上げるときが来たことを示します。
これら4つの処理アクションは、ClassifiedEnhancementsコンポーネントが有効な場合にのみ使用できます。
以前のリビジョンの削除: このアクションは、処理アクションをトリガーしたコンテンツ・アイテムのリビジョンの前のリビジョンを削除するときが来たことを示します。トリガーをアクティブ化したリビジョンは、最新リビジョンのコンテンツ・アイテムである場合がありますが、そうである必要はありません。
コンテンツ・アイテムに5つのリビジョンがあって、この処理アクションがリビジョン5(最新リビジョン)に対してアクティブ化された場合、リビジョン4のみが削除としてマークされます。
コンテンツ・アイテムに5つのリビジョンがあって、この処理アクションがリビジョン3に対してアクティブ化された場合、リビジョン2のみが削除としてマークされます。
リビジョンの削除: このアクションは、処理アクションをトリガーしたコンテンツ・アイテムのリビジョンを削除するときが来たことを示します。このリビジョンは、最新リビジョンのコンテンツ・アイテムである場合がありますが、そうである必要はありません。
コンテンツ・アイテムに5つのリビジョンがあって、この処理アクションがリビジョン5(最新リビジョン)に対してアクティブ化された場合、リビジョン5のみが削除としてマークされます。
コンテンツ・アイテムに5つのリビジョンがあって、この処理アクションがリビジョン3に対してアクティブ化された場合、リビジョン3のみが削除としてマークされます。
削除の承認: このアクションは、レコード・フォルダまたはコンテンツの削除を承認するときが来たことを示します。
すべてのリビジョンを削除する: このアクションは、コンテンツ・アイテムのリビジョン以前のすべてのリビジョンを削除するときが来たことを示します。トリガーをアクティブ化したリビジョンは、最新リビジョンのコンテンツ・アイテムである場合がありますが、そうである必要はありません。DoD構成モジュールが有効になっている場合、処理アクションを承認するときに「すべてのリビジョンの削除(メタデータの破棄)」またはリビジョンの削除(メタデータは削除しない)のいずれかの選択を求めるプロンプトが表示されます。DoD構成モジュールが無効の場合、メタデータは保持できません。
コンテンツ・アイテムに5つのリビジョンがあって、この処理アクションがリビジョン5(最新リビジョン)に対してアクティブ化された場合、リビジョン1からリビジョン5が削除としてマークされます(事実上、コンテンツ・アイテムをリポジトリから完全に削除します)。
コンテンツ・アイテムに5つのリビジョンがあって、この処理アクションがリビジョン3に対してアクティブ化された場合、リビジョン1からリビジョン3が削除としてマークされます。
古いリビジョンを削除する: このアクションは、処理アクションをトリガーしたコンテンツ・アイテムのリビジョンの前のすべてのリビジョンを削除するときが来たことを示します。トリガーをアクティブ化したリビジョンは、最新リビジョンのコンテンツ・アイテムである場合がありますが、そうである必要はありません。
作業用コピーの削除: このアクションは、クローンされたコンテンツ・アイテムの作業用コピーを削除します。まず、クローンの直接の作業用コピーを削除します。次に、修正済クローン自身のリビジョンが見つかるまで、作業用コピーの以前のリビジョンがすべて削除されます。修正済クローン自身のリビジョンが見つかると、削除はその時点で停止します。このアクションは、RmaEnableFixedClones
構成変数がtrueに設定されていない場合には使用できません。
カテゴリの削除ルールが存在する場合、コンテンツは最初に見つかったルールに従って削除されます。したがって、コンテンツは、1つのフォルダからのみではなく同じカテゴリのすべてのフォルダから削除されます。
新規リビジョンのチェックイン: このアクションは、影響を受けるコンテンツ・アイテムの最新リビジョンを取得し、このリビジョンのコピーをリポジトリに新規リビジョンとしてチェックインするときが来たことを示します。これは、変更された履歴情報に基づいてコンテンツ・アイテムのリビジョンを処理したり、期限切れドキュメントをリフレッシュしたり、コンテンツ・アイテムを処理プロセスの条件ワークフローに入れたりする際に便利です。
登録: このアクションは、物の物理的かつ法的保管をNARAなどの記録保管機関に移管するときが来たことを示します。「登録(メタデータの破棄)」または「登録(メタデータは削除しない)」を選択します。
アクティブ化: このアクションは、レコード・フォルダまたはコンテンツをアクティブ化するときが来たことを示します。
閉じる: このアクションは、レコード・フォルダを閉じるときが来たことを示します。
カットオフ: このアクションは、コンテンツまたはレコード・フォルダをさらなるプロセスからカットオフするときが来たことを示します。カットオフとは、アイテムのステータスを変更してさらなるプロセスを禁止することです。
ボリュームのカットオフと作成: これはボリューム・フォルダを作成し、コンテンツをその中に配置し、ボリュームをカットオフします。
期限切れ: このアクションは、レコード・フォルダまたはコンテンツが期限切れになるときが来たことを示します。
廃止: このアクションは、コンテンツを廃止としてマークされるときが来たことを示します。
関連コンテンツとしてマーク: このアクションは、現在のコンテンツにリンクされたコンテンツをマークします。
アクションなし: このアクションは、現在実行するアクションがないことを示します。このアクションは、通常、処理の間にあります。「アクションなし」アクションは、処理マイルストーンを通過し、処理の次のステップのプロセスが始まったことを通知します。
作成者に通知: このアクションは、影響を受けるカテゴリで処理アクションが実行予定になったことをそのカテゴリの作成者に通知するときが来たことを示します。
差替え: このアクションは、コンテンツ・アイテムを別のコンテンツ・アイテムで差し替えるときが来たことを示します。
前述の組込み処理アクションに加えて、カスタム処理を定義して組織固有のレコード管理のニーズを反映できます。
アーカイブ: このアクションは、コンテンツまたはレコード・フォルダをアーカイブするときが来たことを示します。「アーカイブ(メタデータの破棄)」または「アーカイブ(メタデータは削除しない)」を選択します。
コンテンツ・サーバーのアーカイブの作成: このアクションは、影響を受けるコンテンツとそのメタデータを含むアーカイブを作成するときが来たことを示します。
ボリュームの作成: ボリューム・フォルダを作成します。このアクションが発生すると、コンテンツはボリューム・フォルダに転送されます。
移動: このアクションは、コンテンツおよびメタデータをシステム外に移動するときが来たことを示します。「移動(メタデータの破棄)」または「移動(メタデータは削除しない)」を選択します。
転送: このアクションは、コンテンツをある場所から別の場所に転送するときが来たことを示しますが、法的かつ物理的保管は転送しません(これは登録で行います)。「転送(メタデータの破棄)」または「転送(メタデータは削除しない)」を選択します。
ほとんどの場合、保存期間は、トリガー・イベントがカットオフに設定されるまで開始しません。ファイルのレコードをカットオフすることは、レコード・リビジョンが定期的に終了し、完了したブロックを処理または転送できるようにすることです。通信ファイルの場合、これによって新規ファイルを作成できます。カットオフによって、古いファイルへの入力が終了し、新しいファイルへの入力が開始されます。
保存期間の長さによって、コンテンツ・アイテム、カテゴリまたはフォルダをいつカットオフするかおよびカットオフを実行する間隔が決まります。この項で説明するガイドラインを使用すると、カットオフして保存期間を適用するタイミングを決める際に役に立ちます。
トリガーの保存期間は、AllowRetentionPeriodWithCutoff
変数が有効な場合にのみ指定できます。デフォルトでは無効です。
保存期間が1年未満であるコンテンツ・アイテムは、通常保存期間と同じ間隔でカットオフされます。たとえば、保存カテゴリの保存期間が1か月の場合、毎月末にフォルダをカットオフします。次に、最後の処理を適用するまで(たとえばアイテムの破棄まで)次の月の保存期間を適用します。
コンテンツ・アイテムの保存期間が1年以上の場合、各会計年度末またはカレンダ年末にフォルダをカットオフします。年末のカットオフの後、保存期間を適用します。
様々なカテゴリにある複数のフォルダにファイルされるコンテンツは、最長時間処理に基づいて管理されます。
異なる保存カテゴリに属している複数のフォルダにアイテムがファイルされた場合、そのアイテムは複数の処理プロセス・スケジュールの影響を受けます。このシナリオでは、最長保存期間について説明します。ただし、アイテムは、2つ以上のカテゴリに属している処理手順によって処理されます。次のシナリオでは、処理プロセスの優先順位について説明します。
コンテンツは、カテゴリ1のフォルダ1およびカテゴリ2のフォルダ2にファイルされます。
カテゴリ1: フォルダ1 | カテゴリ2: フォルダ2 |
---|---|
2012年4月1日に期限切れ |
2012年3月1日に閉じる |
2012年4月10日にアーカイブ |
2012年4月5日に期限切れ |
2012年4月12日に破棄 |
2014年4月20日に破棄 |
手順は、時間をずらして順番に処理されます。
2012年3月1日、アイテムはそのカットオフ日でカットオフされ、フォルダ2が閉じます。
2012年4月1日、アイテムが期限切れになり、期限切れ日がアイテムに追加されます(コンテンツ情報ページで表示できます)。
2012年4月5日、アイテムは再度有効期限切れにはならないため、期限切れ日は更新されません。
2012年4月10日、アイテムおよびフォルダ1がアーカイブされます。
2012年4月12日、アイテムへのポインタが、コンテンツ情報の更新によってフォルダ1から削除されます。ポインタはフォルダ2には存在し続けます。このアイテムは、実際にはフォルダにファイルされませんが、フォルダを指します。
2014年4月20日、フォルダ2のアイテムは、残りのポインタによって保持されないため、最終的に破棄されます。
注意:
このアクションを実行するには、「管理.記録マネージャ」権限が必要です。この権限は、デフォルトでレコード管理者ロールに割り当てられています。
わかりやすいキャプションは、いつでも有効または無効にできます。この設定は、「スクリーニング」ページの「条件」ボックスの問合せ文字列にも影響します。
わかりやすいキャプションを有効または無効にするには:
注意:
このアクションを実行するには、カテゴリ.作成権限が必要です。この権限は、デフォルトでレコード管理者ロールに割り当てられています。
処理ルールは、デフォルトでカテゴリ内のすべてのコンテンツおよびレコード・フォルダに適用されます。特定のレコード・フォルダにのみ適用する処理ルールを作成することも可能です。これは一般的な操作手順です。特定のタイプの処理の手順例を表示するには、「処理の例」を参照してください。
注意:
このアクションを実行するには、カテゴリ.編集権限が必要です。この権限は、デフォルトでレコード管理者ロールに割り当てられています。
保存カテゴリの処理手順内の処理ルールを編集するには:
「コンテンツの参照」、「保存スケジュール」の順に選択します。
保存スケジュールの検索ページで、適切な保存カテゴリに移動します。
アイテムの「アクション」メニューで「編集」、「処理の編集」の順に選択します。
「処理手順」ページで、編集するルールを選択し、「編集」アイコン(鉛筆のイメージ)をクリックします。
「処理ルール」ページでルールを変更し、「OK」をクリックします。「処理ルール」ページが閉じます。
「更新の送信」をクリックします。
処理情報を含むメッセージが表示されます。
「OK」をクリックします。
注意:
このアクションを実行するには、カテゴリ.作成権限が必要です。この権限は、デフォルトでレコード管理者ロールに割り当てられています。
他のカテゴリからルールをコピーし、現在のカテゴリのルールを上書きするには:
注意:
このアクションを実行するには、カテゴリ.読取り権限が必要です。この権限は、デフォルトでレコード管理者ロールに割り当てられています。
この項では、次の処理の例を示します。
この項の例はすべて、デフォルト(つまり、わかりやすいキャプションではない)処理キャプションを使用します。
この例では、イベント後にコンテンツを破棄するイベント処理手順を作成します。イベントでは、コンテンツが廃止になります。処理アクションは、コンテンツを破棄することです。この例では、1つの処理ルールを作成する必要があります。
「処理手順」: 廃止時に破棄します。
この例では、アイテムのリビジョン・ステータスに基づく処理の作成を示します。
処理手順: 新しいバージョンのアイテムがチェックインされたとき、1週間待機し、元の作成者に通知します。
この例では、保存期間およびコンテンツ破棄の最終処理を備えた時間処理の作成を示します。会計年度末に始まる予測可能なイベント・トリガーがあります。
処理手順: 会計年度末にカットオフし、現在のファイル領域に3会計年度保持してから破棄します。
この処理がシステム導出のトリガー・イベントを使用していることがわかります。アイテムが廃止になった後、会計年度末に自動的にカットオフされ、保存期間が始まります。
時間イベント処理手順の一般的な例は、「訴訟終結の5カレンダ年後に破棄」です。時間イベント処理は、イベントが発生する正確な時間を予測できないため、時間イベントとは異なりますが、イベントが発生すると処理プロセスが始まります。時間イベント処理は、組込みトリガーまたはカスタム・トリガーも使用します。イベントが発生すると、必要に応じて、カスタム・トリガーのアクティブ化日が入力されます。
この例では、イベント後の指定の時間にアイテムを破棄するイベント処理手順を作成します。イベントは、保留中の訴訟の終結です。保存期間は5年です。処理アクションは、コンテンツを破棄することです。
この例では、「Case Closed(訴訟終結)」というカスタム・トリガーを作成します。アクティブ化日を指定せずにカスタム・トリガーを作成します。訴訟が終結した後、カスタム・トリガーのアクティブ化日を設定する必要もあります。
処理手順: 訴訟終結の5カレンダ年後に破棄します。
適切なカテゴリに移動します。
保存カテゴリの行で、アイテムの「アクション」メニューから「編集」→「処理の編集」を選択します。「情報」アイコンをクリックして、「保存カテゴリ情報」ページの「ページ」メニューで「編集」、「処理の編集」の順に選択することもできます。
「処理手順」ページの「処理手順」領域で、「追加」をクリックします。
「処理ルール」ページで最初の処理ルールを定義します。
「トリガー・イベント」リストで、「カスタム・トリガー」サブリストの下の訴訟終結を選択します。
「処理アクション」リストで、「カットオフ」を選択します。
「OK」をクリックします。
ルールが、「処理手順」ボックスに表示されます。
2番目の処理ルールを定義します。
「追加」をクリックして別のルールを追加します。
「トリガー・イベント」リストで、「先行アクション」サブリストの下の「先行アクション」を選択します。
「保存期間」フィールドで、5
カレンダ年を指定します。
「処理アクション」リストで、「破棄」を選択します。
「OK」をクリックします。
ルールが、「処理手順」ボックスに表示されます。先行アクションによって開始されるルールが省略記号付きでインデントされていることがわかります。
「更新の送信」をクリックします。
完了メッセージが表示されます。
この例では、カテゴリ内のフォルダに異なるルールを適用する処理手順の作成を示します。
処理手順: 指定したイベントの後にファイリングを進めるためにフォルダを閉じ、破棄します。
フォルダ1: イベント・トリガーはプログラムABC取消し。
フォルダ2: イベント・トリガーはプログラムBBC期限切れ。
フォルダ3: イベント・トリガーはプログラムCDB廃棄。
この例では、3つのレコード・フォルダ(F1、F2、F3)および各フォルダのカスタム・イベント・トリガーを作成する必要があります。各フォルダには、特定のプログラムに関する対応が含まれています。
適切なカテゴリに移動します。
保存カテゴリの行で、アイテムの「アクション」メニューから「編集」→「処理の編集」を選択します。「情報」アイコンをクリックして、「保存カテゴリ情報」ページの「ページ」メニューで「編集」、「処理の編集」の順に選択することもできます。
「処理手順」ページの「処理手順」領域で、「追加」をクリックします。
「処理ルール」ページで、レコード・フォルダ1の最初の処理ルールを定義します。
「トリガー・イベント」リストで、このフォルダ用に作成したカスタム・トリガーであるプログラムABC取消しを選択します。
「処理アクション」リストで、「破棄」アクションを選択します。
「詳細オプション」セクションで、ルールが適用されているフォルダであるフォルダ1を選択します。
「OK」をクリックします。ルールが、「処理手順」ボックスに表示されます。
レコード・フォルダ2の2番目の処理ルールを定義します。
「追加」をクリックして別のルールを追加します。
「トリガー・イベント」リストで、このフォルダ用に作成したカスタム・トリガーであるプログラムBBC期限切れを選択します。
「処理アクション」リストで、「破棄」アクションを選択します。
「詳細オプション」セクションで、ルールが適用されているフォルダであるフォルダ2を選択します。
「OK」をクリックします。ルールが、「処理手順」ボックスに表示されます。
レコード・フォルダ3の2番目の処理ルールを定義します。
「追加」をクリックして別のルールを追加します。
「トリガー・イベント」リストで、このフォルダ用に作成したカスタム・トリガーであるプログラムCDB廃棄を選択します。
「処理アクション」リストで、「破棄」アクションを選択します。
「詳細オプション」セクションで、ルールが適用されているフォルダであるフォルダ3を選択します。
「OK」をクリックします。
ルールが、「処理手順」ボックスに表示されます。
「更新の送信」をクリックします。
完了メッセージが表示されます。複数の手順間で引かれるルールがあることがわかります。
この例では、処理手順での通常よりも多いフェーズを持つ処理手順の定義を示します。この例には、移動、転送および登録の処理アクションが含まれています。移動処理アクションはコンテンツの法的責任は転送しませんが、転送処理アクションはコンテンツの法的責任と物理的場所の両方を転送します。
処理手順: カレンダ年末にカットオフし、現在のファイル領域に1年間保持し、オフラインの記憶域に1年間移動し、FRC(連邦記録センター)に転送して10年間保持し、NARAに最終登録します。
適切なカテゴリに移動します。
保存カテゴリの行で、アイテムの「アクション」メニューから「編集」、「処理の編集」の順にクリックします。「情報」アイコンをクリックして、「保存カテゴリ情報」ページの「ページ」メニューで「編集」、「処理の編集」の順にクリックすることもできます。
「処理手順」ページの「処理手順」領域で、「追加」をクリックします。
「処理ルール」ページで、処理の最初のフェーズ(カレンダ年末にカットオフし、現在のファイル領域に1年間保持し、オフラインの記憶域に移動)を定義します
「トリガー・イベント」リストで、保存期間のカットオフを選択します。「保存期間」フィールドが使用可能になります。
「保存期間」フィールドで、テキスト・ボックスに1
と入力し、「保存期間」リストから「カレンダ年」を選択します。
「処理アクション」リストで、「移動」を選択し、コンテンツをオフライン記憶域に移動します。
「保存先ロケーション」ボックスで、オフライン記憶域を選択します。
「OK」をクリックします。
ルールが、「処理手順」ボックスに表示されます。
処理の次のフェーズ(オフラインの記憶域での1年間の保存期間の後、連邦記録センターに転送)を定義します。
「追加」をクリックして別のルールを追加します。
「トリガー・イベント」リストで、「先行アクション」を選択します。
「保存期間」フィールドで、1
と入力し、「保存期間」リストから「カレンダ年」を選択します。
「処理アクション」リストで、「転送」を選択し、コンテンツをオフライン記憶域に移動します。
「保存先ロケーション」ボックスにFRC
と入力します。
「OK」をクリックします。
ルールが、「処理手順」ボックスに、前のルールの下にインデントされて表示されます。
処理の最終フェーズ(コンテンツをFRCに10年間保存した後、米国国立公文書館(NARA)に登録)を定義します。
「追加」をクリックして別のルールを追加します。
「トリガー・イベント」リストで、「先行アクション」を選択します。
「保存期間」フィールドで、テキスト・ボックスに10と入力し、「保存期間」リストから「カレンダ年」を選択します。
「処理アクション」リストで、「登録」を選択します。
「保存先ロケーション」ボックスにNARA
と入力します。
「OK」をクリックします。
ルールが、「処理手順」ボックスに、前のルールの下にインデントされて表示されます。
「更新の送信」をクリックします。
完了メッセージが表示されます。
「OK」をクリックします。
この項では、処理がどのように実行されるかおよびある特定のタイプの処理アクションを続行するために必要な承認が何かを説明します。
トップ・メニューで「レコード」、「承認」の順に選択することによって、ユーザーは保存割当てに素早くアクセスできます。「メイン」メニューで「コンテンツ・サーバー」、「レコードの割当」の順に選択してもアクセスできます。
この項では、次の項目について説明します。
コンテンツは、処理で管理されているかどうかに関係なく定期レビューの対象にできます。DoDの観点から、レビュー対象のコンテンツはバイタルです。NARA(米国国立公文書館)によれば、バイタル・レコードは、緊急時または災害時に運用される必要がある重要な政府機関のコンテンツであり、また、政府の法的かつ財政的権利を保護するために必要です。また、指定されるあらゆる目的で更新されます。
政府機関ではない組織は、そのビジネスの種類に関してバイタルであるコンテンツを持っている場合があり、したがってレビューの対象になります。
レビューの対象であるアイテムは、通常、ビジネスで重要であると思われる約5パーセントのコンテンツから構成されます。このタイプのコンテンツの例を次に示します。
ソフトウェアのソース・コード
特許および著作権
信託、不動産、遺言などの法的文書
法規制の順守データ
レビューの対象であるバイタル・コンテンツのサイクルは、廃止されたコンテンツのコピーを現在のコンテンツのコピーに定期的に置き換えることを意味します。最初のレビューは、コンテンツのリリース日およびレコード・フォルダのファイル日に基づきます。次のレビュー日は、レビューアの最後のレビュー日に基づきます。
レビュー待ちのアイテムを検索するには、トップ・メニューで「レコード」、「承認」の順に選択します。「保留中のレビュー」を選択します。
RmaReviewersエイリアスのメンバーである場合、ページの表メニューの「すべてリスト」を選択します。こうすることによって、レビュー待ちのすべてのアイテムおよびこれらのレビューの実行に割り当てられた人が表示されます。ログイン・ユーザーの承認を待っているアイテムのみを表示するには、「自分のリスト」を選択します。
一部の保留中のトリガー・イベントは、処理がカテゴリに最初に設定されたときに「通知レビューア」として指定した人の承認のみが必要です。アクションが承認された後、これは処理が実行されるとき(通常夜間)にそのようにマークされて処理されます。処理アクションは、監査ログにログされ、承認リストから削除されます。
一部のイベントは、イベント・タイプおよび処理されるアイテムに応じて2つのステップが必要です。まず、承認される必要があり、アクションが手動で実行された後、必要なイベント・アクション(たとえば、別の場所への物理的転送)が実行された後に完了とマークされる必要があります。
処理待ちのアイテムを表示するには、トップ・メニューで「レコード」、「承認」の順に選択します。「保留中の処理」を選択します。保留中の処理へのアクセスも行うには、「メイン」メニューで「コンテンツ・サーバー」、「レコードの割当」の順に選択します。
イベントは、処理された後(承認され、必要に応じて、完了とマークされた後)、保留中のイベント・ページ(承認リストまたは完了リスト、あるいは両方)から自動的に削除される必要があります。イベントがこれらのページに残っていると、凍結されたアイテムまたはフォルダがあり削除を妨げている可能性が高いです。
たとえば、合計10アイテムが破棄イベントの影響を受け、その1つが凍結されている場合、その1つのアイテムのイベントが承認リストに残り、イベントは他の9個のアイテムの完了リストに移動します。これら9個のアイテムを破棄してイベントを完了としてマークできますが、凍結されたアイテムは凍結解除されるまで処理できません。
成功しなかった処理を検索する方法の詳細は、「失敗した処理の表示」を参照してください。
保存ステップの検索ページを使用して、処理ステップをスクリーニングします。たとえば、ユーザーは、承認済のアクション、その承認者および行われるアクションを探すためにスクリーニングできます。必要に応じて、スクリーニング結果から破棄証明書として使用できるレポートを作成できます。このページにアクセスするには、トップ・メニューで「レコード」、「監査」、「保存ステップ」の順に選択します。
正しく処理されなかった処理アクションに関する情報も表示できます。「失敗した処理」ページに、指定したように行われた処理アクションが表示されます。このページにアクセスするには、トップ・メニューで「レコード」、「監査」、「失敗した処理」の順に選択します。詳細は、「失敗した処理の表示」を参照してください。
保留中のイベントとレビュー・サイクルは、システムによって24時間サイクルで毎夜処理されます。通知は毎日深夜に送信されます。
スケジュールされた処理時間を待つのではなく特定のアクションをすぐに処理するには、「レコード」メニューの「バッチ・サービス」オプションを使用します。「バッチ」メニューのオプションには次のものがあります。
すべて実行: レビューまたは処理に関するすべてのイベントを処理します。
処理の実行: 処理関連の保留中のイベントをすべて実行します。
レビューの処理: アイテムが処理にあるかどうかに関係なく、保留中のレビューを処理します。
通知の送信: 処理に関する保留中の通知をすべて送信します。
その他の実行: 処理の実行に関係のない他のバッチ・サービス(アラートの監視の通知、スケジュールされたキー・ローテーションなど)を処理します。
システム・デフォルトのスケジュールされたバッチ・サービスは、深夜に毎夜処理され、処理が終了するまで続行します。これらのサービスが実行される時間は、リソース・インクルードによって制御されます。このインクルードは、records_management_resources.htm
ファイルにあり、set_doevent_for_records_daily_event
と呼ばれています。タイミングは、このインクルードをオーバーライドし、処理が実行される時間を変更するコンポーネントを書込むことによって変更できます。
このときに実行されるバッチ・ジョブは次のとおりです。
承認される予定のすべての処理の実行。処理後、これらは保留中になり、ユーザーはこれらを承認できます。
承認されたすべての処理の実行。処理後、処理アクションが実行されます。たとえば、削除される予定のアイテムはレコードから削除されます。
バイタル・レビューアなどのユーザーに送信される予定の様々な通知が完了し、ユーザーは実行する必要があるアクションを通知されます。
自分自身ではなく他のユーザーを選択してレビュー・アクションを実行し、処理イベントを実行すると便利な場合があります(しばらく外出する場合など)。ユーザー・プロファイルで代替レビューアを指定できます。代替レビューアは、あなたに割り当てられた保留中のアクションの電子メール通知を受信し、その処理を行えます。
ログインしてユーザー・プロファイルを開きます。リストから代替レビューアを選択します。リストには、デフォルトの通知受信者として指定したすべてのユーザーが含まれています。選択された人は、あなたに割り当てられた保留中のアクションおよびイベントの電子メール通知を受信します。
注意:
処理の通知の詳細を複数のユーザーまたは複数の代替レビューアに送信するための別名またはスクリプトを指定することもできます。これを実現するには、レビューア・フィールドにalias:<alias name>またはscript:<script name>を指定します。たとえば、alias:RmaReviewersです。
デフォルトでは、代替レビューアのみが通知を受信し、ユーザーは受信しません。システムを構成して、ユーザーと代替レビューアの両方が通知されるようにできます。これを行うには、次のテキストをconfig.cfg
構成ファイルに追加します。
RmaNotifyReviewerAndAlternateReviewer=true
この設定を有効にするには、コンテンツ・サーバーを再起動します。
次のタスクは、処理アクションを処理するときに実行します。
注意:
このアクションを実行するには、「管理.監査」権限が必要です。この権限は、デフォルトでレコード管理者ロールに割り当てられています。
処理アクションおよびイベントをスクリーニングするには:
注意:
このアクションを実行するには、「管理.監査」権限が必要です。この権限は、デフォルトでレコード管理者ロールに割り当てられています。
コンテンツがアダプタ・システムで管理されている場合、処理が失敗しても警告は与えられません。処理が失敗すると、そのアクションが「失敗した処理」ページに表示されます。そのページを確認し、アダプタ処理のステータスを確認します。成功しなかった処理アクションを検索するには:
注意:
このアクションを実行するには、「フォルダ.読取り」権限および「レコード.読取り」権限が必要です。すべての事前定義済管理ロールにこの権限が割り当てられています。自分の保留中イベントまたは他者の保留中イベントを表示するには、「管理.アクションを実行」権限が必要です。この権限は、デフォルトでレコード管理者ロールに割り当てられています。
取得する保留中アクションを表示するには:
注意:
このアクションを実行するには、「管理.保留レビュー実行」権限が必要です。この権限は、デフォルトでレコード・オフィサ・ロールおよびレコード管理者ロールに割り当てられています。他者に割り当てられたアイテムのレビューを実行する場合、メイン通知受信者としても指定されている必要があります。
「レビュー対象」としてマークされているアイテムまたは「レビュー対象」の処理を含むカテゴリ内のアイテムをレビューするには:
注意:
これらのアクションを実行するには、カテゴリ.レビューの編集権限またはフォルダ.レビューの編集権限が必要です。この権限は、デフォルトでレコード管理者ロールに割り当てられています。
保存カテゴリまたはレコード・フォルダのレビュー情報を編集するには:
フォルダのレビュー情報を編集するとき、次の点に注意してください。
このアクションを実行するには、フォルダ.レビューの編集権限が必要です。この権限は、デフォルトでレコード管理者ロールに割り当てられています。
アイテムのレビュー情報の変更に使用した手順と同じ手順に従って、フォルダのレビュー情報を変更します。レビュー設定は継承されます。任意の子フォルダをレビュー対象のままにする必要がある場合、親フォルダまたはカテゴリから設定を継承しなくなったレコード・フォルダのレビュー情報を設定します。
選択したレビューアは、レコード管理者ロールまたはレコード・オフィサ・ロールを持っている必要があります。これは、レコード・ユーザー・ロールを割り当てられたユーザーはレコード・フォルダをレビュー済としてマークできないためです。
保留中の処理にアクセスするには、「レコード」、「承認」の順に選択した後に「保留中のレビュー」または「保留中の処理」を選択するか、あるいは実行する処理またはレビューをユーザーに通知する電子メールのリンクをクリックします。
自分自身用のイベントがリストされます。他のユーザーに割り当てられたものを表示するには、RmaReviewersエイリアスに追加される必要があります。次に、保留中の処理ページまたは「保留中のレビュー」ページの「表」メニューで「すべてリスト」を選択します。
次のリストは、処理するアクションのタイプに関係なく一般的な機能を説明しています。
これらのアクションを実行するには、「管理.アクションを実行」権限が必要です。この権限は、デフォルトでレコード管理者ロールに割り当てられています。
ほとんどのイベントでは、処理イベントが実行されると、自動的に監査ログファイルが作成されます。この監査ログに対してスクリーニングを実行でき、必要に応じてコンテンツ・アイテムとして監査ログをチェックインできます。監査ログは、「移動」イベントや「アクションなし」イベントに対しては作成されません。
ほとんどのアクションは、毎夜実行されるバッチ・サービスで自動的に実行されます。または、「バッチ・サービス」が選択されている場合、「レコード」、「バッチ・サービス」の順に選択して実行されます。
保留中のイベントは、他の通知受信者の承認リストとファイル作成者自身の承認リストの両方に表示されます。メイン受信者がイベントを処理した場合、イベントは作成者の承認リストから削除されます。また、その逆も当てはまります。承認のみが必要なイベントもあります。これらのイベントの承認後、その関連処理アクションは、処理が実行される(通常夜間)と実行されます(「バッチ・サービス」メニューからオプションを選択して処理される場合を除く)。処理されたイベントは承認リストから削除されます。
一部のイベントは、イベント・タイプおよび処理されるアイテムに応じて複数のステップが必要です。まず、承認される必要があり、承認された後に完了としてマークされる必要があります。完了としてマークされたアイテムは、物理的に移動して、アクションを完了する必要があることが多いです(たとえば、アイテムの別の場所への転送)。
イベントを完了としてマークする必要がある場合、これは「保留中の処理」ページに表示されたままになり、イベントの名前が変更されて完了としてマークする必要があることを示します(たとえば、「転送完了としてマーク」)。アイテムを完了としてマークするには、アイテムのボックスを選択し、「表」メニューから「承認」を選択します。
複数のアイテムをレビュー済としてマークするには、アイテムのチェック・ボックスを選択し、「保留中のレビュー」ページの「日付の設定」メニューから「レビュー済としてマーク」を選択します。レビュー・コメントの入力を求めるプロンプトが表示されます。
現在の日付がレビュー日として挿入されます。この日付は、新しい日付を入力またはカレンダ・アイコンから日付を選択することによって変更できます。
レビュー情報を挿入した後、「OK」をクリックします。アイテムは、保留中のレビューのリストから削除されます。
処理アクションは、2つのタイプに分けることができます。1ステップで完了するものと複数のステップが必要なものです。この項では、各タイプの処理の実行について説明します。
処理はグループ化されバッチで保持されます。これらは、自動的にスケジュールされ、他のバッチ・プロセスと同時に実行されます(通常深夜以降)。
すぐに処理を実行するには、トップ・メニューで「レコード」、「バッチ・サービス」の順に選択します。処理するアクションのタイプ(処理、レビュー、通知など)を選択します。
処理されるイベントが使用可能にならず完了としてマークできない場合、影響を受けるアイテム(フォルダ内のコンテンツなど)は凍結され、処理できません。アイテムの「アクション」メニューから「処理フォルダと処理コンテンツのリスト」を使用して、フォルダのコンテンツを表示します。凍結されたアイテムは、凍結解除されるまで処理されません。処理が失敗した可能性もあります。処理ステータスの確認の詳細は、「失敗した処理の表示」を参照してください。
この項では、次のタイプの処理について説明します。
次の処理イベントは、複数のステップの処理が必要です。
登録: 登録は、処理シーケンスの最後のアクションの1つです。登録するファイルは、ディレクトリ(通常weblayout_dir
/groups/secure/rm/RmaAccessionApp
ディレクトリ)に格納され、ユーザーは、ファイルを最終アーカイブ機関にハンド・オフする方法を選択できます。
アイテムを破棄するがそのメタデータを保持、またはメタデータを保持せずにアイテムを破棄するオプションもあります。このオプションは、カテゴリの処理を作成するときに選択します。登録イベントは2つのステップから構成されます。まず、承認される必要があり、アクションが実行された後に完了としてマークする必要があります。
アーカイブ: アーカイブ・アクションは、コンテンツまたはフォルダのzipファイルを作成します。各zipアーカイブ内に、各アイテムおよびそのメタデータのコピーがあります。メタ・ファイルには、保存設定の構成ページの「メタデータ・フォーマットのアーカイブ」設定で指定されたフォーマットのアイテム・メタデータが含まれています(hda
、xml
またはcsv
)。アーカイブ・イベントは2つのステップから構成されます。まず、承認される必要があり、アクションが実行された後に完了としてマークする必要があります。.zip
ファイルはコンピュータの場所に格納されます。場所を確認するには、「保留中の処理」ページの「アーカイブ」アクションの「アクション」メニューから「アーカイブの場所」を選択します。
移動: 移動アクションは、内部(電子)アイテムのコピーをシステムに残しません。このアクションを保存管理システム内での保存アイテムの移動と混同しないでください。保存管理システム内での保存アイテムの移動は、保存スケジュール内で「移動」コマンドを使用して実行されます(「コンテンツの参照」メニュー)。移動イベントは2つのステップから構成されます。まず、承認される必要があり、アクションが実行された後に完了としてマークする必要があります。
転送: 転送アクションは、内部(電子)アイテムのコピーを保存管理システムに残します。転送イベントは、組織がアイテムを別の組織に送信したときに完了とみなすことができます。転送イベントは2つのステップから構成されます。まず、承認される必要があり、アクションが実行された後に完了としてマークする必要があります。最終転送アクションは、転送処理アクションが処理スケジュールの最後のアクションである場合です。転送アクションが処理アクションの最後のステップ(ルール)である場合、アイテムを破棄してからステップを完了としてマークする必要があります。
これらのイベントの1つの側面は、アイテムを処理するとともに破棄する機能です。たとえば、アイテムを転送し、転送後にメタデータを破棄すること、またはメタデータを保持することを選択できます。別の例は、コンテンツを移動し、メタデータを破棄または保持することです。これらのアクションは、最初にカテゴリの処理を設定するときに選択します。
破棄を完了するディスク消去回数は、config.cfg
環境ファイルの次の変数を設定して構成できます。
RecordsManagementNumberOverwriteOnDelete
この変数を設定した後にコンテンツ・サーバーを再起動します。デフォルトでは、ハード・ディスクの消去回数は2に設定されています。
破棄プロセスは、1ステップまたは2ステップから構成できます。電子(内部)アイテムの場合、システムによって複数のアクションが自動的に実行されます。アイテムのメタデータを破棄する場合、これも実行されます。
物理コンテンツ管理を使用して管理される物理的(外部)アイテムの場合、2つのステップが必要です。イベントは、まず承認される必要があり、外部アイテムが手動で破棄された後に完了としてマークする必要があります。
承認ステップ
「ID」列にリストされている名前は、処理されるカテゴリの名前にステップ番号を付加したものです。番号はステップ0から始まります。
トップ・メニューで「レコード」、「承認」の順に選択します。
「保留中の処理」を選択するか、または通知電子メールのリンクをクリックします。
処理アクションの情報を表示するには、「保留中の処理」ページのアクション名をクリックします。「処理情報」ページが開きます。このアクションに含まれているアイテムを表示するには、処理アクションの「アクション」メニューから「処理フォルダと処理コンテンツのリスト」を選択します。個々の処理をこのメニューから承認することも可能です。
承認するアクションのチェック・ボックスを選択し、「表」メニューから「承認」を選択します。
「処理パラメータ」ダイアログで、アクションの理由を入力し、「OK」をクリックします。アクション全体を中止するには、「取消」をクリックします。
アクションが承認されます。処理後(スケジュールされた処理時間中またはバッチ・サービス実行後)、イベントは「保留中の処理」ページに表示され、必要に応じて完了としてマークできます。
完了ステップ
アイテムが承認としてマークされ、処理された後も、「保留中の処理」ページに表示されたままですが、アクション名は「Mark action Complete」に変更されます(たとえば、Mark Accession Complete
)。
内部アイテムは必要に応じて自動的に完了します。このアクションは、ユーザーに対して透過的ですが、システム承認ステップが処理にリストされます。
アクションを完了としてマークするには:
トップ・メニューで「レコード」、「承認」の順に選択します。
「保留中の処理」を選択するか、または通知電子メールのリンクをクリックします。
処理アクションの情報を表示するには、「保留中の処理」ページのアクション名をクリックします。「処理情報」ページが開きます。このアクションに含まれているアイテムを表示するには、処理アクションの「アクション」メニューから「処理フォルダと処理コンテンツのリスト」を選択します。個々の処理をこのメニューから承認することも可能です。
承認する(完了としてマークする)アクションのチェック・ボックスを選択し、「表」メニューから「承認」を選択します。
「処理パラメータ」ダイアログで、処理アクションの理由を入力し、「OK」をクリックします。アクション全体を中止するには、「取消」をクリックします。
アクションで破棄に関する決定(つまり、アクションに関するメタデータの破棄または保持)を行う必要がある場合、「処理パラメータ」ダイアログのメニューから破棄方法を選択します。このような選択を伴う処理アクションは、登録、アーカイブ、移動および転送です。
アクションは、「保留中の処理」ページから削除されます。さらに承認が必要な場合(つまり、別のアクションを行って処理を完了する必要がある場合)、そのアクションは、処理後に「保留中の処理」ページに表示されます(スケジュールされた処理時間中またはバッチ・サービス実行後)。
次の処理は、単一のステップの処理が必要です。
分類されたレコードのアクション
分類のレビュー: このアクションは、アイテムのセキュリティ分類のステータスをレビューするときが来たことを示します。
分類のアップグレード: このアクションは、アイテムのセキュリティ分類を上げるときが来たことを示します。分類は、ユーザーが適用した分類と同じ分類まで上げることができます。
分類解除: このアクションは、コンテンツを分類解除するときが来たことを示します。
分類のダウングレード: このアクションは、アイテムのセキュリティ分類を下げるときが来たことを示します。
処理アクション
以前のリビジョンの削除: このアクションは、処理アクションをトリガーしたコンテンツ・アイテムのリビジョンの前のリビジョンを削除するときが来たことを示します。トリガーをアクティブ化したリビジョンは、最新リビジョンのコンテンツ・アイテムである場合がありますが、そうである必要はありません。
コンテンツ・アイテムに5つのリビジョンがあって、この処理アクションがリビジョン5(最新リビジョン)に対してアクティブ化された場合、リビジョン4のみが削除としてマークされます。
コンテンツ・アイテムに5つのリビジョンがあって、この処理アクションがリビジョン3に対してアクティブ化された場合、リビジョン2のみが削除としてマークされます。
リビジョンの削除: このアクションは、処理アクションをトリガーしたコンテンツ・アイテムのリビジョンを削除するときが来たことを示します。このリビジョンは、最新リビジョンのコンテンツ・アイテムである場合がありますが、そうである必要はありません。
コンテンツ・アイテムに5つのリビジョンがあって、この処理アクションがリビジョン5(最新リビジョン)に対してアクティブ化された場合、リビジョン5のみが削除としてマークされます。
コンテンツ・アイテムに5つのリビジョンがあって、この処理アクションがリビジョン3に対してアクティブ化された場合、リビジョン3のみが削除としてマークされます。
削除の承認: このアクションは、レコード・フォルダまたはコンテンツの削除を承認するときが来たことを示します。
すべてのリビジョンを削除する: このアクションは、処理アクションをトリガーしたコンテンツ・アイテムのリビジョンおよびこれ以前のすべてのリビジョンを削除するときが来たことを示します。トリガーをアクティブ化したリビジョンは、最新リビジョンのコンテンツ・アイテムである場合がありますが、そうである必要はありません。
コンテンツ・アイテムに5つのリビジョンがあって、この処理アクションがリビジョン5(最新リビジョン)に対してアクティブ化された場合、リビジョン1からリビジョン5が削除としてマークされます(事実上、コンテンツ・アイテムを完全に削除します)。
コンテンツ・アイテムに5つのリビジョンがあって、この処理アクションがリビジョン3に対してアクティブ化された場合、リビジョン1からリビジョン3が削除としてマークされます。
DoD構成モジュールが有効になっている場合、すべてのリビジョンを削除してメタデータを破棄または保持するか、あるいは古いリビジョンのみを破棄できます。DoD構成モジュールが無効の場合、メタデータは保持できません。
古いリビジョンを削除する: このアクションは、処理アクションをトリガーしたコンテンツ・アイテムのリビジョンの前のすべてのリビジョンを削除するときが来たことを示します。トリガーをアクティブ化したリビジョンは、最新リビジョンのコンテンツ・アイテムである場合がありますが、そうである必要はありません。
コンテンツ・アイテムに5つのリビジョンがあって、この処理アクションがリビジョン3に対してアクティブ化された場合、リビジョン1と2が削除としてマークされます。
コンテンツ・アイテムに5つのリビジョンがあって、この処理アクションがリビジョン5(最新リビジョン)に対してアクティブ化された場合、りブジョン1からリビジョン4が削除としてマークされます。
作業用コピーの削除: このアクションは、クローンされたコンテンツ・アイテムの作業用コピーを削除します。まず、クローンの直接の作業用コピーを削除します。次に、修正済クローン自身のリビジョンが見つかるまで、作業用コピーの以前のリビジョンがすべて削除されます。修正済クローン自身のリビジョンが見つかると、削除はその時点で停止します。
以前のクローンの削除: このアクションは、コンテンツ・アイテムの以前のクローンを削除します。
その他
新規リビジョンのチェックイン: このアクションは、影響を受けるコンテンツ・アイテムの最新リビジョンを取得し、このリビジョンのコピーを新規リビジョンとしてチェックインするときが来たことを示します。これは、変更された履歴情報に基づいてコンテンツ・アイテムのリビジョンを処理したり、期限切れドキュメントをリフレッシュしたり、コンテンツ・アイテムを処理プロセスの条件ワークフローに入れたりする際に便利です。
アクティブ化: このアクションは、レコード・フォルダまたはコンテンツをアクティブ化するときが来たことを示します。
閉じる: このアクションは、レコード・フォルダを閉じるときが来たことを示します。
カットオフ: このアクションは、コンテンツまたはレコード・フォルダをさらなるプロセスからカットオフするときが来たことを示します。カットオフとは、アイテムのステータスを変更してさらなるプロセスを禁止することです。
ボリュームのカットオフと作成: これはボリューム・フォルダを作成し、コンテンツをその中に配置し、ボリュームをカットオフします。
期限切れ: このアクションは、レコード・フォルダまたはコンテンツが期限切れになるときが来たことを示します。
廃止: このアクションは、コンテンツを廃止としてマークされるときが来たことを示します。
関連コンテンツとしてマーク: このアクションは、現在のコンテンツにリンクされたコンテンツをマークします。これは、xRelatedContentTriggerDate
フィールドを使用するカスタム直接トリガーのトリガー・アクションとして使用できます。
アクションなし: このアクションは、現在実行するアクションがないことを示します。このアクションは、通常、処理の間にあります。「アクションなし」アクションは、処理マイルストーンを通過し、処理の次のステップのプロセスが始まったことを通知します。
作成者に通知: このアクションは、影響を受けるカテゴリで処理アクションが実行予定になったことをそのカテゴリの作成者に通知するときが来たことを示します。
差替え: このアクションは、新規コンテンツをカテゴリまたはフォルダにチェックインし、元のコンテンツ・アイテムを差し替えることを示します。差し替えられたアイテムは、その名前に取消し線が引かれて示されます。
イベントの承認
トップ・メニューで「レコード」、「承認」の順に選択します。
「保留中の処理」を選択するか、または通知電子メールのリンクをクリックします。
「保留中の処理」ページで、処理アクションの情報を表示するアクション名をクリックします。
「処理情報」ページが開きます。
このアクションに含まれているアイテムを表示するには、処理アクションの「アクション」メニューから「処理フォルダと処理コンテンツのリスト」を選択します。現在のアクションの影響を受ける個々のアイテムをこのメニューを使用して承認することもできます。
承認するアクションのチェック・ボックスを選択し、「表」メニューから「承認」を選択します。
「処理パラメータ」ダイアログで、アクションの理由を入力し、「OK」をクリックします。アクション全体を中止するには、「取消」をクリックします。
アクションは、承認され、「保留中の処理」ページから削除されます。