MID サーバーを介した統合の実行時間が最大 40 秒長くなったり、タイムアウトしたりすることがあるのはなぜですか?Issue <!-- div.margin{ padding: 10px 40px 40px 30px; } table.tocTable{ border: 1px solid; border-color:#E0E0E0; background-color: rgb(245, 245, 245); padding-top: .6em; padding-bottom: .6em; padding-left: .9em; padding-right: .6em; } table.noteTable{ border:1px solid; border-color:#E0E0E0; background-color: rgb(245, 245, 245); width: 100%; border-spacing:2; } table.internaltable { white-space:nowrap; text-align:left; border-width: 1px; border-collapse: collapse; font-size:14px; width: 85%; } table.internaltable th { border-width: 1px; padding: 5px; border-style: solid; border-color: rgb(245, 245, 245); background-color: rgb(245, 245, 245); } table.internaltable td { border-width: 1px; padding: 5px; border-style: solid; border-color: #E0E0E0; color: #000000; } .title { color: #D1232B; font-weight:normal; font-size:28px; } h1{ color: #D1232B; font-weight:normal; font-size:21px; margin-bottom:-5px } h2{ color: #646464; font-weight:bold; font-size:18px; } h3{ color: #000000; font-weight:BOLD; font-size:16px; text-decoration:underline; } h4{ color: #646464; font-weight:BOLD; font-size:15px; text-decoration:; } h5{ color: #000000; font-weight:BOLD; font-size:13px; text-decoration:; } h6{ color: #000000; font-weight:BOLD; font-size:14px; text-decoration:; } ul{ list-style: disc outside none; margin-left: 0; } li { padding-left: 1em; } --> MID サーバー、LDAP、インポートセットなどを介した REST メッセージや SOAP メッセージなどの統合が表示される場合があります通常は 1 秒か 2 秒かかりますが、通常よりも実行に時間がかかりますecc_queue出力レコードを確認し、作成時間と処理時間を比較すると、MID サーバーがジョブを取得するのに 最大約 40 秒の遅延が生じる場合があります。 これは、MID サーバージョブへの応答をスクリプトで待機するという悪い習慣を行っている場合、大きな問題になる可能性があります。MID サーバーは通常よりも時間がかかる場合があり、これによりインスタンススレッドがブロックされ、インスタンス全体でバックログとパフォーマンスの問題がすぐに発生する可能性があります。RESTMessageV2 を使用すると、そうすべきではない場合でも、これを行うことができます。代わりに、メッセージ「非同期」を実行して、その時点でスクリプトを終了させ、代わりに応答を読み取るビジネスルールecc_queue「センサー」を記述します (ディスカバリーとオーケストレーションではこのように行われます)。ReleaseHelsinki 以降は、AMB チャネルが実装され、デフォルトのフォールバックポーリング時間が 40 秒に設定されていました。Cause何らかの理由で AMB チャネルが切断された可能性がありますこれは、MID サーバーからインスタンスへのリアルタイム接続です。これにより、新しいジョブが作成されたときに MID サーバーに通知されます。 MID サーバーエージェントログには、AMB チャネルの再接続が必要だったときと失敗した場所のすべてのインスタンスが表示されます。 08/15/18 21:24:45 (404) ECCQueueMonitor.40 WARNING *** WARNING *** Reconnecting AMB channel.. 08/15/18 21:24:45 (404) ECCQueueMonitor.40 Initializing AMB client... 08/15/18 21:24:45 (405) AMBClientProvider Connecting AMB client to instance... 08/15/18 21:24:45 (468) AMBClientProvider WARNING *** WARNING *** Unable to subscribe to AMB channel: /mid/server/bd27969913068bc036aff4d2e144b0a7 ジョブに設定されたタイムアウトが、ジョブがすぐに実行されることを前提としており、MID サーバーがジョブを認識して実行するのにかかる時間よりも短い場合は、タイムアウトになります。それ以外の場合、ジョブは引き続き実行されますが、開始が遅れます。Resolution「AMB チャネルに登録できない」には、さまざまな原因が考えられます。ネットワークの状態や、MID サーバーとインスタンス間のデバイスの問題が接続/セッションに干渉している可能性があり、調査が必要です。MID サーバーのエージェントログまたはラッパーログに例外またはさらなるエラーがあり、それが説明に役立つ可能性があります。 AMB チャネル全般、特に特定のネットワーク環境の MID サーバーには既知の問題がいくつかあり、これはリリースノートに記載されています。ほとんどのお客様は、そのほとんどは既に解決されているため、インスタンスに現在のパッチを適用して、まずそれらを割引することをお勧めします。 Workaround : MID サーバーの再起動 は、AMB チャネルへの再接続を強制的に試行する 1 つの方法です。原因が一時的なネットワークの問題であり、現在解決されている場合は、それだけで済むかもしれません。単に AMBチャンネルを機能させることができない場合、オフにすると、ヘルシンキ以前の動作が使用されます。この MID サーバーパラメーターを設定すると、ポーリング時間はデフォルトで 5 秒になり、AMB 接続の作成は試行されません。mid.disable_amb=trueAMB チャネルが断続的であり、ほとんどの場合機能する場合は、オフにする代わりに、ポーリング時間を 5 秒に 設定して、AMB チャネルがダウンしている場合は、デフォルトの 40 秒ではなく、5 秒ごとにポーリングするようにできます。MID サーバーパラメーターを設定することで、これを 5 秒に短縮できます。mid.poll.time=5