プログラマは、同様のアクションが 1 つのバッチでまとめて実行されるように独自のコードを設計できます。たとえば、50 回の操作でレコードを 1 つずつ作成するのではなく、1 回の操作で 50 のレコードを作成します。このプロセスを一括処理といい、トランザクションでガバナ制限を回避できます。フローを使用している場合、一括処理について考える必要はありません。フローインタビューでアクションが自動的に一括処理されます。
フローの一括処理のしくみ
インタビューの操作は、同じ要素を実行する場合にのみ一括処理されます。つまり、インタビューがすべて同じフローに関連付けられる必要があります。
1 つのトランザクションで同じフローの複数のインタビューが実行される場合、インタビューはそれぞれ一括処理可能な要素に達するまで実行されます。Salesforce は、同じ要素で停止したすべてのインタビューを対象に、これらの操作をインテリジェントにまとめて実行します。他のインタビューが別の要素で停止していれば、Salesforce はその後、これらの操作をインテリジェントにまとめて実行します。Salesforce は、すべてのインタビューが終了するまでこのプロセスを繰り返します。
一括処理であるにもかかわらず、いずれかのインタビューがガバナ制限に達した場合は、トランザクションのすべてのインタビューが失敗します。インタビューがトランザクション内で実行した操作がすべてロールバックされ、トランザクションの操作が再試行されることはありません。外部データにアクセスする操作はロールバックされません。
次のいずれかの要素の実行中にガバナ制限によるものではないエラーが発生した場合、Salesforce は一括操作で成功したすべてのレコード変更について、保存を 3 回試みます。
- サブフロー ([レコードの作成] 要素と [レコードを更新] 要素のみ)
- レコードの作成
- レコードを更新
一括処理可能なフロー要素
フローでは、DML ステートメントまたは SOQL クエリを実行する要素や、フロー外の他の操作 (メール送信など) を行う要素を一括処理できます。
レコードを作成、更新、削除する要素
- レコードの作成、更新、削除時に、トランザクションが DML ステートメントを実行します。
- レコードの作成要素
- レコードを更新要素
- レコードの削除要素
- クイックアクション、Chatter への投稿、または承認申請コアアクション
- Apex アクション要素 (組織によって異なります)
レコードを検索する要素
- レコードの項目が検索されると、トランザクションが SOQL クエリを実行します。
- レコードを取得要素
- レコードを更新要素
- レコードの削除要素
- Apex アクション要素 (組織によって異なります)
メールを送信する要素
- メールの送信コアクション
- メールアラート要素
- Apex アクション要素 (組織によって異なります)
フローの一括処理の例
次の例では、データローダで 100 件のケースが更新されるときに、フローの操作がどのように一括処理されるかを示します。
関連付けられたフロー
関連付けられたフローの設計を理解すれば、概念に対する理解が深まります。
フロー:
ケースの親取引先と、その取引先が有するオープンケースの件数を検索します。
- 取引先のオープンケースが 6 件以上かどうかを確認します。
- 取引先のオープンケースが 6 件以上の場合:
- a. 取引先のディビジョンマネージャを検索します。
b. 取引先の Chatter フィードに投稿して、ディビジョンマネージャと取引先所有者に通知します。 - 取引先のオープンケースが 5 件以下の場合は、取引先の Chatter フィードに投稿して、取引先所有者のみに通知します。
一括処理されるインタビュー
レコードの更新時に、各ケースのフローインタビューが同時に作成されます。インタビューがすべて同じフローに関連付けられます。インタビューはそれぞれ一括処理可能な要素に達するまで実行されます。
最初のインタビューがレコードを取得要素 (1) を処理します。[レコードを取得] は一括処理が可能なため、インタビューは他のすべてのインタビューが同じ処理を終了するまでこの時点で待機します。その後、Salesforce が [レコードを取得] 操作をすべてまとめて実行します (すべて同じフローの同じ要素に対する操作のため)。トランザクションで、100 件の SOQL クエリではなく、1 件の SOQL クエリが実行されます。
最初のインタビューが決定要素 (2) に評価されます。取引先にケースが 6 件あるため、インタビューが「6 件以上」のパスに転送されます。インタビューが 2 つ目のレコードを取得要素 (3a) に進みます。この要素も一括処理が可能なため、インタビューがこの時点で待機します。
2 つ目のインタビューが決定要素 (2) に評価されます。この取引先はケースが 1 件のため、インタビューが「5 件以下」のパスに転送されます。インタビューは [Chatter に投稿] コアアクション (4) に進みます。この要素も一括処理が可能なため、インタビューがこの時点で待機します。
すべてのインタビューが処理された後、30 は 2 つ目のレコードを取得要素 (3a) の実行を待機し、残りの 70 は [Chatter に投稿] コアアクション (4) の実行を待機します。
Salesforce が、最初の 30 のインタビューに対する [レコードを取得] 操作 (3a) をまとめて実行します。トランザクションで、30 件の個々の SOQL クエリではなく、1 件のクエリが実行されます。
次に、トランザクションが [Chatter に投稿] アクション (4) に戻ります。この要素では、70 のインタビューが Chatter に投稿操作の実行を待機しています。これらは、取引先のケースが 5 件以下のインタビューです。Salesforce が、Chatter への投稿操作をまとめて実行します。トランザクションで、各 Chatter 投稿を作成する 100 件の個別の DML ステートメントではなく、100 の投稿をすべて一度に作成する 1 件の DML ステートメントが実行されます。[Chatter に投稿] コアアクションは後続の要素に結び付けられていないため、この 70 のインタビューは終了します。
関連するディビジョンマネージャを検索した 30 のインタビューは、最後の [Chatter に投稿] コアアクション (3b) に進みます。30 のすべてのインタビューの準備が整ったら、Salesforce が 30 の [Chatter に投稿] 操作をまとめて実行します。Chatter 投稿ごとの 30 件の個々の DML ステートメントではなく、1 件の DML ステートメントが実行されます。[Chatter に投稿] コアアクションは別の要素に結び付けられていないため、この 30 のインタビューは終了します。