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.

Sign up for GitHub

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

Jump to bottom

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

Open
hamri opened this issue Jan 12, 2022 · 8 comments
Open

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

hamri opened this issue Jan 12, 2022 · 8 comments

Comments

@hamri
Copy link

hamri commented Jan 12, 2022 •
edited
Loading

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 added a commit that referenced this issue Jan 13, 2022
@zubri
GH-39 test case WIP
8f820c1
@zubri
Copy link
Member

zubri commented Jan 13, 2022

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

@john236 john236 mentioned this issue Jan 17, 2022
Open
@hamri
Copy link
Author

hamri commented Feb 22, 2022

Hello,

Any news about this issue ?

Thanks for your help,

@zubri
Copy link
Member

zubri commented Feb 23, 2022

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

@zubri
Copy link
Member

zubri commented May 25, 2022

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:
#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.

@zubri zubri mentioned this issue May 25, 2022
Open
@dhouhadaoud
Copy link

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
Copy link

jrogers commented Jun 10, 2024 •
edited
Loading

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
Copy link
Member

zubri commented Jun 10, 2024 •
edited
Loading

Indeed it is a known limitation.

There is an open PR to handle the Any element.

#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
Copy link

jrogers commented Jun 10, 2024

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 -

prowide-iso20022/iso20022-core/src/test/java/com/prowidesoftware/swift/model/mx/SupplementaryDataUtilsTest.java

Line 180 in 7cc0e59

+ " <Document xmlns=\"urn:iso:std:iso:20022:tech:xsd:supl.001.001.13\" xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\">"

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@jrogers @zubri @hamri @dhouhadaoud @ptorres-prowide