NI+C EDIシリーズ＜第8弾＞API を利用した EDI？データ連携？解決法！

皆さん、こんにちは

日本情報通信 バリューオペレーション本部　井坂です。

EDI2024年問題が叫ばれるようになって久しいです。あと数年でPSTNからインターネットに移行しなければなりません。

みなさまにおかれては対策は取られているでしょうか。弊社でもさまざまなソリューションをご提供していますので悩み事や困りごとがあればご相談ください。

さて今回は、データ連携方法として今後利用拡大が見込まれるであろう、そして、ご要望やお問合せを頂くことが増えてきた

API（Application Programming Interface）を利用した電子データ交換（EDI）やデータ連携についてご紹介します。

APIを利用したデータ連携が増えてきた

近年、Web APIを利用したEDIやデータ連携を実現したい！というご要望やお問合せを頂くことが増えてきました。

間接材や物品材のWeb調達・購買を行うさまざまな B2B サービス、GCP（Google Cloud Platform）、AWS（Amazon Web Services） などです。

Web調達・購買サービスなどであれば、企業間取引である EDI を目的として、

GCP や AWS などであれば、データマイニングなどを目的としたデータ連携のご要望を頂いています。

EDI

企業間取引としての EDI は国内外の各団体などが中心となって、ANSI、EDIFACT や ebXML および EDIINT-AS などのように、

通信プロトコルやデータ形式が標準化されて、企業間データ連携の精度や利便性の向上、ワークフローの効率化が進んでいます。

Web API

一方、Web API は Web の技術を組み合わせて、それぞれのポリシー等に則って独自仕様のサービスを提供しますのでやや事情が異なります。

例えば、REST（Representational State Transfer） や SOAP（Simple Object Access Protocol）など、

異なるアーキテクチャを用いてそれぞれの API を呼び出す必要がありますので、Web API の種類や仕様の違いによって対応が異なってきます。

データ形式も、XML 、HTML、JSON（JavaScript Object Notation）、各種の画像ファイル形式など様々に異なります。

こういったさまざまな種類の API に対応する必要がありますので、既存システム対応可否やシステム間相互連携等、さまざまな観点で検討する必要があります。

そうした時に今後のデータ連携基盤は、これまでの EDI に加え、それらさまざまな種類の API にも対応可能なデータ連携統合基盤が必要になってきます。

困った・・・

自社内に API に対応可能なリソース（API開発ツールやそれを使いこなす人材、APIに対応可能なシステムなど）が整備されていればまだいいのですが、

開発やシステム等の調達コスト観点などから、API に対応するのはなかなか難しい。という企業も多いのではないかと思います。

ノウハウがない・・・

取引先からの要望に対応出来ない・・・

とはいえ、ビジネスチャンスを失わずに取引先の要望に応えたい。

このような状況で頭を抱える方も多いのではないでしょうか。

これで解決！

その問題、EDIPACK/WebScript で解決しませんか？

ということで、EDIPACK/WebScript について少し触れてみます。

EDIPACK/WebScript

さまざまな Web API に対応できる独自プロトコル（名称：WebScript）を EDIPACK に標準搭載しました。

Web APIサーバとWeb APIクライアントの両機能を提供し、公開されている様々な任意の Web API に対応することができます。

部品の再利用

EDIPACK/WebScript は、部品化されたプログラム群と、それを連結して機能化させたモジュールをさまざまに組み合わせたコンポーネントで構成されます。

HTTPリクエストボディの生成、HTTPリクエスト、HTTPレスポンス解析チェック・・・などがその一例です。

これらの部品やモジュール、コンポーネントは再利用が可能です。

なので、Web API ごとに異なる仕様でも、それらを再利用することで短期間で柔軟な対応が可能です。

こんな悩みごとも解決できます

弊社製品以外にも Web API を実現するために、プログラミングレスやローコードを特徴とした商用製品を利用する方法ももちろんありますが、

API 開発が必要な場合も多々あり、となると、その後のシステムを維持するコストも必要になります。

システムを維持するコストは、何も Web API に限った話ではもちろんないのですが、

先の通り、標準化され一般普及している通信プロトコルとは事情が異なりますので、Web API それぞれごとに開発からメンテナンスが必要です。

これらの悩みを解消すべく

EDIPACK/WebScript は、それぞれの API の対応に必要な部品やモジュール、コンポーネントを一環してパッケージ提供します。

また、EDIPACK/ASPサービスをご利用頂くと、ハードウェアやソフトウェアなどのシステム維持の負荷もなくなります。

開発や運用体制、そしてシステム維持のコストを抑制し、API 対応の面倒ごとから解放 される一助になればと考えています。

最後に：API は EDI に取って代わるのか？

近い将来、「 API は EDI に取って代わるのでは？」と捉えられがちです。

しかしながら、それぞれにメリット、デメリットがあります。

EDI と API は、それぞれの特徴を活かした棲み分けと共存によって、より有用なデータ連携が実現されていくだろうと考えています。

今回は、API を利用した EDI や データ連携の潮流、その解決法についてまとめてみました。

引き続き、NI+C EDIシリーズをよろしくお願い致します。