Versão Experimental - Flumen

Em paralelo ao desenvolvimento normal do módulo workflow, encontra-se em construção uma nova versão experimental, com o objetivo de reestruturar o módulo e introduzir melhorias significativas. O codinome desta versão é "Flumen".

O código fonte está disponível na área sandbox do Svn, e está estruturado desta forma:

 sandbox
  |
  + - workflow
      |
      + - trunk
      |
      + - branches
          |
          + ticket #

O ramo trunk é destinado para a versão em desenvolvimento consolidada, isto é, o código existente no trunk deve ser funcional, podendo ser baixado e executado, com o mínimo de problemas.

O ramo branches é destinado para as versões em desenvolvimento, associadas a tickets do Trac. Cada novo experimento deve estar registrado em um ticket associado ao milestone "SandBox - Workflow".

O ciclo de vida de uma implementação no Flumen deve ser:

• Criar um ticket no Trac para descrever e discutir a nova implementação;
• Associar o ticket ao milestone "SandBox - Workflow";
• Criar um branch a partir do trunk e nomeá-lo com o número do ticket;
• Desenvolver as modificações no branch e testar;
• Quando estiverem concluídas, fazer o merge com trunk e testar;
• Fechar o ticket.

Caso o assunto de um ticket seja de fácil implementação, é opcional criar o branch para ele, podendo a implementação ser feita diretamente no trunk.

Não é recomendado ter mais de um ticket associado a um branch. É preferível ter sempre a associação de um ticket ao seu próprio branch.

Caso alguma implementação no Flumem possa ser aproveitada de imediato no módulo oficial, nada impede que seja transferida, desde que bem testada e não comprometa o funcionamento do módulo e processos.

Mais abaixo segue o levantamento de requisitos desejáveis para a nova versão.

Requisitos para o Módulo

• Definir uma nova árvore de diretórios para o módulo, que separe o código acessível pelo Expresso, código do módulo (lib), e código de terceiros. Prever local para hooks, plugins, especializações de classes, templates por organização;

• Revisar o código do engine
  • Remover métodos desnecessários;
  • Encapsular as classes e atributos, segundo orientação por objetos (private, public, protected);
  • Remover o design pattern Observer;

• Reescrever as interfaces do workflow utilizando plugins
  • Existirá uma super-classe da qual serão especializados os plugins para ações, filtros, conexões com banco, ldap, filesystem, etc;
  • Registrar os plugins disponíveis em cada interface e registrar o controle de acesso dos usuários;
  • Criar uma classe de segurança que verifica se um plugin está disponível para um usuário, antes de rederizar a interface;
  • Pensar um esquema de cache para otimizar as consultas de segurança.

• Implementar um novo modelo de classes para o workflow
  • Considerar o framework de plugins;
  • Transferir para o módulo as classes que são de estrutura dos processos e deixar no engine apenas as funcionalidades relativas ao andamento das instâncias.
  • Documentar o engine com um diagrama de classes.

• Pesquisar e implantar uma ferramenta para design dos fluxos dos processos
  • Atualmente os processos são cadastrados através de formulários, onde o desenvolvedor informa as atividades, transições, perfis, etc. Depois pode exibir um gráfico do processo. A proposta é encontrar uma ferramenta que faça o contrário: desenhe o fluxo e este sirva de entrada para registrar a estrutura do processo. Possivelmente o fluxo será descrito em uma linguagem de definição que pode ser lida pelo módulo workflow, ou então a nova ferramenta poderia acessar diretamente o banco de dados. Reformular a interface administrativa para que as operações possam ser feitas sobre a imagem do processo. Por exemplo, clicando sobre ícone de uma atividade tem-se acesso às suas propriedades e perfis. Impedir que modificações sejam feitas no fluxo quando existirem instâncias dependentes das atividades.

• Implantar um gerador de código
  • Com este novo recurso, quando o gráfico do processo estiver concluído, será gerado o código básico para que o processo funcione. Assim sendo, o desenvolvedor ficaria com a tarefa de preencher lacunas no código, como por exemplo os formulários e métodos associados aos botões.

