Estabelecer regras comerciais

As regras comerciais são partes da lógica personalizada, utilizadas para ampliar a solução FSM para casos específicos do cliente. A lógica padrão no FSM é descrita como "monólito" e não pode ser modificada. Por isso, as regras comerciais só podem ser executadas além ou além da lógica padrão FSM. As regras comerciais são criadas no nível da empresa e executadas dentro desse contexto.

Antes de uma regra comercial ser executada, ela precisa ser acionada por algo. Esse acionador pode ser um evento específico ou uma programação predefinida. Os eventos específicos podem, por exemplo, se referir a modificações no banco de dados da empresa, entradas de um sistema integrado ou eventos publicados por microsserviços FSM.

Após a regra comercial ter sido acionada, os dados são coletados, as condições são verificadas e as ações são executadas.

As regras comerciais podem ajudar a automatizar processos empresariais. Exemplos específicos de casos de utilização para regras comerciais incluem:

• Enviar notificações, SMS ou e-mail
• atribuir um workflow a uma atividade
• anexar Smartforms a atividades
• gerar relatórios
• criar atividades subsequentes
• chamar agendamento automático

Cada empresa FSM vem com várias regras de negócios incorporadas e de amostra/demonstração. As regras incorporadas podem ser ativadas como estão ou servir de exemplos para suas próprias ampliações.

As regras comerciais (BRs) podem ser encontradas na guia correspondente na página Empresa. A lista de regras comerciais pode ser pesquisada, ordenada e filtrada. A partir daqui, os BRs podem ser ativados ou desativados, criados ou excluídos e carregados ou baixados.

Você pode modificar uma regra comercial de amostra processando uma das regras existentes ou criar uma a partir do zero utilizando o botão Criar. Recomenda-se utilizar a regra comercial de amostra como base para iniciar o customizing do FSM para seu caso empresarial.

As partes primárias de uma regra comercial são as configurações principais, a seção do acionador e a seção de ação. Essas partes podem ser descritas da seguinte forma:

Configurações principais: esta seção contém o código, o nome e a descrição da regra comercial. Ele também contém códigos para ativar a regra comercial e se as execuções ignoradas devem ser registradas em log. Por fim, ela contém informações sobre o status do estado da regra comercial e a(s) pessoa(s) de contato técnica que deve(m) ser informada(s) se a regra comercial estiver em um estado de estado crítico.

Acionador: nesta seção, você define o evento que ativa a regra comercial. Ele inclui o tipo de objeto de dados, as variáveis, condições e outros parâmetros para a regra comercial. Quando as condições forem cumpridas, a aplicação irá responder executando a ação indicada na seção de ação.

Ação: nesta seção, você define a resposta da aplicação ao evento indicado na seção acionador. Por exemplo, se você tiver indicado na seção acionadora um evento que ocorre na criação de objeto para um chamado de serviço, na seção de ação, você pode selecionar Ação e Enviar SMS e ter a notificação enviada a um destinatário específico.

As configurações principais para regras comerciais estão descritas abaixo.

• Código: Isto é opcional. Ele pode ser utilizado como um identificador da regra comercial. A melhor prática é manter isso curto.
• Nome: o nome da regra comercial.
• Descrição: uma descrição da regra comercial. A marcação simples pode ser codificada manualmente, por exemplo, para quebras de linha, fonte em negrito ou marcadores.
• Ativado: uma opção sim ou não. Em caso afirmativo, a regra comercial estará ativa.
• Contato técnico: incluirá endereços de e-mail das pessoas de contato para questões técnicas sobre a definição/execução da regra comercial. É recomendado que você adicione vários contatos técnicos. A pessoa listada, ou pessoas, também será o ponto de contato para o suporte da SAP caso a regra de negócio esteja causando uso excessivo de recursos ou outros problemas no servidor.
• Porcentagem do valor limiar de erro: este campo permite que um usuário ajuste o valor limiar, em porcentagem, no qual os contatos técnicos de uma regra comercial são informados sobre regras comerciais com execuções falhadas. Se o campo for deixado em branco, será aplicado um padrão de 50%.
• Log execuções ignoradas: opção sim ou não. Em caso afirmativo, as execuções ignoradas serão exibidas no log de execução, que pode ser acessado na visão de atualização. O número de logs de execução ignorados está limitado às últimas 100 entradas de log ignoradas por regra comercial. As mais antigas são eliminadas automaticamente por meio da configuração da empresa SAP.FSM.BusinessRules.MaxSkippedLogsToKeep. Nesta configuração, você pode definir outro limite - mas com um máximo absoluto de 1000.
• Tipo: atualmente, existem dois tipos de regras de negócios suportadas:
  • Tipo Dois: Este tipo de regra de negócio oferece suporte Javascript completo.
  • Tipo três: esse tipo de regra de negócios é baseado na nova arquitetura de microsserviço e suporta vários tipos diferentes de variável, evento e ação quando comparado com as regras de negócios do tipo dois. Sempre que possível, é aconselhável utilizar o Tipo Três. Para obter detalhes, consulte a documentação mais recente.

