私はここ10年のほとんどを電子商取引プロジェクトに費やしてきました。最初は電子データ交換(EDI)として知られている技術に取り組み、オンライン・ショップ開発を経て、現在はXMLとWebサービスに取り組んでいます。私が今まで経験してきた最も著しい変化は、技術的なもの ではなく可能性 です。

10年前は、電子商取引プロジェクトといえば大事業でした。私は、インターネットが広く普及する前で、そのプロジェクトがいわゆる付加価値通信網(例えばX.25やX.400)、独特なファイル・フォーマット(X12やUN/EDIFACTのようなEDIフォーマット)、専門的なソフトウェアなどを前提としていた頃から関わっています。顧客毎に設計された構成要素があまりにも多かったため、プロジェクトは当然、高価になり、開発が遅くなり、困難になるのは自明の理でした。

現在は技術が発達し、その結果異なる可能性がもたらされました。多くの人が手頃なネットワーク(インターネット)にアクセスでき、(HTMLやXMLのような)少数のファイル・フォーマットが世界中での互換性を保証し、たくさんの手頃なソフトウェアによりWebアプリケーションを構築し実装させることができるようになっています。電子商取引プロジェクトはたやすく、素早く、手頃である、と考えるのは当たり前のことになっているのです。

一般的には、この考えはオンライン・ショップにあてはまります。小さなショップは Yahoo! StoreやeBayなどを利用しており、より大きなビジネスはIBM WebSphere Commerce(参考文献を参照)のようなパッケージ化されたソリューションを購入しています。

BtoB分野(ビジネス・パートナ間の直接的な接続)だけは、可能性がまだ残されています。これらのプロジェクトを成し遂げるには、いまだに高価で、困難な傾向があります。実用的なXML コラムのこの新しいシリーズで、ここ数年の経験を検討して、有望なソリューションを明らかにしたいと思っています。

あるコンテキスト

典型的なBtoBプロジェクトと典型的なオンライン・ストア・プロジェクトの主な違いは、両端の統合の必要性です。オンライン・ストアは、買物客が購入プロセスにしたがってクリックをする対話型のソフトウェアです。途中で、買物客は名前、住所、配達指示などをフォームに記入することで、多くの情報を提供しなければなりません。ショップに多くの買物客がいても、通常それぞれの買物客はそうしばしば買物をするわけではないので、これはうまく機能しています。

ほとんどのBtoBのシナリオでは、いっそう頻繁に取引きが行われます(会社が毎日供給元に数ダースの注文を送ることは一般的です)。したがって、できるだけ取引きを自動化したいことでしょう。例えば、ユーザに入力書式に記入したり、選択肢をクリックしたりしてもらう代わりに、ソフトウェアが自動的にローカル・データベースに基づいた決定をするべきです。自動化は、プロセスを合理化し、(1人の従業員がより多くの仕事ができるように)仕事量を縮小し、エラーの危険性を減少します(タイプミスはよくあることですから)。ここでの課題は自動化を手頃に効果的に達成することにあります。

次に、どのようにビジネスが電子化されたBtoB取引きにより利益を得ることができるのかについていくつかの例を紹介します。

• 電子カタログにより顧客は製品についての総合的な見方ができ、節約が可能になります。例えば、電子カタログにより、顧客は安くてあまり知られていない製品を選択することができるかもしれません。このための必要条件として、供給元は製品リストの電子コピーを提供し、それらを規則的に更新することを承諾しなければなりません。
• 供給元に目的のユーザに直接発送するように依頼する直接配送により、小売り業者は多くの倉庫を閉鎖する(在庫と不動産を軽減する)ことができます。しかし、これは注文の数を途方もなく増加させることにもなります(100箱を倉庫へ配送するという1つの注文から、1箱を別々の住所へ配送する100の注文になるわけです)。したがって、これらの自動化には意味があるのです。
• 配送状況を逐次提供するサービスは、新規顧客の獲得や高い競争力をもたらすでしょう。しかし、これは会社所有の倉庫や運搬人追跡システムのような異なるシステムから情報を取得する必要があるかもしれません。もしも完全な自動化ができなければ、これをリアルタイムで行うのは不可能でしょう。
• 金銭の出納は、ビジネスの本質的な部分なので、会計管理パッケージに収支明細を直接ダウンロードすることは非常に利にかなっています。

