送信通知にプロデューサーフレームワークを使用する

  • リリースバージョン: Australia
  • 更新日 2026年03月12日
  • 所要時間：4分

    • プロデューサーフレームワークは、 ServiceNow インスタンスからイベントを選択し、送信通知を外部システムに送信します。外部システムにインストールされているメッセージングサービスから通知の詳細を取り込むことができます。

    システムプロパティ

    送信通知にプロデューサーフレームワークを使用するように、システムプロパティを設定する必要があります。次の表では、スケジュール済みジョブに設定されているシステムプロパティのリストについて説明します。

    表 : 1. プロデューサーフレームワークのシステムプロパティ
    財産 説明 タイプ
    sn_api_notif_mgmt.event.log
    デバッグログに書き込まれるログのレベル。次のログ記録レベルを選択できます。
    • emerg:完全な障害。
    • alert:たとえば、データベースのシステム破損です。
    • crit:通常、ハードウェアエラーなどに使用されます。
    • err:エラー。
    • 警告:警告
    • 注意:アクションが必要な場合がありますが、必須ではありません。
    • 情報:アクションは要求されません。
    • debug: 一般的には、障害検出のためにすべてをキャプチャする以外には使用されません。

    デフォルト値: err

    		 文字列
    sn_api_notif_mgmt.publisher_message_bus_configuration Hermes Messaging Service、Open Message Bus、または両方のメッセージバスを使用してメッセージを公開するかどうかを定義します。次の値を使用できます。
    • openMessageBus
    • エルメス
    • both

    デフォルト値: openMessageBus

    		 文字列
    sn_api_notif_mgmt.inboundqueue.maxrecords 1 回のスケジューラー実行に対してスケジューラーが受信キューからプルするレコードの最大数。この値は、 sn_api_notif_mgmt.inboundqueue.batch.limit パラメーターと組み合わせて使用します。
    • デフォルト値: 200
    • 使用可能なその他の値：必要に応じて

    たとえば、バッチ制限が 50 に設定され、maxrecords が 200 に設定されていて、受信キューにあるレコードの数が 130 の場合、スケジューラーは 1 回の実行で 3 つの異なるレコードバッチをプルします。2 つは 50 レコード、もう 1 つは 30 レコードです。受信キューのレコード数が 220 の場合、スケジューラーは 50 レコードの 4 つのバッチをプルし、残りの 20 レコードは次にスケジューラーが実行されるまで処理されません。

    この値を設定するときは、スケジューラーが複数のバッチを処理するのにかかる時間も考慮し、それに応じて sn_api_notif_mgmt.schedule.max.runtime 値を設定する必要があります。

    		 整数
    sn_api_notif_mgmt.inboundqueue.batch.limit スケジューラーが受信キューから 1 つのバッチでプルして処理するレコードの数。
    • デフォルト値: 200
    • 使用可能なその他の値：必要に応じて
    		 整数
    sn_api_notif_mgmt.glide.mutex.script.maxspins 受信キューレコードでミューテックスロックを取得する最大試行回数。
    • タイプ: 整数
    • デフォルト値：100
    • 使用可能なその他の値：必要に応じて
    		 整数
    sn_api_notif_mgmt.schedule.max.runtime スケジュール済みジョブが失敗してエラーを報告するまでに実行できる最大時間 (ミリ秒)。
    • タイプ: 整数
    • デフォルト値: 90000
    • 使用可能なその他の値：必要に応じて
    		 整数
    sn_api_notif_mgmt.glide.mutex.script.spinwait 受信キュー内のレコードのミューテックスロックの取得試行間で待機する最大時間 (ミリ秒)。
    • タイプ: 整数
    • デフォルト値：100
    • 使用可能なその他の値：必要に応じて
    		 整数

    プロデューサーフレームワークワークフロー

    システムがイベントをステージングテーブルにプッシュすると プロデューサーフレームワークメカニズムの一部として、次のステップが実行されます。
    1. スケジューラーは、事前に設定された間隔で多数のレコードを選択し、Glide スナップショットをイベントプロセッサーに送信します。
    2. イベントタイプに基づいて、Glide スナップショットが TMF 688 苦情イベントペイロードに変換されます。

      トラブルチケットイベントの TMF 準拠のペイロードを定義および生成するために使用される方法の詳細については、「 TopicAPIUtilsOOB - Scoped」を参照してください。

    3. 通知構成が Hermes Kafka 向けかオープンメッセージバス用かがチェックされます。

      プロデューサーイベント通知フレームワークの構成の詳細については、「 Producer Event Notification Framework developer guide」を参照してください。