SMP Lookup

[monze]

Hello

We are currently using Oxalis 3.2, and noticed a couple of problems with SMP lookup. They were discovered during some internal test runs, and therefore we have not yet seen the problem in production. The issues will only appear in special circumstances, when the SMP registration is done in a valid (but not normally used) way.

If we look at the following registration in the SMP: http://b-ddc207601e442e1b751e5655d39371cd.iso6523-actorid-upis.edelivery.tech.ec.europa.eu/iso6523-actorid-upis%3A%3A9908%3A810017902/services/busdox-docid-qns%3A%3Aurn%3Aoasis%3Anames%3Aspecification%3Aubl%3Aschema%3Axsd%3ACreditNote-2%3A%3ACreditNote%23%23urn%3Awww.cenbii.eu%3Atransaction%3Abiitrns014%3Aver2.0%3Aextended%3Aurn%3Awww.cenbii.eu%3Aprofile%3Abiixx%3Aver2.0%3Aextended%3Aurn%3Awww.difi.no%3Aehf%3Akreditnota%3Aver2.0%3A%3A2.1

We can see that in the ns3:ProcessList that only one ns3:Process exist. In the test performed, there was two ns3:Process elements. The second ns3:Process element contains the information we need. However in the oxalis-common class eu.peppol.smp.SmpLookupManagerImpl we have found this code

   EndpointType selectOptimalEndpoint(SignedServiceMetadataType serviceMetadata) {
        // List of end points contained in the signed service meta data type
        List<EndpointType> endPointsForDocumentTypeIdentifier = serviceMetadata
                .getServiceMetadata()
                .getServiceInformation()
                .getProcessList()
                .getProcess()
                .get(0)
                .getServiceEndpointList()
                .getEndpoint();
...

where the code always take the first ns3:Process element from the process list and we need the second element.

Described below are the first errors: 1 - The first ns3:Process element could be the old START protocol, while the second could be AS2 protocol. So the code should loop through the list and find only those that have an accepting protocol. 2 - The method does not validate the profile. The first ns3:Process element could be a undesired profile, while a later ns3:Process element could be the desired ns3:Process element.

Another error related to above errors were found in the class eu.peppol.smp.DefaultBusDoxProtocolSelectionStrategyImpl, as showed below. However this error could also be described as an invalid SMP registration, but Oxalis should still handle this in a valid way.

@Override
    public BusDoxProtocol selectOptimalProtocol(List<BusDoxProtocol> protocolsAccepted) {
        int lowestIndex = Integer.MAX_VALUE;
        for (BusDoxProtocol busDoxProtocol : protocolsAccepted) {
            int indexOf = knownProtocols.indexOf(busDoxProtocol);
            if (indexOf == -1) {
                throw new IllegalArgumentException("BusDox protocol " + busDoxProtocol + " not known by protocol selection strategy");
            }
            if (indexOf > -1 && indexOf < lowestIndex) {
                lowestIndex = indexOf;
            }
        }
        return knownProtocols.get(lowestIndex);
    }

The error we received was:

Caused by: java.lang.ArrayIndexOutOfBoundsException: 2147483647
    at java.util.Arrays$ArrayList.get(Unknown Source) ~[na:1.8.0_101]
    at eu.peppol.smp.DefaultBusDoxProtocolSelectionStrategyImpl.selectOptimalProtocol(DefaultBusDoxProtocolSelectionStrategyImpl.java:55) ~[oxalis-commons-3.2.0.jar:na]

If we look at the class, the index is first set to 2147483647 ( Integer.MAX_VALUE). In the ns2:Process element, the ns2:ServiceEndpointList element contains no ns2:Endpoint element. The method just jump to:

   knownProtocols.get(lowestIndex);

and the lowestIndex is still 2147483647, so it result in an ArrayIndexOutOfBoundsException.

Jacob Mogensen mySupply ApS Denmark

[monze]

An examples of how multi Process element exist in the ProcessList, can here been seen on page 16-17: http://www.peppol.eu/Archive/final-public-documents-and-presentations/publications/peppol-infrastruture-1-0-specifications-for-hearing/service-metadata-publisher-sml-1.0/at_download/file

The url looks weird, but it actual link to a pdf document.

Jacob Mogensen mySupply ApS Denmark

[monze]

Another issue, that we have notices, is that Oxalis does not evaluate the ServiceActivationDate nor the ServiceExpirationDate.

The documentation about the Service Metadata Publishing (the pdf document in the above post) states that:

.... Senders should ignore services that are
not yet activated, or expired. Format of ServiceExpirationDate date is
xs:dateTime.

So according to that documentation, the service Norwegian test Service (9908:810017902) should no longe be valid:

<ns3:ServiceActivationDate>2013-05-06T02:00:00.000+02:00</ns3:ServiceActivationDate>
<ns3:ServiceExpirationDate>2015-05-06T02:00:00.000+02:00</ns3:ServiceExpirationDate>

Jacob Mogensen mySupply ApS Denmark

[wiecia]

We're using Oxalis v.4.0.4 and it also seems to ignore this properties unfortunately.

[sabandosoleda]

It seems like a change to the SMP lookup client in this direction will soon be necessary, as the SMP v1.2.0 specification made interpretation of ServiceActivationDate and ServiceExpirationDate mandatory for all Sender's starting 10/03/22, meaning that all sending APs will need to abort transmissions when the current date is not between ServiceActivationDate and ServiceExpirationDate (only when those two fields are declared by the recipient's SMP)

[aaron-kumar]

Refer : https://github.com/OxalisCommunity/vefa-peppol/issues/44

[sabandosoleda]

Thanks!

[aaron-kumar]

Changes committed as part of https://github.com/OxalisCommunity/vefa-peppol/commit/96be12a493f88ff072e197837cc05e67245145cc