Returns metadata even if the DocumentType schema is different.

[sakasaka19]

In the "getWildCardServiceMetadataOrNull" method, Returns metadata even if the DocumentType schema is different.

A-NZ PINT Invoice v1.0 as an example,

(1) Registed only Endpoints of such DocumentType Scheme : peppol-doctype-wildcard Value : urn:oasis:names:specification:ubl:schema:xsd:Invoice-2::Invoice##urn:peppol:pint:billing-1@aunz-1*::2.1

(2) If you try to get metadata by specifying the following DocumentType using the "getWildCardServiceMetadataOrNull" method, you can get it. Scheme : busdox-docid-qns Value : urn:oasis:names:specification:ubl:schema:xsd:Invoice-2::Invoice##urn:peppol:pint:billing-1@aunz-1::2.1

[phax]

Well yes, that currently "works as designed".

1. The document type is resolved using the peppol-doctype-wildcard scheme. Multiple options are tried, depending on the number of "Parts" used in the Customization ID.
2. If no wildcard match was found, a fallback to the direct match (using busdox-docid-qns scheme) is selected, if present.

Is there a specific rule in JP PINT how the combination of peppol-doctype-wildcard and busdox-docid-qns should be used in combination? Is there a specific fallback foreseen?

[sakasaka19]

If no wildcard match was found, a fallback to the direct match (using busdox-docid-qns scheme) is selected, if present.

Even though only DocumentType of peppol-doctype-wildcard is registered Isn't it an incorrect move for the busdox-docid-qns scheme's Direct Match to succeed?

In this state, for the EndPoint of peppol-doctype-wildcard I will be able to send an SBDH (XML) with the busdox-docid-qns schema written in it, but that's no good, right?

I want direct match to return results that completely match both DocumentType's Shceme and Value.

Is there a specific rule in JP PINT how the combination of peppol-doctype-wildcard and busdox-docid-qns should be used in combination?

The rules regarding the use of JP PINT are as follows: It will be mandatory to receive peppol-doctype-wildcard from February next year, Since the use of busdox-docid-qns is not prohibited, it seems that there are many SPs that send the XML of busdox-docid-qns. So, for the EndPoint of peppol-doctype-wildcard that I wrote earlier, There is a possibility that the phenomenon of sending the busdox-docid-qns XML may occur.

[phax]

In the recent commits, I made some changes for the upcoming release 9.2.0. A new class PeppolWildcardSelector is introduced, that has different activity modes. You can instruct it to

• Search for busdox-docid-qns only
• Search for peppol-doctype-wildcard only
• Search first for busdox-docid-qns followed by peppol-doctype-wildcard
• Search frst for peppol-doctype-wildcard followed by busdox-docid-qns

And this API extension with the mode was also moved into SMPClientReadOnly.getWildcardServiceMetadataOrNull. The existing APIs use busdox-docid-qns followed by peppol-doctype-wildcard for backwards compatibility reasons.

So for Japan, you would use PeppolWildcardSelector.EMode.WILDCARD_ONLY