2015-04-14 116 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