Обработка Amazon MWS Ответы на подачу

Question

Мы создали систему для обработки каналов Amazon для самых разных клиентов. Это работает для многих клиентов, и мы успешно обрабатывались каналы, как это:

<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 отличается, а обработкаSummary встроена в тег Summary, который схема не ожидает. Последний убивает процесс Unmarshalling JAXB. Я не могу найти документацию о том, почему это происходит, и надеялся, что кто-то здесь столкнулся с этим раньше.

Я не могу даже сказать JAXB игнорировать неизвестные элементы, потому что мне нужен ProcessingSummary, и он похоронен под странным тегом «Сводка».

Кто-нибудь знает, почему один клиент получит один ответ на подачу, а другой получит другой?

Answer 1

Профайлы продавца Amazon существуют в разных версиях. Продавцы, которые были с Amazon в течение длительного времени со специальными согласованными тарифами, могут иметь устаревшие учетные записи, которые никогда не обновлялись до новейшего API. Все, что я должен был связаться с Amazon от имени продавца, чтобы обновить их аккаунт.

В этой ситуации продавец все еще был в состоянии поддерживать выгодные договорные ставки, которые у них были с Amazon, но я не могу гарантировать, что это всегда будет так.

Answer 2

Я знаю, что это не очень важный ответ, но, основываясь на том, что у меня была возможность работать через некоторые из торговых площадок - в частности, в Китае, - они ведут себя по-разному для разных запросов, поскольку они могут иметь разные возможности или необходимую информацию. Следующая ссылка может помочь направить вас в лучшую сторону:

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 (а не к конечной точке Feeds), XML-код ошибки был немного отличался и поэтому даже не соответствовал регулярному выражению, и поэтому я даже не получал полезного сообщения об ошибке назад.

Я упоминаю все это потому, что:

1. Что рынке является получение различных результатов? Не могли бы вы отправить неверную конечную точку?
2. Возможно, в качестве отказа от использования JAXB вы также можете использовать регулярное выражение или xpath или сопоставление строк, чтобы захватить соответствующий раздел.