システム連携で失敗したら?重複更新を防いで再実行する確認表

システム開発・連携 · 実務ガイド
システム連携で失敗したら?重複更新を防いで再実行する確認表
営業の受注システムから出荷システムへ注文を送った後、返事がなくて再送を迷う担当者へ。まず受信側に保存されたかを確認します。返事がないことは、登録されていない証拠ではありません。同じ注文を再送すると、重複する場合があります。
この記事では、注文E044の架空例で、失敗・結果不明・保存済みを分けます。送信内容と保存結果を記録し、提供会社へ再実行の条件を確認できる表を作れます。

この記事でできるようになること
- 返事がない状態と、保存されなかった状態を区別できる
- 同じ注文の重複を避ける再実行条件を確認できる
- 送信・保存結果・判断担当を記録できる
01 / システム開発・連携
送信エラーが出たら、注文は登録されていない?
送信担当者は、画面のエラーだけで決めず、受信側の保存結果を確認します。

説明用の架空例では、営業担当者が注文E044・商品P01・10箱を10時に出荷システムへ送ります。画面は待ち時間を超えてエラーになりました。担当者が知りたいのは「送信ボタンを押せたか」だけではなく、出荷側へ注文が保存され、次の担当者が見つけられるかです。
返事が届かなくても、受信側では保存が終わっている場合があります。反対に、入力を受け付けた後、別の処理で失敗する場合もあります。連携担当者は、保存されなかったと確認できた状態、結果が不明な状態、保存済みと確認できた状態を分けて記録します。
HTTPの状態コードは判断の手掛かりですが、具体的な意味は提供会社の仕様と合わせて読みます。例えば受付を示す返事が、業務処理の完了を意味するとは限りません。エラーコードだけを見て「未登録だから再送」と決めず、保存結果を調べる方法も用意してください。
受信側の管理者へ注文E044の保存結果を確認し、確認表の「保存結果」欄へ未保存・不明・保存済みを記入してください。
この章の根拠:出典2
02 / システム開発・連携
再送する前に、どの記録を集める?
連携担当者は、送信番号・送信内容・送信時刻・返事・受信側の番号を同じ行に残します。

注文E044を送る際の依頼番号をRID009とします。確認表へ、E044、RID009、商品P01、10箱、送信時刻10時を残します。注文番号と送信の依頼番号は役割が違います。1つの注文を修正して送り直すこともあるため、どの内容をどの依頼で送ったかを追える状態にします。
受信側へ問い合わせるときは、「エラーが出た」だけでは探しにくくなります。担当者は番号、時刻、保存先、送信内容を渡し、保存されたレコードと照合してもらいます。架空例では受信側の記録R010が見つかり、E044・P01・10箱が一致したため、保存済みと確認できました。
確認のためにパスワードやAPIキーの実値を表へ貼り付けないでください。提供会社へ渡すログの範囲と共有方法を決め、必要な番号・時刻・状態を整理します。顧客の情報が含まれる場合は、担当者が自社の取扱ルールに沿って共有範囲を確認します。
| 記録 | 内容 | 確認結果 |
|---|---|---|
| 送信 | RID009/E044/10箱 | 10時に送信 |
| 画面の返事 | 待ち時間超過 | 保存結果は不明 |
| 受信側 | R010/E044/10箱 | 内容一致・保存済み |
連携担当者へ送信ログを依頼し、「番号・内容・時刻」欄へE044とRID009、受信記録R010の対応を記入してください。
この章の根拠:出典1
03 / システム開発・連携
同じ依頼番号なら、再送しても重複しない?
担当者は、受信側の重複防止仕様と番号の保持期間、内容変更時の扱いを確認します。

