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

Integração de sistemas com o WebSphere Lombardi Edition V7.2, Parte 1: Visão geral da arquitetura e da solução

Por: Scott Glen 
Em:http://www.ibm.com/developerworks/br/websphere/library/techarticles/1107_glen/1107_glen.html

IBM e Lombardi

Em 2010, a IBM adquiriu a Lombardi Software, e posteriormente aprimorou o portfólio de produtos para gerenciamento de processos de negócios (BPM) com a apresentação do IBM Blueworks Live e do WebSphere Lombardi Edition. O Blueworks Live é uma evolução da oferta Lombardi Blueprint e fornece recursos de modelagem de negócios e colaboração de alto nível baseados na nuvem. O Lombardi é um modelo de negócios integrado e uma plataforma de montagem de solução desenvolvido para permitir o desenvolvimento rápido de aplicativos BPM. Ele se concentra principalmente em fluxo de trabalho antropocêntrico, mas também oferece uma variedade de recursos de integração de backend.
Esta série em três partes se concentra no desenvolvimento de uma solução de Manuseio de Pedidos, especificamente voltada para demonstrar os recursos de integração fornecidos pelo WebSphere Lombardi Edition V7.2 (doravante chamado de Lombardi). Embora a solução seja fictícia, é vagamente baseada em um processo de Manuseio de Pedidos de Telecomunicações alinhado a padrões e foi especialmente desenvolvida para expor uma variedade de opções de integração diferentes, incluindo serviços da Web, JMS, Ajax, JDBC e procedimentos armazenados. Embora tenhamos nos baseado no WebSphere Lombardi Edition, o conteúdo também é aplicável ao IBM Business Process Manager V7.5, que é compatível com o ambiente do Lombardi V7.2.
Esta série não se destina a abranger todos os aspectos do Lombardi. Em vez disso, ela se concentra especificamente em seus recursos de integração, apresentando os diversos serviços e tecnologias que suportam a comunicação com os sistemas operacionais. A Parte 1 apresenta a série, fornece uma visão geral da arquitetura do Lombardi e seu ambiente de desenvolvimento, e cria os recursos subjacentes (como tabelas de banco de dados) sobre os quais a solução é desenvolvida. A Parte 2 se concentrará na anatomia de processo, dando uma olhada mais aprofundada nos recursos de desenvolvimento do Lombardi e apresentando os principais elementos BPM da solução. Por fim, a Parte 3 examinará as diversas técnicas de integração usadas pelo processo de Manuseio de Pedido.
Atualmente, o Lombardi V7.2 é suportado em Windows de 32 e 64 bits®, Solaris®, AIX® e Linux de 32 e 64 bits®. São fornecidos dois caminhos da instalação pelo instalador: simples e customizado. O instalador simples faz tudo, instalando todos os aplicativos dependentes, como DB2® e o WebSphere Application Server subjacente.
A opção customizada é mais flexível, permitindo adaptar a instalação para usar um banco de dados DB2, Oracle® ou SQL Server existente. Se essa opção for escolhida, confirme se está disponível a versão correta dos aplicativos dependentes. Por exemplo, o Lombardi V7.2 depende do DB2 V9.7 FP 1. Se houver uma versão diferente do DB2 instalada, o instalador talvez continue sem erro, mas o aplicativo não funcionará corretamente. Consulte as notas de release na seção Recursos para obter mais detalhes.
A plataforma Lombardi tradicionalmente serve para colaboração, com a equipe de negócios, a administração e a equipe técnica trabalhando em conjunto para desenvolver iterativamente soluções de BPM. Essa abordagem permite a criação de protótipos e a implementação rápidas de aplicativos, normalmente em um intervalo de tempo mais curto do que outros ambientes de BPM.
Essa abordagem é refletida na própria arquitetura do produto, onde os componentes da solução são mantidos em um centro de processos central. Todas as partes envolvidas no esforço de definir, modelar, implementar, medir e melhorar o processo trabalham a partir de uma plataforma comum compartilhada que encapsula cada elemento da solução. Essa plataforma pode ser acessada por meio de uma variedade de ferramentas, que apresentam diversas perspectivas baseadas em função das informações centralizadas.

