（流通BMS 2009 年度版解説書 - DAL...流通ビジネスメッセージ標準...

流通ビジネスメッセージ標準流通ビジネスメッセージ標準（流通（流通BMSBMS）） 20092009年度版年度版

解解説説書書̃̃流通流通BMSBMSの導入に必要な知識と具体的導入作業の解説の導入に必要な知識と具体的導入作業の解説 ̃̃

営業本部営業本部

EDI/EDI/ SCMSCM企画推進企画推進

藤野藤野裕司裕司

2009.06 Ver 3.01

Copyright (C) 2009 Data Applications Co., Ltd. All rights reserved.

1

目次

Ⅰ．流通BMSの概要と

導入のメリット

１．従来型EDIの課題２．課題解決のための流通BMS３．流通BMSと通信プロトコル標準

４．セキュリティ５．従来型EDIとの違い６．流通BMSに移行するメリット

はじめに

１．流通ビジネスメッセージ標準２．通信プロトコル標準３．必要となる申請・手続と期間

Ⅲ．導入事前準備

１．導入のモデル２．導入にかかわる全体の流れ３．事前準備から本番移行まで

Ⅱ．導入までの流れ

１．環境の構築２．システム規模の選択３．目的に応じた具体的構成４．ACMSアップグレードパス

Ⅳ．流通BMSの導入


2

はじめに

本資料には、これから流通ビジネスメッセージ標準（流通BMS ）を導入するために、

必要となる事前準備及び導入に際しての検討ポイント

が記載されています。

また資料後半には、流通BMSの概要を整理した知識編を添付しているため、社内での勉強用資料として、また実際の導入時の手引き書として、ご活用ください。

なお、本書は下記の「流通システム開発センターWebサイト」で公開されている

公式情報に基づいて記述しております。必要に応じてご参照ください。

• 財団法人流通システム開発センター［http://www.dsri.jp/］

»流通業界の標準化・システム化を推進している団体。

– 「経済産業省流通システム標準化事業」»流通システム開発センターのサイトからこのタイトルをクリックする。»このページには流通次世代関連の重要な情報が掲載されている。»このページ内でも特に重要なのが、「流通BMS」のページであり、ここに流通ビジネスメッセージ標準の資料が掲載されているため必読である。


3

Ⅰ．流通BMSの概要と導入のメリット１．従来型EDIの課題

２．課題解決のための流通BMS３．流通BMSと通信プロトコル標準

４．セキュリティ

５．従来型EDIとの違い

６．流通BMSに移行するメリット


4

取引先取引先 AA

InternetInternetInternetInternet

WebEDIWebEDI AA

WebEDIWebEDI BBWebEDIWebEDI CC

WebEDIWebEDI DD

新多端末現象新多端末現象新多端末現象新多端末現象

取引先取引先ＢＢ取引先取引先ＣＣ

取引先取引先ＤＤ

１．従来型EDIの課題

従来型ＥＤＩには課題が山積し、このままでは運用に耐えられない状況となってきた。全銀・JCA手順はもう限界！

• サポートする機器が販売停止、もしくは高コスト。

• 画像情報が送れない。JCA手順は、漢字も送れない。

安価で高速のインターネットが使えない。

国際標準ではないため、海外との取引に利用できない。

ファイル転送のため、トランザクション単位の処理ができない。

データが固定長のため仕様変更が困難。

それらの解決策としてWebEDIが登場したが、

• 各社個別画面ができたことにより新多端末（多画面）現象が起こった。

• 手動操作によるファイル転送を求められるようになった。これにより、

ＥＤＩ本来の自動処理ができなくなり、多大な人的負荷が発生する

ようになった。

企業間･企業内を取引のデータが縦横無尽に行き来

している。

EDIの適用領域が「電子商取引」の

範囲外へ拡大している。

従来型EDI、WebEDI、社内ファイル転送、

データ変換（手組み）は、すべて別の

システムとして稼動しており、

運用監視が複雑化している。

JCAJCA手順は手順は

日本語日本語漢字不可漢字不可

画像情報不可画像情報不可

機器の販売停止機器の販売停止

通信速度は通信速度は2400bps2400bps


5

★課題解決のためインターネット環境での効率的・効果的なEDIを目指す。

可能な限り標準化を進め、全体最適を目指す。

共通基盤は、デファクトスタンダードから選べるようにする。

結論インターネット経由の国際標準の通信手順を使用したXML-EDI！コードは国際標準（GTIN、GLN）を採用。データ項目・メッセージは業

界標準を策定。

取引業務プロセス（メッセージ種）取引業務プロセス（メッセージ種）

データ項目データ項目

コード（コード（GTINGTIN、、GLNGLN））

データ表現形式（データ表現形式（XMLXML））

通信手順（通信手順（ebXML MSebXML MS、、AS2AS2、、JXJX手順）手順）

通信基盤（インターネット通信基盤（インターネット TCP/ IPTCP/ IP））

ＥＤＩメッセージＥＤＩメッセージ

通信インフラ通信インフラ

共通基盤共通基盤（デファクトスタンダードの（デファクトスタンダードの

中から選択）中から選択）

（図は流通システム開発センター資料より）（図は流通システム開発センター資料より）

２．課題解決のための流通BMS

（ebXML MS、AS2、JX手順は、別途説明）


6


★流通BMS検討の基本方針

個別仕様の発生を抑える

• すべての企業間取引で共通のEDIメッセージを使えるように、「メッセージ種別」、

「メッセージ構造」、「データ項目」と「データ項目の意味」・「データの属性」を標準化する

現行業務の担保を図る（現行システムの担保ではない）

• 各社の現行業務をできるだけ担保し、移行の負担を軽減する。

将来の技術・業務に対応できる準備を盛り込む

• 商品マスターの同期化（GDS） → 未対応

• 共通企業識別コード(GLN)• 共通商品識別コード(GTIN)インターネットを使用した通信を前提とする

• XML、セキュリティ

伝票レスを促進する

• 取引証憑の要件を満たすEDIメッセージとすることで、ペーパー仕入伝票を不要

とする。


7

次世代EDI標準検討の経緯


（流通システム開発センター資料より）（流通システム開発センター資料より）

２００３年～２００８年：経産省事業

流通業界全体の情報共有・交換のインフラ基盤としての新たな流通システム標準

業種・業態を超え、ユーザー自らが作り、ユーザー自らが使いユーザー自らが管理するユーザー主体の新標準を目指す

２００９年～：民間運営

流通システム標準普及推進協議会

ユーザー企業・団体が主体となった検討の場

業種・業態や製配販の枠を超えた意見調整と啓発の場

ユーザー企業と情報関連企業の情報交換の場

２００３年度２００３年度２００２００４４年度年度２００２００５５年度年度２００２００６６年度年度２００２００７７年度年度

流通サプライチェーン全体最適化促進事業流通サプライチェーン全体最適化促進事業流通システム標準化事業流通システム標準化事業

取引プロセスモデルの検討

設計開発

実証実験

基本形の標準化検討物流系・情報系メッセージ検討

（預かり在庫型センター、POS/ 在庫データ等）

共同実証

共同実証（生鮮、

ｱﾊﾟﾚﾙ）

基礎調査・研究標準化検討と実証実用化と普及拡大へ

共同実証（チェーンドラッグホームセンター

百貨店）

２００２００８８年度年度

流通システム標準流通システム標準普及推進協議会普及推進協議会

流通システム標準

・開発維持管理・導入支援普及推進・外部からの要請に応じた標準化検討

経産省事業［標準の策定］

民間運営[ 標準の維持管理 ]

引き継ぎ


8

２．課題解決のための流通BMS★業界動向

スーパー業界では既に実運用及び普及段階に入り、百貨店業界やチェーンドラッグ、ホームセンター業界でも共同実証を実施した。

酒類・加工食品

日用品・化粧品

生鮮食品

アパレル

医薬品

住関連製品

ホビー関連製品

家電製品

卸・メーカー

書籍

等

総合スーパー

食品スーパー

百貨店

ドラッグストア

CO-OP

ホームセンター

家電量販点

小売

各種専門店

等

2006年度共同実証実施 2007年度共同実証実施 2008年度共同実証実施

流通BMS

発注/生鮮発注

出荷/生鮮出荷

受領/生鮮受領

返品/生鮮返品

請求/支払

値札

集計表作成

在庫・POS売上･･･

通信インフラ

（図は流通システム開発センター資料より）（図は流通システム開発センター資料より）


9

(1) 流通ビジネスメッセージ標準（流通BMS）メッセージ基本形 V1.2

３．流通BMSと通信プロトコル標準


卸・メーカー小売

商品ﾏｽﾀ登録

発注

商品ﾏｽﾀ登録

消込

買掛

請求

返品受領

受注

出荷

納品提案メッセージ

返品メッセージ

支払メッセージ

請求メッセージ

発注予定メッセージ

商品マスタ（継続検討）

出荷梱包メッセージ（紐付有･無）

小売から

卸･ﾒｰｶｰから

卸･ﾒｰｶｰへ

小売へ

受領訂正メッセージ

POS情報

集計表作成ﾃﾞｰﾀ（出荷梱包紐付有）

集計表作成ﾃﾞｰﾀ（出荷用）

出荷メッセージ

集計表作成ﾃﾞｰﾀ（発注用）集計表作成ﾃﾞｰﾀ（発注用）

請求

支払

売掛

返品

値札作成依頼値札作成値札メッセージ

集計表作成ﾃﾞｰﾀ（受領用）

受領メッセージ

販売情報共有販売情報共有

検品

平成20年度の新規メッセージ（基本形）

発注メッセージ


10

(2) 通信プロトコル標準a. 通信基盤：インターネット、TCP/IP。b. 通信プロトコル：国際標準のebXML MS、AS2と日本独自標準のJX手順。

① ebXML MSとは？– ebXML MSとは、CEFACTとOASISが共同で開発した次世代EDIの国際標準ebXMLの通信プロトコル部分ebXML/MSのこと。– インターネット上で高速安全なEDI環境を構築できる。– アジアを中心に実装が始まっている。– リアルタイムのEDI（メッセージング）を実現。

– データ発生のつどプッシュ型で相手に送るサーバ方式。– 通常のファイル転送（文字情報）のほか、ファイル添付（Word、Excel、PowerPoint、PDF、CAD、画像、音声、動画、等）も可能。

② EDIINT AS2とは？– IETFが制定したインターネットEDIの国際標準。

