ServiceNow 統合のセットアップ

最終更新日: 21 年 2023 月 XNUMX 日

ServiceNow (SN) と LM Dexda 間のデータ同期のために LogicMonitor Data Exchange (LMDX) 統合アプリケーションをインストールして構成する方法を次に示します。 アプリケーションには、LM Dexda と ServiceNow の間でインシデントと CMDB 情報を転送するためのデフォルトのマッピングがあります。 ServiceNow 内の任意のテーブルとデータを同期するようにアプリケーションを構成することもできます。 LMDX は、ドメインで分離されたインスタンスもサポートしています。 ドメイン分離のサポート.

ServiceNow の問題に関する通知を受け取ることができ、リンクから LM Dexda の情報にアクセスして問題を調査できます。 インサイトの詳細を確認し、関連するアラートと問題の種類を確認して、それらが関連付けられた理由を理解できます。 LM Dexda の問題を調査する方法については、次を参照してください。 データの探索.

要件

構成を開始する前に、次のものが揃っていることを確認してください。

  • 「管理者」ロールを持つ ServiceNow ユーザー アカウント。 LMDX は変更を更新セットに保存するため、これは LMDX アプリケーションを構成するために必要です。
  • LogicMonitor が API にアクセスできるようにするための ServiceNow ユーザー アカウント。 これを行うには、アカウントに x_lomo_dx.api_user アプリケーションのインストールに付属する役割。 アカウントの「Web サービス アクセスのみ」設定を安全に有効にすることができます。
  • LM Dexda 管理者によって提供される LM Dexda API エンドポイントとトークン。 詳細については、「」を参照してください。 APIトークン.

インストールと構成

データ同期は、ServiceNow の LMDX 構成レコードを使用して制御されます。 の 構成 (x_lomo_dx_config) record は、LMDX アプリケーションを使用してどのテーブルを同期するように設定するかを決定するメイン テーブルです。

統合には、次の完全に機能する (デフォルトでは非アクティブ) 構成レコードが付属しています。

  • インシデント (LMDXDefaultInc)— との同期を管理します。 incident ServiceNow のテーブル。
  • CMDB (LMDXデフォルトCmdb)— との同期を管理します。 cmdb_ci ServiceNow のテーブル (送信のみ)。

LMDX で作成されたインシデント テーブルの既定の構成には、次の関連するアーティファクトが含まれています。

  • ビジネスルール—LMDXDefaultInc sync & LMDXDefaultCmdb sync、いつ実行するかを定義します。
  • セット テーブルのインポート - LMDXDefaultInc (x_lomo_dx_incident) 関連するフィールドで、 Inbound 変換マップ   フィールドマップ & 変換スクリプト (LMDXDefaultInc のみ)。
  • アウトバウンド変換マップ & フィールドマップ.

これらの構成をそのまま使用することも、必要に応じて変更することもできます。

さらに、必要に応じて、独自の構成レコードを作成して他のテーブルを同期することもできます。 既存のものを使用できる 入射 (LMDXDefaultInc) 他のテーブルの同期を設定するときの参照としての構成とアーティファクト。

注: LMDXは処理できます 外国行きの たとえば、データを LM Dexda にエクスポートします。 ただし、LMDX は次の処理をサポートしていません。 本国行きの ServiceNow の CMDB テーブルにレコードを追加します。 受信 CMDB レコード処理の場合は、LogicMonitor 用の Service Graph Connector または LogicMonitor CMDB 統合を使用します。

これらは次の場所にあります。 ServiceNow アプリ ストア.

アプリケーションのインストール

開始するには、LMDX アプリケーションを ServiceNow アプリ ストア 次に説明するように、組み込みの構成を完了します。

注: 組み込み構成はデフォルトでは非アクティブであり、アクティブにする必要があります。

構成プロパティの設定

LMDX を使用する前に、一連の認証プロパティを定義する必要があります。 アカウントの特定の値を取得するには、LM Dexda 管理者に問い合わせてください。

