よりきめ細いエラー通知が必要

　専用のクライアント・ソフトを各企業で導入してみると，従来のWeb EDIシステムなどにはなかった問題が発生した。クライアント・ソフトが出力するエラー・メッセージが不十分だったことと，各企業のプロキシ・サーバーを経由する場合に，クライアント・ソフトがASPサービスに接続できない場合があったことである。

　エラー・メッセージに関しては，「もっときめ細かく出力して欲しいという要望が多数の企業から出た」（JEITA eビジネス・プロセス・モデル-タスク・フォース［eBPM-TF］委員の小池 博氏）。Web EDIシステムなら，人がWebブラウザを操作して利用するため，さまざまな例外事象に対して，人が臨機応変に対応できる。しかしWebサービス・システムでは，これをシステムが自動的に判断しなければならない。きめ細かいエラー・メッセージがないと，さまざまな例外事象に対処するようにシステムを作り込めない。

　実際に今回の実証実験では，多様なエラーが発生した。例えば注文書などのデータで，項目が抜けていたり順序が間違っていたりしたというもの。「特にCSVでデータをやり取りしていた企業に多かった」（JEITA eBPM-TF委員の小池氏）。XML形式だと，タグ名を見てデータの意味を推測できるので，間違いが少なくなったとみられる。

　クライアント・ソフトとの通信は，「タイムアウトで切れてしまうことが予想以上に多かった」（JEITA eBPM-TF委員の小池氏）。主な原因は，各企業のインターネット接続が一時的に混雑したことだった。

プロキシ経由の接続に失敗する

　クライアント・ソフトのプロキシ経由の通信では，一部の企業で問題が出た。インターネット上のサイトにブラウザでアクセスするなら問題ないのに，専用のクライアント・ソフトでは外部にアクセスできない場合があった。

　プロキシ・サーバーの種類や設定は参加企業ごとに違った。プロキシ・サーバー経由でWebアクセスするのに，ユーザー認証を要求するポリシーを持つ企業もあった。認証方法には，HTTPのベーシック認証やマイクロソフトのNTドメイン認証など複数あった。

　クライアント・ソフトは，JavaベースのSOAPツール・キットやSSLライブラリを使って実装したが，プロキシでのユーザー認証が必要な場合に，SSL接続に失敗する場合があった。「SOAPツール・キットは入手可能なものをいくつか試したが，どうしてもうまくいかない企業があった」（JEITA eBPM-TF委員の小池氏）。

　そこでASPサービスのBtoBサーバーに，HTTPで接続するインタフェースを追加し，それに対応したクライアント・ソフトを開発した。HTTPで接続する場合は，やり取りするメッセージの内容を暗号化し，データが第三者に漏れないようにした。

次は業務ロジックなども実装

図2●次の実証実験ではビジネス・プロセスやTPAを実装
2002年10月以降に実施する実証実験のフェーズ2では，各企業に共通の業務ロジック（ビジネス・プロセス）と，契約条件を交渉して合意するためのebXML規定「TPA」を実装する。企業ごとの例外事項に依存しないように，できるだけ機能を共通化して実装範囲を広げたい考え。

　2002年10月以降に実施する実証実験のフェーズ2では，ASPサービスの機能を強化する。今回のフェーズ1では，発注者や受注者から受け取ったメッセージを相手に転送する機能しか提供していない。フェーズ2では，各社共通の業務ロジック（ビジネス・プロセス）もASPサービスで実行できるようにする（図2[拡大表示]）。例えば，セット・メーカーが，部品メーカーが対応できないリード・タイムを指定したときに，自動的にエラーを返すといったものだ。契約条件を交渉して合意するための「TPA」（トレーディング・パートナ合意）と呼ぶebXML規格も実装する。

　もっとも「ビジネス・プロセスや契約条件には企業ごとに例外事項がたくさんあり，一様にシステム化することが難しい」（JEITA eBPM-TF委員の小池氏）。そうした例外的な処理は，各企業の社内システムで実行するという選択肢もある。しかしASPサービス側でより多くの処理を実行したほうが，企業間でシステムを共通化できる部分が多くなり，結果としてシステムの導入コストが低くなる。実証実験のフェーズ2によって，どの範囲の機能をASPサービスで実現できるかを検証する予定だ。



JEITAコラボレイティブEDI標準の開発の背景

　JEITAが，JEITAコラボレイティブEDI標準の開発に乗り出したのは2000年1月のことである。開発を始めた要因は2つあった。

　1つは，製品開発期間の短縮に対する要求がますます高まるなかで，従来のEDIシステムでは主に受発注処理しかカバーできず，業務の効率化に限界が出てきていたこと。商品情報や商品ロードマップを交換したり，販売状況や生産計画を伝えたりするなど，メーカー間のさまざまなビジネス・プロセスをシステム化することが求められていた。

　もう1つは，こうした新しい業務を支援するWeb EDIシステムが乱立したことがある。Web EDIシステムを各セット・メーカーが独立に構築したため，その業務の流れ（ビジネス・プロセス）がバラバラだった。このため部品メーカーは，セット・メーカーごとに異なる煩雑な手作業を強いられていた。

　こうした背景からJEITAは，セット・メーカーと部品メーカー間のビジネス・プロセス全体を標準化するJEITAコラボレイティブEDI標準の開発を始めた。受発注処理だけでなく，新製品情報の交換や，サンプル品の発注，スペック情報の交換など，さまざまなビジネス・プロセスの標準化を進めている。今回の実証実験で実装した受発注関連のビジネス・プロセスは，2001年10月に最初に規格化したものである。