– 米国を中心に実装が始まっている。– ebXML MS同様、データ発生のつどプッシュ型で相手に送るサーバ方式。

– ウォルマートを中心に国際レベルでの流通調達で普及が始まっている。– 日本でも日用品雑貨メーカを中心に検討の機運が高まっている

③ JX手順とは？– 2007年4月正式に命名され、それ以前はSOAP-RPCと呼ばれていた。– 中小企業では、データ発生のつどプッシュ型で相手に送るサーバ方式の常時運用は難しい。その点JX手順は、必要の都度センターにアクセスし、データを送受信するプル型。– 任意のタイミングでクライアントから起動し、取引先やVANとデータの授受を行う。– ebXML MSでは現行EOSからの移行が難しいため、実態に合わせて作られた日本独自標準。



11


(3) S-S型（サーバ常時稼働）とC-S（PC随時稼働）型

（量販（量販ＸＸ））

ビジネス文書

ビジネスビジネス文書文書

ビジネス文書


アプリケーション



データ変換

データ変換

データ変換

ＥＤＩ

クライアントシステム

ＥＤＩ

ＥＤＩ



ビジネス文書


インターネット



社内形式

社内形式

ファイアウォール相当機能

ビジネス文書


ビジネス文書


ビジネス文書


ＥＤＩ

サーバシステム

ＥＤＩ

ＥＤＩ



データ変換

データ変換

データ変換

ビジネス文書


ビジネス文書








社内形式

社内形式

ファイアウォール（量販（量販ＸＸ））

★S-S型EDIモデル ebXML MSebXML MS、、AS2AS2

★C-S型EDIモデル JXJX手順手順


12


(4) 利用形態（イメージ）

二次卸二次卸

倉庫倉庫

大メーカ大メーカ一次卸一次卸

VANVAN事業者事業者

二次卸二次卸

小売小売 ebXML MSebXML MS

AS2AS2

中小卸中小卸

ebXML MSebXML MS

JXJX手順手順

JXJX手順手順

JXJX手順手順

JXJX手順手順

JXJX手順手順

AS2AS2

ebXML MSebXML MS


13

４．セキュリティ

(1) セキュリティ対策が必要インターネットが前提になるため、従来にはなかったセキュリティ対策が必要となる。サーバ側セキュリティには「システムに対するアクセスの管理」「ファイアウォールやサーバのセキュリティ、監査用ログの管理」「通信プロトコル上での暗号化や認証」「文書の改竄防止」などがある。クライアント側セキュリティは、インターネット接続のＰＣと同等レベルのセキュリティ＋認証情報の設定が必要。

(2) 証明書・署名の扱いサーバシステムには、証明書が必要。署名が必要な場合もある（AS2）。

クライアントシステムにも、証明書が必要な場合がある。認証局より証明書を取得し、目的に応じて証明書・署名として使用する。流通BMSの場合は業界認定の認証局から取得することが前提となっている。

自社用の証明書は認証局から取得し、取引先認証のための認証局証明書は取引先から受領する。取得したサーバ証明書は、システムにセットして取引先と接続する。


14

５．従来型ＥＤＩとの違い

(1) 従来のJCA手順・WebEDI方式との差異

インターネット（固定料金、数Mbps）、TCP/IP、SSL

電話網（回線毎に固定＋従量料金、9600bps等）

インターネット（固定料金、数Mbps）、TCP/IP、SSL通信基盤

画面からの伝票入力、もしくは、手操作によるHTTPファイル転送（標準仕様・JCA手順方式とは異なる）

JCA通信手順国際標準 ebXML MS、EDIINT-AS2、SOAPを使用

通信手順

サーバ側より仕様提示情報システム部同士で個別調整

ebXML、CPA等で通信合意事項を規定

通信に関する当事者間合意

形式規定は小売の仕様書JCA形式（固定長）、形式規定は小売の仕様書

国際標準 XML（可変長）、形式規定もXMLデータ表現形式

個別項目個別項目業務項目、メッセージヘッダー項目を標準化

データ項目

商品：JAN、企業識別：小売コード

商品：JAN、企業識別：小売コード

商品：GTIN(JAN)、企業識別：GLN、小売コード

コード（商品、企業識別）

小売の運用統一フォーマットは受発注のみ、小売の運用

標準メッセージの規定、運用ガイドライン取引業務プロセス

個別交渉個別交渉プロセスやコード種、等の選定項目を提示

業務に関する当事者間合意

WebEDI方式JCA手順方式標準ＥＤＩ

ED

I

通信標準

ED

I

標準メッセージ

標準標準EDIEDIでは、業界の標準となる様々な指針を打ち出している。それにより、従来では、業界の標準となる様々な指針を打ち出している。それにより、従来

相手先毎個別に取り決めが必要だった要件を、標準仕様をベースに共通認識のも相手先毎個別に取り決めが必要だった要件を、標準仕様をベースに共通認識のもとに設定できるよう考慮されている。とに設定できるよう考慮されている。


15


(1) 流通ビジネスメッセージ標準を採用することによるメリット

最初にシステムを標準対応することにより、以降取引先毎のシステム開発は最小限に抑えられる。

• 最初の標準対応も、現行業務が前提となるため、過大な開発負担はないものと考える。

同じシステムで現行のバッチ型ファイル送受信を行うことも、標準通信プロトコル本来の機能であるメッセージ単位のトランザクション処理もできる。

• データ発生の都度送受信することにより、データ精度を高めリードタイムを短縮することが可能。

社内でのデータ活用が柔軟になる。

• XMLデータを活用することにより、アプリケーションの多様化に容易に対

応できる。

国際標準（XML、GLN、GTIN）採用により、グローバル対応が容易。


16


(2) 通信プロトコル標準を採用するメリット

物理的回線や専用ハードウェアの管理が不要になる。

対応可能なハードウェアが豊富。

• 同期モデム損傷による受発注業務停止のリスクがなくなる。

TCP/IP経由のオープン系システムであるため、社内システムとの親

和性が高い。

• ハードやソフトの共用・集約ができ、技術や資産の有効活用が可能。

• 回線の高速化、利用料低廉化により、リードタイム短縮・締め時間延長・利用コスト削減が可能。

• 漢字や画像、EXCEL、PDFなど多様なデータを扱えるので、さまざまな

アプリケーションを通じ、データの有効活用が可能。

ファイル転送型WebEDIの手動操作がなくなる。

• 人件費や人的ミスを削減でき、業務の自動連携を促進できる。

国際標準（ebXML MS、AS2）採用により、グローバル対応が容易。


17


(3) 通信インフラが個別回線からインターネットに①JCA手順固有のリスクから解放される。

・複数回線の管理

・固有のハードウェア（同期モデム等）

②インターネット利用による処理の高速化、コストの低廉化が実現できる。

EDIサーバ

ダイアルアップルータ

INS６４全銀TCP/ IP9600bps～19.2kbps

公衆回線網全銀，JCA2400bps

UST

EDIデータ ACMSACMSEE22XX EDIサーバ

EDIデータ ACMSACMSEE22XX

ルータ ACMSACMSEE22XX

通信サーバ

インターネット50Mbps～100Mbps

（ベストエフォート）

DMZDMZ

・・・・・・・・・・・・・・・・

従量課金従量課金定額料金定額料金

ファイアウォール


18


(4)相手先毎の個別対応がなくなり、取引先やデータ種別の

追加が容易に

XMLXMLビジネスビジネス文書文書

ＥＤＩ


ＥＤＩ

ＥＤＩ



社内形式

データ変換

プログラムAデータ変換データ変換

プログラムプログラム AAA社ﾌｫｰﾏｯﾄ

データ変換

プログラムBデータ変換データ変換

プログラムプログラム BBＢ社ﾌｫｰﾏｯﾄ

データ変換

プログラムCデータ変換データ変換

プログラムプログラム CCＣ社ﾌｫｰﾏｯﾄ

・・・・

・・・・

・・・・

・・・・




社内形式




ＥＤＩ


ＥＤＩ

ＥＤＩ


サーバシステム中間

形式項目・ｺｰﾄﾞ項目・ｺｰﾄﾞﾚｲｱｳﾄ変換ﾚｲｱｳﾄ変換

XML変換

新たなアプリケーションでの利用可！！

取引先ごとに、データを自社のフォーマットに変換するプログラムを作成する必要があった。

•標準フォーマットを、取引先ごとに区別することなく自社フォーマットに変換できる。一部固有の部分がある場合も、従来と違い限られた範囲での対応に抑えることができる。

•この変換は市販のツールを利用できる。ただし、ツールによっては、項目・コード・レイアウト変換などを別に行う必要があるものもある。

•XMLビジネス文書は、このまま新たなアプリケーションでの利用が可能。

•UN/ EDIFACTやCII、X.12などは、標準フォーマットをそのまま利用することができなかった。

ACMS ANY変換

手組み開発市販製品




一般的には


19


(5) 伝票レスでコスト削減

伝票レスとは、小売と卸・メーカの双方が「受領データ」を保存することにより、

従来印刷していた複写式のTA（Turn Around）伝票の印刷が不要になること。

これにより、伝票用紙代、プリント費用、伝票保管費用を削減できる。複写式伝票を印刷

するインパクトプリンタも、機種が少なく印刷速度が遅い、メンテコストがかかるなど多く

の問題を抱えていた。印刷後の伝票も、後日参照･検索する場合、膨大な紙の山から探

し出すのは業務の効率を大幅に低下させていた。

従来も実施例はあるものの、小売毎に仕様が異なり卸側は相手先毎に別システムを持

つ必要があった。今回の流通BMSでは、その仕様が標準化され、システムの統一を図

ることが可能となった。

ただし、これを実現するには双方に高度な在庫精度と検品体制が必要となる。


20


(6) 検品レスで業務の改革と効率化

検品レスとは、卸・メーカ側から納品伝票に代わる「出荷（梱包紐付けあり）

データ」（事前出荷明細）を事前に小売側に送っておき、出荷時に梱包に貼付

したSCMラベルのバーコードを受け入れ側（主に小売物流センター等）がス

キャンし、あらかじめ受信した事前出荷明細と照合することにより検品を行うこ

と。店舗での検品は省略できる。

この検品レスも、前記伝票レスと同様、小売毎に異なる仕様であったものが標

準化されたため、大きな省力効果が期待できる。

一方、卸・メーカ側は従来にも増して高度な物流体制が求められることとなる。

