提案された変更の管理

リリースバージョン: Xanadu

更新日 2024年08月01日

所要時間：10分

提案された変更機能を使用すると、構成アイテムおよび関連する関係に対する変更を事前に構成できます。これらの事前設定済みの変更は実装される準備ができていますが、後で適用されるまで実際には実装されません。

CI を表示するとき、提案された変更を表示すると、計画されている内容を確認できます。

この機能は、変更プロセスが承認段階にある間に変更を加え、承認が完了した後にのみ変更を実装する場合に便利です。変更が承認されない場合、レコードの変更を元に戻す必要はありません。変更が承認されると、提案されたすべての変更がクイックコマンドによって適用されます。

CI に対して以下の提案された変更を行うことができます。

CI フォームのフィールドを変更する。
その CI に関係を追加または削除する。

関係を変更するには、現在の関係を削除して新しい関係を追加する必要があります。提案された変更は削除できません。

CI 履歴の表示

CI の変更履歴は、リスト、カレンダー、タイムラインの形式で表示できます。

CI の提案された変更の表示

提案された変更を表示することで、CI の計画内容を確認できます。

始める前に

必要なロール：personalize_form

このタスクについて

提案された変更を表示するには、CI フォームレイアウトを構成して、[CMDB スケジュール設定済みの変更] フィールドを表示します。提案された変更は、デフォルトでは CI フォームに表示されません。

手順

移動先すべて > 変更 > オープン変更要求を開きます
[影響を受ける CI] 関連リストの [構成アイテム] を開きます。
CI フォームに直接移動することもできます。
フォームヘッダーバーを右クリックします。
選択 Configure (構成) > フォームレイアウト.
[CMDB スケジュール設定済みの変更] フィールドを [選択済み] ペインに移動します。
[保存] をクリックします。
CI フォームは、提案された変更の詳細を [スケジュール設定済みの変更] 領域に表示します。

提案された変更の CI への追加

CI への提案された変更は、変更要求またはタスク関連のレコードを表示しながら行うことができます。

始める前に

必要なロール：itil

手順

変更要求フォームで、[影響を受ける CI] 関連リストに移動します。
[影響を受ける CI] リストに CI がない場合は、[編集] をクリックし、この変更要求の影響を受ける CI を追加します。
提案された変更を構成する CI を右クリックし、[提案された変更] を選択します。
フォームに入力して、提案された変更を行い、[提案された変更を保存] をクリックします。
[更新] をクリックして変更をすぐに適用します。[削除] をクリックして CI を削除します。
CI 関係の追加または削除を提案するには：
1. [関連アイテム] セクションのプラスアイコンをクリックします。
2. [関係] セクションで、関係を追加または削除します。
  関係エディターの使用方法については、「CI 関係の作成または編集」を参照してください。
3. [提案変更の保存] をクリックします。
4. 提案された変更の保存を確認します。
[更新] または [削除] をクリックして変更をすぐにコミットします。
注:
CI 関係でのみ使用してください。ユーザーリレーションシップおよびグループリレーションシップに対して関係の追加または削除を提案することは有効ではありません。

次のタスク

提案された変更が保存されると、[提案された変更を適用] ボタンが変更要求フォームに表示されます。このボタンを使用すると、提案された変更をユーザーが CI にコミットできます。変更をコミットするのに適切な時期は、ビジネスプロセスによって決定されます。提案された変更がコミットされるまで、CI は既存のデータを保持します。ただし、ユーザーは変更が提案されていることを確認できます。

提案された変更の CI への適用

提案された変更を適用すると、その変更要求のすべての提案された変更が構成アイテムに適用されます。提案された変更は、検証なし、または提案された変更の検証テストが失敗した場合でも適用することができます。

始める前に

必要なロール：itil

このタスクについて

提案された変更を適用すると、フォームの [スケジュール設定済みの変更] の部分には [スケジュール設定済みの変更は見つかりません] と表示されます。提案された変更検証ルールを設定して、変更を適用する前に提案された変更を検証することができます。

手順

[変更要求] フォームに移動します。
[提案された変更を適用] ボタンをクリックします。
変更を確認する場合は、フォームヘッダーを右クリックして、[フォームの再ロード] オプションを選択する必要があります。

提案された変更検証ルールを作成または編集する

提案された変更がビジネス要件を満たし、CMDB に無効なデータを導入しないことを確認し、提案された変更を検証するためのスクリプトを含むルールを作成します。

始める前に

必要なロール：asset または itil

このタスクについて

CI に提案された変更検証ルールを設定するときは、提案された変更がルールの検証テストスクリプトをパスするかどうかを検証することもできます。検証テストの結果は合格または不合格として記録され、結果を表示できます。検証テストを実行することは必須ではなく、検証テストが失敗しても、提案された変更を適用できます。

手順

移動先すべて > 構成 > 変更の検証 > 提案された変更検証ルール.
[新規] をクリックするか、編集する既存のルールを選択します。

必要に応じてフィールドに入力します。

表 : 1. [提案された変更検証ルール] フォーム
フィールド	説明
ルール名	このルールの名前。
テーブル名	ルールが適用されるテーブル。
フィルター条件	このルールを特定の CI に適用するための条件。
アクティブ	このルールを有効にするためのチェックボックス。
ルールスクリプト	true または false を返す必要がある検証 Java スクリプト。たとえば、 `validateRule() { var os = current.getValue("os"); var cpu = current.getValue("cpu_count"); //Use current.getValue(fieldName) to get the proposed change value, eg. var os = current.getValue("os"); //Your verification code if (os != "SunOS" \|\| cpu < 2) return false; //Return true to pass the verification and false if the verification failed return true; }`

