Postagem em destaque

Procurando Profissional em Análise de Processos de Negócios, BPM, BPMS e Melhoria de Processos, para atuar na Região Metropolitana de Belo Horizonte?

Marco Gandra Brasileiro – Casado 41 anos - CNH B Nascido em Belo Horizonte e-mail gandraribeiro@gmail.com ...

Pesquisar neste blog

10 de jun de 2013

Modelando seus processos de negócio com o IBM WebSphere Lombardi Edition, Parte 3: Modelagem avançada

Por: Xin Li 
Em: http://www.ibm.com/developerworks/br/websphere/library/techarticles/1112_wang/

A Parte 1 desta série forneceu uma visão geral dos recursos e arquitetura do WebSphere Lombardi V7.1 (a partir de agora chamado de Lombardi). Na Parte 2 você aprendeu como usar os recursos mais comuns do Lombardi, incluindo a definição de processo de negócios (BPD), integração e serviços humanos e de regra para modelar o processo de amostra.
Neste artigo, você aprenderá a usar alguns recursos avançados do Lombardi para enriquecer um processo de negócios, a fim de atender aos requisitos mais complexos, incluindo processos aninhados, marcos, mecanismos de evento, manipulação de exceção e exposição dos serviços da web do Lombardi. Ilustraremos esses recursos usando o cenário de ordem de compra apresentado nas Partes 1 e 2.
Nesta seção, vamos analisar algumas formas de enriquecer os recursos do processo de amostra.
É possível adicionar marcos e um digrama de processo a fim de ilustrar as fases de execução do processo. Para fazer isso, arraste o elemento Milestone até o diagrama de processo e insira um nome para o marco. Por exemplo, é possível adicionar um marco Order Submission para capturar as atividades nas linhas que ocorrem na fase inicial de envio da ordem de um processo, como mostra a Figura 1.

Figura 1. Marcos dentro de um processo
 
Também é possível importar e descompactar o arquivo de exportação .twx do Lombardi na seção Download para passar por toda a definição de processo de negócios.
Além do marco Order Submission, há dois marcos definidos para fases importantes de nosso cenário, como mostra a Figura 1:
  • Marco Order Validation - usado para validar a ordem, incluindo se a ordem precisa da reconfirmação do comprador e da resposta do fornecedor etc.
  • Marco Order Fulfillment – usado para ilustrar as atividades finais de geração, remessa e pagamento da ordem.
É possível usar processos aninhados para conter as atividades que se relacionam dentro de um processo pai. O uso dos processos aninhados permite que você gerencie a complexidade de um processo de negócio, enquanto mantém uma visualização de alto nível do processo geral, representado na definição do processo pai. Cada atividade em uma definição de processo de negócio (BPD) pode ter um processo aninhado anexado a ela, e cada atividade no processo aninhado pode ter um processo aninhado anexado a ela, e assim por diante.
Quando uma atividade implementada por um processo aninhado é acionada no tempo de execução, o processo aninhado anexado é executado. Após a execução completa do processo aninhado, o processo pai retoma sua execução.
Na amostra de processo de ordem de compra, a atividade GenerateOrder na linha ERP é implementada usando um processo aninhado chamado Generate Order, que inclui três atividades: Calculate Price, Select Shipper e Schedule Shipper. A implementação do processo aninhado é parecida com o desenvolvimento geral da BPD.
É possível vincular o processo aninhado à atividade GenerateOrder dentro do processo pai. Para fazer isso, na BPD Purchase Order Process, clique na atividade GenerateOrder e selecione a guia Implementation nas propriedades. Em Implementation, selecione Lombardi Nested Process no menu suspenso. Clique em Select para escolher a BPD na lista de definições de processo de negócio existentes e, em seguida, selecione Generate Order BPD na lista, como mostra a Figura 2.

Figura 2. Implemente uma atividade usando um processo aninhado
 
