ECC キューテーブルレコードの処理方法：出力準備完了から入力処理済みまで - Support and Troubleshooting

ECC キューテーブルレコードの処理方法：出力準備完了から入力処理済みまで Summary 1.ジョブが出力キューに追加 2.MID Server (またはインスタンスコード) がジョブを選択 3.MID Server がジョブを選択したことをインスタンスに通知 4.MID Server がジョブを実行 5.MID Server が結果をインスタンスに返す 6.センサーはインスタンスで実行 例 例 1 - ハートビートプローブ 例 2 - 同期 RESTMessagev2 例 3 - 検出センサー デバッグ 1.ジョブが出力キューに追加 機能またはアプリケーションが ECC キューを使用する統合を実行する必要があるため、ecc_queue テーブルへの挿入を実行します。Discovery の観点からのフィールドの説明については、 MID Server ECC キュー のドキュメントを参照してください。より一般的には、次のことを意味します。

エージェント ジョブを実行するもの。エージェント値が「mid.server」で始まる場合インスタンスを意味する「mid.server.NODE_AGENT」でない限り、MID Serverのジョブですたとえば、NODE_AGENT 値は、インスタンスが要求を直接実行する場合に RESTProbe によって使用されます。

エージェントが「mid.server.*」の場合、「プローブ - すべての MID」ビジネスルール (BR) は、(ステータスに関係なく) すべての個々の MID Server に固有のレコードのコピーを挿入します。これは通常、すべての MID Server がインスタンスの変更で再同期する必要があるシステムコマンドにのみ使用されます。

キュー 出力はジョブ、入力は結果、 インスタンスの観点から見た ものです。 ステータス 準備完了(Ready) は待機中/キューに格納されていることを意味します。 処理済みまたはエラー(Processed/Error) は、ジョブが終了したことを意味します。これらの間に 処理(Processing) があります。これは、ジョブがまだ MID Server の内部キューにある可能性があるため、ジョブが実際にまだ実行を開始したことを意味するものではありません。 トピック ジョブに対して実行される「 プローブ(Probe) 」は、ソースコード内の Java オブジェクトの名前に相当します。 (「検出プローブ(Discovery Probe)」名と混同しないでください)

名前/ソース トピックに固有ですが、通常は メインプローブパラメーター です。 ペイロード プローブの追加のプローブパラメーター 。XML 形式。ECC 出力パラメーターも、結果とエラーとともに EEC 入力に含まれます。 エージェントコリレーター ジョブを作成したコード/タスク/スケジュールを参照するのに役立つもの で、センサーが結果を元の Thing に戻すことができます。 優先度 2= 標準 (デフォルト) 、1= 迅速化、0= インタラクティブ。ほとんどすべてで Standard が使用されます。システムコマンド、またはユーザーが何かをクリックした後に応答を待っているもののみが、より高い優先度を使用します。 シーケンス キュー 順序 。これは、Unix エポックタイムスタンプと、同時に複数のレコードがある場合の数値 (ミリ秒の精度) の組み合わせです。 応答先 入力の場合、これは対応する出力を参照します。 処理日時 ステータスが準備完了(Ready) から処理中(Proessin)に変更された時間。 出力の場合は、queue.processing 入力が挿入されたときです。入力の場合、すべてのセンサーが設定するわけではなく、センサーによって設定されます。 2.MID Server (またはインスタンスコード) がジョブを選択 注意：インスタンスがジョブ自体を実行している場合、これらの MID Server 固有の手順は関与しません。

ジョブを取得するには、MID Server が 稼働し、 検証済みである必要があります。

MID Server の AMB チャネルが機能している場合、MID Server はキューに新しい何かがあることを即座に認識します。そうでない場合は、定期的な ECCQueueMonitor スレッドが実行されて確認されます。

MID Server は、アプリノードの API_INT セマフォを介して、通常の SOAP テーブル API を使用してインスタンス ecc_queue テーブルをクエリします。[エージェント] として [準備完了] ステータスの出力レコードを検索します。MID Server のスレッド数に比例して、一度に特定の数のみがフェッチされます。MID の起動時に、MID Server が処理中に停止し、それらを再度実行する必要があることを前提として、処理ステータスの出力も照会します。

優先度が最も高い最も古いレコードが最初にフェッチされます。

