目次 はじめに Ⅰ. 流通 BMS の概要と導入のメリット Ⅱ. 導入までの流れ 1. 従来型 EDI の課題 2. 課題解決のための流通 BMS 3. 流通 BMS と通信プロトコル標準 4. セキュリティ 5. 従来型 EDI との違い 6. 流通 BMS に移行するメリット 1. 導入のモデル

Transcription

1 流通ビジネスメッセージ標準 ( 流通 BMS BMS) 2009 年度版 解説書 ~ 流通 BMS の導入に必要な知識と具体的導入作業の解説 の導入に必要な知識と具体的導入作業の解説 ~ Ver 3.01 営業本部 EDI/ SCM 企画推進 藤野裕司

2 目次 はじめに Ⅰ. 流通 BMS の概要と導入のメリット Ⅱ. 導入までの流れ 1. 従来型 EDI の課題 2. 課題解決のための流通 BMS 3. 流通 BMS と通信プロトコル標準 4. セキュリティ 5. 従来型 EDI との違い 6. 流通 BMS に移行するメリット 1. 導入のモデル 2. 導入にかかわる全体の流れ 3. 事前準備から本番移行まで Ⅲ. 導入事前準備 1. 流通ビジネスメッセージ標準 2. 通信プロトコル標準 3. 必要となる申請 手続と期間 Ⅳ. 流通 BMS の導入 1. 環境の構築 2. システム規模の選択 3. 目的に応じた具体的構成 4.ACMS アップグレードパス 1