MFAデバイスに移動する  構成プロパティ 次のように値を追加します。

  •  x_lomo_dx.outbound.endpoint 現場で ドメイン分離サポート (x_lomo_dx.domainEnabled) が有効になっていない場合に使用する LMDX エンドポイント.
  • 値 x_lomo_dx.auth.apiKey 現場で ドメイン分離サポート (x_lomo_dx.domainEnabled) が有効になっていない場合に使用する LMDX API キー.

  LMDX 構成レコードのプロパティ 新しい構成レコードを作成するときに使用されます。 詳細については、「」を参照してください。 新しいテーブルのセットアップ.

デフォルト設定の完了

次の手順に従って、ServiceNow のデフォルト構成のセットアップとアクティブ化を完了します。

  1. 下のリストで  で、「インシデント (LMDX0001001)」など、構成を更新するレコードを選択します。
  2. ソフトウェア設定ページで、下図のように 外国行きの タブで、次の説明に従って値を入力します。
  • 調子- 送信ペイロードの作成に条件を追加して、条件に一致するレコードのみが処理の対象となるようにすることができます。
  • トリガーフィールド- レコード上のすべての変更を送信したくない場合があるため、リストされたフィールドのいずれかが変更された場合にのみ、ペイロードが LMDX に送信されるようにトリガーするフィールドのリスト。 フィールド内のすべての変更が考慮されます。 フィールド内の特定の値をフィルター処理する場合は、[条件] フィールドを使用します。 対象となる一般的なトリガー フィールドは、「状態」と「構成項目」です。
  • レコードタイプ- 値 (文字列) は、選択したテーブルによって異なります (たとえば、インシデント テーブルの場合は「sncIncident」)。 特定のテーブルのこのフィールドに何を入力するかについては、LM Dexda 管理者に問い合わせてください。
  • - ペイロードを LMDX に送信する方法を定義します。 オプション:
    • 増分- ペイロードは生成されるとすぐに送信されます。 インシデントなどのタスク的な記録におすすめです。
    • バッチ- ペイロードはバッチで定期的に送信されます。 CMDB などのデータ レコードに推奨されます。 詳細については、「」を参照してください。 バッチ ペイロードの送信.
  • LMDX で作成されたレコードのみを送信する- LMDX によって作成されたレコードのみを同期する場合は、これを選択します。 つまり、特定のユーザーによって作成または更新されるレコードに依存する条件を設定する必要はありません。 この設定は主にインシデントなどのタスクのようなレコードを対象としており、バッチ レコードと組み合わせて使用​​することはできません。
  1. アクティブ- 設定を有効にする場合は、このオプションをオンにします。 これにより、関連するビジネス ルール、変換マップ、およびアウトバウンド変換マップとともに構成レコードがアクティブ化されます。
  2. 選択 アップデイト 構成レコードを保存します。

バッチ ペイロードの送信

    この設定は、ペイロードが生成されるタイミングには影響しませんが、ペイロードが LMDX によって LM Dexda に送信されるタイミングには影響します。 「有効な」レコードで変更が検出されるとすぐに、すべてのペイロードが生成されます。 これは、テーブルの関連するビジネス ルールを通じて、条件およびトリガー フィールドで指定されます。 増分ペイロードは生成されるとすぐに送信されますが、バッチ ペイロードは定期的に送信されます。 「バッチ」ペイロード タイプは、「cmdb_ci」などのバックグラウンド データ レコードに使用することを目的としています。

バッチ ペイロードを送信するには、 LMDX – バッチ アウトバウンド ペイロードの処理 ジョブをスケジュールし、繰り返し間隔を設定します。 最小繰り返し間隔は 5 分以上にすることをお勧めします。 バッチ ペイロードはマージされるため、繰り返し間隔内でレコードに複数の変更があった場合でも、最新の値を含む XNUMX つのペイロードのみが送信されます。

新しいテーブルのセットアップ

デフォルトの構成が特定のユースケースの要件をサポートしていない場合は、同期用に新しいテーブルをセットアップできます。 LMDX を介してこれを行うには、最初に新しい構成レコードを作成する必要があります。 デフォルトでは、次のテーブル (およびその子) のみが新しい構成レコードのドロップダウンから選択できます。

  • 仕事 (task)
  • 構成項目 (cmdb_ci)
  • 資産 (alm_asset)

ドロップダウンに含める他のテーブルを指定するには、 x_lomo_dx.internal.tableWhitelist LMDX Config レコードのプロパティ セクションにあるシステム プロパティ。 このプロパティには、同期する他のテーブル (カスタム テーブルを含む) の名前 (ラベルではなく) を入力できます。

