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: [email protected]
Reporter: [email protected]
QA Contact: [email protected]
CC: [email protected],
[email protected], [email protected]
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.
_______________________________________________
Koha-bugs mailing list -- [email protected]
To unsubscribe send an email to [email protected]
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/
