function readOnly(count){ }
Sign Up ›
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
Learn More

Browse by Topic
ShowAll Questionssorted byDate Posted
+ Start a Discussion
Daniel Gonzalez TorresDaniel Gonzalez Torres 

Metadata API v31.0 checkRetrieveStatus error

I am trying the version 31.0 of the metadata api. There is a new async method checkRetrieve status that accepts an asyncRetrieveId (e.g. 09SK0000001DmPTMA0) but my program throws an exception when I check for the tretrieve status.

I'm trying to retrieve a couple of Apex Classes (already in v31.0).

This is the exception I get:

com.sforce.ws.ConnectionException: Unexpected element. Parser was expecting element 'http://soap.sforce.com/2006/04/metadata:done' but found 'http://soap.sforce.com/2006/04/metadata:fileProperties'
	at com.sforce.ws.bind.TypeMapper.verifyTag(TypeMapper.java:389)
	at com.sforce.ws.bind.TypeMapper.verifyElement(TypeMapper.java:418)
	at com.sforce.soap.metadata.RetrieveResult.loadFields(RetrieveResult.java:237)
	at com.sforce.soap.metadata.RetrieveResult.load(RetrieveResult.java:230)
	at com.sforce.ws.bind.TypeMapper.readSingle(TypeMapper.java:631)
	at com.sforce.ws.bind.TypeMapper.readObject(TypeMapper.java:507)
	at com.sforce.soap.metadata.CheckRetrieveStatusResponse_element.loadFields(CheckRetrieveStatusResponse_element.java:62)
	at com.sforce.soap.metadata.CheckRetrieveStatusResponse_element.load(CheckRetrieveStatusResponse_element.java:54)
	at com.sforce.ws.bind.TypeMapper.readSingle(TypeMapper.java:631)
	at com.sforce.ws.bind.TypeMapper.readObject(TypeMapper.java:507)
	at com.sforce.ws.transport.SoapConnection.bind(SoapConnection.java:174)
	at com.sforce.ws.transport.SoapConnection.receive(SoapConnection.java:148)
	at com.sforce.ws.transport.SoapConnection.send(SoapConnection.java:99)
	at com.sforce.soap.metadata.MetadataConnection.checkRetrieveStatus(MetadataConnection.java:229)
	at com.force.deploy.tools.MainUIController.processApex(MainUIController.java:683)



Best Answer chosen by Daniel Gonzalez Torres
Daniel Gonzalez TorresDaniel Gonzalez Torres
Found a workaround: I manipulated the metadata.xml (wsdl) and changed the RetrieveResult to the old version.

Changed from:

<xsd:complexType name="RetrieveResult">
    <xsd:sequence>
     <xsd:element name="done" type="xsd:boolean"/>
     <xsd:element name="errorMessage" minOccurs="0" type="xsd:string"/>
     <xsd:element name="errorStatusCode" minOccurs="0" type="tns:StatusCode"/>
     <xsd:element name="fileProperties" minOccurs="0" maxOccurs="unbounded" type="tns:FileProperties"/>
     <xsd:element name="id" type="xsd:string"/>
     <xsd:element name="messages" minOccurs="0" maxOccurs="unbounded" type="tns:RetrieveMessage"/>
     <xsd:element name="status" type="tns:RetrieveStatus"/>
     <xsd:element name="success" type="xsd:boolean"/>
     <xsd:element name="zipFile" type="xsd:base64Binary"/>
    </xsd:sequence>
   </xsd:complexType>

to:

<xsd:complexType name="RetrieveResult">
    <xsd:sequence>
     <xsd:element name="fileProperties" minOccurs="0" maxOccurs="unbounded" type="tns:FileProperties"/>
	 <xsd:element name="id" type="xsd:string"/>
     <xsd:element name="messages" minOccurs="0" maxOccurs="unbounded" type="tns:RetrieveMessage"/>
	 <xsd:element name="zipFile" type="xsd:base64Binary"/>
    </xsd:sequence>
   </xsd:complexType>

All Answers

Daniel Gonzalez TorresDaniel Gonzalez Torres
Found a workaround: I manipulated the metadata.xml (wsdl) and changed the RetrieveResult to the old version.

Changed from:

<xsd:complexType name="RetrieveResult">
    <xsd:sequence>
     <xsd:element name="done" type="xsd:boolean"/>
     <xsd:element name="errorMessage" minOccurs="0" type="xsd:string"/>
     <xsd:element name="errorStatusCode" minOccurs="0" type="tns:StatusCode"/>
     <xsd:element name="fileProperties" minOccurs="0" maxOccurs="unbounded" type="tns:FileProperties"/>
     <xsd:element name="id" type="xsd:string"/>
     <xsd:element name="messages" minOccurs="0" maxOccurs="unbounded" type="tns:RetrieveMessage"/>
     <xsd:element name="status" type="tns:RetrieveStatus"/>
     <xsd:element name="success" type="xsd:boolean"/>
     <xsd:element name="zipFile" type="xsd:base64Binary"/>
    </xsd:sequence>
   </xsd:complexType>

to:

<xsd:complexType name="RetrieveResult">
    <xsd:sequence>
     <xsd:element name="fileProperties" minOccurs="0" maxOccurs="unbounded" type="tns:FileProperties"/>
	 <xsd:element name="id" type="xsd:string"/>
     <xsd:element name="messages" minOccurs="0" maxOccurs="unbounded" type="tns:RetrieveMessage"/>
	 <xsd:element name="zipFile" type="xsd:base64Binary"/>
    </xsd:sequence>
   </xsd:complexType>


This was selected as the best answer
zspacekcczspacekcc
For anyone else that might come here looking for an answer, I figured out what causes this.
I had places in my code that were still referencing API 29. In particular I had:
  
RetrieveRequest retrieveRequest = new RetrieveRequest();
retrieveRequest.setApiVersion(29.0);
If I'm not mistaken, because the request was defined as API 29.0, the responce was given in API 29.0 format, which is different then API 31.0+. When the wsc parser tries to parse it, it tries to hold the responce against validation for whatever API version it was compiled for, which is why the exception starts at the verifyTag method within the wsc.
Updating to API 33.0 throughout my application fixed the issue.