![Fechar [x]](http://dw1.s81c.com/i/c.gif){kind=small}
Neste artigo final da série, iremos detalhar o processo para o desenvolvedor técnico implementar os artefatos da regra inicial e permitir que os usuários corporativos não técnicos continuem a testar e desenvolver regras.
a Figura 1 mostra a parte do processo de desenvolvimento do serviço de decisão geral abordada neste artigo.
Figura 1. Processos abordados neste artigo
(Veja uma versão ampliada da Figura 1.)
a Figura 2 mostra uma versão ampliada das tarefas de desenvolvimento de regras abordadas neste artigo.
Figura 2. Visualização ampliada dos processos abordados neste artigo
(Veja uma versão maior da figura 2.)
Vamos iniciar exatamente no local no qual paramos no segundo artigo.
Os conjuntos de regras são implementados no Rule Execution Server para permitir que clientes externos distribuídos chamem o serviço de decisão. Um RuleApp é a unidade de gerenciamento implementável que contém um ou mais conjuntos de regras. A partir de um ponto de vista físico, os conjuntos de regras e os RuleApps são arquivos JAR que contém artefatos de regra. Neste estágio do processo, um desenvolvedor de regras cria um projeto de RuleApp para gerar um RuleApp e implementá-lo no ambiente de desenvolvimento. O WebSphere ILOG JRules inclui ferramentas para implementação de regras nas plataformas Java™ SE ou Java EE. Para este caso de referência, iremos implementar o WebSphere Application Server Community Edition que é distribuído com o WebSphere ILOG JRules. Conforme ilustrado na A figura 3, o processo de implementação é composto das seguintes etapas:
- Criação de um projeto de RuleApp
- Implementação de um RuleApp no Rule Execution Server
Figura 3. Tarefas de implementação de regra
Um projeto de RuleApp chamado "ccc-ruleapp" é criado usando um assistente chamado com a seleção de Novo - Outro - RuleApp Project. No assistente, "ccc-rules" é escolhido como o projeto de regras que será incluído no RuleApp. Isso cria um projeto de RuleApp conforme mostrado na A figura 4.
Figure 4. Projeto de RuleApp
Clique duas vezes em archive.xml para abrir as propriedades do RuleApp. No assistenteRuleset Archives , as propriedades do conjunto de regras podem ser configuradas para controlar o comportamento do tempo de execução do conjunto de regras. Para ativar o monitoramento do conjunto de regras (conforme descrito posteriormente), as seguintes propriedades do conjunto de regras são incluídas:
ruleset.bom.enabled = true
monitoring.enabled = true
ruleset.debug.enabled = true
ruleset.trace.enabled = true
Figura 5, exibe as propriedades do archive do conjunto de regras do ccc-ruleapp após essas propriedades serem especificadas.
Figure 5. Propriedades do archive do conjunto de regras
(Veja uma versão ampliada da figura 5.)
Os RuleApps podem ser facilmente implementados no Rule Studio usando o editor de RuleApp chamado clicando duas vezes no archive.xml no projeto do RuleApp. No editor de RuleApp, clique em implementar para implementar diretamente o RuleApp em um servidor de aplicativo em execução, que pode ser remoto ou local. Esse servidor de aplicativos deve ter o Rule Execution Server instalado e configurado e é necessário saber as credenciais de autenticação. Para este caso de referência, usaremos o WebSphere Application Server Community Edition que é fornecido com o WebSphere ILOG JRules e já possui o Rule Execution Server instalado e usaremos as credenciais-padrão para autenticação no Rule Execution Server.
A Figura 6 ilustra a sequência das etapas usadas na implementação de um RuleApp no Rule Execution Server. Para implementar o RuleApp, siga as etapas a seguir:
- Selecionar o ponto de rastreamento Deploy na seção terminal da web em serviço na visão geral do ccc-ruleapp.
- Na janela aberta, selecione Replace RuleApp version como o tipo de implementação e clique em Next.
- Na janela seguinte, selecione o botão de opções Create a temporary Rule Execution Server configuration , forneça e aceite as credenciais-padrão ("resAdmin" para Login e Password), e clique em Finish.
Figura 6. Implementação do RuleApp
(Veja uma versão ampliada da figura 6.)
Chamando o RuleApp usando o Rule Execution Server
Agora, é possível gerenciar e monitorar o RuleApp usando o console do Rule Execution Server, que é acessado no endereço http://<res_server>.8080/res. No console, é possível explorar os RuleApps implementados no servidor. No nosso caso de referência, como temos um XOM dinâmico baseado em um XSD, o Rule Execution Server o expõe automaticamente como um serviço da Web para ser chamado através de clientes externos. A interface do WSDL com o serviço da Web pode ser obtida através do console do Rule Execution Server clicando em Get HTDS WSDL for this ruleset version na visualização Ruleset View, conforme mostrado na figura 7.
Figura 7. Console do Rule Execution Server
Nesse momento, o WSDL é distribuído aos clientes externos e o serviço de decisão está pronto para ser chamado por esses clientes externos. Para um teste rápido e simples, é possível usar ferramentas como o SOAP UI para emitir solicitações XML para esse serviço de decisão. a Listagem 1 fornece uma solicitação SOAP de amostra que pode ser usada com o SOAP UI.
Listagem 1. Amostra de solicitação SOAP
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:dec="http://www.ilog.com/rules/DecisionService"
xmlns:par="http://www.ilog.com/rules/param"
xmlns:urn="urn:oasis:names:tc:emergency:cap:1.1"
xmlns="urn:oasis:names:tc:emergency:cap:1.1">
<soapenv:Header/>
<soapenv:Body>
<dec:DecisionServiceRequest>
<!--Optional:-->
<dec:DecisionID>5</dec:DecisionID>
<par:request>
<alert>
<identifier>MSG1</identifier>
<sender>CityCommandCenter-EPS</sender>
<sent>2010-10-05T02:30:00+00:00</sent>
<status>System</status>
<msgType>Alert</msgType>
<scope>Private</scope>
<addresses>CityCommandCenter-BRE</addresses>
<info>
<language>en-US</language>
<category>Met</category>
<event>HeavyRainfall</event>
<responseType>Assess</responseType>
<urgency>Immediate</urgency>
<severity>Severe</severity>
<certainty>Observed</certainty>
<expires>2010-11-15T16:00:00+00:00</expires>
<senderName>NATIONAL WEATHER SERVICE ROTTERDAM NL</senderName>
<headline>SEVERE THUNDERSTORM WARNING</headline>
<description>AT 254 PM PDT...NATIONAL WEATHER SERVICE DOPPLER RADAR
INDICATED A SEVERE THUNDERSTORM OVER ROTTERDAM CITY..
OR ABOUT 18 MILES SOUTHEAST OF ROTTERDAM...MOVING SOUTHWEST AT 5 MPH.
HAIL...INTENSE RAIN AND STRONG DAMAGING WINDS ARE LIKELY WITH
THIS STORM.</description>
<instruction>TAKE COVER IN A SUBSTANTIAL SHELTER UNTIL THE
STORM PASSES.</instruction>
<contact>CITY/WEATHERFCT</contact>
<parameter>
<valueName>RainfallLevel1H</valueName>
<value>10</value>
</parameter>
<parameter>
<valueName>RainfallLevel6H</valueName>
<value>60</value>
</parameter>
<parameter>
<valueName>RainfallLevel12H</valueName>
<value>120</value>
</parameter>
<resource>
<resourceDesc>888001</resourceDesc>
</resource>
<area>
<areaDesc>EXTREME NORTH CENTRAL ROTTERDAM CITY IN NL</areaDesc>
<polygon>51.966667,4.333333 51.833333,4.333333 51.833333,4.583333
51.966667,4.583333 51.966667,4.333333</polygon>
</area>
<area>
<areaDesc>999001</areaDesc>
<polygon>51.966667,4.333333 51.966667,4.458333 51.900000,4.458333
51.900000,4.333333 51.966667,4.333333</polygon>
</area>
<area>
<areaDesc>999002</areaDesc>
<polygon>51.966667,4.333333 51.966667,4.458333 51.900000,4.458333
51.900000,4.333333 51.966667,4.333333</polygon>
</area>
</info>
</alert>
</par:request>
</dec:DecisionServiceRequest>
</soapenv:Body>
</soapenv:Envelope>
|
Os administradores podem gerenciar o Rule Execution Server usando o console. Além disso, usando a guia Decision Warehouse no console do Rule Execution Server, é possível auditar execuções de regras nos conjuntos de regras que possuem o monitoramento ativado (consulte "Criar um projeto de RuleApp'). É possível procurar execuções de regras com base na data, no conteúdo de entrada/saída ou nas regras que foram disparadas. É possível visualizar os detalhes da execução da regra, incluindo a solicitação concluída, a resposta e todas as regras que foram chamadas. Isso é muito útil para retraçar porque uma decisão foi feita no passado para uma determinada solicitação para determinar, por exemplo, porque foram enviadas quatro notificações para o Departamento de Águas na semana passada.
Figura 8 descreve as etapas necessárias para visualizar os detalhes da execução. Na seção Decision Warehouse , especifique o critério de filtragem e clique em Pesquisar. Nos resultados retornados da procura, selecione o resultado desejado e clique em View Decision details. Essa ação exibe uma janela que possui todos os detalhes da execução da regra do item selecionado.
Figura 8. Guia Decision Warehouse
(Veja uma versão maior da figura 8)..)
Ativação de usuário corporativo
Um dos principais benefícios de um BRMS é que os usuários corporativos que não são técnicos podem manter as regras independentemente da equipe técnica. Os usuários corporativos podem usar o Rule Team Server para isso. Para permitir que os usuários corporativos escrevam e testem regras, um desenvolvedor de regras publica o projeto de regras no Rule Team Server e cria um modelo de cenário do Microsoft® Excel® para os usuários corporativos desenvolverem cenários de teste.
O modelo de cenário do Excel para criação de etapas de teste de Decision Validation Services (DVS) é facilmente criado usando um assistente clicando com o botão direito do mouse no projeto de regras e selecionado Decision Validation Services - Generate Excel Scenario File Template. Figura 9 ilustra as opções usadas em cada etapa da sequência.
- In Generation Settings, escolha Default Excel (2003) Tabbed Format, especifique um nome do arquivo em Excel Scenario File Namee clique em Next.
- Na tela seguinte na qual as colunas para inclusão na planilha de resultados esperados são escolhidas, clique em Select Alle clique em Concluir.
Figura 9. Geração do modelo de cenário do Excel
(Veja uma versão ampliada da figura 9..)
Esse processo gera um modelo do Excel com diversas planilhas, cada planilha correspondendo a um objeto usado no modelo, como info e area. Usando esse modelo, os cenários podem ser definidos juntamente com os resultados esperados. Um conjunto de cenários de amostra pode ser encontrado na área de trabalho que pode ser transferida por download (consulte Faça o download do). a figura 10
exibe a guia Scenarios dessa planilha de amostra, que define dois cenários.
Figura 10. Cenários de teste
Esses cenários podem ser executados no Rule Studio ou no Rule Team Server. Para executá-los no Rule Studio, crie uma Configuração de Execução em DVS Excel File , como mostra a A Figura 11. Use essa sequência de etapas para criar uma configuração de execução:
- No menu principal do Rule Studio, selecione Run – Run Configurations.
- Selecione DVS Excel File no painel esquerdo do navegador e clique no ícone Launch New Configuration na parte superior.
- Especifique os nomes desejados nos campos Nome, Excel FileeHTML Report. Selecione ccc-rules no campo Rule Project. Clique em Apply e, a seguir, clique em Executar.
Figura 11. Configuração de execução do DVS no Rule Studio
Após executar essa configuração, um relatório, mostrado na A Figura 12, é criado no local especificado na configuração de execução que contém informações sobre as execuções de teste.
Figura 12. Relatório de teste do DVS
Os usuários corporativos usam o Rule Team Server para manter regras. Os desenvolvedores ativam esse recurso publicando os projetos de regras do Rule Studio no repositório do Rule Team Server, que é um banco de dados conectado ao Rule Team Server.
Primeiro, conecte-se ao Rule Team Server a partir do Rule Studio clicando com o botão direito do mouse no projeto de regras e selecionando Rule Team Server - Connect. Essa seleção abre uma janela na qual são inseridos o local do Rule Team Server e as credenciais de autenticação. Esse processo é mostrado na a Figura 13, onde você deve especificar o usuário e a senha padrão ("resAdmin"), especificar http://localhost:8080/teamserver como a URL e, em seguida, clicar em Conectar.
Figura 13. Conexão com o Rule Team Server a partir do Rule Studio
Após a conexão ser estabelecida, a mesma janela fornece opções para publicar o projeto de regras no Rule Team Server. Como mostrado na Figura 14, selecione a coluna Create a new project on Rule Team Server na seção de configuração do projeto da janela e clique em Concluir.
Figura 14. Publicação do projeto de regras no Rule Team Server
A sincronização de um projeto de regras pode ser iniciada a qualquer momento. As sincronizações futuras usam a opção Synchronize with existing Rule Team Server project .
Para o nosso caso de referência, nós possuímos dois projetos de regras: ccc-bom e ccc-rules. Ambos os projetos devem ser criados no Rule Team Server da forma descrita acima, mesmo que somente o ccc-rules seja realmente modificado pelos usuários corporativos.
O Rule Team Server é um repositório e um servidor de gerenciamento de regras escalável com um ambiente da Web colaborativo para criação, gerenciamento, validação e implementação de regras de negócios. Ele fornece um sistema de armazenamento central para regras de negócios e seus metadados e é a área de trabalho designada na qual os usuários corporativos podem colaborar para escrever, editar, organizar e procurar regras de negócios. Os usuários corporativos com responsabilidade de QA podem criar cenários de teste e ativá-los no DVS a partir do Rule Team Server. Os administradores usam o Rule Team Server para extrair regras do repositório e implementá-las em vários ambientes.
Os gerentes de política usam o Rule Team Server para trabalhar colaborativamente em artefatos de regra. O Rule Team Server fornece serviços de histórico e de versão que oferecem suporte para auditoria e retrocesso de artefatos de regra.
Selecionar o ponto de rastreamento Explorer no Rule Team Server para buscar regras e editá-las. Como se vê na A figura 15, os pacotes de regras são organizados de forma hierárquica no painel de navegação esquerdo e as regras no pacote de regras selecionado são mostradas no painel direito.
Figura 15. Buscar regras no Rule Team Server
(Veja uma versão ampliada da figura 15..)
As regras podem ser editadas diretamente nesta ferramenta. Por exemplo, se a regra que avalia chuvas fortes com base na precipitação das últimas 12 horas for alterada de 150 mm para 160 mm, um usuário corporativo pode fazer essa mudança diretamente na regra Heavy Rainfall over 12 hours no Rule Team Server.
figura 16 mostra a regra sendo modificada no Rule Team Server. As etapas envolvidas são as seguintes:
- Selecione a regra e clique em Editar. Como alternativa, clique no ícone de edição ao lado da regra.
- Na janela Rule Editing, clique em 150 e mude o valor para "160".
- Clique em Salvar.
Figura 16. Edição de regra no Rule Team Server
(Veja uma versão ampliada da figura 16.)
Além disso, os usuários corporativos podem criar novas regras do zero ou, mais facilmente, usar um modelo de regra predefinido. Por exemplo, a a Figura 17 mostra uma nova regra de avaliação sendo criada a partir de um modelo de regra predefinido chamado Assessment Template. Várias partes da regra já foram criadas e congeladas no modelo de regra. Para concluir a definição da regra, o usuário corporativo precisa somente preencher os marcadores.
Figura 17. Criação de uma regra nova a partir de um modelo
O Decision Validation Services é usado para criar cenários de teste para os desenvolvedores, as equipes de QA e os usuários corporativos validarem a exatidão e a eficácia dos conjuntos de regras. Usando o modelo do Excel fornecido por desenvolvedores de regras, os usuários corporativos criam etapas de teste de unidade como linhas nas planilhas do Excel. O Decision Validation Services trabalha no Rule Team Server através da conexão com um servidor que possui o Rule Execution Server e um Scenario Service Provider (SSP).
Para iniciar, crie um novo conjunto de testes no Rule Team Server, que consiste essencialmente em apontar para a planilha do Excel que contém os cenários de teste. Quando esse conjunto de testes é executado, ele extrai regras e as implementa temporariamente no Rule Execution Server especificado, que normalmente fica no ambiente de QA. Em seguida, cada cenário definido na planilha é executado como uma etapa de teste individual com relação a esse conjunto de regras recém-implementado e os resultados são exibidos em um relatório. Um relatório de amostra é mostrado na figura 18.
Figura 18. Relatório do DVS
(Veja uma versão ampliada da figura 18.)
Após as regras serem validadas e estarem prontas para implementação, é possível implementar RuleApps diretamente do Rule Team Server. Certamente essa abordagem presume que você possui as credenciais apropriadas para isso.
A implementação segue dois cenários principais:
- A implementação ativa, quando você deseja uma disponibilidade imediata das regras.
- A implementação gradual, quando você deseja efetuar a implementação em um ambiente de produção controlado.
Após selecionar a guia Configurar no Rule Team Server, o administrador pode criar ou editar um RuleApp. A Figura 19 mostra um RuleApp chamado cccruleapp com um conjunto de regras cccrules.
Figura 19. Criação de um RuleApp no Rule Team Server
Agora, o RuleApp pode ser implementado em qualquer host que esteja executando o Rule Execution Server ou pode simplesmente ser exportado para um arquivo JAR RuleApp para implementação gradual. figura 20 mostra a implementação ativa no Rule Execution Server local.
Figura 20. Implementação a partir do Rule Team Server
Após um RuleApp ser implementado, ele está disponível para clientes externos no ambiente como um serviço de decisão para a tomada de decisões complexas. Observe que, com a implementação ativa, as chamadas subsequentes dos clientes externos usam o novo conjunto de regras para processamento.
Vimos que o WebSphere ILOG JRules é uma ferramenta eficiente que oferece um grande conjunto de recursos para a criação de sistemas de gerenciamento de regras de negócios e que pode ser executado em ambiente SOA. Usando um caso de referência, nós acompanhamos um processo de desenvolvimento de serviço de decisão usado comumente para avaliar como pessoas em diferentes funções trabalham em conjunto e como o WebSphere ILOG JRules, através de seus módulos, assistentes e aceleradores facilita muitas tarefas.
| Nome | Tamanho | Método de download |
|---|---|---|
| cccrules_pif_051811.zip | HTTP |
Informações sobre métodos de download
Aprender
- Página do produto IBM WebSphere ILOG JRules: Tenha acesso a mais informações sobre os recursos e benefícios, requisitos do sistema e suporte na página inicial do produto.
- Centro de Informações do IBM WebSphere ILOG JRules: Obtenha mais informações sobre essa linha de produtos e seus recursos.
- OASIS Common Alerting Protocol 1.1: O Common Alerting Protocol (CAP) é um formato simples, mas geral para troca alertas de emergência e avisos públicos sobre todos os perigos em todos os tipos de redes. Consulte o atualizada em outubro de 2007 também.
- Policies and Rules – Improving business agility: Part 1: Support for business agility (Hondo, Boyer, Ritchie, developerWorks, março de 2010): Um desafio na arquitetura e implementação de agilidade de soluções de negócio hoje é que o uso dos termos, políticas e regras difere entre os produtos. Aprenda os conceitos e relacionamentos de políticas e tecnologias de regras para implementar estratégias de negócios e táticas específicas.
- Criando Fatos Intermediários no WebSphere ILOG JRules Usando Objetos Sintéticos (Raj Rao, developerWorks, novembro de 2010): Consulte este artigo do WebSphere Technical Journal para obter mais informações sobre classes virtuais para implementar objetos sintéticos.
-
Segmentos de mercado no IBM developerWorks: Obtenha todos os recursos técnicos específicos do segmento de negócio mais recentes para desenvolvedores.
-
developerWorks: Mantenha-se atualizado em relação à tecnologia nessas sessões.
-
developerWorks no Twitter: Inscreva-se hoje para seguir os tweets do developerWorks.
-
Podcasts do developerWorks: Ouça entrevistas e discussões interessantes para desenvolvedores de software.
Obter produtos e tecnologias
- WebSphere ILOG JRules V7.1: Obtenha a versão de teste para download.
-
Versões de avaliação de produto IBM: Faça o download ou explore as versões de teste online no IBM SOA Sandbox e comece a usar ferramentas de desenvolvimento de aplicativo e produtos de middleware do DB2®, Lotus®, Rational®, Tivoli® e WebSphere®.
Discutir
-
Blogs do developerWorks: Confira esses blogs e participe.
Rajesh (Raj) Rao trabalha na área de sistemas especialistas e sistemas de gerenciamento de regras de negócios há mais de 20 anos e, durante esse tempo, aplicou tecnologia de regras de negócios para construir aplicativos de diagnóstico, programação, qualificação e configuração em vários domínios, como manufatura, transporte e finanças. Ele está na IBM desde 2009. Com formação em inteligência artificial, seus interesses incluem processamento de linguagem natural e Web semântica.
Sandeep Desai é Senior Certified Enterprise IT Architect da equipe Business Partner Technical Professional do IBM WebSphere. Ele trabalha com parceiros de negócios estratégicos, de iniciantes a grandes empresas. Ele atua como mentor para elas, ajudando a ativar sua solução para SOA. Ensina, treina e prepara os parceiros para usar a plataforma de software IBM. Sandeep é Open Group Distinguished Certified IT Architect, IBM Senior Certified Enterprise IT Architect e IBM Certified SOA Solution Designer.
