My Geocode

Migração

Como migrar uma automação do Zapier ou do Make para um novo host de geocodificação

· 3 min de leitura · My Geocode · #zapier#make#automation#no-code#geocoding#migration

Automações criadas no Zapier ou no Make muitas vezes incluem uma etapa de geocodificação escondida em um fluxo maior: um novo lead chega por um formulário, o endereço dele é geocodificado para verificar a atribuição de território, e o resultado dispara uma decisão de roteamento mais adiante na cadeia. Esses fluxos são frequentemente criados por alguém sem formação em engenharia de software, usando o conector pronto ou o módulo HTTP genérico que a plataforma oferecia na época, o que muda a cara de uma migração em comparação com um código personalizado.

Se a sua etapa de geocodificação atual usa um conector dedicado, uma integração oficial criada pelo Zapier ou pelo Make especificamente para o provedor em questão, migrar para um provedor sem um conector dedicado equivalente significa trocar essa etapa por um módulo HTTP ou de webhook genérico, configurado para chamar diretamente a API do novo provedor. Essa é uma mudança real na forma como a automação é construída, e não apenas uma troca de credenciais, e vale a pena testar a etapa substituta a fundo em um cenário de teste isolado antes de mexer em uma automação ativa, de produção, da qual outras partes do negócio dependem.

Passos específicos para fazer essa troca:

  1. Duplique a automação existente no editor da plataforma em vez de editá-la diretamente, para que a versão que funciona continue rodando até a versão substituta ser totalmente testada
  2. Substitua a etapa de geocodificação por um módulo HTTP genérico, configurado com o endpoint e a autenticação do novo provedor, já que uma chave em parâmetro de consulta ou um cabeçalho Authorization: Bearer (ambos suportados aqui) são simples de configurar em um módulo HTTP genérico, sem precisar de um conector dedicado
  3. Mapeie os campos da resposta manualmente na etapa de mapeamento de dados da automação, já que um módulo HTTP genérico retorna os dados brutos da resposta, que precisam ser mapeados explicitamente para os campos que as etapas seguintes da automação esperam, ao contrário de um conector dedicado, que muitas vezes faz esse mapeamento automaticamente
  4. Teste com uma variedade de entradas reais, incluindo casos extremos como endereços parciais ou formatação incomum, já que esse é exatamente o tipo de teste fácil de pular em uma ferramenta no-code, em que o próprio "código" não fica visível para revisão como ficaria em um script
  5. Troque o gatilho da versão de teste para a automação duplicada e verificada e só então desative a original, depois de confirmar que a nova está funcionando corretamente com dados reais por um curto período

Como um host de compatibilidade reproduz exatamente o formato de resposta de um provedor conhecido, se a etapa de geocodificação da sua automação original chamava um provedor que tem um host de compatibilidade correspondente aqui, o mapeamento de campos do passo 3 acima pode ser bem parecido com o mapeamento que o seu conector original já usava internamente, o que pode encurtar bastante esta migração. A lista completa de hosts de compatibilidade está em /compatibility/, e vale a pena consultá-la antes de supor que é necessário um mapeamento de campos do zero.

Para uma automação crítica para o negócio, a cautela extra de testar em uma cópia em vez de editar a versão ativa compensa o pouco tempo a mais de configuração, já que uma automação de roteamento de leads quebrada costuma ser percebida rapidamente, e por pessoas de fora da equipe técnica.

Mais em Migração