KB0743566 MID Server の最大スレッド、ワーカーグループ、優先度、およびキュー - ECC Sender フォルダー、sys_trigger ジョブの優先度、および一度にフェッチされる出力の数に詳細があります。

3.MID Server がジョブを選択したことをインスタンスに通知 MID Server は、トピック=キュー.処理入力を ecc_queue に書き込み、選択した内容をインスタンスに通知します。ペイロードは次のようになります。

2401af2c1b8b1010254542e7cc4bcb5b MID Server はバッチで新しいジョブをクエリーするため、これには複数の sys_id が含まれる場合があります。この入力により、センサービジネスルール「ECC Queue - mark outputs state」がトリガーされ、これらの出力レコードが [準備完了] ステータスから [処理中] ステータスに更新されます。

4.MID Server がジョブを実行 MID Server では、空きワーカースレッド (使用されるスレッドプールは優先度によって異なります) ができるまで、入力はメモリ内のキューに保持され、その後、トピック専用の Java プローブコードに渡され、スレッドで実行されます。

そのため、処理ステータスとしてマークされた ecc_queue 出力は、実行中であることを意味しません。現在 MID Server の内部キューにあり、ある時点で実行されることを意味します。エージェントログエントリには、いつ実行されたかを確認するための ecc 出力レコードの sys_id が含まれています。このため、作成、処理、および更新された出力レコードのタイムスタンプから待機時間と処理時間がわかりますが、その内部キュー待機時間のために正確ではありません。

ジョブの実行中に、コードは AMB/REST/SOAP を直接使用してインスタンス API への追加の呼び出しを行う場合があります。これは ECC キューを経由しない場合があります。たとえば、IntegrationHub の出力は単にフローデザイナーのコンテキストを参照するため、プローブはインスタンス内のそのコンテキストをクエリして、実行する実際のステップを知る必要があります。

ジョブ を実行しているスレッドは、agent\work\monitors\ECCSender のいずれかの ECC Sender 出力フォルダーにある XML ファイルにプローブの実行結果を書き込みます。優先度に応じて、または連続しているかどうかに応じて、複数のフォルダーがあります。これらのフォルダーは送信キューとして機能し、制限があります。

プローブは、実行時に MID Server の agent/logs/agent0.log.0 ファイルにログを記録します。プローブパラメーターと MID Server パラメーターを追加すると、追加のデバッグがログに書き込まれます。各機能のプローブにはさまざまなプローブパラメーターとログ記録レベルがあり、mid.log.level parameter=debug を MID Server に追加するだけでは不十分です。

エージェントログは、結果をディスクに書き込むときに、「ワーカー開始中」、「ワーカー完了」、および「エンキュー：」を書き込みます。ここで、スレッド名の sys_id は ecc_queue 出力レコードです。 「time:」は、MID Server でプローブが実行された時間です。この例では、エンドポイントへの REST メッセージにかかったおおよその時間です。

02/14/23 18:38:37 (328) Worker-Expedited:MIDWorker-02aad4091b01e190d41b65fa234bcb18 Worker starting: RESTProbe source: https://a.b.com/x?x=z 02/14/23 18:38:37 (598) Worker-Expedited:MIDWorker-02aad4091b01e190d41b65fa234bcb18 Enqueuing: / /agent/work/monitors/ECCSender/output_1/ecc_queue.02aad4091b01e190d41b65fa234bcb18.xml 02/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.268 02/14/23 18:38:38 (204) ECCSender.1 Sending ecc_queue.02aad4091b01e190d41b65fa234bcb18.xml 5.MID Server が結果をインスタンスに返す ECCSender スレッドは、各 xml ファイルの ecc キュー入力を挿入してから、XML ファイルを削除します。すべてのフォルダーが空になるまで、優先度が最も高いものが最初に送信され、最も古いものが最初に送信されます。

SOAP テーブル API は、SOAP メッセージを介してテーブルに挿入する他のインバウンド統合と同様に、挿入に使用され、API_INT セマフォで実行されます。インスタンスのトランザクションログには、次のように表示されます。

/ecc_queue.do?redirectSupported=true&SOAP&displayvalue=all 挿入された入力レコードごとに「ECC Queue - mark outputs Processed」ビジネスルールが実行され、出力レコードのステータスが [処理済み] に設定されます。

