2.1. メッセージ・レベル ステータス・メッセージ一般

電子メッセージの作成から、1つまたは複数のトランスポート・ネットワークを経由して指定された受信者に至るトランスポート・ラインを下り、メッセージ・コンテンツの最終的な処理に至るまで、メッセージ交換の開始から終了までのフローを通じて、メッセージが通過したアクションのステータスまたは結果について、関連する関係者にアップラインで応答を与えることが必要になる場合がある。

これらの応答にはさまざまな性質があるが、この文書の目的上、以下の主要なグループに分けることができる。

トランスポート確認応答

これらはトランスポートネットワーク内で交換されるメッセージであり、メッ セージをトランスポートラインに運ぶプロセスについて通知する。 これらの応答は、ある地点への配送が成功したか否かをライン上の誰かに通知し、配送が成功しなかった理由など、関連する問題の詳細を含むことがある。

これらの応答の重要な性質は、伝送されるペイロードのコンテンツの検証結果や処理結果には一切作用しないということである。これらの応答メッセージは一般に 「acks 」と呼ばれる。

メッセージ・レベル・ステータス

メッセージがトランスポート・ラインのあるポイントに到達したとき、そのコンテンツは、コーナー4に配送する前に、合意された仕様に従って検証されることがある。

これらの検証の結果は、関係者に報告され、検証が成功したかどうか、また詳細が通知される。例えば、受信した注文メッセージが、必須フィールドがないため拒否された、関連する構文仕様で指定された通りに記載金額が加算されないため拒否された、C3での処理またはC4への配信が単に失敗したため拒否された、などが考えられる。

既存の MLR の主な特徴は、適用される技術仕様に基づき、メッセージの内容のみを報告することである。

ビジネスレベルのレスポンス

受信され、処理が承認されたメッセージは、受信者のアクションを要求する場合がある。例えば、技術的には正しい注文を受信したが、在庫切れや契約切れなどのビジネス上の理由で、受信者が注文を拒否することを決定した場合などである。

これらのレスポンスの重要な性質は、受信したメッセージインスタンスに対して下されたビジネス上の決定を報告することである。

本仕様書では、メッセージレベルステータスのみを扱う。

MLSでは、`MLS_TYPE`を使用して通知の範囲を設定できます。

この柔軟な設定により、ビジネスニーズに応じた応答が可能になります。

`MLS_TO`を使用することで、通知先をPeppol IDで指定できます。この機能を利用することで、特定のアクセスポイントやサブIDに通知を送信することができ、より柔軟な通知管理が可能です。

MLSは、3つの応答コードを使い、メッセージの配信状態を詳細に伝達します。

これにより、メッセージの配信状態をより正確に把握でき、各段階での処理状況を明確にします。

受信したメッセージが最終受信者に配送されなかった(C4)

ステータスコード: RE

1.メッセージは C3 または C4 によってそれ以上処理されない。

2.MLSはメッセージが配送されなかった理由を含む：

a.列挙された適合性規則によるエラー(MLR Failure)

i.XMLスキーマ検証エラー

ii.標準準拠違反（例：UBL 2.1 で許可されない空要素）

iii.致命的エラー型のスキーマトロン検証エラー

iv.警告タイプのスキマトロン検証エラー。警告だけではビジネス文書が拒絶されてはならないが、致命的エラーに加えて報告されてもよい6。

v.ビジネス文書のバージョン違い（致命的エラーのバリデーションエラーと同様に扱われる）

b.その他、2(a)でカバーされていない、Peppol相互運用性フレームワークの成果物に対する不適合：

i.XMLファイルのサイズが仕様を超えている。

ii.XML要素が長すぎる。

iii.ウイルスまたはマルウェアが検出された

iv.MIMEタイプの不一致[例：PDFが指定されているが、画像が消耗品として提供されている］

v.不正なコンテンツ[破損したPDFや不完全なPDFなど］

c.配信の失敗： C3はメッセージを渡すことができず、C4に代わってビジネスレベルの応答を送ることができないか、許されない。

注：この応答は、C3 がビジネス上の義務を果たし、すべての契約や規制に準拠しているか否かを示唆するものではない。 MLS メッセージは、問題を検知し解決するための、障害通知としての役割のみを果たす。 MLS メッセージはビジネスレベルのレスポンスに代わるものではなく、MLS メッセージの送信によって関係者の責任が変更されることはない。

受信したメッセージは最終的な受信者(C4)に正常に配送された。C3はC4からメッセージが受け入れられたという確認を受け取った。

C4 と C3 の間の通信はこの仕様の範囲外であるため、この確認応答の形式もこの仕様の範囲外であるが、このステータスは C4 と C3 の間に何らかの確認応答がある場合にのみ送信されるべきである。

ステータスコード： AP

-メッセージはC3によってそれ以上処理されてはならない[MUST NOT]。

受信したメッセージは C4 に転送されたが、C3 はそれが到着したことを確認する手段を持たない。このステータスは、C3 と C4 間の通信が、C3 が送達の成功を確認できないような性質のものである場合に使用される。

ステータスコード: AB

-メッセージは C3 によってそれ以上処理されてはならない（MUST NOT）。

-ステータスが不明な理由は、オプションで提供される：
郵便による配送
電子メールによる配送
C4からC3へのポーリングのために、ローカルストレージに配送される。

3.1. 一般的なプロセス

[TODO] ケーパビリティ検索と SBDH シグナリングを含む完全なダイアグラムの追加

MLS メッセージは、C3 から C2 へ送信されるため、送信された元のビジネス文書に直接基づかないアドレッシングスキームを使用する。

デフォルトでは、MLS メッセージは障害が発生した場合にのみ送信され、ドキュメントを送信したサービスプロバイダの Peppol シート ID（ICDスキーム[TBD]）に送信される。

しかし、C2 は C3 に対し、肯定応答（AP および AB）も送信するよう指示することができ、また C3 に対し、自身のシート ID のサブ ID 宛に応答を送信するよう指示することができる。これらの指示は、SBDH 拡張の項で規定されるように、SBDH を通して伝達される。

これにより、全プロセスは以下のようになる：

1.C3 は C2 からメッセージを受信する。

2.C3 は C2 から受信したメッセージを処理し、メッセージの配送を試みる。

3.C3 は MLS メッセージを送信すべきかどうかを決定する：

4.ステップ 3 の結果、MLS メッセージを送信すべきではないと判断された場合、処理は停止する。

5.ステップ 3 の結果、MLS メッセージを送信すべきであると判断された場合、C3 は MLS メッセージの送信先アドレスを決定する：

6.C3 は、MLS 文書タイプについて、5 から識別子を SML/SMP ルックアップする。

7.C3 は、ステップ 6 のルックアップ結果で C2 にメッセージを送信する。

3.2. メッセージレベルステータスプロセス規則

メッセージ・レベル・ステータス・プロセスは、トランザクションがいつどのように発行され、送信側サービス・プロバイダーと受信側サービス・プロバイダーの間でどのように処理されるかを規定する。