No marco Oder Validation, todas as atividades são combinadas em um Processo de confirmação da ordem aninhado, como mostra a Figura 3. Com exceção do evento baseado no timer anexado à atividade Buyer Confirms Order, que discutiremos mais tarde, todas as outras atividades e gateways são os mesmos que aqueles implementados nas partes anteriores da série.

Figura 3. Processo de Confirmação de ordem aninhado
 
Nesta seção, você aprenderá algumas maneiras de customizar a manipulação de eventos no processo de amostra.
Antes de entrarmos na implementação da manipulação de eventos, você precisa entender o conceito de Undercover Agent (UCA) do Lombardi. Um UCA é iniciado por um evento que pode ser acionado por uma mensagem ou com base em um planejamento específico. Quando um UCA é iniciado, ele invoca um serviço anexado em resposta ao evento.
Graças à Parte 1 desta série, você já sabe que o Event Manager é a parte do Process Server que manipula o planejamento e enfileiramento do evento. O Event Manager precisa de um UCA para encontrar o serviço que deve executar. Portanto, se você quiser invocar um serviço quando um evento de mensagem recebida for recebido ou se quiser invocar um serviço como resultado de um evento que ocorre em um planejamento regular, crie um UCA Agent. Cobriremos isso com mais detalhes posteriormente nesta seção.
As mensagens recebidas podem ter origem de um serviço da web criado por você ou de uma mensagem que você postou no JMS Listener. Na amostra, usaremos serviços da web para iniciar solicitações de entrada de sistemas externos.
O Lombardi fornece um mecanismo de evento robusto e flexível que ativa o evento no início, durante ou ao final de um processo de tempo de execução. O Lombardi fornece dez tipos de evento diferentes, incluindo os quatro eventos a seguir que usaremos em nosso cenário de amostra:
  • Evento de início - Um evento de início é automaticamente incluído sempre que você cria uma BPD. Use esse evento para modelar o início de um processo ou de um processo aninhado. Há apenas um evento de início em cada BPD.
  • Evento de término - Um evento de término é incluído automaticamente sempre que você cria uma BPD. Após a execução completa de um processo aninhado, o processo pai retoma sua execução.
  • Evento de mensagem intermediário - Uma BPD pode incluir mais de um evento de mensagem intermediário. Use isso para modelar um evento de mensagem recebido durante a execução de um processo. O evento é acionado pelo UCA que você seleciona.
  • Evento baseado no timer - Use o evento baseado no timer para modelar os caminhos ou atrasos de escalação em suas BPDs. Com um evento baseado no timer, é possível especificar um intervalo de tempo antes ou depois da execução de alguma atividade.