2つの選択肢

(全てではないにしても)ほとんどのBtoBプロジェクトは、大きな組織から始まっています。大きな組織は、取引きが多く、したがって自動化が最も効果的であるところです。しかし、ほとんどのビジネス・パートナは小規模か中規模な組織なので、異なる規模のパートナと連携する方法を探さなければなりません。

統合ソリューションは、大まかに2つのカテゴリーに分類されます。ある種のデータ入力パッケージ(Webサイトあるいは専用のクライアント)を提供して、パートナに全てのデータを入力するように依頼するか、供給元も利用できるシンプルなソリューションを提供するかです。

最初の選択肢(データ入力パッケージ)は、よく知られている技術を基礎にしており最も一般的な選択肢です。実際、シンプルなWebサイトにはこれで十分で、オンライン・ストアのために使用したツールで構築ができます。安く、速く、簡単に稼働させることができます。しかし、これは少なくとも次の3つの理由から完全なソリューションではありません。

1. パートナに負担を転嫁する。多くのパートナは、取引きの記録をとる(QuickBooksやPeachtreeのような)会計管理パッケージを持っています。パートナ同士が異なるシステムに同じデータを入力しても、ほとんど意味がありません。たいていの企業は二度手間を好まず、それゆえしばしば価格を再交渉することになります。
2. スピードが遅い。パートナは自身の会計管理パッケージを速やかに更新します。しかし、彼らはその日かその週の比較的空いている時間帯までオンライン・システムの更新を遅らせるかもしれません。その結果コストがかかることになります。
3. エラーが生じやすい。あるシステムから別のシステムへ無分別にデータをコピーしている場合などは特に、タイプミスを犯しやすいものです。

要するに、データ入力パッケージではBtoBの電子的連携のほとんどの利点が無効になっています。その結果、価格に影響がでることになったり、スピードが遅くなったり、より多くのエラーを引き起こすことになるかもしれません。

より優れたソリューションは、会計管理パッケージのデータベースを利用して、取引きのコピーを保持することです。パッケージの統合によって、情報の検索や取引きの多くを自動化することが可能です。しかし、ほとんどの小規模および中規模の組織には、この統合のためのノウハウがありません。したがって、援助を行うことは大規模なパートナ側の責任です。

プロジェクトの注意点と現状分析

これらのプロジェクトの最も興味深い側面の1つは、異なる規模の組織間の文化の違いです。これは彼らが使用する異なったツールに特に反映されています。大きな組織はITスタッフを専任において、特注のソフトウェアに投資する余裕があります。小さな組織は、既製のパッケージを買う傾向があり、ITスタッフといえばネットワーク管理者ぐらいかもしれません。小さな組織が柔軟で融通が利くパッケージ・ソフトを選択する傾向がある一方で、大きな組織は堅苦しい手続に縛られる傾向があります。

私が最初にXMLに興味を持ったのは次のような考えからです。1997年に、XML/EDIグループはXMLが中規模・小規模組織用のBtoBソリューションを実現させる方法を検討することを約束したのです。

すでに述べたように、現状でBtoBプロジェクトは、多少手間がかかり高価なままだと言うことです。会計管理パッケージとの連携は簡単なことではありません。しかし、オープン・ソース・プロジェクトを利用すれば、成し遂げることができるのです。この新しいシリーズは、ここ数年の私の経験を基にしています。

上に戻る

常にシンプルに、そしてやさしく

会計管理パッケージとの統合は最も魅力的なソリューションですが、難しくて高価であるという評判があり、ITスタッフにはあまり人気がありません。彼らは、IBM Branch Transformation Toolkit for WebSphereのような統合サーバが必要であり、成功させるためにはかなりのコンサルティングが必要であることを知っています。統合は大きな組織にはぴったりのソリューションであるものの、小規模のパートナにはほとんど実行できるものではありません。

かわりに、小規模のパートナは中立的なソリューションを必要としています。統合サーバより単純ではあるが、データ入力パッケージより負担の軽いツールといったものです。中立的なソリューションとは、XMLクライアントであり、XMLメッセージを可能な限り 自動的に作成し統合サーバへ転送することが出来るシンプルなツールです。