Figura 1. Modelo compartilhado do Lombardi 
 
Nas seções a seguir, vamos dar uma olhada mais aprofundada nos principais elementos dessa arquitetura que são relevantes para esta série de artigos, a saber, o Process Center, o Authoring Environment e o Process Portal.
O Process Center fica no núcleo da arquitetura do Lombardi. Ele fornece um ambiente de desenvolvimento central e um repositório, que oferecem suporte a diversos autores e desenvolvedores de processos. Ele é administrado por meio de umProcess Center Console, que permite o gerenciamento de aplicativos, áreas de trabalho e capturas instantâneas contidos no Process Center. Além de agir como repositório de desenvolvimento, ele também contém dois componentes importantes:
  • Process Server, um mecanismo de processo de tempo de execução responsável pela execução dos processos e serviços. Ele fornece um ambiente de teste de unidade (UTE) para os autores de processos e é administrado por meio do Process Admin Console.
  • Performance Data Warehouse é responsável por coletar e agregar dados de processo para permitir a geração de relatórios de desempenho. Ele é configurado por meio do Performance Admin Console.
O Authoring Environment fornece uma ferramenta única para todas as atividades de autoria de processo. É a principal ferramenta com a qual os analistas e desenvolvedores de integração interagem em base diária, e permite que os autores de processo modelem, integrem e simulem seus processos. Cada Authoring Environment é dedicado a um único Process Center. Embora o Authoring Environment forneça uma interface com o usuário baseada em Eclipse, ele é basicamente um thin client, visto que a maior parte da funcionalidade é implementada no Process Center associado.
O Authoring Environment oferece suporte à notação BPMN, que permite que os processos sejam modelados visualmente por meio de uma interface intuitiva do tipo arrastar e soltar. As atividades de negócios podem ser incluídas a raias na tela, conectadas entre si e implementadas por subprocessos ou serviços, como mostrado na Figura 2.

Figura 2. Authoring Environment do Lombardi 
 
Quando mencionamos serviços no contexto do Lombardi, não falamos de serviços SOA. Os serviços do Lombardi são componentes internos dele, desenvolvidos de forma similar aos processos de negócios, mas que modelam um nível inferior de interação. Eles podem assumir muitas formas, mas se dividem em três categorias: serviços de interface com o usuário, serviços de implementação e serviços de regras de negócio.
Os serviços de UI podem ser usados para desenvolver interfaces rapidamente, permitindo que os usuários interajam com os processos. São divididos em duas categorias:
  • Serviços humanos, que normalmente contêm as telas de interfaces (conhecidas como Coaches, ou treinadores, porque orientam os usuários ao longo do aplicativo), bem como os componentes necessários para preencher a interface.
  • Serviços Ajax, usados para recuperar informações de forma assíncrona a partir do servidor. Esses serviços podem ser usados pelos serviços humanos para criar uma experiência do usuário mais dinâmica.
Estes serviços se concentram em conectividade com o mundo exterior, e incluem uma variedade de opções de acesso às informações e funcionalidades contidas em aplicativos externos:
  • Serviços do sistema geral criam um componente de negócios reutilizável que pode ser chamado por outros processos ou serviços.
  • Serviços de integração são usadas para se integrar aos sistemas operacionais que suportam a execução do processo de negócios. O Lombardi oferece suporte a serviço da Web ou a componentes de integração baseados em Java™, bem como uma variedade de opções de integração pré-desenvolvidas por meio do kit de ferramentas de dados do sistema, que inclui diversas integrações baseadas em SQL.
  • Agentes ocultos são usados por outros serviços para fornecer comunicações assíncronas baseadas em mensagens. Podem ser usados para permitir que processos vagamente associados trabalhem cooperativamente, ou para reagir a eventos externos de mensagem baseados em JMS.
  • Atividades externas fornecem capacidade limitada de se integrar diretamente a aplicativos externos, como aqueles implementados em uma plataforma Microsoft® .Net, que pode então manipular os dados de processo.
  • serviços da Web são usados para expor um serviço Lombardi existente como um serviço da Web, tornando-o disponível para outros processos Lombardi ou consumidores externos.
