https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43674 Bug ID: 43674 Summary: ISO 18626 messages are missing the mandatory ISO18626Message envelope Initiative type: --- Sponsorship --- status: Product: Koha Version: 26.05 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: ILL Assignee: koha-bugs@lists.koha-community.org Reporter: minhpq@tinhvan.com QA Contact: testopia@bugs.koha-community.org CC: lisette@bywatersolutions.com, pedro.amorim@openfifth.co.uk, tomascohen@gmail.com Target Milestone: --- Koha's ISO 18626 implementation sends and expects the message type as the XML document element — <request>, <supplyingAgencyMessage>, <requestingAgencyMessage> — with no enclosing element. The schema at https://illtransactions.org/schemas/ISO-18626-v1_2.xsd defines a single root element: <xs:element name="ISO18626Message"> ... <xs:attribute name="version" use="required"/> and makes request / supplyingAgencyMessage / requestingAgencyMessage children of it. So a conformant implementation rejects Koha's messages at deserialisation, before any business logic runs, and Koha in turn rejects a conformant partner's messages. What Koha sends today: <?xml version="1.0" encoding="UTF-8"?> <request> <header> <requestingAgencyRequestId>2</requestingAgencyRequestId> ... What the schema requires: <?xml version="1.0" encoding="UTF-8"?> <ISO18626Message xmlns="http://illtransactions.org/2013/iso18626" version="1.2"> <request> <header> <requestingAgencyRequestId>2</requestingAgencyRequestId> ... Where this comes from: * Koha::REST::V1::to_xml builds the document element from the first key of the JSON structure, with no wrapper and no namespace. * Koha::REST::V1::parse_xml / _parse_node read an incoming document the same way. * Koha::REST::V1::ILL::ISO18626::message determines the message type with my ($messageType) = keys %$json, i.e. from the document element name, and Koha::ILL::ISO18626::message_types lists the six message types as though each were a root element. A side effect is that there is currently no way for a Koha instance to state which revision of ISO 18626 it speaks, since the version attribute lives on the envelope. How it was found: Testing a Koha 26.05.02 instance against a third-party ISO 18626 implementation written in .NET, generated directly from the official v1.2 XSD. Every message was rejected in both directions until a wrapping/unwrapping shim was added on the third-party side. With that shim, and with three conformance fixes applied to the koha-ill-iso18626 plugin (reported upstream at https://github.com/openfifth/koha-ill-iso18626/pull/5), the full round trip works: Koha sends request, the partner replies requestConfirmation with messageStatus OK, the partner sends supplyingAgencyMessage, vand the Koha ILL request moves to ExpectToSupply with the partner's supplyingAgencyRequestId stored. The envelope was the only remaining deviation. This has probably gone unnoticed because ISO 18626 testing so far appears to have been Koha-to-Koha — the recreation steps on bug 43003, for example, stand up two Koha instances with the same plugin on both. Two endpoints that share the same deviation understand each other perfectly; the problem only appears against an implementation built from the schema. Suggested fix: Handle the envelope in the core XML middleware — add it in to_xml on the way out, and unwrap it in the around_action hook on the way in — so every ISO 18626 route keeps working unchanged and nothing needs to know about it. Accepting both wrapped and unwrapped input for a transition period would avoid breaking anyone mid-upgrade. Related: bug 37762 (supplying agency workflows, where the core ISO 18626 handling was added) and bug 41091 (ISO18626 for borrowing). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.