外部システムI/F設計の概要

外部システムI/F設計の概要

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

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

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

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

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

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

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

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

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

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

接続先

まずは接続先を定義します。同一企業内の他システムなのか、社外のシステムなのか。

既存のインターフェースが存在する場合、改修で対応できるのか、新規に開発するほうがよいのかを定義します。

プロトコル・手段

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

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

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

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

  • XML
  • JSON
  • CSV(カンマ区切り)
  • TSV(タブ区切り)

タイミング

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

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

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

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

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

認証・セキュリティ

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

例外処理

各種の例外事象に対して対応を定義します。データベースの読み書きエラー、ネットワーク通信エラー、ファイル入出力時の読み書きエラーなどそれぞれに対して、リターンコードやログファイルによる検知の方法と、リカバリ方法(手動/自動の再送など)を定義します。リアルタイム・双方向なインターフェースになると、順序立ったデータ送受信が必要な場合も出てくるため注意が必要です。

おわりに

外部システムI/Fは、連携先との合意形成が重要になります(入念に合意形成を図っても、テストフェースで認識齟齬が検出されることは少なくありません)。丁寧に言葉の定義を確認し合い、ドキュメントに残しながら検討を進めることをお勧めします。

関連記事

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

参考書籍

著者プロフィール

このブログを書いている人

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

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