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

Oxalis LookupService exception handling #586

Open
canilsenlogiq opened this issue May 6, 2022 · 1 comment
Open

Oxalis LookupService exception handling #586

canilsenlogiq opened this issue May 6, 2022 · 1 comment
Labels
Enhancement Pri/M Medium priority
Milestone

Comments

@canilsenlogiq
Copy link

canilsenlogiq commented May 6, 2022

Hello, thank you for your effort with the Oxalis Project.
We are having some issues with handling the different LookupService exceptions.

In one of the newer Oxalis versions, changes were made to error handling in the LookupService, the LookupService now throws a NotFoundException or a LookupException.

  • NotFoundException maps to situations were the recipient does not exist in the Peppol network.
  • LookupException maps to senarios were something went wrong, such as a timeout.

Because of this we have mapped NotFoundException to be: Recipient and/or Document Format combination does not exist in PEPPOL, can fallback to another channel. And LookupException is mapped to: Lookup failed something went wrong, we have to redo/retry the lookup at a later time.

Issue 1
The LookupException throws the error: "Combination of receiver XXXXX and document type identifier XXXXX is not supported.” which I believe should be a NotFoundException.

This is not a big issue, we just have to check the cause of the LookupException, and if it is the error above, we interept this as: "Recipient and Document Format combination does not exist in PEPPOL".

Issue 2
LookupExceptions with error: "Combination of receiver XXXXX and document type identifier XXXXX is not supported.” are caused by: FileNotFoundException, however this does not distinguish between when the SMP is down(404) and when it is a "real" situation when the recipient does not support the document type identifier.

This is casuing us to not send files through PEPPOL when the SMP is down, instead of trying again later.


If we have interpret the different exceptions wrongly, or there any dangers with the way we have mapped the two different exception types, please tell us.


Two examples, both return same exception and cause, but should in theory be handled differently. One should fallback, the other should retry.

Example 1 - Recipient does not exist in PEPPOL with the document type identifier
network.oxalis.api.lang.OxalisTransmissionException: Combination of receiver (iso6523-actorid-upis::0088:7350112500015) and document type identifier (busdox-docid-qns::urn:oasis:names:specification:ubl:schema:xsd: Invoice-2::Invoice##urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0::2.1) is not supported.

Caused by: network.oxalis.vefa.peppol.lookup.api.LookupException: Combination of receiver (iso6523-actorid-upis::0088:7350112500015) and document type identifier (busdox-docid-qns::urn:oasis:names:specification:ubl:schema:xsd:Invoice-2::Invoice##urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0::2.1) is not supported.

Caused by: java.io.FileNotFoundException: http://B-360b6f1252c88dca9f580e5ca75670c4.iso6523-actorid-upis.edelivery.tech.ec.europa.eu/iso6523-actorid-upis%3A%3A0088%3A7350112500015/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

Example 2 - Recipient exist with document type identifier, but we think SMP was down
network.oxalis.api.lang.OxalisTransmissionException: Combination of receiver (iso6523-actorid-upis::0192:936846777) and document type identifier (busdox-docid-qns::urn:oasis:names:specification:ubl:schema:xsd:Invoice-2::Invoice##urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0::2.1) is not supported.

Caused by: network.oxalis.vefa.peppol.lookup.api.LookupException: Combination of receiver (iso6523-actorid-upis::0192:936846777) and document type identifier (busdox-docid-qns::urn:oasis:names:specification:ubl:schema:xsd:Invoice-2::Invoice##urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0::2.1) is not supported.

Caused by: java.io.FileNotFoundException: http://B-05dafe9d16d8f1da7eed1ad798a69c11.iso6523-actorid-upis.edelivery.tech.ec.europa.eu/iso6523-actorid-upis%3A%3A0192%3A936846777/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

@aaron-kumar aaron-kumar moved this to Open Issues- Review Required in Oxalis Public Roadmap May 7, 2022
@aaron-kumar
Copy link
Member

aaron-kumar commented May 7, 2022

Similar to #158 and #497

@aaron-kumar aaron-kumar added the Pri/M Medium priority label May 7, 2022
@aaron-kumar aaron-kumar added this to the 5.x.x milestone Oct 25, 2022
@aaron-kumar aaron-kumar modified the milestones: 5.x.x, Future, 6.x.x Jan 16, 2023
@aaron-kumar aaron-kumar moved this from Open Issues- Review Required to Q1 2023 –Jan-March in Oxalis Public Roadmap Jan 16, 2023
@aaron-kumar aaron-kumar moved this from Q2 2023 – April-June to Q4 2023 – October-December in Oxalis Public Roadmap Sep 25, 2023
@aaron-kumar aaron-kumar moved this from Q4 2023 – October-December to Future in Oxalis Public Roadmap Dec 9, 2023
@aaron-kumar aaron-kumar modified the milestones: 6.x.x, 7.x.x Dec 9, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Enhancement Pri/M Medium priority
Projects
Status: Future
Development

No branches or pull requests

2 participants