2015-04-14 146 views
0

我們爲各種客戶建立了一個處理亞馬遜供稿的系統。這是工作了很多客戶和我們成功地處理這樣的反饋:處理亞馬遜MWS供稿響應

<AmazonEnvelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="amzn-envelope.xsd"> 
    <Header> 
     <DocumentVersion>1.02</DocumentVersion> 
     <MerchantIdentifier>REDACTED_8055</MerchantIdentifier> 
    </Header> 
    <MessageType>ProcessingReport</MessageType> 
    <Message> 
     <MessageID>1</MessageID> 
     <ProcessingReport> 
      <DocumentTransactionID>1016539</DocumentTransactionID> 
      <StatusCode>Complete</StatusCode> 
      <ProcessingSummary> 
       <MessagesProcessed>218</MessagesProcessed> 
       <MessagesSuccessful>218</MessagesSuccessful> 
       <MessagesWithError>0</MessagesWithError> 
       <MessagesWithWarning>0</MessagesWithWarning> 
      </ProcessingSummary> 
     </ProcessingReport> 
    </Message> 
</AmazonEnvelope> 

然而,一個客戶正在恢復這樣的飼料響應:

<AmazonEnvelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="amzn-envelope.xsd"> 
    <Header> 
     <DocumentVersion>3.00</DocumentVersion> 
     <MerchantIdentifier>REDACTED_43183</MerchantIdentifier> 
    </Header> 
    <MessageType>ProcessingReport</MessageType> 
    <Message> 
     <MessageID>1</MessageID> 
     <ProcessingReport> 
      <ProcessingReportType>Inventory</ProcessingReportType> 
      <DocumentTransactionID>10460738</DocumentTransactionID> 
      <Summary MarketplaceName="All"> 
       <StatusCode>Complete</StatusCode> 
       <ProcessingSummary> 
        <MessagesProcessed>1</MessagesProcessed> 
        <MessagesSuccessful>1</MessagesSuccessful> 
        <MessagesWithError>0</MessagesWithError> 
        <MessagesWithWarning>0</MessagesWithWarning> 
       </ProcessingSummary> 
      </Summary> 
     </ProcessingReport> 
    </Message> 
</AmazonEnvelope> 

不失敗解組。請注意細微差別:DocumentVersion不同,並且processingSummary嵌入在架構不期望的摘要標記內。後者會殺死JAXB解組過程。我找不到任何文件說明爲什麼發生這種情況,並希望以前有人遇到過這種情況。

我甚至不能告訴JAXB忽略未知元素,因爲我需要ProcessingSummary並將它埋在奇怪的「Summary」標記下。

有誰知道爲什麼一個客戶會得到一種類型的飼料反應,另一個會得到一個不同的飼料反應?

+0

那麼,你的問題到底是什麼?爲什麼亞馬遜向其中一個客戶提供不同的XML?很顯然,這是一個不同的模式,所以沒有突出的JAXB不能用1.02類解組3.00。 – lexicore

+0

是的,我的問題是,「爲什麼亞馬遜向不同的客戶提供不同的XML?」我將編輯該問題以反映這一點。 – IcedDante

回答

0

亞馬遜的賣家專業賬戶存在不同的版本。長期以來以特殊協議價格與亞馬遜合作的賣家可能擁有從未升級到最新API的傳統賬戶。我只需要代表賣家與亞馬遜聯繫,讓他們的賬戶升級。

在這種情況下,賣家仍然能夠保持與亞馬遜的利潤豐厚的談判利率,但我不能保證永遠都是如此。

+0

相關知識,感謝您的更新 – drzaus

1

我知道這不是一個很大的答案,但基於我有機會通過一些市場 - 特別是中國 - 工作的機會有所不同,對於不同的請求有一點不同,因爲他們可能具有不同的功能或所需的信息。下面的鏈接可以幫助你指出一個更好的方向發展:

http://docs.developer.amazonservices.com/en_US/feeds/Feeds_Overview.html#Feeds_EU_Global_Seller

我同意這是奇怪的是,同樣的請求將產生不同的結果。我只使用.NET client library for Feeds so far,而不是手動解析XML,但是當提交到錯誤的服務url時,我確實遇到了錯誤反序列化的問題。在查看源代碼(上面的鏈接)後,我注意到他們使用了兩種正則表達式匹配變體,在未能反序列化爲「預期的」ErrorResponse對象後嘗試抓取錯誤代碼/消息。原因是我不小心向Orders端點(而不是Feed端點)發出請求,錯誤XML細微差別,所以甚至沒有匹配正則表達式,因此我甚至沒有收到有用的錯誤消息背部。

我提到這一切的原因是:

  1. 什麼市場越來越不同的結果?你會發送到錯誤的端點嗎?
  2. 也許作爲使用JAXB的回退,您也可以使用正則表達式或xpath或字符串匹配來獲取相關部分。
+0

嗨,感謝您的反饋。我實際上從亞馬遜那裏聽到這個消息,答案是不同的。我現在會公佈細節。 – IcedDante