No processo aninhado Generate Order do cenário de amostra, o requisito é que o comprador pague pela ordem antes de a atividade Select Shipper ser executada. Isso significa que o processo precisa de um evento de mensagem intermediário para aguardar a notificação de pagamento e, em seguida, executar a atividade Select Shipper.
Vamos selecionar um evento de mensagem intermediário para ilustrar o mecanismo de manipulação de evento no Lombardi:
  1. Crie um evento arrastando um elemento Intermediate Message Event da paleta para o diagrama Generate Order BPD e especifique Wait for Buyer's Payment como o nome. Conecte esse evento de mensagem entre a atividade Calculate Price e a atividade Select Shipper, como mostra a Figura 4.

    Figura 4. Crie um evento de mensagem intermediário

  2. Crie um serviço de integração chamado Payment Integration Service ou use o payment.jar já criado, fornecido para download.
    Na visualização Designer, clique no sinal de adição (+) ao lado de Files na biblioteca e selecione um dos arquivos de servidor para adicionar o arquivo JAR. Na caixa de diálogo New File, clique em Browse para selecionar o arquivo JAR.
    Agora, você pode usar essa classe Java™ externa na integração Java.
  3. Arraste o componente Java Integration da paleta para o diagrama do serviço e use as linhas sequenciais para conectar o componente aos eventos Start e End. Clique no componente Java Integration no diagrama e selecione a opçãoDefinition nas propriedades. Clique em Select ao lado do campo Java Class para escolher o arquivo JAR e a classe do arquivo JAR, como mostra a Figura 5. O tipo de dado de entrada da operação de pagamento nessa classe Java éString e o tipo de dados de saída é decimal.

    Figura 5. Integração Java 

  4. Crie um serviço de sistema geral chamado Payment Service e arraste o Payment Integration Service até esse diagrama, como mostra a Figura 6. Clique no ícone de mapeamento automático nas seções Input Mapping e Output Mapping para criar automaticamente as variáveis para o serviço, a fim de correlacionar o serviço de sistema geral.

    Figura 6. Payment Service 

  5. Crie um UCA baseado em evento chamado Settle Payment UCA para envolver o Payment Service recém-criado. Especifique On Event para o tipo de planejamento, como mostra a Figura 7.

    Figura 7. Crie um Settle Payment UCA

  6. Anexe o Undercover Agent ao evento de mensagem.
  7. Selecione o evento de mensagem intermediário Wait for Buyer's Payment na BPD Generate Order e clique na opçãoImplementation nas propriedades. Na seção Message Trigger , clique em Select ao lado do campo Attached UCA para selecionar Settle Payment UCA na lista Undercover Agent.
  8. Consume Message está marcado por padrão. Se você não quiser que a mensagem recebida seja consumida depois de ter sido recebida pelo evento de mensagem, desmarque-a.
  9. Se Durable Subscription estiver marcado, significa que o evento de mensagem pode receber uma mensagem recebida, mesmo quando o evento de mensagem não estiver em um estado ativo.
  10. Na seção UCA Output Correlation , você precisa mapear uma variável de saída UCA apropriada para uma variável local na BPD a fim de correlacionar o evento de mensagem à instância da BPD. Aqui, o ID da ordem é usado como a correlação de saída de UCA, como mostra a Figura 8.

    Figura 8. Anexe o UCA ao evento de mensagem intermediário

Há dois tipos de evento baseado no timer: um evento baseado no timer anexado, que é anexado diretamente a uma atividade em uma BPD, e o outro é um evento baseado no timer intermediário, que é conectado a outras etapas do processo usando as linhas sequenciais. Se um evento baseado no timer não estiver anexado a uma atividade, ele causará um atraso. O processo aguarda pelo acionamento do timer antes de continuar com a próxima atividade. É possível usar eventos baseados no timer para especificar um intervalo de tempo antes ou depois da execução de alguma atividade ou da utilização de outro caminho em seu processo.
Vamos analisar como podemos usar o mecanismo de evento baseado no timer no cenário de amostra. No Order Confirmation Process aninhado, se o fornecedor mudar a quantidade ou preço das mercadorias, o serviço de regra validará a mudança na ordem seguindo as regras do negócio. Nesse caso, talvez o comprador precise reconfirmar a ordem. Nesse caso, supõe-se que se o comprador não confirmar em até uma semana (sete dias), isso significa que o comprador aceitou essa ordem por padrão.
A Figura 9 mostra uma amostra de evento baseado no timer anexado. Na amostra, o timer garante que se uma quantidade específica de tempo (nesse caso, um minuto) passar após a chegada do processo à atividade Buyer Confirms Order, a atividade será passada e o processo continuará na próxima etapa (evento de término).

Figura 9. Exemplo de evento baseado no timer anexado
 
