wiki:WF/IntroducaoaoGalaxia

Version 13 (modified by viani, 16 years ago) (diff)

--

Conceitos Básicos

WikiInclude(WF/tableofcontents)?

Este documento é uma adaptação do original sobre o motor de workflow Galaxia. Veja os créditos sobre este documento ao final desta página.

Alguns conceitos empregados pelo motor de workflow:

Processo

Um processo é definido como um conjunto de atividades que devem ser executadas para atingir um objetivo. Um processo no Galaxia equivale a um processo de negócio da empresa. As atividades do processo são conectadas entre si através de transições, definindo o que deve ser feito quando um atividade for completada.

Atividade

Uma atividade é algo que deve ser feito como parte de um processo. No Galaxia as atividades são mapeadas a scripts PHP (páginas), de modo que uma atividade pode fazer qualquer coisa possível de ser feita com PHP.

Transição

As transições definem qual atividade, ou atividades, vem antes que uma atividade seja executada e depois que for completada.

Perfil

Perfis definem quem pode executar uma atividade. Os perfis são criados a nível de processo. Aos perfis associamos usuários e grupos.

Instância

Uma instância é um processo sendo executado. Uma instância é criada quando um processo é iniciado. A instância passa pelas diversas atividades do processo até ele terminar.

Ítem de trabalho

Quando uma atividade é completada, um ítem de trabalho é adicionado à instância. Os ítens de trabalho representam atividades realizadas.

Tipos de Atividades

Existem oito tipos de atividades que podem ser utilizadas para desenhar um processo:

Start

End

Activity

Switch

Split

Join

Standalone

View

Start

Atividades do tipo start são representadas por um círculo. Cada processo deve ter ao menos uma atividade start. A atividade start é a responsável por criar a instância do processo. É a única que pode ser executada sem que o processo esteja instanciado. Um processo pode ter mais de uma atividade start, mas isto não é muito comum. Nenhuma transição pode resultar como entrada de uma atividade start, e deve haver apenas uma transição de saída para a atividade start.

End

A atividade end representa o fim do processo. Quando uma instância chega à atividade end, o processo é considerado concluído. Processos podem ter apenas uma atividade end. Isto não significa que uma processo não possa terminar de diferentes maneiras, mas a atividade end é o ponto final de todas. A maneira como o processo finaliza, depende das atividades visitadas anteriormente. No Galaxia a atividade end é representada usando um círculo duplo. Uma atividade end pode ter diversas transições de entrada, mas somente uma transição de saída é permitida.

Regras: um processo para ser válido, deve ter ao menos um atividade start e apenas uma atividade end. Deve existir ao menos um caminho que leve do início ao fim.

Normal

Atividades normais não tem nenhum significado especial. Elas são usadas para representar coisas que devam ser executadas como parte do processo. Um retângulo é usado para representar estas atividades. Atividades do tipo normal podem receber diversas transições de entrada, mas apenas uma transição de saída.

Switch

Uma atividade de decisão representa um ponto onde o processo se divide em outros fluxos. As instâncias que chegam a uma atividade de decisão são avaliadas e dependendo do resultado a instância é desviada para um fluxo ou outro. Assim, as atividades de decisão podem ter muitas transições de entrada e muitas transições de saída. Atividades de decisão são representadas por um diamante.

Split

Algumas vezes duas ou mais atividades em um processo podem ser realizadas em paralelo de forma independente. Uma atividade split é usada para fragmentar a instância em muitas atividades. É verdadeiro afirmar que uma instância pode estar em muitas atividades ao mesmo tempo. Atividades split representam subflows em um workflow. Uma atividade split pode receber diversas transições de entrada e pode ter diversas transições de saída. Atividades de split são representadas por um triângulo.

Join