これを機会に業務改革を目指し更なる高効率化を進めたい。

卸･メーカ側小売側

出荷明細

出荷検品入荷検品

事前出荷明細

照合

出荷（梱包紐付けあり）データ出荷（梱包紐付けあり）データ


21

Ⅱ．導入までの流れ１．導入のモデル

(1) サーバタイプかクライアントタイプか

(2) サーバタイプの特徴

(3) クライアントタイプの特徴

(4) 自社構築かASP利用か

２．導入にかかわる全体の流れ

３．最初の取引先との本番移行まで(1) 事前準備

(2) 環境構築

(3) アプリケーション開発とEDI関連情報設定

(4) テスト計画・移行方針の策定

(5) 取引先との接続テスト

(6) 本番移行


22

１．導入のモデル

(1) (1) サーバタイプかクライアントタイプかサーバタイプかクライアントタイプか小売もしくは大手の卸・メーカは、基本的にサーバモデル

小規模の卸・メーカは、クライアントモデル

中間規模の企業は、データ量やプロトコルの特性に応じて判断

大メーカ大メーカ

一次卸一次卸

小売小売・・ASPASP事業者事業者

二次卸二次卸

JXJX手順手順

JXJX手順手順

AS2AS2

ebXML MSebXML MS

AS2AS2

サーバサーバサーバ



クライアントクライアントクライアント

クライアントクライアントクライアント

小規模小規模卸卸SS--SS型型EDIEDIモデルモデル

CC--SS型型EDIEDIモデルモデル


23


ビジネス文書


ビジネス文書





データ変換

データ変換

データ変換

ＥＤＩ


ＥＤＩ

ＥＤＩ



ビジネス文書





社内形式

社内形式


ビジネス文書


ビジネス文書


ビジネス文書


ＥＤＩ


ＥＤＩ

ＥＤＩ



データ変換

データ変換

データ変換

ビジネス文書


ビジネス文書








社内形式

社内形式





［注意］この図は、クライアント側での運用。［注意］この図は、クライアント側での運用。JXJX手順サーバプロトコルと矢印の向きが反対。手順サーバプロトコルと矢印の向きが反対。

S-S型（サーバ常時稼働）とC-S型（クライアント随時稼働）


24

S-S型EDIモデル

取引先とサーバ同士で接続するモデル。

通信プロトコルはebXML MSもしくはAS2。どちらを選ぶかは取引先との調

整により決定する。

どちらのプロトコルも、データが発生したタイミングで相手に送りつけるPush型通信。

C-S型EDIモデル

ハブとなる企業がサーバシステムを設置し、そこに向けて小規模の企業がクライアントシステムで接続するモデル。

通信プロトコルはJX手順。

送受信の要求はクライアント側から発し、サーバ側はその要求に応じて送受信を行うPull型通信。

現行のEOSと同様の運用を実現。サーバ側は、企業が直接行う場合とVANやASPが行う場合がある。



25


システム規模決定の目安

共同実証の結果、JX手順による取引は、取引先との１取引データ量が10MBを超えない

ことが推奨されている。

XML化する場合のデータは、概ねキャラクタの１２倍となる。

データ量が大きくなった場合は圧縮をする。

ebXML MSおよびJX手順では、zipを使う。この場合、圧縮後のファイルサイズは、XMLで１／５０くらいになると言われている。

AS2では、プロトコルが持つ圧縮で行う。通信上で行うため、具体的な圧縮率は不明。

その他、近い将来、接続する取引先が大きく増えたり、データ量の急激な増加が見込ま

れる場合も「サーバシステム＋サーバ通信プロトコル」の採用が推奨される。

通信速度は、インターネットの１００Mbpsを利用した場合でも、実行速度は社内のLAN環境に依存するため、現実には1～3Mbps程度と考える。

同時接続数は、ピーク時（決算時期等）の運用で最大のデータ量（支払・請求）による通

信時間と、そのタイミングで送受信を必要とする相手先の数から計算する。


26


◆ＪＣＡ注文データ１伝票をXML化した場合の想定データ量

128byte × 4.2レコード × 12倍 ≒ 6.5kbyte

※XML化した１伝票のデータサイズは約6.5kbyte

◆データ量が10MBを超える場合の想定パターン

支払メッセージのデータ量が最も多い。

そのデータが10MBに達するためのケースを想定すると、下記の

ように、１日平均220伝票分の注文データ発生すると考えられる。

10MB ÷ 128byte ÷ 12倍 ≒ ６５００伝票

※1ヶ月の注文伝票が約6500～7000伝票

［参考］注文データが10MBになるケースは、下記にように、

１日1600伝票が発生する場合となる。10MB ÷ 128byte ÷ 4.2レコード ÷ 12倍 ≒ 1600伝票

XML化した場合のデータ量の目安

【【前提前提】】

注文伝票１枚の平均明細数（業界平均）は注文伝票１枚の平均明細数（業界平均）は3.23.2行行

JCAJCA注文データは、注文データは、11レコードレコード128byte128byte11伝票は、ヘッダーレコード＋明細レコード伝票は、ヘッダーレコード＋明細レコード

JCAJCA支払データは、支払データは、11伝票伝票11レコード（レコード（128byte128byte））

XMLXML変換により、キャラクタデータは１２倍のサイズになる変換により、キャラクタデータは１２倍のサイズになる

・注文データ１レコード＝128byte・注文データ１伝票＝4.2レコード (1ヘッダ + 3.2明細)・テキスト→XML変換指数＝１２倍

・支払データ１レコード＝128byte・支払データ１伝票＝1レコード


27

１取引データ量による選択


１

４

１

無制限

１

15MB以上10~15MB１０MB未満

同時接続数による選択

③③ クライアントクライアント

②② ミドルサーバミドルサーバ

①① サーバサーバ高セキュリティ構成、負荷分散型構成高セキュリティ構成、負荷分散型構成

※表の基準は目安。

・採用する通信手順、想定されるデータの量、必要となるメッセージ等は、必ずお取引先にご相談してください。

〜〜

〜〜

システム規模とデータ量・同時接続数の相関図


28


ビジネス文書


ビジネス文書





データ変換

データ変換

データ変換

ビジネス文書





社内形式

社内形式

ファイアウォール

ビジネス文書


ビジネス文書


ビジネス文書


ＥＤＩ


ＥＤＩ

ＥＤＩ



データ変換

データ変換

データ変換

ビジネス文書


ビジネス文書








社内形式

社内形式

ファイアウォール取引先取引先

ebXML MSebXML MS、、AS2AS2

JXJX手順手順サーバプロトコルサーバプロトコル

ＥＤＩ


ＥＤＩ

ＥＤＩ



取引先取引先

［注意］後述の［注意］後述のJXJX手順クライアントプロトコルと矢印の向きが反対手順クライアントプロトコルと矢印の向きが反対

(2) サーバタイプの特徴


29

サーバタイプの特徴インターネット上でサーバを常時稼働させる。

通信プロトコルが、ebXML MS、AS2の場合、Push型通信を行う。つまり、アプリケー

ション側で送信データが生成されたら、その場で相手先に送る。受信は常に相手先からのデータを待ち、先方から送りつけられたら、その場で受ける

JX手順サーバプロトコルの場合、常に相手からの要求を待ち、相手からの送りつけなら

そのまま受信に、相手への送信要求なら用意してあったデータを送る。

Push型通信プロトコルは、従来型通信方式と違い、通信と業務は分離独立している。そ

のため、送信側は相手の業務スケジュールと関係なしに、データ発生の都度送信する。受信側は、送られてきたデータを蓄え続け、自社の業務スケジュールで溜まったデータを取り出し、アプリケーションに渡す。

これにより、通信も業務も相手のスケジュールに合わせることなく平準化を図ることができる。

この方式を応用すると、要求を受けたらすぐに返答を返す準リアルタイムのトランザクション処理が可能となる。

通信サーバはDMZ上に、データおよび管理サーバは社内に設置する。外部からの攻撃を受ける可能性があるため、データおよび管理サーバをDMZ上に設置してはならない。

通信サーバと管理サーバを分離することができない場合、リバースプロキシを置き、外部からの攻撃を避ける工夫が必要。

従来型通信プロトコルも並行運用する場合、新旧プロトコルは統合運用が望ましい。



30



ビジネス文書


ビジネス文書





データ変換

データ変換

データ変換

ＥＤＩ


ＥＤＩ

ＥＤＩ



ビジネス文書





社内形式

社内形式


ビジネス文書


JXJX手順手順クライアントプロトコルクライアントプロトコル

［注意］前述の［注意］前述のJXJX手順サーバプロトコルと矢印の向きが反対手順サーバプロトコルと矢印の向きが反対

(3) クライアントタイプの特徴


31


クライアントタイプの特徴

ＥＤＩ関連業務を行うときのみ、システムを運用する随時稼動型。

通信プロトコルはJX手順。データの送受信が必要なときのみ起動し、送信もしくは受信

を行う。

業務アプリケーションとセットになったパッケージもある。

運用形態は、JCA手順と同じであるため、通信システムを入れ替え、流通BMS関連の

設定を行うだけで、既存の業務につなぐことができる場合もある。ただし、業務との連

携部分を十分に確認する必要がある。

PCでの運用を想定したモデルであるが、サーバOSで利用することも可能。


32


小売ですか？小売ですか？

大規模システム大規模システムですか？ですか？

１通信での１通信での大量データは大量データはありますか？ありますか？

通信プロトコルに通信プロトコルにebMSebMS、、AS2AS2、、

JXJX手順サーバプロトコルを手順サーバプロトコルを

利用しますか？利用しますか？

YESYES

YESYES

YESYES

YESYES

NONO

NONO

サーバサーバサーバクライアントクライアントクライアント

ASPASPを利用を利用

しますか？しますか？自社専用自社専用

ASPASPにしますか？にしますか？YESYES

NONO

NONO

YESYES

NONO

自社専用ASP

自社専用自社専用ASPASP汎用ASP汎用汎用ASPASP

NONO

自社構築自社構築

ASPASP利用利用

(4) 自社構築かASP利用か


33

－２ヶ月－１ヶ月＋１ヶ月当月－３ヶ月－４ヶ月－５ヶ月

機器・ソフトの調達

システム開発内容の確認必要に応じてシステム開発

接続テストフェーズ１フェーズ２フェーズ３

旧システムとの並行運用

平行運用の停止