Embora as regras de negócio não sejam usadas nesta série, vale a pena mencionar seus recursos no Lombardi. Há três tipos de serviços de regras de negócios:
  • Serviços de regras permitem o encapsulamento de regras de negócios if-then simples, que podem ser conectadas a um processo de negócios e aplicadas aos dados de processo, fazendo com que sejam executadas ações apropriadas. Embora separar regras de negócios dessa forma seja uma prática sólida de arquitetura, o Lombardi oferece apenas um recurso bastante rudimentar para regras. Em nível corporativo, talvez seja melhor utilizar um mecanismo de regras dedicado, como o IBM WebSphere ILOG® JRules, suportado no Lombardi V7.2, para agir como repositório único para todas as regras de negócios.
  • Principais indicadores de desempenho (KPIs) são medidas de negócios que rastreiam o Lombardi no tempo de execução, armazenam os resultados que pode ser usados para analisar processos e desempenho de tarefas no Optimizer. Os KPIs podem ser associados a qualquer atividade de um processo.
  • Acordos de Nível de Serviço (SLAs) são desenvolvidos com base em KPIs, agregando as medições de processo e permitindo que ocorra uma ação acionadora em condições definidas.
O Process Portal do Lombardi é uma interface baseada na Web onde os usuários podem iniciar e parar processos, gerenciar e executar tarefas para cada processo e ver o desempenho de pessoas, equipes e processos. A interface é baseada em funções, exibindo apenas os processos e as tarefas associados ao grupo a qual o usuário pertence.

Figura 3. Process Portal
 
O Process Portal permite aos usuários concluir as tarefas que resultam de processos em execução no Process Server. Se uma tarefa é reivindicada por um usuário, o Coach adequado é exibido no portal, permitindo que o usuário conclua a tarefa antes de devolver o controle para o próximo estágio do processo.
Agora já apresentamos todos os elementos do Lombardi que serão usados nesta série, então vamos dar uma olhada no próprio cenário da solução.
Tradicionalmente, o produto Lombardi sempre foi voltado para fluxos de trabalho antropocêntricos. No entanto, nesta série, queremos explorar algumas das opções de integração mais técnicas do Lombardi e ver como ele lida bem com um cenário realista de automação de processo. Por essa razão selecionamos um processo simplificado de Manuseio de Pedidos, vagamente baseado em um processo padronizado do segmento de mercado de telecomunicações. A fim de explorar os recursos do Lombardi, introduzimos na solução uma variedade de técnicas de integração. Não defendemos necessariamente o uso de todas essas em uma solução no mundo real, mas isso nos permite demonstrar as diferentes opções que o Lombardi oferece.
A Figura 4 mostra o processo de ponta a ponta em um nível abstrato.

Figura 4. Processo abstrato de Manuseio de Pedidos 
 
Os processos Create Order e Update Order Status imitam de forma eficaz os recursos de um sistema básico de gerenciamento de relacionamento com o cliente (CRM) e, assim, aparecem na raia de CRM. O processo Create Order captura os detalhes do pedido e emite um pedido do cliente para o processo Handle Order, que tenta concluir o pedido antes de enviar o status final de volta para o sistema de CRM, onde ele é recebido pelo processo Update Order Status.
Cada etapa do processo abstrato é implementada por um processo de negócios separado no Lombardi. O processo Create Order, mostrado na Figura 5, utiliza uma série de telas para capturar os detalhes de cliente e produto antes de armazenar o pedido no banco de dados de CRM e emiti-lo para o processo Order Handling.

Figura 5. Processo Create Order 
 
