No exemplo se está mostrando um workflow de uma empresa que vende mercadoria“por atacado”.

Podem ser observados claramente as tarefas consecutivas seguintes para fazer oprocesso de venda.

Gxflow é uma ferramenta integrada ao GeneXus que nos permite e brinda:

1) Modelar os processos da empresa: Diagramar os processos nos da vantagem de podermudar a ordem de suas tarefas, tirar ou incluir tarefas novas e/ou mudar as condições de suaexecução, sem tocar o código dos mesmos objetos.

2) Definir segurança: Se definem regras e quais podem executar quais tarefas. Isto evita terque incluir código para a segurança nos objetos.

3) Definir calendários, alertas, deadlines

4) Etapas de Modelado e Desenvolvimento de aplicação operacional integradas: EmGeneXus X é muito prático e simples relacionar os objetos GeneXus desenvolvidos queimplementam a aplicação operacional com os diagramas que modelam os processos.Veremos como se arrastam os objetos aos diagramas e a prática resultante em ter modeladoos processos integrados com o desenvolvimento da aplicação operacional.

5) Etapa de execução que brinda proatividade: Cada usuário ao executar, de primeiraverá as tarefas que precisam ser feitas (não terá que buscar na aplicação o trabalhopendente).

6) Auditoria: GXflow permite ver o que está em cada usuário, quanto tempo leva cada tarefa,etc.

7) Melhor entendimento: para um membro novo da equipe de trabalho, e também parafazer mostras aos clientes.

A partir do “Folder View” se arrasta um objeto transação ou web panel ao diagrama, seestará agregando una “tarefa / atividade interativa” ao fluxo, e a mesma já ficará comdito objeto associado para a etapa de execução. Também dita “tarefa / atividadeinterativa” agregada ao diagrama, ficará automaticamente nominada com o mesmonome que a transação ou web panel que foi arrastado.

Por outro lado se agregar uma “tarefa/atividade interativa” ao diagrama arrastando osímbolo correspondente a partir do toolbox disponível para confeccionar diagramas deprocessos de negócios, depois será necessário associar a dita tarefa um objetotransação ou web panel definida na KB. Para isso, simplesmente de ter agregado atarefa no diagrama e a tendo selecionada, terá que editar suas propriedades (F4 paraabrir o diálogo de propriedades) e completar a propriedade Web Application com oobjeto que corresponda, assim como a propriedade Name com o nome que se queiradar a “tarefa/atividade interativa”.

Não serão descritos todos os símbolos disponíveis na toolbox de workflow, mas simos símbolos básicos que no início devemos conhecer.

Símbolo: Condição

Quando se está modelando um diagrama de processo e em determinada parte dofluxo de atividades se necessita avaliar uma condição porque dependendo dela sercumprida ou não, siga com certo fluxo de atividades ou outro, por isso que contamoscom o símbolo de condição.

Bastará agregar um símbolo de condição (losango verde) ao diagrama (conectado desde aatividade prévia) e a partir do losango poderão sair N rotas (que terão a cor verde também).Cada uma destas rotas verdes que partem de um losango de condição, deverá ter associadauma condição a ser avaliada (fazendo clique duplo em cada rota verde, um editor é abertopara ingressar sua condição associada); e em tempo de execução do diagrama, comoveremos mais adiante, quando se chegue a condição na execução do processo, dependendode quais avaliações for verdadeira continua com a execução de uma rota e seu fluxo deatividades segue, ou outro.

Em breve veremos exemplos de definição de condições (sintaxe e possibilidades).

Símbolo: Batch Activity

Permite agregar a um diagrama de processo de negócio, um processo batch (por exemplo umprocesso maciço) que será executado no servidor.

É agregado arrastando o símbolo correspondente desde a toolbox, depois será necessárioassociar a dito processo batch um objeto procedimento definido na KB. Para isso,simplesmente depois de ter agregado o símbolo de processo batch no diagrama e tendoselecionado, terá que editar suas propriedades (F4 para abrir o diálogo de propriedades) ecompletar na propriedade Procedure o nome do procedimento que corresponda. Assimmesmo terá que atribuir um nome em sua propriedade Name.

Se por outro lado a partir do “Folder View” se arrasta um determinado procedimento, estarásendo agregado ao diagrama como processo batch que executará no servidor; e o mesmo jáficará com dito procedimento e nome associado para a etapa de execução.

Aqui vemos que temos confeccionado o diagrama de processo que criamos. Temosagregado tarefas interativas e uma condição.

Vemos que com um duplo clique nas rotas verdes que partam da condição, se abreo editor de condições para editar cada condição (em caso dela se cumprir uma ououtra se seguirá com certo fluxo de atividades ou outro).

Em seguida veremos o conceito de “Dados Relevantes” que é fundamental paracompreender qual informação podemos envolver nas condições.

Quando são definidos dados relevantes em um diagrama de processo (definidos automaticamenteou definidos explicitamente) algo a ser dito é que não são os mesmos atributos definidos na KB.