マッピング取引先との接続情報設定

環境構築アプリケーション開発と

EDI関連情報の設定本番移行凡例：

２．導入にかかわる全体の流れ

プロジェクトの立ち上げ

事前準備

標準EDI仕様の理解

取引先との接続テスト

取引先との方針確認

ネットワーク環境手配

システム環境構築

取り決め基本情報作成

テスト計画・移行方針の策定

テスト計画・移行方針の策定


34

(1) 事前準備

具体的作業を始める前に、正式なプロジェクトを立ち上げ、流通BMSにつ

いての十分な理解、取引先との調整を行います。

①プロジェクトの立ち上げ

• システム形態の選定

プロジェクトを立ち上げるにあたり、導入するシステム形態を選定します。

「大手企業や大規模システムを持つ企業」と「中小企業や取引量の少ない企業」とは準備するEDIシステムの形態は異なります。企業の実態に応じたシステムを選定してください。

– S-S型EDIモデル

» 取引先とサーバ同士で接続するモデル。

» 通信プロトコルはebXML MSもしくはAS2。どちらを選ぶかは取引先との調整により決定する。

» どちらのプロトコルも、データが発生したタイミングで相手に送りつけるPush型通信。

– C-S型EDIモデル

» ハブとなる企業がサーバシステムを設置し、そこに向けて小規模の企業がクライアントシステムで接続するモデル。

» 通信プロトコルはJX手順。

» 送受信の要求はクライアント側から発し、サーバ側はその要求に応じて送受信を行うPull型通信。

» 現行のEOSと同様の運用を実現。サーバ側は、企業が直接行う場合とVANやASPが行う場合があ

る。

３．最初の取引先との本番移行まで


35



ビジネス文書


ビジネス文書





データ変換

データ変換

データ変換

ＥＤＩ


ＥＤＩ

ＥＤＩ



ビジネス文書





社内形式

社内形式


ビジネス文書


ビジネス文書


ビジネス文書


ＥＤＩ


ＥＤＩ

ＥＤＩ



データ変換

データ変換

データ変換ビジネス

文書


ビジネス文書








社内形式

社内形式





36

• 体制の立ち上げ

プロジェクトを立ち上げるため、流通BMS導入の目的を明確にし、必要な体制を決めます。

– 導入目的の明確化

» 自社の現状を整理し、なぜ今流通BMSの導入が必要なのかまとめます。

» ポイントは、取引先からの依頼、JCA手順の限界回避、コスト削減、事業の効率化、業務の拡大、等

会社の置かれている環境を的確に理解することです。

– 体制の検討、組織化

» プロジェクト実施に必要な人材を選出します。

» 体制は、「取引先との接点となる人」「取引先との業務アプリケーションを開発する人」「EDIを運用する

人」「システム・ネットワークインフラを管理する人」から構成されます。

» 経営に関わる方がメンバーに入ることも重要な要件です。

» 実際の構築段階では、ここにEDIパッケージベンダーやSIerは加わります。



37

• 計画の立案

プロジェクトが立ち上がると、具体的な計画の策定に入ります。ここで全体の作業負荷を見

極め、予算を決定します。

– 全体計画の策定

» 導入期間の目安は、６ヶ月。

» システムの規模やアプリケーション改変の有無によりその期間は前後します。

» 「１．導入に関わる全体の流れ」を参考に大まかなスケジュールを組みます。

» 詳細なスケジュールは、標準EDIの仕様の理解や業務の見直しを進める中で確定してください。

– 稟議（予算、人、物の確保）

» 大まかなスケジュールをもとに、概略予算を立てます。

» それをもとに、ハードウェア、ソフトウェア（EDIシステム、アプリケーション開発）、ネットワークベンダー

に対してRFPを提示し、その費用を確定します。

» その他導入関連費用を洗い出し、ベンダー見積を合わせて最終稟議を作成します。

» ポイントは、自社システムと標準システムとのギャップに関わる開発費。



38

②標準EDI仕様の理解

• 従来方式との差異を理解

– 流通BMSとはどのようなものか、新しい通信プロトコルにはどのような特徴があるかをま

ず理解する。

– XMLベースのメッセージとはどのようなものかを理解する。

– 標準の業務フロー、メッセージ、項目の意味や扱いに現状との違いがないかを確認する。

– セキュリティーや証明書・署名は、従来なかった概念なので十分な理解が必要。

– 参考とする資料は、本冊子のほか、巻頭「はじめに」記載の「流通ビジネスメッセージ標

準」ダウンロード資料をご参考にしていただきたい。



39

③取引先との方針確認

• 方針等を相互確認

– 最初に取り組む相手先は、経営レベルで相互に流通BMSの拡大を合意できるお取引先で

あること。

– 「共通確認シート」（*1）をベースに、どの業務をどういう方式でいつごろまでに実現する

かを確認する。

– お互い同じ言葉で確認しても、レベルの相違や理解の仕方にズレがあり、誤解を生むこと

もある。十分な話し合いが必要。

– 実現方法には、いくつものパターンがあるため、具体的な内容まで事前に確認し合うこと。

• スケジュール決定

– 双方の確認事項をもとに、環境構築、システム開発、テスト、本番移行等の順に具体的な

スケジュールを決定する。

– 基本は６ヶ月で可能であるが、各社の事情も加味し無理な計画は立てない。

– 決算期や自社のイベント（サーバ入れ替え・・・）など繁忙期は避ける。

– ここでは大まかなスケジュールとし、詳細な検討を進める中でより綿密なスケジュールに

落としていく。


（＊1）流通システム開発センターよりダウンロード：巻頭はじめに参照


40

(2) 環境構築①ハード・ソフトの調達• 全体構成の設計– どのくらいの規模のシステムにするか。

– シングル構成かクラスター構成か。

– 通信サーバを分散型にするかリバースプロキシ経由単独型にするか。

– 既存EDIとの住み分けをどうするか。

– 既存のインターネット環境との住み分けをどうするか。

– 既存のLAN環境との住み分けをどうするか。

– 基幹システムとの連携をどうするか。ハード・ソフトとも。

• ハード･ソフト構成の検討– ハードやネットワークはどのようになるか。

»サーバやインターネット対応機器など。

– どのようなソフトが必要となるか。»セキュリティ関連ソフトやEDIシステムソフト、業務連携ソフトなど。

– 新規ハードを調達するか既存ハードを転用するか。

– システムの開発が必要かどうか。

– 既存のネットワークやシステムにどの程度の影響を及ぼすか。



41

• ハード・ソフトの選定・手配– 候補製品を選び比較・評価・発注。

– 評価結果は報告書としてまとめておく。

• 工事

– 関連工事の手配・実施

– マシンルームレイアウト、電源、空調、LAN、屋内配線工事など

• ハードの搬入・設置

– ハードの搬入・設置

– 現調・動作確認

• ソフトのインストール

– ソフトのインストール

– 基本設定



42

②ネットワーク環境手配

• 回線事業者（プロバイダ）・回線手配

– 回線事業者やインターネットプロバイダを選ぶ。

– 回線は障害に備えて２系統で確保。（NTTとパワードコム、等）

• グローバルIP・ドメイン名の登録申請

– 流通BMSでは、グローバルIPおよび企業ドメイン名が前提となる。

– 既に所有している場合は問題ないが、なければ新規に申請し取得する必要がある。



43

• 証明書・署名の取得申請（流通BMS専用の証明書）– インターネット経由であるため、証明書・署名の使用が必須となっている。

– 使用するプロトコルやサーバかクライアントにより、必要な証明書・署名が異なる。

– 流通BMSでは、流通業界専用の証明書・署名が必要。パブリック証明書は使用できない。

– 業界指定の発行局に申請し取得する。2008年9月時点では、インテック並びにグローバルサインの２社。

– 証明書にはサーバ証明とクライアント証明がある。サーバ運用する場合にはサーバ証明が必須。

– サーバ証明書を申請すると、サーバ証明書と、クライアント証明書と、署名のフル機能取得できる。

– JX手順のPCでクライアント運用をする場合は、クライアント証明書のみを取得する。

– AS2を使用する場合には、署名が必要。この場合も流通BMS専用証明書をそのまま利用することが可能。

– 一般に有効期限は３年。期限切れになる前に再取得し、自社EDIシステムに登録する必要がある。

• 企業コード（GLN）取得申請– 流通BMSでは、企業コードとしてGLNの使用が必須となっている。

– すでにJAN企業コードもしくはJANメーカコードを保有している場合は、それの利用が可。

– 未使用の場合は、新たに流通システム開発センターに申請し取得する必要がある。



44

③システム環境構築インターネットを利用したセキュアな通信・アプリケーション稼働環境を構築する。• 基本ソフトとミドルウェアの環境設定– サーバOS、DBまわりの設定。– ウイルス対策、DNS設定、FW設定、NAT設定。

• ネットワーク機器の環境設定– ルータやネットワーク関連機器の設定。– 社内LANやプロバイダーとのインターネット接続確認。

• サーバ通信環境の構築– EDI関連サーバと業務サーバ間のシステム連携確認。



45

(3) アプリケーション開発とEDI関連情報設定①システム開発内容の確認• 既存業務との差異を確認– 基本的には、既存の業務を大幅に変更することなく流通BMSに移行できるように考えら

れている。

– ただ、細かく見ると少しずつ異なるところもあるはず。それがどの程度影響があるかを調べる必要がある。

– 業務フロー、メッセージで使われている項目、項目名称の呼び方・自社での使われ方など。

– 業務の視点では、

» 伝票レスをするかしないか、納品のプロセスはどのようなパターンになるか、など。

– メッセージでは、» 企業識別がGLNになり、登場人物も小売側では「支払い法人」「発注者」「直接納品先」「最終納品先」「計上

部署」、卸／メーカー側では「最終送信先」」「請求取引先」「取引先」「出荷場所」等の細かい分類となる。

» 商品コードはGTINになり、発注用コードと集合包装用コードは、分けて考える。

» 日付の考え方も、発注日、納品日（直接納品先納品日・最終納品先納品日）、計上日と意味づけが明確に

なっている。

» その他、番号（取引番号・取引明細番号・取引付属番号等）、金額、数量、区分・コード値、梱包情報、等の

扱いも細かく定められた。

– また、自社独自の方式の有無や標準と一致しない所がないかなどを調査。

– これらについては「マッピングシート」(*2)により、標準と対比しながら使用の有無や扱いを決める。