システム プロパティを設定し、インスタンスでスクリプトを XNUMX 回実行することにより、LMDX でアーティファクトを自動的に作成することができます。 新しい構成レコードを作成するたびに、アーティファクトを手動で作成することもできます。 以下では、両方の方法について説明します。

新しい構成レコードの作成

MFAデバイスに移動する    をクリックして 新作. の説明に従って構成値を追加します。 インシデント構成の完了.

アーティファクトの自動作成

次の手順に従って、新しい構成レコードの作成後に LMDX がアーティファクトを自動的に作成できるようにします。

手順 1. グローバル テーブル スクリプトを実行する

「修正」スクリプトまたは「バックグラウンド」スクリプトとして、インスタンスで次のスクリプトを実行します。

注: スクリプトは、スコープ アプリケーションの一部としてではなく、グローバル スコープで実行する必要があるため、アプリケーションに追加することはできません。

function update(tableName){
  var updateGR = new GlideRecord('sys_db_object');
  updateGR.setWorkflow(false);
  updateGR.get('name', tableName);
  updateGR.setValue('create_access', true);
  updateGR.setValue('update_access', true);
  updateGR.setValue('delete_access', true);
  updateGR.update();
  GlideTableManager.invalidateTable(tableName);
  GlideCacheManager.flushTable(tableName);
}
update('sys_db_object');
update('sys_dictionary');
update('sys_transform_map');
update('sys_transform_entry');
update('sys_transform_script');
update('sys_script');

このスクリプトは、次のテーブルの「作成可能」、「更新可能」、および「削除可能」チェックボックスを選択します。

  • テーブル類 (sys_db_object)
  • 辞書 (sys_dictionary)
  • テーブル変換マップ (sys_transform_map)
  • フィールドマップ (sys_transform_entry)
  • 変換スクリプト (sys_transform_entry)
  • ビジネスルール (sys_script)

これにより、アプリケーションはアプリケーション スコープ内からこれらのテーブルのレコードを作成、更新、および削除できます。

注: GlideTableManager 関数と GlideCacheManager 関数を呼び出すとテーブル キャッシュがリセットされ、新しく更新された値がすべてのノード インスタンスで使用されるようになります。 これらの呼び出しが行われない場合、すべてのノード インスタンスにわたってセキュリティ ルールが更新されないため、自動作成が失敗する可能性があります。 詳細については、「 ServiceNow のドキュメント.

ステップ 2.構成プロパティーの更新

スクリプトを実行したら、次の操作を行います。

  • MFAデバイスに移動する  構成プロパティ.
  • のチェックボックスを選択します true に設定すると、関連するアーティファクトを自動作成しようとします。.
  • 選択 Save.

これにより、 x_lomo_dx.config.artefactAutoCreation プロパティを「true」に設定します (デフォルトでは false)。

注: ステップ 1 でスクリプトを実行した場合でも、成果物が自動的に作成されるようにするには、このシステム プロパティを「true」に設定する必要があります。 これらの条件がすべて満たされている場合、アーティファクトはアプリケーション スコープ内のフローを通じて作成されます。 システム プロパティが「true」に設定されていても、スクリプトが実行されていない場合、フローはアーティファクトを作成しません。

LMDX は、新しい構成レコードが作成されるたびに、選択したテーブルに新しいビジネス ルール レコードを作成するようになります。

選択したテーブルが CMDB 階層の一部でない場合、LMDX は以下も作成します。

  • インポート セット行を拡張する新しいテーブル (sys_import_set_row).
  • 新しいテーブルの次のディクショナリ レコード (LMDX 処理目的で使用):
    • 合体型
    • 外部参照
  • 新しいテーブルの新しいテーブル変換マップ。
  • のフィールドマップ sys_id フィールド。
  • An onAfter 変換スクリプト (LMDX 処理の目的で使用)。

アーティファクトの手動作成

インスタンスでスクリプトを実行したくない場合は、新しいテーブルへのデータ同期に必要なアーティファクトを手動で作成できます。 新しい構成レコードが作成されるたびに、アウトバウンド変換マップは常に自動的に作成されます。