KB0743566 MID Server の最大スレッド、ワーカーグループ、優先度、およびキュー - 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 レコードの挿入に問題がある場合、「/ecc_queue.do?SOAP」の API_INT SOAPProcessor スレッドの appnode localhost ログと、MID Server エージェントログの ECCSender スレッドにエラーが記録されます。エラーのタイプに応じて、MID Server は何度か再試行し、再試行間隔を短くして断念する場合があります。

エラーがインスタンス側である場合、XML ファイルは agent\work\monitors\ECCSender\output_error に移動されます。ペイロードが MID Server で許可されている (mid.eccq.max_payload_size) より大きい場合は、agent\work\monitors\ECCSender\output_oversize に移動されます。これらはインスタンスに送信されず、 MID ファイルクリーナー によって 30 日後に削除されます。

挿入に対してビジネスルールが実行され、エラーが発生して挿入トランザクションが中断され、ステータス 500 が返される可能性があります。MID Server は、挿入の前または後にエラーが発生したかどうかを認識せず、挿入が失敗したと想定するため、複数の挿入が発生する可能性があります。

6.センサーはインスタンスで実行される ビジネスルールは、入力レコードの挿入ごとに実行されます。これらは通常、API_INT セマフォ SOAP トランザクションの一部として、入力の前または後に同期されます。これらのビジネスルールの 1 つ (または複数) が、ジョブの「センサー」と呼ばれるものになります。

これらは [順序] フィールドに従って実行され、レコード挿入に関する他のビジネスルールと同様に、条件に基づいてスキップされます。条件チェックを実行して入力が自分用かどうかを確認し、そうでない場合はレコードをそのままにして、次の BR が実行できるようにします。

次のリストは、ecc_queue ビジネスルールをパッケージ別にグループ化したもので、特定のジョブのセンサーとして機能するものを確認するのに役立ちます。通常、条件フィールドを使用すると、センサーの対象となるジョブを簡単に確認できます。 https:// .service-now.com/sys_script_list.do?sysparm_query=collection%3Decc_queue%5Eactive%3Dtrue%5EGROUPBYsys_package

ほとんどのセンサービジネスルールは、「1 回実行」の sys_trigger レコードを挿入することで、作業をスケジュール設定済みジョブに渡します。その後、バックグラウンドスケジューラーワーカースレッドがこのレコードを取得して実行し、実際のセンサー処理を行います。Discovery の場合、これは ECC キューレコードから優先度を継承します。ビジネスルールが SOAP 挿入の一部として処理に時間がかかりすぎると、API_INT セマフォがブロックされるリスクがあります。アプリノードごとに数個しかなく、多くの MID Server がそれらを共有している可能性があるため、これは悪いことです。スケジューラーワーカーの優先度を処理するのは特定のセンサーのジョブであり、機能/アプリごとに異なる場合があります。

特定のセンサーコードは、通常、作業を開始すると入力を [処理ステータス] に設定し、終了すると [エラー] または [処理済み] に設定します。センサーは通常、エラー時に [エラー文字列] フィールドに入力します。各機能/アプリは、センサーで異なる方法で実行できます。

ペイロードフィールドは、インスタンスの SOAP テーブル API が行う添付ファイルになる場合があります (glide.soapprocessor.large_field_patch_max を参照)。それを処理するのは個々のセンサーの責任です。添付ファイルは、システムプロパティ com.glide.attachment.max_get_size よりも小さくする必要があります。Discovery はすべてを 5MB 未満に抑えることを目指していますが、他の機能はそうではない可能性があります。

出力ごとに 1 つの入力を常に想定しているわけではありません。一部の機能は、大きな結果を複数の入力レコードに分割します。インポートセットデータソースの JDBCProbe は、入力を 200 行のデータごとに個別の ecc_queue 入力に分割し、すべての入力が ecc キューに戻された後にのみ変換を続行します。このプローブは output_s ECCSender フォルダーを使用するため、入力はインスタンスに順番に返されます。検出パターンでは複数ページの入力を使用できます。通常、各データサブセット入力は、データの完全なセットを待機することなく、入力されると処理されます。

入力のセンサーがまったくない可能性があります 。これらの入力は [準備完了] ステータスのままです。たとえば、RESTMessageV2 によって作成された RESTProbe 出力は同期的に実行され、結果/エラー処理はジョブを作成する同じスクリプトによって行われるため、多くの場合、センサー BR は必要ありません。一般に、キューバックログの誤った印象を避けるために、少なくともエラー処理を実行し、それを [Processed] に設定するために、常にセンサーが必要です。