Uma atividade join é usada para reagrupar instâncias que foram separadas por uma atividade split. Quando uma instância chega a uma atividade join, o motor verifica se a instância também está presente em alguma outra atividade. Se estiver, a instância deve aguardar, na atividade join até que todas as cópias da instânicia alcancem a atividade join. Quando todas as cópias da instância chegarem na atividade join, a instância será direcionada para a próxima atividade. As atividades join podem ter diversas transições de entrada (mais de uma é esperada) e podem ter apenas uma atividade de saída. Atividades join são representadas por um triângulo invertido.

Standalone

Atividades isoladas são representadas por hexagonos. Uma atividade isolada não é parte do fluxo normal do processo, e por isso não está relacionada à instâncias dos processos. Uma atividade isolada pode ser executada quantas vezes o usuários quiser. Estas atividades são ideias para processamento de dados relacionados ao processos, tabelas, adicionar ítens, remover ítens, etc. Muitos processos podem ser definidos como um conjuntos de tarefas isoladas, se não existir um relacionamento entre as atividades do processo. Outros processos consistem em um fluxo principal e um conjunto auxiliar de atividades isoladas. As atividades isoladas não podem ter transições de entrada e saída.

View

Este é um novo tipo de atividade introduzido no eGroupware. O padrão é exibir dados de uma instância, ao usuário, utilizando um formulário padrão fornecido pelo módulo de workflow. Caso existe uma atividade view, no processo, ela será utilizado para visualização da instância, ao invés do formulário padrão. Considere este tipo de atividade como se fosse um template para as instâncias do processo, para atender às necessidades estéticas. Pode haver apenas uma atividade view por processo.

Propriedades das atividades: Interatividade e Autoroteamento

Interatividade

No Galaxia, as atividades podem ser automáticas ou interativas. As atividades interativas são as atividades que requerem algum tipo de interação com o usuário. Estas atividades usualmente apresentam um formulário, solicitando o preenchimento de alguns campos. Após submeter a informação, a atividade é completada. As atividades automáticas, ao contrário, são executadas automaticamente pelo motor Galaxia, sem a interação do usuário. Frequentemente as atividades automáticas estão ocultas ao usuário.

Autoroteamento

Quando uma atividade é completada, o motor pode ou não automaticamente rotear a instância para próxima atividade no processo. Atividades com a propriedade "autorouting" marcada, irão rotear a instância para a próxima atividade do processo, quando a atividade for completada. Se a atividade não for "autorouting", o usuário deverá enviar a atividade, após ser completada, para permitir que o processo continue. Isto pode ser usado em atividades onde o usuário pode editar informação e revisar muitas vezes antes de decidir que a atividade está completa.

Algumas regras para a representação gráfica de fluxos de processos:

Setas de transição saindo de uma atividade de roteamento automático são vermelhas

Setas de transição saindo de uma atividade de roteamento não automático são pretas

Atividades interativas tem a borda azul

Atividades não interativas tem a borda preta

intro_galaxia_routeinter.png

Processo exemplo

A imagem abaixo mostra o gráfico de um processo. Este processo define requisições à biblioteca dos empregados. A atividade start (interativa) é onde o usuário informa o nome do livro e autor. Então o sistema deve verificar se o livro está disponível, na atividade "check book". Se o livro está disponível, o sistema envia o livro ao usuário, e a solicitação é aceita. Senão, a solicitação é rejeitada. As atividades automáticas "accepted" e "rejected" enviam um email para o usuário notificando-o do resultado da sua solicitação. A atividade isolada "view books" pode ser usada pelo usuário ou pelo sistema para pesquisar o catálogo. As atividades interativas estão marcadas com a borda azul.

intro_galaxia_cd_loans.png

Créditos

Galaxia is based on  OpenFlow

Marc Laporte was the first member of the Tiki team to suggest adding a Workflow engine to  Tiki.

This wikified version was originally a copy/paste from the  PDF Galaxia introduction on SourceForge. This document was originally produced by Garland Foster, Richard Moore and Eduardo Polidor, and edited by Georger Araujo to be included in workflow.tw.o.

Algumas alterações foram feitas no texto original para adaptá-lo às modificações realizadas pela Celepar no módulo de Workflow do Expresso.

Attachments