Washington DC のすべての機能と製品のアップグレード情報

Washington DC の機能と製品のアップグレード情報に関する累積的なリリースノートの概要。

Washington DC にアップグレードする前に、使用しているすべての製品のアップグレード情報を確認してください。一部の製品では、アップグレードする前に特定のタスクを完了する必要があります。

アプリケーションまたは機能	詳細
AI Search	に Washington DCアップグレードすると、 AI 検索 新しい Genius 結果を使用するように既存の Genius 結果構成が自動的に更新されます AI 検索 Genius 結果構成フォーム データを指定しましたこの更新手順では、次の変更が行われます。 既存の Genius 結果回答タイプ フィールド値を削除します。 必要に応じて、 Genius 結果のロジック フィールドの値を新しい AI 検索 要求 プロセッサーフィールドと AI 検索 応答プロセッサー フィールドに移行します。 インスタンスをにアップグレードした後も、AI 検索以前にシステムプロパティにWashington DC 検索クエリに複数の用語が含まれている場合に使用するブール検索演算子 ( glide.ais.query.search_operator )設定した値は保持されます。複数用語検索で新しい拡張クエリモードの利点を得るには、このシステムプロパティの値を AND then OR 2+ key termsに設定します。システム・プロパティの詳細については AI 検索 、「」を参照してください AI Search system properties。 Washington DC以降、ユーザー [sys_user] テーブルではデフォルトで、インデックス付きレコードはsys_updated_on日付でソートされるのではなく、sys_created_on日付でソートされます。この変更では、 のユーザーテーブルのインデックス付きソース AI 検索のインデックスを再作成する必要があり、時間がかかる場合があります。以前のファミリリリースからアップグレード Washington DC する場合、 AI 検索 ユーザーテーブルのインデックス付きソースは自動的にインデックス再作成されません。ユーザーレコードの最新の構成を検索できるようにする必要がある場合は、ユーザーテーブルのインデックス付きソース のインデックスを手動で再作成 できますが、これには時間がかかる場合があります。それ以外の場合は、すべてのレコードのインデックスが再作成されるまで、 AI 検索 更新時に個々のユーザーテーブルレコードのインデックスが再作成されます。
Automated Test Framework	構成変更を行った後に、Now Platform® によって提供されたクイックスタートテストをコピーしてカスタマイズし、インスタンスが機能することを検証します。たとえば、アップグレードを適用するか、アプリケーションを開発する場合です。 カスタマイズを行っていないベースシステム上で、アプリケーションまたは機能プラグインが提供するデフォルトのデモデータを使用してテストを実行した場合にのみ、テストで合格の結果を生成できます。インスタンス固有のデータにクイックスタートテストを適用するには、クイックスタートテストをコピーしてカスタムデータを追加します。詳細については、「Available quick start tests by application or feature」を参照してください。
Business Continuity Management	リリースに Washington DC アップグレードする場合は、既存のビジネスインパクト分析、事業継続性計画、およびイベントに関する次の重要な情報に注意する必要があります。 ビジネスインパクト分析の場合、アップグレード後に手動で追加された依存関係に対して、依存関係アセスメントの [ソース] 列の名前が [プライマリソース] に変更され、BCMソースの名前が [手動] に変更されます。[ 依存関係を更新 ] アクション ボタンを選択すると、依存関係が追加されます CMDB 。 事業継続性計画の場合、[ソース] 列の名前が [アップグレード後の プライマリソース ] に変更されます。[ 依存関係を更新 ] アクション ボタンを選択すると、BIA 依存関係が追加されます CMDB 。以前のリリースとの互換性を維持するために、管理者はソースを構成し、 BCM BIA アップストリーム依存関係と BIA ダウンストリーム依存関係のみをソースとして更新構成に保持できます。 イベントと演習では、[ 依存関係を更新 ] アクションボタンを選択すると、アップグレード後に BIA、および Business Continuity Planning (BCP) の依存関係が追加されます CMDB。以前のリリースとの互換性を維持するために、管理者はソースを構成し、 BCM BIA アップストリーム依存関係と BIA ダウンストリーム依存関係のみをソースとして更新構成に保持できます。
Configuration Management Database (CMDB)	この列 product_instance_id は、新しい製品インスタンス識別子 (PID) をサポートするためにベース構成アイテム [cmdb_ci] テーブルに追加されました。これにより、既存の関連資産、CI、およびインストールベースアイテム (IBI) のルックアップとリンクが可能になります。アップグレード中の変更の影響とその影響を最小限に抑える方法の詳細については、 ワシントン リリースのスキーマ変更によるアップグレードの影響 [KB1534035] ナレッジ ベースの記事CMDB_CIを参照してください。 リリースへの Washington DC アップグレード後に初めて CMDB 360 を有効にする場合、非 CMDB クラス (構成アイテム [cmdb_ci] クラスから派生していないクラス) からの CI の CMDB 360 データのキャプチャを有効にするには、 glide.identification_engine.multisource_non_cmdb_ci_enabled システムプロパティを true に設定する必要があります。 コア UI で従来の Data Certification アプリケーションを使用していた場合、CMDB Workspace でのデータ認定の新しい実装では、関連する定義を使用できません。リリースおよび Washington DC CMDB Workspace バージョン 6.0 にアップグレードした後、従来の Data Certification アプリケーションで作成された定義を CMDB Workspace でドラフトのデータマネージャー認定ポリシーに変換できます。詳細については、「」を参照してください。
Core Now Platform	以前は、トランザクションがキャンセルされた場合に特定の監査可能な操作が記録されませんでした。監査レコードが見つからないこの動作は、レコードの変更と監査の作成前にプラットフォームがレコードの変更の間に一部の操作を実行し、キャンセルされるためです。しかし、現在では、レコードが変更された直後に監査が作成されるため、監査が記録される前にキャンセルされたトランザクションによって操作が中止される可能性が低くなります。この更新を容易にするために、監査はトランザクションと同じスレッドに記録されるようになりました。以前の監査はバックグラウンドスレッドで作成されていました。 この変更により、 glide.db.audit.lazy プロパティのデフォルト値が true から false に再定義されます。理想的には、このプロパティはプロパティテーブルで定義されていません。つまり、大部分のインスタンスで、リリースで Washington DC 新しいデフォルト値と動作の使用が開始されるということです。一部のインスタンスでは、このプロパティが値を true に設定した状態で挿入されている可能性があります。これは、これらのインスタンスがこの変更を使用して動作を監査できないことを意味します。この更新を利用するには、このプロパティを削除してください。
暗号化キー管理	インスタンス Washington DC をアップグレード MID サーバーしても、シークレット管理認証は失敗します。を MID サーバーWashington DCにアップグレードすることで、認証エラーを回避します。アップグレードできない場合は、認証エラーを回避するために、アップグレードWashington DCされるまでMID サーバー認証をオフにする必要があります。 MID Server のアップグレードの詳細については、「」を参照してください MID Server upgrades。
Enterprise Asset Management	に Washington DCアップグレードすると、エンタープライズ資産 [sn_ent_asset] テーブルでmodel_componentフィールドを使用できなくなります。代わりに、資産 [alm_asset] テーブルで新しいmodel_component_idフィールドを使用できます。[ENT - 新しいモデルに移行] コンポーネントスクリプトは、既存のmodel_componentフィールドデータをmodel_component_idフィールドに移動します。 資産の総所有コスト (TCO) について、次のアップグレードシナリオに注意してください。 アップグレードはすべての エンタープライズ資産管理 フロータスクに対して機能します ワークフロータスクごとにタスク料金表が必要です。 TCO のアップグレードにより、各タスクに対応する経費ラインの [ 資産 ] および [経費カテゴリ] フィールドに 入力されます。 経費カテゴリは、経費ラインと経費ラインのソースに基づいて入力されます。 既存のすべてのモデルの [TCO ベンチマークコスト] と [TCO ベンチマークしきい値] フィールドに手動で入力するか、一括インポート機能を使用して入力する必要があります。 TCO のアップグレードは、資産フォームの次のフィールドに入力します。 資産の耐用年数終了:作成日に月単位の有効年限を加えたもの。 資産の最初の使用日:作成日。 資産 TCO:資産に関連するすべての経費ラインの集計合計。単純な資産の場合、資産 TCO はその下の経費ラインの合計です。複合資産の場合、資産 TCO は、親資産とその子資産の経費ラインの合計です。
Financial Services Operations Core	への Washington DCアップグレード中に、プラグインは次の ファイナンシャルサービスオペレーションコア テーブルを再ペアレンティングします。 注: アップグレードされたインスタンスに多数のレコードがある場合は、アップグレードが完了するまでに時間がかかることがあります。 サービス定義 [sn_bom_service_definition] テーブルは、要求定義 [sn_ind_request_definition] ではなくサービス定義 [sn_case_type_selection] テーブルから拡張されています。 財務タスク [sn_bom_task] テーブルは、グローバルタスク [task] テーブルの代わりにカスタマーサービスタスク [sn_customerservice_task] テーブルから拡張されています。 保険加入者 [sn_bom_policy_participant] テーブルは、販売済み製品の関連当事者 [sn_install_base_sold_product_related_party] テーブルから拡張されています。 再ペアレント化により、既存のアプリケーションの機能を維持しながら、によって ServiceNow® カスタマーサービス管理 (CSM) もたらされる利点と進歩を活用できます。
Hardware Asset Management 10.0.0	にアップグレード Washington DCした後は、資産の総所有コスト (TCO) について、次のアップグレードシナリオに注意してください。 アップグレードは、すべての ハードウェア資産管理 フロータスクに対して機能します。 ワークフロータスクごとにタスク料金表が必要です。 TCO のアップグレードは、各タスクに対応する経費ラインの資産と経費のカテゴリフィールドに入力します。 経費カテゴリは、経費ラインと経費ラインのソースに基づいて入力されます。 既存のすべてのモデルの [TCO ベンチマークコスト] と [TCO ベンチマークしきい値] フィールドに手動で入力するか、一括インポート機能を使用して入力する必要があります。 TCO のアップグレードでは、資産の次のフィールドに値が入力されます。 資産の耐用年数終了:作成日と月単位の有効年限。 資産の最初の使用日:作成日と同じ。 資産 TCO:資産に関連するすべての経費ラインの集計。単純な資産の場合、資産 TCO はその下の経費ラインの合計です。複合資産の場合、資産 TCO は、親資産とその子資産の経費ラインの合計です。
Healthcare and Life Sciences Service Management Core	への Washington DCアップグレード中に、ヘルスケア販売済み製品 [sn_hcls_sold_product] 親テーブルが、次のテーブルのインストールベースアイテム [sn_install_base_item] に変更されます。 メンバープラン [sn_hcls_member_plan] 薬剤 [sn_hcls_medium] 予防接種 [sn_hcls_immunization] 登録済みプログラム [sn_hcls_enrolled_program] 登録済みプログラムサービス [sn_hcls_enrolled_program] また、次のテーブルは親テーブルが削除されており、スタンドアロンテーブルになっています。 医療機関[sn_hcls_organization] 医療機関[sn_hcls_location] 開業医所在地[sn_hcls_practitioner_facility] この親の再指定により、顧客はより広範なユースケースに組織テーブルと場所テーブルを使用できるようになります。 既存のデータは、既存の機能が影響を受けないように、次の方法で移行されます。 sn_hcls_immunizationの場所フィールドの参照がcmn_locationを使用するように更新されました。 すべてのデータが、医療販売済み製品テーブルからインストールベースアイテムテーブルに移動されます。 影響を受けるインストールベースアイテムの行は、医療販売済み製品のsource_task値に基づいて入力されます。 sn_hcls_enrolled_programとsn_hcls_enrolled_program_serviceのステータスがhcls_stateからコピーされます。 すべてのデータは、医療機関、医療機関の場所、および開業医の場所のスタンドアロンテーブルに移動します。 このスクリプトは、医療機関テーブルの既存のレコードの事業所テーブルにレコードを作成して、1 対 1 の参照を形成します。 サービス組織を参照するレコードは、適切な事業所への参照で更新されます。 施術者の場所にレコードを持つ施術者は、適切な事業所とともに [サービス組織メンバー] テーブルにレコードが作成されます。 医療の場所データを含むレコードには、その医療の場所の親サービス組織が含まれます。 注: アップグレードされたインスタンスに多数のレコードがある場合は、アップグレードが完了するまでに時間がかかることがあります。
Instance Data Replication	レプリケーションセットを V2 にアップグレードして Hermes メッセージングサービス を使用すると、インスタンスデータレプリケーション (IDR) (IDR) のパフォーマンスと処理効率を向上します。詳細については、「Upgrading legacy replication sets to V2 in Instance Data Replication」を参照してください。 アップグレード後に、レプリケーションペイロードエラー [idr_replication_payload_error] テーブルのログローテーションが自動的に有効になります。デフォルトでは、ログローテーションスケジュールは 7 つのシャードで構成され、シャードごとに 5 日間あります。アップグレード前に作成されたこのテーブルのログエントリはすべて自動的に切り捨てられます。
MID Server	最新の MID サーバー システム要件については、「MID Server のシステム要件」を参照してください。サポートされている JRE の最小バージョンは 11.0.9 で、推奨バージョンは 11.0.16.1 です。 独自の JRE をインストールした場合、アップグレード・プロセスは以下のアクションを実行して、サポートされている MID サーバー JRE が使用されるようにします。 MID サーバーアップグレード時にサポートされていないバージョンの JRE を使用している場合、アップグレード・プロセスでは、JRE の最低バージョンと推奨バージョンを示す警告メッセージが表示されます。 サポートされている JRE がホストで実行されている MID サーバー 場合、アップグレード MID サーバー はそのバージョンを使用します。 自動アップグレードを有効にするには、すべての MID サーバー ホストマシンが install.service-now.com のダウンロードサイトにアクセスする必要があります。詳細については、システムが管理する方法をお読みください MID サーバー 設定してください。. 実行可能ファイルパスごとに許可されるサービスは 1 つだけ Windows MID サーバー です。同じインストール フォルダーを指す複数のサービスがあるアップグレード Windows MID サーバー は開始できません。「」を参照してください。 MID サーバー 開始に失敗しました 詳細。 アップグレードの詳細については MID サーバー 、次のトピックを参照してください。 MID サーバー アップグレード前のチェック:実際にアップグレードを行う前に、システムでのアップグレード機能を MID サーバー AutoUpgradeモニターでテストする方法を説明しています。 のアップグレード MID サーバー 手動:手動でアップグレード MID サーバー する方法について説明します。
Order Management	この Washington DC リリースで導入された新機能は、の 注文管理以前のリリースではサポートされていません。
Performance Analytics	従来の PA スコア [pa_scores] テーブルは廃止されます。PA スコアテーブルにキャプチャされたインジケータースコアがまだある場合、そのようなスコアの数が 4,300 万未満の場合、これらのスコアはアップグレード時にpa_scores_l1テーブルとpa_scores_l2テーブルに自動的に移行されます。アップグレードに追加される予定時間は約 2 時間です。詳細については、「 KB1294371 」または Migrating Performance Analytics scores「」を参照してください。
プラットフォーム分析エクスペリエンス	プラットフォームアナリティクス エクスペリエンス機能は、以前はワークスペースに配置され プラットフォームアナリティクス ていました。機能はコア Now Platformの一部になりました 、から Next Experience 統一ナビゲーションアクセスできます。で作成されたコア UIダッシュボード、レポート、およびパフォーマンスアナリティクスウィジェットをこの機能に移行できます。
Playbook	にWashington DCアップグレードした後、ServiceNow Store のアプリケーションを更新しますプレイブックワークフロースタジオ。
ポートフォリオ計画立案	v8.0.0 以降、() プロライセンス機能にはワークスペースでのみ戦略的計画アクセスできます戦略的ポートフォリオ管理 (SPM)SPM。Pro ライセンスを所有し SPM ていても、Workspace で SPMポートフォリオ計画 Pro ライセンスの機能 (目標、製品フィードバック、ハイブリッドポートフォリオ計画、追加レンズなど) を引き続き使用している場合は、そのような機能にアクセスするには をインストールする 戦略的計画 必要があります。ワークスペースでのみ 戦略的計画 アクセスできる機能の詳細については、「 Portfolio Planning と Strategic Planning の比較」を参照してください。
Predictive Intelligence	に Washington DCアップグレードする場合、新しい回帰ソリューションを作成することはできません。既存のソリューションがある場合、それらは引き続きサポートされ、トレーニングと変更はできますが、新しいソリューションを作成することはできません。 類似性ソリューションおよびクラスタリングソリューションへの変更は、 にある Washington DCすべてのインスタンスに適用されます。
Proactive Service Experience Workflows	トラブルチケット通知を受信したくないお客様は、インシデントテーブルとケーステーブルに関連するビジネスルールを無効にすることができます。トラブルチケット通知のビジネスルールを無効にする方法の詳細については、「」を参照してください Deactivate trouble ticket notification。
Public Sector Digital Services	アップグレード後、CSM 構成可能ワークスペース 内の特定の公共部門メニューおよびメニューアイテムは、元の CSM ラベル名に戻ります。公共部門用のこれらのアイテムに再レベル付けするには、顧客およびサービス組織の UX リストカテゴリを更新します。再ラベル付けの詳細については、 すべて > 構成員サービス > 管理 > Guided Setupをクリックし、 Public Sector Digital Services の構成可能ワークスペース > ワークスペースラベルを手動でカスタマイズします。.
Robotic Process Automation (RPA) Hub	RPA アプリケーションをダウンロードして、次の Microsoft ソフトウェアインストーラー (MSI) のいずれかをアップグレードしてください。 RPA デスクトップデザインスタジオ アテンド型ロボット 無人ロボット 無人ロボット ログインエージェント 詳細については、「Download the RPA applications from RPA Hub (RPA ハブからの RPA アプリケーションのダウンロード)」を参照してください。 次のアップグレード手順は、San Diego または Tokyo から Washington DC にアップグレードする場合にのみ適用されます。 アプリケーションファイルテーブルのレコード数に基づいて、RPA Hub アプリケーションを Tokyo 以前から Washington DC にアップグレードする際に遅延が発生する可能性があります。 RPA Hub を Washington DC にアップグレードする前に、glide.rollback.blacklist.TableParentChange.change システムプロパティの値を [false] に設定する必要があります。このプロパティがシステムプロパティ [sys_properties] テーブルに存在しない場合は、プロパティを追加し、その値を false に設定します。プロパティの追加方法の詳細については、「」を参照してください Add a system property。 にアップグレード Washington DCすると、ボットプロセス定義が新しい構造 (ボットプロセス構成) に変更されます。 ボットプロセス構成がボットプロセスを完全に置き換えるわけではありませんが、ほとんどのフィールドはボットプロセスからボットプロセス構成に移動されます。システムプロパティ値を更新せずに Utah バージョンにアップグレードすると、テーブルは [アプリケーションファイル] テーブルを拡張しません。テーブルの変更を手動で更新するには、ナレッジベースの記事「 Restructuring RPA Hub tables to sys_metadata in Utah (Utah で RPA Hub テーブルの再構築 )」を参照してください Now Support 。
Service Operations Workspace for IT Service Management	次のアプリケーションに互換性のあるアップグレードバージョンが存在することを確認します。 サービスオペレーションワークスペース ITSM Applications アプリケーション (sn_sow_itsm_cont) サービスオペレーションワークスペース ITOM Applications アプリケーション (sn_sow_itom_cont) 表 : 1. 互換性のある SOW バージョン SOW-ITSM (sn_sow_itsm_cont) SOW-ITOM (sn_sow_itom_cont) 1.1.x 21.0.y 1.2.x 21.1.y 1.3.x 21.2.y、21.5.y、および 21.6.y 2.0.x 22.0.y 2.1.x 22.1.y および 22.y.y 3.1.x 23.y.y 4.0.x 24.y.y この表で、x はアプリケーションアプリケーション (sn_sow_itsm_cont) のサブバージョン、y はアプリケーションアプリケーション (sn_sow_itom_cont) のサービスオペレーションワークスペース ITSMサービスオペレーションワークスペース ITOMサブバージョンです。 3.0 のアップグレード後、この機能は 推奨フレームワーク 使用できなくなります。代わりに、機能の標準バージョン Recommended Actions for ITSM のみを使用できます。
Service Portal	アップグレード後に、テーブル入力パラメーターを受け入れる公開ウィジェットのデータにゲストユーザーがアクセスできるテーブルを指定する必要があります。リリースの Washington DC デフォルトでは、テーブル入力パラメーターを受け入れる公開ウィジェットは、ゲストユーザーのテーブルにアクセスしてデータを返すことはできません。アップグレード前に またはglide.service_portal.widget.allow_listシステムプロパティを追加glide.service_portal.widget.table_allow_listした場合、これらのプロパティの値は、アップグレード後にウィジェットの公開テーブル許可リストに移行されます。詳細については、「Configure widget security」を参照してください。 ユーザーが以前に、プラットフォームの他の部分とは異なるポータルの User Experience Analytics のユーザーの同意設定を選択した場合、プラットフォーム用に選択された設定はリリースのポータル Washington DC にも使用されます。たとえば、ユーザーがポータルの追跡をオプトアウトし、リリースでは Vancouver プラットフォームの残りの部分の追跡をオプトインした場合、ポータルのユーザーエクスペリエンス分析はリリースで Washington DC 追跡されます。ユーザーは、ポータルのユーザープロファイルページからいつでも選択内容を更新できます。
Software Asset Management	にWashington DCアップグレードした後は、インスタンスに関連するAdobeすべてのカスタマイズやMicrosoft 365インスタンスとServiceNowの統合をやり直す必要があります。これらの統合の機能はストアSaaS ライセンス管理アプリケーションに移動するソフトウェア資産管理ためです。 影響を受けるファイルをカスタマイズした場合、アップグレードプロセスはファイルをスキップし、競合を示します。競合を手動で解決し、古い既存のファイルが削除されていることを確認する必要があります。 影響を受けるファイルをカスタマイズしていない場合、ファイルはアップグレードの一部として削除され、新しいsys_idを含むファイルが作成されます。
Strategic Planning	v4.0.2以降、ワークスペースSPMでのみ戦略的計画()プロライセンス機能にアクセスできます戦略的ポートフォリオ管理 (SPM)。Pro ライセンスを所有し SPM ていても、Workspace で SPMポートフォリオ計画 Pro ライセンスの機能 (目標、製品フィードバック、ハイブリッドポートフォリオ計画、追加レンズなど) を引き続き使用している場合は、そのような機能にアクセスするには をインストールする 戦略的計画 必要があります。ワークスペースでのみ 戦略的計画 アクセスできる機能の詳細については、「 Portfolio Planning と Strategic Planning の比較」を参照してください。
サプライヤーライフサイクルオペレーション	このリリースからリリースにVancouverWashington DCアップグレードすると、[All] ナビゲーションタブのみSource-to-Pay ワークスペースが表示されます。を引き続き使用すること Source-to-Pay ワークスペースを選択した場合は、何もする必要はありません。 ただし、[ワークスペース] タブには と サプライヤー管理ワークスペース の両方Source-to-Pay ワークスペースが表示されます。デフォルトの代わりにを使用する場合はサプライヤー管理ワークスペース、リリースにWashington DCアップグレードした後に fixscript_migrate_workspace_to_smw.xml 修正スクリプトを実行してください。Source-to-Pay ワークスペースfixscript_migrate_workspace_to_smw.xml ファイルは、からServiceNow Storeダウンロードできます。修正スクリプトの実行方法の詳細については、以下を参照してください Run fix scripts。 を再び使用する場合 Source-to-Pay ワークスペースは、 fixscript_migrate_workspace_to_s2p.xml 修正スクリプトを実行します。fixscript_migrate_workspace_to_smw.xml ファイルは、からServiceNow Storeダウンロードできます。修正スクリプトの実行方法の詳細については、以下を参照してください Run fix scripts。
UI ビルダー	に Washington DCアップグレードした後、 UI ビルダー からアプリケーション ServiceNow Storeを更新します。
ユーザーエクスペリエンス分析	ユーザーは基本追跡をオプトアウトできます。 データソースでは ユーザーエクスペリエンスアナリティクス 、じょうごグラフのデータビジュアル化を使用できます。
Vulnerability Response integrations	アプリケーションのリリース済みバージョン脆弱性対応、およびそのリリースと互換性のあるWashington DCサードパーティおよびServiceNowアプリケーションの詳細については、ナレッジベースの記事Now Support「Vulnerability Response 互換性マトリクスおよびリリーススキーマの変更 [KB0856498]」を参照してください。 の 脆弱性対応新機能については、「」を参照してください 脆弱性対応 リリースノート。