「Discovery - センサー」BR は、検出とは関係がない場合でも、通常は入力に対して実行されます。これはすべて、MID Server が Discovery の一部であり、Discovery でのみ使用されていた時代に遡ります。出力パラメーターに skip_sensor=true が含まれている限り問題はなく、検出センサーはそれをスキップすることを認識しています。すべての非検出ジョブにはこれを含める必要がありますが、一部の OOTB 機能を含め、多くのジョブには含まれません。入力にそのパラメーターがない場合、検出センサーはそれを処理しようとし、エラーが発生する可能性があります。たとえば、skip_sensor のない RESTProbe 入力は、state=Error および Error string="No sensor defined" として設定されます。このパラメーターはペイロード内にあります。ペイロードが大きい場合や添付ファイルである場合もあります。検出センサーはそれを処理してパラメーターを読み取る必要があります。これには時間がかかり、大量のメモリを使用する可能性があります。このセンサーが検出以外のジョブに対して実行されると、[エージェントコリレーター] フィールドの値がこれらのレコードのいずれでもないため、アプリノードログに「Get for non-existent record: discovery_status:..., Initializing」と記録されていることがわかります。

センサーは通常、エージェントコリレーターの値を使用して、結果がジョブを作成した特定のジョブ/レコード/ワークフロー/検出ステータスに戻るようにします。例えば、オーケストレーションの値はすべて "rba" で始まります。 Integrations Hub は "ihub" です。

例 例 1 - ハートビートプローブ sys_trigger ジョブ、BR センサー。センサーはすべてを同期的に実行しますが、実際の処理を sys_trigger ジョブにオフロードしません。

初期スクリプト：Schedule [sys_trigger]：MID Server Monitor センサービジネスルール：MID - ハートビート

例 2 - 同期 RESTMessagev2 通常はインスタンスで同期的に実行され、応答を待機し、文字通りスリープしてプロセス内のスレッドをブロックします。

初期スクリプト：RESTMessagev2.execute() を呼び出す任意のカスタムスクリプト センサービジネスルール：なし この場合、初期スレッドはスリープし、ECC キューを定期的にポーリングします。スレッドのスタックトレースは次のようになります。

main,glide.scheduler.worker.4,4, (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 MID Server を介した送信 REST/SOAP メッセージの ECC キューに「エラー」および「センサーが定義されていません」と表示されるのはなぜですか？ - skip_sensor パラメーターを展開します。 KB0694711 送信 REST Web サービス RESTMessageV2 および SOAPMessageV2 execute() と executeAsync() のベストプラクティス KB0716391 RESTMessageV2 および SOAPMessageV2 のベストプラクティス PRB1305586 RESTMessageV2/SOAPMessageV2 API により、センサー ECC ビジネスルールなしで MID サーバーを介して同期的に実行でき、ブロックされるスリープ中のインスタンススレッド、およびスケジューラーの過負荷 KB0749289 アップグレード後 30 秒後に同期送信 Web サービスコールがタイムアウトする

例 3 - 検出センサー 初期スクリプト：Discovery の開始時、または前の Discovery センサーによってトリガーされる ShazzamLaunch。例：Windows - 分類センサーによって起動された Windows - サーバーパターン。 センサービジネスルール：Discovery - センサー sys_trigger job: ASYNC: Discovery - MultiPage Sensors (注意：Paris には、スレッドのトレースをはるかに簡単にするために、ecc_queue 入力の名前、ソース、および sys_id も含まれるようになりました) この例の詳細については、以下を参照してください。 KB0718653 ECC Queue Processing, with "Discovery - Sensor" used as an example

デバッグ 上記は、プロセスのどのステージで問題があるかを理解するのに役立ちます。「場所」がわかっている場合は、解決の途中です。次の KB が役立ちます。

KB0718589 MID Server 関連のジョブがスタックし、ECC キュー入力がまだ準備完了ステータスのままなのはなぜですか？ - センサーの処理遅延の考えられる原因を提案し、トラブルシューティングのヒントと解決策を提供します。 KB0727132 - ECC キューレコードを特定の機能またはジョブにリンクする方法 - さまざまなアプリケーションで使用されるトピック/名前/ソース/エージェントコリレーターの値をリストします値の意味を説明します