Diogenes Lima

Members
  • Content Count

    159
  • Joined

  • Last visited

  • Days Won

    26

Diogenes Lima last won the day on April 2

Diogenes Lima had the most liked content!

3 Followers

About Diogenes Lima

  • Rank
    Jedi Master

Recent Profile Visitors

668 profile views
  1. Não é jeitinho brasileiro. O correto é não alterar mesmo. Uma venda deve ter os dados do anúncio no momento da venda e não permitir a alteração se o anúncio original for alterado. Já pensou se toda venda tivesse o valor alterado cada vez que você alterasse o preço do anúncio?
  2. Para integração com o MercadoPago apenas você deve verificar a documentação e o suporte deles diretamente. Este fórum é apenas para a integração com a API do MercadoLivre.
  3. Olha bem o que tá escrito: se você estiver trabalhando com local host poderá utilizar http. No redirect -uri você pode colocar http://localhost para testar de forma local sem problema nenhum.
  4. Só voltei a ver isso hoje. Recomendo não deixar tudo em uma mesma máquina, mas se não puder, se forem instâncias isoladas já ajuda. Só não deixe tudo em uma mesma instância Mesmo que ela seja muito parruda, os recursos ficam concorrendo entre si. Aqui eu uso servidores bem parecidos que o seu e a performance tá suave, mesmo nos picos de processamento. Processo em média 3000 notificações por minuto com picos de até 8000 por minuto e tá de boa. Sua configuração está boa pro banco. Eu separaria o front end nesta máquina de 4GB e deixaria outra instância de 4GB semelhante, para os processos de backend e cron. E esta outra instância de 1GB apenas para receber notificações do ML e colocar em uma fila. Assim ela não concorre com o front end e não prejudica o acesso dos seus usuários nos momentos de pico. Além disso, se ela ficar sobrecarregada, seus usuários não perdem o acesso. Não esqueça de ajustar o nginx com relação à memória usada, quantidade de conexões, etc. O mesmo para a máquina do banco de dados. Se possível troque o mysql pelo mariadb. Eles são compatíveis, mas o mariadb gerencia um pouco melhor a memória na minha opinião.
  5. É o id principal do seu usuário no ML. O mesmo que tem em orders no seller_id e em vários outros lugares.
  6. Aquela redução do multiget que era para o dia 31 parece que entrou hoje também para a impressão de etiquetas. Ao enviar mais de 20 ids para imprimir, vem erro que só pode enviar no máximo 20. ML sendo ML.
  7. Seu erro é porque o picture_ids de cada variação é um array e você está enviando uma única string em cada um.
  8. Parece mais problema com alguma lógica do que com o banco em si. Sua máquina parece parruda demais para ter este tipo de problema. O servidor de aplicação está separado do banco? Caso não esteja desta forma, recomendo separar o banco de dados em uma máquina única. Outra apenas para receber as notificações e outra para processar filas de notificações, por exemplo. Qual servidor de aplicação você usa? Quantas notificações você recebe por minuto aproximadamente?
  9. Isto é um bug do ML. Se o vendedor adicionou a anotação pela interface do ML, a API não irá retornar nestes casos mesmo e só aparece lá no front deles. Se você adicionar pela API, o que você adicionou aparece na API e também lá no front do ML.
  10. Acho que você precisa voltar atrás um pouco pra entender alguns conceitos mais básicos. A sua chamada de upload é para enviar somente o caminho de uma imagem já hospedada. Se você criou um curlfile, não vejo sentido chamar um json_encode para ele. Você precisa entender quais são os dados com os quais está trabalhando para entender o que pode ou não ser feito com eles. Do jeito que você fez está enviando apenas textos (strings) e por isso não funciona. Nem sempre o SDK do ML irá prover tudo que você precisa. Em alguns casos, como este, é necessário criar uma nova chamada específica para atender o que você precisa. Lembre-se também que às vezes, mesmo que o seu código consiga enviar dados em um formato, é necessário que a API esteja preparada para receber e tratar os dados no mesmo formato.
  11. Eu acho o validador desnecessário, mas de qualquer forma, você precisa interpretar o resultado do validador. Note que o tipo é "warning", ou seja, é apenas um aviso. A mensagem informa que o frete grátis obrigatório foi adicionado, ou seja, é apenas um alerta e não um erro impeditivo. É só enviar os dados do anúncio no endpoint de criação que ele será criado normalmente.
  12. Você precisa rever a documentação da API. Normalmente para criação de alguma coisa, usa-se o POST. Para alteração, usa-se o PUT. Existem casos onde a alteração não se enquadra em um PUT, pois ela é uma alteração de condição (não sei se este é o termo correto). Para alterar o listing_type você não envia os dados do anúncio nem usa a URL do anúncio e sim uma URL específica para esta alteração, enviando no ID do corpo da requisição o ID DO NOVO LISTING_TYPE. Esta informação de como alterar o LISTING_TYPE está neste link: https://developers.mercadolivre.com.br/pt_br/tutorial-tipos-de-publicacao-y-atualizacao-de-artigos Com relação ao frete, depende de várias outras condições para saber se está correto ou não e se pode ou não ser alterado.
  13. Dê mais detalhes, pois existem várias formas de "solicitar listagem" de anúncio. Dê exemplo de qual chamada está fazendo, se tem alguma pesquisa, se está usando access_token, etc.
  14. Eu acho que tem algum erro de entendimento da sua parte. Quando for criar anúncios, precisa recuperar os dados da categoria e sua estrutura de atributos. Os atributos que estiverem com tag allow_variations somente devem ser utilizados em attribute_combinations de variações. Não use-os em attributes do anúncio. Os atributos que estiverem com tag variation_atribute somente devem ser utilizados nos attributes de variações. Não use nos attributes do anúncio. Para os demais atributos que não tiverem as tags destes acima, só devem ser utilizados nos attributes do anúncio e não devem ser usados em attribute_combinations nem em attributes das variações. Seguindo estas regras, diminui a quantidade de problemas. Aí só acontece problema quando o ML altera a regra de algum destes atributos e para corrigir o problema deve revalidar os dados, de forma que estejam dentro destes regras que citei. Lembrando que para corrigir, pode ser necessário efetuar alterações em 2 passos, por exemplo, enviando attributes vazio e depois os dados corretos, ou zerando as variações e depois enviando-as da forma correta, etc. No seu caso, não faz sentido enviar todos dados como atributes, como você citou que faz. Se o anúncio é simples e está criando sem variação, não deveria enviar os dados de COLOR e SIZE em attributes, senão vai ter problema mesmo, porém para a categoria informada, se eles são obrigatórios, significa que pelo menos uma variação é obrigatória, então deve montar um attribute_combinations e enviar estes dados lá em uma variação. Pode ou não enviar mais de uma variação, desde que esteja no mesmo formato. Se quiser, depois pode adicionar outras variações, sem alterar a estrutura de attribute_combinations.
  15. Funciona sim, pq ele está limpando attributes e não variations. Mesmo se tiver variações obrigatórias, o ML aceita. O problema é que vai perder os dados de atributos e a ficha técnica ficar incompleta, precisando preencher novamente depois. Mas seu problema era ao criar um item ou ao alterar? Ao criar, sua estratégia funciona, mas não teria motivo para enviar somente uma variação se está criando, pode enviar todas que vai funcionar da mesma forma. Se o problema for na alteração, alterar enviando só uma variação ou enviando uma lista também dá no mesmo. O problema costuma ser quando o ML troca um atributo "raiz" transformando-o em atributo de variação ou id de combinação de variação, ou vice-versa. Aí só "zerando" os atributos ou variações e enviando os dados de acordo com a nova estrutura.