アーティファクトの作成を開始する前に、次のことを行います。

  • のチェックボックスがオンになっていることを確認します。 true に設定すると、関連するアーティファクトを自動作成しようとします… on 構成プロパティ が選択解除されます。 システム プロパティ x_lomo_dx.config.artefactAutoCreation その後、アーティファクトが手動で作成されることを示す「false」に設定されます。
  • LogicMonitor Data Exchange 内でアーティファクトを作成していることを確認します (x_lomo_dx) 適用範囲。

インバウンド成果物

注: これは、CMDB 階層内のどのテーブルにも必要ありません。

次の手順に従ってアーティファクトを作成します。

  1. 新しいを作成します セット テーブルのインポート インポート セット行の拡張 (sys_import_set_row) LMDX スコープ内。
  2. 新しいを作成します インバウンド変換マップ LMDX スコープ内。
  3. 創造する coalesce_type & external_reference 新しいの文字列フィールド セット テーブルのインポート.
  4. 作る sys_id 新しいフィールドマップ インバウンド変換マップ、「合体」に設定し、既存のスクリプトからスクリプトをコピーします sys_id 既存のインシデント変換マップからのフィールド マップ。
  5. 作る onAfter スクリプトを変換してコピー onAfter 既存のインシデント変換マップからスクリプトを変換します。

アウトバウンド アーティファクト

作る ビジネスルール 既存の「LMDXDefaultInc Sync」を 入射 テーブルを SN テーブルに。

注: インバウンドおよびアウトバウンド アーティファクトの作成が完了したら、参照フィールドを使用して、それらを新しく作成した LMDX 構成レコードに関連付ける必要があります。

アーティファクトの作成後

新しいフィールドに新しいフィールドを追加できるようになりました セット テーブルのインポート、および新しいフィールド マップ 変換マップ インバウンド処理用。 また、アウトバウンド フィールド マップを アウトバウンド変換マップ アウトバウンド処理用。

送信変換マップ

送信変換マップは、ServiceNow 変換マップと同じように機能します。 これらを使用すると、特定のレコードのどのフィールドを ServiceNow から LogicMonitor に送信するかを構成できます。 フィールドは、ServiceNow フィールド マップと同様に、送信フィールド マップを使用して指定されます。

アウトバウンド フィールド マップの機能

アウトバウンド フィールド マップの次の機能は、LogicMonitor 統合に固有です。

  • 値型- ユーザー インターフェイスに表示される値とともに基礎となる値を持つフィールドで使用できます。 これは、フィールドが「実際の」値を送信する必要があるかどうかを示します(たとえば、 sys_id 参照フィールドの場合)、「表示値」(参照フィールドに表示される値)、または両方の値。

    「両方」を選択すると、「実際の」値を含む「_fv」の接尾辞を持つフィールドとともに、「表示」値がフィールドの値に設定されます。

  • 操作タイプ- フィールドが特定のレコード操作タイプに対して送信されるかどうかを示します。 たとえば、フィールドは、レコードが挿入、更新、またはその両方が行われた場合にのみ送信される必要があります。

アウトバウンド フィールド マップでのスクリプト作成

ServiceNow のフィールド マップと同様に、送信フィールド マップは変換プロセス中にスクリプトを実行できます。 の中に アウトバウンド フィールド マップ フォームで、 スクリプトを使用 を表示するチェックボックス スクリプト フィールドと関連する フィールド名.

にスクリプトを追加する場合 スクリプト フィールドでは、次の変数を使用できます。

  • 現在-a GlideRecord アウトバウンド変換によって処理されているレコードの。 ビジネス ルールと同じ現在のオブジェクト。
  • 無視する- フィールドを無視するかどうかを示すブール値。 この値を返す必要はありません。

スクリプト フィールドを使用するには、次の例に示すように値を返す必要があります。 または、「無視」を「true」に設定することもできます。

注: スクリプト化されているかどうかに関係なく、すべてのアウトバウンド フィールド マップにわたって、フィールド名がアウトバウンド変換マップ内で一意であることを確認するための検証が行われます。 これは、データ形式として JSON が使用されているためです。 したがって、キーは最新の値を上書きするため、重複したキーを持つことはできません。 重複するフィールド名を入力すると、エラーが返され、アクションが中止されます。