46

②必要に応じてシステム開発• システムの改修･追加開発箇所を特定– 調査結果に基づき、既存システムに改修を加える必要があるところ、新たに開発しなければならない

ところ、がどこかを特定する。

– 伝票レスによる業務の追加・変更、項目追加やコード値（荷姿コード）標準化による処理の変更など。

• トランスレータを用いてフォーマット変換・データ加工・編集処理– 流通BMSでは標準データフォーマットがXMLとなる。そのため「既存データ⇒XML」「XML⇒既存デー

タ」の変換のステップが新たに発生する。この変換は、フォーマット変換ツール（トランスレータ）を用いて行う。

– XML標準側スキーマは、流通システム開発センターより配布される。これにより、メッセージの基本チェック（バリデーションチェック）を行うことができる。

– トランスレータには、フォーマット変換・項目変換・コード変換・計算・関数処理ができるものもある。どの程度までできるかは、製品のスペックによる。

– 単純な変換や編集・計算などは、極力その機能を使い、手作りのプログラム開発は最小限に抑える。

• 既存業務との連携を含めて必要となるシステムを開発– 開発内容を明確にし、詳細のスケジュールを確定する。

– 個別開発は、通常の開発ルールに従って設計～開発～テストを行う。

– 新しいシステムによる業務の組み立て、既存業務との連携、運用管理も含め、全体の流れを作り上げる。

– テストは、流通BMS関連業務の通信を除いた部分での業務連携テストまで実施する。



47

③EDIサーバに取引先との接続情報設定

レガシーＥＤＩに比べ設定情報が格段に増えている。特に、異なる法人が相対でサーバ相互認証を行うのは経験の少ない分野。接続相手と十分に調整し、不整合のないように注意する。

• 通信パラメータ設定

– 「通信パラメータ協定シート」 (*3)を、「小売側」「卸／メーカー側」双方で記入。

– 記入したものをもとに双方でCPAを作成し、ＥＤＩサーバに登録。ただ、現実には「小売側」がCPAを作成し、「卸／メーカー側」に配布するパターンが多く見受けられる。

– 「通信パラメータ協定シート」にそってＥＤＩサーバに以下の接続情報を設定する。» ＥＤＩ基本情報協定

» ＥＤＩ通信パラメータ協定（ebXML MS、AS2、JX手順）

• 証明書関連設定– 証明書発行局から取得した自社証明書をＥＤＩサーバへ登録。

– ACMSの場合、通信サーバを分散構成にした場合であっても、証明書は管理サーバへ登録。

• 運用情報・業務連携情報設定– スケジュール情報、業務連携情報、運用情報等を、各々必要とされる所定のEDIサーバ

や関連機器に設定する。




48

(4) テスト計画・移行方針の策定

①テスト計画の策定

• 流通BMSに関わる業務一連の流れに対してテスト計画を立てる。

• 改修・追加・新規開発を含めた社内システムと、相手先まで含めた全体の流れ

を分けたテスト計画が必要。

• 特に障害系については、社内のみならず関連企業との連携もふまえた計画を作

成する。



49

②移行方針の策定

– 移行にあたっては、接続先と移行対象・移行順・時期・整合性の確認方法・旧シ

ステムとの並行稼働期間等について綿密な調整を行う。

– 本番開始判定基準、旧システムの停止基準を双方で確認する。

– 本番移行が不可能だと判断した場合、旧システムに戻すための段取り等も計

画、明文化する。

– 移行において個別対応が必要な場合を想定し、その対応マニュアルも作成す

る。

– 本番移行後、未整備のドキュメントはキッチリとまとめ、拡大時に混乱のないよ

うマニュアル化を進める。

– 拡大に向けた取引先への説明会、説明資料等の準備も行う。



50

(5) 取引先との接続テスト①フェーズ１：疎通テスト• EDI通信環境の相互接続

• ネットワークの確認、EDIシステム送受信確認– 相互認証を含めたEDIシステム間でのメッセージ送受信を確認。

②フェーズ２：EDIシステム間の流通ビジネスメッセージ標準確認• 送信メッセージの生成とEDI通信、受信メッセージの検定

• 標準メッセージ形式と送受信の相互接続– 業務データをXMLの標準フォーマットに変換して送信、受信した側はそのXMLデータを業

務データに逆変換し整合性の確認を行う。

– 整合性の確認は、XMLレベルでのスキーマを使ったバリデーションチェックと業務レベルの項目チェックの両方で確認する。

③フェーズ３：業務システム間の整合性確認• 業務システムを含めた標準プロセスに従った送受信の確認– 本番業務に準ずるデータを用意し、業務の最初から最後まで通した一連の結果が正当で

あることを双方で確認する。

– 実際に起こり得るあらゆるパターンの確認を行い、整合性が確認できた段階で本番移行可能とする。



51

(6) 本番移行①旧システムとの並行運用による新システムの稼働開始• 本番稼動状況ウォッチ• 旧システムとの整合性チェック– 新システムに本番データと同じデータを投入し並行稼働開始。

– 稼働結果を確認し整合性をチェック。

②旧システムから新システムへ本番業務を切替• 本番開始判定• 本番業務を旧システムから新システムへ切替– 本番開始判定基準に基づき、取引先と双方合意が取れた段階で本番業務を新システム

に切替。

③旧システムの並行運用停止• 旧システム停止判定• 旧システムを停止し新システムでの完全本番化– 一定の並行稼働後、旧システムの停止基準に基づき旧システムを停止。移行は新システ

ムだけで稼働。

③移行後のドキュメント整備– 正常稼働を開始した段階で、継続運用が可能なように各種ドキュメント、マニュアル類を

整備する。



52

Ⅲ．導入事前準備１．流通ビジネスメッセージ標準２．通信プロトコル標準３．必要となる申請・手続と期間

３－１回線・プロバイダ・グローバルIP３－２ドメイン名３－３証明書３－４ＧＬＮ（Global Location Number ）


53

１．流通ビジネスメッセージ標準

(1) 業務プロセス受発注業務モデル：業務の流れを標準化•小売企業と卸・メーカとの間で受発注･出荷･受領をやり取りするモデル。

•発注で付番される取引番号が、出荷、受領、請求、支払の各メッセージに引き継がれるため、取引番号をキーとして発注から支払までの取引を追うことができる。

業務とメッセージ種：業務の種類とメッセージの内容を標準化•発注［発注、生鮮発注、集計表作成］、出荷［出荷伝票、出荷梱包（紐付あり）、出荷梱包（紐付なし）、生鮮出荷］、受領［受領、生鮮受領、集計表作成］、返品［返品、生鮮返品］、請求、支払、値札、在庫［補充勧告、報告］、入庫［予定、確定］、等。

•メッセージ種はEDI通信手順に依存していない。

伝票レス：紙の伝票を廃止•「ＥＤＩメッセージ」を商品売買の証憑とみなすことにより、取引当事者間でやり取りされているペーパーの仕入伝票（統一伝票）をなくし、運用費用（伝票代、発行時間、保存コスト、パンチコスト等）を削減する。

•現在は流通ＢＭＳの使用に限り、請求伝票に関して保存しなくても良いと国税庁から確認が取れている（請求伝票以外は、企業個別に税務署の確認を受ける必要があるが、将来的には、帳票保存が不要になる予定）


54

１．流通ビジネスメッセージ標準メッセージ一覧



55


(2) メッセージ項目企業識別：登場人物とコード体系を標準化

•登場人物の体系を標準化【課題】

－従来は、項目として「店」、「センター」、「計上部署」があり、指定が必要な場合に当事者が任意にセットするルールとしていたため、卸・メーカー（受注者）にとって、物流上、商流上の決済ポイントがあいまいになる恐れがあった。

【対策】

－流通ビジネスメッセージ標準では、最終納品先、直接納品先、計上部署、発注者、支払法人の５つを設けて、「卸メーカー（受注者）は、どこに納品するのか」、「最終的にどこに納品されるのか」「所有権が移転するのはどこか」「発注者は誰か」「支払うのは誰か」を表現できるようにした。（次ページ参照）

– 登場人物：小売» 最終納品先、直接納品先、計上部署、発注者、支払法人

– 登場人物：卸・メーカー» 最終送信先、請求取引先、取引先、出荷場所


56

売場・フロア売場・フロア


– 登場人物の関係

店舗店舗

最終納品先／計上部門

陳列場所

物流センター物流センター

直接納品先／計上部門

小売Ａ社小売Ａ社

小売小売（Ａ社グループ企業）（Ａ社グループ企業）

卸・メーカ卸・メーカ XX社社

卸・メーカ卸・メーカ（（XX社グループ企業）社グループ企業）

支払企業請求取引先

発注者取引先

倉庫倉庫

事業部事業部

枝番

出荷先コードVANVAN

データ送信元直接送信先最終送信先

VAN事業者が介在する

場合



57


•GLN（Global Location Number）－コード体系を標準化

– 国際流通標準機関GS1が、企業や事務所を識別するために定めた、グローバル

でユニークになる１３桁のコード

– JAN企業コード／GLN企業コードは、流通システム開発センターが付番貸与GLNロケーションコードは、各企業が付番基準に沿って自らの責任で付番

商品識別：コード体系を標準化

•GTIN（Global Trade Item Number）－コード体系を標準化

– 集合包装用商品コード（１４桁）とEANコード（JANコード：１３桁、８桁）とUPCコー

ド（１２桁、８桁）を包括し、１４桁にそろえた国際標準の識別コード。

– 現在のJANバーコード・シンボル、およびその桁数（１３桁、８桁）を変更する必要

はない。

– 上記３種類のコードは、いずれも「０」を前詰めし、１４桁にそろえてGTINとする。

４４９９００１１００１１００ＬＬＬＬＬＬＬＬＬＬ CDCD（例）（例）

GLNGLN企業コード（企業コード（JANJAN企業コード）企業コード）

ロケーションコードロケーションコード各企業が付番各企業が付番


58


メッセージ間の項目の引継ぎ発注・出荷・受領メッセージ間における項目の引継ぎ例。赤字の部分は、前のメッセージでセットされた値を後のメッセージに引き継ぐ。

＜支払い法人＞

支払い法人コード

＜発注者＞

発注者コード

＜取引＞

取引番号： 1000001請求取引先コード

取引先コード

＜取引内容＞

発注日： 2007年1月18日

計上日： 2007年1月２０日（予定日）

