ECC Queue テーブルレコードの処理方法: Output Ready から Input Processed までSummary<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } 目次 1.ジョブが Output Queue に追加される2.MID サーバー (またはインスタンスコード) がジョブを取得します3.MID サーバーは、ジョブを取得したことをインスタンスに通知します4.MID サーバーがジョブを実行します5.MID サーバーが結果をインスタンスに返します6.センサーがインスタンスで実行される例 例 1 - ハートビートプローブ例 2 - 同期 RESTMessagev2例 3 - ディスカバリーセンサーデバッグ 1.ジョブが Output Queue に追加される 機能またはアプリケーションが ECC Queue を使用する統合を実行するため、ecc_queue テーブルに insert を実行します。 Brazil/Australia パッチ 4/Zurich パッチ 11 以降、「ECC キュー認証ポリシー」コードが追加され、これが learning mode のままである間、ECC Queue に入るすべてのものに対して ecc_queue_authorization_policy レコードが自動生成されることをお客様は確認できます。オンにすると (当面はオプションですが) これにより、特定のタイプのジョブを ECC キューに挿入できるアプリケーションが制御されます。すべての標準アプリは、Australia Patch 8 および Brazil Patch 2 までにこれらのポリシーレコードを含んでいるはずです。顧客とサードパーティは、独自の統合とアプリ用にこれらのポリシーレコードを生成することが期待されます。 ディスカバリーの観点からのフィールドの説明については、 MID Server ECC Queue のドキュメントを参照してください。より一般的には、次のことを意味します。 Agent ジョブを実行するもの。エージェントの値が「mid.server.」で始まる場合、インスタンスを意味する「mid.server.NODE_AGENT」でない限り、MID サーバー用のジョブです。たとえば、NODE_AGENT値は、インスタンスが直接要求を実行する場合に RESTProbe によって使用されます。 エージェントが「mid.server.*」の場合、「プローブ - すべての MID」ビジネスルール (BR) は、個々の MID サーバーに固有のレコードのコピーを挿入します (ステータスに関係なく)。これは通常、すべての MID サーバーがインスタンスの変更と再同期する必要があるシステムコマンドでのみ使用されます。 Queue出力はジョブ、入力は インスタンスの観点からの結果です。 State Ready は、待機中/キューに格納されていることを意味します。Processed または Error はジョブが終了したことを意味します。その間は Processing です。ジョブはまだ MID サーバーの内部キューにある可能性があるため、ジョブが実際に実行が開始されているわけではありません。Topic ジョブに対して実行する「プローブ」。これは、ソースコード内の Java オブジェクトの名前に相当します。(「ディスカバリープローブ」名と混同しないでください) Name/Source トピックに固有ですが、通常は メインプローブパラメーターです。Payloadプローブの追加のプローブパラメーターXML 形式。ECC 出力パラメータも、結果およびエラーとともに ECC 入力に含まれます。Agent Correlatorセンサーが結果を元のものに渡すことができるように、 ジョブを作成したコード/タスク/スケジュールへの参照に役立ちます。 Priority 2=標準 (デフォルト)、1=Expedited、0=インタラクティブ。ほとんどすべてが標準を使用します。システムコマンド、またはユーザーが何かをクリックした後に応答を待っているコマンドのみが、より高い優先度を使用します。 Sequence キュー Order。Unix エポックのタイムスタンプと、同時に複数のレコードがある場合の数字を組み合わせたものなので、ミリ秒の解像度以内です。 Response To 入力の場合、これは対応する出力を参照します。 Processe State が Ready から Processing に変更された時間。出力の場合は、queue.processing 入力が挿入されたときです。入力の場合、センサーによって設定されますが、すべてのセンサーが設定するわけではありません。 2.MID サーバー (またはインスタンスコード) がジョブを取得します 注意:インスタンス自体がジョブを実行している場合、これらの MID サーバー固有の手順は関係ありません。 ジョブを取得するには、MID サーバーを Up and Validated する必要があります。 MID サーバーの AMB チャネルが機能している場合、MID サーバーはキューに何か新しいものがあることを即座に認識します。そうでない場合は、定期的な ECCQueueMonitor スレッドが実行されてチェックされます。 MID Server は app node の API_INT semaphores を介して通常の SOAP Table API を使用し、インスタンスの ecc_queue テーブルをクエリします。Output レコードを Agent として、Ready state で検索します。MID サーバーのスレッド数に比例して、一定数のみが一度にフェッチされます。MID の起動時に、Processing state の Output レコードの処理中に MID サーバーが停止し、再度実行する必要があることを前提として、Processing state の Output レコードのクエリーも行います。 最も優先度が高く、その中で最も古いレコードが最初にフェッチされます。 KB0743566 MID サーバーの最大スレッド数、ワーカーグループ、優先度、およびキュー :ECC Sender フォルダー、sys_trigger ジョブの優先度、一度にフェッチされる出力数の詳細が含まれます。 Brazil/Australia パッチ 4/Zurich パッチ 11 で追加された ECC キューファイアウォールコードを有効にすると、特定のアプリケーションで許可されていないプローブトピックが MID サーバーで実行されなくなります。MID サーバーを使用する各 ServiceNow、サードパーティ、または顧客アプリケーションは、ecc_agent_application内にあり、許可されるすべてのトピックをリストする必要があります。 3.MID サーバーは、ジョブを取得したことをインスタンスに通知します MID サーバーは、topic=queue.processing 入力を ecc_queue に書き込み、取得した内容をインスタンスに通知します。ペイロードは次のようになります。 <queue.processing output_message_count="1"><sys_id state="processing">2401af2c1b8b1010254542e7cc4bcb5b</sys_id></queue.processing> MID サーバーはバッチで新しいジョブを照会するため、これには複数のsys_idsが含まれる場合があります。その入力により、センサービジネスルール「ECC キュー - 出力ステータスをマーク」がトリガーされ、出力レコードが Ready state から Processing state に更新されます。 4.MID サーバーがジョブを実行します MID サーバーでは、出力は空きワーカースレッド (使用されるスレッドプールは優先度によって異なります) ができるまでメモリ内のキューに保持され、その後、トピック専用の Java プローブコードに渡され、スレッドで実行されます。 そのため、処理中ステータスとしてマークされたecc_queue出力は、実行中であることを意味するわけではありません。これは、MID サーバーの内部キューにあり、ある時点で実行されることを意味します。エージェントログエントリには、いつ実行されたかを確認するための ecc 出力レコードのsys_idが含まれます。このため、作成、処理、更新された出力レコードのタイムスタンプは待機時間と処理時間の把握を提供しますが、内部キューの待機時間のために正確ではありません。 ジョブの実行中に、コードが AMB/REST/SOAP を直接使用してインスタンス API に対して追加の呼び出しを行う場合がありますが、これは ECC キューを経由しない場合があります。たとえば、統合ハブの出力は単にフロー実行コンテキストを参照するだけで、プローブはインスタンスフロー API でそのコンテキストをクエリして、実際に実行するステップを把握する必要があります。 ジョブを実行しているスレッドはプローブの実行結果を、agent\work\monitors\ECCSender 内の ECC Sender 出力フォルダーの 1 つに XML ファイルに書き込みます。優先度または連続しているかどうかに応じて、いくつかのフォルダーがあります。これらのフォルダーは送信キューとして機能し、制限があります。 プローブは実行時に MID サーバーの agent/logs/agent0.log.0 ファイルにログを記録します。プローブパラメーターと MID サーバーパラメーターを追加すると、追加のデバッグがログに書き込まれます。各機能のプローブは、プローブパラメーターとログ記録のレベルが異なる可能性が高く、MID サーバーに mid.log.level parameter=debug を追加するだけでは不十分です。 エージェントログには、結果をディスクに書き込むときに「Worker starting」と「Worker completed」、およびEnqueuing と記録されます。スレッド名のsys_idはecc_queue出力レコードです。「time:」は、プローブが MID サーバーで実行された時間です。この例では、エンドポイントへの REST メッセージにかかったおおよその時間です。 02/14/23 18:38:37 (328) Worker-Expedited:MIDWorker-02aad4091b01e190d41b65fa234bcb18 Worker starting: RESTProbe source: https://a.b.com/x?x=z02/14/23 18:38:37 (598) Worker-Expedited:MIDWorker-02aad4091b01e190d41b65fa234bcb18 Enqueuing: /<install_folder>/agent/work/monitors/ECCSender/output_1/ecc_queue.02aad4091b01e190d41b65fa234bcb18.xml02/14/23 18:38:37 (599) Worker-Expedited:MIDWorker-02aad4091b01e190d41b65fa234bcb18 Worker completed: RESTProbe source: https://a.b.com/x?x=z time: 0:00:00.26802/14/23 18:38:38 (204) ECCSender.1 Sending ecc_queue.02aad4091b01e190d41b65fa234bcb18.xml 5.MID サーバーが結果をインスタンスに返します ECCSender スレッドは、XML ファイルごとに ECC キュー入力を挿入してから、XML ファイルを削除します。すべてのフォルダーが空になるまで、最も優先度の高いものが最初に送信され、そのうち最も古いものが最初に送信されます。 SOAP テーブル API は、SOAP メッセージを介してテーブルに挿入する他のインバウンド統合と同様に挿入に使用され (オーストラリアの場合)、API_INT セマフォで実行されます。インスタンスのトランザクションログには、次のように表示されます。 /ecc_queue.do?redirectSupported=true&SOAP&displayvalue=all 「ECC Queue - mark outputs processed」ビジネスルールは、挿入された入力レコードごとに実行され、出力レコードのステータスが処理済みに設定されます。Zurich 以降では、手順 3 で MID サーバーが出力を取得したときに設定されたタイムスタンプを置き換えるために、[処理済み] タイムスタンプも更新されます。 KB0743566 MID サーバーの最大スレッド数、ワーカーグループ、優先度、およびキュー :ECC Sender フォルダー、sys_trigger ジョブの優先度、一度にフェッチされる出力数の詳細が含まれます。 エージェントログには「ECCSender.1 Sending」と書き込まれます。ここで、一時ファイル名のsys_idはecc_queue出力レコードです。 02/14/23 18:38:38 (204) ECCSender.1 Sending ecc_queue.02aad4091b01e190d41b65fa234bcb18.xml ecc_queueレコードの挿入時に問題が発生した場合、appnodeのlocalhostログ（「/ecc_queue.do?SOAP」を処理するAPI_INT SOAPProcessorスレッド）およびMID Serverエージェントログ（ECCSenderスレッド）にエラーが記録されます。エラーの種類によっては、MID Serverが再試行を数回行い、再試行の間隔を段階的に延ばしながら（バックオフ）、最終的に処理を断念する場合があります。 エラーがインスタンス側の場合、XML ファイルは agent\work\monitors\ECCSender\output_error に移動されます。ペイロードが MID サーバーで許可されているサイズ (mid.eccq.max_payload_size) よりも大きい場合は、agent\work\monitors\ECCSender\output_oversize に移動されます。これらはインスタンスに送信されず、 MID ファイルクリーナーによって 30 日後に削除されます。 ビジネスルールは挿入に対して実行されますが、エラーが発生して挿入トランザクションが中断され、ステータス 500 が返される可能性があります。MID サーバーは、挿入の前または後にエラーが発生したかどうかを知らず、挿入が失敗したと見なし、複数の挿入につながる可能性があります。 6.センサーがインスタンスで実行される 入力レコードが挿入されるたびにビジネスルールが実行されます。これらは通常、API_INTセマフォ SOAP トランザクションの一部として、入力の前または後に同期されます。これらのビジネスルールの 1 つ (または複数) は、ジョブの「センサー」と呼ばれるものです。 これらは Order フィールドに従って実行され、レコード挿入時の他のビジネスルールと同様に条件に基づいてスキップされます。入力が自分のものであるかどうかを確認するために条件チェックを実行し、そうでない場合はレコードをそのまま残して、順番の次のBRが実行できるようにします。 次のリストは、ecc_queueビジネスルールをパッケージ別にグループ化したもので、特定のジョブのセンサーとして機能するものを確認するのに役立ちます。通常、条件フィールドを使用して、センサーがどのジョブに適しているかを簡単に確認できます。https://<インスタンス名>.service-now.com/sys_script_list.do?sysparm_query=collection%3Decc_queue%5Eactive%3Dtrue%5EGROUPBYsys_package ほとんどのセンサービジネスルールは、「1 回実行」sys_triggerレコードを挿入することで作業をスケジュール済みジョブに渡します。その後、バックグラウンドスケジューラーワーカースレッドが実際のセンサー処理を行うために取得して実行します。ディスカバリーの場合、これは ECC キューレコードから優先度を継承します。ビジネスルールが SOAP 挿入の一部として処理に多くの時間を費やすと、API_INT セマフォがブロックされるリスクがあります。アプリノードあたりの数個しかなく、それらを共有している MID サーバーが多数存在する可能性があるため、これは悪いことです。スケジューラーワーカーの優先順位を処理するのは特定のセンサーの仕事であり、機能/アプリごとに異なる方法で行うことができます。 特定のセンサーコードは通常、入力が開始されると入力を処理ステータスに設定し、終了するとエラーまたは処理済みになります。センサーは通常、エラー時に Error String フィールドに入力します。各機能/アプリは、センサーで異なる方法で行う場合があります。 ペイロードフィールドは、インスタンスの SOAP テーブル API が行う添付ファイルになる場合があります (glide.soapprocessor.large_field_patch_max を参照)。それに対処するのは、個々のセンサーの責任です。添付ファイルはシステムプロパティ com.glide.attachment.max_get_size よりも小さくする必要があります。ディスカバリーはすべてを 5MB 未満に抑えることを目的としていますが、他の機能はそうではない可能性があります。 出力ごとに常に 1 つの入力を期待する必要はありません。一部の機能では、大きな結果が複数の入力レコードに分割されます。インポートセットデータソースの JDBCProbe は、データの 200 行ごとに入力を個別の ecc_queue 入力に分割し、すべての入力が ECC キューに受信された後にのみ変換を続行します。このプローブはoutput_s ECCSender フォルダを使用するため、入力は順番にインスタンスに戻されます。ディスカバリーパターンでは複数ページの入力を使用でき、各データサブセット入力は通常、完全なデータセットを待たずに、受信時に処理されます。 入力用のセンサーがまったくない可能性があります。これらの入力は Ready state のままです。たとえば、RESTMessageV2 によって作成された RESTProbe 出力は同期的に実行され、結果/エラー処理がジョブを作成するのと同じスクリプトによって行われるため、多くの場合、センサー BR は必要ありません。通常、少なくともエラー処理を行うためには常にセンサーがあり、キューバックログの誤った印象を避けるために、センサーを Processed に設定する必要があります。 Discovery - Sensors BR は、ディスカバリーとは関係がない場合でも、通常は入力に対して実行されます。これはすべて、MID サーバーがディスカバリーの一部であり、ディスカバリーによってのみ使用されていた時代にさかのぼります。出力パラメーターに skip_sensor=true が含まれている限り、問題ありません。ディスカバリーセンサーはそれをスキップすることを認識しています。ディスカバリー以外のすべてのジョブにこれを含める必要がありますが、一部の OOTB 機能を含め、多くのジョブに含まれていません。入力にそのパラメーターがない場合、ディスカバリーセンサーはそれを処理しようとします。エラーが発生する可能性があります。たとえば、skip_sensorのない RESTProbe 入力は、"state=Error and Error string="No sensors defined"として設定されます。そのパラメーターはペイロードにあり、ペイロードは巨大であったり、添付ファイルでもあり、ディスカバリーセンサーはパラメーターを読み取るためにそれを処理する必要があります。それ自体に時間がかかったり、大量のメモリを使用したりする可能性があります。このセンサーがディスカバリー以外のジョブに対して実行されている場合、Agent Correlator フィールド値がこれらのレコードの 1 つに対してないため、アプリノードログに「存在しないレコードの取得:discovery_status:...、初期化中」と表示されることがわかります。 センサーは通常、エージェントコリレーターの値を使用して、ジョブを作成した特定のジョブ/レコード/ワークフロー/ディスカバリーステータスで結果が戻っていることを確認します。たとえば、オーケストレーションの値はすべて「rba.」で始まり、統合ハブは「ihub.」で始まります。 例 例 1 - ハートビートプローブ sys_triggerジョブ、BRセンサー。センサーがすべてを同期的に実行するという少し悪い例です - 実際の処理をsys_triggerジョブにオフロードしません。 初期スクリプト:スケジュール [sys_trigger]: MID サーバーモニターセンサービジネスルール:MID - ハートビート 例 2 - 同期 RESTMessagev2 インスタンスで同期的に実行され、応答を待機し、文字通りスリープ状態になり、プロセス内のスレッドがブロックされるという点で珍しいことです。 初期スクリプト:RESTMessagev2.execute() を呼び出す任意のカスタムスクリプトセンサービジネスルール:なし この場合、最初のスレッドはスリープ状態になり、ECC キューを定期的にポーリングします。スレッドのスタックトレースは次のようになります。 main,glide.scheduler.worker.4,4,<thread name - often a business rule or scheduled job name> (82899 ms)java.lang.Thread.sleep(Native Method)com.glide.ecc.ECCResponsePoller.poll(ECCResponsePoller.java:50)com.glide.rest.outbound.ecc.ECCRESTResponse.fetchAndProcessEccResponse(ECCRESTResponse.java:232)com.glide.rest.outbound.ecc.ECCRESTResponse.getBody(ECCRESTResponse.java:124) この例の詳細と、その理由については、以下を参照してください。KB0727028 Why is State "Error" and "No sensors defined" in the ECC Queue for outbound REST/SOAP Message via MID Server? - Expands on the skip_sensor parameter.KB0694711 Outbound REST Web Services RESTMessageV2 and SOAPMessageV2 execute() vs executeAsync() Best Practices KB0716391 Best practices for RESTMessageV2 and SOAPMessageV2PRB1305586 RESTMessageV2/SOAPMessageV2 APIs allow running via MID Servers Synchronously, without a Sensor ECC business rule, causing blocked instance threads while sleeping, and Scheduler overloadKB0749289 Synchronous Outbound Web Service Calls Timing Out After 30 seconds Following Upgrade 例 3 - ディスカバリーセンサー 初期スクリプト: Discovery 開始時の ShazzamLaunch、または前のディスカバリーセンサーによってトリガーされます。例:Windows - 分類センサーによって起動された Windows - Server パターン。センサービジネスルール:Discovery - Sensorssys_triggerジョブ:ASYNC: Discovery - MultiPage Sensors (注:Paris には、スレッドのトレースがはるかに簡単になるように、ecc_queue入力の名前、ソース、およびsys_idも含まれるようになりました) この例の詳細については、以下を参照してください。KB0718653 ECC Queue Processing and debugging, with "Discovery - Sensors" used as an example - ディスカバリーの例をより詳細に説明するために、ディスカバリーセンサーが具体的にどのように処理するかについて詳しく説明します。 デバッグ 上記は、プロセスのどの段階で問題が発生しているかを理解するのに役立ちます。問題が発生している「場所」が分かれば、解決への半分は達成したようなものです。次の KB が役に立ちます KB0718589 MID サーバー関連のジョブがスタックし、ECC キュー入力がまだ準備完了ステータスのままであるのはなぜですか? - センサー処理遅延の考えられる原因を示唆し、トラブルシューティングのヒントと解決策を提供します。KB0727132 - ECC キューレコードを特定の機能またはジョブにリンクする方法 - さまざまな機能で使用されるトピック/名前/ソース/エージェントコリレーター値とその意味を一覧表示します。 Related Links<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } 少なくともオーストラリアまでは既知の問題があり、プローブが 2 回実行される可能性があります。PRB2011363 MID Server will run the same probe twice, if it completes during a MID Server shutdown, when the result is prevented from being written to the ECCSender folder