2. 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 o
processo de venda.

4. Gxflow é uma ferramenta integrada ao GeneXus que nos permite e brinda:
1) Modelar os processos da empresa: Diagramar os processos nos da vantagem de poder
mudar a ordem de suas tarefas, tirar ou incluir tarefas novas e/ou mudar as condições de sua
execução, sem tocar o código dos mesmos objetos.
2) Definir segurança: Se definem regras e quais podem executar quais tarefas. Isto evita ter
que 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: Em
GeneXus X é muito prático e simples relacionar os objetos GeneXus desenvolvidos que
implementam 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 modelado
os processos integrados com o desenvolvimento da aplicação operacional.
5) Etapa de execução que brinda proatividade: Cada usuário ao executar, de primeira
verá as tarefas que precisam ser feitas (não terá que buscar na aplicação o trabalho
pendente).
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 para
fazer mostras aos clientes.

8. A partir do “Folder View” se arrasta um objeto transação ou web panel ao diagrama, se
estará agregando una “tarefa / atividade interativa” ao fluxo, e a mesma já ficará com
dito objeto associado para a etapa de execução. Também dita “tarefa / atividade
interativa” agregada ao diagrama, ficará automaticamente nominada com o mesmo
nome que a transação ou web panel que foi arrastado.
Por outro lado se agregar uma “tarefa/atividade interativa” ao diagrama arrastando o
símbolo correspondente a partir do toolbox disponível para confeccionar diagramas de
processos de negócios, depois será necessário associar a dita tarefa um objeto
transação ou web panel definida na KB. Para isso, simplesmente de ter agregado a
tarefa no diagrama e a tendo selecionada, terá que editar suas propriedades (F4 para
abrir o diálogo de propriedades) e completar a propriedade Web Application com o
objeto que corresponda, assim como a propriedade Name com o nome que se queira
dar a “tarefa/atividade interativa”.

9. Não serão descritos todos os símbolos disponíveis na toolbox de workflow, mas sim
os 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 do
fluxo de atividades se necessita avaliar uma condição porque dependendo dela ser
cumprida ou não, siga com certo fluxo de atividades ou outro, por isso que contamos
com o símbolo de condição.

10. Bastará agregar um símbolo de condição (losango verde) ao diagrama (conectado desde a
atividade 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 associada
uma condição a ser avaliada (fazendo clique duplo em cada rota verde, um editor é aberto
para ingressar sua condição associada); e em tempo de execução do diagrama, como
veremos mais adiante, quando se chegue a condição na execução do processo, dependendo
de quais avaliações for verdadeira continua com a execução de uma rota e seu fluxo de
atividades 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 um
processo maciço) que será executado no servidor.
É agregado arrastando o símbolo correspondente desde a toolbox, depois será necessário
associar 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 tendo
selecionado, terá que editar suas propriedades (F4 para abrir o diálogo de propriedades) e
completar na propriedade Procedure o nome do procedimento que corresponda. Assim
mesmo 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.

11. Aqui vemos que temos confeccionado o diagrama de processo que criamos. Temos
agregado tarefas interativas e uma condição.
Vemos que com um duplo clique nas rotas verdes que partam da condição, se abre
o editor de condições para editar cada condição (em caso dela se cumprir uma ou
outra se seguirá com certo fluxo de atividades ou outro).
Em seguida veremos o conceito de “Dados Relevantes” que é fundamental para
compreender qual informação podemos envolver nas condições.

13. Quando são definidos dados relevantes em um diagrama de processo (definidos automaticamente
ou 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, é totalmente
análoga a sintaxe do nome de um atributo (e além disso tem um tipo de dados associado)...mas
não é um atributo, mas sim um “dado global” que será conhecido em todo esse diagrama de
processo.
Ou seja que ao ver num diagrama de processo um dado relevante de nome InvoiceId, não
devemos confundir com o atributo definido na KB.
Todavia, para os dados relevantes que são definidos automaticamente com mesmo nome e tipo
que as chaves primárias das transações (como neste exemplo: InvoiceId), tem uma
correspondência automática entre o dado relevante e o atributo PK, no sentido que quando
modelamos o diagrama “o dado relevante é o dado global conhecido nesse contexto” e nos objetos
GeneXus 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 do
desenvolvimento da funcionalidade respectivamente). Em outras palavras tem um mapa
automático entre o dado relevante com o mesmo nome e tipo que um atributo chave primária com
dito atributo chave primária.
A maioria de Dados Relevantes num diagrama de processo se correspondem com as chaves
primárias, também existem casos que surge a necessidade de definir explicitamente outros dados
relevantes. Em seguida veremos exemplos, e também veremos como definir correspondência
entre dados relevantes que definiremos em um diagrama de processo e variáveis que deveremos
definir nos objetos GeneXus associados as atividades do diagrama (veremos que utilizaremos
tipos 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”).

