alguns dados, como marketingData, não são entregues no endpoint de OMS List

VTEX in your native language 🌎 Português
1

Olá, estamos fazendo uma integração para embarcar dados de nossos clientes em nossas plataformas de big data, e o design da api hoje torna isso extremamente custoso. Na api de OMS, onde listamos todas as ordens, não temos todos os dados necessários. Isso nos obriga a listar todas as ordens e depois consultar a api individualmente para cada ordem. Resultando em mais de 1000 chamadas à API por dia. Isso é ruim tanto para nossos servidores quanto o de vocês. Não existe uma forma de pedir ao endpoint de list para trazer os campos que escolhermos, ao invés de recebermos apenas as entregas default?

​

No nosso caso, precisaríamos do nós:

marketingData

hostname

Alguma luz?

2

Olá Thomas, algum feedback?

Estou insistindo pois você havia me dito que

"no caso não precisa se preocupar quanto às chamadas excessivas ao GET Order. Se você está fazendo isso e não há um workaround temos que ter infra necessária para aguentar as chamadas, certo?"

abcs

Pablo

3

Oi Pablo, desculpe nao responder antes (estava de férias)!

Todo pedido feito na VTEX possui dois workflows, certo? Um deles é o Marketplace e o outro o Fulfillment. Talvez essa nomencaltura confunda um pouco, mas consideramos a própria loja como um Marketplace, pois existe a feature nativa de uma loja VTEX ser um marketplace. O erro aponta para um timeout na rota do Fulfillment.

Essa mensagem de erro foi response de qual chamada, poderia compartilhar?

Olhando nossos logs, tivemos apenas 140 timeouts do fulfillment nos ultimos 30 dias. Nenhum evento relacionado com esse accountname. Acredito que esse response não está ligado ao erro, deve ser uma mensagem de um sistema intermediário. Se eu entender melhor o que seu programa está fazendo posso investigar melhor.

4

Olá tomas, muito obrigado pela resposta! Segue abaixo o cURL que estamos fazendo. Estamos buscando detalhes de ordens uma por uma, para conseguir obter os dados que precisamos.

A questão, ao que parece, é que fazemos muitas chamadas dessas simultaneamente (com ids de compra diferentes, obviamente).

curl -X GET \ http://rihappy.vtexcommercestable.com.br/api/oms/pvt/orders/v11318862rihp-01 \ -H 'accept: application/json' \ -H 'cache-control: no-cache' \ -H 'content-type: application/json' \ -H 'x-vtex-api-appkey: MINHACHAVE###' \ -H 'x-vtex-api-apptoken: MEUTOKEN###!'

5

Olá Pablo, vou levar essa sugestão pro time do OMS! Obrigado por se preocupar com a performance da VTEX :) mas no caso não precisa se preocupar quanto às chamadas excessivas ao GET Order. Se você está fazendo isso e não há um workaround temos que ter infra necessária para aguentar as chamadas, certo?

De qualquer forma vou revalidar a estrutura do LIST Orders e te retorno!

6

Olá Thomas, muito obrigado.

Minha preocupação maior na verdade é a performance dos meus servidores e dos meus clientes. :)

Na verdade a questão principal é o tempo necessário para rodar toda a rotina. O que poderia durar segundos acaba durando um bocado de tempo.

​

Se vcs puderem dar uma olhada nisso seria fantástico!

7

Então estamos alinhados!! Se a preocupação é tempo talvez o caminho seja abrir multiplas threads, ou seja, fazer a consulta de forma assíncrona. Assim não precisa chamar um pedido e depois o outro.

Para esclarecer a "limitação" de dados no JSON do List Orders, isso acontece por conta da origem dos dados. O List Order recolhe informações do SOLR (o indexador usado pela VTEX), enquanto o Get Order busca a informação de cada pedido diretamente no Checkout.

Infelizmente o SOLR é hiper sensível a mudanças como a indexação de novos campos. Vamos atualizar a versão dele em breve e possivelmente novos campos possam ser incluidos. (já está na hora de dar um up na tela inicial do OMS certo?)

8

Muito obrigado Thomas. Nós já estamos trabalhando assincronamente, mas um e-commerce "parrudo" vai ter sempre centenas e centenas de orders e invariavelmente vai tomar tempo.

​

Mas tá entendida a limitação. :)

9

Ah, e caso estejam ainda decidindo quais campos vão incluir, ia ser maravilhoso se estes abaixo estivessem incluídos :)

lastChange

hostname

marketingData

shippingData.address.state

10

Thomas, esbarramos em um grande problema:

Como estamos usando paralelismo, fazemos muitas chamadas de uma vez, uma vez ao dia (para atualizar os últimos 7 dias de dados), e estamos meio que aleatoriamente tomando um erro (500) da api vtex. Apesar da mensagem ser descritiva, não conseguimos reproduzir um padrão para evitar o erro. Esse tempo de 10 segundos é exatamente em relação a que?

​

[x-vtex-error-message] => Array ( [0] => A chamada do conector ao recurso 'pvt/orders/00-v11148408rihp-01?an=rihappy' do serviço 'http://fulfillment.vtexcommerce.com.br/api/fulfillment' atingiu o tempo limite em 10 segundos )

​