AS400 / IBM i の現場では、「古い5250画面をWeb化したい」「外部システムとAPI連携したい」「CSV連携をやめたい」「既存RPGを残したまま周辺だけ新しくしたい」という相談が増えます。Web化やAPI連携は魅力的ですが、現行業務を理解しないまま進めると、本番処理やデータ整合性を壊すことがあります。
AS400連携で最初に決めること
AS400 / IBM i を外部システムやWeb APIと連携するときは、最初に「どの処理を外に出すか」を決めます。既存のRPG/CL、DB2 for i、夜間バッチ、5250画面をすべて置き換えるのではなく、在庫照会、入出荷状況、請求データ、EDI連携など、外部から使わせたい範囲を切り出す方が現実的です。
- 照会系と更新系を分け、更新系は承認・ログ・排他制御を先に決める
- リアルタイム連携と夜間バッチ連携を混ぜない
- 文字コード、日付形式、ゼロ埋め、桁数を連携仕様に明記する
- 障害時にAPI側ログとAS400側ジョブログを突き合わせられるようにする
- 再送、再実行、重複更新の扱いを事前に決める
文字コードやCSV連携は AS400のCCSID・CSV文字化け確認、外部連携の障害切り分けは AS400本番障害の初動チェックリスト、改修前の影響確認は RPG/CL改修前の影響調査チェックリスト も合わせて確認してください。
この記事では、AS400のWeb化・API連携を検討する前に整理することを、保守現場の目線でまとめます。ツールや方式を決める前に、業務、データ、ジョブ、エラー時の扱いを先に確認することが大切です。
最初に決めるのは方式ではない
Web化やAPI連携の話になると、すぐに画面、フレームワーク、API方式、クラウド連携の話に進みがちです。しかし最初に見るべきなのは、対象業務とデータの流れです。受注、出荷、在庫、売上、請求、締め処理のどこに関係するのかを確認します。
| 確認項目 | 見る理由 | 関連ページ |
|---|---|---|
| 対象業務 | どの処理をWeb化・連携対象にするか | 販売管理システム保守ガイド |
| 対象データ | どのファイルを読み書きするか | DSPFFD / DSPPFM |
| 既存処理 | RPG/CL、夜間バッチ、帳票、外部連携の影響 | RPG/CL改修前の影響調査チェックリスト |
| ファイル連携 | CSV、IFS、FTP、再送、文字コード | IFS入門 |
| 障害時 | 再実行、二重送信、取り消し、ジョブログ | 本番障害の初動対応 |
Web化でよくある落とし穴
- 画面だけ新しくして、裏側の業務ロジックを理解していない
- AS400側の更新タイミングとWeb側の登録タイミングがずれる
- バッチ処理中に外部から更新してしまう
- CSV連携の再送や二重取込のルールがない
- 権限と個人情報の扱いを後回しにする
- エラー時にどちらのシステムで復旧するか決まっていない
API連携で先に決めること
API連携では、どのデータを、いつ、どちらが主として、どの単位で連携するかを決めます。リアルタイム連携が必要なのか、日次バッチで十分なのか、失敗時に再送できるのか、同じ伝票を二重処理しないかが重要です。
現行RPGの入力チェックや更新順を確認せずに連携口を追加すると、既存の業務ルールを欠落させることがあります。方式選定と並行して、呼び出す処理の前提条件を一覧にします。
| 論点 | 確認すること |
|---|---|
| 主システム | AS400側が正か、外部側が正か |
| 連携タイミング | 即時、定期、夜間、手動再送 |
| エラー処理 | 失敗時の通知、再実行、取り消し、二重防止 |
| データ形式 | CSV、JSON、固定長、文字コード、桁数 |
| 認証・権限・通信 | 呼び出し元の認証に加え、会社・部署・レコード単位の閲覧権限を検証する。TLSを使い、認証情報や顧客情報をURL・ログへ残さない |
| 負荷・障害時 | 検索件数、タイムアウト、呼び出し頻度を制限し、更新APIは二重送信・途中失敗時の扱いを決める |
リプレースとは分けて考える
Web化やAPI連携は、全面リプレースとは別の選択肢です。AS400を残しながら周辺の画面や連携を改善するか、置き換えを検討するかは、モダナイゼーション・リプレース判断ガイドの比較項目で整理してください。
AS400連携方式を目的から選ぶ
「AS400をAPI化する」と言っても、既存RPG/CLを外部公開する方法、外部アプリからDB2 for iへ接続する方法、IFSとファイルで受け渡す方法では、確認する場所が違います。方式名から選ばず、対象業務と更新の有無から絞ります。
| 目的 | 方式の例 | 先に確認すること | 主な注意点 |
|---|---|---|---|
| 既存RPG/CLの処理を外部から呼ぶ | IBM i Integrated Web Services | 入出力パラメーター、実行ユーザー、コミット範囲 | 既存処理が対話ジョブやライブラリー・リストを前提にしていないか |
| 外部アプリからデータを参照・更新する | ODBC / JDBC / SQL | SQL権限、ジャーナル、トランザクション、業務ロジック | RPG側の入力チェックや在庫引当を飛び越えないか |
| 定時にまとまったデータを渡す | IFS、CSV、SFTP | CCSID、桁数、ファイル確定条件、再取込防止 | 転送途中の読込み、二重取込、処理済みファイルの残し方 |
| 5250画面の操作性を変える | Web画面やフロントエンドを追加 | 画面裏のRPG/CL、Fキー、セッション、権限 | 見た目だけを変えて既存の業務判断を欠落させないか |
既存ILEプログラムやサービス・プログラムをWebサービスとして公開する選択肢は、IBMのIntegrated Web Services for IBM iでも確認できます。DB接続を使う場合はODBC/JDBC接続の確認ポイント、ファイル連携はIFSの基本も合わせて確認してください。
照会APIと更新APIを同じ設計にしない
在庫照会APIは、参照権限、応答項目、検索条件、負荷を確認すれば小さく始めやすい処理です。一方、受注登録APIは、在庫引当、得意先チェック、締め状態、伝票番号採番、ジャーナル、後続バッチまで影響します。同じ「API」という名前でも、更新系は戻し方まで決まらなければ本番へ出せません。
| 確認 | 照会API | 更新API |
|---|---|---|
| 権限 | 必要なファイルの参照だけに絞る | 対象処理に必要な更新だけに絞る |
| 再試行 | 同じ照会を再実行できる | 受付番号や一意キーで二重登録を防ぐ |
| 障害記録 | 検索条件と応答エラーを残す | 更新前後、ジョブ、受付番号、結果を残す |
| 復旧 | 原因解消後に再照会する | 取消、再送、手動補正の承認手順を決める |
更新APIを設計する時は、API側のエラーだけで判断せず、IBM i側のジョブログとジャーナルで「どこまで更新されたか」を確認できるようにします。本番データや認証情報を外部ログへそのまま出さず、調査に必要な受付番号と処理結果を残します。
