APIは、既存プログラム単位ではなく、業務機能単位で設計します。

更新処理の二重実行を防ぐ

ネットワークがタイムアウトしても、IBM i側では処理が完了している場合があります。

その状態で再送すると、二重登録が発生する可能性があります。

1回目
API呼び出し
   ↓
IBM iでは登録完了
   ↓
応答だけタイムアウト

2回目
同じ要求を再送
   ↓
二重登録

対策として、要求ごとに一意なIDを付与します。

{
  "request_id": "BRANCH01-20260725-000123",
  "customer_id": "100001",
  "new_address": "..."
}

同じrequest_idが再送された場合は、新しい処理を実行せず、前回の結果を返します。

レガシー環境移行で特に注意すべきポイント

共有ID

古い基幹システムでは、部署単位の共有ユーザーが残っていることがあります。

共有IDを使うと、IBM iのログだけでは実際の操作者を特定できません。

すぐに個人IDへ変更できない場合は、まずSASEまたはZTNA側で個人を認証し、次のログを関連付けます。

SASE利用者ID
    ↓
接続時刻
    ↓
接続先IBM i
    ↓
5250共有ID
    ↓
IBM i操作ログ

最終的には、個人単位の識別へ移行することが望まれます。

TLS復号