wiki:WF/IntroducaoaoGalaxia

Version 1 (modified by trac, 12 years ago) (diff)

--

Galaxia é um workflow baseado em atividades. Os processos de workflow são implementados como um conjunto de atividades que devem ser completadas para atingir um resultado. As atividades do Galaxia são representadas por scripts PHP. São três os principais módulos do Galaxia: "administração de processos", "controle de processos" e "Interface do usuário". Segue uma descrição conceitual do Galaxia:

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 usá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 sete tipos de atividades que podem ser utilizadas para desenhar um processo:

Start

End

Activity

Switch

Split

Join

Standalone

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 activities

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 activities

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 activities

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 activities

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 activities

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.

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

http://doc.workflow.celepar.parana/wiki/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.

http://doc.workflow.celepar.parana/wiki/intro_galaxia_cd_loans.png

Módulos

Galaxia define três módulos:

Process manager

Process monitor

User interafce

Process manager

O gerenciador de processo é um módulo usado para criar/atualizar processos. Este módulo é normalmente usado pelo administrador ou pelos designers de processo. O gerenciador de processos cobre as seguintes funcionalidades:

Criar processos e versões de processos

Renomear e deletar atividades

Definir as atividades dos processos

Ver um gráfico das atividades do processo

Checar se o processo é válido

Ativar/desativar processos

Editar o código fonte das atividades (php) e templates (atividades interativas)

Definir perfis e definir quais perfis tem permissão para executar quais atividades

Mapear perfis a usuários

Salvar processos (processos são salvos usando XML)

Carregar processos a partir de arquivos XML

Process monitor

O monitor de processos é usado para controlar a execução dos processos. A lista abaixo mostras algumas funcionalidades da API do monitor de processos:

Listar processos, atividades e o número de instâncias por atividade

Listar instâncias ativas e exceções

Percorrer a lista de instâncias e modificar suas propriedades

Enviar uma instância para alguma atividade

Assinalar ou reassinalar uma instância para um usuário

Abortar instâncias

Ver estatísticas sobre os processos completados, tempo de execução, e tempo por atividade.

User interface

A interface do usuário é usuada pelos usuários para ver os processos que eles podem executar, ou as atividades que lhe estão atribuídas, aguardando a sua intervenção. Os usuários podem executar atividades, ver os resultados e algumas estatísticas sobre o trabalho atribuído a eles.

Resumo

Este documento apresenta uma introdução ao "Galaxia", um motor de workflow em PHP, que pode ser usado em qualquer projeto PHP e que é fornecido juntamente com os módulos do Tiki. Galaxia pode ser usado para criar novas funcionalidades em qualquer aplicação PHP, definindo processos, onde todas as atividades relacionadas à funcionalidade estão agrupadas. Se necessário, o Galaxia pode definir o fluxo das atividades de um processo, conceito de workflow. A flexibilidade e extensão do motor abrem muitas áreas novas e interessantes para qualquer projeto PHP que use o produto.

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