ことを確認するための検証もあります。 GlideRecord.insert() & .update() で使用されていません スクリプト 分野。 これは、このスクリプトを使用してレコードを挿入または変更すると、論理データ フローに影響を与える可能性があるためです。

ペイロード表

LMDX は、着信 (インバウンド) および発信 (アウトバウンド) のすべてのペイロードをキャプチャします。 これにより、インスタンスから送受信される情報、ペイロードの順次処理、およびエラーの回復を簡単に確認できます。

自動再試行ポリシー

外国行きの ペイロードには自動再試行ポリシーがあります。 特定の HTTP 応答ステータス コードが検出されると、ペイロードの再試行が自動的に 3 回試行されます。 ペイロードの送信が 3 回試行された場合、または特定の HTTP 応答ステータス コードが検出された場合、ペイロードは **エラー** 手動での再試行を待っている状態。

本国行きの ペイロードには自動再試行ポリシーがありません。 これは、インバウンド ペイロードのエラーまたは警告は、ServiceNow 管理者が手動で解決する必要があるためです。 したがって、受信ペイロードには順次処理機能があります。

手動再試行ポリシー

インバウンドとアウトバウンドの両方のペイロードで、手動による再試行が可能です。

本国行きの ペイロードのステータスが「エラー」または「完了(警告あり)」の場合、ペイロードには「再処理」ボタンが表示されます。 手動再試行では、該当する場合、受信ペイロードの順次処理が実行されます。

外国行きの ペイロードは リトライ 特定の HTTP 応答ステータス コードが検出された場合、またはペイロードが 3 回試行された場合は、ボタンをクリックします。

インバウンド・ペイロードの順次処理

LMDX には、受信ペイロードの順次処理機能があります。 インバウンド ペイロードの処理中にエラーまたは警告が発生した場合、新しいインバウンド ペイロードは同じ 外部参照 (external_reference) 値は、同じ警告またはエラーを自動的に想定します。

警告またはエラーの根本原因が解決されると、同じペイロードで任意のペイロードを使用できるようになります。 外部参照 すべての既存のペイロードを順番に再処理する値。 これは、 作成日 (sys_created_on) 各ペイロードの値。 これにより、ServiceNow が LM Dexda から受信したのと同じ順序ですべてのペイロードが処理されます。

ペイロード レコードの削除

ペイロード レコードは、組み込みの ServiceNow のテーブル クリーナー機能。 デフォルトでは、アプリケーションは 2 日前に更新されたペイロードを削除するように設定されており、ステータスは受信ペイロードの場合は「完了」、送信ペイロードの場合は「送信済み」になります。 このしきい値は必要に応じて変更できます。 ただし、テーブル内のレコードが蓄積されるとパフォーマンスの問題が発生する可能性があるため、長すぎないことをお勧めします。

エラーまたは警告を回復できるように、「エラー」状態のペイロードやステータス「完了 (警告あり)」の受信ペイロードは自動的に削除されません。

トラブルシューティング

LMDX には、特定の領域のデバッグ メッセージをオンにできる一連のシステム プロパティがあります。 ServiceNow のすべてのデバッグ プロパティは、次の場所にあります。 開発者のデバッグ.

プロパティ名説明
x_lomo_dx.inbound.logLevelインバウンド HTTP 要求。
x_lomo_dx.payload.inbound.logLevel受信ペイロード処理。
x_lomo_dx.coalesce.logLevel変換マップ合体。
x_lomo_dx.internal.logLevelServiceNow アプリケーションの構成 (参照修飾子やクライアント スクリプトなど)。
x_lomo_dx.payload.outbound.logLevel送信ペイロード処理。
x_lomo_dx.outbound.auth.logLevelLM デクスダ認証。
x_lomo_dx.outbound.logLevelアウトバウンド HTTP 要求。
x_lomo_dx.debug全体的なデバッグ スイッチ。 これは、エラーの原因となっている領域がわからない場合にのみ使用してください。

推奨事項: すべてのロギング メッセージのメッセージ本文には、 作成した 分野。 フィルタリング ビデオメッセージ 最新のメッセージを最初に取得するために、アプリケーション ログを参照するときにフィールドを降順で表示します。

記事上で