After developing integration with Adobe Elements 6.0.0 web services then finding Adobe had altered their interface for 6.0.1 (see an earlier post), we've tried modifying our .Net application to work with this new soap service. However, Microsoft Soap technologies cannot handle the response. This is because the response is invalidly generated by Adobe Elements Server - not an issue with the Microsoft technologies.<br /><br />I expect, like my previous posting, this will be totally ignored by Adobe.<br /><br /><?xml version="1.0" encoding="UTF-8"?><br /><SOAP-ENV:Envelope xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance" <br /> xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"<br /> xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"<br /> xmlns:xsd="http://www.w3.org/1999/XMLSchema"<br /> SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"><br /> <SOAP-ENV:Body><br /> <namesp1:createPDFResponse xmlns:namesp1="urn:aaes"><br /> <status xsi:type="xsd:int">0</status><br /> <errorMessage xsi:type="xsd:string"/><br /> <jobID.xsi:type="xsd:string">4dfba64e-a8bd-4bb9-a274-72fce16e2912</jobID><br /> </namesp1:createPDFResponse><br /> </SOAP-ENV:Body><br /></SOAP-ENV:Envelope> <br /><br />The problem is in the 3 parameters: status, errorMessage and jobID. They should strictly have the "urn:aaes" namespace, as their parent element createPDFResponse. However, because the namespace is defined as a prefix, rather than the default namespace, it is not carried to the child elements, so they are not recognised.
FYI: This is an issue with the third party Perl Soap layer (SoapLite)that Adobe Elements implements. There's an official workaround for this issue. This requires a change to the Soap Service which Adobe appear to have disregarded. Consequently Adobe Elements Server's web service response is invalid and breaks compatibility with (at least) Microsoft soap integration.