Skip to main content
パッケージリンク: こちらをクリックしてください。 このリリースでは、ガバナ制限に関連する同期実行の動作に対処し、設定可能なテストデータを利用した柔軟でフェイルセーフなトリガー/テストクラスのデプロイを導入し、再試行ロジックとテストクラスの命名を改善することで、システムの信頼性を向上させています。

新機能

このバージョンで導入された新機能と改善点は次のとおりです。

新しい Sync Queue レコードの作成

同じ基になる Record ID の既存のレコードが失敗し、再試行の対象外である場合でも、Sync Queue レコードが作成されます。
  • 再試行できないエラー (例: Missing Attribute、Max retries exceeded) に適用されます。
  • これにより、レコードへの以降の更新を正しく同期できます。

デプロイ用のカスタムテストデータのサポート

クライアント組織の既存のコードロジックや検証が原因でテストクラスのデプロイが失敗した場合、ユーザーはカスタムテストデータを入力できるようになりました。
  • このテストデータはテストクラスの生成に使用され、オブジェクトで同期機能が適切に有効化されるようにします。

413 レスポンスタイプの処理の強化

MoEngage は、413 (Request Entity Too Large - Payload too large) エラーを処理する際に、HTML と JSON の両方のレスポンス形式をサポートします。
  • 以前は JSON のみが想定されていたため、サーバーが HTML で応答した場合に解析エラーが発生していました。
  • この変更により堅牢性が向上し、大規模な同期の試行中によりクリーンなエラー処理が可能になります。

問題の修正

履歴同期が Processing のままになる

問題 : すべてのレコードが正常に処理された場合に、Apex のガバナ制限 (10,000 DML 行) に達したため、同期が Processing ステータスのままになっていました。 解決策 : Failed Sync Queue レコードは、finish メソッドで最後にまとめて処理するのではなく、各バッチの実行中に処理および更新されるようになりました。これにより、DML 制限を超えるリスクが軽減されます。

テストクラス名が 40 文字の制限を超える

問題 : テストクラス名が Salesforce の 40 文字の制限を超え、デプロイが失敗していました。 解決策 : テストクラス名は次のようになりました。
  • 文字数制限内に収まるように切り詰められます。
  • 切り詰めた名前が重複する場合は、区別するために一意の番号が付加されます。