Quando os processos desenvolvidos exigem integração com sistemas externos, scripts de servidor e outras implementações complexas, é necessário antecipar as possíveis exceções e criar os componentes necessários para manipular essas exceções, quando elas ocorrerem.
Há dois eventos de exceção para BPDs: o evento de exceção intermediário, que é usado para capturar exceções na execução do processo e manipular as exceções com uma atividade manipuladora de erro ou processar ainda mais o fluxo, e o evento de exceção de término, que é usado para causar uma exceção nos processos pai.
No cenário de ordem de compra de amostra, o Shipper Selection é realizado automaticamente pelo sistema, que é exposto como um serviço da web. No processo aninhado Generate Order, se uma exceção é causada quando esse serviço é chamado, supõe-se que o sistema precisa notificar o fornecedor.
Para atender a esse requisito, arraste o elemento Intermediate Exception Event da paleta para a atividade Select Shipper e adicione uma nova atividade chamada Send Exception to Supplier ao processo. Conecte o componente Intermediate Exception Event à nova atividade, como mostra a Figura 10.

Figura 10. Adicione o evento de exceção intermediário
 
Isso completa a manipulação de exceção para a atividade Select Shipper. Quando você recebe erros na atividade Select Shipper, o processo vai automaticamente para a atividade Send Exception to Supplier.
Uma definição de serviço da web expõe um serviço do Lombardi (ou um conjunto de serviços do Lombardi) como um serviço da web que pode ser chamado por SOAP. Isso permite que os aplicativos corporativos acessem aplicativos de gerenciamento de processo de negócios desenvolvidos no Lombardi. É possível criar e publicar um serviço da web para ativar aplicativos externos a fim de iniciar um serviço específico do Lombardi ou um conjunto de serviços.
No cenário de amostra, criaremos um serviço da web com as entradas apropriadas para chamar o Settle Payment UCA a fim de enviar o evento (serviço responsável pela chamada). Para fazer isso, complete as seguintes etapas:
  1. Crie um serviço de sistema geral chamado Call Payment UCA Service.
  2. Arraste um elemento UCA até o diagrama e especifique Kickoff Settle Payment UCA como o nome. Na guiaImplementation , selecione Settle Payment UCA como o UCA anexado, como mostra a Figura 11.

    Figura 11. Serviço Call Payment UCA 

  3. Em seguida, você precisa expor o serviço Call Payment UCA como um serviço da web para invocação externa. Na visualização Designer, selecione o sinal de adição (+) ao lado da categoria Implementation e selecione Web Servicena lista, para criar um serviço da web chamado PaymentWS.
  4. Na seção Operations , clique em Add para escolher um serviço existente (o serviço Call Payment UCA) a fim de adicioná-lo. Especifique callPaymentUCA como o nome da operação, como mostra a Figura 12.
    Para ver a descrição XML do serviço da web resultante e seus elementos e operações, clique no URI do WSDL na seção Behavior .


    Figura 12. Crie um serviço da web

Na Parte 3 desta série, você aprendeu a usar alguns dos recursos avançados do WebSphere Lombardi Edition V7.1 a fim de enriquecer o processo de amostra para atender aos requisitos mais complexos, incluindo a adição de processos aninhados, marcos, mecanismos de evento, manipulação de exceção e exposição de serviços da web do Lombardi. Nos artigos futuros da série, você aprenderá a usar coaches para desenvolver serviços humanos.

Downloads
DescriçãoNomeTamanhoMétodo de download
Purchase Order process filePurchaseOrderProcess_V3.zip452KBHTTP
Payment integration servicepayment.jar2KBHTTP

Xi Ning Wang photo
Xi Ning Wang é engenheiro de equipe de software e líder de desenvolvimento de infraestrutura em nuvem, IBM SOA Advanced Technologies, IBM Software Group. Ele já projetou e desenvolveu tecnologias de SOA e soluções em projetos importantes. Atualmente, está focado nas áreas de computação em nuvem e solução de segmento de mercado. Ele foi designado como um autor contribuinte para o IBM developerWorks em 2009.
Xi Lin photo
Xin Li é engenheiro de software no Laboratório de desenvolvimento da IBM China, onde se concentra no design e desenvolvimento relacionado ao SOA. Li Xin tem bastante experiência em integração de sistema de domínio de telecomunicações e também muito conhecimento sobre normas e tecnologias de telecomunicações.

Nenhum comentário:

Postar um comentário