...

Este documento tem como objetivo descrever como foi desenvolvido e implementado 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.

Limitação do escopo

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 proposto 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á criado duas linhas de fluxo, caracterizando um processamento paralelo. Se na atividade em uma das linhas for negada pelo usuário, a solicitação será cancelada, mesmo que na outra linha a atividade (proposta) seja aprovada, e 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 o 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: 

O processo inicia com a seleção do cliente para qual a proposta será criada e preenchimento do formulário com os dados da proposta: seleção dos produtos para concessão de limite, inserção de participantes (avalistas), bens e garantias. Assim que o formulário é submetido, o processo caí na primeira atividade, que é o Parecer Comitê Análise. Esta atividade está possui um mecanismo de atribuição definido por Grupo. Mais adiante será explicado sobre os diversos tipos de mecanismos de atribuição e seus comportamentos. Ao assumir a atividade, o usuário pertencente ao Grupo “Comitê de Análise” terá acesso ao formulário preenchido com as informações da proposta. Ele poderá alterar as informações conforme julgar necessário e quando concluir, deverá aprovar ou negar a proposta e então enviar. Ao enviar, o fluxo do processo será direcionado para a próxima atividade, Parecer Supervisor de Crédito. Esta atividade possui um mecanismo de atribuição definido por Papel. Quando um usuário que possui o papel de Supervisor de Crédito assumir a atividade, lhe será exibido o formulário da mesma forma como foi exibido na atividade anterior e, igualmente, lhe será permitido alterar os dados da proposta a critério. Ao enviar a atividade, o fluxo será direcionado para a próxima atividade, Parecer Gerente Crédito. Esta atividade é idêntica à anterior, com a diferença que o usuário que a for assumir deverá ter papel de Gerente de Crédito. A próxima atividade no fluxo depende de uma tomada de decisão. Esta decisão está baseada nos tipos de produtos que a proposta de limite de crédito possui. Se a proposta possuir um Finame, o fluxo será direcionado para a atividade Parecer Comitê Gestor. Caso possua Garantia, será direcionado para Parecer Comitê CEO. Caso a proposta não possua nenhum dos dois produtos citados anteriormente o processo será finalizado diretamente. Caso possua Garantia ou Finame, ao fim de ambas atividades o processo será finalizado e a proposta de limite de crédito estará disponível no GRisco, conforme decisão dos usuários, seja aprovada ou negada.

...

Mecanismos de atribuição de atividades

...

As atividades do processo precisam ser atribuídas para que algum usuário qualificado possa assumir a atividade e dar andamento no processo. No Fluig, existem várias maneiras de se definir mecanismos de atribuição de atividades. Veja tabela abaixo os mecanismos disponíveis. No contexto do motor de crédito do GRisco, será utilizado apenas os mecanismos de atribuição Para um Grupo (Pool) e Para um Papel (Pool).

 

Solução técnica

Para permitir a integração com o Fluig, foi necessário expor uma série de serviços do GRisco. Para tanto, foi criado uma camada de serviços utilizando tecnologia REST bem como SOAP. Veja na tabela abaixo os serviços expostos:

Solução técnica

...

...

Serviços RESTful

...