決済処理会社は、クレジット カードとデビット カードのトランザクションを処理するために、決済処理 API Mule アプリケーションを実装しました。決済処理 API は機密性の高い情報を処理するため、決済処理会社は、データが転送中と保存中の両方で暗号化される必要があると要求しています。
これらのセキュリティ要件を満たすために、Payment Processing API の利用者は、API で指定された JSON 形式でリクエスト メッセージ ペイロードを作成し、メッセージ ペイロード値を暗号化する必要があります。
Payment Processing API は API コンシューマーから受け取ったリクエストをどのように検証できますか?

• A. Mule アプリケーション実装は、検証モジュールを使用して JSON データを復号し、検証できます。
• B. Mule アプリケーション実装は、DataWeave を使用してメッセージ ペイロードを復号化し、JSON スキーム検証モジュールを使用して JSON データを検証できます。
• C. Mule アプリケーション実装は、APIkit モジュールを使用して JSON データを復号化して検証できます。
• D. トランスポート層セキュリティ (TLS) - API Manager で受信ポリシーを適用してメッセージ ペイロードを復号化し、Mule アプリケーション実装で JSON 検証モジュールを使用して JSON データを検証できます。

組織は、注文をオフライン処理のためにバックエンド システムに送信することで注文を処理する統合 Mule アプリケーションを設計しています。各注文は、HTTPS POST を介して Mule アプリケーションによって受信され、すぐに確認する必要があります。承認されると、注文はバックエンド システムに送信されます。バックエンド システムからの拒否により正常に送信できない注文は、(バックエンド システム外で) 手動で処理する必要があります。
Mule アプリケーションは、顧客がホストするランタイムにデプロイされ、必要に応じて既存の ActiveMQ ブローカーを使用できます。ActiveMQ ブローカーは、組織のファイアウォール内にあります。バックエンド システムには、小規模なネットワーク接続の問題と長時間の停止の両方が原因で、信頼性が低いという実績があります。
Mule アプリケーション コンポーネントと ActiveMQ キューの (本来の目的に使用される) どの慣用的な組み合わせが、バックエンド システムへの注文の自動送信を保証すると同時に、手動注文処理をサポートしながら最小限に抑えるために必要ですか?

• A. バックエンド システムの呼び出しを支援する 1 つ以上の On Error スコープ
  1 つ以上の ActiveMQ 長期再試行キュー
  CloudHub オブジェクト ストア サービスで構成された永続的な配信不能オブジェクト ストア
• B. バックエンド システムの呼び出しを支援する 1 つ以上の On Error スコープ
  長時間の再試行のための VM コンポーネントを含む、成功するまでのスコープ
  CloudHub で構成された永続的な配信不能 VM キュー
• C. バックエンド システムを呼び出すまでのスコープ
  1 つ以上の ActiveMQ 長期再試行キュー
  手動処理​​用の 1 つ以上の ActiveMQ 配信不能キュー
• D. バックエンド システムを呼び出すための Batch Job スコープ
  長時間の再試行用の Object Store コンポーネントを含む Until Successful スコープ Mule アプリケーションで設定された配信不能オブジェクト ストア

展示を参照してください。

API 実装によって呼び出されるバックエンド システムの 1 つは、特定のクライアントが行うことができる要求の数にレート制限を適用します。バックエンド システムと API 実装の両方が、運用環境に加えていくつかの非運用環境にデプロイされます。
バックエンド システムのレート制限は、すべての非実稼働環境に適用されます。ただし、本番環境にはレート制限がありません。
ステージング (非実稼働) 環境で API 実装のパフォーマンス テストを実施するための最も効果的なアプローチは何ですか?

• A. MUnit を使用してバックエンド システムからの標準応答をシミュレートし、パフォーマンス テストを実施してシステム内の他のボトルネックを特定します。
• B. レート制限されたバックエンド システムに対してステージング環境でスケールダウンされたパフォーマンス テストを実施し、パフォーマンス結果をフル プロダクション スケールにアップスケールします。
• C. バックエンド システムの本番パフォーマンス特性を複製するモッキング サービスを作成します。次に、モッキング サービスを使用するように API 実装を構成し、パフォーマンス テストを実施します。
• D. パフォーマンス テストの状況でバックエンド システムの呼び出しをバイパスするロジックを API 実装内に含めます。代わりに、典型的なバックエンド システムの応答を複製するローカル スタブを呼び出し、この API 実装を使用してパフォーマンス テストを実施します。

ある会社は、オラクル ERP でホストされている REST API 対応のクレーム支払いルール エンジンによって駆動される一連の重要な機能をサポートする新しい Mule アプリケーションを実装しています。設計どおり、ミュール アプリケーションはバッチ処理ロジックを実行するため、多くのデータ変換操作を必要とします。
同社は、既存の Java ベースの機能 (クラス、オブジェクト、データ モデルなど) を可能な限り活用して再利用したいと考えています。新しい Mule で Mule アプリケーションと Oracle ERP の間で必要なデータ マッピングと変換を実装する際に考慮すべきアプローチは何ですか。応用？

• A. Mule で適切な Java オブジェクトから新しいメタデータ RAML クラスを作成し、Dataweave を介して変換を実行します。
• B. 適切な Java メソッドのいずれかを直接呼び出し、メタデータ RAML クラスを作成してから、Dataweave を介して必要な変換を実行します。
• C. Dataweave から適切な Java クラスを呼び出して変換します。
• D. mule アプリケーションから、XSLT モデルを介して変換します。

銀行会社は、オンライン ビジネス用の新しい API セットを開発しています。重要な API の 1 つは、システム API であるマスター ルックアップ API です。このマスター ルックアップ API は、永続的なオブジェクト ストアを使用します。この API は、マスター ルックアップ データを提供するために、他のすべての API で使用されます。

マスター ルックアップ API は、キャッシュするマスター データが大量にあるため、それぞれ 0.1 vCore の 2 つの cloudhub ワーカーにデプロイされます。マスター ルックアップ データは、キーと値のペアとして保存されます。キーがキャッシュ内に見つからない場合、キャッシュは更新されます。
パフォーマンス テストを行ったところ、マスター ルックアップ API は、マスター ルックアップ データを取得するためのデータベース クエリの実行により、応答時間が長くなることが観察されました。
このパフォーマンスの問題により、オンライン ビジネスの稼働は保留されており、銀行に財務上の損失をもたらす可能性があります。
統合アーキテクトとして、パフォーマンスの問題を解決するために次のオプションのうちどれを提案しますか?

• A. マスター ルックアップ API のすべての GET エンドポイントに HTTP キャッシュ ポリシーを実装する
• B. マスター ルックアップ API のすべての GET エンドポイントに HTTP キャッシュ ポリシーを実装し、ロックを実装してオブジェクト ストアへのアクセスを同期します。
• C. vCore のサイズを 0.1 vCore から 0.2 vCore にアップグレードします。
• D. 追加の Cloudhub ワーカーを追加して、追加の容量を提供します