domingo, 15 de novembro de 2020

Benefícios de uma Solução MDM


Por conta da transformação digital, as maiorias das empresas estão cada vez mais conscientes que seus dados são um dos ativos mais importantes, a cada dia que passa o volume de dados aumentam exponencialmente e através da aplicação da metodologia Data-Driven, que basicamente é a utilização de dados para orientação de ações que geram novos dados que geram novas ações, logo se tornou essencial o gerenciamento de dados como um dos focos principais das organizações. Por conta dessa importância, podemos entender o quanto é vital para qualquer empresa, independentemente de seu tamanho,  um processo que envolva a coleta, sanitização, normatização, garantia de qualidade, governança e principalmente a transmissão dos dados entre todas as partes interessadas.

E é nesta solução desse problema que se encaixa perfeitamente um MDM, Master Data Management, em tradução livre ficaria, Gerenciamento de Dados Mestres. Essa solução fornecerá todos os requisitos mencionados anteriormente, como também a consolidação da oferta de dados em uma única fonte, que ofertará os benefícios: 

Qualidade dos Dados

No processo de coleta dos dados para transferência para o MDM é possível garantir através de regras de aceitação e da eliminação de dados inválidos. Como resultado os usuários poderão trabalhar com dados consistentes, uniformes e de melhor qualidade, o que tornará os processos de negócios mais eficientes e confiáveis.

Duplicação de Dados

Eliminando qualquer chance de conter dados duplicados, o que nos cenários atuais sem a centralização de dados é extremamente comum e leva a dúvidas em relação qual dados é mais confiável, o MDM irá construir uma única fonte de dados altamente confiável e proverá aumento na eficiência do negócio.

Precisão dos Dados

Sem dados inválidos ou duplicados, as discrepâncias no dados não existiram e aumentaram o nível de precisão dos mesmos, reduzindo os riscos de processamento de informações incorretas, como também o fator de normalização das estrutura facilitando a recuperação e entendimentos dos dados.

Redução de Custos

Uma vez que teremos uma solução gerenciando todos os dados mestres da empresa, automaticamente iremos reduzir os locais que precisam estar processando os dados, monitoramento da utilização,  sem contar a eliminação do impacto negativo ao negócio quando um dado impreciso é compartilhado.

Conformidade dos Dados Verídicos

Cada dia que passa os regulamentos e as políticas sobre dados estão ficando cada vez mais rígidos, com isso é fundamental que qualquer negócio tenha total controle (gerenciamento) sobre os dados, pois a não conformidade pode acarretar multas pesadas, como regulamentadas pela LGPD. A aplicação de um gerenciamento dos dados diminui as chances de violações de segurança e possibilita a conformidade regulamentar.

Tomada de Decisão em Dados

Já sabemos como as empresas estão aumentando a utilização dos dados para tomadas de decisões, informações incompletas e incorretas possibilitando à administração tomar decisões mal direcionadas que impactam o crescimento da empresa a curto e longo prazo. O simples fato de ter acesso a dados com qualidade, ajudará todos os gestores a desenvolverem estratégias eficazes.

Estamos num bom momento para considerar uma abordagem de MDM para gerenciamento de dados nas empresas. Já existem algumas ferramentas no mercado despontando com maturidade para oferecer um bom pacote de serviços, como também é possível implementar uma solução interna totalmente adaptada para o contexto do negócio. O que eu sei é, o gerenciamento de dados é um caminho inevitável para qualquer organização que queria estar no futuro entregando valores para seus clientes.


Marcelo Goberto de Azevedo 

Arquiteto na GFT Brasil

//marcelogoberto.com.br


sábado, 24 de outubro de 2020

TDD no SQL com tSQLt

 

A utilização de teste é uma realidade muito comum no desenvolvimento de aplicativos, porém banco de dados é tratada como uma forma de exceção quando falamos da utilização do método desenvolvimento orientado a testes, principalmente pela falta de uma ferramenta integrada que possibilite a criação de testes, classes, além da metrificação dos resultados da execução dos testes.

O tSQLt é uma ferramenta que oferece uma estrutura de testes para ser aplicado em banco de dados SQL, o tSQLt permite implementar testes de unidade em T-SQL, também fornece recursos como: testes dentro das transações, agrupamento dos testes em classes, saída em texto simples ou XML e o principal de criar clonar de tables, views, functions e procedure para utilizar em simulação nos testes sem interferir nas estruturas reais.

