8.1 概要
ebXML MS 2.0手順が提供する機能の概要を解説します。
ACMS Cloudの概要の他、ebXML MS 2.0手順のプロトコルの詳細について学びたい場合は、以下のリンクをご参照ください。
https://community.dal.co.jp/s/article/protocol-ebxml-ms20
8.1.1 ACMS CloudにおけるebXML MS 2.0手順の実装
ACMS CloudではebXML MS(Message Service) Version 2.0に則ったebXML MSを実装します。サポート機能、非サポート機能は以下のとおりです。
■サポート機能
- 同期応答 / 非同期応答
- 信頼性保証
- 重複破棄
- 配送順序保証(Message Order)
- SSLによる通信経路の暗号化(盗聴防止)
- SSLクライアント認証
- ベーシック認証
- XML電子署名(メッセージ送信否認防止)
配信順序保証（Message Order）は、送信側については、ロードのパラメーターによって、シーケンス番号を割り振ることができます。しかし、受信側については受信番号等による順序維持のための待ち合わせ処理は実装しません。そのため、受信後に起動するアプリケーションで対処する、又は、運用者が操作にて対処する必要があります。
■非サポート機能
- 送信メッセージ自身の暗号化機能
- メッセージ状態問い合わせ機能(Message Status Service)
- MSH状態問い合わせ機能(MSH Ping Service)
- マルチホップ機能(ルーティング機能：VAN業者的な機能)
- exceptionInfo要素によるエラー詳細通知機能
- ビジネスシグナルメッセージ
exceptionInfo要素によるエラー詳細通知機能は、ebXML BPSS 仕様の ExceptionMessage 要素に続く要素、または SOAP の fault 要素中の detail 要素の子要素としても使用しません。
8.1.2 S-S型メッセージ交換の実装
ebXML MS 2.0は、ebXML MS(Message Service) Version 2.0とebXML CPPA(Collaboration Protocol Profile / Agreement) Version 2.0に従います。
ebXML MS Version 2.0は、前バージョンであるVersion 1.0に対する後方互換性はありません。そのため、ebXML MS Version 1.0を用いる通信ソフトウェアとの相互運用を行うことはできません。
8.1.2.1 S-S型メッセージ交換方式
SOAP Version 1.1通信規約をベースにして、企業間電子取引で必要となる機能(高信頼配信やセキュリティ等) を拡張したebXML MS仕様に従って、SOAP with Attachmentを使用してペイロード(ビジネス文書)の送受信を行います。
8.1.2.2 ビジネスシーケンス
ebXML CPPAに準拠したビジネスメッセージを行います。各メッセージの交換は非同期に別のセッション上で行います。
8.1.2.3 ビジネスメッセージ
ビジネスドキュメントをコンテンツに持つメッセージです。ビジネスメッセージは、ebXMLヘッダーコンテナと複数のebXMLペイロードコンテナからなります。
①ebXMLヘッダー情報(ebXMLヘッダーコンテナ)
ebXML MS 2.0手順で送受信に必要な送信元 / 宛先情報、ビジネスメッセージをやり取りする為のルール等の情報を格納します。
②ビジネスドキュメント(ebXMLペイロードコンテナ)
業務データのビジネスドキュメントを格納します。
③添付ファイル(ebXMLペイロードコンテナ)
MIMEメディアタイプで表される文書形式の実データを格納します。
添付ファイルについては必ずしも存在するとは限りません。
8.2 仕様
ACMS Cloudにおける、ebXML MS 2.0手順の仕様を解説します。
8.2.1 ビジネスメッセージの作成および検証
ACMS Cloudにおける、送信メッセージの作成方法と受信メッセージの検証方法について説明します。
8.2.1.1 ebXMLヘッダーコンテナの作成（送信）
データベースに登録されている情報を元に、ebXML ヘッダー情報を作成します。
作成されるebXMLヘッダーコンテナのエンコーディング方式は「UTF-8」となります。
8.2.1.2 ebXMLヘッダーコンテナの検証（受信）
受信したMIME形式のビジネスメッセージから、ebXMLヘッダーコンテナを抜き出してXML Parserを用いて検証を行います。
検証対象のebXMLヘッダーコンテナは「UTF-8」で作成されている必要があります。
XML Parserでは以下の内容の検証を行います。
- ebXMLヘッダーコンテナをXML Parserで構造チェック
- ebXMLヘッダー情報の項目内容をチェック
(必須項目の存在確認や設定されている値とデータベースの設定値のマッチング)
上記検証によりエラーとなったビジネスメッセージは受信障害として扱います。
8.2.1.3 ビジネスドキュメント(ebXMLペイロードコンテナ)の仕様
ACMS Cloudでは、送受信対象データの内容を意識していないため、ビジネスドキュメントの作成及び検証の仕様を規定していません。
必要に応じて、別途作成及び検証を行う必要があります。
8.2.1.4 添付ファイル(ebXMLペイロードコンテナ)の仕様
ACMS Cloudでは、添付ファイルをMIMEメディアタイプで表される文書形式の実データとして扱うため、添付ファイルの作成及び検証の仕様を規定していません。
必要に応じて、別途作成及び検証を行う必要があります。
8.2.1.5 各コンポーネントのパッケージング
送信対象のビジネスドキュメントや添付ファイルにebXMLヘッダー情報を加えて、「multipart/related」形式のMIMEメッセージにパッケージングします。
パッケージングの最中に何らかの障害が発生した場合には、内部的にエラー処理を行いメッセージの送信処理を中断します。
また、パッケージングされた各MIMEヘッダーについては、以下のように作成されます。
■ebXMLヘッダー情報のMIMEヘッダー
項目名 | 値 |
|---|---|
Content-Type | text/xml |
Content-ID | (ユニークな値)@(hostname) |
Content-Transfer-Encoding | Binary |
■ビジネスドキュメントのMIMEヘッダー
項目名 | 値 |
|---|---|
Content-Type | application/xml(変更可能) |
Content-ID | (ユニークな値)@(hostname) |
Content-Transfer-Encoding | Binary |
■添付ファイルのMIMEヘッダー
項目名 | 値 |
|---|---|
Content-Type | 実データの文書形式を表すMIMEメディアタイプ (変更可能) |
Content-ID | (ユニークな値)@(hostname) |
Content-Transfer-Encoding | binary/base64 |
8.2.1.6 各コンポーネントのアンパッケージング
受信したビジネスメッセージを「multipart/related」形式のMIMEメッセージからアンパッケージングします。ACMS Cloudでは各ファイルをそれぞれ1つの通信タスクとして保存します。
アンパッケージングの最中に何らかの障害が発生した場合には、内部的にエラー処理を行いメッセージの受信に失敗したものとして処理します。
8.2.2 ebXMLビジネスメッセージの通信プロトコル
ACMS Cloudでは、ビジネスメッセージを送受信するためにHTTP/1.1の通信プロトコルを使用します。また、SSLプロトコル(バージョン3)との結合により、HTTPSによる暗号化通信及びサーバー認証、クライアント認証を行うことができます。
なお、SMTPによる通信については未サポートとなります。
8.2.2.1 HTTP に利用する情報
許容するHTTPリクエストについては「POST」のみとなります。それ以外の接続は受け付けません。
また、通信の設定や送信メッセージ内容にかかわらず設定されるHTTPヘッダー情報を以下に示します。
項目名 | 値 |
|---|---|
SOAPAction | ebXML |
Content-Type | multipart/related |
Content-Length | 送信メッセージのサイズ |
Connection | Close |
8.2.3 ビジネスメッセージのシーケンス
ビジネスメッセージを送信してからMSH Ackを受け取るまでの流れを、ACMS Cloudのタスク登録及び終了処理の起動タイミングを踏まえて説明します。
なお、本書ではMSH Ackの送信要求を行わない場合については言及しません。
8.2.3.1 同期応答
ビジネスメッセージの受信側は、MSH Ackを、HTTPレスポンスとして送信します。ビジネスメッセージの送信側は、MSH Ackを正常に受信することで、送信が正常に終了したものと認識します。
以降では、送受信の正常系と異常系のシーケンスについて、それぞれ説明をします。
■ACMS Cloudが送信側の場合(正常系)
相手先へビジネスメッセージを送信した後、MSH AckのHTTPレスポンスを受信した場合に、ビジネスメッセージの送信が完了したことになります。また、正常時終了処理のタスク登録が行われます。
■ACMS Cloudが送信側の場合(異常系)
ビジネスメッセージの送信を行った後、相手先よりHTTPレベルのエラーレスポンス(Internal Server error：500等)を受信することがあります。その場合は通信ユーザー情報に指定されたリトライ情報に従って相手先への再送を行います。リトライを行ってもMSH Ackを受信できない場合(リトライオーバー)には、送信タスクを障害とします。
なお、相手先よりエラーのMSH Ackを受信した場合にはリトライを行いません。
■ACMS Cloudが受信側の場合(正常系)
相手先より着信があり、ビジネスメッセージを正常に受信および検証が行えた場合に、正常時終了処理のタスク登録が行われ、相手先へMSH AckのHTTP レスポンスを送信します。
■ACMS Cloudが受信側の場合（異常系）
ビジネスメッセージの受信および検証をおこなった結果、不正なメッセージと判断した場合には、相手先へメッセージエラーを送付します。
相手先より着信があり、ビジネスメッセージを正常に受信および検証が行えた後、何らかのエラーが発生した場合には相手先へメッセージエラーを送付します。
その後、同一のMessageIDのビジネスメッセージを受信し、正常に検証まで完了した場合は相手先へMSH Ack を送信します。また、正常時終了処理のタスク登録が行われます。
8.2.3.2 非同期応答
ビジネスメッセージの受信側は、MSH Ackを、別セッションのHTTPリクエストとして送信します。ビジネスメッセージの送信側は、MSH Ackを正常に受信することで、送信が正常に終了したものと認識します。
基本的には同期応答と変わらないため、送信の正常系のシーケンスについてのみ説明をします。
■ACMS Cloudが送信側の場合(正常系)
ACMSでは、送信タスクを登録することによりビジネスメッセージの送信を行います。
相手先へビジネスメッセージを送信した後、MSH Ackを新規HTTPリクエストとして受信した場合に、ビジネスメッセージの送信が完了したことになります。また、正常時終了処理のタスク登録が行われます。
8.2.3.3 信頼性保証(Reliable Messaging)
ACMS Cloudでは、ebXML MS 2.0手順によるメッセージの送受信に対する信頼性保証として、「欠落防止」と「重複破棄」の機能を備えています。また、次の機能により、欠落防止と重複破棄を実現しています。
- 受信メッセージに対するMSH Ackの送信
- 送信メッセージに対するMSH Ack未受信検出時の再送
- 永続記憶への送受信メッセージの記録
■欠落防止
ネットワーク障害など様々な要因で発生するビジネスメッセージの損失を防止します。
リトライを行っても通信が正常に終了しない場合は、送信が行えない理由を双方で調査する必要があります。
■重複破棄
ビジネスメッセージの送信時は、論理ファイルで「重複メッセージ」に”削除する”と設定された場合に、ビジネスメッセージ内のebXML ヘッダーコンテナ内に<eb:DuplicateElimination/>要素を定義して送信します。
ビジネスメッセージの受信時は、受信したビジネスメッセージ内のebXMLヘッダーコンテナ内に
<eb:DuplicateElimination/>要素が存在する、かつ論理ファイルの「重複メッセージ」に”重複を削除する”と設定した場合に、受信済みのMessageIDが存在するかどうかをチェックする機能となります。
ビジネスメッセージを受信した際に受信済みのMessageIDであれば、受信したデータを破棄し、相手先へMSH Ackを送信します。
なお、ACMS Cloudの重複破棄機能では、CPAの設定内容にかかわらず全受信タスク内のMessageIDと重複チェックを行います。
8.2.4 XML署名によるセキュリティ機能
メッセージの送信時、ebXML MS 2.0論理ファイルで「MSH メッセージの署名方式」に“署名有り”または、“ 署名有り（ヘッダーとペイロードに署名する）”と設定した場合には XML 署名を行い送信します。
MSH Ack の送信時、ebXML MS 2.0論理ファイルで「MSH Ackの方式」に“MSH Ack有り(署名有り)”と設定した場合には XML 署名を行い送信します。
XML 署名を実施して、メッセージの送受信を行う際には、キーペアと公開鍵証明書が必要となります。
メッセージ並びに、MSH Ack の署名部に添付する証明書は、登録されているキーペア(公開鍵証明書と秘密鍵証明書のペア)の登録内容により異なります。
認証局とエンドポイントの公開鍵証明書を含むキーペアを登録した場合は、認証局からエンドポイントの連鎖した公開鍵証明書をメッセージに付与します。
エンドポイントのみの公開鍵証明書を含むキーペアを登録した場合は、連鎖していない公開鍵証明書をメッセージに付与します。
■メッセージ／Acknowledgmentと証明書
メッセージ署名 | Acknowledgment | 送信 | 受信 | ||
|---|---|---|---|---|---|
当方証明書 | 相手証明書 | 当方証明書 | 相手証明書 | ||
なし | なし | × | × | × | × |
なし | あり（署名なし） | × | × | × | × |
なし | あり（署名あり） | － | － | － | － |
あり | なし | ○ | × | × | △ |
あり | あり（署名なし） | ○ | × | × | △ |
あり | あり（署名あり） | ○ | △ | ○ | △ |
○：必要
×：不要
－：実施不可（Acknowledgment署名ありはメッセージ署名ありが前提
△：署名に相手証明書が含まれない場合に必要
ACMS CloudがXML署名を行う際に利用できる証明書の署名アルゴリズムは下記になります。
・ SHA1withRSA
・ SHA256withRSA
・ SHA384withRSA
・ SHA512withRSA
・ SHA1withDSA
・ SHA256withDSA
・ SHA1withECDSA
・ SHA256withECDSA
・ SHA384withECDSA
・ SHA512withECDSA
上記の署名アルゴリズムの証明書を用いてXML署名を行う際に、ebXML MS 2.0通信ユーザー内の「署名アルゴリズム」に”証明書の署名アルゴリズムを使用”と設定し、「ハッシュアルゴリズム」に”証明書のハッシュアルゴリズムを使用”と設定した場合、XML署名の署名アルゴリズムは証明書のものを利用します。