＜取引合計＞

原価金額合計： 5,000円

数量合計： 5

＜取引明細＞

商品コード（発注用）

原価金額： 1,000円

発注数量（バラ）： 5

＜取引明細＞

・・・・・・

発注発注

■赤字は引継項目 ■青字は基本的には引継だが変更する場合もある項目（再計算等） ■灰色の字は引き継がない項目



＜発注者＞

発注者コード

＜取引＞


取引先コード

＜取引内容＞


計上日： 2007年1月２０日（予定日）

＜取引合計＞


数量合計： 4 （再計算）

＜取引明細＞



発注数量（バラ）： 5出荷数量（バラ）： 4欠品数量（バラ）： 1

＜取引明細＞

・・・・・・

出荷出荷



＜発注者＞

発注者コード

＜取引＞


取引先コード

＜取引内容＞


計上日： 2007年1月２3日（確定日）

＜取引合計＞


数量合計： 4

＜取引明細＞



発注数量（バラ）： 5出荷数量（バラ）： 4欠品数量（バラ）： 1受領数量（バラ）： 4

＜取引明細＞

・・・・・・

受領受領



59


(3) メッセージ構造メッセージフォーマットにXMLを採用

•XMLの特徴

–各データ項目単位にデータの意味を表すタグを持ち、複数のデータ項目をグルー

プ化（構造化）することができる。外部構造化も可能。

–データとレイアウト・デザインを分離可能。

［XMLデータ例］<lineID>

<lineNumber>01</lineNumber></lineID><itemID>

<gtin>04902106843603</gtin><orderItemCode codeType="005">4902106843603 </orderItemCode><name>こだいらカップ本格的コーンクリーム１０Ｐ</name><name_sbcs>ｺﾀﾞｲﾗｶｯﾌﾟﾎﾝｶｸﾃｷｺｰﾝｸﾘｰﾑ</name_sbcs>

</itemID>・

・

•EDIを行う上でのメリット

–XMLは多くのプラットフォーム上で取扱可能なため、システム環境に依存すること

なくデータ転送・データ処理が可能。


60


XML化を進めることにより得られるメリット

•データの意味を表すラベル（タグ）とグループによる構造化によって、データ

に意味（内容）と構造（グループ化）を保持したままデータ交換が可能なため、

アプリケーションの共通化を図ることが可能。

•スキーマ(XML Schema など)を使ってデータ構造を外部定義することが可

能なため、このスキーマを共有することで標準化を保つことが出来るととも

に、データのチェックやデータ変換定義の作成に活用することも可能。

•スタイルシート(XSLT)を使用することで、画面表示や印刷のレイアウト定義

が容易に作成できる。


61


メッセージの基本構造

①ＳＢＤＨ

②メッセージ情報

③発注ヘッダー

④取引ヘッダー

⑤明細

①ＳＢＤＨ（Standard Business

Document Header）

メッセージの送受信に必要な情報を記述送信プロトコルの規定に従って参照される。

② メッセージ情報メッセージに含まれる取引件数や、最終送信先への送受信件数を集計するのに用いられる。

③ 発注ヘッダー

送信されるメッセージの取引に関するデータを括る発注者と支払い法人が記述される。出荷梱包の場合のみ発注者と最終納品先ごとの梱包に関する情報を括る故、取引先や直接納品先などの項目が記述される。

④ 取引ヘッダー一取引先における取引明細情報を括る項目が記述される。伝票での伝票ヘッダーにあたる。

⑤ 明細一取引先における取引明細が記述される。



62

(4) 証明書

手順別推奨セキュリティ設定について

• 各手順毎に推奨されるセキュリティ設定は下記の通り。


（流通システム開発センター資料より（流通システム開発センター資料より（（一部加筆一部加筆））））


63

SSL証明書とメッセージ署名用証明書の違い

• SSL証明書は通信経路上の暗号化を実施するために必要。

• メッセージ署名用証明書はビジネスメッセージへの電子署名のために必要。

• 通常、SSL証明書とメッセージ署名用証明書は別々に導入が必要であるが、流通BMS専用の証明書はこの双方に対応している。

• 2008年9月現在、流通BMS専用証明書発行局として認証されているのは、以下の2社。

– グローバルサイン（株）

– （株）インテック



64

流通業界専用証明書について

• 流通BMSを実施する際には、必ず流通業界専用の証明書を使わなけれ

ばならない。


※ 通常、SSLサーバ証明書はサーバごとに証明書を取得する必要があるが、弊社ACMS製品については、負荷分散のため複数の通信サーバを立てる場合であっても証明書は管理サーバで一元管理するため、１通の証明書を取得するだけでよい。



65

流通BMSの認証方式について• 事前にルートCA※と中間CAの証明書を事前交換しておくが、お互いのサーバ証明

書は交換しない。これは、下記のようにルートCAと中間CAが一致することによりサーバ証明書は正しいものとみなし認証する、という方式を採用しているためである。

• この方式を採用している理由は、小売企業の中には接続先が数千社に及ぶものが存在するため、数千社分の証明書交換と期限切れ証明書更新の負荷が運用に耐えられないと判断されたためである。


ルートCAルートルートCACA

中間CA中間中間CACA

ユーザユーザユーザ接続先接続先接続先EDI接続

ルートCA、中間CAの証明書を事前にインポート

信頼

証明証明

証明証明

※ＣＡ：認証局


66

証明書の切替• 証明書には有効期限（流通業界専用証明書の場合、最長３年）が存在するため、証

明書の切替が必要であり、切替実施については相対間での日程調整が必要になる。

• それ以外にも鍵の漏洩等により切替が必要となるケースがある。




67

(5) XMLスキーマXMLスキーマは商材拡大やプロセス拡充などのため、今後もまだまだバージョンアップ

が実施される予定である。




68

従って、今後発生するバージョンアップに対し柔軟に対応できなければならない。• 生鮮の商材拡大

• 百貨店業界への適用

上記は、平成20年度に予定されているバージョンアップ

また、複数バージョンが併存することになるため、複数バージョンを利用できるシステムでなければならない。• グロサリ商材： V1.0 • アパレル商材： V1.1 • 生鮮商材： fresh V1.0

上記は、平成19年度実証実験までの実績


※ 弊社ACMS製品については、AnyTran(トランスレータ)変換定義は接続相手先毎にその

利用バージョンに合う変換定義を使用することが出来るため、複数バージョンへの対応は問題なく、かつ、変換定義を入れ替えることでバージョンアップへの対応も迅速に実施可能である。


69

XMLスキーマ検証• XMLスキーマ検証（妥当性検証）機能を持ち合わせていなければならない。

• XMLスキーマ検証についても、複数のスキーマバージョンが併存することになるため、複数バー

ジョンが利用できなければならない。

• 本番前のテスト通信では、XMLスキーマ検証によってデータフォーマットの正当性チェックを実

施し、本番開始に向けての判断材料の一つとする。

• なお、本番通信でXMLスキーマ検証を実施しエラーが発生したとしても、そのエラーを相手へ通知する手段がないことと、検証の実施によりCPU・メモリ等のコンピュータ資源を消費することより、本番でXMLスキーマ検証を実施するかどうかについては、慎重に検討しなければならない。


※ 弊社ACMS製品については、AnyTran(トランスレータ)変換定義にてXMLスキーマ検証を実施するかどうか指定する。また、そのチェック時に使用するXMLスキーマについては

実行時に柔軟に変更することが可能なため、複数バージョンへの対応も容易である。



70

(6) データ圧縮データサイズが大きな場合にはデータ圧縮を行うよう、下記の指針が出ている。




71

データサイズ10MB越えを目安として、圧縮の検討を行う。

• JX手順で検討を進めていた場合には、サーバ型のebXML手順もしくはAS2手順へ

の通信手順変更も検討する必要がある。

データ圧縮は、通信相手先・メッセージ種ごとに圧縮する／圧縮しないを取り決める。

• 圧縮する、と取り決めたデータ種については、ある日のデータが10MBを下回る

データサイズであったとしても、必ず圧縮しなければならない。


※ 弊社ACMS製品については、ZIP圧縮機能は提供しない。利用ユーザにおいてZIP圧縮ツールを入手頂き、ACMSのEDI連携のJOBステップとしてZIP圧縮ツールを呼び出すことにより、流通BMS標準で示された圧縮を実現する。


72

(7) 禁則文字禁則文字については下記のような指針が存在するため、これに従わなければならない。




73

(8) EDI通信パラメータの調整「流通BMS協定シート」を使用して、EDIシステムの設定に必要な業務とITの

パラメータ調整を行う。

「流通BMS協定シート」は、「共通確認シート」、「EDI基本情報協定シート」、「EDI通信パラメータ協定シート」、「EDI通信パラメータ情報シート」で構成され

ている。




74

「流通BMS協定シート」に、EDIを実施する相対間でそれぞれの必要項目を記入の上パラメータ調整を実施することにより、スピーディーなEDI実施を可能と

している。

また、同一資料を双方で保持することによりパラメータの不一致を排除することが出来る。




75

「EDI通信パラメータ情報シート」は３種類の通信手順毎に分かれており、通信

手順毎に調整・設定が必要な通信パラメータが記載されている。

この「EDI通信パラメータ情報シート」を元に、お互いのEDI通信ソフトウェアに

対して通信パラメータを設定できるようになっている。




76

調整作業で使用する「流通BMS協定シート」は、小売企業が作成して卸・メーカ企業に提

示し、卸・メーカ企業は自社情報を記入して返送するルールとなっている。

ebXML手順の場合には、「流通BMS協定シート」を元にCPA（通信設定の定義情報）を

作成するのも小売企業の作業となる。


小売小売小売仕入先仕入先仕入先

「流通BMS協定シート」の送付（自社情報記入済）

「流通BMS協定シート」へ必要事項記入、返送

CPAの作成と送付

CPA受領

ACMSへCPA読み込みACMSへCPA読み込み

流通BMS協定シート

CPA

ACMSACMSEE22XX

ACMSACMSEE22XX

流通BMS協定シート


77

２．通信プロトコル標準

(1) 通信基盤：インターネット経由でのHTTPを前提とする。

(2) 通信プロトコル：標準として３種類（ebXML MS、EDIINT AS2、JX手順）を制定。

３プロトコル登場の背景•最初にeJapanでebXML MSが次世代通信プロトコルとして定められた。