3 はじめに 本資料には これから流通ビジネスメッセージ標準 ( 流通 BMS ) を導入するために 必要となる事前準備及び 導入に際しての検討ポイントが記載されています また資料後半には 流通 BMS の概要を整理した知識編を添付しているため 社内での勉強用資料として また実際の導入時の手引き書として ご活用ください なお 本書は下記の 流通システム開発センター Web サイト で公開されている公式情報に基づいて記述しております 必要に応じてご参照ください 財団法人流通システム開発センター [ 流通業界の標準化 システム化を推進している団体 経済産業省流通システム標準化事業» 流通システム開発センターのサイトからこのタイトルをクリックする» このページには流通次世代関連の重要な情報が掲載されている» このページ内でも特に重要なのが 流通 BMS のページであり ここに流通ビジネスメッセージ標準の資料が掲載されているため必読である 2

4 Ⅰ. 流通 BMS の概要と導入のメリット 1. 従来型 EDI の課題 2. 課題解決のための流通 BMS 3. 流通 BMS と通信プロトコル標準 4. セキュリティ 5. 従来型 EDI との違い 6. 流通 BMS に移行するメリット 3

5 1. 従来型 EDI の課題 従来型 EDI には課題が山積し このままでは運用に耐えられない状況となってきた 全銀 JCA 手順はもう限界! サポートする機器が販売停止 もしくは高コスト 画像情報が送れない JCA 手順は 漢字も送れない 安価で高速のインターネットが使えない 国際標準ではないため 海外との取引に利用できない ファイル転送のため トランザクション単位の処理ができない データが固定長のため仕様変更が困難 それらの解決策として WebEDI が登場したが 各社個別画面ができたことにより新多端末 ( 多画面 ) 現象が起こった 手動操作によるファイル転送を求められるようになった これにより EDI 本来の自動処理ができなくなり 多大な人的負荷が発生するようになった 企業間 企業内を取引のデータが縦横無尽に行き来している EDI の適用領域が 電子商取引 の範囲外へ拡大している 従来型 EDI WebEDI 社内ファイル転送 データ変換 ( 手組み ) は すべて別のシステムとして稼動しており 運用監視が複雑化している 新多端末現象 Internet JCA 手順は 取引先 A 日本語 WebEDI A 取引先 B WebEDI B 通信速度は 2400bps 漢字不可 画像情報不可 機器の販売停止 取引先 C WebEDI C 取引先 D WebEDI D 4

6 2. 課題解決のための流通 BMS 課題解決のため インターネット環境での効率的 効果的な EDI を目指す 可能な限り標準化を進め 全体最適を目指す 共通基盤は デファクトスタンダードから選べるようにする 結論 インターネット経由の国際標準の通信手順を使用した XML-EDI! コードは国際標準 (GTIN GLN) を採用 データ項目 メッセージは業界標準を策定 取引業務プロセス ( メッセージ種 ) EDI メッセージ 通信インフラ データ項目 コード (GTI ( N GLN) データ表現形式 (XM ( L) L 通信手順 (ebxm ( L M S AS2 JX 手順 ) 通信基盤 ( インターネット TCP/ IP) 共通基盤 ( デファクトスタンダードの中から選択 ) (ebxm L M S AS2 JX 手順は 別途説明 ) ( 図は流通システム開発センター資料より ) 5

7 2. 課題解決のための流通 BMS 流通 BMS 検討の基本方針 個別仕様の発生を抑える すべての企業間取引で共通の EDI メッセージを使えるように メッセージ種別 メッセージ構造 データ項目 と データ項目の意味 データの属性 を標準化する 現行業務の担保を図る ( 現行システムの担保ではない ) 各社の現行業務をできるだけ担保し 移行の負担を軽減する 将来の技術 業務に対応できる準備を盛り込む 商品マスターの同期化 (GDS) 未対応 共通企業識別コード (GLN) 共通商品識別コード (GTIN) インターネットを使用した通信を前提とする XML セキュリティ 伝票レスを促進する 取引証憑の要件を満たす EDIメッセージとすることで ペーパー仕入伝票を不要とする 6

8 2. 課題解決のための流通 BMS 次世代 EDI 標準検討の経緯 流通サプライチェーン全体最適化促進事業 経産省事業 [ 標準の策定 ] 流通システム標準化事業 2003 年度 2004 年度 2005 年度 2006 年度 2007 年度 2008 年度 基礎調査 研究標準化検討と実証実用化と普及拡大へ 民間運営 [ 標準の維持管理 ] 流通システム標準普及推進協議会 引き継ぎ 取引プロセスモデルの検討 設計開発 実証実験 基本形の標準化検討 2003 年 ~2008 年 : 経産省事業 流通業界全体の情報共有 交換のインフラ基盤としての新たな流通システム標準 業種 業態を超え ユーザー自らが作り ユーザー自らが使いユーザー自らが管理するユーザー主体の新標準を目指す 2009 年 ~ : 民間運営 流通システム標準普及推進協議会 ユーザー企業 団体が主体となった検討の場 業種 業態や製配販の枠を超えた意見調整と啓発の場 ユーザー企業と情報関連企業の情報交換の場 共同実証 物流系 情報系メッセージ検討 ( 預かり在庫型センター POS/ 在庫データ等 ) 共同実証 ( 生鮮 アハ レル ) 共同実証 ( チェーンドラッグホームセンター百貨店 ) 流通システム標準 開発維持管理 導入支援普及推進 外部からの要請に応じた標準化検討 ( 流通システム開発センター資料より ) 7

9 2. 課題解決のための流通 BMS 業界動向 スーパー業界では既に実運用及び普及段階に入り 百貨店業界やチェーンドラッグ ホームセンター業界でも共同実証を実施した 卸 メーカー酒類 加工食品日用品 化粧品生鮮食品アパレル医薬品住関連製品ホビー関連製品家電製品書籍等 流通 BMS 発注 / 生鮮発注出荷 / 生鮮出荷受領 / 生鮮受領返品 / 生鮮返品請求 / 支払値札集計表作成 在庫 POS 売上 通信インフラ 小売 総合スーパー 食品スーパー 百貨店 ドラッグストア CO-OP ホームセンター 家電量販点 各種専門店等 2006 年度共同実証実施 2007 年度共同実証実施 2008 年度共同実証実施 ( 図は流通システム開発センター資料より ) 8

10 3. 流通 BMS と通信プロトコル標準 (1) 流通ビジネスメッセージ標準 ( 流通 BMS) メッセージ基本形 V1.2 小売卸 メーカー 商品マスタ登録 値札作成依頼 商品マスタ ( 継続検討 ) 値札メッセージ 発注予定メッセージ 値札作成 商品マスタ登録 発 注 納品提案メッセージ 発注メッセージ集計表作成テ ータ集計表作成テ ータ ( 発注用発注用 ) 受 注 卸 メーカーから 検 品 出荷メッセージ 集計表作成テ ータ ( 出荷用 ) 集計表作成テ ータ ( 出荷梱包紐付有 ) 出荷梱包メッセージ ( 紐付有 無 ) 出 荷 小売へ 受領メッセージ集計表作成テ ータ ( 受領用 ) 受領訂正メッセージ 卸 メーカーへ 販売情報共有 返 品 POS 情報返品メッセージ 販売情報共有 返品受領 小売から 買掛 売掛 請求 請求メッセージ 請求 支払 支払メッセージ 消込 平成 20 年度の新規メッセージ ( 基本形 ) ( 流通システム開発センター資料より ) 9

11 3. 流通 BMS と通信プロトコル標準 (2) 通信プロトコル標準 a. 通信基盤 : インターネット TCP/IP b. 通信プロトコル : 国際標準の ebxml MS AS2 と日本独自標準の JX 手順 1 ebxml MS とは? ebxml MS とは CEFACT と OASIS が共同で開発した次世代 EDI の国際標準 ebxml の通信プロトコル部分 ebxml/ms のこと インターネット上で高速安全な EDI 環境を構築できる アジアを中心に実装が始まっている リアルタイムの EDI( メッセージング ) を実現 データ発生のつどプッシュ型で相手に送るサーバ方式 通常のファイル転送 ( 文字情報 ) のほか ファイル添付 (Word Excel PowerPoint PDF CAD 画像 音声 動画 等 ) も可能 2 EDIINT AS2 とは? IETF が制定したインターネット EDI の国際標準 米国を中心に実装が始まっている ebxml MS 同様 データ発生のつどプッシュ型で相手に送るサーバ方式 ウォルマートを中心に国際レベルでの流通調達で普及が始まっている 日本でも日用品雑貨メーカを中心に検討の機運が高まっている 3 JX 手順とは? 2007 年 4 月正式に命名され それ以前は SOAP-RPC と呼ばれていた 中小企業では データ発生のつどプッシュ型で相手に送るサーバ方式の常時運用は難しい その点 JX 手順は 必要の都度センターにアクセスし データを送受信するプル型 任意のタイミングでクライアントから起動し 取引先や VAN とデータの授受を行う ebxml MS では現行 EOS からの移行が難しいため 実態に合わせて作られた日本独自標準 10

12 インターネットサーバシステムEDIインターネットクライアントシステムビジネスムEDI3. 流通 BMS と通信プロトコル標準 (3) S-S 型 ( サーバ常時稼働 ) と C-S(PC 随時稼働 ) 型 S-S 型 EDI モデル アプリケーション形式 社内形式 ebxml MS AS2 データ変換ビジネス文書ビジネスト社内文書 文書アファイアウォール ビジネス文書 ビジネス文書 ( 量販 X) C-S 型 EDI モデル アプリケーション形式 社内形式 文書アJX 手順 データ変換ト社内 ビジネス文書 ビジネス文書 ファイアウォール相当機能 ( 量販 X) ビジネス文書 ビジネス文書 11

13 3. 流通 BMS と通信プロトコル標準 (4) 利用形態 ( イメージ ) VAN 事業者 小売 ebxml MS JX 手順 二次卸 JX 手順 ebxml MS 中小卸 AS2 ebxml MS JX 手順 JX 手順 AS2 倉庫 JX 手順 大メーカ 一次卸 二次卸 12

14 4. セキュリティ (1) セキュリティ対策が必要 インターネットが前提になるため 従来にはなかったセキュリティ対策が必要となる サーバ側セキュリティには システムに対するアクセスの管理 ファイアウォールやサーバのセキュリティ 監査用ログの管理 通信プロトコル上での暗号化や認証 文書の改竄防止 などがある クライアント側セキュリティは インターネット接続の PC と同等レベルのセキュリティ + 認証情報の設定が必要 (2) 証明書 署名の扱い サーバシステムには 証明書が必要 署名が必要な場合もある (AS2) クライアントシステムにも 証明書が必要な場合がある 認証局より証明書を取得し 目的に応じて証明書 署名として使用する 流通 BMS の場合は業界認定の認証局から取得することが前提となっている 自社用の証明書は認証局から取得し 取引先認証のための認証局証明書は取引先から受領する 取得したサーバ証明書は システムにセットして取引先と接続する 13

15 5. 従来型 EDI との違い (1) 従来の JCA 手順 WebEDI 方式との差異 標準 EDI では 業界の標準となる様々な指針を打ち出している それにより 従来相手先毎個別に取り決めが必要だった要件を 標準仕様をベースに共通認識のもとに設定できるよう考慮されている 標準 EDI JCA 手順方式 WebEDI 方式 業務に関する当事者間合意 プロセスやコード種 等の選定項目を提示 個別交渉 個別交渉 取引業務プロセス 標準メッセージの規定 運用ガイドライン 統一フォーマットは受発注のみ 小売の運用 小売の運用 コード ( 商品 企業識別 ) 商品 :GTIN(JAN) 企業識別 :GLN 小売コード 商品 :JAN 企業識別 : 小売コード 商品 :JAN 企業識別 : 小売コード データ項目 業務項目 メッセージヘッダー項目を標準化 個別項目 個別項目 データ表現形式 国際標準 XML( 可変長 ) 形式規定も XML JCA 形式 ( 固定長 ) 形式規定は小売の仕様書 形式規定は小売の仕様書 EDI 標準メッセージ通信標準EDI 通信に関する当事者間合意通信手順 ebxml CPA 等で通信合意事項を規定 国際標準 ebxml MS EDIINT-AS2 SOAP を使用 情報システム部同士で個別調整 JCA 通信手順 サーバ側より仕様提示 画面からの伝票入力 もしくは 手操作による HTTP ファイル転送 ( 標準仕様 JCA 手順方式とは異なる ) 通信基盤 インターネット ( 固定料金 数 Mbps) TCP/IP SSL 電話網 ( 回線毎に固定 + 従量料金 9600bps 等 ) インターネット ( 固定料金 数 Mbps) TCP/IP SSL 14

16 6. 流通 BMS に移行するメリット (1) 流通ビジネスメッセージ標準を採用することによるメリット 最初にシステムを標準対応することにより 以降取引先毎のシステム開発は最小限に抑えられる 最初の標準対応も 現行業務が前提となるため 過大な開発負担はないものと考える 同じシステムで現行のバッチ型ファイル送受信を行うことも 標準通信プロトコル本来の機能であるメッセージ単位のトランザクション処理もできる データ発生の都度送受信することにより データ精度を高めリードタイムを短縮することが可能 社内でのデータ活用が柔軟になる XML データを活用することにより アプリケーションの多様化に容易に対応できる 国際標準 (XML GLN GTIN) 採用により グローバル対応が容易 15

17 6. 流通 BMS に移行するメリット (2) 通信プロトコル標準を採用するメリット 物理的回線や専用ハードウェアの管理が不要になる 対応可能なハードウェアが豊富 同期モデム損傷による受発注業務停止のリスクがなくなる TCP/IP 経由のオープン系システムであるため 社内システムとの親和性が高い ハードやソフトの共用 集約ができ 技術や資産の有効活用が可能 回線の高速化 利用料低廉化により リードタイム短縮 締め時間延長 利用コスト削減が可能 漢字や画像 EXCEL PDF など多様なデータを扱えるので さまざまなアプリケーションを通じ データの有効活用が可能 ファイル転送型 WebEDI の手動操作がなくなる 人件費や人的ミスを削減でき 業務の自動連携を促進できる 国際標準 (ebxml MS AS2) 採用により グローバル対応が容易 16

18 6. 流通 BMS に移行するメリット (3) 通信インフラが個別回線からインターネットに 1JCA 手順固有のリスクから解放される 複数回線の管理 固有のハードウェア ( 同期モデム等 ) 2 インターネット利用による処理の高速化 コストの低廉化が実現できる EDI データ EDI サーバ ACM S E 2 X EDI データ EDI サーバ ACM S E 2 X DMZ UST ダイアルアップルータ ルータ ファイアウォール ACM S E 2 X 通信サーバ 公衆回線網全銀,JCA 2400bps INS64 全銀 TCP/ IP 9600bps~ 19.2k bps 従量課金 定額料金 インターネット 50M bps~ 100M bps ( ベストエフォート ) 17

19 アプリケーションインターネットアプリケーション6. 流通 BMS に移行するメリット (4) 相手先毎の個別対応がなくなり 取引先やデータ種別の追加が容易に ム社内形式 形式アデータ変換プログラム A データ変換プログラム B データ変換プログラム C A 社フォーマット B 社フォーマット フォーマット C 社 新たなアプリケーションでの利用可!! サーバシステムEDI社内 項目 コート レイアウト変換 ACMSANY 変換 XML ビジネス文書 ム中間 市販製品ト一般的には XML 変換形式 サーバシステムEDI取引先ごとに データを自社のフォーマットに変換するプログラムを作成する必要があった 標準フォーマットを 取引先ごとに区別することなく自社フォーマットに変換できる 一部固有の部分がある場合も 従来と違い限られた範囲での対応に抑えることができる 手組み開発 この変換は市販のツールを利用できる ただし ツールによっては 項目 コード レイアウト変換などを別に行う必要があるものもある XM L ビジネス文書は このまま新たなアプリケーションでの利用が可能 UN/ EDIFACT や CII X.12 などは 標準フォーマットをそのまま利用することができなかった 18

20 6. 流通 BMS に移行するメリット (5) 伝票レスでコスト削減 伝票レスとは 小売と卸 メーカの双方が 受領データ を保存することにより 従来印刷していた複写式の TA(Turn Around) 伝票の印刷が不要になること これにより 伝票用紙代 プリント費用 伝票保管費用を削減できる 複写式伝票を印刷するインパクトプリンタも 機種が少なく印刷速度が遅い メンテコストがかかるなど多くの問題を抱えていた 印刷後の伝票も 後日参照 検索する場合 膨大な紙の山から探し出すのは業務の効率を大幅に低下させていた 従来も実施例はあるものの 小売毎に仕様が異なり卸側は相手先毎に別システムを持つ必要があった 今回の流通 BMSでは その仕様が標準化され システムの統一を図ることが可能となった ただし これを実現するには双方に高度な在庫精度と検品体制が必要となる 19

21 6. 流通 BMS に移行するメリット (6) 検品レスで業務の改革と効率化 検品レスとは 卸 メーカ側から納品伝票に代わる 出荷 ( 梱包紐付けあり ) データ ( 事前出荷明細 ) を事前に小売側に送っておき 出荷時に梱包に貼付した SCM ラベルのバーコードを受け入れ側 ( 主に小売物流センター等 ) がス キャンし あらかじめ受信した事前出荷明細と照合することにより検品を行うこ と 店舗での検品は省略できる この検品レスも 前記伝票レスと同様 小売毎に異なる仕様であったものが標 準化されたため 大きな省力効果が期待できる 一方 卸 メーカ側は従来にも増して高度な物流体制が求められることとなる これを機会に業務改革を目指し更なる高効率化を進めたい 事前出荷明細 出荷明細 出荷 ( 梱包紐付けあり ) データ 照合 卸 メーカ側 出荷検品 入荷検品 小売側 20

22 Ⅱ. 導入までの流れ 1. 導入のモデル (1) サーバタイプかクライアントタイプか (2) サーバタイプの特徴 (3) クライアントタイプの特徴 (4) 自社構築か ASP 利用か 2. 導入にかかわる全体の流れ 3. 最初の取引先との本番移行まで (1) 事前準備 (2) 環境構築 (3) アプリケーション開発と EDI 関連情報設定 (4) テスト計画 移行方針の策定 (5) 取引先との接続テスト (6) 本番移行 21

23 1. 導入のモデル (1) サーバタイプかクライアントタイプか 小売もしくは大手の卸 メーカは 基本的にサーバモデル 小規模の卸 メーカは クライアントモデル 中間規模の企業は データ量やプロトコルの特性に応じて判断 AS2 サーバ クライアント S-S 型 EDI モデル 小売 ASP 事業者 JX 手順 C-S 型 EDI モデル 小規模卸 大メーカ サーバ AS2 ebxml MS クライアント JX 手順 二次卸 一次卸 サーバ 22

24 インターネットサーバシステムEDIインターネットクライアントシステムビジネスムEDI1. 導入のモデル S-S 型 ( サーバ常時稼働 ) と C-S 型 ( クライアント随時稼働 ) S-S 型 EDI モデル アプリケーション形式 社内形式 ebxml MS AS2 データ変換ビジネス文書ビジネスト社内文書 文書アファイアウォール ビジネス文書 ビジネス文書 ( 量販 X) C-S 型 EDIモデル JX 手順 アプリケーション形式 社内形式 データ変換ト社内 文書アビジネス文書 ビジネス文書 ファイアウォール相当機能 ( 量販 X) ビジネス文書 ビジネス文書 [ 注意 ] この図は クライアント側での運用 JX 手順サーバプロトコルと矢印の向きが反対 23

25 1. 導入のモデル S-S 型 EDI モデル 取引先とサーバ同士で接続するモデル 通信プロトコルは ebxml MS もしくは AS2 どちらを選ぶかは取引先との調整により決定する どちらのプロトコルも データが発生したタイミングで相手に送りつける Push 型通信 C-S 型 EDI モデル ハブとなる企業がサーバシステムを設置し そこに向けて小規模の企業がクライアントシステムで接続するモデル 通信プロトコルは JX 手順 送受信の要求はクライアント側から発し サーバ側はその要求に応じて送受信を行う Pull 型通信 現行の EOS と同様の運用を実現 サーバ側は 企業が直接行う場合と VAN や ASP が行う場合がある 24

26 1. 導入のモデル システム規模決定の目安 共同実証の結果 JX 手順による取引は 取引先との 1 取引データ量が 10MB を超えない ことが推奨されている XML 化する場合のデータは 概ねキャラクタの 12 倍となる データ量が大きくなった場合は圧縮をする ebxml MS および JX 手順では zip を使う この場合 圧縮後のファイルサイズは XML で 1/50 くらいになると言われている AS2 では プロトコルが持つ圧縮で行う 通信上で行うため 具体的な圧縮率は不明 その他 近い将来 接続する取引先が大きく増えたり データ量の急激な増加が見込ま れる場合も サーバシステム + サーバ通信プロトコル の採用が推奨される 通信速度は インターネットの 100Mbps を利用した場合でも 実行速度は社内の LAN 環境に依存するため 現実には 1~3Mbps 程度と考える 同時接続数は ピーク時 ( 決算時期等 ) の運用で最大のデータ量 ( 支払 請求 ) による通 信時間と そのタイミングで送受信を必要とする相手先の数から計算する 25

27 1. 導入のモデル XML 化した場合のデータ量の目安 前提前提 注文伝票 1 枚の平均明細数 ( 業界平均 ) は 3.2 行 JCA 注文データは 1レコード 128byte 1 伝票は ヘッダーレコード + 明細レコード JCA 支払データは 1 伝票 1レコード (128byte ( 128byte) XM L 変換により キャラクタデータは 12 倍のサイズになる JCA 注文データ 1 伝票を XM L 化した場合の想定データ量 128byte 4.2レコード 12 倍 6.5kbyte 注文データ 1レコード =128byte XM L 化した 1 伝票のデータサイズは約 6.5kbyte 注文データ 1 伝票 =4.2レコード (1ヘッダ 明細 ) テキスト XM L 変換指数 =12 倍 データ量が 10M Bを超える場合の想定パターン支払メッセージのデータ量が最も多い そのデータが 10M Bに達するためのケースを想定すると 下記のように 1 日平均 220 伝票分の注文データ発生すると考えられる 10M B 128byte 12 倍 6500 伝票 1 ヶ月の注文伝票が約 6500~7000 伝票 支払データ 1 レコード =128byte 支払データ 1 伝票 =1 レコード [ 参考 ] 注文データが 10M B になるケースは 下記にように 1 日 1600 伝票が発生する場合となる 10M B 128byte 4.2 レコード 12 倍 1600 伝票 26

28 1. 導入のモデル 無制限 表の基準は目安 採用する通信手順 想定されるデータの量 必要となるメッセージ等は 必ずお取引先にご相談してください ~時接続数による選択10MB 未満同 システム規模とデータ量 同時接続数の相関図 1 サーバ~2 ミドルサーバ 3 クライアント 高セキュリティ構成 負荷分散型構成 10~15MB 1 取引データ量による選択 15MB 以上 27

29 28 1. 導入のモデルビジネス文書ビジネスビジネス文書文書ビジネス文書ビジネスビジネス文書文書アプリケーションアプリケーションアプリケーションデータ変換データ変換データ変換ビジネス文書ビジネスビジネス文書文書インターネットインターネットインターネット社内形式社内形式ファイアウォールビジネス文書ビジネスビジネス文書文書ビジネス文書ビジネスビジネス文書文書ビジネス文書ビジネスビジネス文書文書EDIサーバシステムEDIEDIサーバシステムサーバシステムデータ変換データ変換データ変換ビジネス文書ビジネスビジネス文書文書ビジネス文書ビジネスビジネス文書文書アプリケーションアプリケーションアプリケーションインターネットインターネットインターネット社内形式社内形式ファイアウォール取引先取引先 ebxml MS ebxml MS AS2 AS2 JX JX 手順手順サーバプロトコルサーバプロトコルEDIサーバシステムEDIEDIサーバシステムサーバシステム取引先取引先 [ 注意 ] 後述の [ 注意 ] 後述の JX JX 手順クライアントプロトコルと矢印の向きが反対手順クライアントプロトコルと矢印の向きが反対 (2) サーバタイプの特徴

30 1. 導入のモデル サーバタイプの特徴 インターネット上でサーバを常時稼働させる 通信プロトコルが ebxml MS AS2 の場合 Push 型通信を行う つまり アプリケーション側で送信データが生成されたら その場で相手先に送る 受信は常に相手先からのデータを待ち 先方から送りつけられたら その場で受ける JX 手順サーバプロトコルの場合 常に相手からの要求を待ち 相手からの送りつけならそのまま受信に 相手への送信要求なら用意してあったデータを送る Push 型通信プロトコルは 従来型通信方式と違い 通信と業務は分離独立している そのため 送信側は相手の業務スケジュールと関係なしに データ発生の都度送信する 受信側は 送られてきたデータを蓄え続け 自社の業務スケジュールで溜まったデータを取り出し アプリケーションに渡す これにより 通信も業務も相手のスケジュールに合わせることなく平準化を図ることができる この方式を応用すると 要求を受けたらすぐに返答を返す準リアルタイムのトランザクション処理が可能となる 通信サーバは DMZ 上に データおよび管理サーバは社内に設置する 外部からの攻撃を受ける可能性があるため データおよび管理サーバを DMZ 上に設置してはならない 通信サーバと管理サーバを分離することができない場合 リバースプロキシを置き 外部からの攻撃を避ける工夫が必要 従来型通信プロトコルも並行運用する場合 新旧プロトコルは統合運用が望ましい 29

31 インターネットアプリケーション1. 導入のモデル (3) クライアントタイプの特徴 形式 社内形式 JX 手順クライアントプロトコル クライアントシステムビジネスムデータ変換ト社内 ビジネス文書 ビジネス文書 EDIファイアウォール相当機能 文書ア( 量販 X) ビジネス文書 ビジネス文書 [ 注意 ] 前述の JX 手順サーバプロトコルと矢印の向きが反対 30

32 1. 導入のモデル クライアントタイプの特徴 EDI 関連業務を行うときのみ システムを運用する随時稼動型 通信プロトコルは JX 手順 データの送受信が必要なときのみ起動し 送信もしくは受信を行う 業務アプリケーションとセットになったパッケージもある 運用形態は JCA 手順と同じであるため 通信システムを入れ替え 流通 BMS 関連の設定を行うだけで 既存の業務につなぐことができる場合もある ただし 業務との連携部分を十分に確認する必要がある PCでの運用を想定したモデルであるが サーバ OSで利用することも可能 31

33 1. 導入のモデル (4) 自社構築か ASP 利用か 小売ですか? YES NO 大規模システムですか? YES NO 1 通信での大量データはありますか? YES ASP を利用しますか? NO YES 自社専用 ASP にしますか? NO YES NO 通信プロトコルに ebms AS2 JX 手順サーバプロトコルを利用しますか? NO クライアント YES 自社構築 サーバ 汎用 ASP ASP 利用 自社専用 ASP 32

34 2. 導入にかかわる全体の流れ -5 ヶ月 -4 ヶ月 -3 ヶ月 -2ヶ月 -1ヶ月当月 +1ヶ月 プロジェクトの立ち上げ 標準 EDI 仕様の理解 取引先との方針確認 機器 ソフトの調達 ネットワーク環境手配 システム環境構築 システム開発内容の確認必要に応じてシステム開発 取り決め基本情報作成 マッピング取引先との接続情報設定 テスト計画 移行方針の策定 接続テストフェーズ 1 フェーズ 2 フェーズ 3 旧システムとの並行運用 平行運用の停止 凡例 : 事前準備 環境構築 アプリケーション開発と EDI 関連情報の設定 テスト計画 移行方針の策定 取引先との接続テスト 本番移行 33

35 3. 最初の取引先との本番移行まで (1) 事前準備 具体的作業を始める前に 正式なプロジェクトを立ち上げ 流通 BMS についての十分な理解 取引先との調整を行います 1 プロジェクトの立ち上げ システム形態の選定 プロジェクトを立ち上げるにあたり 導入するシステム形態を選定します 大手企業や大規模システムを持つ企業 と 中小企業や取引量の少ない企業 とは準備する EDI システムの形態は異なります 企業の実態に応じたシステムを選定してください S-S 型 EDI モデル» 取引先とサーバ同士で接続するモデル» 通信プロトコルは ebxml MS もしくは AS2 どちらを選ぶかは取引先との調整により決定する» どちらのプロトコルも データが発生したタイミングで相手に送りつける Push 型通信 C-S 型 EDI モデル» ハブとなる企業がサーバシステムを設置し そこに向けて小規模の企業がクライアントシステムで接続するモデル» 通信プロトコルは JX 手順» 送受信の要求はクライアント側から発し サーバ側はその要求に応じて送受信を行う Pull 型通信» 現行の EOS と同様の運用を実現 サーバ側は 企業が直接行う場合と VAN や ASP が行う場合がある 34

36 インターネットサーバシステムEDIインターネットクライアントシステムビジネスムEDI3. 最初の取引先との本番移行まで S-S 型 EDI モデル アプリケーション形式 社内形式 ebxml MS AS2 データ変換ビジネス文書ビジネスト社内文書 文書アファイアウォール ビジネス文書 ビジネス文書 ( 量販 X) C-S 型 EDI モデル アプリケーション形式 社内形式 文書アJX 手順 データ変換ト社内 ビジネス文書 ビジネス文書 ファイアウォール相当機能 ( 量販 X) ビジネス文書 ビジネス文書 35

37 3. 最初の取引先との本番移行まで 体制の立ち上げプロジェクトを立ち上げるため 流通 BMS 導入の目的を明確にし 必要な体制を決めます 導入目的の明確化» 自社の現状を整理し なぜ今流通 BMSの導入が必要なのかまとめます» ポイントは 取引先からの依頼 JCA 手順の限界回避 コスト削減 事業の効率化 業務の拡大 等会社の置かれている環境を的確に理解することです 体制の検討 組織化» プロジェクト実施に必要な人材を選出します» 体制は 取引先との接点となる人 取引先との業務アプリケーションを開発する人 EDIを運用する人 システム ネットワークインフラを管理する人 から構成されます» 経営に関わる方がメンバーに入ることも重要な要件です» 実際の構築段階では ここに EDIパッケージベンダーや SIerは加わります 36

38 3. 最初の取引先との本番移行まで 計画の立案プロジェクトが立ち上がると 具体的な計画の策定に入ります ここで全体の作業負荷を見極め 予算を決定します 全体計画の策定» 導入期間の目安は 6ヶ月» システムの規模やアプリケーション改変の有無によりその期間は前後します» 1. 導入に関わる全体の流れ を参考に大まかなスケジュールを組みます» 詳細なスケジュールは 標準 EDIの仕様の理解や業務の見直しを進める中で確定してください 稟議 ( 予算 人 物の確保 )» 大まかなスケジュールをもとに 概略予算を立てます» それをもとに ハードウェア ソフトウェア (EDI システム アプリケーション開発 ) ネットワークベンダーに対して RFPを提示し その費用を確定します» その他導入関連費用を洗い出し ベンダー見積を合わせて最終稟議を作成します» ポイントは 自社システムと標準システムとのギャップに関わる開発費 37

39 3. 最初の取引先との本番移行まで 2 標準 EDI 仕様の理解 従来方式との差異を理解 流通 BMSとはどのようなものか 新しい通信プロトコルにはどのような特徴があるかをまず理解する XMLベースのメッセージとはどのようなものかを理解する 標準の業務フロー メッセージ 項目の意味や扱いに現状との違いがないかを確認する セキュリティーや証明書 署名は 従来なかった概念なので十分な理解が必要 参考とする資料は 本冊子のほか 巻頭 はじめに 記載の 流通ビジネスメッセージ標準 ダウンロード資料をご参考にしていただきたい 38

40 3. 最初の取引先との本番移行まで 3 取引先との方針確認 方針等を相互確認 最初に取り組む相手先は 経営レベルで相互に流通 BMS の拡大を合意できるお取引先であること 共通確認シート (*1) をベースに どの業務をどういう方式でいつごろまでに実現するかを確認する お互い同じ言葉で確認しても レベルの相違や理解の仕方にズレがあり 誤解を生むこともある 十分な話し合いが必要 実現方法には いくつものパターンがあるため 具体的な内容まで事前に確認し合うこと スケジュール決定 双方の確認事項をもとに 環境構築 システム開発 テスト 本番移行等の順に具体的なスケジュールを決定する 基本は 6 ヶ月で可能であるが 各社の事情も加味し無理な計画は立てない 決算期や自社のイベント ( サーバ入れ替え ) など繁忙期は避ける ここでは大まかなスケジュールとし 詳細な検討を進める中でより綿密なスケジュールに落としていく (*1) 流通システム開発センターよりダウンロード : 巻頭はじめに参照 39

41 3. 最初の取引先との本番移行まで (2) 環境構築 1 ハード ソフトの調達 全体構成の設計 どのくらいの規模のシステムにするか シングル構成かクラスター構成か 通信サーバを分散型にするかリバースプロキシ経由単独型にするか 既存 EDI との住み分けをどうするか 既存のインターネット環境との住み分けをどうするか 既存の LAN 環境との住み分けをどうするか 基幹システムとの連携をどうするか ハード ソフトとも ハード ソフト構成の検討 ハードやネットワークはどのようになるか» サーバやインターネット対応機器など どのようなソフトが必要となるか» セキュリティ関連ソフトや EDI システムソフト 業務連携ソフトなど 新規ハードを調達するか既存ハードを転用するか システムの開発が必要かどうか 既存のネットワークやシステムにどの程度の影響を及ぼすか 40

42 3. 最初の取引先との本番移行まで ハード ソフトの選定 手配 候補製品を選び比較 評価 発注 評価結果は報告書としてまとめておく 工事 関連工事の手配 実施 マシンルームレイアウト 電源 空調 LAN 屋内配線工事など ハードの搬入 設置 ハードの搬入 設置 現調 動作確認 ソフトのインストール ソフトのインストール 基本設定 41

43 3. 最初の取引先との本番移行まで 2 ネットワーク環境手配 回線事業者 ( プロバイダ ) 回線手配 回線事業者やインターネットプロバイダを選ぶ 回線は障害に備えて 2 系統で確保 (NTT とパワードコム 等 ) グローバル IP ドメイン名の登録申請 流通 BMS では グローバル IP および企業ドメイン名が前提となる 既に所有している場合は問題ないが なければ新規に申請し取得する必要がある 42

44 3. 最初の取引先との本番移行まで 証明書 署名の取得申請 ( 流通 BMS 専用の証明書 ) インターネット経由であるため 証明書 署名の使用が必須となっている 使用するプロトコルやサーバかクライアントにより 必要な証明書 署名が異なる 流通 BMS では 流通業界専用の証明書 署名が必要 パブリック証明書は使用できない 業界指定の発行局に申請し取得する 2008 年 9 月時点では インテック並びにグローバルサインの 2 社 証明書にはサーバ証明とクライアント証明がある サーバ運用する場合にはサーバ証明が必須 サーバ証明書を申請すると サーバ証明書と クライアント証明書と 署名のフル機能取得できる JX 手順の PC でクライアント運用をする場合は クライアント証明書のみを取得する AS2 を使用する場合には 署名が必要 この場合も流通 BMS 専用証明書をそのまま利用することが可能 一般に有効期限は 3 年 期限切れになる前に再取得し 自社 EDI システムに登録する必要がある 企業コード (GLN) 取得申請 流通 BMSでは 企業コードとして GLNの使用が必須となっている すでに JAN 企業コードもしくは JANメーカコードを保有している場合は それの利用が可 未使用の場合は 新たに流通システム開発センターに申請し取得する必要がある 43

45 3. 最初の取引先との本番移行まで 3 システム環境構築インターネットを利用したセキュアな通信 アプリケーション稼働環境を構築する 基本ソフトとミドルウェアの環境設定 サーバ OS DB まわりの設定 ウイルス対策 DNS 設定 FW 設定 NAT 設定 ネットワーク機器の環境設定 ルータやネットワーク関連機器の設定 社内 LAN やプロバイダーとのインターネット接続確認 サーバ通信環境の構築 EDI 関連サーバと業務サーバ間のシステム連携確認 44

46 3. 最初の取引先との本番移行まで (3) アプリケーション開発と EDI 関連情報設定 1 システム開発内容の確認 既存業務との差異を確認 基本的には 既存の業務を大幅に変更することなく流通 BMS に移行できるように考えられている ただ 細かく見ると少しずつ異なるところもあるはず それがどの程度影響があるかを調べる必要がある 業務フロー メッセージで使われている項目 項目名称の呼び方 自社での使われ方など 業務の視点では» 伝票レスをするかしないか 納品のプロセスはどのようなパターンになるか など メッセージでは» 企業識別が GLN になり 登場人物も小売側では 支払い法人 発注者 直接納品先 最終納品先 計上部署 卸 / メーカー側では 最終送信先 請求取引先 取引先 出荷場所 等の細かい分類となる» 商品コードは GTIN になり 発注用コードと集合包装用コードは 分けて考える» 日付の考え方も 発注日 納品日 ( 直接納品先納品日 最終納品先納品日 ) 計上日と意味づけが明確になっている» その他 番号 ( 取引番号 取引明細番号 取引付属番号等 ) 金額 数量 区分 コード値 梱包情報 等の扱いも細かく定められた また 自社独自の方式の有無や標準と一致しない所がないかなどを調査 これらについては マッピングシート (*2) により 標準と対比しながら使用の有無や扱 (*2) 流通システム開発センターよりダウンロード : 巻頭はじめに参照いを決める 45

47 3. 最初の取引先との本番移行まで 2 必要に応じてシステム開発 システムの改修 追加開発箇所を特定 調査結果に基づき 既存システムに改修を加える必要があるところ 新たに開発しなければならないところ がどこかを特定する 伝票レスによる業務の追加 変更 項目追加やコード値 ( 荷姿コード ) 標準化による処理の変更など トランスレータを用いてフォーマット変換 データ加工 編集処理 流通 BMS では標準データフォーマットが XML となる そのため 既存データ XML XML 既存データ の変換のステップが新たに発生する この変換は フォーマット変換ツール ( トランスレータ ) を用いて行う XML 標準側スキーマは 流通システム開発センターより配布される これにより メッセージの基本チェック ( バリデーションチェック ) を行うことができる トランスレータには フォーマット変換 項目変換 コード変換 計算 関数処理ができるものもある どの程度までできるかは 製品のスペックによる 単純な変換や編集 計算などは 極力その機能を使い 手作りのプログラム開発は最小限に抑える 既存業務との連携を含めて必要となるシステムを開発 開発内容を明確にし 詳細のスケジュールを確定する 個別開発は 通常の開発ルールに従って設計 ~ 開発 ~ テストを行う 新しいシステムによる業務の組み立て 既存業務との連携 運用管理も含め 全体の流れを作り上げる テストは 流通 BMS 関連業務の通信を除いた部分での業務連携テストまで実施する 46

48 3. 最初の取引先との本番移行まで 3EDI サーバに取引先との接続情報設定レガシー EDI に比べ設定情報が格段に増えている 特に 異なる法人が相対でサーバ相互認証を行うのは経験の少ない分野 接続相手と十分に調整し 不整合のないように注意する 通信パラメータ設定 通信パラメータ協定シート (*3) を 小売側 卸 / メーカー側 双方で記入 記入したものをもとに双方で CPA を作成し EDI サーバに登録 ただ 現実には 小売側 が CPA を作成し 卸 / メーカー側 に配布するパターンが多く見受けられる 通信パラメータ協定シート にそって EDI サーバに以下の接続情報を設定する» EDI 基本情報協定» EDI 通信パラメータ協定 (ebxml MS AS2 JX 手順 ) 証明書関連設定 証明書発行局から取得した自社証明書を EDI サーバへ登録 ACMS の場合 通信サーバを分散構成にした場合であっても 証明書は管理サーバへ登録 運用情報 業務連携情報設定 スケジュール情報 業務連携情報 運用情報等を 各々必要とされる所定の EDI サーバや関連機器に設定する (*3) 流通システム開発センターよりダウンロード : 巻頭はじめに参照 47

49 3. 最初の取引先との本番移行まで (4) テスト計画 移行方針の策定 1テスト計画の策定 流通 BMSに関わる業務一連の流れに対してテスト計画を立てる 改修 追加 新規開発を含めた社内システムと 相手先まで含めた全体の流れを分けたテスト計画が必要 特に障害系については 社内のみならず関連企業との連携もふまえた計画を作成する 48

50 3. 最初の取引先との本番移行まで 2 移行方針の策定 移行にあたっては 接続先と移行対象 移行順 時期 整合性の確認方法 旧システムとの並行稼働期間等について綿密な調整を行う 本番開始判定基準 旧システムの停止基準を双方で確認する 本番移行が不可能だと判断した場合 旧システムに戻すための段取り等も計画 明文化する 移行において個別対応が必要な場合を想定し その対応マニュアルも作成する 本番移行後 未整備のドキュメントはキッチリとまとめ 拡大時に混乱のないようマニュアル化を進める 拡大に向けた取引先への説明会 説明資料等の準備も行う 49

51 3. 最初の取引先との本番移行まで (5) 取引先との接続テスト 1 フェーズ 1: 疎通テスト EDI 通信環境の相互接続 ネットワークの確認 EDI システム送受信確認 相互認証を含めた EDI システム間でのメッセージ送受信を確認 2 フェーズ 2:EDI システム間の流通ビジネスメッセージ標準確認 送信メッセージの生成と EDI 通信 受信メッセージの検定 標準メッセージ形式と送受信の相互接続 業務データを XML の標準フォーマットに変換して送信 受信した側はその XML データを業務データに逆変換し整合性の確認を行う 整合性の確認は XML レベルでのスキーマを使ったバリデーションチェックと業務レベルの項目チェックの両方で確認する 3 フェーズ 3: 業務システム間の整合性確認 業務システムを含めた標準プロセスに従った送受信の確認 本番業務に準ずるデータを用意し 業務の最初から最後まで通した一連の結果が正当であることを双方で確認する 実際に起こり得るあらゆるパターンの確認を行い 整合性が確認できた段階で本番移行可能とする 50

52 3. 最初の取引先との本番移行まで (6) 本番移行 1 旧システムとの並行運用による新システムの稼働開始 本番稼動状況ウォッチ 旧システムとの整合性チェック 新システムに本番データと同じデータを投入し並行稼働開始 稼働結果を確認し整合性をチェック 2 旧システムから新システムへ本番業務を切替 本番開始判定 本番業務を旧システムから新システムへ切替 本番開始判定基準に基づき 取引先と双方合意が取れた段階で本番業務を新システムに切替 3 旧システムの並行運用停止 旧システム停止判定 旧システムを停止し新システムでの完全本番化 一定の並行稼働後 旧システムの停止基準に基づき旧システムを停止 移行は新システムだけで稼働 3 移行後のドキュメント整備 正常稼働を開始した段階で 継続運用が可能なように各種ドキュメント マニュアル類を整備する 51

53 Ⅲ. 導入事前準備 1. 流通ビジネスメッセージ標準 2. 通信プロトコル標準 3. 必要となる申請 手続と期間 3-1 回線 プロバイダ グローバル IP 3-2 ドメイン名 3-3 証明書 3-4 GLN(Global Location Number ) 52

54 1. 流通ビジネスメッセージ標準 (1) 業務プロセス 受発注業務モデル : 業務の流れを標準化 小売企業と卸 メーカとの間で受発注 出荷 受領をやり取りするモデル 発注で付番される取引番号が 出荷 受領 請求 支払の各メッセージに引き継がれるため 取引番号をキーとして発注から支払までの取引を追うことができる 業務とメッセージ種 : 業務の種類とメッセージの内容を標準化 発注 [ 発注 生鮮発注 集計表作成 ] 出荷 [ 出荷伝票 出荷梱包 ( 紐付あり ) 出荷梱包 ( 紐付なし ) 生鮮出荷 ] 受領 [ 受領 生鮮受領 集計表作成 ] 返品 [ 返品 生鮮返品 ] 請求 支払 値札 在庫 [ 補充勧告 報告 ] 入庫 [ 予定 確定 ] 等 メッセージ種は EDI 通信手順に依存していない 伝票レス : 紙の伝票を廃止 EDI メッセージ を商品売買の証憑とみなすことにより 取引当事者間でやり取りされているペーパーの仕入伝票 ( 統一伝票 ) をなくし 運用費用 ( 伝票代 発行時間 保存コスト パンチコスト等 ) を削減する 現在は流通 BMS の使用に限り 請求伝票に関して保存しなくても良いと国税庁から確認が取れている ( 請求伝票以外は 企業個別に税務署の確認を受ける必要があるが 将来的には 帳票保存が不要になる予定 ) 53

55 1. 流通ビジネスメッセージ標準 メッセージ一覧 ( 流通システム開発センター資料より ) 54

56 1. 流通ビジネスメッセージ標準 (2) メッセージ項目 企業識別 : 登場人物とコード体系を標準化 登場人物の体系を標準化 課題 - 従来は 項目として 店 センター 計上部署 があり 指定が必要な場合に当事者が任意にセットするルールとしていたため 卸 メーカー ( 受注者 ) にとって 物流上 商流上の決済ポイントがあいまいになる恐れがあった 対策 - 流通ビジネスメッセージ標準では 最終納品先 直接納品先 計上部署 発注者 支払法人の 5 つを設けて 卸メーカー ( 受注者 ) は どこに納品するのか 最終的にどこに納品されるのか 所有権が移転するのはどこか 発注者は誰か 支払うのは誰か を表現できるようにした ( 次ページ参照 ) 登場人物 : 小売» 最終納品先 直接納品先 計上部署 発注者 支払法人 登場人物 : 卸 メーカー» 最終送信先 請求取引先 取引先 出荷場所 55

57 1. 流通ビジネスメッセージ標準 登場人物の関係 支払企業 請求取引先 最終納品先 / 計上部門 小売 A 社 卸 メーカ X 社 枝番 店舗 発注者 取引先 事業部 小売 (A 社グループ企業 ) 卸 メーカ (X 社グループ企業 ) 売場 フロア 倉庫 陳列場所 VAN 出荷先コード データ送信元直接送信先最終送信先 直接納品先 / 計上部門 物流センター VAN 事業者が介在する場合 ( 流通システム開発センター資料より ) 56

58 1. 流通ビジネスメッセージ標準 GLN(Global Location Number) - コード体系を標準化 国際流通標準機関 GS1 が 企業や事務所を識別するために定めた グローバルでユニークになる 13 桁のコード JAN 企業コード /GLN 企業コードは 流通システム開発センターが付番貸与 GLN ロケーションコードは 各企業が付番基準に沿って自らの責任で付番 ( 例 ) LLLLL CD GLN 企業コード (JAN ( 企業コード ) ロケーションコード各企業が付番 商品識別 : コード体系を標準化 GTIN(Global Trade Item Number) - コード体系を標準化 集合包装用商品コード (14 桁 ) と EAN コード (JAN コード :13 桁 8 桁 ) と UPC コード (12 桁 8 桁 ) を包括し 14 桁にそろえた国際標準の識別コード 現在の JAN バーコード シンボル およびその桁数 (13 桁 8 桁 ) を変更する必要はない 上記 3 種類のコードは いずれも 0 を前詰めし 14 桁にそろえて GTIN とする 57

59 1. 流通ビジネスメッセージ標準 メッセージ間の項目の引継ぎ発注 出荷 受領メッセージ間における項目の引継ぎ例 赤字の部分は 前のメッセージでセットされた値を後のメッセージに引き継ぐ 発注 出荷 受領 < 支払い法人 > 支払い法人コード < 発注者 > 発注者コード < 取引 > 取引番号 : 請求取引先コード取引先コード < 取引内容 > 発注日 : 2007 年 1 月 18 日計上日 : 2007 年 1 月 20 日 ( 予定日 ) < 取引合計 > 原価金額合計 : 5,000 円数量合計 : 5 < 取引明細 > 商品コード ( 発注用 ) 原価金額 : 1,000 円発注数量 ( バラ ) : 5 < 取引明細 > < 支払い法人 > 支払い法人コード < 発注者 > 発注者コード < 取引 > 取引番号 : 請求取引先コード取引先コード < 取引内容 > 発注日 : 2007 年 1 月 18 日計上日 : 2007 年 1 月 20 日 ( 予定日 ) < 取引合計 > 原価金額合計 : 4,000 円数量合計 : 4 ( 再計算 ) < 取引明細 > 商品コード ( 発注用 ) 原価金額 : 1,000 円発注数量 ( バラ ) : 5 出荷数量 ( バラ ) : 4 欠品数量 ( バラ ) : 1 < 取引明細 > < 支払い法人 > 支払い法人コード < 発注者 > 発注者コード < 取引 > 取引番号 : 請求取引先コード取引先コード < 取引内容 > 発注日 : 2007 年 1 月 18 日計上日 : 2007 年 1 月 23 日 ( 確定日 ) < 取引合計 > 原価金額合計 : 4,000 円数量合計 : 4 < 取引明細 > 商品コード ( 発注用 ) 原価金額 : 1,000 円発注数量 ( バラ ) : 5 出荷数量 ( バラ ) : 4 欠品数量 ( バラ ) : 1 受領数量 ( バラ ) : 4 < 取引明細 > 赤字は引継項目 青字は基本的には引継だが変更する場合もある項目 ( 再計算等 ) 灰色の字は引き継がない項目 ( 流通システム開発センター資料より ) 58

60 1. 流通ビジネスメッセージ標準 (3) メッセージ構造 メッセージフォーマットに XML を採用 XML の特徴 各データ項目単位にデータの意味を表すタグを持ち 複数のデータ項目をグループ化 ( 構造化 ) することができる 外部構造化も可能 データとレイアウト デザインを分離可能 [XML データ例 ] <lineid> <linenumber>01</linenumber> </lineid> <itemid> <gtin> </gtin> <orderitemcode codetype="005"> </orderitemcode> <name> こだいらカップ本格的コーンクリーム 10P</name> <name_sbcs> コタ イラカッフポンカクテキコーンクリーム </name_sbcs> </itemid> EDI を行う上でのメリット XML は多くのプラットフォーム上で取扱可能なため システム環境に依存することなくデータ転送 データ処理が可能 59

61 1. 流通ビジネスメッセージ標準 XML 化を進めることにより得られるメリット データの意味を表すラベル ( タグ ) とグループによる構造化によって データに意味 ( 内容 ) と構造 ( グループ化 ) を保持したままデータ交換が可能なため アプリケーションの共通化を図ることが可能 スキーマ (XML Schema など ) を使ってデータ構造を外部定義することが可能なため このスキーマを共有することで標準化を保つことが出来るとともに データのチェックやデータ変換定義の作成に活用することも可能 スタイルシート (XSLT) を使用することで 画面表示や印刷のレイアウト定義が容易に作成できる 60

62 1. 流通ビジネスメッセージ標準 メッセージの基本構造 1SBDH 2メッセージ情報 3 発注ヘッダー 4 取引ヘッダー 5 明細 1 SBDH (StandardBusiness DocumentHeader) 2 メッセージ情報 3 発注ヘッダー 4 取引ヘッダー メッセージの送受信に必要な情報を記述送信プロトコルの規定に従って参照される メッセージに含まれる取引件数や 最終送信先への送受信件数を集計するのに用いられる 送信されるメッセージの取引に関するデータを括る発注者と支払い法人が記述される 出荷梱包の場合のみ発注者と最終納品先ごとの梱包に関する情報を括る故 取引先や直接納品先などの項目が記述される 一取引先における取引明細情報を括る項目が記述される 伝票での伝票ヘッダーにあたる 5 明細 一取引先における取引明細が記述される ( 流通システム開発センター資料より ) 61

63 1. 流通ビジネスメッセージ標準 (4) 証明書 手順別推奨セキュリティ設定について 各手順毎に推奨されるセキュリティ設定は下記の通り ( 流通システム開発センター資料より ( 一部加筆 )) 62

64 1. 流通ビジネスメッセージ標準 SSL 証明書とメッセージ署名用証明書の違い SSL 証明書は通信経路上の暗号化を実施するために必要 メッセージ署名用証明書はビジネスメッセージへの電子署名のために必要 通常 SSL 証明書とメッセージ署名用証明書は別々に導入が必要であるが 流通 BMS 専用の証明書はこの双方に対応している 2008 年 9 月現在 流通 BMS 専用証明書発行局として認証されているのは 以下の 2 社 グローバルサイン ( 株 ) ( 株 ) インテック 63

65 1. 流通ビジネスメッセージ標準 流通業界専用証明書について 流通 BMS を実施する際には 必ず流通業界専用の証明書を使わなければならない 通常 SSLサーバ証明書はサーバごとに証明書を取得する必要があるが 弊社 ACMS 製品については 負荷分散のため複数の通信サーバを立てる場合であっても証明書は管理サーバで一元管理するため 1 通の証明書を取得するだけでよい ( 流通システム開発センター資料より ) 64

66 1. 流通ビジネスメッセージ標準 流通 BMS の認証方式について 事前にルート CA と中間 CA の証明書を事前交換しておくが お互いのサーバ証明書は交換しない これは 下記のようにルート CA と中間 CA が一致することによりサーバ証明書は正しいものとみなし認証する という方式を採用しているためである この方式を採用している理由は 小売企業の中には接続先が数千社に及ぶものが存在するため 数千社分の証明書交換と期限切れ証明書更新の負荷が運用に耐えられないと判断されたためである ルートルート CA CA ルート CA 中間 CA の証明書を事前にインポート 中間中間 CA CA 証明 ユーザユーザ EDI 接続 接続先接続先 証明 CA: 認証局 信頼 65

67 1. 流通ビジネスメッセージ標準 証明書の切替 証明書には有効期限 ( 流通業界専用証明書の場合 最長 3 年 ) が存在するため 証明書の切替が必要であり 切替実施については相対間での日程調整が必要になる それ以外にも鍵の漏洩等により切替が必要となるケースがある ( 流通システム開発センター資料より ) 66

68 1. 流通ビジネスメッセージ標準 (5) XML スキーマ XML スキーマは商材拡大やプロセス拡充などのため 今後もまだまだバージョンアップが実施される予定である ( 流通システム開発センター資料より ) 67

69 1. 流通ビジネスメッセージ標準 従って 今後発生するバージョンアップに対し柔軟に対応できなければならない 生鮮の商材拡大 百貨店業界への適用上記は 平成 20 年度に予定されているバージョンアップ また 複数バージョンが併存することになるため 複数バージョンを利用できるシステムでなければならない グロサリ商材 :V1.0 アパレル商材 :V1.1 生鮮商材 :fresh V1.0 上記は 平成 19 年度実証実験までの実績 弊社 ACMS 製品については AnyTran( トランスレータ ) 変換定義は接続相手先毎にその利用バージョンに合う変換定義を使用することが出来るため 複数バージョンへの対応は問題なく かつ 変換定義を入れ替えることでバージョンアップへの対応も迅速に実施可能である 68

70 1. 流通ビジネスメッセージ標準 XML スキーマ検証 XML スキーマ検証 ( 妥当性検証 ) 機能を持ち合わせていなければならない XML スキーマ検証についても 複数のスキーマバージョンが併存することになるため 複数バージョンが利用できなければならない 本番前のテスト通信では XML スキーマ検証によってデータフォーマットの正当性チェックを実施し 本番開始に向けての判断材料の一つとする なお 本番通信で XML スキーマ検証を実施しエラーが発生したとしても そのエラーを相手へ通知する手段がないことと 検証の実施により CPU メモリ等のコンピュータ資源を消費することより 本番で XML スキーマ検証を実施するかどうかについては 慎重に検討しなければならない ( 流通システム開発センター資料より ) 弊社 ACMS 製品については AnyTran( トランスレータ ) 変換定義にて XML スキーマ検証を実施するかどうか指定する また そのチェック時に使用する XML スキーマについては実行時に柔軟に変更することが可能なため 複数バージョンへの対応も容易である 69

71 1. 流通ビジネスメッセージ標準 (6) データ圧縮 データサイズが大きな場合にはデータ圧縮を行うよう 下記の指針が出ている ( 流通システム開発センター資料より ) 70

72 1. 流通ビジネスメッセージ標準 データサイズ 10MB 越えを目安として 圧縮の検討を行う JX 手順で検討を進めていた場合には サーバ型の ebxml 手順もしくは AS2 手順への通信手順変更も検討する必要がある データ圧縮は 通信相手先 メッセージ種ごとに圧縮する / 圧縮しないを取り決める 圧縮する と取り決めたデータ種については ある日のデータが 10MB を下回るデータサイズであったとしても 必ず圧縮しなければならない 弊社 ACMS 製品については ZIP 圧縮機能は提供しない 利用ユーザにおいて ZIP 圧縮ツールを入手頂き ACMS の EDI 連携の JOB ステップとして ZIP 圧縮ツールを呼び出すことにより 流通 BMS 標準で示された圧縮を実現する 71

73 1. 流通ビジネスメッセージ標準 (7) 禁則文字 禁則文字については下記のような指針が存在するため これに従わなければならない ( 流通システム開発センター資料より ) 72

74 1. 流通ビジネスメッセージ標準 (8) EDI 通信パラメータの調整 流通 BMS 協定シート を使用して EDI システムの設定に必要な業務と IT のパラメータ調整を行う 流通 BMS 協定シート は 共通確認シート EDI 基本情報協定シート EDI 通信パラメータ協定シート EDI 通信パラメータ情報シート で構成されている ( 流通システム開発センター資料より ) 73

75 1. 流通ビジネスメッセージ標準 流通 BMS 協定シート に EDI を実施する相対間でそれぞれの必要項目を記入の上パラメータ調整を実施することにより スピーディーな EDI 実施を可能としている また 同一資料を双方で保持することによりパラメータの不一致を排除することが出来る ( 流通システム開発センター資料より ) 74

76 1. 流通ビジネスメッセージ標準 EDI 通信パラメータ情報シート は 3 種類の通信手順毎に分かれており 通信手順毎に調整 設定が必要な通信パラメータが記載されている この EDI 通信パラメータ情報シート を元に お互いの EDI 通信ソフトウェアに対して通信パラメータを設定できるようになっている ( 流通システム開発センター資料より ) 75

77 1. 流通ビジネスメッセージ標準 調整作業で使用する 流通 BMS 協定シート は 小売企業が作成して卸 メーカ企業に提示し 卸 メーカ企業は自社情報を記入して返送するルールとなっている ebxml 手順の場合には 流通 BMS 協定シート を元に CPA( 通信設定の定義情報 ) を作成するのも小売企業の作業となる 小売小売 流通 BMS 協定シート の送付 ( 自社情報記入済 ) 流通 BM S 協定シート 仕入先仕入先 流通 BMS 協定シート へ必要事項記入 返送 流通 BM S 協定シート CPA の作成と送付 CPA CPA 受領 ACM S へ CPA 読み込み ACM S へ CPA 読み込み ACM S E 2 X ACM S E 2 X 76

78 2. 通信プロトコル標準 (1) 通信基盤 : インターネット経由での HTTP を前提とする (2) 通信プロトコル : 標準として 3 種類 (ebxml MS EDIINT AS2 JX 手順 ) を制定 3 プロトコル登場の背景 最初に ejapan で ebxml MS が次世代通信プロトコルとして定められた ただし 流通業界ではプッシュ型サーバとサーバタイプのこのプロトコルでは EOS に対応できないため 独自プロトコルとして SOAP-RPC をベースとしたプル型である JX 手順が定められた しかし 海外ではウォルマートを中心とした EDIINT AS2 の利用が盛んとなり 今後グローバルな取引を考えた場合 本プロトコルの採用も必須との意見が多く出された これらを総合し 通信プロトコルは ebxml MS EDIINT AS2 JX 手順の 3 プロトコルを標準と定めることとなった 3 プロトコル利用上の言葉と意味の統一を図るため EDI 通信パラメータ協定シート 並びに EDI 通信パラメータ情報シート を作成している 77

79 2. 通信プロトコル標準 (3) 各プロトコルの構造 ebxml MS 通信プロトコルヘッダ (HTTP) MIMEエンベロープ ( 付属文書付きSOAP) MIME パート SOAP エンベロープ SOAP ヘッダー ebxml MS 情報 SOAP ボディー付属文書一覧 EDIINT AS2 通信プロトコルヘッダ (HTTP) AS2 情報 SMIMEor MIMEメッセージ文書署名 JX 手順 通信プロトコルヘッダ (HTTP) SOAP エンベロープ SOAP ヘッダー SOAP-RPC 情報 SOAP ボディー文書 MIME パート ペイロード 付属文書文書 いずれのプロトコルについても 流通 BMS の規定では 1 通信で 1 文書のみの送受信と規定されている規定されている 78

80 3. 必要となる申請 手続きと期間 3-1. 回線 プロバイダ グローバル IP (1) サーバ プロバイダ選定および回線申請 ( 申し込み ~ 開通まで約 2 週間 ) 固定 IP アドレス ( グローバル IP) を使用できるプロバイダを選定 プロバイダのサービス品目にある回線を申請 注 :B フレッツは 常時接続性を保証したサービスでは無い為 バックアップ回線として ひかり one Yahoo! BB 光 等を同時に契約される事をお勧め (2) クライアント プロバイダ選定および回線申請 ( 申し込み ~ 開通まで約 2 週間 ) 接続回線を選定 例 ISDN ADSL CATV FTTH( 光ファイバー ) 等 選定した回線が使用可能なプロバイダを選定 選定した回線を申請 79

81 3. 必要となる申請 手続きと期間 3-2. ドメイン名 (1) サーバ ドメイン名決定および登録申請 ( 約 7 営業日 ) 取得したい属性型 JP ドメイン名 (XXX.co.jp) を日本レジストリサービスより指定された属性型 地域型 JP ドメイン名のレジストラサイトで検索し 使用されていない事を確認した上で そのドメイン名のレジストラへ申し込む DNS サーバ構築と DNS サーバ IP アドレスの登録 (2) クライアント 不要 DNS サーバ構築 (2~3 日 )» グローバル IP アドレスを割り振った DNS サーバ ( プライマリ セカンダリ ) の構築 DNS サーバ IP アドレスの登録 (1 営業日 )» DNS サーバ ( プライマリ セカンダリ ) のグローバル IP アドレスをレジストラへ登録申請 80

82 3. 必要となる申請 手続きと期間 3-3. 証明書 (1) サーバ 流通 BMS 対応電子証明書 ( サーバ ) の取得 ( 約 10 営業日 ) 例 インテックの場合 1 各種情報確認確認項目コモンネーム (FQDN) (CN) 部署名 (OU) 法人名 (O) 住所 (L) 都道府県名 (ST) 国 地域名 (C) 2 申請書類のダウンロード 3 申請書類の記入および送付 4 証明書発行キット (CD-R) の受け取り 5 認証局証明書のダウンロード 6 認証局証明書のインストール 7 指定 URL にアクセスし証明書の発行操作 8 証明書の格納 9 証明書のエクスポート 10 証明書のサーバへのインストール 発生費用登録料 ( 初期費用 ) 更新料 (3 年ごと ) グローバルサイン ( 株 ) からも提供されています 株式会社インテック EINS/ PKI + for EDI 資料より抜粋 81

83 3. 必要となる申請 手続きと期間 (2) クライアント 流通 BMS 対応電子証明書 ( クライアント ) の取得 ( 約 10 営業日 ) 例 インテックの場合 1 各種情報確認確認項目部署名 (OU) 法人名 (O) 住所 (L) 都道府県名 (ST) 国 地域名 (C) 2 (1) サーバの場合と同じ 10 発生費用登録料 ( 初期費用 ) 更新料 (3 年ごと ) グローバルサイン ( 株 ) からも提供されています 株式会社インテック EINS/ PKI + for EDI 資料より抜粋 82

84 3. 必要となる申請 手続きと期間 3-4.GLN (1) サーバ クライアント共通 企業コード (GLN) の取得 ( 約 1 週間 ) GLN 専用企業コード登録申請書 に必要事項を記入 登録申請料を納付 登録申請書の裏面に登録申請料納付後の受領証 ( コピー ) を貼付して 流通システム開発センター宛に郵送 (FAX 不可 ) 流通システム開発センターにて登録申請書を受付後 約 1 週間で GLN 管理担当者様に GLN 専用企業コード登録通知書 が郵送される 注 ) 自社の商品に JAN コードを表示する必要がある場合には GLN 企業コードと併用できる JAN 企業コード (JAN メーカーコード ) の申請が必要 JAN 企業コードを申請 ( 有料 ) する場合の問い合わせは 財団法人流通システム開発センターまで 83

85 Ⅳ. 流通 BMS の導入 1. 環境の構築 2. システム規模の選択 3. 目的に応じた具体的構成 4.ACMS アップグレードパス 84

86 1. 環境の構築 (1) サーバ ( 約 1 ヶ月 ) 社外接続用ネットワーク構成の決定 および ネットワーク機器の導入 構築 既存のウェッブアーキテクチャ構成とリバースプロキシ型構成には 各々右図の様なメリット デメリットがある 1 ACM S E 2 Xは 既存の Web アーキテクチャ使用時でも 分散管理機能により ACM S 独特の非常にセキュリティレベルが高い構成を可能 ( 詳細は 3. 目的に応じた具体的構成を参照 ) (2) クライアント ( 約 2 週間 ) 社外接続用ネットワーク構成の決定 および ネットワーク機器の導入 構築 85

87 2. システム規模の選択 1 取引データ量による選択 伝送の可能性がある 最も大きなデータを想定してください JCA 注文データ 1 伝票を XM L 化すると下記のデータ量と なります 128byte 4.2 レコード 12 倍 6.5kB 注文データ 1 レコード =128byte 注文データ 1 伝票 =4.2 レコード (1 ヘッダ 明細 ) テキスト XML 変換指数 =12 倍 その支払データが 10M B になるケースを想定すると 下記のように 1 日約 230 伝票分の注文データがあった場合となります 10M B 128byte 12 倍 30 日 伝票 1 ヶ月に換算すると約 7000 伝票 (230 伝票 30) なので 7000~10000 伝票 ( 注文明細行 ) を目安として考えてください 支払データ 1 レコード =128byte 支払データ 1 伝票 =1 レコード 1 ヶ月の受注日数 =30 日 [ ご参考 ] 注文データだけで 10M B になるケースは 下記のように 1 日約 1630 伝票が発生する場合となります 10M B 128byte 4.2 レコード 12 倍 1625 伝票 同時接続数による選択 ピークの運用時に必要とされる 同時接続数の最大数 共同実証の結果より JX 手順 ( クライアント ) による取引は 取引先との 1 取引データ量が 10M B を超えないことが 推奨されています 下記の条件も考慮に加えることをおすすめします 業務拡張により ビジネスメッセージの増加した場合 今後 取引先の増加した場合 何らかの理由で 2 日分の送受信が発生した場合 86

88 無制限 表の基準は目安です 採用する通信手順 想定されるデータの量 将来必要となるメッセージ等に関しましては 必ずお取引先にご相談ください ~時接続数による選択10MB 未満同2. システム規模の選択 1 サーバ~2 ミドルサーバ 3 クライアント 1 高セキュリティ構成 負荷分散型構成 (W W indow s 環境のみ ) 10~15MB 1 取引データ量による選択 15MB 以上 87

89 2. システム規模の選択 製品 推奨ネットワーク構成 ( 次ページ以降参照 ) セキュリティと可用性 サイジング 1 ACMS E 2 X ネットワーク構成 A 分散構成可 5000 明細, 同時 8 受信 1 分半程度で完了 1 1 ACMS B2B ネットワーク構成 B 分散は不可 4000 明細, 同時 4 受信 2 ACMS B2B LE ネットワーク構成 B 分散は不可 2 分程度で完了 1 クラスタは不可 3 ACMS Lite ネットワーク構成 C - 5MBの受信 30 秒程度で完了 1 1: マシンスペックは次ページ以降を参照 88

90 3. 目的に応じた具体的構成 3-1. ネットワーク構成 A 通信サーバと管理サーバを分散配置 ACMS の分散構成では DMZ 上の通信サーバには送受信データを実体化させる事なく 運用する事が可能 従って DMZ 上の通信サーバが攻撃を受けた場合でも 送受信データの漏洩 改竄 破壊を防止でき セキュアな運用環境を提供 Internet DMZ ACM S E 2 X 通信サーバ -1 ACM S E 2 X 通信サーバ -2 負荷分散装置 ファイアウォール 社内ネットワーク 送受信データ ACM S E 2 X 管理サーバ クラスタ構成 証明書 共有ディスク 管理 DB AP データ 89

91 3. 目的に応じた具体的構成 セキュリティ対策 通信機能を DMZ 上に置く分散配置を推奨 3-1. ネットワーク構成 A データが隔離された社内 LAN 上に存在するため最もセキュリティが高い 既存および 新規にかかわらず インターネット接続の出入口には ファイアウォールの設置と 社内 LAN との間には緩衝域としての DMZ( 非武装地帯 ) の設置が必要である 必要な HW SW は多種多様であるが セキュリティレベルの変更という考え方ではなく ネットワーク規模 ( トラフィック ) によって設置する HW の能力 ( キャパシティ ) を決定し 新規の設置や増設を行うという考え方が一般的 現在市販されているルータ等の HW( 旧型の機種は確認が必要 ) は 安価なものであってもすでに DMZ 構築に必要な機能を持っていることが多い サイバーアタック検知機能 ファイアウォール機能 SSL サーバ機能 VPN 機能 DHCP 機能 といったネットワーク構築に必要な機能が一筐体の HW に全て組み込まれたものが主流となっているので これを導入するのが一般的 ただし セキュリティ対策はあくまで該当企業のポリシーに従うものとする 90

92 3. 目的に応じた具体的構成 インターネット環境 既存の環境を流用 ただし ネットワーク規模 ( トラフィック ) によっては 増設あるいは 新規の回線設置が必要 新規の環境 3-1. ネットワーク構成 A 回線の信頼性を考慮した選択が必要 よりクリティカルな環境においては バックアップの目的で二本以上の回線を異なる回線プロバイダと契約し 回線の二重化を推奨 ( 回線プロバイダの責任において 回線トラブル時の切り替えなどを行うサービスもあるので契約時に確認 ) 回線品質をある程度保証する法人向けインターネット回線もあるが 高額となる 最終的にはコストとリスクに配慮し 各社の事情に見合うものを選択することになる 91

93 3. 目的に応じた具体的構成 サイジング 3-1. ネットワーク構成 A 下記は比較的低スペックなマシンで測定した ACMSE 2 X での ebxml( 流通 BMS) プロトコル通信の測定である No 明細件数 多重度 JCA データ XML データ 通信時間 処理時間 サイズ サイズ 平均 全体 平均 全体 1 5, MB 7.11MB 4.2s 8.8s 40.6s 46.5s 2 5, MB 7.11MB 7.0s 11.8s 86.3s 95.5s 3 5, MB 7.11MB 16.4s 26.5s 138.5s 157.9s 4 25, MB 35.5MB 16.1s 20.2s 172.6s 191.3s 5 100, MB 142MB s s 測定環境 ( サイジング基礎データとするため低スペックの環境にて測定 ) Solaris10 CPU : AMD family 15 model 65 step 2 clock 1809 MHz MEM : 2GB 測定条件 (XML から量販フォーマット (FLAT) へ変換したのち自社フォーマット (FLAT) へ変換 ) XML データ受信 MIME デコード XMLtoFLAT 変換 FLATtoFLAT 変換 92

94 3. 目的に応じた具体的構成 3-2. ネットワーク構成 B リバースプロキシを使った構成 DMZ 上にはリバースプロキシのみを配置することにより 外部からの通信を制限し社内ネットワーク内の ACMS サーバに接続 この構成の場合 http 通信が社内ネットワークまで入るため 非常に高度な なりすまし による進入を受けた場合 http 上に仕込まれた悪意あるプログラムが社内ネットワークに影響を及ぼす可能性を残す また アクセスがすべてリバースプロキシを経由するため 負荷が高い場合にはリバースプロキシサーバがボトルネックとなる可能性がある Internet DMZ 証明書 証明書 リバースプロキシ フォワードプロキシ LE の場合は クラスタ構成不可 クラスタ構成 ファイアウォール 送受信データ ACM S B2B 管理 DB or 送受信データ ACM S B2B LE 管理 DB 社内ネットワーク 通信 / 管理サーバ 通信 / 管理サーバ 93

95 3. 目的に応じた具体的構成 セキュリティ対策 3-2. ネットワーク構成 B リバースプロキシ設定を既存の環境に加えたり 新たに構築することを推奨 必要な HW SW の選定方法は大規模と同様 ただし 既存のプロキシサーバの設定変更のみで対応可能な場合もある 新規導入の場合 大規模同様 ネットワーク構築に必要な機能が一筐体の HW に全て組み込まれたものが主流となっているので これを導入するのが一般的だが プロキシサーバだけは別途用意する必要がある 安価に済ませるためには 専用の HW 導入を避け 導入サーバに 該当する機能を持った SW を導入する手段もある ソフトウェアはウィルス対策 ( サイバーアタック検知 ファイアウォール ) Web アプリケーションサーバ (SSL サーバ DHCP プロキシサーバなど ) を導入する インターネット環境 ネットワーク構成 A と同様 ただし セキュリティ対策はあくまで該当企業のポリシーに従うものとする 94

96 3. 目的に応じた具体的構成 サイジング 3-2. ネットワーク構成 B 下記は比較的低スペックなマシンで測定した ACMSB2B LE での ebxml( 流通 BMS) プロトコル通信の測定である No 明細件数 多重度 JCA データサイズ XML データサイズ 全体通信時間 全体処理時間 KB 53KB 2.3s 3.7s KB 513KB 2.4s 6.0s 3 4, KB 5MB 4.1s 34.2s KB 53KB 2.8s 7.1s KB 513KB 3.1s 18.6s 6 4, KB 5MB 7.1s 132.9s 測定環境 ( サイジング基礎データとするため低スペックの環境にて測定 ) CPU : Celeron 2.0GHz MEM : 1024MB 測定条件 (XML から量販フォーマット (FLAT) へ変換したのち自社フォーマット (FLAT) へ変換 ) XML データ受信 MIME デコード XMLtoFLAT 変換 FLATtoFLAT 変換 95

97 3. 目的に応じた具体的構成 3-3. ネットワーク構成 C クライアント環境 インターネットに接続可能な Windows クライアント PC を使用する ウィルス対策ソフトやファイアウォールの使用を推奨するが 使用するかどうかは各企業のセキュリティポリシーに任せる 可能であれば ルータが持つファイアウォール機能や ウィルス対策ソフトのファイアウォール機能を利用する もしくは WindowsOS 標準のファイアウォールでも十分使用に耐えると考える Internet 社内ネットワーク クライアント PC ファイアウォール相当機能 ACM S Lite 送受信データ 証明書 96

98 3. 目的に応じた具体的構成 セキュリティ対策 ウィルス対策ソフトの導入を推奨 3-3. ネットワーク構成 C 可能であれば ルータが持つファイアウォール機能や ウィルス対策ソフトのファイアウォール機能を設定することが望ましい また WindowsOS 標準のファイアウォールでも十分使用に耐えると考える インターネット環境 既存の環境を流用 ただし ネットワーク規模 ( トラフィック ) によっては 増設あるいは 新規の回線設置が必要 新規の環境 プロバイダ選定および回線申請 接続回線を選定 例 ISDN ADSL CATV FTTH( 光ファイバー ) 等 選定した回線が使用可能なプロバイダを選定 ただし セキュリティ対策はあくまで該当企業のポリシーに従うものとする 97

99 3. 目的に応じた具体的構成 サイジング 3-3. ネットワーク構成 C 下記は比較的低スペックなマシンで測定した ACMSLite での JX 手順プロトコル通信の測定である No 明細件数 多重度 JCA データサイズ XML データサイズ 通信時間 処理時間 KB 53KB 5.0s 6.2s KB 513KB 5.3s 7.9s 3 4, KB 5MB 8.9s 27.4s 測定環境 CPU : Celeron 2.0GHz MEM : 1024MB 測定条件 (XML から量販フォーマット (FLAT) へ変換したのち自社フォーマット (FLAT) へ変換 ) XML データ受信 XMLtoFLAT 変換 FLATtoFLAT 変換 98

100 3. 目的に応じた具体的構成 3-4. ネットワーク構成 ( 従来型共存 ) [ ご参考 ] 従来型手順との共存 インターネット系の次世代手順は DMZ 上の通信サーバで通信を実行するが 従来型手順は社内ネットワークに置く通信 / 管理 /AP サーバで通信する Internet DMZ ACM S E 2 X 通信サーバ 次世代手順 全銀 TCP/IP 手順 全銀手順 JCA 手順 通信回線網 ( 専用線 /ISDN)/ ファイアウォール ダイアルアップルータ UST 社内ネットワーク 送受信データ ACM S E 2 X 通信 / 管理 / AP サーバ 証明書 99

101 (接続数を増やせます4.ACMS アップグレードパス JX 全銀 TCP/ IP W ebagent 手順追加 AS2 手順追加 ( 必要な手順が後から追加できます ) 43同時接続数2全銀 TCP/ IP ebxm L M S 全銀 BACREX 手順 JCA 1)JX W ebagent 手順追加 ( 必要な手順が後から追加できます ) 詳細は 製品価格表にてご確認ください 100

102 (接続数を後から追加できます4.ACMS アップグレードパス 同時接続数追加( 分散処理サーバを通信サーバ 変換サーバ などの負荷に応じて後から追加できます ) ノード数追加 Over JX ebxm L M S )Over 50 AS2 全銀 JCA 全銀 TCP/ IP BACREX 手順 W ebagent 手順追加 ( 必要な手順が後から追加できます ) LE から B2B E2X へのアップグレードも可能 詳細は 製品価格表にてご確認ください 101

103 お問い合わせ先 株式会社株式会社データ アプリケーション 東京都中央区日本橋人形町 Tel Fax URL ブログ EDI 情報館 URL DAL および ACMS,AnyTran AnyTranは株式会社データ アプリケーションの日本および海外での登録商標です その他記載の社名および製品名は 各社の商標または登録商標です 102