違いは次の4つの単語as automatically as possible (可能な限り自動的に)です。サーバは24時間/365日利用可能で、何千ものトランザクションを処理するように設計されています。サーバは高度なロギング、ユーザとアプリケーションの分割、(おそらく)クラスタリングも提供して、1時間に数千のトランザクションをおこなうことができれば、完璧です。そうでなければ、行き過ぎでしょう。

私の経験では、1日当たり数百のトランザクション、あるいはより少ない(時にはかなり 少ない)トランザクションのためでさえ自動化をする価値があります。そのためには、適切なツールを使用しなければなりません。コストを縮小する場合、予算が少ないのであれば、トランザクションを開始したら監視してもらうようにユーザに依頼することはとても合理的です。また、XMLクライアントは可能な限り自動化されますが、ユーザが欠落した情報を提供してくれるものだと考えておくことは理不尽なことではありません。

このようなXMLクライアントは、統合サーバとは完全に異なるものです。私の経験では、XMLクライアントは統合サーバの補足 はするものの、競合 するものではありません。

要求分析

どこにそのようなXMLクライアントがあるのでしょう。残念ながら、私が知っている限りでは、そのようなパッケージ化されたソリューションはありません。少数の優れたキットは利用可能ですが、とにかく開発しなければならないならXSLプロセッサやSOAPライブラリのようなオープン・ソース・コンポーネントで自分のクライアントを構築してはどうでしょう。

XMLクライアントの仕様は次のとおりです

• メッセージ準備: 標準的な会計管理パッケージによりエクスポートされたデータからXMLメッセージを準備します。その逆もしかりです。これがXMLクライアントの中核です。つまり、会計管理パッケージからエクスポートされたデータからXMLメッセージを準備します。反対に、会計管理パッケージにXMLメッセージを入力します。
• サーバ・インタフェース: SOAPのような標準XMLプロトコルを使用して統合サーバ間でメッセージを送受信します。この場合、クライアントがサーバを補足することになります。これは、本格的な統合サーバの必要性がないパートナ向けに設計されています。
• 使いやすさ: ユーザが既製のパッケージに精通しているならば、XMLクライアントは使い慣れた外観にすべきです。電子メール・クライアントはユーザ・インタフェースの良いお手本です。
• たくさんのユーザ情報の提供: BtoBの電子商取引は、ほとんどのユーザにとって新しいものです。したがって、彼らはそのようなシステムに信頼を築く必要があります。私の経験から、最良のアプローチは、よりたくさんの情報を提供することです。
• 優れたロギング: 定義上は、電子商取引の関係性は地理的に制限されていません。したがって、ユーザを間接的に支援することができる優れたロギングが必要です。

私はこれらの仕様から意図的に1つを省きました。それは、サーバにメッセージを送る前にメッセージを編集する機能です。ほとんどの会計管理パッケージは電子商取引を考慮して設計されていないので、この必要性があります。ほとんどの会計管理パッケージは、必要とされるすべての情報を格納しているとは限りませんし、すべての必要な情報をエクスポートすることができるとも限りません (私の経験では、安価な会計管理パッケージのうちのいくつか高額なパッケージほど情報が公開されていません)。

データが欠落している場合、ソリューションは完全ではありません。これに対する最も現実的な選択肢は、会計管理パッケージからできる限りの情報を取得し、ユーザからの説明を求めることです。この場合もやはり、高額な統合サーバでは受け入れられないでしょうが、XMLクライアントでは現実的な意味をなします。

理想的なXMLクライアントはXMLエディタを含みますが、このコラムでは含めないことにしました。私は、近い将来、このプロジェクトにオープン・ソースのXFormコンポーネントを組み込むつもりでいます。しかし現時点では、優れたエディタは商用プロジェクトにしか無いようです。特定の製品とこのコラムを結び付けたくないので、エディタについては読者のみなさんの課題としましょう。

上に戻る

XIのいくつかの変更

