16 gx flow-curso-gxxbr

273 visualizações

Publicada em

0 comentários
0 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
273
No SlideShare
0
A partir de incorporações
0
Número de incorporações
6
Ações
Compartilhamentos
0
Downloads
14
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

16 gx flow-curso-gxxbr

  1. 1. 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.
  2. 2. 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.
  3. 3. 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”.
  4. 4. 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.
  5. 5. 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.
  6. 6. 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.
  7. 7. 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”).
  8. 8. 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
  9. 9. 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:
  10. 10. 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).
  11. 11. 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.
  12. 12. 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.
  13. 13. 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.
  14. 14. 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.

×