同じ依頼番号を付ける仕組みは、同じ依頼の再送を見分ける手掛かりです。ただし、送信側がRID009と書くだけでは、受信側に注文が2件できるのを防げません。提供会社へ、番号の記録と登録処理をどう結び付け、同じ番号を受けたとき何を返すかを確認します。
確認表には、番号が有効な期間、同じ送信者であることの条件、同じ内容で再送する条件を残します。番号の保持期間が過ぎた後は、以前の依頼と分かるとは限りません。期間切れや条件不明の場合は、受信側の保存記録を調べて担当者が判断する手順を決めてください。
注文数量が10箱から12箱へ変わった場合は、同じ内容の再送ではありません。RID009を使い回して上書きできると考えず、提供会社が定める変更処理へ進みます。注文を識別する番号の一意性も必要ですが、番号の制約だけで通信中の再実行がすべて安全になるわけではありません。
提供会社へ同じ依頼の扱いを確認し、「再実行条件」欄へ番号の保持期間・同じ内容・変更時の方法を記入してください。
04 / システム開発・連携
未保存と確認できたら、誰が再実行する?
会社は再実行する担当者と回数・間隔のルールを決め、結果を確認して記録します。

別の架空ケースでは、入力欄の数量が空欄で、受信側の仕様とログから未保存だと確認できたとします。担当者は元の注文で数量を確認し、決めた手順で内容を直します。すべての入力エラーで未保存だと断定せず、このケースで保存されなかった根拠を残します。
営業、出荷、提供会社の全員が同時に再実行すると、記録が追いにくくなります。会社は対応する担当者を決め、再送中は別の担当者が同じ注文を手入力しないよう共有します。自動再試行が動く場合は、それを含めて現在の状態と、手動対応との関係を確認してください。
再実行を無制限に繰り返す運用にはしません。回数や間隔は受信側の制限、障害の状態、重複防止の条件に合わせて決めます。再実行後は、返事だけでなく注文E044の数量と受信側の件数を確認し、保存結果が不明なまま次の作業へ進めないでください。
対応責任者へ再実行する担当を確認し、「実行・確認結果」欄へ実行時刻と受信側の件数・内容を記入してください。
05 / システム開発・連携
保存できたら、出荷まで完了したことになる?
注文の保存と出荷の完了を分け、次の担当者が正しい注文を見つけられるか確認します。

受信側にR010が1件できたことは、注文の保存が確認できたという結果です。在庫の確保、納期の確認、実際の出荷まで終わったとは限りません。会社は、連携でどこまでを成果物とするかを決め、保存後に誰が何を確かめるかを業務の流れに合わせます。
出荷担当者はE044の品目・数量・希望日を元の注文と比べ、必要な確認へ進みます。保存済みなのに出荷一覧へ表示されないなら、表示条件、後続処理、番号の対応を確認します。探せないから新しい注文を手入力する前に、R010がどこで止まっているかを調べてください。
繰り返すエラーは、送信の入力条件、返事の表示、確認手順のどこで迷ったかを整理します。担当者が毎回提供会社へ聞く必要があるなら、保存結果を調べる画面や共有先を見直します。操作時間だけを短くせず、送信から保存確認までの担当者の手間を記録しましょう。
出荷担当者へR010を渡し、「後続確認」欄へ在庫・希望日・出荷記録の確認先を記入してください。
この章の根拠:出典2
06 / システム開発・連携
まとめ:保存結果を確かめてから、条件に沿って再実行する
担当者は依頼番号と内容を残し、受信側の保存結果・再実行条件・対応担当をそろえます。

連携のエラーで不安になるのは、担当者が悪いからではありません。「どこまで終わったか」を調べる記録がないと、誰でも再送を迷います。送信依頼と受信記録を結ぶと、結果不明の注文と、未保存・保存済みの注文を分けて対応できます。
この記事のE044・RID009・R010は説明用の架空例です。自社では、提供会社の仕様から番号の保持期間、内容変更の方法、保存結果の調べ方を確認します。同じ依頼番号があっても仕様が不明なら安全とは評価せず、確認する担当者と連絡先を残してください。
まず最近迷った連携1件を選び、下の確認表へ番号・時刻・送信内容・受信結果を書いてください。結果が不明なら受信側の管理者へ照会します。未保存と確認できた場合も、再実行する担当と条件を合わせ、実行後の件数と内容まで記録してください。
受信側の管理者へ結果不明の連携1件を照会し、確認表の「保存結果」と「再実行条件」欄を埋めてください。
仕事の流れから、顧客との接点まで。
一体で見直す、最初の一歩を。


