Views: 51
eB2B: OpenPeppolと他のEDIシステムの連携に関する解説
OpenPeppolとGENAのeB2Bプロジェクトが公開している Enhanced B2B Solution Architecture 1.1 では、OpenPeppolが国際的なeDeliveryフレームワークを提供するとともに、ZUGFeRDやFactur-Xなど他のEDIプロトコルと連携可能な柔軟性を備えています。本記事では、通信層、メッセージ層、アプリケーション層におけるアーキテクチャの概要を解説し、具体的な連携の例についても紹介します。
1. 通信層
通信層では、AS4プロトコルが主に使用され、以下の特徴があります：
-
AS4プロトコル：OpenPeppolの標準通信プロトコルで、信頼性の高いメッセージ送信とセキュアな通信を実現します。
-
PKIインフラストラクチャ：Peppolネットワークでは独自のサブCAを活用し、eB2B証明書を発行しています。これにより、通信相手の認証とデータの暗号化を行います。
1.1. 秘密鍵の発行
秘密鍵はPeppol Service Desk経由で以下の手順により発行されます：
-
PKI v3証明書の申請。
-
テスト環境用と本番環境用の2種類の証明書を発行。
-
証明書にはPeppolの命名規則が適用され、発行元と使用範囲が明確に特定されます。
例: CN=<Seat ID>, O=<AP事業者名>, C=<国コード>
2. メッセージ層
メッセージ層では、以下の標準が用いられます：
-
SBDH（Standard Business Document Header）：全てのメッセージに統一的なヘッダーを提供。
-
ZUGFeRD/Factur-X連携：ZUGFeRDやFactur-X形式のPDF文書は、SBDH内の`BinaryContent`エンベロープを使用して送信可能です。
<BinaryContent xmlns="http://peppol.eu/xsd/ticc/envelope/1.0" mimeType="application/pdf+xml">
<!-- ZUGFeRD/Factur-X PDF Payload -->
</BinaryContent>3. アプリケーション層
アプリケーション層では、注文情報、配送情報、インボイス情報などを効率的に処理します。特に以下の要素が重要です：
プロセスID：urn:peppol:eb2b:order（注文）、urn:peppol:eb2b:billing（請求）など、プロセスごとに特定の識別子を使用します。
メッセージタイプID：メッセージの種類を一意に識別します。例えば、`urn:peppol:doctype:pdf+xml##eb2b:factur-x:1.0::0`はFactur-Xの請求書に対応します。
4. 連携の具体例
4.1. ZUGFeRDプロバイダ（C2）とOpenPeppolプロバイダ（C3）の接続
シナリオ：ZUGFeRDプロバイダが生成した請求書を、OpenPeppol経由で配送。
手順：
1. C2がZUGFeRD形式で請求書を生成し、SBDHエンベロープにラップします。
2. AS4プロトコルを使用してC3に送信します。
3. C3はPeppolネットワーク上の受信者（C4）にメッセージを配送します。
4.2. メッセージ形式の変換に関する考慮事項
4.2.1. C3が変換を行う場合:
C2（ZUGFeRDプロバイダ）は請求書をZUGFeRD形式で送信し、C3（OpenPeppolプロバイダ）は受信したメッセージをPeppol形式（例: EN16931-UBL）に変換してC4に配送します。
必要な機能:
フォーマット変換機能：C3がZUGFeRD（PDF/XML）を解析し、Peppol形式に変換するスキーマ変換ツール。
ビジネスルールの適用：Peppol仕様に基づいたバリデーション（例: Schematronチェック）。
メリット:
C4は標準のPeppol形式をそのまま受信できるため、特別な変換機能を持たなくてもよい。
課題:
C3に変換機能が必要で、フォーマットの更新や異なるバージョンへの対応が複雑。
4.2.2. C3が変換を行わず、そのままC4に渡す場合:
C2（ZUGFeRDプロバイダ）が生成したZUGFeRD形式の請求書をC3がPeppolネットワーク経由でそのままC4に配送します。
必要な機能:
バイナリペイロード対応：C3はSBDH（Standard Business Document Header）の`BinaryContent`としてZUGFeRD形式をそのまま格納。
C4の互換性：C4側でZUGFeRD形式を扱える環境が必要。
メリット:
C3の実装が簡単で、フォーマット変換に伴う処理負荷がない。
課題:
C4がZUGFeRD形式を処理する必要がある。
4.2.3. 推奨される運用モデル:
Peppolネットワーク全体の一貫性を保つためには、C3が変換を行い、Peppol準拠の形式（例: EN16931-UBL）でC4に配送するモデルが望ましい。
ただし、C4がZUGFeRD形式をそのまま処理できる場合、C3で変換を省略する運用も現実的。
4.2.4. 送信メッセージ例（XML）
<StandardBusinessDocument xmlns="http://www.unece.org/cefact/namespaces/StandardBusinessDocumentHeader">
<StandardBusinessDocumentHeader>
<Sender>
<Identifier Authority="iso6523-actorid-upis">0088:4005458756324</Identifier>
</Sender>
<Receiver>
<Identifier Authority="iso6523-actorid-upis">0088:5702458856644</Identifier>
</Receiver>
<DocumentIdentification>
<Standard>urn:peppol:doctype:pdf+xml</Standard>
<TypeVersion>1.0</TypeVersion>
<Type>factur-x</Type>
</DocumentIdentification>
</StandardBusinessDocumentHeader>
<BinaryContent mimeType="application/pdf+xml">
<!-- Factur-X PDF Payload -->
</BinaryContent>
</StandardBusinessDocument>5. 結論
OpenPeppolは柔軟なアーキテクチャを通じて、他のEDIプロトコルとの相互運用性を提供します。特にZUGFeRDやFactur-Xの統合において、SBDHとAS4の使用は効率的なソリューションを可能にします。
コメントを残す