• Criar um mecanismo autenticado para inclusão de instâncias
  • Com esta funcionalidade, sistemas externos poderão iniciar instâncias no workflow, sem passar pelas atividades Start dos processos. Já temos webservice no módulo (porém somente disponível para a Celepar). Verificar se é possível tornar autenticado. Considerar a possibilidade de uso de certificado.

• Criar boletins para processos
  • Implementar uma área, em cada processo, para divulgar as novidades, melhorias e correções. Isso é útil para os usuários acompanharem a evolução dos processos.

• Substituir o conector Ajax
  • Trocar o atual conector Ajax (connector.js / controller.php) usado na interface do módulo, pelo framework nanoAjax, que já é utilizado nos processos. Substituir todas as chamadas do antigo conector pelo novo.

• Criar um controle de tempo de execução para atividades
  • Implementar uma nova funcionalidade para atividades em que possa ser definido um tempo máximo de permanência da mesma com o usuário que detém a posse. Criar um job genérico que rode diariamente e selecione as atividades que expiraram os prazos, e de alguma forma comunicar o usuário ou um administrador designado.

• Prover uma auditoria de queries executadas nas tabelas do módulo Workflow.
  • Quando alguma alteração nos dados do processo for realizada, na interface de administração, registrar o evento em banco de dados para se ter um histórico dos acontecimentos. Por exemplo, ativação/desativação de processo, alteração de parâmetros, etc;
  • Verificar a possibilidade de executar triggers nas tabelas do módulo Workflow, para logar a atividade sql. Cuidar para não impactar na performance geral do banco;
  • Outra abordagem pode ser inserção de código nos principais eventos administrativos, para logar as modificações;

Requisitos para o MVC

• Definir uma nova estrutura de diretórios para os processos. Considerar a experiência do Serpro da Bahia. Analisar a estrutura de outros frameworks como o Cake e Simphony;

• Criar um novo modelo de execução de atividades
  • Criar uma classe base para execução de atividades, contendo métodos básicos como inicialização, finalização, cancelamento, execução, continuação de uma instância, execução de ajax, comunicação com o engine e outros que um estudo mais detalhado venha a revelar;
  • Incluir também objetos para as classes já existentes hoje como regex, factory, validações;
  • O desenvolvedor irá criar uma classe para cada uma de suas atividades, que estenderá a superclasse e que contenha atributos do tipo objeto para as classes controller e model da atividade;
  • Implementar um método run que possa ser executado para iniciar a atividade. Continuarão a existir as classes de controller e model da atividade, em separado. Continuarão a existir as classes basecontroller e basemodel;
  • O desenvolvedor poderá sobrescrever os métodos de evento da superclasse: inicialização, finalização, cancelamento, transição. Em especial a transição pode servir ao desenvolvedor para obter o id da instância, após o encerramento de uma atividade start;
  • Criar uma nova classe run_activity, que será responsável por instanciar a classe da atividade e executá-la. Usar uma função global para obter este objeto, de modo a garantir que somente o código da classe seja carregado;
  • Criar um mecanismo que impeça o código do usuário criar objetos das classes do módulo e do engine. Como sugestão poderia ser uma análise no call_back procurando a origem da instanciação;
  • Acomodar os processamentos pré e pós execução das atividades (agente de correio) em outro local do código;

• Criar uma camada de visualização para encapsular o gerador de templates Smarty
  • Criar componentes para os diversos elementos de formulário, como textarea, inputs, etc;
  • Implementar o conceito de container, que agrega componentes em uma mesma linha do template;
  • Criar componente de ocultação e um array de botões submit;
  • Prever também o encapsulamento dos plugins smarty criados para o workflow (select users, etc);
  • Esta camada será representada pela classe baseview, que terá atributos para os componentes adicionados ao objeto view;
  • O submit fará uma chamada ao dispatch. O dispatch fará a verificação prévia de campos obrigatórios. Caso não tenha erros irá chamar o método de validação em php, via ajax. Caso sem erros, será montado o array request na model;
  • Carregar no template os arquivos javascript indicados pelo desenvolvedor. Possibilitar associar funções javascript aos componentes;
  • O objeto view deverá carregar os dados preparados as outras camadas e mesclar no template;
  • A criação do objeto smarty ficará ao encargo da camada view.