我们为各种客户设置了处理Amazon Feed的系统。这适用于很多客户,我们成功处理了这样的Feed:
<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>
但是,有一位客户正在收回这样的Feed响应:
<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嵌入在架构不期望的Summary标记内。后者杀死了JAXB Unmarshalling流程。我无法找到有关为什么会发生这种情况的任何文档,并希望此处有人遇到此问题。
我甚至不能告诉JAXB忽略未知元素,因为我需要ProcessingSummary并将其隐藏在奇怪的&#34;摘要&#34;标签
有谁知道为什么一个客户会得到一种类型的Feed响应而另一个客户会得到另一种不同的响应?
答案 0 :(得分: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时,我确实遇到了错误反序列化的问题。在查看了源代码(上面的链接)之后,我注意到他们正在使用两种正则表达式匹配的变体来尝试在未能反序列化到&#34;期望的&#34;之后获取错误代码/消息。 ErrorResponse对象。结果是因为我不小心向Orders端点(而不是Feeds端点)发出请求,错误XML略有不同,因此甚至不匹配正则表达式,因此我甚至没有得到一个有用的错误消息。
我提到这一切是因为:
答案 1 :(得分:0)
亚马逊的卖家专业版账号存在于不同的版本中。长期以特殊协商价格与亚马逊合作的卖家可能拥有从未升级到最新API的旧帐户。我只需代表卖家联系亚马逊就可以升级他们的帐户。
在这种情况下,卖方仍然能够保持与亚马逊的利润丰厚的协商价格,但我无法保证总是如此。