Unable to fetch http://smp.difi.no

[runholen]

Yesterday and today we seem to have error sending EHFs I get error messages ala these: no.difi.oxalis.api.lang.OxalisTransmissionException: Unable to fetch 'http://smp.difi.nohttp/iso6523-actorid-upis%3A%3A0192%3A971228997/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'

Is there a problem with smp.difi.no? Or has something changed?

[ic-officient]

We have the same problem: http://smp.difi.nohttp/iso6523-actorid-upis%3A%3A0192%3A883945212/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

Probably something at difi has changed. I have tried to add smp.difi.nohttp to the host file to get oxalis to send but the we get a 404 from openresty...

if you try https://anskaffelser.dev/service/lookup/0192/914791723 you get a page with a red box with "smp.difi.nohttp"

[canilsenlogiq]

We have the same issue.

Adding lookup.locator.class=no.difi.vefa.peppol.lookup.locator.BusdoxLocator helped the SMP lookup. But outbound still fails with the same Unable to fetch error.

[maerevoet-wim]

We also have the same issue with smp.belgium.be

OxalisTransmissionException: Unable to fetch 'http://smp.belgium.behttp/iso6523-actorid-upis%3A%3A9925%3Abe0426594914/services/busdox-docid-qns%3A%3Aurn%3Aoasis%3Anames%3Aspecification%3Aubl%3Aschema%3Axsd%3AInvoice-2%3A%3AInvoice%23%23urn%3Acen.eu%3Aen16931%3A2017%23conformant%23urn%3AUBL.BE%3A1.0.0.20180214%3A%3A2.1'

[arjantippe]

Same issue here. Outbound fails with Unable to fetch since this weekend.

[dladlk]

Yesterday evening, 26.09.2021, in around 18:00 CEE time, the change in NAPTR record format, planned after 15.09.2021, was applied, so for old Oxalis before 5.0.0 a switch to Busdox should be done. Results you get look like Busdox switch was not done:

Just ensure that you use Busdox Locator - alternative is to add custom BdxlLocator implementation with 3 lines added:

[canilsenlogiq]

We tried to change to BusdoxLocator first thing this morning. But that only helped for the SMP lookups. Any ideas why this does not work for the outbound module? network.oxalis.api.outbound.Transmitter.transmit(...) no.difi.oxalis.api.outbound.Transmitter.transmit(...) does not seem to be affected by the lookup.locator.class=no.difi.vefa.peppol.lookup.locator.BusdoxLocator property in oxalis.conf.

[dladlk]

Package "network.oxalis.api.outbound.api" is a package from Oxalis 5. Package "no.difi.vefa" - from Oxalis 4...

[canilsenlogiq]

That was a miss-copy on my side. I copied the package name when I was inside our 5.X.X upgrade branch. no.difi.oxalis.api.outbound.Transmitter.transmit(...) does not seem to be affected by the lookup.locator.class=no.difi.vefa.peppol.lookup.locator.BusdoxLocator property in oxalis.conf.

[wilhelm71]

We also have the same problem:

unable to fetch 'http://smp.peppol.mehttp/iso6523-actorid-upis%3A%3A0088%3A7381036600956/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' with data: Failed to process message

I am a bit new to this, but I don't see any oxalis.conf in our entire project.

Also, it seems to fail in:

import no.difi.oxalis.api.outbound.TransmissionRequest; import no.difi.oxalis.outbound.transmission.TransmissionRequestBuilder;

.. TransmissionRequestBuilder requestBuilder = oxalis.getTransmissionRequestBuilder(); .. TransmissionRequest request = requestBuilder.build(); <---- ..

[dladlk]

I have reproduced the issue with Oxalis 4 with and without switch to Busdox from Bdsl. If I do not switch, new SML result NAPTR record returns root SMP name doubled, e.g. http://smp.difi.nohttp://smp.difi.no/ Method resolveServiceMetadata in this case tried to apply code

    @Override
    public URI resolveServiceMetadata(URI location, ParticipantIdentifier participantIdentifier,
                                      DocumentTypeIdentifier documentTypeIdentifier) {
        return location.resolve(String.format("/%s/services/%s",
                        participantIdentifier.urlencoded(),
                        documentTypeIdentifier.urlencoded())
        );
    }

to this doubled URl and returns "http://smp.difi.nohttp/iso6523-actorid-upis ...

So I am absolutely sure, that if it does not work for you - it is only because switch from Bdxl to Busdox did not happen.

If you say that there are SMP part and Outbound part - could it be that your Outbound part was not affected by your change of oxalis.conf or is managed by another oxalis.conf or overwritten in some other reference.conf of Guice?

[canilsenlogiq]

@wilhelm71 the oxalis.conf is located inside the .oxalis folder. Your application most likely have a OXALIS_HOME system property pointing to the .oxalis folder.

@dladlk We have 3 applications, Inbound, Outbound and SMP. They all use the same OXALIS_HOME system property, so should all read the same oxalis.conf file. We are currently working on upgrading to 5.0.5 but facing some issues. Will have to investigate why our Outbound application does not read the oxalis.conf property.

[runholen]

I don't know what the differences are between our setup and canilsenlogiq's setup, but I tried adding lookup.locator.class=no.difi.vefa.peppol.lookup.locator.BusdoxLocator as canilsenlogiq mentioned earlier in our oxalis 4.1.1's oxalis.conf file, and restarting everything, and now we luckily got it to work again sending ehf's

[phax]

See https://github.com/OxalisCommunity/oxalis/issues/498 for the fix

[ic-officient]

I can confirm that adding lookup.locator.class=no.difi.vefa.peppol.lookup.locator.BusdoxLocator to oxalis.conf works for oxalis-standalone 4.1.2

[canilsenlogiq]

Can confirm the same. Got it working after a proper restart of the application.

[aaron-kumar]

Thanks @dladlk and @phax for answering queries when I was away 👏

This change was already documented with reason and fix at : https://www.oxalis.network/technical-information

Now it seems for everyone ( @runholen and @ic-officient , @canilsenlogiq ) it is working after suggested changes. Closing issue now

[wilhelm71]

I found the oxalis.conf file, and applied the mentioned change. All is working well now. Thanks alot for the quick responses.