Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

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

Closed
robrechtD opened this issue Jan 22, 2021 · 7 comments
Closed

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

robrechtD opened this issue Jan 22, 2021 · 7 comments

Comments

@robrechtD
Copy link

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
Copy link

phax commented Jan 22, 2021

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
Copy link

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
Copy link
Author

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

@phax
Copy link

phax commented Jan 22, 2021

@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
Copy link

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
Copy link

phax commented Feb 5, 2021

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

@aaron-kumar aaron-kumar changed the title unable to fetch Problem with NAPTR based lookup in SMK. Change it to Default CNAME based lookup as per Peppol SML specification Feb 5, 2021
@aaron-kumar
Copy link
Member

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

@aaron-kumar aaron-kumar mentioned this issue Feb 9, 2021
Closed
@phax phax mentioned this issue Sep 27, 2021
Closed
@pierfrancesco72 pierfrancesco72 mentioned this issue May 4, 2022
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@phax @jannewaren @aaron-kumar @robrechtD @open-gdsn