To main content

Message Level Response

The NPa Peppol Test Tool supports the PEPPOL BIS 3 Message Level Response profile.

This section describes how the test tool has implemented MLRs, and how you can check whether your access point implements them correctly.

MLR Specification

Sending MLRs to your access point

MLRs sent automatically

When a document, such as a test invoice, is received by the Test Tool, it will check whether the sender (as specified in the SBDH Envelope) supports message level responses. This is done by an SMP lookup for the process (ProfileID) urn:fdc:peppol.eu:poacc:bis:mlr:3 and document type (CustomizationID) urn:fdc:peppol.eu:poacc:trns:mlr:3.

If the lookup is succesful, an MLR will be generated and sent automatically.

The Test Tool will only attempt to send the MLR once. It will report a failure to send if the sending fails, but it will not retry to send the MLR. If you are testing your accesspoint’s ability to process incoming MLR documents, and it failed to process the MLR, you will need to send a new original document to try again.

The MLR that is sent will contain the schematron validation results for the document that was received. It will either report Rejected (schematron validation errors) or Accepted (no schematron validation errors, but there may be warnings)

Note: If the document failed validation, it is still accepted and stored by the Test Tool. An MLR rejected response means the document could have been rejected if this was an actual Access Point.

Viewing MLR send results

You can check whether the MLR was sent successfully to your access point in the MLR column of the Received Documents view.

Screenshot of Received Documents view

The icons indicate failure or success as follows:

Icon Result
MLR not sent icon No MLR was sent; either the sender of this document does not support MLR, or this document was received before MLR support was added to the Test Tool
MLR sent icon The MLR was sent successfully
MLR send error icon There was an error while sending the MLR

Note that this indication shows whether the MLR sending was successful, not whether the MLR itself reported a document error.

You can see the MLR that was generated by clicking on the icon.

Screenshot of MLR view

Note that the ‘Document validated’ message regards the MLR itself; as you can see in the screenshot, this message is not about the original document that was received, and which the MLR contains the response for.

Processing MLR Responses from your access point

When your access point sends an MLR document to the TestTool (i.e. the Peppol Identifier linked to your testtool account, of the form 0106:SITESTXXXXX), the test tool will find the transaction identifier as specified in the MLR.

If it cannot find a related transaction in your sent documents, it will reject the MLR on a transport level, and the MLR will not be stored or shown in the system.

When it does find the related transaction, the Sent Documents view shall show the MLR results in the MLR column.

Screenshot of Sent Documents view

This report contains two status icons: The first icon shows the Response as specified in the MLR, i.e. Accepted, Acknowledged, or Rejected. The second icon reports the correctness of the MLR message itself (valid MLR, invalid MLR, valid MLR but with warnings). This results in the following possibilities:

Icon(s) Result Result
MLR not received icon No MLR was received
MLR accepted iconMLR valid icon An MLR with the status ‘accepted’ (AP) was received The MLR itself is valid
MLR accepted iconMLR invalid icon An MLR with the status ‘accepted’ (AP) was received The MLR itself is not valid
MLR accepted iconMLR warnings icon An MLR with the status ‘accepted’ (AP) was received The MLR itself is valid, but there are validation warnings
MLR rejected iconMLR valid icon An MLR with the status ‘rejected’ (RE) was received The MLR itself is valid
MLR rejected iconMLR invalid icon An MLR with the status ‘rejected’ (RE) was received The MLR itself is not valid
MLR rejected iconMLR warnings icon An MLR with the status ‘rejected’ (RE) was received The MLR itself is valid, but there are validation warnings
MLR acknowledged iconMLR valid icon An MLR with the status ‘acknowledged’ (AB) was received The MLR itself is valid
MLR acknowledged iconMLR invalid icon An MLR with the status ‘acknowledged’ (AB) was received The MLR itself is not valid
MLR acknowledged iconMLR warnings icon An MLR with the status ‘acknowledged’ (AB) was received The MLR itself is valid, but there are validation warnings

You can see the MLR message itself, as well as the validation report of the MLR document, by clicking on these icons.

Screenshot of MLR report view

Implementation notes and specification gaps

Invalid MLR messages

The specification of MLR 3.0 does not discuss how to treat validation of MLR messages themselves; there are validation rules, and of course access points should always send valid documents, but in practice, documents that do not pass validation are regularly seen as well. This is one of the reasons MLRs exist in the first place.

The test tool will treat MLR validation as follows:

  • If the MLR document does not pass XML Schema validation, it is rejected on the transport level
  • If the MLR document does not pass Schematron validation, it is accepted if the test tool can derive the necessary information from it. Problems are reported in the document views.

When to send MLRs

The specification does not discuss how MLR documents are requested; i.e. how an access point knows whether to send an MLR in the first place. The Test Tool will create and send an MLR if the sender from the SBDH envelope has published support for MLRs in their SMP registration.

Namespace prefixes in LineReference xpaths

The specification uses a LineReference example with the namespaces cac: and cbc:. These are generally used prefixes, but an implementation should really use either the prefixes as defined in the original document, or use full namespace identifier without prefixes. The test tool uses namespace-uri() calls in selectors.

Unknown transaction identifiers

The specification does not mention how to handle the case where an MLR is received with a transaction ID that is not known to the access point. The test tool will reject such MLRs on the transport level.