O pedido é emitido de forma assíncrona por meio de uma fila de mensagens, visto que um pedido de telecomunicações real pode levar vários dias para ser concluído se envolver o fornecimento físico de equipamentos em nível de rede. O processo, portanto, usa uma combinação de técnicas de Lombardi, incluindo Coaches, SQL, chamada de procedimentos armazenados, atualizações Ajax e sistema de mensagens assíncrono.
Uma instância do processo Handle Order é iniciada quando a mensagem de pedido é lida na fila de mensagens. A viabilidade do pedido é primeiramente verificada e depois a classificação de crédito do cliente é avaliada (estamos supondo que esse é um pedido para um serviço que é pago mensalmente em atraso). O pedido é então preenchido e, por fim, encerrado. Uma combinação de serviços da Web, sistema de mensagens assíncrono e Coaches para manipulação de exceção e escalada é usada nesse processo.

Figura 6. Processo Handle Order 
 
Quando o processo Handle Order é concluído, ou se o pedido não puder ser preenchido por qualquer motivo, uma mensagem de status adequada é enviada de forma assíncrona de volta para o sistema de CRM e é manipulada pelo processo Update Order Status.

Figura 7. Update Order Status
 
Esse processo primeiro atualiza o registro de CRM no banco de dados com o status do pedido e depois cria uma tarefa manual para exibir o pedido. Ele usa sistema de mensagens assíncrono, atualizações de SQL e Coaches.
Para oferecer suporte à solução, criamos um modelo simples de dados que fornece os dados do produto estático para conduzir o processo, e serve como repositório para pedidos concluídos. A Figura 8 mostra o Diagrama de Relacionamento de Entidade (ERD), criado no InfoSphere® Data Architect V7.5.3:

Figura 8. Diagrama de Relacionamento de Entidade 
 
As complexidades do mundo real dessas entidades não foram modeladas aqui, visto que esse não é o foco desta série de artigos. No entanto, as informações que elas contêm, e seus relacionamentos entre si, serão usados para conduzir os BPDs. As entidades são descritas abaixo:
  • Product define os produtos principais fornecidos pela empresa, como banda larga, telefonia fixa, e assim por diante.
  • Um Offering é um agrupamento de um ou mais produtos fornecidos para venda aos clientes. Isso permite que os produtos sejam agrupados para criar ofertas como "Trios" (banda larga, telefone fixo e celular).
  • A tabela Offering_Product_Mapping implementa o relacionamento de muitos para muitos entre Products e Offerings.
  • Customer modela um cliente.
  • Order associa um cliente a uma oferta. O nome do Offering relacionado (o campo Offering_Name ) foi desnormalizado e incluído aqui por questão de simplicidade dentro da solução.
Os scripts para criar essas tabelas em DB2® são fornecidos na seção Downloads deste artigo. Outros scripts para implementar os procedimentos armazenados associados (que serão descritos em uma parte futura desta série) e para carregar dados de amostra de Product estarão disponíveis para download em partes futuras desta série. Consulte a seçãoRecursos para obter mais informações sobre a configuração de origens de dados no Lombardi.
O WebSphere Lombardi Edition V7.2 fornece uma plataforma integrada na qual desenvolver soluções de BPM (gerenciamento de desempenho de negócios). Embora tenha sido tradicionalmente forte na área de fluxo de serviços antropocêntricos, esta série se concentra nos seus recursos de integração usando serviços da Web, JMS, Ajax, JDBC e procedimentos armazenados para criar um processo fictício de Manuseio de Pedidos.
Esta parte inicial do tutorial forneceu uma visão geral do Lombardi, apresentando sua arquitetura e descrevendo a solução de Manuseio de Pedidos. Na parte 2 começaremos a desenvolver os processos e a apresentar os vários recursos de integração fornecidos pelo Lombardi.

Download
DescriçãoNomeTamanhoMétodo de download
Sample scriptOH_Script.zip1KBHTTP

Scott Glen photo
Scott Glen é IT Architect certificado da equipe de Business Performance and Service Optimization (BPSO) da IBM. Ele tem mais de 19 anos de experiência em arquitetura, design e desenvolvimento de sistemas orientados a objetos, fornecendo consultoria aos setores de finanças, governo, telecomunicações e mídia. Com interesse especial nas arquiteturas WebSphere, Java EE e padrões de design associados, Scott agora se especializa em SOA e BPM, fornecendo serviços de consultoria e implementação para clientes por toda a Europa, Oriente Médio e África.

Nenhum comentário:

Postar um comentário