管理上の更新には、ユーザーの削除、グループ内のメンバーシップの変更、リソースのためのアクセス コントロールの更新などが含まれる可能性があります。
ESF を使用する Enterprise Server コンポーネントには、管理者のために、ESF への Administrative Update Notification 要求をトリガーするためのさまざまな方法が用意されています。セキュリティ上の変更を加えた後は、稼働しているシステムでセキュリティ上の変更が取得されるように、MFDS および/または 1 つ以上の Enterprise Server に指示して ESF に通知する必要がある場合があります。これは、GUI またはコマンド ライン クライアントを使用して行うことができます。詳細については、Enterprise Server の管理マニュアルを参照してください。
その後、Enterprise Server コンポーネントでその ESF サブシステムへの Administrative Update Notification 要求が行われます。ESF によって、関連するすべてのキャッシュ済み結果がフラッシュされ、同じことを実行するよう、影響を受けた ESM Module に通知が行われます。
ES/MTO など、複数のプロセスで ESF が使用され、共有メモリを介して通信する環境では、1 つのプロセスによって各 Update 要求が処理されます。そのプロセスにより、影響を受けたすべてのデータが共有メモリからフラッシュされます。ただし、個々のプロセスでそれぞれ専用メモリ内にキャッシュ済みセキュリティ情報を保持している場合は、それらの各プロセスにも、他の ESF 要求が処理される前にその更新を通知する必要があります。
そのため、CAS SEP では ESF 呼び出しのたびに、他の SEP によって更新が処理されたかどうかを確認する必要があります。更新が処理された場合は、関連するすべてのプロセス専用データがフラッシュされ、影響を受けた ESM Moduleを呼び出して、同じことを実行するようそれらに命令が行われます。
これらの “更新保留” 操作には、2 種類の形式があります。前回 ESF が呼び出されてから 1 つの更新のみが処理された場合は、ESF によって、その単一の更新に影響を受けたすべてのデータがフラッシュされます。しかしながら、複数の更新が処理された場合は、ESF によってすべてのキャッシュ済み情報がフラッシュされます (“リフレッシュ” とも呼ばれる)。これにより、ほとんどアクティブにならないプロセスのための古い更新要求を際限なく保存する必要がなくなります。