Sobre

O componente Árvore de Decisões permite aos usuários configurar e interagir com menus de contexto personalizados, atribuindo ações a serem realizadas no painel de acordo com o status de um card.

Índice

• Preparando o ambiente
  • Habilitando e Criando as Tabelas Decision Tree
  • Permissões de Acesso
  • Token de Autenticação
  • Configurações Escalation/API
• Configurações Arvore de Decisões:
  • Estrutura
    • Label
    • Menu
    • CardIcon
    • TopButton
    • Exemplo
• Entry Points
• Árvores Abertas
• Sincronismo Escalation
• Escalation X NFS
  • Autenticação
  • Integração

1. Preparando o Ambiente:

1.1 Habilitando e Criando as Tabelas Decision

Para que a funcionalidade da arvore de decisões funcione corretamente, precisamos habilitar alguns parametros na tabela nfs_core_par_parametros, sendo estes:

INSERT INTO nfs_core_par_parametros(EMPRESA, FILIAL, `LOCAL`, NOME, CONTEUDO, TIPO)
VALUES(9999, 9999, 9999, 'DECISION_TREE_ENABLED', '1', 1);

Este parâmetro é responsável por criar algumas tabelas no sistema, sendo estas:

• app_decision_tree_json: Tabela que contem os JSONs abertos cadastrados no escalation(preenchida via agendamento\scheduller);
• nfs_decision_tree_config: Tabela de configurações da arvore de decisões(menus, botão do topo, etc);
• nfs_decision_tree_n_panel: Tabela que faz o vinculo da arvore de decisões ao painel.
• nfs_decision_tree_api_log: Log de requisições feitas do Escalation para o NFS.

Após a inserção do parâmetro será necessário executar o create DS/DDL

1.2 Permissões de Acesso

Para que o icone fique disponivel para um usuario ou grupo de usuario, será necessario adicionar permissão na tabela DECISION_TREEpara os mesmos:

INSERT INTO nfs_acl_grupo_permissao(EMPRESA, FILIAL, `LOCAL`, MENU_SEQ_DB, TABELA_NOME, SIUDT, GRUPO_SEQ_DB, CAMPOS_PERMITIDOS, INS_DH, ATIVO, DELETED, SIUD)
VALUES(1, 9999, 9999, NULL, 'DECISION_TREE', '11110', 1, '', '2020-11-19 16:16:53', 1, 0, NULL);

Lembre-se de alterar o seqDb do grupo(ou usuario caso seja um insert na tabela nfs_acl_usuario_permissao) conforme a sua necessidade

1.3 Token de Autenticação

Para que as ações criadas no menu de contexto possam se comunicar com o serviço externo, será necessario gerar um token unico para cada local que vai utilizar a arvore de decisão

Para gerar o token, será necessario solicitar ao responsavel pelo serviço externo(Escaltion) uma chave unica para a FILIAL do ambiente (esta chave deverá ser registrada no campo TREE_KEY na tabela nfs_org_filial).

Pode ser necessario executar o Create DS do core para adicionar o novos campos referente ao token nas tabelas ORG

Após cadastrar essa chave, ao acessar o ADMIN CONSOLE, um usuario de nivel ADMINISTRADOR ou SUPER ADMINISTRADOR terá acesso a um novo botão no card NFS ENVIRONMENT que será responsavel pela geração do token no ambiente:

Este token ficará salvo na tabela nfs_org_local e expira após 12 horas

1.4 Configurações Escalation/API:

Essa configurações permitem alterações nas tratativas do sistema para que o ambiente fique compativel e consiga se comunicar com a API externa (atualmete Escalation).

Essas configurações podem ser definidas atavés dos parametros TICKET_API_PARAMS:

1.4.1 Nome da Arvore de Decisões:

O nome da arvore de decisões será utilizado para enviar ou receber informações da API de tickets(Escalation):

{
  "typeName":"arvoreDecisao"
}

arvoreDecisao será utilizado por padrão caso esse atributo não tenha sido definido na configuração

1.4.2 Definindo "apelidos" para Empresa, Filial e Local

Caso seja necessario utilizar uma sigla para EFL diferente da padrão ja definida no sistema, podemos usar o parametro "efl" para criar um alias para um local Especifico.

{
   "efl":{
      "3":{
         "LOCAL":"MA",
         "FILIAL":"LOGISTICA",
         "EMPRESA":"SAL"
      }
   }
}

Note que a estrutura é definida pelo parametro "efl", contendo o seqDb do local como chave e qual o apelido será usado para EFL daquele local

1.4.3 Campo Principal na API

Essa configuração, define qual o campo retornado no JSON da API será utilizado para verificar se o QII possui arvore de decisão aberta.

{
  "mainField": "EQUIPAMENTO"
}

o campo EQUIPAMENTO será utilizado por padrão caso esse atributo não tenha sido definido na configuração

2. Configurações do Arvore de Decisões:

tabela nfs_decision_tree_config

A configuração do menu, permite definir quais os items vão aparecer no menu de contexto e quais as condições necessárias para que isso aconteça.

2.1 Estrutura:

Campo CONFIG

{
  "label":"",
  "menu":[],
  "cardIcon":{
    "styles":[]
  },
  "topButton":{}
}

2.1.1 label

Apelido dado a arvore de decisão - *utilizar camelCase

Ao utilizar com escalation o apelido devera ser o mesmo ao nome definido para a arvore no próprio escalation.

2.1.2 menu

Itens que vão aparecer no menu de contexto:

Este parâmetro tem como valor um array de objetos, sendo cada objeto um item do menu:

