この文章は Salesforce 機械翻訳システムを使用して翻訳されました。詳細はこちらをご参照ください。
英語に切り替える

変更のポーリング

クライアントアプリケーションは、定期的にデータ変更のポーリングを行います。ポーリングについては、次の点を考慮する必要があります。

  • ポーリングの頻度は、組織の Salesforce データのローカルデータへの適用の時差の許容範囲、という業務上の要件により異なります。日に一度のポーリングで十分なクライアントアプリケーションもあれば、精度の高いデータを得るために 5 分ごとにポーリングを実施する必要があるクライアントアプリケーションもあります。
  • 削除されたレコードは、getDeleted() からアクセス可能な削除ログに出力されます。2 時間ごとに実行されるバックグラウンドプロセスは、削除ログのレコード数が制限を超えた場合、削除ログに書き込まれてから 2 時間以上経過したレコードを消去します。最も古いレコードから順に、削除ログが制限を下回るまで消去を行います。このような処理を行うのは、大量の削除ログによる Salesforce のパフォーマンス上の問題を防ぐためです。制限値は次の数式を使用して算出します。
    15000 * number of licenses in the organization

    たとえば、1,000 ライセンスを所有する組織では、削除ログのレコード数が 5,000,000 (5 百万) レコード以上になると消去処理を開始します。getDeleted() コールを実行する前に消去処理を実行すると、INVALID_REPLICATION_DATE エラーが返されます。この例外が発生した場合、テーブル全体に対するプル処理を実行する必要があります。

  • API は、dateTime 値の秒の値を切り捨てます。たとえば、クライアントアプリケーションが 12:30:15 から 12:35:15 (協定世界時 (UTC)) までの時間を送信した場合、API は、12:30:00 から 12:35:00 (UTC) までに変更された項目 (両端の値を含む) の情報を取得します。

    時間データの処理方法は、開発ツールごとに異なります。開発ツールによってはローカル時間を表示するものも、協定世界時 (UTC) を表示するものもあります。開発ツールごとの時間の処理方法はツールのドキュメントを参照してください。

    メモ

  • ポーリングの頻度は、5 分以上に設定することをお勧めします。アプリケーションの不備によりデータ複製の API コールが頻繁に実行されることがないようにするための制御機能が組み込みで実装されています。
  • クライアントアプリケーションは、以前のデータ複製の API コールで使用した期間を保存する必要があります。それにより、データ複製が最後に正常に実行された時間をアプリケーション側で把握することができます。
  • ローカルデータの整合性を確保するために、クライアントアプリケーションはポーリング中の関連する変更すべてを取得し、差異がないようにする必要があります (これにより、データを重複して処理しなければならないこともあります)。クライアントアプリケーションには、ローカルデータにすでに統合済みのデータの処理を避けるためのビジネスロジックを組み込むことができます。
  • ハードウェア障害や接続エラーなど何らかの理由でクライアントアプリケーション側でデータのポーリングが失敗した場合も、データに差異が生じる場合があります。最後に正常に実行されたデータ複製とポーリングを確認し、次の処理期間を設定するためのビジネスロジックを、クライアントアプリケーションに組み込むことができます。
  • 何らかの理由でローカルデータに変更が加えられた場合、ローカルデータを一から構築しなおすためのビジネスロジックを、クライアントアプリケーションに組み込むこともできます。

ここで Outbound Messaging を使用し、ポーリングの代わりにアクションをトリガすることも可能です。

メモ