•ただし、流通業界ではプッシュ型サーバとサーバタイプのこのプロトコルではEOSに対応できないため、独自プロトコルとしてSOAP-RPCをベースとしたプル型であるJX手順が定められた。

•しかし、海外ではウォルマートを中心としたEDIINT AS2の利用が盛んとなり、今後グローバルな取引を考えた場合、本プロトコルの採用も必須との意見が多く出された。

•これらを総合し、通信プロトコルはebXML MS 、EDIINT AS2、JX手順の３プロトコルを標準と定めることとなった。

•３プロトコル利用上の言葉と意味の統一を図るため、「EDI通信パラメータ協定シート」並びに「EDI通信パラメータ情報シート」を作成している。


78

２．通信プロトコル標準

(3) 各プロトコルの構造

通信プロトコルヘッダ（ＨＴＴＰ）

MIMEエンベロープ（付属文書付きSOAP）

ＭＩＭＥパート

ＳＯＡＰエンベロープ

ＳＯＡＰヘッダー

ＳＯＡＰボディー

ebXML MS

ebXML MS 情報

付属文書一覧

ＭＩＭＥパート

ペイロード付属文書文書


SＭＩＭＥ or MIMEメッセージ

EDIINT AS2

文書

署名


ＳＯＡＰエンベロープ

ＳＯＡＰボディー

SOAP-RPC情報

文書

ＳＯＡＰヘッダー

JX手順

いずれのプロトコルについても、いずれのプロトコルについても、流通流通BMSBMSの規定の規定ではでは

１通信で１文書のみの送受信と１通信で１文書のみの送受信と規定されている規定されている。。

AS2 情報


79

(1) サーバ

•プロバイダ選定および回線申請（申し込み～開通まで約２週間）

– 固定ＩＰアドレス（グローバルIP）を使用できるプロバイダを選定

– プロバイダのサービス品目にある回線を申請

注：Ｂフレッツは、常時接続性を保証したサービスでは無い為、バックアップ回線として、

ひかりone、Yahoo! BB 光、等を同時に契約される事をお勧め。

(2) クライアント

•プロバイダ選定および回線申請（申し込み～開通まで約２週間）

– 接続回線を選定【例】ISDN・ADSL・CATV・FTTH（光ファイバー）、等

– 選定した回線が使用可能なプロバイダを選定

– 選定した回線を申請

３-１．回線・プロバイダ・グローバルIP３．必要となる申請・手続きと期間


80

(1) サーバ

•ドメイン名決定および登録申請（約７営業日）–取得したい属性型JPドメイン名(XXX.co.jp)を日本レジストリサービスより指定された属性型・地域型JPド

メイン名のレジストラサイトで検索し、使用されていない事を確認した上で、そのドメイン名のレジストラへ

申し込む。

•DNSサーバ構築とDNSサーバIPアドレスの登録

–DNSサーバ構築（２～３日）

» グローバルIPアドレスを割り振った、DNSサーバ（プライマリ・セカンダリ）の構築

–DNSサーバＩＰアドレスの登録（１営業日）

» DNSサーバ（プライマリ・セカンダリ）のグローバルIPアドレスをレジストラへ登録申請

(2) クライアント

•不要

３-２．ドメイン名

３．必要となる申請・手続きと期間


81

【例】インテックの場合

①各種情報確認確認項目コモンネーム (FQDN) (CN)部署名(OU)法人名(O)住所(L)都道府県名(ST)国･地域名(C)

②申請書類のダウンロード③申請書類の記入および送付④証明書発行キット(CD-R)の受け取り⑤認証局証明書のダウンロード⑥認証局証明書のインストール⑦指定URLにアクセスし証明書の発行操作⑧証明書の格納⑨証明書のエクスポート

⑩証明書のサーバへのインストール

発生費用登録料（初期費用）更新料（3年ごと）

(1) サーバ•流通BMS対応電子証明書（サーバ）の取得（約１０営業日）

３-３．証明書


※株式会社インテック EINS/ PKI+ for EDI 資料より抜粋※グローバルサイン（株）からも提供されています。


82

(2) クライアント•流通BMS対応電子証明書（クライアント）の取得（約１０営業日）

【例】インテックの場合

①各種情報確認確認項目部署名(OU)法人名(O)住所(L)都道府県名(ST)国･地域名(C)

②｜(1)サーバの場合と同じ⑩

発生費用登録料（初期費用）更新料（3年ごと）


※株式会社インテック EINS/ PKI+ for EDI 資料より抜粋※グローバルサイン（株）からも提供されています。


83

(1) サーバ・クライアント共通•企業コード（GLN）の取得（約１週間）

– 『GLN専用企業コード登録申請書』に必要事項を記入

– 登録申請料を納付

– 登録申請書の裏面に登録申請料納付後の受領証（コピー）を貼付して、流通システム開発センター宛に郵送（FAX不可）

– 流通システム開発センターにて登録申請書を受付後、約１週間でGLN管理担当者様に『GLN専用企業コード登録通知書』が郵送される。

注) 自社の商品にJANコードを表示する必要がある場合には、GLN企業コードと併用できるJAN企業コード（JANメーカーコード）の申請が必要。JAN企業コードを申請（有料）する場合の問い合わせは、財団法人流通システム開発センターまで。

３-４．ＧＬＮ



84

Ⅳ．流通BMSの導入１．環境の構築２．システム規模の選択３．目的に応じた具体的構成４．ACMSアップグレードパス


85

※※１１ ACMS EACMS E22XXは、既存のは、既存のWebWebアーキテクチャ使用時でも、分散管理アーキテクチャ使用時でも、分散管理機能により、機能により、ACMSACMS独特の非常にセキュリティレベルが高い構成を可能。独特の非常にセキュリティレベルが高い構成を可能。

（詳細は、３．（詳細は、３．目的に応じた具体的構成目的に応じた具体的構成を参照）を参照）

(1) サーバ（約１ヶ月）

社外接続用ネットワーク構成の

決定、および、ネットワーク機器

の導入・構築。

•既存のウェッブアーキテクチャ構成と

リバースプロキシ型構成には、各々右

図の様なメリット・デメリットがある。

(2) クライアント（約２週間）

社外接続用ネットワーク構成の決定、および、ネットワーク機器の導入・

構築。

１．環境の構築


86

※下記の条件も考慮に加えることをおすすめします。

・業務拡張により、ビジネスメッセージの増加した場合。・今後、取引先の増加した場合。・何らかの理由で２日分の送受信が発生した場合。

◆ＪＣＡ注文データ１伝票をXML化すると下記のデータ量と

なります128byte × 4.2レコード × 12倍 ≒ 6.5kB

◆その支払データが10MBになるケースを想定すると、下記の

ように、１日約230伝票分の注文データがあった場合となります

10MB ÷ 128byte ÷ 12倍 ÷ 30日 ≒ 227.5伝票

※1ヶ月に換算すると約7000伝票（230伝票×30）なので、

7000～10000伝票（注文明細行）を目安として考えてください。

［ご参考］注文データだけで10MBになるケースは、下記のように、

１日約1630伝票が発生する場合となります

10MB ÷ 128byte ÷ 4.2レコード ÷ 12倍 ≒ 1625伝票

※共同実証の結果より、JX手順（クライアント）による取引は、取引先との１取引データ量が１０MBを超えないことが、推奨されています。

◆ １取引データ量による選択 ⇒伝送の可能性がある、最も大きなデータを想定してください。

・注文データ１レコード＝128byte・注文データ１伝票＝4.2レコード (1ヘッダ + 3.2明細)・テキスト→XML変換指数＝１２倍

・支払データ１レコード＝128byte・支払データ１伝票＝1レコード

・１ヶ月の受注日数＝30日

◆ 同時接続数による選択 ⇒ピークの運用時に必要とされる、同時接続数の最大数

２．システム規模の選択


87

１取引データ量による選択

１

４

１

無制限

１

15MB以上10~15MB１０MB未満

同時接続数による選択

③③ クライアントクライアント

②② ミドルサーバミドルサーバ（（WindowsWindows環境のみ）環境のみ）

①①’’ サーバサーバ①高セキュリティ構成、負荷分散型構成①高セキュリティ構成、負荷分散型構成

※表の基準は目安です。

・採用する通信手順、想定されるデータの量、将来必要となるメッセージ等に関しましては、必ずお取引先にご相談ください。

〜〜

〜〜



88


5000明細,同時8受信

1分半程度で完了※１

◎

分散構成可ネットワーク構成AACMS E2X①

5MBの受信

30秒程度で完了※１－ネットワーク構成CACMS Lite③

4000明細,同時4受信

2分程度で完了※１△

分散は不可

クラスタは不可

ネットワーク構成BACMS B2B LE②

○

分散は不可ネットワーク構成BACMS B2B①’

サイジングセキュリティと可用性

推奨ネットワーク構成

（次ページ以降参照）製品

※１：マシンスペックは次ページ以降を参照


89

ACMSの分散構成では、DMZ上の通信サーバには送受信データを実体化させる事なく、運用する事が可能。

従って、DMZ上の通信サーバが攻撃を受けた場合でも、送受信データの漏洩・改竄・破壊を防止でき、セキュアな運用環境を提供。

InternetInternet

ファイアファイアウォールウォール

DMZDMZ

通信サーバ通信サーバ--11

ACMSACMSEE22XX

通信サーバ通信サーバ--22

ACMSACMSEE22XX

負荷分散装置負荷分散装置

クラスタ構成クラスタ構成

社内ネットワーク社内ネットワーク管理サーバ管理サーバ共有ディスク共有ディスク

送受信送受信データデータ APAPデータデータ

管理ＤＢ管理ＤＢ

証明書証明書

通信サーバと管理サーバを分散配置通信サーバと管理サーバを分散配置

ACMSACMSEE22XX

３．目的に応じた具体的構成

３－１．ネットワーク構成Ａ


90

セキュリティ対策

通信機能をDMZ上に置く分散配置を推奨。

• データが隔離された社内LAN上に存在するため最もセキュリティが高い

• 既存および、新規にかかわらず、インターネット接続の出入口には、ファイアウォールの設置と、社内LANとの間には緩衝域としてのDMZ（非武装地帯）の設置が必要である。

• 必要なHW、SWは多種多様であるが、セキュリティレベルの変更という考え方ではなく、ネットワーク規模（トラフィック）によって設置するHWの能力（キャパシティ）を決定し、新規の設置や増設を行うという考え方が一般的。

