Problem with NAPTR based lookup in SMK. Change it to Default CNAME based lookup as per Peppol SML specification

[robrechtD]

We receive an error while trying to use the lookup function in oxalis.
We do a lookup for our document but we get a wrong endpoint, which causes the lookup to fail.
On building the transmission request we get the following error:
Unable to fetch 'http://smp-test.belgium.behttp/iso6523-actorid-upis%3A%3A0208%3A0871221633/services/busdox-docid-qns%3A%3Aurn%3Aoasis%3Anames%3Aspecification%3Aubl%3Aschema%3Axsd%3AInvoice-2%3A%3AInvoice%23%23urn%3Acen.eu%3Aen16931%3A2017%23compliant%23urn%3Afdc%3Apeppol.eu%3A2017%3Apoacc%3Abilling%3A3.0%3A%3A2.1'

the error is caused by the smp endpoint: smp-test.belgium.behttp/ should be smp-test.belgium.be/
When I lookup the receiver manually however: http://b-bbb3f462fb81fe13ecd0520be87c3a43.iso6523-actorid-upis.acc.edelivery.tech.ec.europa.eu/iso6523-actorid-upis::0208:0407214017
I do find the correct url in the xml I get back.

I don't know where to continue looking, the lookup seems to find the receiver but then the url is different somehow from what I find on my manual lookup.

[phax]

That is because of a change of CEF, that they did on the NAPTR records in the DNS (currently on the test system only).
This change leads to the unexpected behavious in Oxalis, since Oxalis uses NAPTR record DNS lookups by default (which is btw. against the Peppol specifications).

But good news: Danish company mySupply found a workaround, to use the good old CNAME lookup (as compliant to the Peppol specification). Therefore ensure the following setting is used in oxalis.conf:

lookup.locator.class=no.difi.vefa.peppol.lookup.locator.BusdoxLocator

This should be used in test and - after careful checks - also in production systems.

hth

[jannewaren]

Interesting! I have forgotten why but we (at Visma AutoInvoice) have been using lookup.locator.class = no.difi.vefa.peppol.lookup.locator.BusdoxLocator in our oxalis.conf for at least two years, both in testing and production. Just want to report this, it works :)

I don't fully understand this issue or background for this though. Why is there another lookup locator and why is it the default one? What's the difference between these two lookup implementations and should there really be two or just one?

[robrechtD]

the solution above has indeed worked for us.
Thanks for the quick help!

[phax]

@jannewaren Here are some background information:
Peppol uses the Peppol specification.
OASIS (BDXR TC) refined them to be OASIS specifications.
One of the changes were, that the storage of SMP records in the DNS was changed from CNAME to NAPTR records.
The CEF SMK/SML implements both techniques, knowing that for Peppol entries both record types (CNAME and NAPTR) are created where for other domains only NAPTR is created.
So the usage of the DNS NAPTR records will (most likely) become mandatory for the Peppol network as well, but that is a future activity. In the meantime, we're bound to the CNAME resolution.

[open-gdsn]

Can someone please improve thet title of this 'issue' And would it not be better to have the

lookup.locator.class=no.difi.vefa.peppol.lookup.locator.BusdoxLocator

As a default in new releases (if it is not). And if it is already the default then this is a non-issue right?

[phax]

I fully agree with you @open-gdsn but I don't have the rights to do so - sorry

[aaron-kumar]

Changed title.
Upcoming release will change it to CNAME based lookup by default @open-gdsn