コンテンツにスキップ

ADR 0023 · JWNET は Web-EDI を本番方式として運用する（準備中を解除・標準EDI は将来 TODO）

背景

JWNET 連携の方式は Web-EDI(0019) → 標準EDI 一本化(0020) → 当面 Web-EDI(0021・#506/mig208) → 標準EDI 再確定+機能準備中(0022・#507/mig209) と揺れた。最終的に、Web-EDI を本番運用の方式として確定し、EDI 機能を「準備中」ではなく通常提供に戻す。標準EDI は魅力的な長期方向だが、go-live が外部律速（EDI事業者登録の審査・接続テスト・IPsec/方式確定＝方式B の SaaS EDI でも拡張Z手順+IPsec は要照会）で当面到達できないため、将来の TODO として保持する（設計・調査・コードは資産として git 履歴・ロードマップに保全済み）。

判断

JWNET は Web-EDI を本番方式として運用する。EDI 機能の「準備中」を解除し、標準EDI は将来 TODO とする。

  • Web-EDI を本番方式とする。collector の JWNET送信 / JWNET設定 を通常提供（nav 活性）に戻す（#507 で入れた status:'soon' gate と準備中バナーを撤去）。搬送は HTTPS + 送受信 BOX（接続テスト不要）・WE-01 申込で本番到達。
  • develop を Web-EDI 実装へ復帰: #507（標準EDI 再確定+準備中）を revert し JWNET コードを prod(main/v1.68.0) の Web-EDI 状態へ戻す。DB は forward migration で整合: mig205-209 は dev 適用済で un-apply 不可のため、mig210 で mig209 を逆転し Web-EDI（jwnet_credentials 復元・2 層表 drop・Web-EDI authz）へ戻す。dev も prod も forward のみで整合。
  • 標準EDI = 将来 TODO: bd 起票 wl-qvt（標準EDI 対応（将来・Web-EDI から移行））+ git 履歴（#504/#505/#507・mig205-209）+ 標準EDI ロードマップ + 方式B（SaaS EDI）ベンダー調査 を資産として保持。外部（事業者登録・接続テスト・IPsec/方式）が整った時点で着手し、その時に本 ADR を supersede する go-live ADR を起こす。

本 ADR は 0021 を supersede し、0022（#507 で採択・その後 revert）は git 履歴に残す（rewrite しない）。

帰結

得るもの

  • JWNET に到達できる実働経路（Web-EDI）を本番方式として即運用可能（WE-01 ~10 営業日・インフラ投資不要・IPsec 争点を今解かなくてよい）。prod(v1.68.0) は元から Web-EDI コードを保持し、develop も本 ADR で同一状態へ戻る。
  • EDI 機能が通常提供に戻り、事務が使える（準備中で隠れない）。
  • 標準EDI の設計・調査・コードは資産として保全され、再開時にやり直さない。

手放す / 引き受けるコスト

  • 日次報告の搬送は人手のまま（要求/結果ファイルを人が送受信 BOX で授受）。
  • ASP / 自動搬送は当面保留（標準EDI 前提）。
  • migration の往復 cruft: develop に mig205-210（標準↔Web-EDI を 3 往復）が積む。次の develop→main リリースで prod に 205-210 が順次適用され net Web-EDI（prod は元から Web-EDI なので実質変化なし・番号連番でギャップなし・順序整合は docker proof が担保）。

次のアクション

  1. Web-EDI 本番運用（ユーザー・外部）: WE-01「Web-EDI 機能利用申込書」提出（~10 営業日）→ EDI利用確認キー等の設定 → demo 検証 → 本番。
  2. develop の Web-EDI 復帰（本 ADR と同一スライス）: #507 revert + mig210 + 全 docker proof / verify。
  3. 標準EDI TODO（将来）: bd 起票の issue（wl-qvt）を維持。外部前提が整ったら go-live ADR を起こして着手。