A sintaxe do nome de um dado relevante definido em um diagrama de processo, é totalmenteanáloga a sintaxe do nome de um atributo (e além disso tem um tipo de dados associado)...masnão é um atributo, mas sim um “dado global” que será conhecido em todo esse diagrama deprocesso.

Ou seja que ao ver num diagrama de processo um dado relevante de nome InvoiceId, nãodevemos confundir com o atributo definido na KB.

Todavia, para os dados relevantes que são definidos automaticamente com mesmo nome e tipoque as chaves primárias das transações (como neste exemplo: InvoiceId), tem umacorrespondência automática entre o dado relevante e o atributo PK, no sentido que quandomodelamos o diagrama “o dado relevante é o dado global conhecido nesse contexto” e nos objetosGeneXus que desenvolvemos as atividades do diagrama “recebemos no parm o atributo PK”(tratando-se da mesma informação ou no contexto do diagrama, ou no contexto dodesenvolvimento da funcionalidade respectivamente). Em outras palavras tem um mapaautomático entre o dado relevante com o mesmo nome e tipo que um atributo chave primária comdito atributo chave primária.

A maioria de Dados Relevantes num diagrama de processo se correspondem com as chavesprimárias, também existem casos que surge a necessidade de definir explicitamente outros dadosrelevantes. Em seguida veremos exemplos, e também veremos como definir correspondênciaentre dados relevantes que definiremos em um diagrama de processo e variáveis que deveremosdefinir nos objetos GeneXus associados as atividades do diagrama (veremos que utilizaremostipos de dados workflow, propriedades e métodos, para que variáveis “a nível de objeto”correspondam com dados relevantes definidos “a nível do diagrama de processo”).

Inicialmente explicamos que quando trabalhamos no GeneXus com workflow, realizamosbasicamente os seguintes passos:

• Criar objetos GeneXus

• Criar diagramas de processos de negócios

• Associar objetos GeneXus a diagramas de processos de negócios

• Executar processo

Estamos assim confeccionando um diagrama de processo em nossa KB; tínhamos previamentedefinidos alguns objetos GeneXus que arrastamos ao diagrama, e vamos desenvolvendo outrosobjetos e incorporá-los ao diagrama também. Mais adiante veremos como atribuir regras asdiferentes atividades do diagrama. Por enquanto a idéia é que contamos na KB com umatransação “Invoice”, a qual foi arrastada ao diagrama como primeira atividade interativa doprocesso e mais adiante definiremos que esta tarefa interativa poderá ser executada pelasvendedoras da empresa.

Quando uma vendedora ingresse uma venda (através da transação “Invoice”), entrará o cliente, amercadoria solicitada, as quantidades, a forma de pagamento solicitada pelo cliente, gravará avenda com um número interno (não o nro da fatura formal) e aí terminará a primeira atividade.Depois essa venda deverá ser avaliada por um supervisor (quem vai avaliar de qual cliente setrata, o montante, a forma de pagamento), e o supervisor deverá aceitar ou recusar a venda. Estasegunda atividade interativa do processo foi agregada ao diagrama arrastando a web panel“Authorization”.

Então, a nível do diagrama de processo contamos com o dado relevante InvoiceId (com o mesmonome e tipo de dado que o atributo InvoiceId), o qual significa que dito dado se conhece ao longode todo o fluxo de atividades. E no que se refere aos objetos GeneXus relacionados ao diagrama,a web panel “Authorization” implementa a 2da atividade do processo e recebe por parâmetro oatributo InvoiceId. No form da web panel “Authorization” serão visualizados os dados da fatura, olimite de crédito e o saldo do limite de crédito do cliente e possibilita ter o histórico das faturas

Vale explicar que quando trabalhamos com workflow em GeneXus, no código dos objetos já nãopodemos chamar de um objeto a outro. Por outro lado, nos diagramas de processos queconfeccionamos já ficam implícitas as chamadas entre atividades consecutivas.

Mais adiante veremos que na etapa de execução vamos executar uma aplicação que nos permitecriar instancias dos processo que definimos (por exemplo poderão ser criadas N instancias doprocesso de venda definido). Ao criar uma nova instancia de processo, começa a execução daprimeira atividade (será mostrada a trn “Invoice” para isso, e se foram definidas, será validado queem particular essa atividade seja realizada por uma vendedora, seguirá a segunda atividade (para serefetuada por ele rol que corresponda, que em nosso exemplo é um supervisor) e assimsucessivamente e as atividades da instancia do processo vão sendo finalizadas e executando asseguintes atividades até concluir dita instancia do processo.

De modo que não codificamos mais calls nos objetos GeneXus, e caso se necessite mudar a ordemde precedências das atividades em um processo, ou agregar ou tirar atividades, assim como mudaras condições de execução das atividades, fazemos no diagrama de processo sem tocar o código dosobjetos no diagrama de processo.

Algo que se deve notar é que não definimos calls no código mesmo dos objetos, mas definimos regraparm nos objetos, se definimos a regra parm nos objetos GeneXus que participam num diagrama deprocesso. Isto é porque os objetos são chamados – com outro esquema de trabalho do queconhecíamos – e precisa passar a informação necessária ... Assim é que são recebidos porparâmetro os atributos chaves primárias que são análogas aos dados relevantes no diagrama deprocesso (e que tem uma correspondência entre esses conceitos).

Agora que isso foi explicado, seguiremos estudando passo a passo a implementação da segundaatividade do processo que estamos confeccionando. A web panel “Authorization” recebe porparâmetro o atributo InvoiceId, que mostra em seu form informação para a tomada de decisão daautorização ou recusa e para isso tem 2 botões “Authorize” e “Refuse” respectivamente.

Se nosso objetivo é carregar uma variável com valor 1 no evento “Authorize” e com valor 0 no evento“Refuse”, e queremos que o valor atribuído “seja visto” no diagrama de processo, bastará realizar oseguinte:

1) No tab “Relevant Data” do diagrama de processo, precisa criar um dado relevante (por exemplo denome: InvoiceAuthorized) de tipo Numeric.