NPa Peppol Test Tool documentation

Message Level Response

The NPa Peppol Test Tool supports the PEPPOL BIS 3 Message Level Response profile.

This section describes how the test tool has implemented MLRs, and how you can check whether your access point implements them correctly.

MLR Specification

Sending MLRs to your access point

MLRs sent automatically

When a document, such as a test invoice, is received by the Test Tool, it will check whether the sender (as specified in the SBDH Envelope) supports message level responses. This is done by an SMP lookup for the process (ProfileID) urn:fdc:peppol.eu:poacc:bis:mlr:3 and document type (CustomizationID) urn:fdc:peppol.eu:poacc:trns:mlr:3.

If the lookup is succesful, an MLR will be generated and sent automatically.

The Test Tool will only attempt to send the MLR once. It will report a failure to send if the sending fails, but it will not retry to send the MLR. If you are testing your accesspoint’s ability to process incoming MLR documents, and it failed to process the MLR, you will need to send a new original document to try again.

The MLR that is sent will contain the schematron validation results for the document that was received. It will either report Rejected (schematron validation errors) or Accepted (no schematron validation errors, but there may be warnings)

Note: If the document failed validation, it is still accepted and stored by the Test Tool. An MLR rejected response means the document could have been rejected if this was an actual Access Point.

Viewing MLR send results

You can check whether the MLR was sent successfully to your access point in the MLR column of the Received Documents view.

Screenshot of Received Documents view

The icons indicate failure or success as follows:

Icon Result
MLR not sent icon No MLR was sent; either the sender of this document does not support MLR, or this document was received before MLR support was added to the Test Tool
MLR sent icon The MLR was sent successfully
MLR send error icon There was an error while sending the MLR

Note that this indication shows whether the MLR sending was successful, not whether the MLR itself reported a document error.

You can see the MLR that was generated by clicking on the icon.

Screenshot of MLR view

Note that the ‘Document validated’ message regards the MLR itself; as you can see in the screenshot, this message is not about the original document that was received, and which the MLR contains the response for.

Processing MLR Responses from your access point

When your access point sends an MLR document to the TestTool (i.e. the Peppol Identifier linked to your testtool account, of the form 0106:SITESTXXXXX), the test tool will find the transaction identifier as specified in the MLR.

If it cannot find a related transaction in your sent documents, it will reject the MLR on a transport level, and the MLR will not be stored or shown in the system.

When it does find the related transaction, the Sent Documents view shall show the MLR results in the MLR column.

Screenshot of Sent Documents view

This report contains two status icons: The first icon shows the Response as specified in the MLR, i.e. Accepted, Acknowledged, or Rejected. The second icon reports the correctness of the MLR message itself (valid MLR, invalid MLR, valid MLR but with warnings). This results in the following possibilities:

Icon(s) Result Result
MLR not received icon No MLR was received
MLR accepted iconMLR valid icon An MLR with the status ‘accepted’ (AP) was received The MLR itself is valid
MLR accepted iconMLR invalid icon An MLR with the status ‘accepted’ (AP) was received The MLR itself is not valid
MLR accepted iconMLR warnings icon An MLR with the status ‘accepted’ (AP) was received The MLR itself is valid, but there are validation warnings
MLR rejected iconMLR valid icon An MLR with the status ‘rejected’ (RE) was received The MLR itself is valid
MLR rejected iconMLR invalid icon An MLR with the status ‘rejected’ (RE) was received The MLR itself is not valid
MLR rejected iconMLR warnings icon An MLR with the status ‘rejected’ (RE) was received The MLR itself is valid, but there are validation warnings
MLR acknowledged iconMLR valid icon An MLR with the status ‘acknowledged’ (AB) was received The MLR itself is valid
MLR acknowledged iconMLR invalid icon An MLR with the status ‘acknowledged’ (AB) was received The MLR itself is not valid
MLR acknowledged iconMLR warnings icon An MLR with the status ‘acknowledged’ (AB) was received The MLR itself is valid, but there are validation warnings

You can see the MLR message itself, as well as the validation report of the MLR document, by clicking on these icons.

Screenshot of MLR report view

Implementation notes and specification gaps

Invalid MLR messages

The specification of MLR 3.0 does not discuss how to treat validation of MLR messages themselves; there are validation rules, and of course access points should always send valid documents, but in practice, documents that do not pass validation are regularly seen as well. This is one of the reasons MLRs exist in the first place.

The test tool will treat MLR validation as follows:

  • If the MLR document does not pass XML Schema validation, it is rejected on the transport level
  • If the MLR document does not pass Schematron validation, it is accepted if the test tool can derive the necessary information from it. Problems are reported in the document views.

When to send MLRs

The specification does not discuss how MLR documents are requested; i.e. how an access point knows whether to send an MLR in the first place. The Test Tool will create and send an MLR if the sender from the SBDH envelope has published support for MLRs in their SMP registration.

Namespace prefixes in LineReference xpaths

The specification uses a LineReference example with the namespaces cac: and cbc:. These are generally used prefixes, but an implementation should really use either the prefixes as defined in the original document, or use full namespace identifier without prefixes. The test tool uses namespace-uri() calls in selectors.

Unknown transaction identifiers

The specification does not mention how to handle the case where an MLR is received with a transaction ID that is not known to the access point. The test tool will reject such MLRs on the transport level.