Condições sobre o dado

Sem condição, uma Coleta empurra tudo o que coleta para todos os destinos, e o “Encaminhar Resposta” de uma Entrega faz o mesmo com a resposta. A condição decide pelo conteúdo: só encaminhe se a temperatura passar de 80, só mande ao MES a nota que o SAP aceitou, abra uma nota de PM se o status for diferente de OK e a máquina estiver ligada.

Uma condição é escrita uma vez, no mesmo editor, e serve a três lugares:

Como se escreve

Uma condição é uma ou mais regras, combinadas com E (todas precisam valer) ou OU (basta uma):

O botão ao lado do campo sugere caminhos em três grupos: Da última mensagem (com o valor lido), Parâmetros de Entrada e Do Contrato Observado — os campos das mensagens reais daquela Coleta ou das respostas daquela Entrega, ver Contrato Observado. Dá para digitar qualquer outro.

O que vale saber sobre a comparação

• Número compara como número. "100" > "80" é verdadeiro, mesmo com os dois como texto no JSON. Vírgula decimal vale: 80,5 é oitenta e meio.
• Campo ausente não é maior nem igual a nada, mas é diferente de tudo, e conta como vazio.
• Variável é por Aplicação. {{LIMITE_TEMP}} resolve com a Variável da Aplicação da Coleta (ou da Entrega) quando existe, e a Global quando não. É assim que cada máquina tem o seu limite com uma regra só. Uma Variável que não existe não vira “limite zero”: a comparação falha.
• mudou não dispara na primeira leitura — não há com o que comparar. A última leitura de cada campo fica guardada e sobrevive a reinício. Salvar a Coleta, a Entrega ou o alerta recomeça essa memória.

Parâmetros de Entrada — input.

O campo normal lê o dado: a leitura da Coleta, ou a resposta da Entrega. Para decidir pelo que quem chamou mandou, use o prefixo input. com o nome do Parâmetro de Entrada: input.sendToMES igual a true encaminha ao MES só as chamadas que pediram isso.

• O parâmetro aparece na hora. O grupo Parâmetros de Entrada vem das linhas do formulário: o parâmetro recém-adicionado já é oferecido, antes de salvar e antes de haver mensagem.
• O prefixo separa os dois. Se o dado também tiver um campo sendToMES, sendToMES lê o dado e input.sendToMES lê o parâmetro.
• Coleta agendada não tem parâmetros: ninguém chamou. Ali input.<nome> é campo ausente — e, numa Coleta sem Parâmetros de Entrada, input.x continua sendo um caminho comum no dado.
• Mensagens coletadas antes desta versão não guardaram os parâmetros: para elas, input.<nome> é ausente.

Testar com a última mensagem

O botão Testar com a última mensagem, no editor, avalia a condição que está na tela — mesmo sem aplicar — contra o dado real mais recente: a última leitura da Coleta, ou a última resposta da Entrega. O resultado mostra se atende e, regra por regra, o valor lido e o esperado, além do dado. Nada é gravado. O botão aparece depois que a Coleta ou a Entrega foi salva uma vez; mensagens do Banco de Testes ficam de fora. Os Parâmetros de Entrada daquela mensagem entram entre os campos, como input.<nome>, com o valor recebido.

Encaminhamento condicional

Em cada linha de Encaminhar Coleta (na Coleta) e de Encaminhar Resposta (na Entrega), o botão Regras, no início da linha, abre o editor. Quando há condição, ele fica azul e mostra quantas regras ela tem; o resumo aparece no tooltip.

• Sem condição, o destino recebe tudo — como sempre foi.
• Condição verdadeira: encaminha, com o Transformador do encaminhamento como de costume.
• Condição falsa: aquele destino não recebe, e fica o rastro do motivo.

A condição olha o dado cru, antes do Transformador: a regra fala da leitura, não do formato do destino.

Quando nenhum destino da Coleta atende, a mensagem termina Processada — foi a regra que decidiu, não é erro. Na Entrega, a mensagem já terminou quando o destino respondeu; a condição só decide o que segue adiante.

Um uso típico na Entrega: a BAPI devolve RETURN.TYPE. Com RETURN.TYPE igual a S no encaminhamento para o MES, só a nota aceita pelo SAP segue; a recusada fica com o motivo na mensagem.

Alerta Condição Atendida

Em Alertas, o tipo Condição Atendida vale para uma Coleta e tem, além dos destinatários e canais de sempre:

Sem avalanche

Um MQTT publicando a cada segundo com a temperatura alta abriria uma nota por segundo. O alerta dispara na passagem de falso para verdadeiro, e fica quieto enquanto a condição continuar valendo. Quando ela deixa de valer, sai o aviso Condição Normalizada, e a próxima passagem dispara de novo.

A duração mínima é conferida a cada nova leitura: não há relógio próprio. Uma fonte que para de publicar não completa a duração.

Separar por

Uma Coleta que traz vários equipamentos — uma linha por forno, a cada ciclo — com um estado só alternaria “atendida” e “normalizada” a cada ciclo: o forno 2 acima do limite e o forno 1 abaixo se desmentiriam. Com Separar por equipamento, cada forno tem o seu estado: dispara quando ele passa do limite e normaliza quando ele volta. A mensagem e o chamado trazem o valor — Condição atendida na Coleta “FORNO_01” (equipamento = forno-2).

Escolha um campo que identifique a coisa monitorada, e não a leitura: um id de mensagem ou um horário criaria um estado por leitura.

Chamado

O alerta abre chamado nos destinos de Help Desk como qualquer outro, e o corpo do destino pode usar o dado que disparou: {{dado.equipamento}}, {{dado.tags.Status}}. É o que permite abrir a nota de PM no equipamento que veio na leitura.

Cada passagem abre o seu chamado — e, separado por chave, cada equipamento o seu. A trava de “um chamado por vez” dos outros alertas não se aplica aqui: com ela, a nota do forno 2 esperaria a do forno 1.

O que não dispara

• Mensagem de teste (Banco de Testes): o encaminhamento condicional é avaliado e mostrado, mas o alerta não dispara.
• Reenvio de uma leitura antiga: reenviar não abre nota de novo.
• Coleta só de consulta, que devolve o resultado a quem chamou e não encaminha.