{
  "menu": [
    {
      "condition": "",
      "entryPoint": "",
      "icon": "",
      "text": "",
      "url": ""
    },
    {
      "condition": "",
      "entryPoint": "",
      "icon": "",
      "text": "",
      "url": "",
      "type":""
    }
  ]
}

Legenda:

2.1.3 cardIcon

Estilos custom para o ícone de arvore de decisão:

{
  "cardIcon": {
    "styles": [
      {
        "condition": "DECISION_TREE_OPEN",
        "style": "color:green;"
      },
      {
        "condition": "F12",
        "style": "color:red;"
      }
    ]
  }
}

Legenda:

2.1.4 topButton

Configuração do botão de lista do topo, esse botão por hora só exibe todos as arvores abertas:

{
  "topButton": {
    "title": "Mostrar todos os tickets",
    "url": "https://escalation-qa.simova.cloud/ext/tickets"
  }
}

• title: titulo exibido ao fazer hover no botão
• url: pagina que contem todos os tickets

2.1.5 Exemplo configuração completa

{
    "label": "arvoreDecisao",
  "cardIcon": {
    "styles": [
      {
        "condition": "DECISION_TREE_OPEN",
        "style": "color:green;"
      },
      {
        "condition": "F12",
        "style": "color:red;"
      }
    ]
  },
  "menu": [
    {
      "condition": "",
      "entryPoint": "openTicket",
      "icon": "fa fa-plus-circle",
      "text": "Abrir Chamado",
      "url": "https://escalation-qa.simova.cloud/ext/tickets/edit"
    },
    {
      "condition": "F12",
      "entryPoint": "openTicket",
      "icon": "fa fa-plus-circle",
      "text": "Abrir Chamado Tempo Excedido",
      "url": "https://escalation-qa.simova.cloud/ext/tickets/edit"
    },
    {
      "condition": "DECISION_TREE_OPEN",
      "entryPoint": "listTicket",
      "icon": "fa fa-list",
      "text": "Listar Chamados",
      "type": "list",
      "url": "https://escalation-qa.simova.cloud/ext/tickets"
    }
  ],
  "topButton": {
    "url": "https://escalation-qa.simova.cloud/ext/tickets",
    "title": "Mostrar todos os tickets"
  }
}

3. Entry Point:

exemplo de entry point para editar inserir um novo ticket:

$this->outputValues = array(
  "typeName" => "arvoreDecisao",
  "insDh" => "2024-07-08 08:42:44",
  "statusCode" => "1",
  "values" => array(
    array(
      fieldName => "idApt",
      value => mt_rand(0, 999999)
    ),
    array(
      fieldName => "eqp",
      value => $this->inputValues['qii']['QII_SEQ_DB']
    )
  )
);

Os campos devem ser enviados conforme os nome e estrutura definida no Escalation

exemplo de entry point de listagem:

$this->outputValues = array(
  "status" => "1" 
);

4. Árvores Abertas

Para manter o registro das árvores que estão abertas no escalation, podemos configurar um agendamento que vai busca-las e as armazenar na tabela app_decision_tree_json.

Para isso basta criar o agendamento(nfs_core_scheduller) com o codigo como no exemplo abaixo:

$treeService = new DecisionTreeService();
$treeService->updateOpenTrees();

Feito isso, podemos verificar se um QII possui árvore aberta através do field DECISION_TREE_OPEN:

{
 "cardIcon": {
    "styles": [
      {
        "condition": "DECISION_TREE_OPEN",
        "style": "color:green;"
      }
    ]
  },
}

Exemplo onde alteramos a cor do icone da arvore de decisão no painel caso o equipamento possua ticket aberto.

5. Sincronismo com o Escalation

Para enviar os dados e torna-los disponiveis no Escalation, devemos agendar um sincronismo no NFS, isso pode ser feito utilizando o serviço EscalationApiService do NFSCore como no exemplo abaixo:

/** Sincronismo de Frentes */
/**
 * Busca os registros da tabela APP_FRENTE
 */
$allFrentes = Dao::table('FRENTE')->select('SEQ_DB','CODIGO','DESCRICAO','ATIVO')->all()->get();
$listaAllFrentes = array_column($allFrentes, null, 'SEQ_DB');
$listaFinal = [
	'tableName' => "silv_modulo",
	'fkDisplayColumnName' => "description",
	'fkColumnName' => "sync_id",
	'companyCode' => "SILV",
	'branchCode' => "SILVICULTURA",
	'siteCode' => "DEV"
];
$listaDados = [];
foreach($listaAllFrentes as $frente){
	$arrayInput = [
	  'fkColumn' => $frente['SEQ_DB'],
	  'fkDisplayField' => $frente['CODIGO'].' - '.$frente['DESCRICAO'],
	  'active' => $frente['ATIVO']
  ];

	array_push($listaDados,$arrayInput);
}
$listaFinal['values'] = $listaDados;

/**
 * Cria o serviço de comunicação com o Escalation
 * e efetua o sincronismo
 */
$escalationApiService = new EscalationApiService();
$escalationApiService->sync($listaFinal);

6. Envio dos tickets do Escalation para o NFS:

Caso seja necessario salvar os dados dos tickets ao efetuar alguma modificação no Escalation, um usuario de API deverá ser criado no ambiente alvo com acesso aos locais que possuem a arvore de decisão.

Feito isso sera possivel obter o token e efetuar a integração dos dados do escalation com o NFS.

6.1 Autenticação

/* Dados do usuario cadastrado no ambiente e local */
{
  "user": "escalation-api-user",
  "pass": "senha123",
  "branchCode": "localA"
}

6.2 Integração

/**
* Dados do ticket
* Usar dados reais, exemplo meramente ilustrativo.
*/
{
  "id": 10036,
  "seq": 8,
  "type":{...},
  "values":{...}
}