– 現在市販されているルータ等のHW（旧型の機種は確認が必要）は、安価なものであってもすでにDMZ構築に必要な機能を持っていることが多い。

– サイバーアタック検知機能、ファイアウォール機能、SSLサーバ機能、VPN機能、DHCP機能、といったネットワーク構築に必要な機能が一筐体のHWに全て組み込まれたものが主流となっているので、これを導入するのが一般的。

※ただし、セキュリティ対策はあくまで該当企業のポリシーに従うものとする。

３－１．ネットワーク構成A



91

インターネット環境

既存の環境を流用

• ただし、ネットワーク規模（トラフィック）によっては、増設あるいは、新規の回線設置が必要。

新規の環境

• 回線の信頼性を考慮した選択が必要。

– よりクリティカルな環境においては、バックアップの目的で二本以上の回線を異なる回線プロバイダと契約し、回線の二重化を推奨。（回線プロバイダの責任において、回線トラブル時の切り替えなどを行うサービスもあるので契約時に確認。）

– 回線品質をある程度保証する法人向けインターネット回線もあるが、高額となる。

– 最終的にはコストとリスクに配慮し、各社の事情に見合うものを選択することになる。




92

サイジング

下記は比較的低スペックなマシンで測定したACMS E2XでのebXML(流通BMS)プロトコル通信の測定である

－

172.6s

138.5s

86.3s

40.6s

平均

－

16.1s

16.4s

7.0s

4.2s

平均

処理時間通信時間

157.9s26.5s7.11MB0.99MB165,0003

95.5s11.8s7.11MB0.99MB85,0002

46.5s8.8s7.11MB0.99MB45,0001

191.3s20.2s35.5MB4.95MB425,0004

1

多重度

100,000

明細件数

244.3s18.4s142MB19.8MB5

全体全体

XMLデータ

サイズ

JCAデータ

サイズ

No

測定環境（サイジング基礎データとするため低スペックの環境にて測定）

• Ｓｏｌａｒｉｓ１０

• CPU : AMD family 15 model 65 step 2 clock 1809 MHz• MEM : ２ＧＢ

測定条件（XMLから量販フォーマット(FLAT)へ変換したのち自社フォーマット(FLAT)へ変換）

• XMLデータ受信→MIMEデコード→XMLtoFLAT変換→FLATtoFLAT変換




93

DMZDMZ

リバースプロキシリバースプロキシ

証明書証明書

InternetInternet


クラスタ構成クラスタ構成

社内ネットワーク社内ネットワーク通信通信// 管理管理

サーバサーバ

送受信送受信データデータ管理ＤＢ管理ＤＢ

ACMSACMSB2BB2B

３－２．ネットワーク構成Bリバースプロキシを使った構成リバースプロキシを使った構成

DMZ上にはリバースプロキシのみを配置することにより、外部からの通信を制限し社内ネットワーク内のACMSサーバに接続。

※ この構成の場合、http通信が社内ネットワークまで入るため、非常に高度な「なりすまし」による進入を受けた場合、http上に仕込まれた悪意あるプログラムが社内ネットワークに影響を及ぼす可能性を残す。また、アクセスがすべてリバースプロキシを経由するため、負荷が高い場合にはリバースプロキシサーバがボトルネックとなる可能性がある。

oror

※※ LELEの場合は、クラスタ構成不可の場合は、クラスタ構成不可

通信通信// 管理管理

サーバサーバ

送受信送受信データデータ

ACMSACMSB2B LEB2B LE 管理ＤＢ管理ＤＢ


フォワードプロキシフォワードプロキシ

証明書証明書


94


リバースプロキシ設定を既存の環境に加えたり、新たに構築することを推奨。

• 必要なHW、SWの選定方法は大規模と同様。ただし、既存のプロキシサーバの設定変更のみで対応可能な場合もある。

• 新規導入の場合。

– 大規模同様、ネットワーク構築に必要な機能が一筐体のHWに全て組み込まれたものが主流となっているので、これを導入するのが一般的だが、プロキシサーバだけは別途用意する必要がある。

– 安価に済ませるためには、専用のHW導入を避け、導入サーバに、該当する機能を持ったSWを導入する手段もある。ソフトウェアはウィルス対策（サイバーアタック検知、ファイアウォール）、Webアプリケーションサーバ（SSLサーバ、DHCP、プロキシサーバなど）を導入する


ネットワーク構成Aと同様。


３－２．ネットワーク構成B



95

サイジング

下記は比較的低スペックなマシンで測定したACMS B2B LEでのebXML(流通BMS)プロトコル通信の測定である

34.2s4.1s5MB715KB14,0003

6.0s2.4s513KB72KB14002

3.7s2.3s53KB7KB1401

7.1s2.8s53KB7KB4404

4

4

多重度

4,000

400

明細件数

132.9s7.1s5MB715KB6

18.6s3.1s513KB72KB5

全体処理時間全体通信時間XMLデータサイズJCAデータサイズNo

測定環境（サイジング基礎データとするため低スペックの環境にて測定）

• CPU : Celeron 2.0GHz• MEM : 1024MB


• XMLデータ受信→MIMEデコード→XMLtoFLAT変換→FLATtoFLAT変換

３－２．ネットワーク構成B



96

３－３．ネットワーク構成Cクライアント環境クライアント環境

InternetInternet

ファイアファイアウォールウォール相当機能相当機能

社内ネットワーク社内ネットワーク

証明書証明書

クライアントクライアントPCPC

ACMSACMSLiteLite

送受信送受信データデータ

インターネットに接続可能なWindowsクライアントPCを使用する。ウィルス対策ソフトやファイアウォールの使用を推奨するが、使用するかどうかは各企業のセキュリティポリシーに任せる。

• 可能であれば、ルータが持つファイアウォール機能や、ウィルス対策ソフトのファイアウォール機能を利用する。もしくは、WindowsOS標準のファイアウォールでも十分使用に耐えると考える。



97


ウィルス対策ソフトの導入を推奨。

• 可能であれば、ルータが持つファイアウォール機能や、ウィルス対策ソフトのファイアウォール機能を設定することが望ましい。また、WindowsOS標準のファイアウォールでも十分使用に耐えると考える。


既存の環境を流用

• ただし、ネットワーク規模（トラフィック）によっては、増設あるいは、新規の回線設置が必要。

新規の環境

• プロバイダ選定および回線申請

– 接続回線を選定【例】ISDN・ADSL・CATV・FTTH（光ファイバー）、等

– 選定した回線が使用可能なプロバイダを選定


３－３．ネットワーク構成C



98

サイジング

下記は比較的低スペックなマシンで測定したACMS LiteでのJX手順プロトコル通信の測定である

27.4s8.9s5MB715KB14,0003

7.9s5.3s513KB72KB14002

6.2s5.0s53KB7KB1401

多重度明細件数処理時間通信時間XMLデータサイズJCAデータサイズNo

測定環境

• CPU : Celeron 2.0GHz• MEM : 1024MB


• XMLデータ受信→XMLtoFLAT変換→FLATtoFLAT変換

３－３．ネットワーク構成C



99

• インターネット系の次世代手順はDMZ上の通信サーバで通信を実行するが、従来型手順は社内ネットワークに置く通信/管理/APサーバで通信する。

［ご参考］従来型手順との共存［ご参考］従来型手順との共存

３－４．ネットワーク構成（従来型共存）

InternetInternet


DMZDMZ

社内ネットワーク社内ネットワーク

通信通信// 管理管理/ AP/ APサーバサーバ

通信サーバ通信サーバ

送受信送受信データデータ証明書証明書

通信回線網通信回線網((専用線／専用線／ISDN)ISDN)

USTUST

ダイアルアップルータ全銀手順全銀手順JCAJCA手順手順

全銀全銀TCP/IPTCP/IP手順手順

次世代次世代手順手順

ACMSACMSEE22XX

ACMSACMSEE22XX



100

※詳細は、製品価格表にてご確認ください。

手順追加手順追加（必要な手順が後から追加できます）

同時接続数

同時接続数

（接続数を増やせます）

JX

AS2

ebXML MS

JCA

全銀

WebAgent

全銀TCP/ IP

全銀TCP/ IPJX WebAgent

手順追加手順追加（必要な手順が後から追加できます）

４

３

２

１

BACREX手順

４．ACMSアップグレードパス


101

Over

５０

２０

１０

５

２

手順追加（必要な手順が後から追加できます）

同時接続数追加

同時接続数追加

（接続数を後から追加できます）

JX

AS2

ebXML MS

JCA

全銀

WebAgent

全銀TCP/ IP

※詳細は、製品価格表にてご確認ください。

LEから、B2B・E2Xへのアップグレードも可能

Over

64

32

16

８

４

２

（分散処理サーバを通信サーバ、変換サーバなどの負荷に応じて後から追加できます）

ノード数追加

BACREX手順

４．ACMSアップグレードパス


102

〒〒103103--00130013東京都中央区日本橋人形町東京都中央区日本橋人形町11--33--88TelTel 0303--56405640--85448544FaxFax 0303--56405640--85418541EE--MailMail [email protected]@dal.co.jpURLURL http://http://www.dal.co.jpwww.dal.co.jp//ブログ「ＥＤＩ情報館」ブログ「ＥＤＩ情報館」

URLURL http://http://wwwwww.ediblog.jp.ediblog.jp

データ・アプリケーションデータ・アプリケーション株式会社株式会社

お問い合わせ先お問い合わせ先

・・DALDALおよびおよびACMSACMS，，AnyTranAnyTranは株式会社データ・アプリケーションの日本および海外での登録商標です。は株式会社データ・アプリケーションの日本および海外での登録商標です。

・その他記載の社名および製品名は、各社の商標または登録商標です。・その他記載の社名および製品名は、各社の商標または登録商標です。

（流通BMS 2009 年度版解説書 - DAL...流通ビジネスメッセージ標準...

Documents

Transcript of （流通BMS 2009 年度版解説書 - DAL...流通ビジネスメッセージ標準...

（流通BMS 2009 年度版 解 説 書 - DAL...流通ビジネスメッセージ標準...

Documents

Transcript of （流通BMS 2009 年度版 解 説 書 - DAL...流通ビジネスメッセージ標準...

（流通BMS 2009 年度版解説書 - DAL...流通ビジネスメッセージ標準...

Transcript of （流通BMS 2009 年度版解説書 - DAL...流通ビジネスメッセージ標準...