Open hamri opened 2 years ago
There is an issue parsing the unknown "Any" element at the supplementary data: FromBOData
Hello,
Any news about this issue ?
Thanks for your help,
Hi, it's still pending and not easy to fix. You are welcome to propose a solution via PR.
I've been exploring this issue.
The actual error comes from the custom NamespaceAndElementFilter. In particular, the startPrefixMapping method causes the negative index in the internal UnmarshallingContext implementation. By removing that the exception is not thrown, however the Any element is not parsed into a generic Element as expected.
Test cases and sandbox code has been pushed to: https://github.com/prowide/prowide-iso20022/pull/48
Anyone with the same or similar issue is welcome to explore alternatives for a fix in the NamespaceAndElementFilter or MxReadImpl classes, which are the relevant ones for this.
Hello, I want to retrieve the data from splmtryData while parsing the XML. AbstractMX parse = AbstractMX. Parse (new File (xmlFilePath), new MxId("urn:iso:std:iso:20022:tech:xsd:pacs.008.001.10")); "splmtryData": [ { "plcAndNm": "core:FIToFICstmrCdtTrf/core:CdtTrfTxInf/core:PmtId", "envlp": {} } ] Is there a solution, please? , i get it null
This seems to be quite a large limitation for this library, especially since the library actually supports a bunch of the xml elements that could be in the splmtryData which can't really be used, ie. (https://github.com/prowide/prowide-iso20022/tree/develop/model-supl-types/src/generated/java/com/prowidesoftware/swift/model/mx/dic). By the time the message has been read, we can't even get access to the xml string at that point to do it manually. I'm curious if the are any workarounds other than parsing everything before the message itself is parsed? This approach doesn't work with frameworks like JMS, etc.
Indeed it is a known limitation.
There is an open PR to handle the Any element.
https://github.com/prowide/prowide-iso20022/pull/48
The idea is to return the supplementary data content and any other using Any in the schema as a generic DOM Element. I did not had the time myself the time to explore this further but the feature is on the wish list.
Hmm that doesn't seem to work though if the supplementary data is under a different namespace though I don't think? Like in this example message - https://github.com/prowide/prowide-iso20022/blob/7cc0e5923471ddfae6c13da801187c517e94bb33/iso20022-core/src/test/java/com/prowidesoftware/swift/model/mx/SupplementaryDataUtilsTest.java#L180
Hello,
We are facing a problem while parsing an MX message of type admi.007.001.01 using SRU2020-9.1.5 version. Upgrading to SRU2021-9.2.5 version doesn't resolve the issue.
This is an example of an admi.007.001.01 message:
Could you please help us to fix the issue?
Thanks,