Registador personalizado

No caso em que as ferramentas acima enumeradas para encontrar erros não sejam suficientes, pode sempre fazer o seu próprio registador e implementar todas as suas necessidades no mesmo. Por exemplo, vamos criar um registador que irá adicionar informações sobre o utilizador que desencadeou este evento e o seu nível de acesso, para além da descrição geral do evento.

Modelo de dados do registador

Para tal, vamos começar por criar um modelo na base de dados. Precisamos de um modelo muito simples, com três campos obrigatórios.

• info (text) - informações gerais sobre o evento
• user (integer) - Identificação do utilizador
• access (array string) - grupos de utilizadores (pode haver vários)
  

Processo de negócio do logger

Depois disso, criaremos um processo empresarial para a escrita de um registo na base de dados. A sua tarefa será receber informação sobre qualquer evento, complementá-la com informação sobre o utilizador, e guardar o resultado final na base de dados.

Para obter informações sobre o utilizador, utilize o Auth: Get current user bloco. Note-se que só poderá representar o resultado como um modelo de utilizador se Middleware Token Auth foi activado no ponto final que iniciou a sua execução.

Utilizamos Expand User para expandir o resultado e obter os campos necessários. No nosso caso, estes são ID, Login, e Groups. Usando os dois primeiros é bastante banal, basta converter Login do formato de correio para um padrão String (To String bloco).

No caso de grupos de utilizadores, a situação é um pouco mais complicada. Estes são armazenados em Enum formato. Este é um tipo enumerado que armazena apenas uma lista de identificadores na base de dados, e não o seu valor de texto. No nosso caso, o valor 1 corresponde ao grupo de administradores (Admins), e o valor 2 ao grupo de utilizadores (Users).

A nossa tarefa é decifrar este identificador e escrever o resultado sob a forma de dados textuais convenientes. Para isso, é necessário:

• Declarar uma variável em que texto será escrita a informação sobre grupos de utilizadores. Vamos utilizar a variável String Array e Set Variable blocos.
• Iniciar o laço com o For each loop bloco. Receberá um conjunto de grupos de utilizadores e, depois, em cada iteração, converterá o próximo grupo ao seu valor de texto e adicioná-lo-á ao conjunto.
• Usando o Switch bloquear, verificar o grupo de utilizadores e, dependendo do resultado, orientar ainda mais o processo.
• Utilizando o bloco de String e Set Variable blocos, armazenar o valor requerido do grupo do utilizador numa variável.
• Utilizar a variável Append Array e Set Variable blocos para adicionar o resultado a uma matriz e armazená-lo numa variável declarada antes do início do laço.
  

Após a conclusão do laço, deve ser utilizado o Concat Strings (Multiple) bloco para formar uma cadeia final a partir de dados dispersos, que serão convertidos em Text e escrito ao diário de bordo.

A última coisa a fazer é gerar o log modelo e escrevê-lo na base de dados.

O BP resultante deve ter o seguinte aspecto:

Ponto final do logger

O processo comercial está pronto. Agora precisamos de criar um ponto final para ele. Para tal, vamos substituir o processo de negócio do sistema de POST /log/ ponto final com o processo comercial que acabou de ser criado.

Agora o nosso próprio registo está completamente pronto para partir. Pode voltar ao início do módulo, ao Basic functions processo empresarial, e substituir o diário de bordo padrão por aquele que você mesmo fez.

Agora, cada vez que os cálculos são iniciados, um registo especial registará não só informações sobre o próprio facto deste evento, mas também sobre qual o utilizador que o fez. Podemos verificar o resultado em Swagger.

Óptimo, o nosso diário de bordo funciona mesmo. Agora contém informações sobre o evento, o login do utilizador, e os seus direitos de acesso.

Possíveis erros e acções recomendadas

Como resultado, estruturamos possíveis variantes de erros e acções para os corrigir.

• Erros no próprio processo empresarial. Recomenda-se a utilização de registos para verificação passo a passo. Assim, é possível verificar o próprio facto de lançar um determinado bloco de processo empresarial e todos os parâmetros que o bloco utiliza, tanto na entrada como na saída.
• Erros no envio do pedido para o servidor. Para o fazer, utilize o Developer Tools no browser. Pode verificar o facto de que o pedido foi enviado, analisar a sua estrutura, e ver a resposta recebida.
• Os pedidos são malformados. Recomenda-se a utilização de Swagger para testes completos, verificando várias opções de consulta, e combinações de parâmetros.
• O resultado do pedido não é analisado correctamente. Acontece que estamos à espera do resultado onde ele não deveria estar. Por exemplo, adicionamos dados à base de dados mas não os actualizamos na tabela que exibe estes dados. Lembre-se de que cada componente requer um processo comercial correspondente, e assegure-se de que este processo é configurado correctamente.