この記事の内容
  1. 実行時刻と対象期間を分ける
  2. 欠損と遅延を失敗と区別する
  3. API制限と分割の単位
  4. 夜間の集計を試す例
  5. 担当者が朝に確認する項目
  6. 実行基盤を比較する
  7. 遅れて届く一件を照合する

実行時刻と対象期間を分ける

朝九時に実行する処理でも、前日一日分か、最後の成功以降かで対象は異なります。時差、休日、外部サービスの更新時刻を確認し、どの期間を完了したかを記録します。実行履歴の時刻だけを、データの処理済み範囲として使わないでください。

欠損と遅延を失敗と区別する

APIがゼロ件を返した場合、取引が本当にないのか、認証や抽出条件の問題なのかを確認します。前回の件数と同じである必要はありませんが、調べるべき条件を決めます。遅れて届く更新がある場合は、一定の期間を照合し直す手順も検討してください。

API制限と分割の単位

一度に全件取得するのか、ページや期間で分けるのかを外部APIの仕様に合わせます。上限に達した場合の待機、再試行、未処理の記録を用意します。実行基盤の月間枠が十分でも、外部APIの条件がなくなるわけではないことに注意してください。

夜間の集計を試す例

架空の夜間処理で、注文APIから一日分を取得し、集計を保存する例を使います。途中のページで失敗、前日分の追加、同じ期間の再実行を検証します。最初は集計だけを別に出し、既存の手集計と差分が説明できてから本番の参照先へ切り替えます。

担当者が朝に確認する項目

実行成功だけでなく、対象期間、取得件数、除外、失敗、保存先を確認できるようにします。通知が来なかった場合に元の受付や処理記録を調べる方法も残してください。処理が止まっていても入力が失われないよう、手作業の代替と再開の条件を事前に決めます。

実行基盤を比較する

Windmill、n8n、Activepiecesへ同じ仕様を当てはめ、独自コード、標準操作、保存がどこに置かれるかを比較します。人数、実行数、計算資源などの単位を同一視せず、必要な一か月の費用へ戻します。移行時には最後に完了した期間を引き継ぎ、漏れと二重処理を照合します。

遅れて届く一件を照合する

架空の前日集計を確定した後に、遅れた一件がAPIへ現れる例を作ります。その一件を無視するのか、一定期間を照合し直すのか、別の修正記録として扱うのかを業務の条件で決めます。最後の実行時刻だけを記録していると、対象期間の抜けを見つけにくくなります。処理済みの期間と、後から変わり得る範囲を分けて保存する設計を検討してください。

利用量から費用を確かめる

月の処理件数、課金対象のステップ数、再試行を入力し、サービスごとに異なる課金単位を確認できます。

費用を試算する

参照した公式情報

料金・提供条件・対応範囲は変更されることがあります。契約前に、下記の公式ページでご確認ください。

比較方針を読む広告について