CEF Connectivity Test (dynamic scenario) #179
Comments
aaron-kumar
added
help wanted
|
Hi all, I have a question: if I access the SMK website: acc.edelivery.tech.ec.europa.eu/edelivery-sml/listDNS
In fact, if I try to enter the name on the left in the browser url, I am redirected to the url that appears on the right after CNAME:
I press the Enter button and I am actually redirected to my server smp.pantarei-si.it:
This happens because in the specific line of the DNS list acc.edelivery.tech.ec.europa.eu/edelivery-sml/listDNS As regards the mapping of PARTICIPANT-IDs, the DNS resource type is no longer CNAME, but NAPTR:
In this case the url on the left, copied and pasted into the browser, does not produce the actual redirection to my SMP: http://smp.pantarei-si.it/
This could be the reason why, whenever I test sending a message via PEPPOL to the specific PARTICIPANT-ID, it tells me that this PARTICIPANT-ID does not exist in the SMK. Payload.xml:
What do you think about this behaviour I have described, relating to NAPTR type mapping that is not picked up by the DNS? I saw the topic 498, and now I'm wondering if Oxalis also has issues with the NAPTR protocol. What do you guys think? |
|
I have exactly the same problem |
|
there is a site that allows you to test various configurations, through online tools: https://peppol.helger.com/public/locale-en_US/menuitem-tools If I run a test to verify the existence of the participant "dynceftest2party70gw", the test is successful:
But when I test the correctness of the participant's declaration structure, according to what I have been able to understand from the documentation, the test fails:
While if I insert a known structure, like the following: iso6523-actorid-upis::0211:05901080969, the test is successful:
This may be why we always receive that the participant is not recognized in SMK. What are your thoughts on this? Greetings Pierfrancesco |
|
I couldn't find where to set this subdomain I tried (unsuccessfully) to change the parameter: lookup.locator.hostname="connectivitytest.acc.edelivery.tech.ec.europa.eu/edelivery-sml/"and I also saw that in the oxalis code, regarding the CEF connectivity test, there are carved parameters. That is, by searching the code for the AS4 configuration class, it appears in 6 places: https://github.com/search?q=org%3AOxalisCommunity+network.oxalis.as4.config&type=code For example As4OutboundModule.java so anything I put in the payload.xml would seem to be ignored. |
|
Did you try to omit context name from the locator hostname? This looks weird for me - this configuration is used for DNS resolution, not for making calls...
Try
And as far as I see, NAPTR records are not supported by browsers, NAPTR is used by BdxlLookup, but Busdox lookup use CNAME via hashes. Try to debug network.oxalis.vefa.peppol.lookup.locator.BusdoxLocator to see how the lookup is done. As it does not log debug messages, only real debugging is possible. |
|
Oh, I remembered a way how to see debug messages for DNS lookups - add into your code before lookup invocation next line:
This will give you in stdout something like: so you can check what kind of DNS lookups actually are done. Also it will show you DNS servers it queries so it is possible to optimize it by passing e.g. |
|
Thanks @dladlk for your answer. I think I have overcome the problem related to participant recognition with this configuration: oxalis.keystore {
path=dynceftest2party70gw.jks
password = test123
key.alias = dynceftest2party70gw
key.password = test123
}
oxalis.as4.type=cef-connectivity
lookup.locator.hostname="connectivitytest.acc.edelivery.tech.ec.europa.eu"
lookup.locator.class = network.oxalis.vefa.peppol.lookup.locator.BdxlLocator
security.validator.class = network.oxalis.vefa.peppol.security.util.EmptyCertificateValidator
oxalis.path.inbound = /home/XXXXXX/.oxalis/in
oxalis.logging.config=logback.xmlI have now come to the problem of recognizing the in fact the class PeppolDocumentTypeId.java, has a parser that retrieves that value, through a regular expression: static Pattern documentIdPattern = Pattern.compile("(.*)::(.*)##(.*)::(.*)");Is there any way to bypass this step of deconstructing and rebuilding the DOCUMENTID, and just take what is written in the TAG? I'm making several attempts to find a tag content that will work, but I haven't succeeded yet. Below is my payload.xml: <?xml version="1.0" encoding="UTF-8"?>
<StandardBusinessDocument xmlns="http://www.unece.org/cefact/namespaces/StandardBusinessDocumentHeader">
<StandardBusinessDocumentHeader>
<HeaderVersion>2.2</HeaderVersion>
<Sender>
<Identifier Authority="connectivity-partid-qns">dynceftest2party70gw</Identifier>
</Sender>
<Receiver>
<Identifier Authority="connectivity-partid-qns">cefsupport1gw</Identifier>
</Receiver>
<DocumentIdentification>
<Standard>NONE</Standard>
<TypeVersion>1.0</TypeVersion>
<InstanceIdentifier>d8b5b55f-508d-438a-8363-2e5e0d7820fc</InstanceIdentifier>
<Type>CEF Connectivity test</Type>
<CreationDateAndTime>2022-05-05T18:15:00.000+02:00</CreationDateAndTime>
</DocumentIdentification>
<BusinessScope>
<Scope>
<Type>DOCUMENTID</Type>
<Identifier>connectivity-docid-qns</Identifier>
<InstanceIdentifier>::doc_id1##::</InstanceIdentifier>
</Scope>
<Scope>
<Type>PROCESSID</Type>
<Identifier>connectivity-procid-qns</Identifier>
<InstanceIdentifier>urn:www.cenbii.eu:profile:bii04:ver1.0</InstanceIdentifier>
</Scope>
</BusinessScope>
</StandardBusinessDocumentHeader>
<Request>eDelivery AS4 Connectivity test. Sending Message</Request>
</StandardBusinessDocument>log: |
|
I tried the same than pierfrancesco and I received the same response Message failed : Combination of receiver (xxx) and document type identifier (xxx) is not supported. |
|
Wow... It really looks weird for me :) But let's look into your configuration: lookup.locator.hostname=connectivitytest.acc.edelivery.tech.ec.europa.eu When I do it, I do not get Busdox simple result - but only Bdxl result:
So, as war as I see, SML forwards responses from https://gateway-edelivery.westeurope.cloudapp.azure.com:444/connectivity-partid-qns::cefsupport1gw If we try to access it to see which documents are configured, we see this XML: But if I try to access the URL to details of the single published document - it hangs: It slightly corresponds to log records you printed - Oxalis tries to load this metadata but gets ErrorResponse at 14:48:22.518... Something is weird with this SMP registration, it has sense to ask CEF support why the SMP works so strange... The question to them could be - why the link inside this XML result does not work? https://gateway-edelivery.westeurope.cloudapp.azure.com:444/connectivity-partid-qns::cefsupport1gw |
|
Oh, I again answered not exact your question :) According to overview of registered ServiceMetadataReferences, I think the document type id in SBDH should be just "connectivity-docid-qns::doc_id1": In other words, in your logs I can see next line (URL decoded):
According to SMP overview by participant, it should be just:
I guess that is why it was rejected immediately and did not hang. But the problem for me was to get the response from SMP by request to details of this ServiceMetadata from SMP... Are you able to get it? If yes, please post the response XML here. |
|
Many Thanks @dladlk, regarding what you suggest, there is the problem I mentioned in my previous post, that is the one regarding the XML parser, in fact if I insert this specific
Oxalis immediately stops the execution of the request, already at the moment of the parse of the |
|
Oh, you are right - I again answered not what you asked :) The answer is - build SBDH by yourself. The class you mention is inside oxalis-document-sniffer sub-project - which is an a legacy part. It is done to build SBDH by some predefined sets of documents, and that is why you have issues with doc_id1. Just wrap your payload with SBDH and put there whatever you want - as I know, Oxalis invokes sniffer only if it is not already SBD in payload. |
|
I'm not quite sure what to do... I've tried editing the <?xml version="1.0" encoding="UTF-8"?>
<StandardBusinessDocument xmlns="http://www.unece.org/cefact/namespaces/StandardBusinessDocumentHeader">
<StandardBusinessDocumentHeader>
<HeaderVersion>2.2</HeaderVersion>
<Sender>
<Identifier Authority="connectivity-partid-qns">dynceftest2party70gw</Identifier>
</Sender>
<Receiver>
<Identifier Authority="connectivity-partid-qns">cefsupport1gw</Identifier>
</Receiver>
<DocumentIdentification>
<Standard>connectivity-docid-qns</Standard>
<TypeVersion>1.0</TypeVersion>
<InstanceIdentifier>c799362c-45aa-494d-be1c-2df3ba277bf8</InstanceIdentifier>
<Type>doc_id1</Type>
<CreationDateAndTime>2022-05-09T12:00:00.000</CreationDateAndTime>
<!--Standard>NONE</Standard>
<TypeVersion>1.0</TypeVersion>
<InstanceIdentifier>d8b5b55f-508d-438a-8363-2e5e0d7820fc</InstanceIdentifier>
<Type>CEF Connectivity test</Type>
<CreationDateAndTime>2022-05-05T18:15:00.000+02:00</CreationDateAndTime-->
</DocumentIdentification>
<BusinessScope>
<Scope>
<Type>DOCUMENTID</Type>
<Identifier>connectivity-docid-qns</Identifier>
<InstanceIdentifier>doc_id1</InstanceIdentifier>
</Scope>
<Scope>
<Type>PROCESSID</Type>
<Identifier>connectivity-procid-qns</Identifier>
<InstanceIdentifier>urn:www.cenbii.eu:profile:bii04:ver1.0</InstanceIdentifier>
</Scope>
</BusinessScope>
</StandardBusinessDocumentHeader>
<Request>eDelivery AS4 Connectivity test. Sending Message</Request>
</StandardBusinessDocument>but the sniffer error is still there:
And if I try to remove the first TAG
|
|
Oh, yes, you already send SBD... |
|
For now I have only dirty hack for you - omit actual lookup and supply its results by yourselves :) My previous suggestion that something is wrong with SMP was not fully correct - the only issue it has - they publish HTTP links in signed metadata but do not allow them :) So the URL is openable if you change http to https: Here you can find receiver certificate, URL and transport protocol you can use to pass as parameters to eu.sendregning.oxalis.Main What confuses me - that the transport profile in SMP response is bdxr-transport-ebms3-as4-v1p0 - which I cannot find in the code of Oxalis at all. I found only this ticket: #12 which references this profile. And it relates to Peppol testbed, not CEF test bed you pass, right? But if you supply all required parameters, lookup will be omitted and you can use your original InstanceIdentifier "::doc_id1##::" |
|
Found the transport profile in vefa-peppol: https://github.com/OxalisCommunity/vefa-peppol/blob/373176b22d91fc975ce0a297387a70dbef69108e/peppol-common/src/main/java/network/oxalis/vefa/peppol/common/model/TransportProfile.java#L42 So I guess it should work :) Please post a message if you succeed - something like |
I do not know if this stacktrace can be significant. |
|
Sorry, I meant the stacktrace when you put or But I guess it happens somewhere in network.oxalis.outbound.transmission.TransmissionRequestBuilder#build() line 206, when Oxalis tries to make a lookup and converts PeppolStandardBusinessHeader to Vefa... |
|
I am interested in your case because it looks like Oxalis does not support CEF connectivity dynamic scenario. I cannot test it by myself without submitting for the report, that is why I am asking all this :) |
|
You could think of a temporary wokraround, to allow the CEF connectivity test to pass, which would involve putting a constant in the payload.xml within the for example: <InstanceIdentifier>connectivity::cef##connectivity-docid-qns::doc_id1</InstanceIdentifier>thus the presence of the property: oxalis.as4.type=cef-connectivityin outbound stage, the connectivity::cef## constant will be removed so that the match can be made. What do you think? Is it feasible? This in the short term, then this management will be better structured in future releases. |
|
I would do something like if it was my own project :) But I do not have enough knowledge yet about all the code to be sure that there are no other options. Only now I have found this documentation: https://github.com/OxalisCommunity/Oxalis-AS4/blob/master/docs/CEF-connectivity.md It suggests exactly what I proposed you to do - pass all required lookup results into parameters when you call document sending, so the lookup can be done by the "wrong" DOCUMENT_ID which conforms with Peppol requirements:
In my eyes it has some incorrect values, e.g.
should be
And looking into the code where is referenced, only now I found, that something similar to what you suggest already has done here:Oxalis-AS4/src/main/java/network/oxalis/as4/common/As4CommonModule.java Lines 121 to 131 in 739a7e0 Anyway, for now I would suggest you to try omitting real lookup as it is mentioned in the documentation for CEF connectivity test (btw, there is also CEF conformance test) - and I update the documentation basing on your results. More general solution for easier CEF connectivity test passing should be discussed and confirmed by the Oxalis team I guess - as it will require more time to review the solution, approve and release... |
Hi @dladlk , I have tried this configuration and the error is still there: start.sh: java -classpath "./standalone/*:./as4/*" eu.sendregning.oxalis.Main -f ./payload.xml -d doc_id1 -p urn:www.cenbii.eu:profile:bii04:ver1.0 payload.xml: <BusinessScope>
<Scope>
<Type>DOCUMENTID</Type>
<Identifier/>
<InstanceIdentifier>connectivity::cef##connectivity::submitMessage</InstanceIdentifier>
</Scope>
... |
|
Yes, because you did not define endpoint URL, certificate, and all other parts mentioned in the documentation example for CEF connectivity test or in my example - that is why it still tries to make a lookup. The trick is to make the lookup by yourselves - and get required data from the SMP link I posted and pass them as parameters to the program. Try to define all of them in your script.sh file - looks like it is the only way to pass the test now... |
|
There seem to be references to the old packages anyway
|
|
Looks like the file you passed as --cert is not valid :) E.g. try to rename its extension to *.crt and open as windows - it should be openable and show certificate details. You need to copy the contents of published certificate at SMP into file and pass it to Oxalis:
E.g. like this:
Result file should (certificate of the endpoint) should be passed as --cert The package you mentioned from commons-certvalidator.jar which is out of Oxalis, external library from Difi. BTW, may be the document type for Oxalis should be in the Peppol-compliant form - like |
|
Sorry Dym you are right, I have modified the certificate and it is now OK, I have also modified the java.util.concurrent.ExecutionException: network.oxalis.api.lang.OxalisTransmissionException: Transport protocol 'bdxr-transport-ebms3-as4-v1p0' not supported. |
|
Yes, that is what I worried about... But looks like we are close :) In the doc file about CEF connectivity https://github.com/OxalisCommunity/Oxalis-AS4/blob/master/docs/CEF-connectivity.md it is mentioned another protocol for this:
Also as oxalis.conf:
Try to "play" with these options - e.g. use another protocol... If it does not help - possible option is to expand your oxalis.conf with definition for the profile: At least for now it fails because cannot find sender value - but I am not sure which configs are expected here... |
|
OK, with <env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
<env:Header>
<eb:Messaging xmlns:eb="http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200704/" env:mustUnderstand="true">
<eb:SignalMessage>
<eb:MessageInfo>
<eb:Timestamp>2022-05-11T10:56:02.943Z</eb:Timestamp>
<eb:MessageId>[email protected]</eb:MessageId>
<eb:RefToMessageId>[email protected]</eb:RefToMessageId>
</eb:MessageInfo>
<eb:Error category="PROCESSING" errorCode="EBMS:0010" origin="ebMS" refToMessageInError="[email protected]" severity="failure" shortDescription="ProcessingModeMismatch">
<eb:Description xml:lang="">The ebMS header or another header (e.g. reliability, security) expected by the MSH is not compatible with the expected content, based on the associated P-Mode.</eb:Description>
<eb:ErrorDetail>No matching dynamic discovery processes found for message.</eb:ErrorDetail>
</eb:Error>
</eb:SignalMessage>
</eb:Messaging>
</env:Header>
<env:Body>
<env:Fault>
<env:Code>
<env:Value>env:Receiver</env:Value>
</env:Code>
<env:Reason>
<env:Text xml:lang="en">An error occurred while processing your request. Please check the message header for more details.</env:Text>
</env:Reason>
</env:Fault>
</env:Body>
</env:Envelope>this is the log file: oxalis-standalone.log while with the configuration oxalis.conf: oxalis.keystore {
path=dynceftest2party70gw.jks
password = test123
key.alias = dynceftest2party70gw
key.password = test123
}
oxalis.as4.type=cef-connectivity
defaults.transport.bdxr-transport-ebms3-as4-v1p0 = {
profile: bdxr-transport-ebms3-as4-v1p0
sender: oxalis-as4
weight: 5001
}
lookup.locator.hostname="connectivitytest.acc.edelivery.tech.ec.europa.eu"
lookup.locator.class = network.oxalis.vefa.peppol.lookup.locator.BdxlLocator
security.validator.class = network.oxalis.vefa.peppol.security.util.EmptyCertificateValidator
oxalis.path.inbound = /Users/BK001496/.oxalis/in
oxalis.logging.config=logback.xmland with parameter
and with parameter <eb:Error category="PROCESSING" errorCode="EBMS:0010" origin="ebMS" refToMessageInError="[email protected]" severity="failure" shortDescription="ProcessingModeMismatch">
<eb:Description xml:lang="">The ebMS header or another header (e.g. reliability, security) expected by the MSH is not compatible with the expected content, based on the associated P-Mode.</eb:Description>
<eb:ErrorDetail>No matching dynamic discovery processes found for message.</eb:ErrorDetail>
</eb:Error> |
|
We are close :) What is the payload you sent? I guess they have Domibus on their side, the message about "No matching dynamic discovery processes found for message" means that SBDH is not configured as expected... Try to activate again http logging - so we see actual SBDH sent there... |
|
Hi @pierfrancesco72! I hope you did not give up and successfully passed the test, did you? ;) |
|
No, I have temporarily put the test on hold. I did not download the sources, in order to highlight the logs of the http request, sent to the receiving participant. |
aaron-kumar
added
CEF TestBed
I have registered a participant with Phoss SMP:
connectivity-partid-qns::dynceftest2party71gwIf I try to find it on https://acc.edelivery.tech.ec.europa.eu/edelivery-sml/search :
it is present:
SML sub-domain: connectivitytest.acc.edelivery.tech.ec.europa.eu
or in this other site: https://peppol.helger.com/public/locale-en_US/menuitem-tools-participant
but when I try to send a payload.xml from
oxalis-distribution-5.0.6-distrooxalis-standalone.jar with this payload.xml:and this command:
java -classpath "./*:../api/*" eu.sendregning.oxalis.Main -f ./payload.xmlI receive this error:
Message failed : Identifier 'dynceftest2party71gw' is not registered in SML.
Maybe my payload.xml is badly formatted?
this is my
oxalis.conf:oxalis.keystore { path=dynceftest2party71gw.jks password = test123 key.alias = dynceftest2party71gw key.password = test123 } security.truststore.ap=/home/ubuntu/.oxalis/truststore/gateway_truststore.jks security.truststore.password=test123 oxalis.as4.type=cef-connectivity #oxalis.header.parser=dummy lookup.locator.hostname="acc.edelivery.tech.ec.europa.eu/edelivery-sml/" lookup.locator.class = network.oxalis.vefa.peppol.lookup.locator.BusdoxLocator security.validator.class = network.oxalis.vefa.peppol.security.util.EmptyCertificateValidator oxalis.path.inbound = /home/ubuntu/.oxalis/inThe text was updated successfully, but these errors were encountered: