インターフェースプログラムは、あるシステムから他のシステムへデータを連携する仕組みです。装置と人間の接点として入出力を行う画面のことをユーザーインターフェースと呼びますが、ここでは、そうした画面機能とは区別し、何らかのトリガーでデータを連携する処理のことを扱います。
インターフェースは送信元と受信先で合意したデータフォーマットでやりとりしますが、想定外のデータが連携された時に備えてプログラムはエラー処理設計を行います。
本記事では、受信元で作成されたIFファイルを使って変換・更新処理を行う時のエラー設計について紹介します。
インターフェース処理の終了パターン
インターフェースは大きく3つの処理パターンがあります。
1つ目は、正常終了。正常に登録や更新処理を行えたパターンです。
2つ目は、業務エラーです。送受信の取り決めと異なるフォーマットやデータが来た場合、エラー内容によって警告のみを出力して後続に進める警告終了と、処理を中止して後続は進めない異常終了に分けて処理を行います。
3つ目は、システムエラーです。サーバが停止していて応答がなかった、データベースに接続できない、ネットワーク通信エラーなどエラー内容は挙げきれません。これらは全て異常終了させ、後続処理があっても中止し、システム運用担当による影響調査やリカバリ対応がなされていきます。
エラー処理として設計する内容
フォーマットチェック
ファイルフォーマットが仕様通りかチェックを行います。ヘッダやフッタから想定通りに情報が取得できない時や、データ領域のバイト数（固定長ファイルの場合）や項目数（カンマやタブ区切りの場合）が異なる場合もこのチェックでエラー検知を行います。
一意チェック
レコードを一意に特定するPK（プライマリーキー）で重複がないかチェックを行います。データベースでPKは通常1項目ですが、複数項目で一意になる場合もあります。いずれにしても重複が存在すると他テーブルとの結合時に件数が実際よりも増えてしまったり、結果の書き込み時に一意制約エラーで失敗したりするので、加工処理前に、一意かどうかのチェックは必要です。
必須項目チェック
加工処理や書き込み処理で必須となる項目には値が入っていることをチェックします。値が入っていない場合は、対象レコードと項目名とエラー内容をログ出力します。
例外的に何らかの固定値を入れて処理を継続する以外は、業務起因ですが異常終了が必要です。ここで異常終了させなくても後の加工や書き込みで異常終了するため、想定外の事象を回避するためにも先に処理することが賢明です。
外部キー参照チェック
マスタやトランザクションとリレーションを持つデータの場合は、それぞれを参照する外部キー項目（相手側のプライマリーキー項目）が存在するものかどうかチェックします。商談データが顧客項目を持っている場合は、顧客コードというキー項目が顧客マスタデータに存在するものかどうかチェックを行います。
存在しなければ、対象レコードと存在しなかった値とエラー内容をログ出力します。
処理の続け方は3種類考えられます。
警告終了にして処理を続けるか、該当レコードはエラーとしてスキップして次レコードに移るか、後のレコードも処理せず該当プログラムを異常終了させるかです。
画面上で値がブランクになるだけなら警告処理で継続するのでOKです。
値ブランクになることが集計レポートの該当行の結果に影響を与えるなど問題がある場合はエラーとしてスキップします。これによりエラーレコード以外のデータを救うことができます。
ただし集計レポートの合計数値などに影響が出る場合は、それを防ぐために、行スキップも行わず異常終了させます。
エラーリカバリと根本解決について
発生したエラーは業務影響に応じた処理を行い、ログ出力しシステム運用を通じてユーザに通知されます。送信元システム側での対応でインターフェースを再送する場合と、受信側でのマスタメンテナンスを行ってから処理の再実行など、状況ごとに用意したリカバリ手順で対応を行います。
しかし本来はこうしたエラーは発生しないよう運用設計すべきです。取り決めた以外のフォーマットやデータは連携させないよう送信元でチェック機能を設けるべきですし、マスタ参照エラーが発生しないようマスタインターフェースのやメンテナンス手順の不備を解消することが重要です。