O processo para utilização é bem simples e vamos demonstrar desde a instalação e criação de um teste e sua execução.

  1. Instalação do tSQLt

  • Baixe tSQLt do site tSQLt.ORG

  • Acesse ou crie um novo banco de dados

  • Execute o script tSQLtClass.SQL no banco de dados


Installed at 2020-10-24 18:23:21.390
+-----------------------------------------+
|                                         |
| Thank you for using tSQLt.              |
|                                         |
| tSQLt Version: 1.0.5873.27393           |
|                                         |
+-----------------------------------------+
  1. Efetuar a criação de “Classes” para agrupar o teste

EXEC tSQLt.NewTestClass 'UnitTestClass';

Esse comando irá criar uma classe que poderá ser utilizada para executar somente os testes que estiverem associadas à ela, na prática o SQL criará um “Schema” com esse nome.

  1. Criando um teste

CREATE OR ALTER PROC [UnitTestClass].[Test Exists Function CalculateBestQuote]
AS
BEGIN
  --Arrange
 
  --Act
  
  --Assert
   EXEC tSQLt.AssertObjectExists @ObjectName = N'fnCalculateBestQuote'
END
GO

Importante, toda procedure que representa um teste deve obrigatoriamente iniciar com a palavra “Test”, como o banco de dados podem conter estrutura que podem não existir, diferente de código estático, existe um Assert específico que efetua a validação da existência do objeto, no caso do exemplo, ele está verificando se a function “fnCalculateBestQuote” existe no banco de dados.

  1. Executando os testes

    EXEC tsqlt.RunTestClass 'UnitTestClass'

Através do comando, todos os testes que estão associados a classe referida, será executado exibindo as mensagens de erros, os resultados esperados e um resumo dos testes.

[UnitTestClass].[Test Exists Function CalculateBestQuote] failed: (Failure) 'fnCalculateBestQuote' does not exist
 
+----------------------+
|Test Execution Summary|
+----------------------+
 
|No|Test Case Name                                           |Dur(ms)|Result |
+--+---------------------------------------------------------+-------+-------+
|1 |[UnitTestClass].[Test Exists Function CalculateBestQuote]|    127|Failure|
-----------------------------------------------------------------------------
Msg 50000, Level 16, State 10, Line 1
Test Case Summary: 1 test case(s) executed, 0 succeeded, 1 failed, 0 errored.
-----------------------------------------------------------------------------

  1. Criando a function 

CREATE OR ALTER FUNCTION fnCalculateBestQuote
(
    @BaseValue decimal(10,2),
@Fator decimal(6,2)
)
RETURNS Decimal(15,2)
AS
BEGIN
    RETURN @BaseValue / @Fator * 2;
END
GO

Após a execução dos testes e da falha, devemos escrever o código que satisfaça a regra de negócio esperada.

  1. Executando o teste novamente

EXEC tsqlt.RunTestClass 'UnitTestClass'

O resultado dos testes será com sucesso

+----------------------+
|Test Execution Summary|
+----------------------+
 
|No|Test Case Name                                           |Dur(ms)|Result |
+--+---------------------------------------------------------+-------+-------+
|1 |[UnitTestClass].[Test Exists Function CalculateBestQuote]|      6|Success|
-----------------------------------------------------------------------------
Test Case Summary: 1 test case(s) executed, 1 succeeded, 0 failed, 0 errored.
-----------------------------------------------------------------------------

Portanto, agora ficará mais fácil detectar bugs antes mesmo de conectar com seu código de backend, simplesmente executando os testes no banco de dados.

Existem várias funções desenvolvidas para validações, além claro da parte de clonar tabelas e afins para criar massa de testes, existe uma vasta documentação em https://tsqlt.org/full-user-guide/

Na GFT praticamos TDD em sessão de Coding Dojo que ocorrem a cada 15 dias em sessões online, elas são abertas para todos participarem, basta acessar //meetup.com/GFTBrasil, escolher o melhor dia e horário para você praticar.


Marcelo Goberto de Azevedo 

Arquiteto na GFT Brasil

//marcelogoberto.com.br


sábado, 26 de setembro de 2020

Logs, quem são, onde vivem, o que comem?

Logs são apontamento de atividades gerados por sistemas. O armazenamento pode ser feito em arquivos, base de dados, ferramentas. Eles comem, ops, servem como fonte de informações que permitem analisar o histórico de comportamento do programa, como identificar erros, indicar falhas de sistema ou ainda fornecer insumos para previsibilidade de eventos futuros.

São muitas as alternativas para que os logs sejam criados. A captura de registro de logs devem ser desenhada para atender um equilíbrio que todos registros sejam sucintos e minimamente didáticos para solução de um problema. É obrigatório que toda uma aplicação seja coberta por registros de log de erros, isso garante o mínimo do mínimo. 