• Eventos: o evento que aciona a regra comercial. As opções para objetos incluem o seguinte:
  • Eventos baseados em CRUD para um determinado objeto de dados (criar, atualizar, excluir ou uma combinação dos mesmos). Acionadores deste tipo:
    • Em Criação de objeto: se selecionado, a regra comercial será acionada na criação de um novo objeto.
    • Na criação ou atualização do objeto: se selecionada, a regra comercial será acionada na criação de um novo objeto ou na atualização/modificação de um objeto existente.
    • Na atualização de objeto: se selecionada, a regra comercial será acionada na atualização/modificação de um objeto existente.
    • Em Atualização ou exclusão de objeto: se selecionada, a regra de negócios será acionada quando um objeto existente for atualizado ou excluído.
    • Na exclusão do objeto: se selecionada, a regra de negócios será acionada quando um objeto existente for excluído.
    • No Upload de objeto do conector ERP: se selecionada, a regra de negócios será acionada quando os dados do objeto (por exemplo, parceiro de negócios) forem carregados usando o Conector ECC Proaxia.
  • Programado: se selecionado, a regra de negócios será definida para ser executada nos horários e intervalos especificados.
  • Eventos FSM: os eventos do Field Service Management são eventos comerciais, que são publicados por serviços do SAP Field Service Management caso tenha ocorrido uma ocorrência relacionada.
• Tipo de objeto: o objeto de transferência de dados (DTOs) associado ao evento. Para uma análise mais detalhada desses DTOs, consulte o modelo de dados.
• Ordem: a ordem na qual as regras de negócios são executadas quando acionadas pelo mesmo evento.
• Execução:
  • Assíncrono (ocorre após a sincronização com o aplicativo cliente).
  • Síncrono (ocorre durante a sincronização com o aplicativo cliente). As regras comerciais síncronas são usadas em combinação com uma ação de validação e podem causar atrasos na sincronização com apps de cliente (por exemplo, móveis).
• Atrasar execução (seg.): você pode definir uma regra comercial a ser executada com um atraso de até 600 segundos. Somente regras comerciais com o tipo de execução "assíncrono" podem ser atrasadas, excluindo regras comerciais programadas. Considere o seguinte antes de usar um atraso:
  • Uma regra comercial só será executada quando a duração de um atraso for atingida.
  • Uma vez que o atraso só define a duração mínima que precisa ser alcançada, pode ser que a execução assíncrona de uma regra comercial seja mais atrasada do que o definido.
  • Se existirem regras comerciais acionadas pelo mesmo evento (ou seja, a atualização de uma atividade) e definidas com atrasos diferentes, não é garantido que a ordem de execução será baseada na duração dos atrasos definidos.
  • Para garantir que as regras comerciais sejam executadas em uma ordem específica, uma alternativa melhor é utilizar o campo da ordem.
  • Se você combinar usando um atraso e uma ordem em regras comerciais acionadas pelo mesmo evento, a ordem só será considerada para as regras definidas com o mesmo atraso. Isso garante que essas regras sejam acionadas no mesmo momento e, em seguida, a ordem correta das regras pode ser considerada. O sistema não consegue considerar a ordem das regras acionadas em momentos diferentes devido a diferentes atrasos.
  • Em geral, recomenda-se usar atrasos com cautela. As execuções atrasadas colocam uma carga adicional no sistema, o que pode ter um impacto na performance do sistema.
• Cláusula CoreSQL WHERE: esse campo será exibido quando o tipo de evento for "programado". Recomenda-se a utilização deste campo para determinar os objetos para os quais a regra deve ser executada. Para cada registro de objeto encontrado, as variáveis e condições serão resolvidas e as ações executadas de modo correspondente.
• Frequência: este campo aparecerá quando o tipo de evento for "agendado". Aqui, você pode inserir a frequência com que a regra comercial deve ser acionada quando as condições são cumpridas.

