Things were going swimmingly until I was working on the code to download the Track+ issue attachments and attach them to the JIRA issue.
For whatever reason, Atlassan designed their JIRA WSDL for attaching files as follows:
<wsdl:message name="addAttachmentsToIssueRequest">
<wsdl:part name="in0" type="xsd:string"/>
<wsdl:part name="in1" type="xsd:string"/>
<wsdl:part name="in2" type="impl:ArrayOf_xsd_string"/>
<wsdl:part name="in3" type="impl:ArrayOf_xsd_base64Binary"/>
</wsdl:message>
What this results in is a element in the SOAP call like this:
<multiRef id="id884" soapenc:root="0"
soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
xsi:type="xsd:byte" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/">
89
</multiRef>
... for every byte in the attachment(s).
So every byte in the attachment winds up being nearly 200 bytes in the SOAP class. 1 MB attachment? 200 MB+ SOAP request that has to be constructed, sent across the wire, and processed. Ouch.
Thankfully, the JIRA user community has reported the issue to JIRA and provided a (non-SOAP) workaround.
If only there was some alternative method to encode binary data into the printable ASCII character set... And/or some kind of "fat-free" alternative to XML... One can always dream though, right? :-p
No comments:
Post a Comment