競争の激しい流通業界では、競争優位を得るために、顧客が求める価値をタイムリーに提供する様々な試みが行われています。
競争の激しい流通業界では、競争優位を得るために、顧客が求める価値をタイムリーに提供する様々な試みが行われています。
このような中、食品スーパーマーケットチェーンを展開する株式会社カスミ、およびパートナー企業である食品メーカー、卸の4社は、商品の付加価値を高めることを目的に、商品情報、販促情報、販売実績といった情報を交換する流通コラボレーション「Kasumi B2B Integration Project(以下B2Bプロジェクト)」を実施しています(図 1)。
本B2Bプロジェクトは、交換される情報形式として柔軟で加工の容易なXML文書を活用したこと、またビジネスプロトコルにebXML MS(Message Service)仕様をベースとしたメッセージプロトコルを用いたことを特徴としています。
以下、本文ではB2Bプロジェクトへの参加経験を通して判明したebXML MS V1.0仕様の不備な点、およびB2Bプロジェクトにおいて取った対応策について記述します。
企業間でコラボレーションを実現するには、データの交換、すなわちEDIを行うわけですが、このEDIの標準化対象は大きく次の4つがあります。
本B2Bプロジェクトでも、多数の企業が容易に接続できるように情報表現規約について標準化を行っています。「シンタックスルール」としてはXMLを使用します。「標準メッセージ」としては、商品情報、販促情報、販売実績、棚割り情報などのXMLビジネス文書フォーマットが新規に開発されています。また「データエレメントディレクトリ」、すわなち辞書には、GLN(Global Location Number)や(財)流通システム開発センターが規定しているJICFSコードなど既存のコードを活用することが決められています(図 2)。
また、インターネットを利用するため、情報伝達規約としては、Hypertext Transfer Protocol [HTTP] Version 1.1を採用しています。また、ワイヤセキュリティは相互認証型のSecure Sockets Layer (SSL) v3またはTransport Layer Security (TLS) 1.0などの技術を利用して確保します。さらに、業界に依らずインターネット上でデータ交換を行うためには、ビジネス文書をくるむ、「エンベロープ」と呼ばれる交換メッセージに関するメタ情報の必要性が広く認識されています。
データを様々な企業、または業界を越えて交換するには、独自エンベロープ形式を使用するのではなく、標準形式を使うことが求められます。
BizTalk FrameworkやRNIF(RosettaNet Implementation Framework)などもエンベロープ形式を規定していますが、本B2BプロジェクトではebXML MS 1.0仕様をメッセージ交換のベースとして採用しました。これは、国内流通標準化団体を含む各種標準化団体における標準開発動向、ebXML仕様の開発に関与している団体・企業、さらには、プロジェクト開始の前年の2000年7月に国際流通業標準化団体であるGCI(Global Commerce Initiative)がebXML MS仕様の採用を表明している点などを総合的に判断して、選択されています(図 3)。
しかし、ebXML MS 1.0の完成度は十分とはいえず、曖昧な箇所や、実ビジネスにおいて不十分と思われる箇所があったため、本B2BプロジェクトではebXML MS仕様の機能実装の取捨選択、機能追加を行っています。以降の節では、これらについて述べていきます。
[図 4]は通信プロトコルとしてHTTPを利用した場合のebXMLメッセージ構造を示しています。ebXMLメッセージはSOAP Messages with Attachments仕様(MIME/Multipartメッセージエンベロープ)に準拠した構造を持っています。
メッセージパッケージは、大きく、「ヘッダコンテナ」と呼ばれるマルチパートMIMEのルートパートと、それに続く0個以上の「ペイロードコンテナ」と呼ばれるMIMEパートで構成されています。
次にHTTPヘッダとMIMEヘッダ、およびペイロードコンテナについて簡単に説明します。
ebXML MS仕様は通信プロトコル独立で、任意の通信プロトコルを使用することができますが、本B2Bプロジェクトでは、開発コストを抑えるためにHTTPプロトコルのみを採用しています。
POST 指定URL HTTP/1.1 |
Host: www.xxx.co.jp |
SOAPAction: "ebXML" |
Content-type: multipart/related; boundary="BoundarY"; type="text/xml"; |
start="<ebxhmheader111@xxx.co.jp>" |
項目のいくつかについて以下に簡単に説明します。
メッセージパッケージの各MIMEパートには次のようなMimeヘッダを付加します。
--BoundarY |
Content-ID:<ebxhmheader111@xxx.co.jp> |
Content-Type:text/xml; charset="UTF-8" |
[説明]
ebXML MS仕様ではペイロードコンテナに格納するオブジェクト種別についての制約はありません。テキストでも、バイナリデータでも格納することができます。本B2Bプロジェクトでは、プロジェクトにおいて開発した、「商品情報」、「販促情報」、「販売実績」、「棚割り情報」などのXMLビジネス文書を格納しています。
また、ペイロードに関する情報は、ebXML extensionのManifest要素に記載されます。
Manifest要素はid、およびversion属性と、1つ以上のReference要素から構成されます。Reference要素は次に示す属性やSchema要素、およびDescription要素などから構成されています。
属性名 | 値 |
---|---|
eb:id | 一意な任意の文字列。 |
xlink:href | (必須)参照されるペイロードコンテナのMIMEヘッダのContent-IDを設定します。 |
要素名 | 値 |
---|---|
Schema | 文書インスタンスを定義するスキーマに関する情報で、location属性には、ペイロードオブジェクトのスキーマロケーションを記述します。 |
Description | この要素は任意ですが、"商品登録依頼"など内容を説明するわかりやすい任意の文字列を設定します。日本語を入力する場合は、xml:lang属性に"ja-JP"を設定します。 |
<eb:Manifest eb:id="Manifest" eb:version="1.0"> |
<eb:Reference eb:id="payload01" xlink:href="cid:payload-1"> |
<eb:Schema eb:version="1.0" |
eb:location="http://www.dsri-dcc.jp/retailCollaboration/2001/11/b2b/ProductRegistration.dtd"/> |
<eb:Description xml:lang="ja-JP">商品登録依頼<eb:Description> |
</eb:Reference> |
</eb:Manifest> |
また、2002年3月には、(財)流通システム開発センターにおいて、「商品マスタ」、「発注」、「入荷予定」に関する標準XMLビジネス文書フォーマットJEDICOS-XMLが策定されており、他企業との接続性を考慮し、「商品情報」ビジネス文書など同じ目的を持つ文書はJEDICOS-XMLへの移行を検討しています(図 5)。
ebXML MSには、複数サーバー間でデータを転送するマルチホップを実現する機能など、ビジネスにおけるいくつかの利用形態を考慮した機能が含まれています。しかし、プロジェクトの開始時点ではebXML対応のBtoBサーバーが存在しないという事情もあり、ebXML SOAP extension要素のうち、1対1の非同期メッセージ交換に最低限必要な機能であるMessageHeader要素、ErrorList要素、およびManifest要素のみを利用することにしました。 また、相互の仕様の解釈の違いによる通信エラーを回避するために、ヘッダコンテナに設定する値についてもプロジェクトで規定を設けています。次に、MessageHeader 要素に設定する値の一部を紹介します。
要素名 | 値 |
---|---|
From/PartyId | type属性値として"Retail-J"を設定し、GLNを利用します。 |
To/PartyId | 同上 |
Service | type属性には"Retail-J"を設定し、要素値として固定値を設定します。 |
Action | 処理内容に応じて以下の文字列を設定します。 商品カタログ送信 : ProductRegistration 販促情報送信 : PromotionPlan など |
MessageData/MessageId | 値は次の形式を持ち、ローカル部は任意ですが、メッセージ間で一意な値を設定します。 xxxx-xxxxx-xxxx@yyy.co.jp ローカル部 企業固定 |
MessageData/Timestamp | (必須要素)ebXMLメッセージハンドラで現在時刻(XML SchemaのtimeInstant型データ)を設定します。 |
MessageHeader要素の子要素のうち、QualityOfServiceInfo、およびSequenceNumberは使用していません。なお、これら要素はebXML MS 2.0 rev Cでは、要素名称が変更されていたり、削除されていること、さらに今回利用したextension要素がebXML MS 2.0 rev CにおけるCore Extension Elementsとほぼ同等であることから、ebXML MS 2.0仕様への移行コストを低減できるのではないかと思われます。
ビジネス文書、例えば商品カタログのXML文書の処理がどれくらいの時間内で完了するかを予め見積もることが困難なため非同期メッセージ通信を採用しています。メッセージの流れは次のようになります。
上記のメッセージの流れにおいて、B2BプロジェクトではebXML MS仕様とは異なる実装を行っています。
まず、ebXML MS 1.0では通信の同期/非同期はVia要素のSyncReply属性で示すことになっていますが、B2Bプロジェクトでは非同期通信のみが使用されることを理由にVia要素を利用していません。ebXML MS 2.0 rev CではVia要素がなくなり、CPA(Collaboration Protocol Agreement)中でその指定を行うよう変更されていますので、ebXML MS 2.0への移行を考えると、使用していないことがかえって幸いであったといえます。
次に、ebXML MS 1.0では、非同期通信に関する記述が非常に少なく、Appendix B.2.4およびB.2.5が解釈の中心となっているため、解釈の相違による問題の発生が危惧されます。これらの部分には、非同期時には、HTTPレスポンスはHTTPボディが空で、HTTPステータスコードがのみが返されるものと記述されています。一方、Via要素にはackRequestedという属性があり、SignedかUnsignedが指定されるとAcknowledgement要素を含むebXMLメッセージを返す必要がありますが、返信されるebXMLメッセージはHTTPレスポンスで返すのか、あるいは独立したHTTP POSTで返すかについては明確な記述はありません。結局、B2Bプロジェクトでは、Acknowledgement要素を使うメリットは特に無いと判断し、HTTPステータスコードのみを返す方式を採用しました。また、HTTPステータスコードには、HTTPボディが空であるため、より状況に合致しているということで"202"を使用しています。
さらに、要求(Request)メッセージの受信側は送達確認(Ack)メッセージを返す前に、ヘッダコンテナ部のXML文書を構文解析していますが、これは、エラーを可能な限り通知するという本B2Bプロジェクトに沿った処理手順に沿ったものです。たとえば、ヘッダコンテナに誤りが存在した場合、非同期形式のメッセージ交換では、いったん送達確認(Ack)メッセージを返してから、新たなHTTPコネクションでエラーを示す応答(Reply)メッセージを返すのが一般的な流れです。しかし、この流れでは、何らかの問題で要求(Request)メッセージのMessageID要素に値が設定されていない場合には、どのメッセージでエラーが発生したかを相手側に通知するこができません。我々は、このような場合でも送信元にエラーを通知できるよう、エラーを通知するメッセージを同一HTTPコネクションのレスポンスで返すようにしています。
ebXML MSの仕様に、すべてのエラー発生原因とその処理方法が記述されているわけではありませんので、設計時に、エラーの発生原因を整理して対応を決めていく必要がありました。
エラーの発生状況には以下が考えられます。
ebXML MS 1.0仕様ではペイロードに格納する情報形式に制約を設けていないため、ペイロード中のエラーの通知については規定が存在しません。このため、ペイロードデータ中のエラーの通知は何らかのルールを決めておく必要があります。
ここで、ペイロードコンテナ、すなわちXMLビジネス文書の内容に関するエラーとしては、妥当性検証で検出される、XML要素の出現順序誤り、必須要素の欠落、出現回数誤り、範囲外データ(値の上限/下限、文字列の長さ)、型不整合、規定されていない選択肢、などがあります。
また、W3C XML Schemaによるスキーマ定義ファイルを用いた妥当性検証ではエラーとならないが、アプリケーションや人間によって検出されるエラーとしては、例えば、アプリケーションにより検出されるエラーとしては、相手側DBに既に存在する商品の情報を新規登録依頼した場合や、人間によって検出されるエラーとしては、データに異常と考えられる値(小売価格が0円など)が含まれている場合などがあります。
ペイロードコンテナ(XMLビジネス文書)の処理結果は、B2Bプロジェクトで定めたXML文書をペイロードコンテナに格納したebXMLメッセージを要求元にHTTP POST送信することで返されます。
このペイロードコンテナに格納するXML文書には、正常終了の場合とエラーの場合の2つのXML文書が存在します。正常終了の場合は、任意のコメントをコンテントとする要素で構成されたXML文書が送信されます。一方、異常終了の場合は、エラーの発生したタイミングを示す要素や、エラーの発生理由を示すコード、エラー内容を説明する文、エラーの発生箇所などを示す要素から構成される、XML文書を送信します。
ebXMLメッセージのヘッダコンテナでエラーが検出されるとErrorList 要素、およびその子要素のError要素を用いてエラーを通知しますが、ebXML MS仕様では、エラーの発生箇所はXPointerを用いて示すことになっています。
しかし、2002年4月現在、XPointerは勧告候補(Candidate Recommendation)の状態ということもあり、XPointerを扱えるXMLパーサーが存在しません。つまり、XMLパーサーでebXMLヘッダコンテナの妥当性検証を行ってエラーが検出されても、エラーの発生箇所をXPointer構文で示してくれません。したがって、エラーの発生箇所を示すXPointer記述を生成するためには自身でコーディングする必要があります。XPointerの仕様が勧告(Recommendation)になれば、これに対応したXMLパーサーも現れると思いますが、それまではXPointer記述の組み立て部分に開発コストがかかることに注意が必要です。
ebXML MS 1.0仕様に記載されているURL上で公開されているスキーマ定義ファイルはW3C XML Schemaの勧告候補版で記述されているため、Xerces2 Javaなど、勧告版にのみ対応したXMLパーサーでは妥当性を検証できません。
そこで、勧告版に記述しなおしてローカルファイルとして配置し、このローカルファイルを利用して妥当性検証を行うことが一つの解決手段となります。このようにパーサーが利用できるスキーマ定義ファイルをローカルに配置することは、ebXML SOAP extension部の妥当性検査をパーサーで行うことによって開発効率が向上するだけでなく、性能面でも大きなメリットをもたらします。
なお、勧告候補版にしたがって記述されたスキーマ定義ファイルを勧告版の記述に変換する作業は、変換機能をもったスキーマ定義エディタがいくつか存在しますので、さほど工数をかけずに行えます。
B2BプロジェクトにおけるebXML MS仕様の適用を通して、ebXML MSがBtoBにおけるエンベロープとして必要な項目をそろえることが確認できました。
B2Bプロジェクトとしては、現時点では電子署名機能を利用していませんが、今後より多くの企業がコラボレーションに参加し、より多くのデータを扱うようになると、改ざん防止が重要な意味を持つことになりますので、近い将来電子署名機能の導入を図る必要があると思われます。
さらに、今後ebXML MSに対応したソフトウェアも増加すると思われますが、企業間で相互接続検証を実施していただき、"Kasumi B2B Project"にこれから参加しようとする企業が任意のebXML MS対応ソフトウェアを利用できることを要望します。
B2Bプロジェクトへの参加、および本文を執筆する機会をいただき、プロジェクトリーダーである株式会社カスミの神林飛志様をはじめ、プロジェクトメンバーの皆様に感謝いたします。