14. Inicialmente explicamos que quando trabalhamos no GeneXus com workflow, realizamos
basicamente 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 previamente
definidos alguns objetos GeneXus que arrastamos ao diagrama, e vamos desenvolvendo outros
objetos e incorporá-los ao diagrama também. Mais adiante veremos como atribuir regras as
diferentes atividades do diagrama. Por enquanto a idéia é que contamos na KB com uma
transação “Invoice”, a qual foi arrastada ao diagrama como primeira atividade interativa do
processo e mais adiante definiremos que esta tarefa interativa poderá ser executada pelas
vendedoras da empresa.
Quando uma vendedora ingresse uma venda (através da transação “Invoice”), entrará o cliente, a
mercadoria solicitada, as quantidades, a forma de pagamento solicitada pelo cliente, gravará a
venda 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 se
trata, o montante, a forma de pagamento), e o supervisor deverá aceitar ou recusar a venda. Esta
segunda 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 mesmo
nome e tipo de dado que o atributo InvoiceId), o qual significa que dito dado se conhece ao longo
de 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 o
atributo InvoiceId. No form da web panel “Authorization” serão visualizados os dados da fatura, o
limite de crédito e o saldo do limite de crédito do cliente e possibilita ter o histórico das faturas

15. Vale explicar que quando trabalhamos com workflow em GeneXus, no código dos objetos já não
podemos chamar de um objeto a outro. Por outro lado, nos diagramas de processos que
confeccionamos 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 permite
criar instancias dos processo que definimos (por exemplo poderão ser criadas N instancias do
processo de venda definido). Ao criar uma nova instancia de processo, começa a execução da
primeira atividade (será mostrada a trn “Invoice” para isso, e se foram definidas, será validado que
em particular essa atividade seja realizada por uma vendedora, seguirá a segunda atividade (para ser
efetuada por ele rol que corresponda, que em nosso exemplo é um supervisor) e assim
sucessivamente e as atividades da instancia do processo vão sendo finalizadas e executando as
seguintes atividades até concluir dita instancia do processo.
De modo que não codificamos mais calls nos objetos GeneXus, e caso se necessite mudar a ordem
de precedências das atividades em um processo, ou agregar ou tirar atividades, assim como mudar
as condições de execução das atividades, fazemos no diagrama de processo sem tocar o código dos
objetos no diagrama de processo.
Algo que se deve notar é que não definimos calls no código mesmo dos objetos, mas definimos regra
parm nos objetos, se definimos a regra parm nos objetos GeneXus que participam num diagrama de
processo. Isto é porque os objetos são chamados – com outro esquema de trabalho do que
conhecíamos – e precisa passar a informação necessária ... Assim é que são recebidos por
parâmetro os atributos chaves primárias que são análogas aos dados relevantes no diagrama de
processo (e que tem uma correspondência entre esses conceitos).
Agora que isso foi explicado, seguiremos estudando passo a passo a implementação da segunda
atividade do processo que estamos confeccionando. A web panel “Authorization” recebe por
parâmetro o atributo InvoiceId, que mostra em seu form informação para a tomada de decisão da
autorizaçã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 o
seguinte:
1) No tab “Relevant Data” do diagrama de processo, precisa criar um dado relevante (por exemplo de
nome: InvoiceAuthorized) de tipo Numeric.
2) Na web panel "Authorization“ terá que ler o dado relevante e carregá-lo em cada evento da web
panel, 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:

16. Vimos que definimos um dado relevante no diagrama de processo (de nome InvoiceAuthorized) e
depois na web panel “Authorization” se lê o dado relevante na variável &wfAuthoriz de tipo
WorkflowApplicationData. O tipo de dados WorkflowApplicationData significa “dado relevante”.
Também temos definido na web panel uma segunda variável de tipo WorkflowProcessInstance. O
tipo de dados WorkflowProcessInstance significa “instancia de processo”. Ou seja se analisarmos
a 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 nome
do dado relevante tal como foi definido no diagrama de processo) pertencente a instancia do
processo 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 a
propriedade Numeric do tipo de dado WorkflowApplicationData, por estar atribuindo um valor
numérico).
Por último em cada evento se faz return, porque já foi recuperado o valor do dado relevante, se foi
carregado 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 as
atividades de um diagrama de processo (exceto quando se trata de dados relevantes com mesmo
nome e tipo que as chaves primárias, já que nesses casos são recebidos por parm os atributos
primários diretamente e pronto).

18. 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 fluxo
podem ser inferidos atributos através dos Dados Relevantes correspondentes a chaves
primárias, e avaliar diretamente atributos.

19. 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.

20. Se o supervisor autoriza uma venda, a seguinte atividade no diagrama é
“InvoiceToBePrepared”. Esta atividade interativa tem uma web panel associada que
recebe por parâmetro o atributo InvoiceId, mostra a informação da venda autorizada e
tem um botão para que a pessoa do pacote quando terminar de preparar a mercadoria o
pressione. 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 o
atributo InvoiceId, mostra a informação da venda preparada e tem um botão para emitir a
fatura. Quando uma vendedora pressionar este botão, o evento associado ao botão
chama um procedimento que grava na invoice o número de fatura formal e emitirá a
impressão.
A última atividade deste fluxo que estamos explicando, corresponde a distribuição da
mercadoria. Esta atividade também tem uma web panel associada que mostra os dados
da 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 registradas
durante a execução do workflow.

22. 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 a
modalidade “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 a
aplicação na modalidade “Prototyper” inicialmente são limpas todas as instancias de testes
anteriores 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 se
requer criar usuários (para login) cada um deles com a lista de regras que o corresponda, já
que neste caso a segurança é controlada.