バッチワークフローの概要
お知らせ：当社は、お客様により充実したサポート情報を迅速に提供するため、本ページのコンテンツは機械翻訳を用いて日本語に翻訳しています。正確かつ最新のサポート情報をご覧いただくには、本内容の英語版を参照してください。
1. このページの内容
大きなタスクを効率的に小さなバッチに分割し、オフピーク時間にバッチワークフローを使って処理する方法を説明します。
2. 提供状況
バッチワークフロー機能:
3. 概要
バッチ処理は、扱うデータを管理しやすいバッチに分割し、高ボリュームかつ反復的なデータ処理を効率的かつ定期的に完了させるために使用されます。各バッチは非同期フローで個別に処理されます。この方法では人の介入を最小限に抑えつつ、1 日を通して順次、または任意の間隔で実行できます。バッチ処理を利用できる代表的な業務プロセスには、レポートの生成、ドキュメントの印刷、終業時の情報更新などがあります。
4. Creator におけるバッチワークフロー
Creator では、ワークフローはアプリケーション内の定型処理を自動化するために、特定のタイミングで実行される一連の処理で構成されます。バッチワークフローを使用すると、大量のデータに対してカスタマイズした Deluge スクリプトをデータのインポート完了後またはスケジュールされた間隔で効率的に実行できます。大量データを 1 バッチあたり10 ～ 1000件のデータに分割し、[実行中]セクションで、各バッチブロック（グループ化されたデータの集合）内の各データに対して実行する処理を設定できます。その後、[実行前]および[実行後]セクションが表示され、上記の Deluge スクリプトの実行前後に実行する処理を指定できます。たとえば、注文が発生するたびに処理するのではなく、バッチワークフローを設定して 1 日の終わりにすべての注文を集計し、出荷担当チームと共有することができます。このようにデータ処理を分割することで、Deluge の実行制限（10～50k トランザクションの上限）を回避し、大規模データセットを円滑に処理できます。
- スクリプト全体の実行時間とリソース使用率を最適化できるバッチサイズを選択することで、パフォーマンスと処理効率のバランスを取ることができます。
- バッチワークフローの実行中に、あるバッチでエラーが発生した場合、そのバッチのみがロールバックされます。つまり、1 つのバッチでエラーが発生しても、同じバッチブロック内の他のバッチの正常な実行には影響しません。
4。1 バッチワークフローで自動化できるプロセスの例
バッチワークフローは、さまざまな種類のデータ処理に対して設定でき、代表的なものとして次のようなものがあります。
- 定期請求 - 個々の請求日に応じて、定期的に合計金額を計算します。
- 請求書の作成 - 要件に応じて営業請求書を生成します。
- 給与計算 - 組織内の各従業員に対して、月次の給与明細をメール送信します。
- 在庫管理 - 商品在庫を定期的に追跡し、在庫切れを防ぎます。
- 不正取引の検知 - クレジットカードの月次利用明細を生成し、不正利用を検知します。
バッチワークフローは、業務効率を高め、繰り返しタスクを自動化し、組織の生産性を最大化すると同時に、反復作業に対する手動での監督を削減します。
5. バッチワークフロー実行のステージ
バッチワークフローには、次の3つのステージがあり、それぞれに対して個別の処理を設定できます。
メモ: [実行前]および[実行後]ブロックは、要件に応じて省略できます。ただし、[実行中]ブロックで実行するスクリプトは必ず設定する必要があります。
- バッチワークフローの実行前: 変数の定義や初期化（他の 2 つのブロックでも使用可能）を行い、バッチワークフローの実行開始前に行う必須処理を設定します。初期化処理の例としては、処理開始前の通知送信、在庫システムへの Webhook コールで在庫情報を取得してリストを作成することなどがあります。設定方法を見る
[実行前]ブロックは、バッチワークフローの実行開始時に最初に 1 回だけ実行されます。
- バッチワークフローの実行中: ここでは、バッチブロック内の各データに対して実行する 1 つの処理を設定します。この処理は、バッチワークフローの実行中、各データに対して実行されます。たとえば、各従業員の月次給与（税金、福利厚生などを含む）を計算する処理を設定できます。設定方法を見る
[実行中]ブロックは、そのバッチワークフロー内のすべてのバッチブロックが完了するまで繰り返し実行されます。
- バッチワークフローの実行後: すべてのバッチの実行完了後に実行する処理を設定し、成功と失敗の両方のシナリオを処理します。たとえば、クリーンアップ処理の実行、結果に応じた（成功/失敗）通知の表示、エラー処理などです。例として、バッチワークフローの実行が正常に完了した後に、従業員へメールで月次給与明細を通知するよう設定できます。設定方法を見る
6. 前提条件
- アプリケーション内に、バッチワークフローの基準となるフォームが必要です。
- バッチワークフローをいつトリガーするか、また各バッチのサイズ（データ件数）の目安を決めておく必要があります。
7. 動作イメージ
組織がクレジットカードを発行しており、クレジットカード管理という Creator アプリケーションを作成しているとします。毎月 1 日に、各顧客に対して請求明細を作成し送信する必要があります。そのために、毎月 1 日に実行されるようバッチワークフローをスケジュールし、関連する明細を生成する処理を設定できます。また、各顧客の合計請求額を算出するなど、動的な計算に変数を利用することもできます。実行が正常に完了したら、月次のクレジットカード請求明細をメールの添付ファイルとして送信するよう設定できます。
8. ユースケース
ケース 1: データのインポート完了後に実行
営業・マーケティングの領域では、見込み客を効率的に管理することが、コンバージョンの向上と売上成長にとって非常に重要です。ここでは、見込み客管理という Creator アプリケーションを作成しているとします。
組織には、サードパーティプラットフォームからのインポートを含むさまざまな経路から、大量の見込み客が取り込まれます。各見込み客には、エンゲージメントレベル、属性情報、過去のやり取りなど、さまざまな指標に基づいてリードスコアを計算する必要があります。さらに、地域、専門性、負荷状況などに基づいて適切なリード担当者を割り当てることも、タイムリーなフォローアップとコンバージョンのために重要です。しかし、多数の見込み客に対してこれらのタスクを手作業で処理すると、時間がかかるうえに人的ミスも発生しやすくなります。
これらの見込み客をアプリケーションにインポートしている状況を想定します。このプロセスを効率化するために、見込み客のインポート完了後に実行されるバッチワークフローを作成できます。インポートされた見込み客に対して、リードスコアを計算し、リード担当者を割り当てる処理を設定します。
[実行前] ブロック
- リード処理の開始を関係者に通知するなど、初期化タスクを実行します。
バッチブロックの実行中
- 見込み客を扱いやすい単位で処理できるよう、バッチサイズを設定します。
- あらかじめ定義した条件に基づいてリードスコアを計算し、テリトリーマッピングや負荷分散アルゴリズムを用いて適切なリード担当者を割り当てるスクリプトを作成します。
[実行後] ブロック
- バッチ実行の成功または失敗に応じた処理を実装します。
- リード処理の完了を関係者に通知し、処理済み見込み客に関する統計情報（リードスコアや担当者の割り当て状況など）を提供します。
- この機能により、見込み客データを扱いやすいバッチ単位で自動処理でき、効率と正確性を確保できます。
ケース 2: カスタムスケジュールの設定
1 日を通して注文を受け付ける EC サイトを管理しているとします。注文管理という Creator アプリケーションを作成済みです。マーケティング担当者として、アプリケーションのレポートから顧客フィードバックを集計し、顧客満足度に関するレポートを毎月作成したいとします。この場合、バッチワークフローを作成し、データソースを指定して、必要なスクリプトを特定の時間に実行するよう設定し、収集したデータを関係者と簡単に共有できます。
9. バッチワークフロー作成のナビゲーションガイド
［ソリューション］タブに移動し、対象のアプリケーションを開きます。次に、上部の[ワークフロー]タブをクリックして、ワークフローダッシュボードに移動します。ここでバッチワークフローセクションを選択し、こちらに記載の手順に従います。
10. 注意事項
- バッチワークフローは、アプリケーションデータのインポート完了後または指定した時間に実行するよう設定できます。
- 同じフォームを基準に、条件が異なる、または同一条件の複数のバッチワークフローを作成できます。
- 1 つのバッチブロック内のすべてのバッチは順次実行されます。
- バッチワークフローの実行ステータスは、アプリケーションログセクションから確認できます。キューの状態、実行中の処理、完了ステータス（成功/失敗）などの情報が表示されます。
- 最初の5件のバッチブロック失敗について、エラーログを表示でき、失敗の原因を把握できます。
- ブロック内の 1 つ以上のバッチが失敗した場合でも、そのバッチのみがロールバックされ、バッチワークフローは他のバッチの実行を継続します。該当ブロックの失敗メッセージはログで確認できます。
- バッチサイズは10、50、100、200、500、1000件から選択してバッチワークフローを実行できます。
- 1 つのアカウントで同時に作成できるバッチワークフローは最大100件です。
- 1 日あたりにアカウントで実行できるバッチブロックの実行回数には、契約プランに応じた上限があります。
- 各バッチの実行タイムアウトは1 分に設定されています。たとえば、1000件のデータを 1 バッチブロックとして設定した場合、その1000件のデータの実行タイムアウトは1 分です。
- 同様に、[実行前]および[実行後]バッチブロックのタイムアウトは、それぞれ30 秒です。
11. 制限事項
- このワークフローは、現在連携フォームではサポートされていません。
- 1 つのバッチワークフロー内で作成できる変数は最大5個です。
- 1 つのアカウントで同時に実行できるバッチワークフローは 1 件のみです（作成日順に基づきます）。これにより、追加のバッチワークフローは実行キューに入れられ、公平なリソース配分とシステムリソースの過負荷防止が保証されます。
Deluge の制限事項
- '修正前' キーワードはバッチワークフローではサポートされていません。
- Infoメッセージは50KBを超えることはできません。超えた場合、メッセージは切り捨てられます。
- 許可されるファイル添付の最大サイズは15 MBです。この制限を超えた添付ファイルは、メール送信時に除外されます。
- 指定したファイルのコンテンツを取得したり、必要なコンテンツを使用してファイルオブジェクトを作成したりする場合、対象ファイルのサイズは2 MB未満である必要があります。
- getUrl()およびpostUrl()タスクは現在サポートされていません。
- グローバル変数に値を代入することはできません。ただし、infoステートメントを使用して参照することは可能です。
- 範囲指定での取得および削除の各操作は、最大5000件のデータまでに制限されています。
- 次の Deluge 操作はバッチワークフローではサポートされません。
- 項目のすべての値の取得
- 集計関数（distinct を除く）の、取得済みデータへの適用
- getall ビルトイン関数の使用
- クライアント関数
メモ: 上記の制限は、バッチワークフローから実行される関数呼び出しにも適用されます。