正解: Anypoint Exchange で適切な既存のフォールバック API を検索し、注文 API に加えてこのフォールバック API への呼び出しを実装します。
****************************************
>> API クライアントが HTTP 3xx 一時リダイレクト ステータス コードを受信し、別の API を呼び出すためにフォールバック ロジックを実装する必要があるという事前承認済みの合意が API クライアントとの間でない限り、これは理想的でも適切なアプローチでもありません。
>> API マネージャーで同じ Order API の別のエントリを作成すると、同じ API 実装の上に別のインスタンスが作成されるだけです。したがって、同じ API のクローンをフォールバック API として使用しても効果はありません。フォールバック API は、理想的にはプライマリ API とは異なる API 実装である必要があります。
>> 現在、Anypoint HTTP Connector では、応答として特定の HTTP ステータス コードを受信したときにフォールバック API を呼び出すことができるオプションは提供されていません。
指定されたオプションの中で TRUE となる唯一のステートメントは、適切な既存のフォールバック API を Anypoint エクスチェンジで検索し、注文 API に加えてこのフォールバック API への呼び出しを実装することです。

正解: Anypoint Runtime Manager で「ワーカーが応答していません」アラートを設定します。
****************************************
>> すべてのオプションは、最終的に、アプリケーションが応答を停止したときに必要なアラートを生成するのに役立ちます。
>> ただし、API 呼び出し内で例外を処理し、API クライアントからアラートを発生させるのは不適切で愚かなことです。API 実装を呼び出す API クライアントは多数ある可能性があり、すべてのクライアントでこの設定を一貫して行うことは理想的ではありません。現実的な方法ではありません。
>> API 内でヘルス チェック/ハートビートを実装し、外部から呼び出してヘルスを判定するのは問題ないように思えますが、追加の設定が必要であり、同時に、API 実装でヘルス チェック API を呼び出す外部ツール間で断続的なネットワークの問題が発生すると、誤報が発生する可能性が非常に高くなります。API 実装自体には問題がないかもしれませんが、他の要因により誤報が発生する可能性があります。
>> 指定された期間内に API がリクエストを受信しなかった場合に API Manager でアラートを作成すると、実際に現実的なアラートが生成されますが、API クライアントからのリクエストが実際にない場合にも、誤ったアラートが送信される可能性があります。
この要件を満たす最善かつ正しい方法は、Runtime Manager に「ワーカーが応答しない」という条件でアラートを設定することです。これにより、ワーカーが応答しなくなるとすぐにアラートが生成されます。

正解: プライマリ環境にデプロイされたシステム API を呼び出します。断続的な障害を回避するために、プロセス API にタイムアウトと再試行ロジックを追加します。それでも障害が発生する場合は、DR 環境にデプロイされたシステム API を呼び出します。
****************************************
この質問には、DR 環境のシステム API がプライマリ環境が提供するレート制限の 20% しか提供しないという重要な考慮事項が 1 つあります。したがって、比較すると、プライマリ環境と比較して、DR 環境 API への呼び出しは非常に少なくなります。これを念頭に置いて、適切かつ最適なフォールト トレラント呼び出し戦略を分析しましょう。
1. DR 環境には 20% の制限があるため、両方のシステム API を並行して呼び出すことは絶対に実行可能なアプローチではありません。毎回並行して呼び出すと、DR 環境のレート制限が簡単かつ急速に使い果たされ、必要なときに真の断続的なエラー シナリオが発生する機会がなくなる可能性があります。
2. もう一つのオプションは、プライマリ環境のシステム API を呼び出すときに、プロセス API にタイムアウトと再試行ロジックを追加することを提案することです。これは今のところは良いことです。ただし、すべての再試行が失敗した場合、オプションは DR 環境でプロセス API のコピーを呼び出すことを提案しますが、これは正しくなく、推奨されません。フォールバックの対象となるのはシステム API のみであり、プロセス API 全体ではありません。プロセス API には通常、DR のプロセス API を呼び出して再度繰り返したくない他の多くの API を呼び出す大量のオーケストレーションがあります。したがって、このオプションは正しくありません。
3. もう 1 つのオプションは、最初にプライマリ環境のシステム API を再試行するのではなく、プロセス API に再試行 (タイムアウトなし) ロジックを追加して、DR 環境のシステム API を直接再試行することを提案することです。これはまったく適切なフォールバックではありません。適切なフォールバックは、最初にプライマリ環境ですべての再試行が実行され、使い果たされた後にのみ発生するはずです。ただし、ここでのオプションは、メイン API を試行せずに、最初の失敗自体でフォールバック API を直接再試行することを提案しています。したがって、このオプションも正しくありません。
これにより、適切かつ最適なオプションが 1 つ残ります。
- プライマリ環境にデプロイされたシステムAPIを呼び出す
- プロセス API にタイムアウトと再試行のロジックを追加します。
- すべての再試行後も失敗した場合は、DR 環境にデプロイされたシステム API を呼び出します。

正解: アップストリーム API の SLA は提供できません。
****************************************
>> まず最初に、HTTP コネクタのデフォルトの HTTP 応答タイムアウトは 10000 ミリ秒 (10 秒) です。500 ミリ秒ではありません。
>> Mule ランタイムは、このような「負荷依存」のタイムアウトを適用しません。現在、Mule にはそのような動作はありません。
>> HTTP コネクタにはデフォルトで 10000 ミリ秒のタイムアウトがあるため、信頼性の低い SLA 時間により、ダウンストリーム API の呼び出しがタイムアウトせずに完了することを常に保証することはできません。応答時間が 10 秒を超えると、リクエストがタイムアウトする可能性があります。
これによる主な影響は、アップストリーム API の適切な SLA を提供できないことです。