Histórico da Página
...
Este documento tem como objetivo descrever como foi desenvolvido desenvolvida e implementado implementada a solução técnica para realizar a experiência #2 que consiste na internalização de funcionalidades dos produtos do Totvs Financial Services para o Fluig.
da TOTVS Financial Services para o Fluig.
Entendendo a Experiência #2
Integração com o Gestão de Risco
Conhecido pela internalização de funcionalidades dos produtos da TOTVS para o Fluig, a experiência de uso sugere a integração do Sistema de Gestão de Rísco de Crédito (GRISCO) com o Sistema Fluig ECM, com a finalidade de automatizar o processo de aprovação de proposta no módulo Gestão de Risco. Utilizando o engine de Workflow/BPM do Fluig, os Analistas de Negócio terão mais autonomia para configurar o workflow da esteira de crédito do GRISCO conforme as necessidades funcionais de cada cliente. O Sistema GRISCO continua sendo o provedor do serviço de manutenção dos dados da proposta, enquanto o Fluig o gestor e motor de execução do processo de concessão de limite, que será executado e modelado através do Fluig. O módulo GRISCO possui um engine nativo como motor de workflow do fluxo de aprovação de propostas que será substituido pelo Fluig workflow/BPM, integrando com o social. Podemos ver na figura abaixo a representação do processo do GRISCO pelo Fluig Diagrama. O BPM busca através de um formulário informações do GRisco, que é usado como repositório para o fluig.
| Aviso |
|---|
| Obs: Para que o GRISCO contemple o Workflow do Fluig é necessário que as configurações de uso do GRISCO sejam desativadas. |
O processo define os grupo e eventos do processo. Um grupo de evento no GRISCO representa um agrupador de atividades, podemos associar um grupo de evento com um subprocesso.
Abaixo a descrição do processo ilustrado na figura para um melhor entendimento da integração com o GRisco.
1 | Solicitar Proposta Limite O usuário acessa o Fluig e inicializa um processo de Concessão de Limite de Crédito.
|
2 | Registrar Proposta O usuário assume a atividade para registrar os dados da proposta. O Fluig direciona o usuário para a tela de iteração com o workflow do processo. O formulário do processo abre a tela de cadastramento de proposta do Sistema de Risco. Neste momento o usuário precisa iteragir com os dois Sistemas, no GRISCO para entrar com os dados da proposta e no Fluig para avançar a atividade. Obs: Neste ponto é necessário implementar uma validação no evento de finalização da atividade para verificar se o usuário realmente cadastrou a proposta no Sistema de Risco.
|
3 | Executar Motor de Crédito Esta atividade faz uma requisição ao Motor de Crédito, o retorno do Motor de Crédito é avaliado em uma expressão automatica para determinar o caminho do processo. O retorno do motor é exatamente como ocorre atualmente entre GRISCO e Motor de Crédito (Intellector). O Motor de Crédito retorna uma sigla que define quais os grupos de eventos que serão gerados para a proposta. |
4 | Registrar Pendência de Empréstimo Subprocesso que definie quais serão as atividades de interação humana. Estas atividades são representadas por eventos no GRISCO e estes eventos serão desativados enquanto estiver em interação com o Fluig. |
5 | Registrar Pendência de GRAVAME Nesta atividade o usuário apenas registra a observação e avança o processo. Em todas as atividades do processo o usuário poderá modificar as informações da proposta acessando o Sistema GRISCO por dentro do Fluig. O formulário do processo irá exibir os dados da proposta em todas as atividades, através da tela do Sistema de Risco. |
6 | Finalizar formalização Esta atividade tem por finalidade consumir o serviço do Sistema de Risco para finalizar o ciclo de vida da proposta, o propósito é notificar o GRISCO do resultado do Workflow de concessão de limite. O resultado é obtido conforme o caminho lógico percorrido pelo Fluig. |
Estrutura Workflow Fluig
Tem o objetivo de fazer com que usuários, clientes, fornecedores e parceiros participem ativamente da empresa, administrando os processos, gerenciando fluxos de trabalho, desenhando e evoluindo processos simples e complexos, sustentados por formulários eletrônicos e administrados por regras parametrizáveis, interagindo com outros sistemas e aplicativos da empresa.
Na versão 11, iniciamos a externalização dos fluxos de aprovação dos ERPs para o engine workflow/BPM do Fluig que possui aplicativo móvel como sua interface para suportar as aprovações. Cada atividade no Workflow corresponde a uma etapa de aprovação e a próxima etapa só poderá ser alcançada se a anterior tiver sido aprovada. O processo possui tomadas de decisão, ou seja, toma caminhos diferentes conforme os produtos selecionados para concessão do limite de crédito. Se a proposta de crédito tiver os dois produtos Garantia e Finame, significa que serão criadas duas linhas de fluxo, caracterizando um processamento paralelo. Se na atividade uma das linhas for negada pelo usuário, a solicitação será cancelada, mesmo que na outra linha a atividade seja aprovada, e o processo não atingirá seu final. Imagem do workflow pode ser vista a seguir no tópico Desenho do Processo no Fluig.
Limitação do escopo
Esteira de Crédito
...
Conforme a descrição de escopo do documento de declaração de trabalho das experiências de uso, o texto sugere que o motor de aprovação de limite de crédito seja todo executado no Fluig, substituindo o motor que existe atualmente no GRisco, mantendo o mesmo como sistema de background para persistência e repositório da proposta no seu estado final, ou seja, aprovada ou negada. Foi, então, selecionado um processo real do cliente Moneo e tomado como referência para ser reproduzido no Fluig. Algumas características importantes acerca do processo escolhido serviram para limitar o escopo do desenvolvimento:
- O processo de proposta de limite de crédito possui atividades dispostas em série, sendo que cada atividade corresponde a uma etapa de aprovação e a próxima etapa só poderá ser alcançada se a anterior tiver sido aprovada. Cada atividade no Fluig pode ser entendida como um evento no GRisco;
- O processo possui tomadas de decisão, ou seja, toma caminhos diferentes conforme os produtos selecionados para concessão do limite de crédito. Se a proposta de crédito tiver os dois produtos, Garantia e Finame, significa que será criada duas linhas de fluxo, caracterizando um processamento paralelo. Se na atividade uma das linhas for negada pelo usuário, a solicitação será cancelada, mesmo que na outra linha a atividade (proposta) seja aprovada, o processo não atingirá seu final;
- Não está previsto atividade conjunta, que são aquelas atividades que possuem vários aprovadores que precisam chegar a um consenso.
Desenho
...
do processo no Fluig
Para desenhar o processo, foi utilizado o TDS (Totvs Developer Studio). Trata-se de uma ferramenta baseada no Eclipse com plug-ins para desenvolvimento no Fluig. Dentro do projeto foi criado o desenho do processo conforme ilustração abaixo:
...
As atividades do processo precisam ser atribuídas para que algum usuário qualificado possa assumir a atividade e dar andamento no processo. Ao assumir a responsabilidade o usuário deverá aprovar ou negar a tarefa. No Fluig, existem várias maneiras de se definir mecanismos de atribuição de atividades. Veja , veja na tabela abaixo os mecanismos disponíveis. No contexto do motor de crédito do GRisco, será utilizado serão utilizados apenas os mecanismos de atribuição Para um Grupo (Pool) e Para um Papel (Pool).
...
Widgets de Consulta Rápida: Diretriz para o Roadmap V12- projeto conjunto VPT - Framework + VP Fluig WCM para prover um framework de desenvolvimento de widgets de consulta rápida.
...
O fluig de antigamente, antes das experiências de uso, sofria diversas dores, por não ser uma ferramenta totalmente integrada com o sistema. Navegação por múltiplos sistemas, ícones e atalhos, o que complica a centralização das atividades, gestão de segurança não integrada, diversos engines do workflow, difícil usabilidade, tornou o fluig alvo de reclamações. Começaram assim, a serem implantadas melhorias no sistema. Através das experiências feitas conseguimos tornar o fluig uma ferramenta usual de grande efetividade, simplificando o modo de usar e entender os processos da empresa.
Entendendo a Experiência #2
A experiência de uso sugere a integração do Sistema de Gestão de Rísco de Crédito (GRISCO) com o Sistema Fluig ECM, com a finalidade de automatizar o processo de aprovação de proposta no módulo Gestão de Risco. Utilizando o engine de Workflow/BPM do Fluig, os Analistas de Negócio terão mais autonomia para configurar o workflow da esteira de crédito do GRISCO conforme as necessidades funcionais de cada cliente. O Sistema GRISCO continua sendo o provedor do serviço de manutenção dos dados da proposta, enquanto o Fluig o gestor e motor de execução do processo de concessão de limite, que será executado e modelado através do Fluig. O módulo GRISCO possui um engine nativo como motor de workflow do fluxo de aprovação de propostas que será substituido pelo Fluig workflow/BPM, integrando com o social. Podemos ver na figura abaixo a representação do processo do GRISCO pelo Fluig Diagrama. O BPM busca através de um formulário informações do GRisco, que é usado como repositório para o fluig.
O processo define os grupo e eventos do processo. Um grupo de evento no GRISCO representa um agrupador de atividades, podemos associar um grupo de evento com um subprocesso.
Abaixo a descrição do processo ilustrado na figura para um melhor entendimento da integração com o GRisco.
1 | Solicitar Proposta Limite O usuário acessa o Fluig e inicializa um processo de Concessão de Limite de Crédito.
|
2 | Registrar Proposta O usuário assume a atividade para registrar os dados da proposta. O Fluig direciona o usuário para a tela de iteração com o workflow do processo. O formulário do processo abre a tela de cadastramento de proposta do Sistema de Risco. Neste momento o usuário precisa iteragir com os dois Sistemas, no GRISCO para entrar com os dados da proposta e no Fluig para avançar a atividade. Obs: Neste ponto é necessário implementar uma validação no evento de finalização da atividade para verificar se o usuário realmente cadastrou a proposta no Sistema de Risco.
|
3 | Executar Motor de Crédito Esta atividade faz uma requisição ao Motor de Crédito, o retorno do Motor de Crédito é avaliado em uma expressão automatica para determinar o caminho do processo. O retorno do motor é exatamente como ocorre atualmente entre GRISCO e Motor de Crédito (Intellector). O Motor de Crédito retorna uma sigla que define quais os grupos de eventos que serão gerados para a proposta. |
4 | Registrar Pendência de Empréstimo Subprocesso que definie quais serão as atividades de interação humana. Estas atividades são representadas por eventos no GRISCO e estes eventos serão desativados enquanto estiver em interação com o Fluig. |
5 | Registrar Pendência de GRAVAME Nesta atividade o usuário apenas registra a obersão e avança o processo. Em todas as atividades do processo o usuário poderá modificar as informações da proposta acessando o Sistema GRISCO por dentro do Fluig. O formulário do processo irá exibir os dados da proposta em todas as atividades, através da tela do Sistema de Risco. |
6 | Finalizar formalização Esta atividade tem por finalidade consumir o serviço do Sistema de Risco para finalizar o ciclo de vida da proposta, o propósito é notificar o GRISCO do resultado do Workflow de concessão de limite. O resultado é obtido conforme o caminho lógico percorrido pelo Fluig. |
...
Integração com o Social do Fluig
A integração da experiência de uso #2 com o Social do Fluig acontece justamente a cada atividade ou solicitações durante o processo no Workflow, onde entra o alerta na Central de Notificações do Fluig. A central de notificações reúne em um único local do Sistema todos os alertas de atividades e eventos em andamento que foram enviados ao usuário. Assim que alguma decisão onde o usuário . está relacionado é tomada, o mesmo recebe um alerta conforme a imagem abaixo.
Estrutura Workflow Fluig
Na versão 11, iniciamos a externalização dos fluxos de aprovação dos ERPs para o engine workflow/BPM do Fluig que possui aplicativo móvel como sua interface para suportar as aprovações. Cada atividade no Workflow corresponde a uma etapa de aprovação e a próxima etapa só poderá ser alcançada se a anterior tiver sido aprovada. O processo possui tomadas de decisão, ou seja, toma caminhos diferentes conforme os produtos selecionados para concessão do limite de crédito. Se a proposta de crédito tiver os dois produtos Garantia e Finame, significa que serão criadas duas linhas de fluxo, caracterizando um processamento paralelo. Se na atividade uma das linhas for negada pelo usuário, a solicitação será cancelada, mesmo que na outra linha a atividade seja aprovada, e o processo não atingirá seu final.
Resultado da Experiência #2
Obtivemos resultados positivos referente a experiência #2, conseguindo integrar o sistema e torná-lo parametrizável para outras experiências. Com a integração das funcionalidades dos produtos da TOTVS, o Workflow do Fluig efetua a troca de informações com o sistema GRisco, podendo ser utilizado de maneira ágil e conectada. Para que o sistema rodasse livremente, foi preciso ajustar algumas configurações de uso do GRisco, onde basicamente através dos formulários o Fluig busca as informações no sistema.
Tecnologia Utilizada para Desenvolver
Para o desenvolvimento das experiências foi utilizado o framework AngularJS.
O exemplo acima ilustra cerca de 2 diretivas que são utilizadas para dados vinculação no AngularJS.
Imagem acima de um formulário HTML, onde o Angular transforma os objetos .json para html, fazendo o binding.
...
Visão Geral
Import HTML Content
Conteúdo das Ferramentas
Tarefas