2) Na web panel "Authorization“ terá que ler o dado relevante e carregá-lo em cada evento da webpanel, assim:

Sendo:

&wfAuthoriz: uma variável definida na web panel, de tipo de dados é: WorkflowApplicationData

&wfProcessInstance: uma variável definida na web panel, de tipo de dados:

Vimos que definimos um dado relevante no diagrama de processo (de nome InvoiceAuthorized) edepois na web panel “Authorization” se lê o dado relevante na variável &wfAuthoriz de tipoWorkflowApplicationData. O tipo de dados WorkflowApplicationData significa “dado relevante”.

Também temos definido na web panel uma segunda variável de tipo WorkflowProcessInstance. Otipo de dados WorkflowProcessInstance significa “instancia de processo”. Ou seja se analisarmosa primeira linha codificada dos 2 eventos, estamos recuperando na variável &wfAuthoriz (de tipo“dado relevante”) o valor do dado relevante de nome ‘InvoiceAuthorized’ (entre aspas vai o nomedo dado relevante tal como foi definido no diagrama de processo) pertencente a instancia doprocesso que está sendo executado.

Depois na segunda linha codificada em ambos eventos, se está atribuindo a variável&wfAuthoriz (de tipo “dado relevante”) o valor 0 ou 1 segunda corresponda (utilizando apropriedade Numeric do tipo de dado WorkflowApplicationData, por estar atribuindo um valornumérico).

Por último em cada evento se faz return, porque já foi recuperado o valor do dado relevante, se foicarregado o valor desejado e se deseja culminar com a execução desta atividade.

Desta maneira então lemos e carregamos dados relevantes nos objetos GeneXus associados asatividades de um diagrama de processo (exceto quando se trata de dados relevantes com mesmonome e tipo que as chaves primárias, já que nesses casos são recebidos por parm os atributosprimários diretamente e pronto).

Com esta solução, não temos necessidade de definir Dado Relevante InvoiceAuthorized,já que temos num atributo a informação se a invoice foi autorizada/recusada… e no fluxopodem ser inferidos atributos através dos Dados Relevantes correspondentes a chavesprimárias, e avaliar diretamente atributos.

A definição de regras a nível da KB na seção de Preferences.

Depois selecionando cada atividade do diagrama e pressionando F4, na propriedade Roles poderáatribuir a lista de regras que dita atividade poderá executar.

Se o supervisor autoriza uma venda, a seguinte atividade no diagrama é“InvoiceToBePrepared”. Esta atividade interativa tem uma web panel associada querecebe por parâmetro o atributo InvoiceId, mostra a informação da venda autorizada etem um botão para que a pessoa do pacote quando terminar de preparar a mercadoria opressione. O evento associado a esse botão, vai chamar um procedimento que gravaránum atributo da invoice, um valor indicador (flag) de que o pacote já foi realizado.

A seguinte atividade é interativa e tem uma panel associada que recebe por parâmetro oatributo InvoiceId, mostra a informação da venda preparada e tem um botão para emitir afatura. Quando uma vendedora pressionar este botão, o evento associado ao botãochama um procedimento que grava na invoice o número de fatura formal e emitirá aimpressão.

A última atividade deste fluxo que estamos explicando, corresponde a distribuição damercadoria. Esta atividade também tem uma web panel associada que mostra os dadosda venda e pressionando um botão, uma proc grava que a mesma foi entregue.

As datas/horários que foram efetuadas cada uma das atividades, ficarão registradasdurante a execução do workflow.

Tem 2 modalidades de execução:

• Prototyper• Full Client

Na seção de Preferences se configura a desejada:

Logicamente a modalidade “Prototyper” está orientada a etapa de prototipação. E amodalidade “Full-Client” a etapa de produção.

Na etapa de prototipação não nos interessa testar a segurança, motivo pelo qual ao executar aaplicação na modalidade “Prototyper” inicialmente são limpas todas as instancias de testesanteriores e é permitido executar todas as atividades sem controlar regras.

Ao executar a aplicação na modalidade “Full-Client”, não se aborta nada inicialmente e serequer criar usuários (para login) cada um deles com a lista de regras que o corresponda, jáque neste caso a segurança é controlada.