Hora da ação acionada: o sistema permite que você acione uma regra comercial programada até 4 vezes por hora (XX:00, XX:15, XX:30, XX:45).

A execução de regras empresariais é otimizada para preservar melhor os recursos do servidor (CPU, memória, etc.).

Frequência e tempo de execução: dependendo do subconjunto de dados a serem processados e das ações definidas em uma regra comercial, o tempo de execução varia de uma regra para outra. Para proteger os recursos do sistema Cloud, a execução de uma regra comercial pode ser ignorada. Isso pode acontecer quando a mesma regra é acionada para execução enquanto a execução da regra anterior ainda está sendo executada.

Para evitar isso, a programação da regra comercial deve ser configurada para que [TriggerTime]+[ExecutionTime] não cumpra a [TriggerTime] seguinte.

Para evitar que as ações definidas não sejam executadas devido a uma regra comercial ignorada, é vivamente recomendado definir as condições acionadoras de modo que as condições acionadoras não possam ser influenciadas por outro processo. Em outras palavras, as condições de acionamento devem ser cumpridas a qualquer momento, desde que as ações desejadas das regras comerciais não sejam executadas.

Se uma frequência for definida para uma regra comercial com uma condição, ela será executada na frequência indicada quando a regra for acionada.

As variáveis são utilizadas para ler dados necessários para a execução adequada da regra comercial. Os dados em variáveis podem ser usados em Variáveis, Condições e Ações subsequentes.

Uma variável consiste em uma consulta no CoreSQL (igual à API de consulta), funções Javascript ou uma combinação das mesmas. Os valores das variáveis são resolvidos durante a validação e execução da regra. Depois que uma variável foi definida resolvida, a variável e suas propriedades podem ser referidas usando javascript. Por exemplo, ${activity.code} refere-se ao campo "código" de uma variável definida anteriormente chamada "atividade".

Algumas variáveis são predefinidas e se referem ao seguinte:

• O objeto acionador relevante
• Dados do objeto ‘antigo’ vs. ‘novo’
• O usuário atual, Empresa e Conta

As configurações da empresa e as configurações do usuário são acessadas pelas variáveis ${company.settings} e ${user.settings}. Por exemplo, para recuperar o idioma que o usuário definiu no aplicativo da Web, use ${user.settings.Cockpit_SelectedLanguage.data}.

As variáveis personalizadas podem ser definidas da seguinte forma:

• Objeto: um registro individual de um determinado tipo
• Array: permite a seleção de muitos objetos individuais usando uma consulta complexa
• Valor: geralmente consistindo de uma cadeia de texto/valor com programação incondicional ou de outra forma definida por uma função javascript que é resolvida durante a execução.

As variáveis de objeto e matriz são especificadas pelo seguinte:

• Tipo de objeto (DTO)
• Versão do objeto
• Cláusula CoreSQL WHERE ou uma consulta CoreSQL completa.

No modo de consulta avançada, consultas CoreSQL complexas podem ser definidas. Para acessar o modo avançado, pressione o ícone de chave inglesa. Ao usar o modo avançado, todos os tipos de objeto e suas versões devem ser definidos explicitamente, por exemplo, Activity.40;ServiceCall.26. Todas as consultas definidas podem ser inspecionadas e executadas na interface API de consulta utilizando o ícone de triângulo.

A consulta CoreSQL ou a cláusula -WHERE pode conter snippets de código javascript, contidos entre parênteses: ${ ... }

As variáveis de valor podem conter, por exemplo, uma string de texto, um snippet de código Javascript ou similar.

Objetos e campos personalizados (também conhecidos como objetos e campos definidos pelo usuário) são suportados. Eles podem ser referenciados em variáveis (usando a cláusula WHERE), condições e ações para todos os objetos disponíveis.

As condições são definidas com operadores lógicos e relacionais integrados e podem comparar o seguinte:

• Variáveis e suas propriedades
• Cadeias de texto
• Números
• Valores booleanos
• Funções JavaScript

As condições são avaliadas após a resolução das variáveis. Em seguida, se todas as condições forem cumpridas, as ações serão executadas. Contudo, se uma das condições não for cumprida, a execução da regra comercial é ignorada.