どうやってXMLメッセージを準備すれば良いでしょうか。すべての会計管理パッケージがXMLを認識するとは限りません。しかし、すべてのパッケージには様々なフォーマットでデータをエクスポートしたりインポートしたりするオプションがあります。最も知られているフォーマットの2つは、カンマ区切り(CSV)と固定長フィールドです。パッケージが明示的にエクスポート機能を提供していない場合は、Microsoft Officeとの統合を調べてみてください。そのような機能は、ほとんどの場合CSVファイル経由で実装されています。

これらのファイルをXMLに変換するためには、私がこのコラムで以前に紹介したXML Import (XI) というプロジェクトを使用してもよいでしょう。覚えていると思いますが、XIはテキスト・ドキュメントを解析し、それらをXMLへインポートするために正規表現を使用しています。

エクスポートの方はどうでしょう。<xsl:output method="text"/> は、実用性の面では非常に制限されています。よりよい解決策は、XIにテキスト・ジェネレータを追加することです。テキスト・ジェネレータは、必要とする形式のテキスト・ドキュメントを記述するために特殊なXMLボキャブラリーを使用します。私は3つほどタグを定義しました。

• flat:root は、テキスト・ドキュメントのルートです。
• flat:field は、1つのテキスト・フィールドを表します。
• flat:br 現行システムでの行の終端文字(UNIXでは\n、Windowsでは\n\r)を表します。

flat:field には次の属性があります。

• width は、文字フィールドの幅を表わし、テキストはwidthで指定した幅まで切り詰められるかパディングされます。
• align は、テキストが右詰めまたは左詰めにされるかどうかを示します。
• padding はパディングされる文字を設定します。

flat:root要素のdefault-width、default-align、default-padding属性によって、上述の属性にディフォルト値を設定することができます。

XI用のテキスト・ジェネレータを起動するためには、<xsl:output method="xi:flat"/>のように、出力形式の指定(output method)にxi:flatをセットする必要があります。ジェネレータ(もちろん、それを使用するXIユーザ・インタフェースの更新も含む)は、ダウンロードが可能です。

XIを開発した際、私はJDKによる制限を受けないように正規表現プロセッサを抽象化しておきました。この小さな恩恵は、XIがJDK 1.3環境でも動作するということです。

上に戻る

これからは・・・

今回の記事は、「実用的なXML」コラムの新しいプロジェクトの始まりを表しています。このプロジェクトの目的は、既存のXIエンジンでXMLクライアントを書くことです。

参考文献

• この記事で使用されているソース・コードをダウンロードしてください。
  
  
• Branch Transformation Toolkit for WebSphere Studio (WebSphereで統合サーバを作成する強力なキット) を入手してください。
  
  
• WebSphereで手頃に効果的にWebストアを作成する方法を、Donna Sutarno氏およびFrances Mullally氏によるチュートリアル、「 Creating an online store using WebSphere Commerce」で学んでください。
  
  
• Chen Shu氏、Nianjun Zhou氏、Dikran S Meliksetian氏による「XSLTを利用してアプリケーションを構築する」 (developerWorks 、2003年3月)で、アプリケーションの作成にXSLTを使用する方法についてのデモンストレーションを参照してください。
  
  
• Mike Edwards氏による「Create Web services with the WebSphere SDK Version 5.1」(developerWorks 、2003年10月)を参照してください。WebSphereアプリケーション・サーバとWebサービスの生成について解説されています。
  
  
• オンライン・ストアの良い例である、Yahoo! Storeは小規模なショップをターゲットにしています。
  
  
• developerWorksXMLゾーン には、ほかにも多くのXML関連の参考文献が掲載されています。
  
  
• XML及び関連技術においてIBM 認定開発者になる方法についてはこちらを参照してください。
  
  

著者について

Benoit Marchal氏は、ベルギーのナミュールを拠点にしたコンサルタントおよび著述家です。彼の著作には、 XML by Example(Que社、邦訳: インプレス社「実例で学ぶXML」。間もなく第2版が出版される予定です)、 Applied XML Solutions および XML and the Enterprise があります。また、Gamelanのコラムや、developerWorks XML zoneのコラムWorking XML の著者でもあります。最新プロジェクトの詳細については、www.marchal.com をご覧ください。

この記事を評価する

コメント

上に戻る

目次

• あるコンテキスト
• 常にシンプルに、そしてやさしく
• XIのいくつかの変更
• これからは・・・
• 参考文献
• 著者について
• コメント