Parsing issue with MX message of type admi.007.001.01

hamri commented 2 years ago

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:

<?xml version="1.0" encoding="ISO-8859-1"?>
<Body>
    <AppHdr xmlns="urn:iso:std:iso:20022:tech:xsd:head.001.001.01">
        <Fr>
            <FIId>
                <FinInstnId>
                    <BICFI>XXXXXXXXXXX</BICFI>
                </FinInstnId>
            </FIId>
        </Fr>
        <To>
            <FIId>
                <FinInstnId>
                    <BICFI>XXXXXXXXXXX</BICFI>
                </FinInstnId>
            </FIId>
        </To>
        <BizMsgIdr>XXXXXXX</BizMsgIdr>
        <MsgDefIdr>admi.007.001.01</MsgDefIdr>
        <CreDt>2022-01-11T15:02:09Z</CreDt>
    </AppHdr>
    <Document xmlns="urn:iso:std:iso:20022:tech:xsd:admi.007.001.01">
        <RctAck>
            <MsgId>
                <MsgId>XXXXXXX</MsgId>
            </MsgId>
            <Rpt>
                <RltdRef>
                    <Ref>XXXXXX</Ref>
                </RltdRef>
                <ReqHdlg>
                    <StsCd>ACKT</StsCd>
                    <Desc>CR50</Desc>
                </ReqHdlg>
            </Rpt>
            <SplmtryData>
                <Envlp>
                    <FromBOData>TOTO</FromBOData>
                </Envlp>
            </SplmtryData>
        </RctAck>
    </Document>
</Body>

Could you please help us to fix the issue?

Thanks,

zubri commented 2 years ago

There is an issue parsing the unknown "Any" element at the supplementary data: FromBOData

hamri commented 2 years ago

Hello,

Any news about this issue ?

Thanks for your help,

zubri commented 2 years ago

Hi, it's still pending and not easy to fix. You are welcome to propose a solution via PR.

zubri commented 2 years ago

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.

dhouhadaoud commented 3 months ago

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

jrogers commented 3 months ago

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.

zubri commented 3 months ago

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.

jrogers commented 3 months ago

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

prowide / prowide-iso20022

Parsing issue with MX message of type admi.007.001.01 #39