Pular para conteúdo

✅ RESOLVIDO em produção 2026-07-07. O fix foi aplicado no cenário 2912018 (SetVariable [92] + GetVariables [93] + filtros {{length(93.uf_guard)}}) e validado. Detalhes reais em historico.md (entrada 2026-07-07). Este arquivo fica como referência de reuso — o passo a passo abaixo serve pra refazer o padrão em outro cenário. Correção importante vs. o texto abaixo: não é limitação do Make — a referência de variável no filtro só precisa estar envelopada (length(...)), e a expressão de array precisa ser resolvida pra escalar num SetVariable antes.

Passagem de bastão — Fix do "Guard UF" (cenário Make 2912018 Pipedrive→Omie)

Você é um agente com acesso ao Make.com da Bepex. Preciso que você aplique uma correção estrutural num cenário de produção. O diagnóstico já está fechado; sua tarefa é executar a mudança e validar. Leia tudo antes de agir.

Contexto do sistema

  • Plataforma: Make.com, região US1 (https://us1.make.com), Org 115055 (Bepex).
  • Cenário: 2912018 — "Pipedrive to Omie (Instant)". Recebe orçamento do sistema BPEX (bepex.flowtech.net.br) via webhook e cria o Pedido de Venda na Omie do tenant certo (DALE/ONIX/ATARES). 44+ módulos, multi-tenant, PJ+PF.
  • Editor: https://us1.make.com/115055/scenarios/2912018/edit · Logs/History: .../2912018/logs

Sintoma

Desde 03/jul/2026 nenhum pedido cujo CNPJ tenha mais de um endereço no DateCode sobe pra Omie. As execuções aparecem como "Success" mas o módulo [57] "Cria pedido de venda sem itens" é filtrado (não roda) → pedido nunca criado. Falha silenciosa.

Causa raiz (confirmada com dado real)

No dia 03/jul foi adicionado um sub-router "Guard UF" (módulo id 91) dentro do router id 52, que decide entre: - Rota 0 → módulo [90] "⚠️ Alerta — UF Vazia" (email), filtro ... text:equal "" (UF vazia) - Rota 1 → módulo [31] "Adiciona Cliente no Omie", filtro ... text:notEqual "" (UF preenchida)

Os dois filtros usam a expressão: 

{{ifempty(33.data[].enderecos[].uf; switch(78.address_admin_area_level_1; ...27 estados...; 78.address_admin_area_level_1))}}
O problema: essa expressão, no operando de um filtro de router, é avaliada como array quando o DateCode (módulo [33]) retorna vários endereços (data[].enderecos[] com N>1). Aí text:equal "" e text:notEqual "" dão os dois falso → nenhuma rota dispara → módulo [31] não roda → variável código cliente omie fica vazia → módulo [55] (GetVariables) lê vazio → filtro do [57] {{length(55.\código cliente omie`)}} > 0` bloqueia → sem pedido.

Fato-chave: a mesma expressão funciona dentro do body do módulo [31] (contexto de mapper, colapsa pra escalar "RS"). Ela só quebra no filtro. Já foram testadas 6 variações in-filter (raw, [1], first(), trim(), join(), e a exata com switch) — nenhuma funciona no filtro, porque o Make trata array[].array[].campo de formas diferentes conforme a função e no operando cru vira array.

A correção (obrigatória: mover a expressão pra um mapper)

Inserir um módulo SetVariable logo depois do "consulta date solutions" (módulo [33]) e antes do router [91], que roda a expressão em contexto de mapper e guarda o resultado escalar; depois repontar os dois filtros do guard pra essa variável.

Passo a passo (UI do editor — mais seguro)

  1. Abra https://us1.make.com/115055/scenarios/2912018/edit.
  2. Ache o módulo "consulta date solutions" (HTTP, id 33). A saída dele vai para o router "Guard UF" (id 91).
  3. Entre o [33] e o [91], adicione um módulo Tools › Set variable (util:SetVariable2):
  4. Variable name: uf_guard
  5. Variable lifetime: One cycle (roundtrip)
  6. Variable value: cole EXATAMENTE a expressão do campo estado do módulo [31] (está no bloco "Expressão exata" abaixo).
  7. Abra o router "Guard UF" e edite os dois filtros:
  8. Rota do Alerta (módulo [90], "UF vazia — bloquear"): operando esquerdo → {{uf_guard}} (do novo módulo SetVariable), operador Equal to, valor vazio.
  9. Rota do Adiciona Cliente (módulo [31], "Estado preenchido"): operando esquerdo → {{uf_guard}}, operador Not equal to, valor vazio.
  10. Salve o cenário (o save recompila o blueprint no engine).

Alternativa via API (se preferir programático)

  • CSRF: use jQuery.ajax() (a página do Make já injeta o header a partir do cookie XSRF-TOKEN). fetch puro dá 401 (IM023).
  • GET blueprint: GET /api/v2/scenarios/2912018/blueprint → resp.response.blueprint.
  • Estrutura: router id 52 → routes[0].flow é [33, 91]. Insira o novo módulo entre eles: [33, <novoId>, 91]. Use maxId+1 (hoje 92) como id.
  • Schema do SetVariable2 (copie do módulo id 54): { id, module:"util:SetVariable2", version:1, mapper:{ name:"uf_guard", scope:"roundtrip", value:"<expr>" }, metadata:{ designer:{x,y}, expect:[{name,type,label,...}], interface:[{name:"uf_guard",type:"any",label:"uf_guard"}] } }.
  • Repointe: nos módulos 90 e 31, filter.conditions[0][0].a = "{{92.uf_guard}}" (mantenha o e b como estão: 90 = text:equal/""; 31 = text:notEqual/"").
  • PATCH: PATCH /api/v2/scenarios/2912018 com body { blueprint: JSON.stringify(bp) }, contentType application/json; charset=utf-8.
  • Recarregar o engine: POST /api/v2/scenarios/2912018/stop → espere ~1.5s → POST /api/v2/scenarios/2912018/start. (O replay usa "a versão mais recente" do cenário.)

Expressão exata (colar como valor de uf_guard — é a mesma do campo estado do módulo 31)

{{ifempty(33.data[].enderecos[].uf; switch(78.address_admin_area_level_1; "Acre"; "AC"; "Alagoas"; "AL"; "Amapá"; "AP"; "Amazonas"; "AM"; "Bahia"; "BA"; "Ceará"; "CE"; "Distrito Federal"; "DF"; "Espírito Santo"; "ES"; "Goiás"; "GO"; "Maranhão"; "MA"; "Mato Grosso"; "MT"; "Mato Grosso do Sul"; "MS"; "Minas Gerais"; "MG"; "Pará"; "PA"; "Paraíba"; "PB"; "Paraná"; "PR"; "Pernambuco"; "PE"; "Piauí"; "PI"; "Rio de Janeiro"; "RJ"; "Rio Grande do Norte"; "RN"; "Rio Grande do Sul"; "RS"; "Rondônia"; "RO"; "Roraima"; "RR"; "Santa Catarina"; "SC"; "São Paulo"; "SP"; "Sergipe"; "SE"; "Tocantins"; "TO"; 78.address_admin_area_level_1))}}

Validação (obrigatória — "Success" não prova nada)

  1. Vá em History, abra a execução 6e2233baef6345408a44adbadadb1fa1 (Instant de hoje 16:19:38, CNPJ 15092013000105, cliente em Xangri-lá/RS) e clique Replay run.
  2. Abra o log do replay e confirme nó por nó:
  3. módulo [90] "Alerta UF Vazia" = filtrado (UF presente, não deve alertar);
  4. módulo [31] "Adiciona Cliente no Omie" = completed (statusCode 200 ou 500-"já cadastrado");
  5. módulo [55] GetVariables código cliente omie = não vazio;
  6. módulo [57] "Cria pedido de venda sem itens" = completed (não filtrado).
  7. Confirme na Omie do tenant correto que o Pedido de Venda foi realmente criado.
  8. Repita o replay para a outra execução Instant de hoje (12:00:08) — está no History do mesmo cenário. Essas duas são os pedidos que precisam ser recuperados.
  9. Faça 1 replay por execução (a integração NÃO é idempotente — codigo_pedido_integracao usa timestamp; replay duplicado = pedido duplicado).

Segurança / rollback

  • Backup do blueprint já existe: <Downloads local>/blueprint_2912018_backup_2026-07-07_preGuardFix.json. Se algo der errado, PATCH de volta com esse JSON.
  • Cenário está ativo em produção. Toggle stop/start é seguro (webhook instant enfileira durante os ~2s off).

Alternativa mais simples (se não quiser mudança estrutural)

Remover o filtro do módulo [31] (deixar a rota 1 sem filtro = incondicional). O cliente passa a ser criado sempre → pedido sobe. É o comportamento pré-03/jul, que funcionava. Perde só o alerta de "UF vazia" (que hoje já está quebrado). É só edição de filtro, sem inserir módulo.