Para informações pertinentes e relevantes um registro de log deve ser composto pelos seguintes propriedades:

Data Evento

Essa data refere ao momento do registro do Log, de preferência com fuso horário ajustado para a audiência.

Aplicação

Nome da aplicação que está gerando a mensagem de log.

Nível

Todo log deve pertencer obrigatoriamente a um nível, é fundamental o entendimento desses níveis, porque alguns não são aplicados em todos ambientes.


  • TRACE: Esse nível deve ser utilizado para rastrear algo pontual em produção e nunca devem ficar habilitados definitivamente em produção.

  • DEBUG: Nesse nível pode ser logado qualquer coisa durante o desenvolvimento, porque esse tipo só será registrado em ambiente de desenvolvimento.

  • INFO: Os logs desse nível devem basicamente rastrear pontos de fluxo do aplicativo.

  • NOTICE: Todos esses logs serão criados para monitoramentos em produção.

  • WARN: Neste nível são os logs de alertas (monitoramento) para potenciais problemas que podem gerar erros, como falta de espaço, lentidão. Porém não causam a interrupção da execução do aplicativo.

  • ERROR: Todas as condições de erro gerados dentro do programa, quando um fluxo fluxo de execução é interrompido devido a uma falha.

  • FATAL: Os logs neste nível devem ser utilizados para acionar contingências, pois descrevem um aplicativo irrecuperável ou falha do sistema que requer atenção imediata.

Categoria

Todos os logs devem conter obrigatoriamente uma categoria, essa categoria deve ser utilizada para agruparem logs dentro do mesmo contexto, que facilitem a extração dentro de um comportamento. Outro fator importante, é utilizar um nível hierárquico respeitando o princípio simples de responsabilidade.

Mensagem

As mensagens devem ser escritas em inglês, isso se deve ao fato das ferramentas de análise de logs estarem preparadas para analisar palavras e frases associados ao idioma inglês, além de evitar problemas com acentuação que ocorre muito no idioma português.

O conteúdo da mensagem devem ser ricos no sentido que ofereçam informações que auxiliem no entendimento do logs, muitas vezes quem estará interpretando a mensagem não necessariamente tem o conhecimento do negócio.

Sempre adicione contexto as mensagens, todo registro de log deve conter por si só, todas as referências necessárias para auxiliar no entendimento da sua geração.

A grande maioria dos logs atualmente são analisado por ferramentas de monitoria, e lembrando que essas leituras são feitas por máquinas, é importante que o conteúdo das mensagens sejam acessíveis a humano e máquina, logo é importante normatizar os dados para facilitar o entendimento de ambos, uma forma é elegante é tipificar através do formato JSON o conteúdo.

Nenhuma informação sensitiva devem ser armazenadas em nenhum nível de logs, seja nome do cliente, número de documento, senhas, tokens, ou seja, nenhum dados que possa identificar ou expor informações. Os logs não passam por nenhum tipo de validação de conteúdo, por conta que as informações são muito genéricas, logo é sua responsabilidade não armazenar informações que ferem as leis (LGPD).

Regra de ouro para definir o que registrar numa mensagem de log?

Simplesmente pense em algo que alguém terá de lê-lo um dia ou mais tarde. Mais importante, é pensar em quem vai ler essas linhas, pois isso define o conteúdo, contexto, categoria e nível da mensagem.

Usuário

Essa informação diz a respeito do usuário que está utilizando a aplicação no momento do log, seja um colaborador ou até mesmo um processo automatizado.

Ambiente

Deve sempre identificar o ambiente em que log foi gerado (Desenvolvimento, Homologação, Pré-Produção, Produção, ...)

Outro ponto importante, é a centralização dos logs, pois permitirá  aumentar a segurança e praticidade, sendo que os logs centralizados ficam mais fácil para fazermos consultas em busca de erros e análise e controlar a permissão de acesso.

Lembre-se também de criar uma regra de retenção, porque os logs contém uma volumetria muito alto e se não for criado essa política, com o tempo muitas informações não mais necessárias estarão aumentando o tempo de consulta e dificultando a localização de dados relevantes.

E ainda, cada vez que um código for refatorado é importante criar mensagens de log. Procure manter uma sincronia entre os comentários e o registro de log, porque não há nada pior ao solucionar problemas para obter mensagens irrelevantes que não têm relação com o código processado.


Marcelo Goberto de Azevedo 

Arquiteto na GFT Brasil

//marcelogoberto.com.br