[送信] または [更新] をクリックします。

タスクの結果

[変更要求] フォームで [提案された変更の検証] をクリックすると、影響を受ける CI の提案された変更を検証できます。

提案された変更の検証

影響を受ける CI に提案された変更を適用する前に、提案された変更検証ルールを使用して、変更がビジネス要件を満たしていて、CMDB に無効なデータを追加しないことを検証します。

始める前に

提案された変更を検証するために使用されるルールを作成または編集します。詳細については、「提案された変更検証ルールを作成または編集する」を参照してください。

必要なロール：なし

このタスクについて

検証されていない、または検証テストに失敗した場合でも、提案された変更を適用することができます。

手順

CI に影響を与える [変更要求] フォームを開きます。
[提案された変更の検証] をクリックします。
提案された変更は、CI が [フィルター条件] の基準を満たしている提案された変更検証ルールに対して検証されます。
検証プロセスが完了した後、フォームの上部に表示されるメッセージを確認します。
メッセージには、検証テストが合格したか失敗したかが示されます。

次のタスク

過去 2 日間の変更要求に対して実行された検証テストの詳細を表示するには、[提案された変更検証ログ] 関連リンクをクリックします。

予定されている変更の検証スクリプトの作成または編集

ビジネス要件に従ってクラスへの変更が有効であったかどうか、および変更が予定されていたかどうかをチェックするカスタムスクリプトを作成します。予定されている変更の検証スクリプトは、CI 変更が CI タイムラインまたは変更履歴で表示されるたびに使用されます。

始める前に

必要なロール：admin または itil

このタスクについて

次のように各 CI 変更の検証が試行されます。

CI または CI の親の 1 つにカスタムスクリプトが存在する場合、スクリプトが実行され、その結果を使用して変更が有効か無効かのフラグが付けられます。親 CI は階層順に検査されます。
CI またはその親のいずれかにカスタムスクリプトが存在しない場合、事前定義された検証スクリプトが使用されます。変更された CI に関連付けられた変更要求の [作業開始日時] と [作業終了日時] の日の間に変更が発生した場合、その変更は予定されている変更として判定されます。

ただし、このチェックは常に信頼できるとは限りません。これは、作業日内に手動で CI を変更し、変更が無効であっても有効であるとフラグが付けられている可能性があるためです。

スクリプトは、スクリプト内のテスト条件を満たすかどうかによって、true または false のブーリアンを返す必要があります。CI クラスごとに別々のスクリプトを定義することができます。また、1 つのクラスに対して予定されている複数の変更検証スクリプトを定義することもできます。たとえば、異なるバージョンのスクリプトを維持するためなどです。特定の時点で CI クラスに対して有効なスクリプトは 1 つのみです。

変更を一意に特徴付けるパラメーターは次のとおりです。

変更されたフィールド
変更を実行したデータソース
変更のタイムスタンプ

変更の有効性を正しく判断するには、パラメーターを調べ、ビジネスロジックを適用して検証テストが満たされているかどうかを評価します。予定されている変更の検証スクリプトは、これらの特性のいずれかをテストし、変更が事前に確立された基準をいつ満たすのかを判断できます。たとえば、カスタムスクリプトは、CI のモードが稼働中またはメンテナンスであるか、誰が変更を開始したかをチェックできます。

手順

移動先すべて > 構成 > 変更の検証 > 予定されている変更の検証スクリプト.
[新規] をクリックするか、編集する検証スクリプトを選択します。

フォームに入力します。

表 : 2. [予定されている変更の検証スクリプト] フォーム
コントロール	説明
アクティブ	変更を検証するためのこのスクリプトを有効にするためのチェックボックス。
適用先	このスクリプトが適用されるクラス。
スクリプト	変更を検証するために実行するスクリプト。スクリプトがブーリアン値を返さない場合は、false に設定されます。

スクリプトには、スクリプトの入力変数を表示するテンプレートがあります。

表 : 3. テンプレートスクリプトの入力変数
変数	タイプ	説明
current	GlideRecord	処理中の現在のレコード。
updatedOn	GlideDateTime	変更のタイムスタンプ。
updatedBy	文字列	変更に対して責任を負うエンティティ。
fieldsChanged	文字列	変更されたすべてのフィールドの名前のカンマ区切りリスト。

このサンプルスクリプトは、誰がレコードの更新を開始したかをチェックします。アドミンがレコードの更新を開始した場合は、true を返します。それ以外の場合、スクリプトは false を返します。

isValidChange();

function isValidChange(/*GlideRecord current, GlideDateTime updatedOn, String updatedBy, String changedFields*/) 
{ 
   //Return true if the user that updated the record has an admin role 
   return isUserAdmin(updatedBy); 
}

function isUserAdmin(userName)
{
   var grUser = new GlideRecord("sys_user");
   grUser.addQuery('name', userName);
   grUser.query();
   if(grUser.next()) 
   {
       var roles = new GlideRecord ("sys_user_has_role");
       roles.addActiveQuery();
       roles.addQuery('user', grUser.sys_id);
       roles.query();
       while(roles.next()) 
       {
          if(roles.role.name == 'admin')
             return true;
       }
   }
   return false;
}

[送信] をクリックします。