受け付けた後まで、処理の流れを設計する。

画面の返答と、業務の完了を分ける

同じ依頼がもう一度届いても、結果を重ねない

非同期の呼び出しでは、失敗後の再試行に加え、同じイベントが複数回届く場合を考慮します。受付番号など業務に合う識別子を決め、すでに処理した依頼と新しい依頼を区別する設計を検討します。

通知を二重送信する、同じ申請を二度登録するなど、重複したときの影響を先に挙げます。どこで処理済みと記録するか、途中で止まった場合に何を再開するかは、データの更新方法と合わせて決めます。

失敗を発見してから、再開するまで

1. 失敗した依頼を特定できるようにする

   入力と処理状態を調べるための情報を整理します。記録に個人情報を残しすぎないよう、識別子と詳細データの保管先を分ける案も検討します。

2. 再試行してよい原因かを分ける

   一時的な接続失敗と、入力や権限の不備を区別します。再試行の回数だけで解決しようとせず、修正する担当と確認方法を決めます。

3. 結果を確認して状態を閉じる

   依頼を再実行した場合は、業務の結果と重複の有無を確認します。受付状態だけを完了へ書き換えて、実際の結果との食い違いを残さないようにします。

実装前にそろえる、処理の契約

入力と結果

必要な入力、不正な入力の扱い、成功とみなす状態を具体的な例で整理します。

権限と接続

処理が読むデータ、書くデータ、呼び出す外部サービスを分け、必要な操作の範囲を確認します。

運用と変更

処理を止める条件、失敗を確認する担当、変更前へ戻す方法を決めます。実行環境の制限は採用する方式ごとに最新資料で確認します。

自動実行に任せる範囲を考える