Ignorar muitas execuções de regras comerciais ainda custa recursos do sistema, porque o BR ainda reagiu ao evento/acionador, resolveu as variáveis e verificou as condições.

Uma regra comercial pode executar até 100 ações que são executadas em sequência se as condições da regra comercial forem cumpridas. Existem muitos tipos diferentes de ações, cada um com seus próprios parâmetros de entrada específicos. Os parâmetros de entrada são preenchidos com dados das variáveis, funções JavaScript, valores com programação incondicional, etc.

Alguns exemplos de ação estão listados abaixo.

• Webhook/FSM: essas ações retornam uma variável de resposta, que pode ser usada em ações subsequentes.
• Executar operação condicional: consiste em uma condição que determina se a ação subsequente é executada ou ignorada.
• Criar/atualizar/excluir objeto: objetos personalizados são suportados e referenciados no campo de tipo de objeto.
• Criar relatório de lista de verificação: para cada instância de lista de verificação fechada na atividade selecionada, o aplicativo gerará um relatório e o anexará à atividade.
• Validar: usado em regras de negócios síncronas para impedir que algo aconteça antes de confirmar os dados correspondentes no banco de dados. Por exemplo, um cliente móvel/web sincronizando alguns dados novos ou alterados.

As ações de webhook do FSM são limitadas a APIs que exigem autenticação FSM. Uma vantagem dessa ação é que você não precisa mais definir uma ação de webhook explícita para determinar um token de autorização para OAuth2. Você só precisa inserir o ID e a chave secreta do cliente para garantir que as credenciais adequadas sejam utilizadas.

Na seção Variável, o código será composto principalmente pelo CoreSQL, a fim de coletar os dados relevantes. Em toda a regra de negócios, incluindo dentro das consultas CoreSQL, o Javascript pode ser usado: independentemente ou para referenciar e manipular dados contidos em Variáveis previamente definidas. Tudo entre um sinal de dólar e colchetes é interpretado como JavaScript ${..}. As funções JavaScript devem ser baseadas no padrão ECMAScript 6.0.

Depois de ter concluído as seções de acionador e ação da regra comercial, você pode selecionar Salvar. A aplicação só valida para campos obrigatórios, por isso uma regra comercial salva com êxito não indica automaticamente que a regra comercial é válida. No entanto, o registro será salvo e você pode modificar a regra comercial conforme necessário até que ela seja válida.

Para ajudar a garantir que a regra empresarial funcionará como previsto, é necessário validá-la. A função de validação permite a você simular a execução da regra comercial e ver como as variáveis estão sendo resolvidas. Além disso, a função de validação verifica se a sintaxe básica da sua regra está correta. No entanto, quaisquer chamadas API não são executadas e os resultados não são confirmados para o banco de dados.

Para ir para a tela Validação, selecione Validar. Na tela de validação, você precisa indicar os dados de entrada necessários. Normalmente, isso significa selecionar um registro de objeto relevante do banco de dados. Um popup suporta o usuário na seleção de um objeto, exibindo uma lista de possíveis IDs de objeto. No entanto, normalmente é necessário encontrar primeiro um objeto relevante com API de consulta, de modo que as características relevantes sejam conhecidas e o comportamento da regra comercial possa ser simulado de modo correspondente. O campo de pessoa pode ser usado para avaliar o impacto das permissões do usuário ou quando as configurações do usuário e outros dados são relevantes.

Quando os dados necessários tiverem sido inseridos, selecione Validar. Durante a validação, todas as variáveis na regra comercial serão resolvidas e exibidas na tela. Os snippets JavaScript serão executados e substituídos pelos seus resultados/saída. Os erros levam a uma interrupção do processo e serão exibidos na parte superior da tela.

Após a validação com êxito, a próxima etapa é executar a regra comercial manualmente, em um ambiente de teste. Para ir para a tela de execução manual, selecione Executar.

Tal como durante a validação, você precisa selecionar os dados de entrada relevantes. Quando isso for efetuado, selecione Executar.

Ao contrário da validação, a função de execução manual não exibe as variáveis resolvidas. Além disso, todas as ações são efetivamente executadas e os resultados são confirmados no banco de dados. Dependendo da sua regra comercial específica, a execução pode ser avaliada verificando o log de execução, o banco de dados ou na IU da Web.

Depois de a regra comercial ter sido testada com êxito no modo manual, você pode ativar a regra comercial. Isso torna a execução da regra comercial completamente automática, de acordo com as configurações do acionador.