TMACUL

VALIDAÇÃO DE DADOS (Parte 02)  18/11/2015

Blog Post created by TMACUL Champion on Jan 1, 2016

Não tenho intenção de encerrar este assunto neste post. Caso você conheça outras alternativas de validação, contribua conosco.

Dando continuidade ao post anterior...

 

VALIDAÇÃO DE SALVAMENTO VINCULADO À CATEGORIA

Essa customização se faz necessária quando existe a necessidade de criar regras de salvamento de acordo com a categoria do ticket. O funcionamento é baseado na "injeção" de código Javascript importado do "template" da categoria, de forma que, através de um "eval", esta validação seja processada através de uma etapa de execução da função "preSaveTrigger".

Quem estiver interessado no seu funcionamento, acesse o post https://www.facebook.com/groups/usuariossdmbrasil/permalink/1011830798847834/.

RECOMENDAÇÃO: Esta funcionalidade só é possível através de uma customização "hardcore" na ferramenta e deve ser muito bem avaliada. Para administradores da ferramenta que precisam vincular a regra de negócio na categoria do ticket utilizando a linguagem Javascript ao invés de manter uma trigger SPEL específica que só tende a crescer. Esta customização mesmo sendo bastante complexa, proporciona uma maior agilidade nas mudanças de regra de negócio das categorias, sem causar indisponibilidade na ferramenta e ao mesmo tempo, com reflexo imediato nas novas criações de ticket. Mas é bom destacar que esta customização deve ser exaustivamente testada pelo fato do browser do usuário poder interferir no pleno funcionamento da solução.

EXEMPLO: Ao preencher um formulário e suas propriedades, antes que o usuário salve o ticket, os dados são validados em fontes externas utilizando webservices REST/SOAP de fontes externas de validação.

 

OUTRAS FUNÇÕES JAVASCRIPT

Através de eventos Javascript associados a elementos no formulário, funções de validação/complementação de dados são executadas imediatamente durante o preenchimento do ticket mesmo que o objeto ainda não esteja salvo, otimizando a experiência do usuário.

RECOMENDAÇÃO: Outra customização "hardcore" que deve ser muito bem avaliada. Para administradores da ferramenta que precisam acessar informações em outras bases de dados ou que precisam executar validações imediatas no formulário antes que o ticket seja salvo. Caso a fonte dos dados de validação/complementação esteja hospedada em outro domínio diferente da SDM, é recomendável construir uma "bridge de acesso" dentro do contexto Java (CAIsd) da aplicação. Somente desta forma, os problemas de "crossBrowsing" serão evitados. Mas é bom destacar que esta customização deve ser exaustivamente testada pelo fato do browser do usuário poder interferir no pleno funcionamento da solução.

EXEMPLO: Ao alterar o conteúdo de um atributo específico de um formulário (onChange), uma chamada externa REST direcionada a outra fonte de dados é executada retornando um dado JSON utilizado para preencher automaticamente outro atributo do formulário.

 

FUNÇÕES REGEX ACOPLADAS A PROPRIEDADES

Através de um evento Javascript que executa uma expressão regular (RegEx), uma informação digitada pelo usuário em uma propriedade é validada imediatamente retornando uma mensagem amigável de alerta caso ocorra falha na validação. Estas expressões RegEx e suas respectivas mensagens de alerta são associadas ao template das propriedades da categoria de acordo com as regras de negócio definidas. A importação dessas regras a partir do template só ocorre durante a geração do ticket e cada expressão RegEx é armazenada em um atributo específico da tabela de propriedades relacionada ao objeto.

RECOMENDAÇÃO: Outra customização "hardcore" que deve ser muito bem avaliada. Para administradores da ferramenta que precisam validar informalções preenchidas em propriedades através de expressões regulares. Mas é bom destacar que esta customização deve ser exaustivamente testada pelo fato do browser do usuário poder interferir no pleno funcionamento da solução.

EXEMPLO: Uma propriedade de uma solicitação que exige um número de CPF válido ou uma URL respeitando determinada RFC.

 

CONDIÇÕES DE TRANSIÇÃO DE STATUS EM TAREFAS

A ferramenta permite nativamente que seja definida uma condição de transição de status em uma tarefa de fluxo de trabalho de forma que, uma validação seja executada antes que o usuário consiga modificar o status da respectiva tarefa. A solução é baseada em uma condição SPEL que retorna os valores TRUE/FALSE e uma mensagem de erro caso o retorno da validação seja falso.

RECOMENDAÇÃO: A implementação das condições de transição é bem simples e depende apenas da associação desta com cada respectivo comportamento de tarefa.

EXEMPLO: Antes que a tarefa "XYZ" que está com o status "Pendente" seja "Concluída", uma validação de preenchimento de um atributo opcional da requisição de mudança deve ser executada.

 

Até a próxima.

 

Publicado Originalmente: 18 de novembro de 2015 às 21:20

Em: CA SDM Brasil - facebook

Por: daniel-bighelini

Outcomes