外部システムインターフェース設計の基礎知識

外部システムインターフェース設計の基礎知識

企業の業務システムが社内外のシステムと連携するには、インターフェースプログラムを構築します。

インターフェースプログラムには、送信元システムが受信システムの公開APIを呼び出す、あるいは受信システムの所定の格納先にファイルを格納するなど方式もいろいろあります。

本記事では、こうした外部システムとのインターフェースを設計する際の検討項目を紹介します。

インターフェースという用語の整理

最初に、インターフェースという用語の定義を確認しておきます。

外部設計とは?-SE虎の巻 -システムエンジニアのためのサイト- によると、インターフェースは「複数の物事の存在の中で、お互いの情報をやり取りするための仲介を行う媒体」であり、以下の3種類があるとされています。

  1. ハードウェア・インタフェース  ハードウェアの規約や、電気的な手続きの形式
  2. ソフトウェア・インタフェース  プログラム同士、機能同士がやり取りするデータ形式。またはデータのやり取りそのもの。
  3. ユーザ・インタフェース   画面など、システムを利用する上での操作性。
  1. この分類に沿うと、本記事で扱うものはソフトウェア・インターフェースにあたります。ただ、業務システム自体がソフトウェアでもあるため、外部システムインターフェース(I/F)という言葉を用いることにします。

外部システムI/F設計で検討する項目

外部システムI/Fを設計する際には、以下のような項目を検討します(参考書籍より引用)。

  • 接続先
  • プロトコル・手段
  • タイミング
  • インターフェース項目仕様
  • 認証・セキュリティ
  • 例外処理

接続先

まずは接続先を定義します。

これは同一企業内の他システムの場合もあれば、社外のシステムの場合もあります。社内であればイントラネット、社外であればインターネット上のネットワークを通じて接続を行います。

対象の接続先システムとの間で既存のインターフェースが存在する場合は、システム改修で対応できるのか、別で新規インターフェースを開発するほうがよいのかを検討します。

プロトコル・手段

自システムと接続先システムのインターフェースの方向を定義します。

  • 自システム→接続先システム
  • 自システム←接続先システム
  • 自システム⇔接続先システム(双方向)

接続方式を定義します(FTP、API、HTTPSなど)。

FTP(File Transfer Protocol)を用いる場合は、格納先へのputや、取得元からのgetなどをどうするのか取り決めます。APIの場合はサービス名や呼び出し時の引数パラメータなどを決めます。

また、データ形式も検討します。

  • XML(eXtensible Markup Language)
  • JSON
  • CSV(カンマ区切り、Comma Separated Value)
  • TSV(タブ区切り、Tab Separated Value)

CSVやTSV形式のデータでファイルをやりとりする場合は、ヘッダレコードやフッタレコードにファイル定義や件数などの情報を入れるのかも検討します。FTPの場合は書き込み途中でファイルを取得してしまうケースや通信エラーなどでデータ欠損がないかを確認するために、フッターに件数を入れておいてチェックすることがあります。

タイミング

インターフェースのタイミングとしては大きく分けて、リアルタイム(画面操作などに合わせて即時)バッチ(夜間など指定時間にまとめて)があります。

バッチについては、夜間などユーザの利用時間外にジョブネットを組んで自動処理するものや、日中に30分置きなどサイクルを決めて処理するものがあります。

インターフェース項目仕様

インターフェースでやりとりされるデータ項目を定義します。

  • 項目名(論理)
  • 項目名(物理)
  • データの長さ(バイト数と桁数)
  • データ型(数値、テキスト、日付など)
  • 項目説明(コード値が入る場合の定義など)

参考記事:インターフェース仕様書の読み方

認証・セキュリティ

相手先システムにログインする際の方式や外部認証のシステム、パスワードの更新サイクルを定義します。

例外処理

各種の例外事象に対して対応を定義します。

データベースの読み書きエラー、ネットワーク通信エラー、ファイル入出力時の読み書きエラーなどそれぞれに対して、リターンコードやログファイルによる検知の方法と、リカバリ方法(手動/自動の再送など)を定義します。

リアルタイム・双方向なインターフェースになると、順序立ったデータ送受信が必要な場合も出てくるため注意が必要です。

エラー処理設計の参考記事→運用を困らせないインターフェースのエラー処理とリカバリ設計

おわりに

外部システムインターフェース設計は、連携先との合意形成が重要になります(入念に合意形成を図っても、テストフェースで認識齟齬が検出されることは少なくありません)。

丁寧に言葉の定義を確認し合い、ドキュメントに残しながら検討を進めることをお勧めします。

関連記事

インターフェース仕様書の読み方

参考書籍

このブログを書いている人
電子書籍「システム導入のためのデータ移行ガイドブック」著者。 新卒から外資系コンサルティングファームに所属。15年に渡り販売物流、特にCRM領域のコンサルティングに従事。 100名を超えるプロジェクトのPMOなど全体を推進していく役回りや、ユーザ企業への出向を通じた実務経験を持つ。

このブログでは、自身がかき集めた知識や経験を共有する。クライアントへの提案やソリューション開発に直結しないガラクタのようなもの。将来再利用する自分のために。同じような悩みを抱える誰かのためにブログ「元外資系コンサルのガラクタ箱」を運営