送信通知用プロデューサフレームワークの使用

  • リリースバージョン: Zurich
  • 更新日 2025年07月31日
  • 所要時間：4分

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

    システムプロパティ

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

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

    デフォルト値: err

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

    デフォルト値: openMessageBus

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

    たとえば、バッチ制限が 50 に設定され、maxrecords が 200 に設定されていて、受信キューにあるレコードの数が 130 の場合、スケジューラは 1 回の実行で 3 つの異なるレコードバッチをプルします。50 レコードの 2 つと 30 レコードの 1 つ。受信キューのレコード数が 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」を参照してください。