Guia de Configuração e Administração

Red Hat JBoss BPM Suite 6.1

Guia de Configuração e Administração para o Red Hat JBoss BPM Suite

Kanchan Desai

Doug Hoffman

Eva Kopalova

Serviços do Conteúdo da Red Hat

Gemma Sheldon

Red Hat Serviços de Conteúdo de Engenharia

Joshua Wulf

Resumo

Guia para administradores e usuários avançados que lidam com a instalação, a configuração e o uso avançado do Red Hat JBoss BPM Suite.

Parte I. Introdução

Capítulo 1. Business Process Model and Notation

O Business Process Model and Notation (BPMN) é uma notação padrão para a modelagem de processos empresariais. O BPMN almeja diminuir a distância entre os analistas empresariais e os programadores, fornecendo uma linguagem de fluxo de trabalho que possa ser claramente compreendida por ambos.

1.1. Componentes

O Red Hat BPM Suite integra vários componentes, apoia os processos empresariais por todo o seu ciclo de vida e fornece recursos e ferramentas de gerenciamento de processos para os analistas empresariais, desenvolvedores e usuários empresariais. O produto pode ser implantado em vários servidores compatíveis com JEE; a opção recomendada é o Red Hat JBoss Enterprise Application Platform 6.
O Red Hat JBoss BPM Suite consiste nos componentes principais a seguir:
  • Execution Engine - fornece o ambiente de tempo de execução para as Regras e os Processos Empresariais. Engloba uma biblioteca de fluxo de trabalho que pode ser incorporada a um aplicativo web do usuário. O gerenciador do tempo de execução é o objeto raiz e contém os seguintes componentes:
    • Runtime Engine - implementa o comportamento principal da linguagem do computador e é fornecido pelo gerenciador do tempo de execução.
      • Process Engine - é o ambiente para a execução do modelo de processos empresariais.
      • Task Service - controla os ciclos de vida das tarefas humanas.
    • Rule Engine - pode ser usado com o mecanismo de processos ou sozinho.
      • Rules Evaluation - executa as regras empresariais no conjunto de fatos fornecido.
      • Complex Event Processing - aplica as regras empresariais ao fluxo de eventos de entrada.
  • Business Central - aplicativo baseado na web que acomoda ferramentas para a criação, o gerenciamento e o monitoramento de ativos, fornecendo um ambiente web integrado.
    • Asset Repository - é o local central de compartilhamento (Knowledge Store) para formulários, regras, processos, ativos empresariais e etc. Os usuários acessam esse repositório através do modo de exibição do Explorador de Projeto do Business Central via CriaçãoCriação de Projeto. O produto inicializa, por padrão, um repositório local GIT como o seu Repositório de Ativos. No entanto, outros repositórios podem ser adicionados ou removidos, conforme necessário.
    • Artifact Repository - é um repositório baseado no Maven para o armazenamento dos artefatos jar dos projetos.
    • Execution Server - fornece um ambiente de execução para as tarefas e instâncias dos processos empresariais.
    • Business Activity Monitor - fornece uma visão personalizada do desempenho empresarial.

Nota

O Red Hat JBoss BRMS vem junto com o seu próprio aplicativo Business Central, que é um subconjunto do aplicativo Business Central no Red Hat JBoss BPM Suite.

1.2. Projeto

Um projeto é um contêiner para os pacotes de ativos (processos empresariais, regras, definições de trabalho, tabelas de decisão, modelos de fato, modelos de dados e DSLs) que ficam no Repositório de Conhecimento. É esse contêiner que define as propriedades da Base KIE e da Sessão KIE que são aplicadas ao seu conteúdo. No GUI, você pode editar essas entidades no Editor de Projetos.
Como um projeto é um projeto Maven, ele contém o arquivo de Modelo de Objeto do Projeto, (pom.xml), com informações sobre como construir o artefato de saída. Ele também contém o arquivo Descritor do Módulo, kmodule.xml, que contém a configuração da Base KIE e da Sessão KIE para os ativos no projeto.

1.3. Criando um Projeto

Para criar um projeto, siga as instruções a seguir:
  1. Abra a perspectiva Criação de Projetos: no menu principal, clique em CriaçãoCriação de Projeto.
  2. No Explorador de Projeto, selecione a unidade organizacional e o repositório onde você queira criar o projeto.
  3. No menu de perspectiva, vá até Novo ItemProjeto.
  4. Na janela de diálogo Criar Novo Projeto, defina os detalhes do projeto:
    1. Na caixa de texto Projeto, insira o nome do projeto.
  5. O explorador atualiza-se para apresentar uma janela pop-up Novo Assistente de Projeto.
  6. Defina os detalhes de Configuração Geral do Projeto e Grupo Artefato Versão para esse novo projeto. Esses parâmetros são armazenados dentro do arquivo de configuração do Maven pom.xml.
    • Nome do Projeto: o nome para o projeto, por exemplo MortgageProject
    • Descrição do Projeto: a descrição do projeto, que pode ser útil para a documentação do projeto.
    • ID do Grupo: a identidade do grupo, por exemplo org.mycompany.commons
    • ID do Artefato: a identidade do artefato exlusiva no grupo, por exemplo myframework. Evite usar espaço ou caracteres especiais que possam gerar um nome inválido.
    • ID da Versão: a versão do projeto, por exemplo 2.1.1
    O modo de exibição da Tela do Projeto é atualizado com os novos detalhes do projeto, como definidos no arquivo pom.xml. Observe que você pode trocar os arquivos descritores do projeto na caixa suspensa por Configurações do Projeto e Configurações da Base de Conhecimento e editar seus conteúdos.

1.4. Adicionando Dependências

Para adicionar dependências ao seu projeto, siga as instruções a seguir:
  1. Abra o Editor de Projetos para o projeto fornecido:
    1. No modo de exibição do Explorador de Projeto da perspectiva Criação de Projeto, abra o diretório do projeto.
    2. Clique no botão para abrir o modo de exibição do projeto.
  2. No modo de exibição da Tela do Projeto, selecione o item Dependências na caixa suspensa Configurações do Projeto.
  3. Na Tela do Projeto atualizada, clique no botão Adicionar para adicionar uma dependência maven ou clique no botão Adicionar a partir do repositório para adicionar uma dependência do Knowledge Store (repositório de artefatos):
    • Ao adicionar uma dependência maven, o usuário precisa definir a ID do Grupo, a ID do Artefato e a ID da Versão na nova linha que foi criada na tabela de dependências.
    • Ao adicionar uma dependência do Knowledge Store, selecione a dependência na caixa de diálogo exibida: a dependência será adicionada à tabela de dependências.
  4. Para aplicar as diversas alterações, as dependências devem ser salvas.

Atenção

Se estiver trabalhando com artefatos modificados, não recarregue esses artefatos modificados e que não sejam do tipo snapshot, pois o Maven não saberá que eles foram atualizados e não funcionará caso sejam implantados dessa maneira.

Parte II. Configuração

Capítulo 2. Configuração do Business Central

Como o Business Central é um aplicativo web, todas as definições de configuração são carregadas a partir do DEPLOY_DIRECTORY/business-central.war/WEB-INF/web.xml e de seus arquivos referenciados, assim como do jboss-web.xml e jboss-deployment-structure.xml, caso sejam implantadas no Red Hat JBoss EAP 6.
Observe que, o aplicativo todo pode ser executado em perfis diferentes (consulte o guia Red Hat JBoss BPM Suite Installation Guide).

2.1. Controle de Acesso

O mecanismo de controle de acesso inclui autorização e autenticação. No ambiente unificado do Red Hat JBoss BPM Suite, os usuários podem atualizar as funções padrão do usuário localizadas em $JBOSS_HOME/standalone/deployments/business-central.war/WEB-INF/classes/userinfo.properties.
Para conceder ao usuário acesso ao JBoss BPM Suite, o usuário precisa ter a respectiva função atribuída:
  • admin: administra o sistema JBoss BPM Suite e possui total direito de acesso para fazer quaisquer alterações necessárias, incluindo a habilidade de adicionar e remover os usuários do sistema.
  • desenvolvedor: implementa os códigos necessários para os processos funcionarem e tem acesso a tudo, com exceção das tarefas de administração.
  • analista: cria e projeta processos e formatos, instancia processos e implanta artefatos. Essa função é semelhante a do desenvolvedor, sem o acesso a repositórios de ativos e implantações.
  • usuário: declara, desempenha e invoca outras ações (tais como, escalonamento, rejeição e etc.) nas tarefas atribuídas e não possui acesso às funções de criação.
  • gerenciador: monitora o sistema e suas estatísticas e possui acesso somente ao painel.
  • usuário de negócios: trabalha nas tarefas de negócios que são necessárias para dar continuidade aos processos. Trabalha principalmente com a lista de tarefas.
Caso esteja usando o Red Hat JBoss EAP, para criar um usuário com algumas funções em particular, execute o script $JBOSS_HOME/add-user.sh e crie um Usário do Aplicativo em ApplicationRealm com as respectivas funções.

Configuração do Workbench

No Red Hat JBoss BPM Suite, os usuários podem configurar as funções usando LDAP e modificar as funções existentes. Os usuários podem modificar as funções na configuração do workbench, para assegurar que as funções únicas baseadas em LDAP sigam os padrões empresariais, editando o diretório de implantações em $JBOSS_HOME/standalone/deployments/business-central.war/WEB-INF/classes/workbench-policy.propeties.
Ao autenticar um usuário via LDAP ou GIT, os administradores precisam definir as propriedades do sistema org.uberfire.domain com o nome do módulo de login que ele usará para autenticar os usuários via o serviço GIT. Isto deve ser definido no arquivo standalone.xml no EAP.

Autenticação nas Tarefas Humanas

Toda tarefa que precisa ser executada é atribuída a uma ou várias funções ou grupos, para que todo usuário com a função dada ou com o grupo dado possa declarar a instância da tarefa e executá-la. As tarefas também podem ser atribuídas diretamente a um ou vários usuários. O JBoss BPM Suite usa a interface UserGroupCallback para atribuir tarefas ao usuário.

Atenção

Um grupo para uma Tarefa Humana não deve receber o nome de um usuário existente no sistema. Isto pode causar problemas intermitentes.

2.2. Configuração do Perfil do Business Central

O servidor do Red Hat JBoss BPM Suite 6 (ou superior) pode iniciar o aplicativo Business Central em três modos distintos:
  • Perfil completo - perfil padrão que é ativado sem necessitar de uma configuração adicional (IU e serviços remotos, ex. REST).
  • Perfil do servidor de execução - desabilita completamente os componentes da IU do aplicativo e permite apenas o acesso remoto, ex. via a interface REST.
  • Perfil do servidor da IU - desabilita os serviços remotos, ex. REST, e permite apenas o acesso à IU do aplicativo.
Para alterar o perfil, siga os seguintes passos de configuração.

Procedimento 2.1. Configurando os Perfis do Business Central

  1. Selecione o web.xml desejado dentro do $BPMS_HOME/standalone/deployments/business-central.war/WEB-INF/. Os seguintes arquivos são fornecidos:
    • web.xml (padrão) para perfil completo
    • web-exec-server.xml para o perfil do servidor de execução
    • web-ui-server.xml para o perfil do servidor da IU
  2. Para ativar um perfil que não seja o perfil completo padrão, deve-se renomear o arquivo web-<PROFILE>.xml para web.xml. Os passos a seguir demonstram uma maneira de habilitar o perfil do servidor de execução:
    1. Faça o backup do arquivo web.xml a partir do perfil completo:
      $ mv web.xml web-full.xml
    2. Renomeie o arquivo web-exec-server.xml:
      $ mv web-exec-server.xml web.xml
  3. Inicie o servidor do aplicativo com a propriedade adicional do sistema, instruindo o gerenciador do perfil a ativar o perfil especificado:
    • Dorg.kie.active.profile=full - para ativar o perfil completo ou ignorar a propriedade por completo
    • Dorg.kie.active.profile=exec-server - para ativar o perfil do servidor de execução
    • Dorg.kie.active.profile=ui-server - para ativar o perfil do servidor da IU

2.3. Criando uma Marca para o Aplicativo Business Central

O aplicativo web Business Central permite a personalização de sua aparência, possibilitando que você substitua alguns de seus estilos padrão. A possibilidade de personalizar uma marca para o Business Central permite que você tenha uma aparência consistente em todos os seus aplicativos e, consequentemente, melhore a experiência do usuário. Isso também ajuda nos casos em que várias equipes usam o aplicativo, pois cada equipe pode desenvolver a sua própria interface de usuário. Os elementos personalizáveis são criados usando folhas de estilos em cascata (CSS), imagens e arquivos HTML, fornecendo uma abordagem fácil e flexível para a personalização, sem que o código precise ser recompilado.
Você pode modificar os seguintes elementos no aplicativo Business Central para seguir a linha da marca da sua empresa:
  • Tela de login
    Você pode personalizar os seguintes atributos da tela de login do Business Central:
    • A imagem de plano de fundo
    • O logotipo da empresa
    • O logotipo do aplicativo
  • O cabeçalho do aplicativo
    Você pode personalizar os seguintes atributos do cabeçalho do aplicativo Business Central:
    • O cabeçalho do Business Central contendo o título e o logotipo do banner
  • Janelas pop-up de ajuda
    Você pode personalizar os seguintes atributos das janelas de pop-up de ajuda da tela inicial:
    • As imagens de ajuda da tela inicial
    • O texto do rótulo

2.3.1. Personalizando a Página de Login do Business Central

Procedimento 2.2. Alterando a Imagem de Plano de Fundo da Página de Login do Business Central

  1. Inicie o servidor EAP e abra http://localhost:8080/business-central em um navegador da web.
  2. Copie a nova imagem de plano de fundo no diretório $EAP_HOME/standalone/deployments/business-central.war/images na sua instalação do JBoss BPM Suite.
  3. Navegue até o diretório $EAP_HOME/standalone/deployments/business-central.war/styles e abra o arquivo login-screen.css em um editor de texto.
  4. No arquivo login-screen.css, forneça o local da sua nova imagem de plano de fundo no seguinte atributo background-image.
    background-image: url("../images/login-screen-background.jpg");
    O atributo background-image aponta para a imagem padrão login-screen-background.jpg.
    Além da imagem de plano de fundo, você também pode modificar outros atributos, tais como: o tamanho da imagem, a posição e a cor do plano de fundo no arquivo login-screen.css.
Atualize a página de login do Business Central para visualizar as suas alterações.

Procedimento 2.3. Alterando o Logotipo da Empresa na Página de Login do Business Central e o Logotipo do Projeto

  1. Inicie o servidor EAP e abra http://localhost:8080/business-central em um navegador da web.
  2. Naveque até o diretório $EAP_HOME/standalone/deployments/business-central.war/images na sua instalação do JBoss BPM Suite.
  3. Substitua a imagem padrão login-screen-logo.png por uma nova imagem. Esse é o logotipo da empresa que aparece no canto superior direito da página de login.
  4. Substitua a imagem padrão RH_JBoss_BPMS_Logo.pngRH_JBoss_BRMS_Logo.png por uma nova imagem. Esse é o logotipo do projeto que aparece no lado central esquerdo da página de login.
Atualize a página de login do Business Central para visualizar as suas alterações.

2.3.2. Personalizando o Cabeçalho do Aplicativo Business Central

Procedimento 2.4. Alterando o Cabeçalho (Banner) do Aplicativo Business Central

  1. Inicie o servidor EAP e abra http://localhost:8080/business-central em um navegador da web.
  2. Faça o login no aplicativo Business Central com as suas credenciais de usuário.
  3. Copie a sua nova imagem de cabeçalho do aplicativo no diretório $EAP_HOME/standalone/deployments/business-central.war/banner na sua instalação do JBoss BPM Suite.
  4. Abra o arquivo $EAP_HOME/standalone/deployments/business-central.war/banner/banner.html em um editor de texto.
  5. No arquivo banner.html, edite a seguinte tag <img> para fornecer o nome da sua nova imagem de cabeçalho:
    <img src="banner/logo.png"/>
    A imagem padrão é logo.png.
Atualize a página inicial do Business Central para visualizar as suas alterações.

2.3.3. Personalizando as Janelas de Ajuda da Tela Inicial

O diretório $EAP_HOME/standalone/deployments/business-central.war/plugins contém as páginas da tela inicial e seus arquivos html correspondentes. Cada página da tela inicial mantém o nome do arquivo html, o qual possui informações sobre a(s) imagem(s) e o texto a ser exibido. Por exemplo, a página da tela inicial authoring_perspective.splash.js aponta para o arquivo authoring_perspective.splash.html. authoring_perspective.splash.html contém os nomes e o local de todos os arquivos de imagem que aparecem na ajuda da tela inicial da Perspectiva de Criação, assim como as suas legendas. Você pode personalizar as imagens e as legendas correspondentes das janelas pop-up de ajuda da tela inicial existente.

Procedimento 2.5. Alterando as Legendas e as Imagens de Pop-Up de Ajuda da Tela Inicial

  1. Inicie o servidor EAP e abra http://localhost:8080/business-central em um navegador da web.
  2. Faça o login no aplicativo Business Central com as suas credenciais de usuário.
  3. Copie a(s) sua(s) nova(s) imagem(s) no diretório $EAP_HOME/standalone/deployments/business-central.war/images na sua instalação do JBoss BPM Suite.
  4. Abra o arquivo html correspondente a partir do diretório $EAP_HOME/standalone/deployments/business-central.war/plugins em um editor de texto.
  5. Edite o arquivo html para apontar para a sua nova imagem de ajuda da tela inicial. Por exemplo, para alterar a primeira imagem que aparece na ajuda da tela inicial da Perspectiva de Criação, edite a seguinte tag <img> no arquivo authoring_perspective.splash.html para adicionar a sua nova imagem:
    <img src="images/authoring_perspective1.png" alt="">
    A imagem padrão é authoring_perspective1.png, a qual aparece na primeira página de ajuda da tela inicial da Perspectiva de Criação.
  6. Para alterar a legenda da imagem que aparece na ajuda da tela inicial, edite os conteúdos de tag <h4> e <p> abaixo da tag <img>:
    <h4>Authoring</h4>
    <p>Modularized and customizable workbench</p>
Atualize a página inicial do Business Central e acesse as janelas pop-up de ajuda da tela inicial para visualizar as suas alterações.

2.4. Descritores de Implantação

As regras e os processos no Red Hat JBoss BPM Suite 6, ou superior, ficam armazenados em pacotes baseados no Apache Maven e são conhecidos como arquivos de conhecimento ou kjar. As regras, os processos, os ativos e etc fazem parte de um arquivo jar compilado e gerenciado pelo Maven. Um arquivo mantido dentro do diretório META-INF do kjar chamado kmodule.xml pode ser usado para definir as sessões e bases de conhecimento. Este arquivo kmodule.xml, por padrão, fica vazio.
Sempre que um componente de tempo de execução, como o Business Central, está prestes a processar o kjar, ele consulta kmodule.xml para construir a representação do tempo de execução.
Os Descritores de Implantação, um novo recurso introduzido na ramificação 6.1 do Red Hat BPM Suite, permitem que você controle sua implantação e também suplementam o arquivo kmodule.xml. A presença desses descritores é opcional e sua implantação procederá sem eles com êxito. As propriedades que você pode definir usando esses descritores são puramente técnicas, em natureza, e incluem valores meta, como persistência, auditoria e estratégia de tempo de execução.
Esses descritores permitem que você configure o servidor de execução em vários níveis (nível de servidor padrão, descriptor de implatação diferente por kjar, entre outros). Isso permite que você faça simples ajustes à configuração inicial do servidor de execução (possivelmente por kjar).
Você deve definir esses descritores em um arquivo chamado kie-deployment-descriptor.xml e deixar esse arquivo próximo ao seu arquivo kmodule.xml na pasta META-INF. Você pode mudar esse local padrão (e o nome do arquivo) ao especificá-lo como um parâmetro de sistema:
-Dorg.kie.deployment.desc.location=file:/path/to/file/company-deployment-descriptor.xml

2.4.1. Configuração dos Descritores de Implantação

Os descritores de implantação permitem que o usuário configure o servidor de execução em vários níveis:
  • nível de servidor: é o nível principal e é aquele que se aplica a todos kjars implantados no servidor.
  • nível kjar: permite que você configure os descritores com base em kjar.
  • nível de tempo de implantação: descritores que são aplicados durante a implantação de um kjar.
Os itens de configuração granular especificados pelos descritores de implantação têm prioridade sobre aqueles de nível de servidor, exceto nos casos dos itens de configuração que são baseados em coleção, os quais são mesclados. A hierarquia funciona da seguinte maneira: configuração do tempo de implantação > configuração kjar > configuração do servidor.

Nota

A configuração do tempo de implantação é aplicada às implantações feitas via API REST.
Por exemplo, se o modo de persistência (um dos itens que você pode configurar) definido no nível de servidor for NONE (Nenhum), mas esse mesmo modo estiver especificado como JPA no nível kjar, o modo, na verdade, será JPA para aquele kjar. Caso nada esteja especificado para o modo de persistência no descritor de implantação para esse kjar (ou caso não haja descritor de implantação algum), ele retrocederá para a configuração do nível de servidor, a qual é, nesse caso, NONE (Nenhum) (ou para JPA, caso não haja descritor de implantação do nível de servidor).

É possível substituir esse comportamento de modo de mesclagem hierárquica?

Sim. Na forma padrão, caso existam descritores de implantação presentes em vários níveis, as propriedades de configuração são mescladas com as granulares, substituindo os valores brutos, e com os itens de configuração ausentes no nível granular, sendo fornecidos com esses valores a partir de níveis mais altos. O resultado final é uma configuração do Descritor de Implantação mesclada. Esse modo de mesclagem padrão é chamado de modo MERGE_COLLECTIONS. Mas, você pode alterá-lo (Seção 2.4.2, “Gerenciando os Descritores de Implantação”) para um dos seguintes modos, caso não seja adequado para o seu ambiente:
  • KEEP_ALL: nesse modo, todos os valores de nível superior substituem todos os valores de nível inferior (os valores do nível do servidor substituem os valores do nível kjar)
  • OVERRIDE_ALL: nesse modo, todos os valores de nível inferior substituem todos os valores de nível superior (os valores kjar substituem os valores do nível do servidor)
  • OVERRIDE_EMPTY: nesse modo, todos os itens de configuração não vazia de níveis inferiores substituem aqueles em níveis superiores, incluindo os itens que estão representados como coleções.
  • MERGE_COLLECTIONS (PADRÃO): nesse modo, todos os itens de configuração não vazia de níveis inferiores substituem aqueles de níveis superiores (como em OVERRIDE_EMPTY), mas as propriedades de coleção são mescladas (combinadas).
Os Decritores de Implantação de kjars dependentes são colocados mais baixos do que o próprio kjar sendo implantado, mas eles ainda estão em uma posição mais elevada na hierarquia do que o nível do servidor.

Preciso fornecer um Descritor de Implantação completo para todos os kjars?

Não. E é exatamente aqui que a mesclagem entre os diferentes arquivos pode ser útil a você. É possível e recomendável o fornecimento de Descritores de Implantação parcial. Por exemplo, se quiser substituir apenas o modo de auditoria em um kjar, você precisa apenas fornecê-lo e o resto dos valores será mesclado a partir do nível do servidor ou dos kjars de nível superior.
É importante notar que, ao usar o modo de mesclagem OVERRIDE_ALL, todos os itens de configuração devem ser especificados já que os kjars relevantes sempre os usarão e não mesclarão com nenhum outro descritor de implantação na hierarquia.

O que pode ser configurado?

Os detalhes de configuração técnica de nível superior podem ser configurados através dos descritores de implantação. A tabela a seguir lista esses detalhes junto com os valores padrão e os valores permitidos.

Tabela 2.1. Descritores de Implantação

ConfiguraçãoEntrada XMLValores PermitidosValor Padrão
Nome da unidade de persistência para os dados de tempo de execução persistence-unitQualquer nome de pacote de persistência válido org.jbpm.domain
Nome da unidade de persistência para os dados de auditoriaaudit-persistence-unitQualquer nome de pacote de persistência válido org.jbpm.domain
Modo de persistênciapersistence-modeJPA, NENHUMJPA
Mode de auditoriaaudit-modeJPA, JMS ou NENHUMJPA
Estratégia de Tempo de Execuçãoruntime-strategySINGLETON, PER_REQUEST ou PER_PROCESS_INSTANCESINGLETON
Lista de Ouvintes de Evento a serem registradosevent-listenersNomes de classe de ouvintes válidos, como ObjectModelNenhum valor padrão
Lista de Ouvintes de Evento de Tarefa a serem registradostask-event-listenersNomes de classe de ouvintes válidos, como ObjectModelNenhum valor padrão
Lista de Manipuladores de Itens de Trabalho a serem registradoswork-item-handlersClasses de Manipuladores de Itens de Trabalho válidas fornecidas como NamedObjectHandlerNenhum valor padrão
Lista de Globais a serem registradasglobalsVariáveis globais válidas fornecidas como NamedObjectModelNenhum valor padrão
Estratégias de marshalling a serem registradas (para persistências variáveis conectáveis) marshalling-strategiesClasses ObjectModel válidasNenhum valor padrão
Funções necessárias que serão concedidas acesso aos recursos do kjarrequired-rolesNomes de funções de cadeia Nenhum valor padrão
Entradas de Ambiente adicionais para a Sessão de Conhecimentoenvironment-entriesNamedObjectModel válidoNenhum valor padrão
Opções de configuração adicionais da Sessão de Conhecimento configuraçõesNamedObjectModel válidoNenhum valor padrão

Como fornecer valores para itens de configuração baseados em coleções?

Você deve ter notado anteriormente, na tabela dos itens válidos de configuração, que os valores válidos para os itens baseados em coleção são ObjectModel ou NamedObjectModel. Ambos são semelhantes e fornecem uma definição do objeto a ser construído ou criado durante o tempo de execução, com exceção de que os detalhes do objeto NamedObjectModel nomeiam o objeto a ser observado. Esses dois tipos são definidos usando um identificador, parâmetros opcionais e um resolvedor (para resolver o objeto).
  • identificador - define todas as informações sobre o objeto, tais como o nome de classe totalmente qualificado, a identidade Spring bean ou uma expressão MVEL.
  • parâmetros - parâmetros opcionais que devem ser usados durante a criação de instâncias de objetos a partir deste modelo.
  • resolvedor - identificador do resolvedor que será usado para criar instâncias de objetos a partir do modelo - (reflection, mvel ou Spring).
Por exemplo, suponhamos que você tenha construído uma estratégia marshalling personalizada e queira que suas implantações usem essa estratégia ao invés da padrão, você precisará fornecer essa estratégia como um ObjectModel, com o identificador sendo com.mycompany.MyStrategy, o resolvedor sendo reflection (padrão e mais fácil) e quaisquer parâmetros necessários para a sua estratégia funcionar. O reflection será usado, então, para criar uma instância dessa estratégia usando o nome de classe totalmente qualificado que você forneceu como o identificador.
<marshalling-strategy> 
 <resolver>reflection</resolver> 
 <identifier>com.myCompany.MyStrategy</identifier> 
 <parameters>
    <parameter xsi:type="xs:string" xmlns:xs="http://www.w3.org/2001/XMLSchema">
      param
    </parameter>
  </parameters> 
</marshalling-strategy>
Caso o reflection baseado em resolvedores não seja suficiente (como demonstrado no exemplo anterior), você pode usar um resolvedor baseado na expressão MVEL, como o identificador do modelo do objeto. Durante o processo de avaliação das expressões, você pode substituir os parâmetros iniciais. Como no exemplo a seguir:
<marshalling-strategy> 
  <resolver>mvel</resolver> 
  <identifier>new com.myCompany.CustomStrategy(runtimeManager)</identifier> 
</marshalling-strategy>
O resolvedor baseado em Spring permite que você consulte um bean pelo seu identificador a partir de um contexto do aplicativo Spring. Toda vez que o JBoss BPM Suite é usado com Spring, esse resolvedor ajuda a implantar kjars no período de execução. Observe o exemplo a seguir (observe que o identificador, nesse caso, é um bean nomeado no contexto Spring):
<marshalling-strategy>
 <resolver>spring</resolver> 
 <identifier>customStrategy</identifier> 
</marshalling-strategy>

2.4.2. Gerenciando os Descritores de Implantação

Os Descritores de Implantação podem ser editados através do Business Central de duas formas: graficamente (clicando em CriaçãoCriação de Projeto e, depois, selecionando FerramentasDescritor de Implantação) ou clicando no menu CriaçãoAdministração e, depois, clicando na pasta META-INF no Explorador de Arquivo. Clique no arquivo kie-deployment-descriptor.xml para editá-lo manualmente.
Toda vez que um projeto é criado, um arquivo de estoque kie-deployment-descriptor.xml é gerado com valores padrão como descritos anteriormente.

Substituindo o Comportamento de Modo de Mesclagem Hierárquica

Para alterar o modo padrão de MERGE_COLLECTIONS para uma das opções KEEP_ALL, OVERRIDE_ALL ou OVERRIDE_EMPTY, você pode usar os seguintes métodos, dependendo dos requisitos.
  • Defina a propriedade do sistema org.kie.dd.mergemode com um desses valores. Esse modo de mesclagem se tornará padrão para todos kjars implantados no sistema, ao menos que você o substitua em um nível kjar usando o próximo método.
  • Quando implantando uma nova unidade de implantação através do Business Central (ImplantarImplantações), você pode selecionar o modo de mesclagem que deve ser usado para aquele kjar em particular.
  • Quando estiver implantando via API REST, você pode adicionar o parâmetro de consulta mergemode ao comando URL para um desses modos e definir o modo de mesclagem para essa implantação.

Restringindo o acesso ao Mecanismo de Tempo de Execução

Um dos itens de configuração discutidos anteriormente, required-roles, pode ser editado através dos Descritores de Implantação. Essa propriedade restringe o acesso ao mecanismo de tempo de execução ao nível do servidor ou kjar, assegurando que o acesso a certos processos seja concedido somente a usuários definidos por esta propriedade.
A função de segurança pode ser usada para restringir o acesso às definições do processo ou para restringir o acesso durante o tempo de execução.
O comportamento padrão é adicionar as funções necessárias às propriedades com base nas restrições dos repositórios. Você pode, é claro, editar essas propriedades manualmente, caso necessário, como descrito acima, fornecendo funções que correspondam com as funções definidas no realm de segurança.

2.5. Gerenciando a Polícia de Substituição de Implantação

Caso um usuário tente implantar um artefato com um GAV (Identidade de Grupo, Identidade de Artefato e Versão) que já exista no sistema, a implantação falhará e uma mensagem de erro será exibida no painel de Mensagens.
Esse recurso evita que o usuário sobrescreva uma implantação existente por engano.
Esse recurso é habilitado por padrão, ou seja, o sistema evitará que o usuário sobrescreva uma instalação existente com o mesmo GAV.
No entanto, podem haver situações em que o usuário possa querer sobrescrever as implantações existentes com o mesmo GAV. Embora você não possa fazer a sobrescrição com base nas implantações, você pode configurar esse recurso para o sistema como um todo, usando a definição de sistema org.kie.override.deploy.enabled. Essa definição é falsa por padrão. Altere-a para verdadeiro para habilitar a sobrescrição das implantações com o mesmo GAV durante o tempo de inicialização do seu servidor (-Dorg.kie.override.deploy.enabled=true).

2.6. Extendendo o Business Central

Ao iniciar a versão 6.1 do JBoss BPM Suite, o Business Central pode ser configurado para a adição de novas telas, menus, editores, telas iniciais e perspectivas pelo Administrador. Esses elementos podem extender a funcionalidade do Business Central e podem ser acessados através do menu Extensões e são classificados sob o Gerenciamento de Plug-ins.
Você pode, agora, definir seus próprios plug-ins baseados em HTML e Javascript para extender o Business Central e adicioná-los sem ter que se preocupar em copiar os arquivos no sistema de arquivo subjacente. A seguir uma tela é adicionada ao sistema para a demonstração das noções básicas dessa funcionalidade.

2.6.1. Gerenciamento de Plug-ins

Acesse a tela de Gerenciamento de Plug-ins clicando em ExtensõesGerenciamento de Plug-ins. Isso exibe a tela Plug-in Explorer que lista todos os plug-ins existentes sob suas perspectivas categorias: Plug-in de Perspectiva, Plug-in de Tela, Plug-in de Editor, Plug-in de Tela Inicial e Menu Dinâmico. Abra qualquer um desses plug-ins e você poderá ver os plug-ins existentes em cada categoria, incluindo os não editáveis gerados pelo sistema.
Vamos criar um novo plug-in que ecoe "Hello World" quando os usuários visitam a tela para esse plug-in. Em geral, os passos para a criação de um novo plug-in são:
  • Crie uma nova tela
  • Crie uma nova perspectiva (e adicione a nova tela a ela)
  • Crie um novo menu (e adicione uma nova perspectiva a ele)
  • Aplicativos (opcional)

Adicionando uma nova tela

Clique no botão Novo ... e selecione Nova Tela. Você será solicitado a inserir o nome dessa nova tela. Insira "HelloWorldJS" e pressione o botão OK. O editor do plug-in de tela abrirá, dividido em 4 seções: Modelo, CSS, JavaScript e Mídia.

Nota

Todos os elementos criados manualmente vão para as suas respectivas categorias, caso você queira editá-los depois. Nesse caso, abra o editor do plug-in de tela novamente, se você o fechou, e abra a categoria Plug-in de Tela e passe pelas telas geradas pelo sistema para ir até o plug-in criado manualmente por você e clique nele para abrir o editor do plug-in de tela de novo.
O Modelo é para onde o seu HTML vai, CSS é para o estilo, JavaScript é para as suas funções e Mídia é para o carregamento e gerenciamento de imagens.
Já que estamos criando um plug-in Hello World simples, insira o seguinte código na seção de Modelo: <div>My Hello World Screen</div>. Ele pode estar em qualquer código HTML e você pode usar as estruturas Angular e Knockout fornecidas. Para efeitos desse exemplo, não estamos usando nenhuma dessas estruturas, mas você pode escolher uma delas ao selecionar o menu suspenso na seção de Modelo.
Insira o seu código JavScript na seção javaScript. Alguns métodos e propriedades comuns são definidos para você, incluindo main, on_close e on_open. Para essa demonstração, selecione on_open e insira o seguinte: function () { alert('Hello World'); }
Clique no botão Salvar para concluir a criação da tela.

Adicionando uma nova Perspectiva

Uma vez que a tela tenha sido adicionada, você precisa criar uma perspectiva onde essa tela residirá. As perpectivas também podem ser criadas de maneira semelhante à criação de uma tela, clicando no botão Novo... e, então, selecionando Nova Perspectiva. Isso abrirá o editor do plug-in de perspectiva, semelhante ao editor do plug-in de tela.
O Editor de Perspectiva é como um gerador de grade que pode arrastar e soltar as telas e os componentes HTML. Remova quaisquer grades existentes do lado direito e, então, arraste uma grade 6 6 no lado direito.
Depois, abra a categoria Componentes e arraste um Componente de Tela ao lado direito (em qualquer grade). Isto abrirá a caixa de diálogo Editar Componente, onde você pode inserir a sua tela criada no passo anterior (HelloWorldJS). Clique no botão OK e, então, clique no botão para salvar essa perspectiva. Insira HelloWorldPerspective, insira Página Inicial no campo de nome da tag (e clique no botão Adicionar Tag) e clique no botão OK para concluir o que foi salvo.
Caso você precise carregar essa perspectiva novamente, você precisará do nome que deu a ela, já que essa perspectiva não aparece na lista de perspectivas. Para carregar, clique no botão e insira o nome da perspectiva.

Adicionando um novo menu

O passo final na criação do nosso plug-in é a adição de um menu dinâmico de onde a nova tela/ perspectiva possa ser chamada. Para fazer isso, vá até ExtensõesGerenciamento de Plug-ins e, então, clique no botão Novo ... para selecionar Novo Menu Dinâmico. Dê um nome a esse menu dinâmico (HelloWorldMenu) e clique no botão OK. O editor do menu dinâmico abrirá.
Insira o nome da perspectiva (HelloWorldPerspective) como a Id de Atividade e o nome para o menu suspenso (HelloWorldMenuDropDown). Clique no botão OK e, depois, no botão Salvar.
Esse novo menu será adicionado ao seu workbench na próxima vez que você atualizar o Business Central. Para ver HelloWorldMenu adicionado ao seu menu de nível superior, atualize-o agora. Clique nele para exibir HelloWorldMenuDropDown, o qual, ao ser clicado, abrirá a sua perspectiva/tela com a mensagem Hello World.
Você criou o seu primeiro Plug-in!

Trabalhando com Aplicativos (Opcional)

Caso você crie vários plug-ins, você pode usar o recurso do diretório de Aplicativos para organizar seus próprios componentes e plug-ins, ao invés de depender apenas das entradas do menu superior.
Quando você salva uma nova perspectiva, você pode adicionar rótulos (tags) a ela e esses rótulos (tags) serão usados para associar uma perspectiva a um diretório de Aplicativos. Você pode abrir os diretórios de Aplicativos clicando em ExtensõesApps.
O diretório de Aplicativos fornece uma maneira alternativa de abrir a sua perspectiva. Quando você criou o seu HelloWorldPerspective, você inseriu a tag Página Inicial. O diretório de Aplicativos contém um único diretório, por padrão, chamado Página Inicial, ao qual você associou a sua perspectiva. E é onde você a encontrará quando abrir o diretório de Aplicativos. Você pode clicar nele para executar a perspectiva agora.
Você pode criar múltiplos diretórios e associar as perspectivas a esses diretórios, dependendo das exigências funcionais e verticais do negócio. Por exemplo, você poderia criar um diretório RH e, então, associar todas as perspectivas relacionadas ao RH a esse diretório para gerenciar melhor os aplicativos.
Você pode criar um novo diretório, clicando em:

2.6.2. API JavaScript (JS) para Extensões

A extensibilidade do Business Central é obtida através de uma API JavaScript (JS) subjacente, a qual é carregada automaticamente caso seja colocada na pasta de plug-ins do webapp do Business Central (geralmente: {INSTALL_DIR}/business-central.war/plugins/), ou carregada através das chamadas regulares JavaScript.
Essa API é dividida em vários conjuntos de acordo com as funcionalidades que ela desempenha.
  • API Register Perspective: permite a criação dinâmica das perspectivas. O exemplo abaixo cria um painel usando o método registerPerspective:
    				
    $registerPerspective({
        id: "Home",
        is_default: true,
        panel_type: "org.uberfire.client.workbench.panels.impl.MultiListWorkbenchPanelPresenter",
        view: {
            parts: [
                {
                    place: "welcome",
                    min_height: 100,
                    parameters: {}
                }
            ],
            panels: [
                {
                    width: 250,
                    min_width: 200,
                    position: "west",
                    panel_type: "org.uberfire.client.workbench.panels.impl.MultiListWorkbenchPanelPresenter",
                    parts: [
                        {
                            place: "YouTubeVideos",
                            parameters: {}
                        }
                    ]
                },
                {
                    position: "east",
                    panel_type: "org.uberfire.client.workbench.panels.impl.MultiListWorkbenchPanelPresenter",
                    parts: [
                        {
                            place: "TodoListScreen",
                            parameters: {}
                        }
                    ]
                },
                {
                    height: 400,
                    position: "south",
                    panel_type: "org.uberfire.client.workbench.panels.impl.MultiTabWorkbenchPanelPresenter",
                    parts: [
                        {
                            place: "YouTubeScreen",
                            parameters: {}
                        }
                    ]
                }
            ]
        }
    });
    
  • API Editor: permite que você crie dinamicamente editores e os associe com um tipo de arquivo. O exemplo abaixo cria um editor de amostra e o associa com um tipo de arquivo filename.
    
    $registerEditor({
        "id": "sample editor",
        "type": "editor",
        "templateUrl": "editor.html",
        "resourceType": "org.uberfire.client.workbench.type.AnyResourceType",
        "on_concurrent_update":function(){
            alert('on_concurrent_update callback')
            $vfs_readAllString(document.getElementById('filename').innerHTML, function(a) {
                document.getElementById('editor').value= a;
            });
        },
        "on_startup": function (uri) {
            $vfs_readAllString(uri, function(a) {
                alert('sample on_startup callback')
            });
        },
        "on_open":function(uri){
            $vfs_readAllString(uri, function(a) {
                document.getElementById('editor').value=a;
            });
            document.getElementById('filename').innerHTML = uri;
        }
    });
    Além dos métodos on_startup e on_open apresentados no exemplo anterior, a API expõe os seguintes eventos de retorno de chamada para o gerenciamento do ciclo de vida do editor:
    • on_concurrent_update;
    • on_concurrent_delete;
    • on_concurrent_rename;
    • on_concurrent_copy;
    • on_rename;
    • on_delete;
    • on_copy;
    • on_update;
    • on_open;
    • on_close;
    • on_focus;
    • on_lost_focus;
    • on_may_close;
    • on_startup;
    • on_shutdown;
    Você pode exibir esse editor através de um modelo html:
    <div id="sampleEditor">
        <p>Sample JS editor (generated by editor-sample.js)</p>
        <textarea id="editor"></textarea>
    
        <p>Current file:</p><span id="filename"></span>
        <button id="save" type="button" onclick="$vfs_write(document.getElementById('filename').innerHTML, document.getElementById('editor').value,  function(a) {});">Save</button>
        <br>
    
        <p>This button change the file content, and uberfire send a callback to the editor:</p>
        <button id="reset" type="button" onclick="$vfs_write(document.getElementById('filename').innerHTML, 'Something else',  function(a) {});">Reset File</button>
    </div>
    
  • API PlaceManager: os métodos dessa API permitem que você solicite ao Business Central a exibição de um componente em particular associado ao destino: $goToPlace("componentIdentifier");
  • API Register plu-in: os métodos dessa API permitem que você crie plug-ins dinâmicos (que serão transformados em telas do Business Central) via a API JS.
    $registerPlugin( {
        id: "my_angular_js",
        type: "angularjs",
        templateUrl: "angular.sample.html",
        title: function () {
            return "angular " + Math.floor(Math.random() * 10);
        },
        on_close: function () {
            alert("this is a pure JS alert!");
        }
    });
    O plug-in faz referência ao modelo angular.sample.html:
    
    <div ng-controller="TodoCtrl">
        <span>{{remaining()}} of {{todos.length}} remaining</span>
        [ <a href="" ng-click="archive()">archive</a> ]
        <ul class="unstyled">
            <li ng-repeat="todo in todos">
                <input type="checkbox" ng-model="todo.done">
                <span class="done-{{todo.done}}">{{todo.text}}</span>
            </li>
        </ul>
        <form ng-submit="addTodo()">
            <input type="text" ng-model="todoText" size="30" placeholder="add new todo here">
            <input class="btn-primary" type="submit" value="add">
        </form>
        <form ng-submit="goto()">
            <input type="text" ng-model="placeText" size="30" placeholder="place to go">
            <input class="btn-primary" type="submit" value="goTo">
        </form>
    </div>
    
    Um plug-in pode ser associado a eventos do Business Central através de uma série de chamadas de retorno JavaScript:
    • on_concurrent_update;
    • on_concurrent_delete;
    • on_concurrent_rename;
    • on_concurrent_copy;
    • on_rename;
    • on_delete;
    • on_copy;
    • on_update;
    • on_open;
    • on_close;
    • on_focus;
    • on_lost_focus;
    • on_may_close;
    • on_startup;
    • on_shutdown;
  • API Register splash screens: usa os métodos nessa API para criar telas iniciais
    $registerSplashScreen({
        id: "home.splash",
        templateUrl: "home.splash.html",
        body_height: 325,
        title: function () {
            return "Cool Home Splash " + Math.floor(Math.random() * 10);
        },
        display_next_time: true,
        interception_points: ["Home"]
    });
    
    
  • API Virtual File System (VFS): com essa API, você pode ler e gravar um arquivo salvo no sistema de arquivos usando uma chamada assíncrona.
    $vfs_readAllString(uri,  function(a) {
      //callback logic
    });
        
    $vfs_write(uri,content,  function(a) {
      //callback logic
    })
    

2.7. Configurando Colunas de Tabela

O Business Central permite que você configure os modos de exibição que contêm listas de itens na forma de tabelas. Você pode redimensionar, mover e classificar as colunas e adicionar ou remover a lista padrão de colunas. Essa funcionalidade é fornecida para todos os modos de exibição que contêm tabelas.
Depois que você aplicar as alterações às colunas de um modo de exibição de tabela, essas alterações serão mantidas para o usuário conectado.

Adicionando e Removendo Colunas

As tabelas que permitem que suas colunas sejam configuradas possuem o botão no canto superior direito. Ao clicar nesse botão, uma lista das colunas que podem ser adicionadas ou removidas da atual tabela abrirá com uma caixa de verificação próxima a cada coluna:

Redimensionando Colunas

Para redimensionar as colunas, coloque o seu cursor entre as bordas do cabeçalho da coluna e mova-o na direção que você desejar:

Movendo Colunas

Para reordenar e arrrastar e soltar uma coluna para uma posição diferente, focalize o mouse sobre a área mais à direita do cabeçalho da coluna: .
Você pode, agora, arrastar a coluna e movê-la: .
Solte-a sobre o cabeçalho da coluna onde você gostaria de deixá-la.

Classificando Colunas

Para classificar as colunas, clique no cabeçalho da coluna que deseja configurar. Para reverter a classificação, clique no cabeçalho novamente.

Capítulo 3. Configuração da Linha de Comando

kie-config-cli é uma ferramenta de configuração da linha de comando que fornece as capacidades para gerenciar o repositório do sistema a partir da linha de comando e pode ser usada em modo online ou offline.
  1. Modo Online (padrão e recomendado) - mediante inicialização, a ferramenta conecta-se a um repositório Git usando um servidor Git fornecido por kie-wb. Todas as alterações são feitas localmente e enviadas para o upstream somente após a execução explícita do comando push-changes. Use o comando exit para publicar as alterações locais. Para descartar as alterações locais ao sair, use o comando discard.
  2. Modo Offline (um estilo de instalador) - cria e manipula o repositório do sistema diretamente no servidor (não há opção discard).
A ferramenta está disponível no Portal do Consumidor Red Hat. Para baixar a ferramenta kie-config-cli, siga as instruções a seguir:
  1. Vá até o Portal do Consumidor Red Hat e faça o log in.
  2. Clique em DownloadsDownloads de Produtos.
  3. Na página Downloads de Produtos que abrir, clique em Red Hat JBoss BPM Suite.
  4. A partir do menu suspenso Versão, selecione a versão 6.1.
  5. Na tabela exibida, navegue até a linha Ferramentas Suplementares e depois clique em Download.
Extraia o pacote zip para as ferramentas suplementares que você baixou a partir do Portal do Consumidor Red Hat. Ele contém o diretório kie-config-cli-6.MINOR_VERSION-redhat-x-dist com o arquivo kie-config-cli.sh.

3.1. Iniciando a Ferramenta kie-config-cli no Modo Online

  1. Para iniciar a ferramenta kie-config-cli no modo online, navegue até o diretório kie-config-cli-6.MINOR_VERSION-redhat-x-dist onde você instalou a ferramenta e, então, execute o comando a seguir.
  2. Em um ambiente Unix, execute:
    ./kie-config-cli.sh
    Em um ambiente Windows, execute:
    ./kie-config-cli.bat
A ferramenta inicia, por padrão, no modo online e solicita as credenciais do usuário e um URL do Git para conectar-se (o valor padrão é git://localhost/system). Para conectar-se a um servidor remoto, substitua o host e a porta por valores adequados. Exemplo: git://kie-wb-host:9148/system

3.2. Iniciando a Ferramenta kie-config-cli no Modo Offline

Para operar em modo offline, anexe o parâmetro offline ao comando, como demonstrado abaixo.
  1. Navegue até o diretório kie-config-cli-6.MINOR_VERSION-redhat-x-dist onde você instalou a ferramenta.
  2. Em um ambiente Unix, execute:
    ./kie-config-cli.sh offline
    Em um ambiente Windows, execute:
    ./kie-config-cli.bat offline
A execução desse comando altera o comportamento da ferramenta e exibe uma solicitação para especificar a pasta onde o repositório do sistema (.niogit) está localizado. Caso .niogit ainda não exista, o valor da pasta pode ser deixado vazio e uma nova configuração é criada.

3.3. Comandos Disponíveis para a Ferramenta kie-config-cli

Os seguintes comandos estão disponíveis para o gerenciamento do repositório GIT usando a ferramenta kie-config-cli:
  • add-deployment - adiciona uma nova unidade de implantação
  • add-repo-org-unit - adiciona um repositório à unidade organizacional
  • add-role-org-unit - adiciona funções a uma nova unidade organizacional
  • add-role-project - adiciona funções a um projeto
  • add-role-repo - adiciona funções a um repositório
  • create-org-unit - cria uma nova unidade organizacional
  • create-repo - cria um novo repositório git
  • discard -não publica alterações locais, limpa diretórios temporários e fecha a ferramenta
  • exit - publica o trabalho, limpa os diretórios temporários e fecha a ferramenta
  • fetch-changes - busca alterações a partir do repositório upstream
  • help - imprime os comandos disponíveis com descrições
  • list-deployment - lista as implantações disponíveis
  • list-org-units - lista as unidades organizações disponíveis
  • list-repo - lista os repositórios disponíveis
  • push-changes - envia alterações por push para o repositório upstream (em modo online apenas)
  • remove-deployment - remove implantações existentes
  • remove-org-unit - remove unidades organizacionais existentes
  • remove-repo - remove um repositório existente da config apenas
  • remove-repo-org-unit - remove um repositório da unidade organizacional
  • remove-role-org-unit - remove funções de uma unidade organizacional
  • remove-role-project - remove funções de um projeto
  • remove-role-repo - remove funções de um repositório

Capítulo 4. Migração

A migração dos seus projetos do Red Hat JBoss BPM Suite 5 para o Red Hat JBoss BPM Suite 6 exige um planejamento rigoroso e uma avaliação passo a passo dos diversos problemas. Você pode planejar a migração manualmente ou usando processos automáticos. A maioria das migrações em um cenário real exigirá uma combinação desses dois processos.
Já que o JBoss BPM Suite 6 utiliza o GIT para o armazenamento de ativos, artefatos e repositórios de códigos, incluindo processos e regras, você deve começar criando um projeto vazio no JBoss BPM Suite 6, como a base para a sua migração, com arquivos fictícios como substitutos para os vários ativos e artefatos. A execução de um clone do GIT desse projeto vazio no seu IDE de preferência iniciará o processo de migração.
Baseado nos arquivos substitutos no seu projeto clonado, você pode começar a adicionar os ativos nos locais corretos. O sistema do JBoss BPM Suite 6 é inteligente o suficiente para compreender essas alterações e aplicá-las adequadamente. Certifique-se de que, quando estiver importando os arquivos de regras antigas, eles sejam importados com a estrutura do nome do pacote correta.
Como o Maven é usado para a criação de projetos, os ativos de projetos, como regras, processos e modelos, são acessíveis como um simples arquivo jar.
Essa seção lista passo a passo as maneiras geralmente aceitas para a migração do seu projeto. Porém, tratam-se de diretrizes apenas, podendo variar bastante o processo de migração propriamente dito.
No geral, você deve...
  1. Migrar primeiro os dados: eles são os seus ativos empresariais.
  2. Migrar, em seguida, os processos do tempo de execução.
  3. E, por fim, converter as chamadas API antigas em novas, uma por uma.
Esses passos serão analisados mais detalhadamente nas seções a seguir.

4.1. Migração dos Dados

Para migrar os dados do Red Hat JBoss BPM Suite 5, siga as instruções a seguir:
  1. Baixe a ferramenta de migração fazendo o login no Portal do Consumidor Red Hat e, depois, navegue até a seção de Downloads de Software do Red Hat JBoss BPM Suite. Clique em Red Hat JBoss BPM Suite Migration Tool para baixar o arquivo zip.
  2. Descomprima o arquivo zip baixado em um diretório de sua escolha e navegue até esse diretório em um prompt de comando. Esse diretório contém quatro pastas:
    • bin - contém os scripts de inicialização
    • jcr-exporter-libs - contém as bibliotecas específicas à parte export-from-JCR da migração.
    • vfs-importer-libs - contém as bibliotecas específicas à parte import-into-Git da migração.
    • conf - contém a configuração global da ferramenta de migração.
  3. Para os bancos de dados de produção, copie o driver JDBC no banco de dados utilizado pelo repositório JCR no diretório jcr-exporter-libs da ferramenta de migração.
  4. Execute os seguintes comandos:
    ./bin/runMigration.sh -i <source-path> -o <destination-path> -r <repository-name>
Onde:
  • <source-path> é um caminho para um repositório JCR fonte.
  • <desintation-path> é um caminho para um destino GIT VFS. Essa pasta não deve existir ainda.
  • <repository-name> é um nome arbitrário para o novo repositório.
O repositório é migrado no destino especificado.
Além do comando -i, você também pode usar -h, para imprimir uma mensagem de ajuda, e -f, para forçar a substituição do diretório de saída, eliminando, assim, a necessidade de excluir manualmente esse diretório.

Importando o repositório no Business Central

O repositório pode ser importado no Business Central clonando-o. Na perspectiva de administração, clique no menu Repositórios e, depois, clique no menu Clonar Repositório para iniciar o processo.

Nota

Os ativos também podem ser migrados manualmente, pois são apenas arquivos de texto. A especificação BPMN2 e a sintaxe DRL não passaram por alterações entre as diferentes versões.

Importando o repositório no JBDS

Para importar o repositório no JBoss Developer Studio, siga as instruções a seguir:
  1. Inicie o JBoss Developer Studio.
  2. Inicie o Red Hat JBoss BPM Suite Server (caso não esteja em execução ainda) selecionando o servidor através da guia servidor e clique no ícone iniciar.
  3. Selecione ArquivoImportar... e navegue até a pasta Git. Abra a pasta Git para selecionar os Projetos do Git e clique em avançar.
  4. Selecione a origem do repositório como Repositório local existente e clique em avançar.
  5. Selecione o repositório a ser configurado a partir da lista dos repositórios disponíveis.
  6. Importe o projeto como um projeto geral na próxima janela e clique em avançar. Nomeie este projeto e clique em Concluir.

4.2. Migração do Tempo de Execução

Para executar os processos do Red Hat JBoss BPM Suite 5 no Red Hat JBoss BPM Suite 6, siga as instruções a seguir:
  1. Defina a propriedade do sistema jbpm.v5.id.strategy como verdadeira no arquivo standalone.xml do JBoss BPM Suite:
    <property name="jbpm.v5.id.strategy" value="true"/>
  2. Carregue KieSession como demonstrado aqui:
    KieSession ksession = JPAKnowledgeService.loadStatefulKnowledgeSession(sessionID, kbase, sessionConf, env);
  3. Continue a execução normal do processo usando métodos KieSession:
    ksession.signalEvent("SomeEvent", null);

4.3. Compatibilidade com Versões Anteriores e API

Migrando para a Versão 6.1

Na versão 6.1, as APIs 5.x  não possuem mais suporte oficialmente.
O Red Hat JBoss BPM Suite não fornece mais compatibilidade retroativa com a interface de programação de aplicativo (API) de processos, eventos e regras através do JBoss BRMS 5. O conteúdo do arquivo knowledge-api JAR não possui mais suporte na versão 6.1 e foi substituído pelas APIs contidas no arquivo kie-api JAR que foram introduzidas no JBoss BPM Suite 6.0.
Se você usava a API 5.x legada (localizada em knowledge-api.jar), por favor migre (reescreva) as chamadas da API  para a nova APIKIE . Por favor, esteja ciente de que outras APIs foram alteradas entre o JBoss BRMS 5.x e o JBoss BPM Suite 6.x, como a API de serviço de tarefas e a API REST.

Migrando para a Versão 6.0

O sistema do JBoss BPM Suite 6 fornece compatibilidade retroativa com as interações de processos, eventos e regras a partir do JBoss BRMS 5. Você deve migrar (reescrever), eventualmente, essas interações para a API de núcleo reformatada e nova, pois essa compatibilidade retroativa será provavelmente preterida.
Caso você não possa migrar o seu código para usar a nova API, você pode usar a API fornecida pelo jar knowledge-api criado especificamente para o código de compatibilidade retroativa. Essa API é uma interface pública, capaz de funcionar com o JBoss BPM Suite e o JBoss BRMS e é compatível com versões anteriores.
Caso você esteja usando a API REST no JBoss BPM Suite 5, observe que ela recebeu alterações também e não há mecanismo algum nela para a compatibilidade com versões anteriores.

4.4. Migrando o Serviço de Tarefas

O JBoss BPM Suite 6 fornece suporte apenas para um serviço de tarefas em execução local. Isto significa que você não precisa configurar nenhum serviço de mensagem no seu projeto - diferentemente do JBoss BPM Suite 5, que fornecia um serviço de tarefas que estava ligado ao mecanismo principal usando, geralmente, o sistema de mensagem fornecido pelo HornetQ.
Para ajudar a diminuir essa distância até que você possa fazer a migração na sua atual arquitetura, existe um assistente ou método utilitário, o LocalHTWorkItemHandler.
Como a API TaskService faz parte da API pública, você precisará, agora, refatorar as suas importações devido às alterações do pacote, assim como refatorar os seus métodos devido às alterações da própria API.

Capítulo 5. Gerenciamento de Dados

5.1. Backup de dados

Quando estiver aplicando um mecanismo de backup ao Red Hat JBoss BPM Suite, certifique-se de fazer o backup dos seguintes recursos:
  • quaisquer descritores de implantação personalizados (tais como, web.xml, jboss-web.xml, jboss.xml)
  • quaisquer arquivos de propriedades personalizadas

    Nota

    Considere fazer o backup completo dos arquivos business-central.war e dashbuilder.war

5.2. Configuração de Índices

Configure os índices de chaves estrangeiras

Alguns bancos de dados, como Oracle e Postgres, não criam automaticamente um índice para cada chave estrangeira, o que pode resultar na ocorrência de deadlocks. Para evitar essa situação, é necessário criar um índice em todas as chaves estrangeiras, principalmente no banco de dados do Oracle.

Configure os índices para o Painel de Tarefas e de Processos

O Painel de Tarefas e Processos na versão 6.1 foi refatorado para lidar com o alto volume de instâncias de processos e tarefas. Para a obtenção de um bom tempo de resposta enquanto consultando o banco de dados, as seguintes tabelas do JBoss BPM Suite precisam ser indexadas: processinstancelog e bamtasksummary.
Observe que TODAS as colunas nessas duas tabelas precisam ser indexadas e não apenas as chaves primárias e estrangeiras.

5.3. Configurando o Banco de Dados

O aplicativo Dashbuilder necessita de um banco de dados existente, criado anteriormente antes da execução do aplicativo. Para criar um banco de dados, você pode usar qualquer ferramenta do cliente do banco de dados e executar os seguintes comandos:
Postgres
A frase sql a seguir é usada para criar um banco de dados Postgres:
CREATE DATABASE dashbuilder
  WITH ENCODING='UTF8'
         OWNER=dashbuilder
         CONNECTION LIMIT=-1

Nota

A codificação do banco de dados deve ser UTF8
DB2
O banco de dados DB2 pode ser criado usando a frase sql a seguir:
CREATE DATABASE dashb PAGESIZE 16384

Nota

O tamanho da página (pagesize) padrão para os sistemas DB2 é 4k, o que não é suficiente para o tamanho das colunas da tabela do Dashbuilder. O tamanho da página deve ser forçado para 16384, como apresentado na frase acima.
Depois que o banco de dados é criado, a fonte de dados do servidor do aplicativo deve ser configurada. Você deve editar o arquivo de configuração do JBoss EAP e configurar o subsistema da fonte de dados, como os exemplos a seguir:
<datasource jndi-name="java:jboss/datasources/jbpmDS" enabled="true" use-java-context="true" pool-name="postgresqlDS">
    <connection-url>jdbc:postgresql://localhost/test</connection-url>
    <driver>postgresql</driver>
    <pool></pool>
    <security>
       <user-name>sa</user-name>
       <password>sa</password>
    </security>
</datasource>
<drivers>
    <driver name="postgresql" module="org.postgresql">
        <xa-datasource-class>org.postgresql.xa.PGXADataSource</xa-datasource-class>
    </driver>
</drivers>

5.4. Editando o Banco de Dados

O Dashbuilder necessita que o JBoss BPM Suite tenha tabelas do banco de dados do log do histórico. É mandatória a implantação do console de Tarefas Humanas (ou um superset, ex.: kie-wb) primeiro. Caso contrário, o Painel não será inicializado corretamente e não será possível exibir os seus indicadores chave de desempenho.
O aplicativo é configurado, por padrão, para usar uma fonte de dados com o seguinte nome JNDI:
java:jboss/datasources/ExampleDS
Isto é especificado no arquivo de configuração do JBoss EAP; por exemplo, standalone.xml.

Nota

Essa fonte de dados é usada para fins de demonstração/desenvolvimento e está presente em qualquer instalação JBoss por padrão.
Caso queira implantar em um banco de dados diferente do H2, como Oracle, MySQL, Postgres ou MS SQL Server, por favor realize os seguintes passos:

Procedimento 5.1. Alterando o Banco de Dados

  1. Instale o driver do banco de dados no JBoss (consulte a documentação do driver JBoss).
  2. Crie um banco de dados e uma fonte de dados JBoss que conecta-se ao driver do banco de dados.
  3. Modifique o arquivo dashbuilder.war/WEB-INF/jboss-web.xml:
    <jboss-web>
       <context-root>/dashbuilder</context-root>
       <resource-ref>
           <res-ref-name>jdbc/dashbuilder</res-ref-name>
           <res-type>javax.sql.DataSource</res-type>
           <jndi-name>java:jboss/datasources/myDataSource</jndi-name>
       </resource-ref>
       ...
    
  4. Substitua o valor do parâmetro jndi-name pelo caminho JNDI da fonte de dados JBoss que você criou.
  5. Modifique o arquivo dashbuilder.war/WEB-INF/jboss-deployment-structure.xml
  6. Adicione o seguinte trecho de configuração à tag deployment, onde jdbcDriverModuleName é o nome do módulo do driver JBoss JDBC:
      <dependencies>
          <module name="jdbcDriverModuleName" />
      </dependencies>
    

5.5. Scripts DDL

Os scripts DDL para as tabelas do banco de dados para ambos JBoss BRMS e BPM Suite estão disponíveis para download através do Portal do Consumidor. Esses scripts permitem que você estude as tabelas e usem-nas para criar as tabelas e os índices manualmente ou em bancos de dados que não possuem suporte direto.
Para baixar esse scripts, faça o login no Portal do Consumidor e clique em Red Hat JBoss BPM Suite. Selecione a versão do produto que atenda às suas exigências e, então, clique em Download na linha Red Hat JBoss BPM Suite 6.x.x Supplementary Tools para baixar as ferramentas suplementares.
Descompacte o arquivo no seu computador. Os scripts DDL estão localizados na pasta ddl-scripts. Os scripts do banco de dados são fornecidos para DB2, H2, MySQL5, Oracle, PostgreSQL e SQLServer.
O diagrama completo do Relacionamento entre Entidades pode ser visto em Red Hat Solution.

Capítulo 6. Repositório de Ativos

Os arquivos de definição das Regras e dos Processos Empresariais e de outros ativos e recursos criados no Business Central são armazenados no Repositório de Ativos, o qual também é conhecido como Knowledge Store.
O Knowledge Store é um repositório centralizado para os conhecimentos do seu negócio. Ele conecta-se ao repositório GIT que permite o armazenamento dos diferentes tipos de artefatos e ativos de conhecimento em um único local. O Business Central fornece um front-end da web, permitindo aos usuários visualizar e atualizar o conteúdo armazenado. Você pode acessá-lo usando o Explorador de Projeto do ambiente unificado do Red Hat JBoss BPM Suite.

6.1. Criando um Repositório

Importante

Observe que apenas o usuário com a função ADMIN pode criar um repositório.

Procedimento 6.1. Criando um novo repositório

  1. Abra a perspectiva Administração: no menu principal, clique em CriaçãoAdministração.
  2. No menu de perspectiva, clique em RepositóriosNovo Repositório.
  3. A janela pop-up Criar Repositório é exibida.
    A screenshot of the BRMS Administration menu - Create repository pop-up window

    Figura 6.1. Janela Pop-up Criar Repositório

  4. Insira os detalhes mandatórios:
    • Nome do repositório.

      Nota

      Observe que o nome do repositório deve ser um nome de arquivo válido. Evite usar espaço ou caracteres especiais que possam gerar um nome de pasta inválido.
    • Selecione a unidade organizacional na qual o repositório será criado a partir da opção suspensa Unidade Organizacional.
  5. Clique em Concluir
O novo repositório pode ser visualizado no Explorador de Arquivos ou Explorador de Projeto.

6.2. Clonando um Repositório

Importante

Observe que apenas o usuário com a função ADMIN pode clonar um repositório.

Procedimento 6.2. Clonando um Repositório

  1. Abra a perspectiva Administração.
  2. No menu Repositórios, selecione Clonar repositório.
  3. A janela pop-up Clonar Repositório é exibida.
    A screenshot of the BRMS Administration menu - Clone repository pop-up window

    Figura 6.2. Janela Pop-up Clonar Repositório

  4. Na janela de diálogo Clonar Repositório, insira os detalhes do repositório:
    1. Insira o Nome do Repositório a ser usado como o identificador do repositório no Repositório de Ativos e selecione a Unidade Organizacional onde ele deve ser adicionado.
    2. Insira o URL do repositório GIT:
      • Para um Repositório Local: file:///path-to-repository/reponame
      • Para um Repositório remoto ou preexistente: git://hostname/reponame

      Nota

      O protocolo do arquivo possui suporte somente para as operações de 'LEITURA'. As operações de 'GRAVAÇÃO' não possuem suporte.
    3. Se necessário, insira o Nome do Usuário e a Senha usados para autenticação, quando clonando o repositório.
  5. Clique em Clonar.
  6. Um prompt de confirmação com o botão OK será exibido, notificando o usuário de que o repositório foi criado com êxito. Clique em OK. O repositório será indexado. Alguns recursos do workbench estarão indisponíveis até que a indexação esteja completa.
O repositório clonado pode ser verificado no Explorador de Arquivos ou Explorador de Projeto.

6.3. Removendo um Repositório

Os repositórios podem ser removidos usando qualquer um dos procedimentos a seguir.

Removendo um Repositório do Business Central

A forma mais simples de remover um repositório é usando o RepositoryEditor no Business Central.

Procedimento 6.3. Usando o Business Central para Remover um Repositório

  1. Acesse o RepositoryEditor no Business Central CriaçãoAdministração.
  2. Selecione Repositórios do menu de árvore à esquerda.
  3. No RepositoryEditor à direita, localize o repositório a ser excluído da lista dos repositórios disponíveis.
  4. Selecione mestre do menu suspenso e clique no botão Excluir.
  5. A seguinte mensagem aparecerá:
    Você tem certeza que deseja remover o Repositório "<$RepositoryName>"? Alguns editores podem tornar-se inoperáveis caso seus conteúdos estejam inacessíveis.
    Pressione Ok para excluir.

Removendo um Repositório Usando a Ferramenta kie-config-cli

Os repositórios podem ser removidos usando a ferramenta kie-config-cli através do comando remove-repo.
Para mais informações sobre a ferramenta kie-config-cli, consulte Capítulo 3, Configuração da Linha de Comando .

Removendo um Repositório Usando API REST

Para remover um repositório do Knowledge Store, emita o chamado DELETE REST API. Esse chamado baseia-se na criação de uma sessão HTTP autenticada pelo usuário antes de emitir esse comando.

Exemplo 6.1. Removendo um repositório usando curl

curl -H 'Accept: application/json' -H 'Content-Type: application/json' -X DELETE 'localhost:8080/business-central/rest/repositories/REPOSITORY_NAME'

6.4. Gerenciando Ativos

Nota

O conteúdo nessa seção é classificado como Visualização Técnica para o lançamento 6.1 do Red Hat JBoss BPM Suite. É fornecido tal como é, sem suporte.
Para ativar e usar os recursos descritos aqui, você precisará fazer o login no Business Central como um usuário que tenha recebido a função especial de kiemgmt.
Para realizar o gerenciamento de projetos de forma mais fácil, o Red Hat JBoss BPM Suite fornece, agora, uma maneira de gerenciar múltiplos projetos baseada em padrões. Isto permite a criação de estruturas de repositórios através das melhores práticas do setor para a manutenção, o controle de versão e a distribuição dos seus projetos.
Para começar, os repositórios podem, agora, ser gerenciados ou não gerenciados.

Repositórios Gerenciados e Não Gerenciados

Os Repositórios Não Gerenciados são as estruturas de repositório com as quais você está acostumado a lidar. Eles podem conter múltiplos projetos não relacionados entre si.
Os Repositórios Gerenciados, por outro lado, fornecem um controle de versão ao nível do projeto e ramificações do projeto para o gerenciamento do ciclo de lançamento. Além disso, os Repositórios Gerenciados podem estar restritos a apenas um projeto ou abranger múltiplos projetos. Quando um Repositório Gerenciado é criado, o processo de configuração do gerenciamento de ativos é iniciado para a criação das ramificações do repositório, assim como para a estrutura correspondente do projeto.
Para criar um Repositório Gerenciado ou Não Gerenciado, abra a tela para a criação de um novo repositório. Vá até CriaçãoAdministração e depois clique em RepositóriosNovo Repositório. Isto faz com que a tela Novo Repositório seja exibida.
A criação do Repositório Não Gerenciado acontece da mesma maneira. Insira o nome do repositório e selecione a unidade organizacional a que ele pertence e clique no botão Concluir.
Para criar um Repositório Gerenciado, selecione a caixa de verificação Repositório Gerenciado, após fornecer um nome ao repositório e à unidade organizacional a que ele pertence. Clique no botão Avançar e insira os detalhes desse Repositório Gerenciado.
Selecione o rótulo Projeto Único se o projeto que você estiver criando for um projeto simples e autocontido. Insira os detalhes do projeto gerenciado, junto com os detalhes GAV. Mais tarde, você não será capaz de adicionar mais projetos a esse repositório.
Para os projetos mais complexos, onde é provável haver um projeto pai abrangendo os outros projetos menores, selecione o repositório com Multi-Projetos. Todos os projetos criados em um repositório com multi-projetos serão gerenciados juntos, com os seus números de versão sendo incrementados juntos também. Além disso, insira os detalhes do projeto pai e o GAV, os quais serão herdados por todos os projetos futuros que você criar nesse Repositório Gerenciado.

Ramificações Gerenciadas

Junto com os Respositórios Gerenciados vem o benefício adicional das Ramificações Gerenciadas. Como no GIT, você pode optar por trabalhar em diferentes ramificações do seu projeto (por exemplo, mestre, desenvolvimento e lançamento). Esse processo de ramificação também pode ser automatizado para você, basta selecionar a caixa de verificação ao criar um novo Repositório Gerenciado (tanto para o projeto único quanto para multi-projetos).
Você pode alternar entre as ramificações, selecionando a ramificação desejada enquanto estiver trabalhando no Explorador de Projeto.

Estrutura do Repositório

Caso você não selecione o gerenciamento de ramificações automático, enquanto estiver criando um repositório, você pode criar as ramificações manualmente depois. Com os Repositórios Gerenciados, você pode fazer isto usando o botão Configurar. Esse botão, junto com os botões Promover e Lançar, é fornecido no modo de exibição da Estrutura do Repositório. Você pode acessar esse modo de exibição clicando em RepositórioEstrutura do Repositório no menu de perspectiva do Explorador de Projeto.
A ação de clicar no botão Configurar sempre permite criar ramificações ou editar aquelas criadas automaticamente.
Você pode promover os ativos da ramificação mestra a outras ramificações usando o botão Promover. De forma semelhante, você pode lançar as ramificações e implantá-las no servidor usando o botão Lançar.
Essas duas funções são controladas internamente pelo uso de processos pré-definidos que são implantados na sua instância. Por exemplo, quando você clicar no botão Promover, depois de ter trabalhado na sua ramificação de desenvolvimento, o processo Promover Alterações (Promote Changes) será iniciado em segundo plano. Um usuário, com a função de kiemgmt, terá uma tarefa de usuário aparecendo nessa lista de tarefas para revisar os ativos sendo promovidos. Esse usuário pode declarar essa tarefa e decidir por promover todos, alguns ou nenhum ativo. O processo subjacente irá promover um cherry-pick das confirmações selecionadas pelo usuário para uma ramificação de lançamento. Esse usuário também pode solicitar uma outra revisão desses ativos e esse processo pode ser repetido múltiplas vezes até que todos os ativos estejam prontos para o lançamento. O fluxo desse processo é apresentado abaixo:
De forma semelhante, quando você clicar no botão Lançar, um fluxo do processo de lançamento é iniciado. Esse fluxo de processo cria o projeto e atualiza todos os artefatos do Maven para a próxima versão e implanta o projeto no tempo de execução, caso os detalhes da implantação do tempo de execução sejam fornecidos.

Atenção

As ramificações do projeto a serem lançadas devem começar com a palavra-chave lançar (release)
.

6.5. Repositório do Maven

O Maven é uma ferramenta de gerenciamento de projetos de software que utiliza um modelo de objeto do projeto (POM) para gerenciar:
  • Compilações
  • Documentações
  • Notificações
  • Dependências
  • Lançamentos
  • SCMs
  • Distribuições
O repositório do Maven é usado para manter ou armazenar os artefatos de compilação e as dependências do projeto e possui, geralmente, dois tipos:
  • Local: refere-se a um repositório local onde todas as dependências do projeto são armazenadas e está localizado junto à instalação atual na pasta padrão como "m2". Trata-se de um cache de downloads remotos que também possui os artefatos de compilação temporária, os quais não foram ainda lançados.
  • Remoto: refere-se a qualquer outro tipo de repositório que possa ser acessado por uma variedade de protocolos, tais como file:// or http://. Esses repositórios podem estar em um local remoto, configurados por terceiros, para o download de artefatos, ou em um repositório interno configurado em um arquivo ou servidor HTTP, usado para compartilhar artefatos privados entre as equipes de desenvolvimento para o gerenciamento de lançamentos internos.

6.6. Configurando Implantações em um Repositório Remoto Nexus

Nexus é um gerenciador de repositórios frequentemente usado em organizações para centralizar o armazenamento e o gerenciamento de artefatos de desenvolvimento de software. É possível configurar o seu projeto para que os artefatos produzidos por cada compilação sejam automaticamente implantados em um repositório em um servidor remoto Nexus.
Para configurar o seu projeto para implantar artefatos em um repositório remoto Nexus, adicione um elemento distributionManagement ao arquivo pom.xml do seu projeto, como demonstrado no exemplo de código abaixo.
<distributionManagement>
  <repository>
    <id>deployment</id>
    <name>Internal Releases</name>
    <url>http://your_nexus_host:8081/nexus/content/repositories/releases</url>
  </repository>
  <snapshotRepository>
    <id>deployment</id>
    <name>Internal Releases</name>
    <url>http://your_nexus_host:8081/nexus/content/repositories/snapshots/</url>
  </snapshotRepository>
</distributionManagement>
Substitua os URLs do exemplo pelos URLs reais dos seus repositórios Nexus. O repositório especificado no elemento snapshotRepository é usado quando o qualificador -SNAPSHOT é anexado ao número da versão atual do projeto. Em outras situações, o repositório especificado no elemento repository é usado.
Caso o seu servidor Nexus necessite de autenticação, você também precisará modificar as configurações dos seus projetos Maven para adicionar as suas credenciais no arquivo settings-security.xml, usando uma senha mestra. Por padrão, esse arquivo fica na pasta ~/.m2, a menos que você tenha mudado a sua localização ao alterar as propriedades do sistema kie.maven.settings.custom.
<servers>
  <server>
    <id>deployment</id>
    <username>admin</username>
    <password>admin.123</password>
  </server>
</servers>
Com a implementação desta configuração, clique no botão Compilar e Implantar no Business Central para executar a compilação do Maven e implantar os artefatos de compilação tanto no repositório local quanto em um dos repositórios Nexus especificados no arquivo pom.xml.

6.7. Configuração do Sistema

Para mudar uma propriedade do Business Central no JBoss EAP, como a configuração para SSH, siga as instruções a seguir:

Procedimento 6.4. Alterando as Propriedades do Sistema

  1. Edite o arquivo $JBOSS_HOME/domain/configuration/host.xml
  2. Localize o servidor dos elementos XML que pertencem a main-server-group e adicione as propriedades do sistema. Por exemplo:
    <system-properties>
     <property name="org.uberfire.nio.git.dir" value="..." boot-time="false"/>
     ...
    </system-properties>
    
Segue abaixo uma lista de todas as propriedades do sistema disponíveis:
  • org.uberfire.nio.git.dir: Local do diretório .niogit. Padrão: diretório de trabalho
  • org.uberfire.nio.git.daemon.enabled: Habilita/desabilita GIT daemon. Padrão: verdadeiro
  • org.uberfire.nio.git.daemon.host: Caso GIT daemon seja habilitado, use essa propriedade como o identificador localhost. Padrão: localhost
  • org.uberfire.nio.git.daemon.port: Caso GIT daemon seja habilitado, use essa propriedade como o número da porta. Padrão: 9418
  • org.uberfire.nio.git.ssh.enabled: Habilita/Desabilita SSH daemon. Padrão: verdadeiro
  • org.uberfire.nio.git.ssh.host: Caso SSH daemon seja habilitado, use essa propriedade como o identificador localhost. Padrão: localhost
  • org.uberfire.nio.git.ssh.port: Caso SSH daemon seja habilitado, use essa propriedade como o número da porta. Padrão: 8001
  • org.uberfire.nio.git.ssh.cert.dir: Local do diretório .security onde os certificados locais serão armazenados. Padrão: diretório de trabalho
  • org.uberfire.metadata.index.dir: Local da pasta .index para Lucene. Padrão: diretório de trabalho
  • org.uberfire.cluster.id: Nome do cluster Helix, por exemplo: kie-cluster
  • org.uberfire.cluster.zk: Cadeia de caracteres de conexão ao Zookeeper. Está no formato de host1:port1,host2:port2,host3:port3. Por exemplo: localhost:2188.
  • org.uberfire.cluster.local.id: Id exclusiva do nó do cluster Helix. Observe que ':' é substituído por '_'. Por exemplo: node1_12345.
  • org.uberfire.cluster.vfs.lock: Nome do recurso definido no cluster Helix, por exemplo: kie-vfs
  • org.uberfire.cluster.autostart: Atrasa a clusterização VFS até que o aplicativo seja totalmente iniciado, evitando conflitos quando todos os membros do cluster criam clones locais. Padrão: falso
  • org.uberfire.sys.repo.monitor.disabled: Desabilita o monitor de configuração (por favor, não desabilite, ao menos que tenha certeza do está fazendo). Padrão: falso.
  • org.uberfire.secure.key: Senha secreta usada pela criptografia de senha. Padrão: org.uberfire.admin
  • org.uberfire.secure.alg: Algoritmo criptografado usado pela criptografia de senha. Padrão: PBEWithMD5AndDES
  • org.guvnor.m2repo.dir: Lugar onde a pasta do repositório do Maven será armazenada. Padrão: working-directory/repositories/kie
  • org.kie.example.repositories: Pasta de onde os repositórios de demonstração serão clonados. Os repositórios de demonstração precisam ser obtidos e colocados nessa pasta. Essa propriedade do sistema tem prioridade sobre as propriedades org.kie.demo e org.kie.example. Padrão: não usado.
  • org.kie.demo: Habilita os clones externos de um aplicativo de demonstração do GitHub. Essa propriedade do sistema tem prioridade sobre org.kie.example. Padrão: verdadeiro.
  • org.kie.example: Habilita a estrutura de exemplo composta pelo Repositório, pela Unidade de Organização e pelo Projeto. Padrão: falso.

Capítulo 7. Importação e Exportação de Processos

7.1. Criando uma Definição de Processo

Certifique-se de que você tenha feito o login no JBoss BPM Suite ou de que esteja no JBoss Developer Studio com o repositório conectado.
Para criar um processo, siga as instruções a seguir:
  1. Abra a perspectiva Criação de Projeto (CriaçãoCriação de Projeto).
  2. No Explorador de Projeto (Criação de ProjetoExplorador de Projeto), navegue até o projeto onde você deseja criar a definição do processo (no modo de exibição do Projeto, selecione o respectivo repositório e projeto nas listas suspensas; no modo de exibição do Repositório, navegue até o diretório REPOSITORY/PROJECT/src/main/resources/).

    Nota

    É recomendável criar os seus recursos, incluindo as suas definições de processos, em um pacote de um projeto para permitir a importação dos recursos e de suas referências. Para criar um pacote, siga as instruções a seguir:
    • No modo de exibição do Repositório do Explorador de Projeto, navegue até o diretório REPOSITORY/PROJECT/src/main/resources/.
    • Vá até Novo ItemPacote.
    • Na caixa de diálogo Novo recurso, defina o nome do pacote e verifique o local do pacote no repositório.
  3. A partir do menu de perspectiva, vá até Novo ItemProcessos Empresariais.
  4. Na caixa de diálogo Novos Processos, insira o nome do processo e clique em OK. Aguarde até que o Editor do Processo apareça com o diagrama do processo.

7.2. Importando uma Definição de Processo

Para importar uma definição BPMN2 ou JSON existente, siga as instruções a seguir:
  1. No Explorador de Projeto, selecione um projeto e o respectivo pacote para o qual você deseja importar a definição do processo.
  2. Crie um novo Processo Empresarial para trabalhar indo até Novo ItemProcesso Empresarial.
  3. Na barra de ferramentas do Designer de Processos, clique no ícone Importar na barra de ferramentas do editor e selecione o formato da definição do processo importado. Observe que você deve optar por sobrescrever a definição do processo existente para poder importar.
  4. A partir da janela Importar, localize o arquivo do processo e clique em Importar.
    Import window for Business Process Editor displaying imports from BPMN2.

    Figura 7.1. Importar Janela

Sempre que uma definição de processo é importada, a definição importada existente é sobrescrita. Certifique-se de não sobrescrever uma definição de processo que você editou para não perder nenhuma alteração.
Um processo também pode ser importado para o repositório git no sistema de arquivos clonando o repositório, adicionando os arquivos do processo e enviando as alterações de volta para o git. Além dos métodos de importação alternativos, você pode copiar e colar um processo ou apenas abrir um arquivo na caixa de diálogo de importação.
Durante a importação dos processos, o Designer de Processos fornece um suporte visual para os elementos do processo e exige, assim, informações sobre as posições dos elementos no canvas. Caso as informações não sejam proporcionadas no processo importado, você precisará adicioná-las manualmente.

7.3. Importando jPDL 3.2 para BPMN2

Para migrar e importar uma definição jPDL para BPMN2, no Designer de Processos, clique no botão importar e, depois, selecione Migrar jPDL 3.2 para BPMN2.
Image of selecting the Migrate jPDL 3.2 to BPMN2 button

Figura 7.2. Migrar jPDL 3.2 para BPMN2

Na caixa de diálogo Migrar para BPMN2, selecione o arquivo de definição do processo e o nome do arquivo gpd. Confirme clicando o botão Migrar.
Window displayed for migrating definition files to BPMN2.

Figura 7.3. Caixa de diálogo Migrar para BPMN2

Importante

A ferramenta de migração da definição jPDL 3.2 para BPMN2 é um recurso em visualização técnica e, portanto, não possui suporte no Red Hat JBoss BPM Suite.

7.4. Exportando um Processo

Procedimento 7.1. Exportando um processo empresarial

Para exportar um processo empresarial, siga as instruções a seguir:
  1. Abra a perspectiva Criação de Projetos: no menu principal, clique em CriaçãoCriação de Projeto.
  2. Selecione o processo empresarial a ser exportado para visualizá-lo no Designer de Processos.
  3. Clique no botão ( ) da barra de ferramentas do designer de processos e selecione Exibir as Fontes do Processo a partir das opções suspensas.
  4. A janela Fontes do Processo é exibida.
  5. Clique no botão Baixar BPMN2 e salve o processo empresarial no local desejado.

Parte III. Integração

Capítulo 8. Implantando os Artefatos do Red Hat JBoss BPM Suite no Repositório S-RAMP (SOA Repository Artifact Model and Protocol)

Mesmo que o Red Hat JBoss BPM Suite e o S-RAMP sejam dois produtos independentes, é possível mover os artefatos entre eles. Você pode mover os artefatos do JBoss BPM Suite para o S-RAMP usando o Maven ou através de uma interface de usuário.
Esta seção fornece informações sobre esses dois processos.

8.1. Implantando os Artefatos do Red Hat JBoss BPM Suite no Repositório S-RAMP Usando Maven

Antes de implantar os artefatos do Red Hat JBoss BPM Suite no S-RAMP usando o Maven, você precisará habilitar o S-RAMP Maven Wagon. O Maven Wagon é um recurso chave que suporta o protocolo API REST baseado em S-RAMP Atom. Ao habilitar o S-RAMP Maven Wagon, os usuários serão capazes de acessar os artefatos a partir do repositório S-RAMP, como dependências, em um projeto Maven.
Habilite o S-RAMP Maven Wagon ao editar o arquivo pom.xml, como apresentado abaixo:
<build>
  <extensions>
    <extension>
      <groupId>org.overlord.sramp</groupId>
      <artifactId>s-ramp-wagon</artifactId>
      <version>${s-ramp-wagon.version}</version>
    </extension>
  </extensions>
</build>
Depois que o S-RAMP Maven Wagon é habilitado, você pode implantar os artefatos do JBoss BPM Suite no repositório S-RAMP. Para fazer isto, siga os passos abaixo:
  1. Clone o repositório git onde você salvou o projeto BPM Suite executando o seguinte comando:
    git clone http://localhost:8001/REPOSITORY_NAME
  2. Na linha de comando, mova para a pasta que contém o projeto.
  3. Siga as instruções em Red Hat JBoss Fuse Service Works 6 Development Guide, Volume 3: Governance, na seção Implantando no S-RAMP (Deploying to S-RAM). Use o URL do exemplo abaixo:
    <distributionManagement>
      <repository>
        <id>local-sramp-repo</id>
        <name>S-RAMP Releases Repository</name>
        <url>sramp://S-RAMP_SERVER_URL/s-ramp-server/</url>
      </repository>
      <snapshotRepository>
        <id>local-sramp-repo-snapshots</id>
        <name>S-RAMP Snapshots Repository</name>
        <url>sramp://S-RAMP_SERVER_URL/s-ramp-server/</url>
      </snapshotRepository>
    </distributionManagement>
    Com esses parâmetros de configuração, as implantações do Maven são enviadas diretamente para o repositório S-RAM, usando o API S-RAMP. Observe que os artefatos são adicionados ao repositório S-RAM com um tipo de artefato baseado no tipo Maven do projeto. Você pode substituir esse comportamente ao adicionar um parâmtero de consulta ao repositório URL no arquivo pom.xml. Por exemplo:
    <distributionManagement>
      <repository>
        <id>local-sramp-repo</id>
        <name>S-RAMP Releases Repository</name>
        <url>sramp://S-RAMP_SERVER_URL/s-ramp-server/?artifactType=KieJarArchive</url>
      </repository>
    </distributionManagement>
    
    O exemplo acima faz com que o artefato do Maven seja carregado com um tipo de artefato S-RAMP de KieJarArchive.
  4. Corrija o plug-in do maven no arquivo pom.xml e adicione a ele uma dependência como a seguir, no caso do projeto não conter as tabelas de decisão:
    <plugins>
        <plugin>
          <groupId>org.kie</groupId>
          <artifactId>kie-maven-plugin</artifactId>
          <version>6.0.2-redhat-6</version>
          <extensions>true</extensions>
          <dependencies>
              <dependency>
                  <groupId>org.jbpm</groupId>
                  <artifactId>jbpm-bpmn2</artifactId>
                  <version>6.0.2-redhat-6</version>
              </dependency>
          </dependencies>  
         </plugin>
        </plugins>
    
    Caso o projeto contenha tabelas de decisão, use essa dependência para o kie-maven-plugin:
    <plugins>
        <plugin>
          <groupId>org.kie</groupId>
          <artifactId>kie-maven-plugin</artifactId>
          <version>6.0.2-redhat-6</version>
          <extensions>true</extensions>
          <dependencies>
              <dependency>
                   <groupId>org.drools</groupId>
                   <artifactId>drools-decisiontables</artifactId>
                   <version>6.0.2-redhat-6</version>
               </dependency>
          </dependencies>  
         </plugin>
        </plugins>
    
  5. Execute uma implantação limpa do maven usando o seguinte comando:
    mvn -s sramp-settings.xml deploy
    .

Nota

Para a implantação do Maven no repositório S-RAMP, é necessário ter as credenciais definidas no arquivo settings.xml. Para mais detalhes sobre credenciais, consulte a documentação sobre Autenticação em Red Hat JBoss Fuse Service Works (FSW).

8.2. Implantando os Artefatos do Red Hat JBoss BPM Suite no Repositório S-RAMP Usando a Interface Gráfica do Usuário (GUI)

Para implantar os artefatos do Red Hat JBoss BPM Suite no repositório S-RAMP usando a interface do usuário, siga as instruções a seguir:
  1. Em um navegador da web, navegue até http://localhost:8080/s-ramp-ui/. Se a interface do usuário tiver sido configurada para executar a partir de um nome de domíno, substitua localhost pelo nome de domínio. Por exemplo, http://www.example.com:8080/s-ramp-ui/.
  2. Clique em Artefatos.
  3. Na seção Gerenciar Artefatos, selecione Importar.
  4. Localize o arquivo kie que você queira implantar. Na caixa de diálogo que abrir, preencha KieJarArchive como o tipo e selecione Importar.
  5. A implantação, então, cria estas entradas no repositório S-RAMP:
    KieJarArchive, da qual derivam-se:
    • KieXmlDocument (caso o arquivo contenha kmodule.xml)
    • BpmnDocument (caso o arquivo contenha definições bpmn)
    • DroolsDocument (caso o arquivo contenha definições drl)

Capítulo 9. Integrando o Red Hat JBoss BPM Suite ao Red Hat JBoss Fuse

A integração do Red Hat JBoss Fuse permite que os usuários do JBoss Fuse complementem a sua solução de integração com os recursos adicionais fornecidos pelo JBoss BPM Suite e JBoss BRMS. A integração do Red Hat JBoss BPM Suite é fornecida por dois arquivos features.xml: um fornecendo os recursos principais do JBoss BPM Suite e JBoss BRMS, o qual define os recursos OSGi que podem ser implantados no JBoss Fuse, e o outro fornecendo um suporte adicional à integração ao SwitchYard e Camel.

Nota

Para os usuários do JBoss Fuse 6.1, apenas os recursos principais do JBoss BPM Suite e JBoss BRMS, fornecidos pelo arquivo de recursos a seguir, possuem suporte. Os clientes que estão usando uma versão mais antiga desse arquivo devem atualizá-lo.

Importante

A integração do SwitchYard é uma Visualização Técnica no JBoss Fuse 6.2 e, portanto, não possui suporte atualmente.
Os recursos principais do JBoss BPM Suite e JBoss BRMS são fornecidos pelo drools-karaf-features-6.2.0.Final-redhat-6-BZ1232486-features.xml:
  • drools-common
  • drools-module
  • drools-templates
  • drools-decisiontable
  • drools-jpa
  • kie
  • kie-ci
  • kie-spring
  • kie-aries-blueprint
  • jbpm-commons
  • jbpm-human-task
  • jbpm
  • droolsjbpm-hibernate
  • h2
Esse arquivo de recursos (e repositórios de suporte) é fornecido atualmente como uma correção no Portal do Consumidor Red Hat.
A tabela a seguir fornece exemplos de casos de uso para alguns dos recursos listados acima.

Tabela 9.1. Exemplos de Casos de Uso e Recursos

RecursoCaso de Uso
drools-moduleUsa o mecanismo JBoss BRMS para a avaliação de regras, sem necessidade de persistências, processos ou tabelas de decisão.
drools-jpaUsa o mecanismo JBoss BRMS para a avaliação de regras com persistências e transações mas, sem necessidade de processos ou tabelas de decisão. O recurso drools-jpa já inclui drools-module, no entanto você também pode precisar de instalar o recurso droolsjbpm-hibernate ou verificar se um pacote Hibernate compatível foi instalado.
drools-decisiontableUsa o mecanismo JBoss BRMS com tabelas de decisão.
jbpmUsa o JBoss BPM Suite (ou o mecanismo JBoss BRMS com processos). O recurso jbpm já inclui drools-module e drools-jpa. Você também pode precisar de instalar o recurso droolsjbpm-hibernate ou verificar se um pacote Hibernate compatível foi instalado.
jbpm e jbpm-human-taskUsa o JBoss BPM Suite (ou o mecanismo JBoss BRMS com processos) com Tarefas Humanas.
mecanismos principais jars e kie-ci. Usa o JBoss BRMS ou JBoss BPM Suite com KieScanner (KIE-CI) para baixar kJARs de um repositório do Maven.
kie-springUsa a integração do KIE-Spring.
kie-spring e kie-aries-blueprint.Usa a integração do KIE-Aries-Blueprint.
Os recursos adicionais a seguir para a integração do SwitchYard e Camel ao JBoss Fuse são fornecidos pelo org/jboss/integration/fuse/karaf-features/1.0.0.redhat-620137/karaf-features-1.0.0.redhat-620137-features.xml:
  • fuse-bxms-switchyard-common-knowledge
  • fuse-bxms-switchyard-rules
  • fuse-bxms-switchyard-bpm
  • kie-camel
  • jbpm-workitems-camel
Esse arquivo (e os repositórios de suporte) está localizado em http://repository.jboss.org/nexus/content/repositories/public e já possui uma configuração pronta para uso no JBoss Fuse 6.2 em installDir/etc/org.ops4j.pax.url.mvn.cfg.
O arquivo tembém pode ser baixado a partir do JBoss Fuse 6.2 ou da página do produto JBoss BPM Suite no Portal do Consumidor Red Hat.

9.1. Instale/ Atualize os Recursos Principais de Integração

Caso você já tenha instalado uma versão mais antiga dos recursos principais do JBoss BPM Suite e JBoss BRMS (por exemplo, drools-karaf-features-6.2.0.Final-redhat-6-features.xml), você precisará removê-los assim como todos os seus arquivos associados antes de instalar o arquivo mais recente features.xml.

Procedimento 9.1. Removendo uma Instalação drools-karaf-features Existente

  1. Inicie o console Fuse usando:
    $ ./installDir/bin/fuse
  2. Desinstale recursos/ aplicativos antigos que usavam o arquivo features.xml anterior. Por exemplo:
    JBossFuse:karaf@root> features:uninstall drools-module
    JBossFuse:karaf@root> features:uninstall jbpm
    JBossFuse:karaf@root> features:uninstall kie-ci
    
  3. Pesquise por referências de pacotes usando drools/kie/jbpm e remova-as:
    list -t 0 -s | grep drools
    list -t 0 -s | grep kie
    list -t 0 -s | grep jbpm
    Para remover os pacotes:
    karaf@root> osgi:uninstall <BUNDLE_ID>
  4. Remova o url drools-karaf-features antigo:
    karaf@root> features:removeurl mvn:org.drools/drools-karaf-features/6.2.0.Final-redhat-<VERSION>/xml/features
  5. Reinicie Fuse
  6. Adicione o novo arquivo de recursos:
    karaf@root> features:addurl mvn:org.drools/drools-karaf-features/6.2.0.Final-redhat-6-BZ1232486/xml/features
  7. Instale os recursos:
    karaf@root> features:install ...
Para instalar drools-karaf-features:

Procedimento 9.2. Instale os recursos principais do JBoss BPM Suite e JBoss BRMS

  1. Baixe e instale a correção.
    1. Baixe jboss-brms-6.1.1-BZ-1232486.zip.
    2. Descompacte-o.
    3. Navegue até o diretório BZ-1232486 descompactado.
    4. Execute o seguinte comando de console:
      $ mvn org.apache.maven.plugins:maven-install-plugin:2.5.2:install-file -Dfile=drools-karaf-features-6.2.0.Final-redhat-6-BZ1232486-features.xml -DgroupId=org.drools -DartifactId=drools-karaf-features -Dversion=6.2.0.Final-redhat-6-BZ1232486 -Dpackaging=xml -Dclassifier=features
  2. Configure os repositórios necessários:
    1. Edite o arquivo installDir/etc/org.ops4j.pax.url.mvn.cfg na sua instalação do JBoss Fuse e adicione a seguinte entrada à variável org.ops4j.pax.url.mvn.repositories, observe que as entradas são separadas por ‘, \’:
      • http://maven.repository.redhat.com/techpreview/all/@id=bxms-product-repo
  3. Inicie o JBoss Fuse:
    $ ./installDir/bin/fuse
  4. Adicione uma referência ao arquivo dos recursos principais executando o seguinte comando de console:
    JBossFuse:karaf@root> features:addurl mvn:org.drools/drools-karaf-features/6.2.0.Final-redhat-6-BZ1232486/xml/features
  5. Você pode instalar, agora, os recursos fornecidos por este arquivo executando, por exemplo, o seguinte comando de console:
    JBossFuse:karaf@root> features:install drools-module

9.2. Instale os Recursos Adicionais de Integração

Use o procedimento a seguir para uma integração adicional com SwitchYard e Camel.

Importante

A integração do SwitchYard é uma Visualização Técnica no JBoss Fuse 6.2 e, portanto, não possui suporte atualmente.

Procedimento 9.3. Integração do SwitchYard e Camel

  1. Adicione uma referência ao arquivo dos recursos para uma integração adicional com o SwitchYard e Camel executando o seguinte comando de console:
    JBossFuse:karaf@root> features:addurl mvn:org.jboss.integration.fuse/karaf-features/1.0.0.redhat-620137/xml/features
  2. Você pode instalar, agora, os recursos fornecidos pela integração do SwitchYard e Camel executando, por exemplo, o seguinte comando de console:
    JBossFuse:karaf@root> features:install fuse-bxms-switchyard-rules

9.3. Instale os Aplicativos de Início Rápido de Integração do JBoss Fuse

Os recursos a seguir para os aplicativos de início rápido de integração do JBoss Fuse são fornecidos pelo org/jboss/integration/fuse/quickstarts/karaf-features/1.0.0.redhat-620137/karaf-features-1.0.0.redhat-620137-features.xml:
  • fuse-bxms-switchyard-quickstart-bpm-service
  • fuse-bxms-switchyard-quickstart-remote-invoker
  • fuse-bxms-switchyard-quickstart-rules-camel-cbr
  • fuse-bxms-switchyard-quickstart-rules-interview
  • fuse-bxms-switchyard-quickstart-rules-interview-container
  • fuse-bxms-switchyard-quickstart-rules-interview-dtable
  • fuse-bxms-switchyard-demo-library
  • fuse-bxms-switchyard-demo-helpdesk
Esse arquivo (e os repositórios de suporte) está localizado em http://repository.jboss.org/nexus/content/repositories/public e já possui uma configuração pronta para uso no JBoss Fuse 6.2 em installDir/etc/org.ops4j.pax.url.mvn.cfg.

Procedimento 9.4. Instalando o Aplicativo de Início Rápido

  1. Adicione uma referência ao arquivo dos recursos executando o seguinte comando de console:
    JBossFuse:karaf@root> features:addurl mvn:org.jboss.integration.fuse.quickstarts/karaf-features/1.0.0.redhat-620137/xml/features
  2. Você pode instalar, agora, os aplicativos de início rápido fornecidos por este arquivo de recursos executando, por exemplo, o seguinte comando de console:
    JBossFuse:karaf@root> features:install fuse-bxms-switchyard-quickstart-bpm-service
Você também pode baixar um arquivo ZIP a partir da página de conhecimento do produto: https://repository.jboss.org/nexus/content/repositories/public/org/jboss/integration/fuse/fuse-integration-karaf-distro/1.0.0.redhat-620137/ . Esse arquivo fornece o código fonte para cada aplicativo de início rápido, assim como o código para teste.

Procedimento 9.5. Baixando e Instalando os Arquivos ZIP de Início Rápido

  1. Baixe o arquivo ZIP do aplicativo de início rápido.
  2. Desempacote os conteúdos do diretório de início rápido no seu diretório existente installDir/quickstarts.
  3. Desempacote os conteúdos do diretório do sistema no seu diretório existente installDir/system.

9.3.1. Testando o seu Primeiro Aplicativo de Início Rápido

Procedimento 9.6. Testando o Aplicativo de Início Rápido

  1. Inicie o JBoss Fuse:
    $ ./installDir/bin/fuse
  2. Instale e inicie switchyard-bpm-service executando o seguinte comando de console:
    JBossFuse:karaf@root> features:install fuse-bxms-switchyard-quickstart-bpm-service

    Nota

    Todos os recursos dependentes especificados pelo arquivo de recursos do aplicativo serão instalados automaticamente.
  3. Envie uma solicitação de serviço web para invocar o gateway SOAP.
    1. Abra uma janela do terminal e navegue até o diretório de início rápido associado que foi desempacotado do arquivo ZIP do aplicativo de início rápido (nesse caso, switchyard-bpm-service).
    2. Execute o seguinte comando:
      $ mvn clean install

      Nota

      Você precisará dos seguintes repositórios configurados no seu arquivo settings.xml:
      • http://maven.repository.redhat.com/techpreview/all/
      • http://repository.jboss.org/nexus/content/repositories/public/
    3. Execute o seguinte comando:
      $ mvn exec:java -Pkaraf
  4. Você receberá a seguinte resposta:
    SOAP Reply:
    <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><SOAP-ENV:Header xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"/><soap:Body><ns2:submitOrderResponse xmlns:ns2="urn:switchyard-quickstart:bpm-service:1.0">
        <orderId>test1</orderId>
        <accepted>true</accepted>
        <status>Thanks for your order, it has been shipped!</status>
    </ns2:submitOrderResponse></soap:Body></soap:Envelope>

Capítulo 10. Integrando ao Spring

10.1. Configurando o Red Hat JBoss BPM Suite com Spring

Consulte o Guia de Instalação do Red Hat JBoss BPM Suite para baixar o módulo Spring. Você precisará baixar a versão genérica implantável do JBoss BPM Suite.
O módulo Spring está presente no arquivo jboss-bpms-engine.zip e é chamado de kie-spring-VERSION-redhat-MINORVERSION.jar.
A maneira como você pretende usar os módulos Spring no seu aplicativo afeta a forma como você deve configurá-los.

Como um Mecanismo de Processos Autogerenciados

Essa é a maneira padrão para começar a usar o JBoss BPM Suite no seu aplicativo Spring. Você o configura apenas uma vez e o executa como parte do aplicativo. Ao usar a API RuntimeManager, uma sincronização perfeita entre o mecanismo de processos e o serviço de tarefas é gerenciada internamente e o usuário final não precisa lidar com o código interno para fazer os dois funcionarem juntos.

Como um Serviço de Tarefas Compartilhado

Quando você usa uma única instância de um TaskService, você obtém mais flexibilidade na configuração da instância do serviço de tarefas, já que é independente do RuntimeManager. Depois de configurado, ele é, então, usado pelo RuntimeManager quando solicitado.
Para criar um RuntimeEnvironment a partir do seu aplicativo Spring, você pode usar a classe org.kie.spring.factorybeans.RuntimeEnvironmentFactoryBean. Essa classe de fábrica é responsável pela produção de instâncias do RuntimeEnvironment que são consumidas pelo RuntimeManager mediante criação. Segue abaixo um RuntimeEnvironment configurado com o gerenciador de entidade, gerenciador de transação e recursos para a classe org.kie.spring.factorybeans.RuntimeEnvironmentFactoryBean:
<bean id="runtimeEnvironment" class="org.kie.spring.factorybeans.RuntimeEnvironmentFactoryBean">
  <property name="type" value="DEFAULT"/>
  <property name="entityManagerFactory" ref="jbpmEMF"/>
  <property name="transactionManager" ref="jbpmTxManager"/>
  <property name="assets">
    <map>
      <entry key-ref="process"><util:constant static-field="org.kie.api.io.ResourceType.BPMN2"/></entry>
    </map>
  </property>
</bean>
O RuntimeEnvironment a seguir pode ser criado ou configurado:
  • DEFAULT - configuração padrão (mais comum) para o RuntimeManager
  • EMPTY - ambiente completamente vazio para ser populado manualmente
  • DEFAULT_IN_MEMORY - o mesmo que DEFAULT, mas sem persistências do mecanismo de tempo de execução
  • DEFAULT_KJAR - o mesmo que DEFAULT, mas os ativos de conhecimento são tomados do KJAR identificado por releaseid ou GAV
  • DEFAULT_KJAR_CL - construído diretamente a partir do caminho de classe que consiste no descritor kmodule.xml
Dependendo do tipo selecionado, diferentes propriedades mandatórias serão solicitadas. No entanto, pelo menos uma das propriedades de conhecimento a seguir deve ser fornecida:
  • knowledgeBase
  • assets
  • releaseId
  • groupId, artifactId, version
Por fim, para os tipos DEFAULT, DEFAULT_KJAR, DEFAULT_KJAR_CL, a persistência precisa ser configurada na forma de valores para entity manager factory e transaction manager. Segue abaixo um exemplo de RuntimeManager para org.kie.spring.factorybeans.RuntimeManagerFactoryBean:
<bean id="runtimeManager" class="org.kie.spring.factorybeans.RuntimeManagerFactoryBean" destroy-method="close">
  <property name="identifier" value="spring-rm"/>
  <property name="runtimeEnvironment" ref="runtimeEnvironment"/>
</bean>

Capítulo 11. Integração CDI

11.1. Integração CDI

Para utilizar jbpm-kie-services no seu sistema, você precisará fornecer alguns mbeans para satisfazer todas as dependências dos serviços. Existem vários mbeans que dependem dos cenários vigentes.
  • gerenciador de entidades e fábrica de gerenciador de entidades
  • retorno de chamadas de grupos de usuários para tarefas humanas
  • provedor de identidade para passar informações sobre o usuário para os serviços
Durante a execução em um ambiente JEE, como o JBoss Application Server, o mbeam deve satisfazer todos os requisitos de jbpm-kie-services
public class EnvironmentProducer { 

    @PersistenceUnit(unitName = "org.jbpm.domain")
    private EntityManagerFactory emf;

    @Inject
    @Selectable
    private UserGroupCallback userGroupCallback;

    @Produces
    public EntityManagerFactory getEntityManagerFactory() {
        return this.emf;
    }

    @Produces
    @RequestScoped
    public EntityManager getEntityManager() {
        EntityManager em = emf.createEntityManager();
        return em;
    }

    public void close(@Disposes EntityManager em) {
        em.close();
    }

    @Produces
    public UserGroupCallback produceSelectedUserGroupCalback() {
        return userGroupCallback;
    }
    @Produces

    public IdentityProvider produceIdentityProvider {
        return new IdentityProvider() {
             // implement IdentityProvider
        };
    }
}
Depois, o arquivo deployments/business-central.war/WEB-INF/beans.xml pode ser configurado para alterar os parâmetros de configuração atuais da nova implementação usergroupcallback.
<beans xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://docs.jboss.org/cdi/beans_1_0.xsd">

<alternatives>
  <class>org.jbpm.services.task.identity.JAASUserGroupCallbackImpl</class>
</alternatives>

</beans>

Nota

org.jbpm.services.task.identity.JAASUserGroupCallbackImpl é apenas um exemplo dado aqui para demonstrar as configurações do servidor do aplicativo, independente do que ele seja na verdade (LDAP, DB, etc).

Capítulo 12. Persistência

Os dados do tempo de execução do Mecanismo de Processo podem persistir nos armazenamentos de dados. O mecanismo de persistência salva os dados usando marshalling: os dados do tempo de execução são convertidos em um conjunto de dados binário e o conjunto de dados é salvo no repositório de dados.
Observe que a persistência não é configurada por padrão e o mecanismo é executado sem persistência.

Nota

Os dados do tempo de execução são salvos usando marshalling (persistência binária). O mecanismo marshalling é um mecanismo de serialização personalizado.
O Red Hat JBoss BPM Suite persistirá o seguinte, quando a persistência é configurada:
  • Estado da sessão: inclui a id da sessão, a data da última modificação, os dados da sessão que as regras empresariais precisariam para avaliação, o estado dos trabalhos do temporizador.
  • Estado da instância do processo: inclui a id da instância do processo, a id do processo, a data da última modificação, a data do último acesso de leitura, a data de início da instância do processo, os dados do tempo de execução (o status da execução, incluindo o nó sendo executado, os valores da variável e etc.) e os tipos de eventos.
  • Estado do tempo de execução do item de trabalho: inclui a id do item de trabalho, a data de criação, o nome, a id da instância do processo e o estado do item de trabalho propriamente dito.
Baseado nos dados persistentes, é possível restaurar o estado de execução de todas as instâncias dos processos em execução no caso de falha ou de remoção temporária das instâncias em execução da memória e, depois, restaurá-las. Por padrão, nenhuma persistência é configurada.
Para permitir a persistência, você precisa adicionar os arquivos jar jbpm-persistence ao caminho de classe do seu aplicativo e configurar o mecanismo para usar a persistência. O mecanismo armazena automaticamente o estado do tempo de execução no armazenamento quando o mecanismo atinge um momento seguro. Momentos seguros são momentos quando a instância do processo está em pausa. Quando uma invocação da instância do processo atinge um momento seguro no mecanismo, o mecanismo armazena qualquer alteração na instância do processo como um snapshot dos dados do tempo de execução do processo. No entanto, quando uma instância do processo é concluída, o snapshot persistente dos dados do tempo de execução da instância do processo é deletado automaticamente.
Caso ocorra uma falha e você precise restaurar o tempo de execução do mecanismo a partir do armazenamento, as instâncias dos processos são restauradas automaticamente e as suas execuções são retomadas, não havendo a necessidade de recarregar e disparar as instâncias dos processos manualmente.
Os dados de persistência do tempo de execução devem ser considerados internos ao mecanismo. Você não deve acessar os dados do tempo de execução persistentes ou modificá-los diretamente, já que isso pode causar efeitos colaterais.
Para obter mais informações sobre o estado da execução atual, refira-se ao log do histórico. Consulte o banco de dados para os dados do tempo de execução apenas se for absolutamente necessário.

12.1. Sessão

As sessões são persistentes como entidades SessionInfo. Elas persistem o estado da sessão KIE do tempo de execução e armazenam os seguintes dados:

Tabela 12.1.

CampoDescriçãoAnulável
id
chave primária
falso
lastmodificationdate
última vez salvo no armazenamento de dados
N/A
rulesbytearray
conjunto de dados binário com estado de sessão (blob binário)
falso
startdate
início da sessão
optlock
número da versão usado para bloquear o valor para o bloqueio otimista.

12.2. Instâncias do Processo

As instâncias do processo são persistentes como entidades ProcessInstanceInfo, que persistem o estado de uma instância do processo em tempo de execução e armazenam os seguintes dados:

Tabela 12.2.

CampoDescriçãoAnulável
instanceid
chave primária
falso
lastmodificationdate
última vez salvo no armazenamento de dados
N/A
lastreaddate
última leitura do armazenamento de dados
N/A
processid
Id do processo em que a instância se baseia
falso
processinstancebytearray
conjunto de dados binário com o estado de instância do processo (blob binário)
falso
startdate
data de início da instância do processo
optlock
número da versão usado para bloquear o valor para o bloqueio otimista.
state
estado da instância do processo
falso
ProcessInstanceInfo possui uma relação 1:N com a entidade EventTypes.
A entidade EventTypes contém os seguintes dados:

Tabela 12.3.

CampoDescriçãoAnulável
instanceid
referência à Instância do Processo (chave estrangeira para processinstanceinfo)
falso
element
campo de texto relacionado a um evento ao qual a Instância do processo foi submetida

Suporte de Bloqueio Pessimista

O mecanismo padrão de bloqueio para a persistência dos processos é otimista. Mas, com uma simultaneidade alta e multi-thread na mesma instância do processo, essa estratégia de bloqueio pode gerar um mau desempenho.
Com o lançamento da versão 6.1 do Red Hat JBoss BPM Suite, isso pode ser alterado durante o tempo de execução, permitindo que o usuário defina o bloqueio de acordo com o processo e permitindo, assim, que ele seja pessimista (essa alteração pode ser feita ao nível da Sessão Kie ou ao nível do Gerenciador do Tempo de Execução também e não apenas ao nível do processo).
Para configurar um processo para usar o bloqueio pessimista, utilize o ambiente de tempo de execução:
import org.kie.api.runtime.Environment;
import org.kie.api.runtime.EnvironmentName;
import org.kie.api.runtime.manager.RuntimeManager;
import org.kie.api.runtime.manager.RuntimeManagerFactory;

...

// here env is an instance of org.kie.api.runtime.Environment
env.set(EnvironmentName.USE_PESSIMISTIC_LOCKING, true);

// now create your Runtime Manager using this enviornment
RuntimeManager manager = RuntimeManagerFactory.Factory.get().newPerRequestRuntimeManager(environment);

12.3. Itens de Trabalho

Os Itens de Trabalho são persistentes como entidades workiteminfo, as quais persistem o estado da instância do item de trabalho em particular durante o tempo de execução e armazenam os seguintes dados:

Tabela 12.4.

CampoDescriçãoAnulável
workitemid
chave primária
falso
name
nome do item de trabalho
processinstanceid
id da instância do processo pai
falso
state
número inteiro representando o estado do item de trabalho
falso
optlock
número da versão usado para bloquear o valor para o bloqueio otimista.
workitembytearray
conjunto de dados binário com o estado do item de trabalho (blob binário )
falso
creationDate
carimbo de data/hora de criação do item de trabalho
falso

12.4. Configuração da Persistência

12.4.1. Configuração da Persistência

Embora a persistência não seja usada por padrão, as dependências necessárias estão disponíveis no diretório do tempo de execução como arquivos jar .
A persistência é definida por sessão e pode ser definida usando a classe JBPMHelper, depois que você criar uma sessão, ou usando JPAKnowledgeService, para a criação da sua sessão. A última opção proporciona mais flexibilidade, enquanto JBPMHelper possui um método próprio para criar uma sessão e utiliza um arquivo de configuração para configurar essa sessão.

12.4.2. Configurando a Persistência Usando JBPMHelper

Para configurar a persistência da sua sessão usando JBPMHelper, siga as instruções a seguir:
  1. Defina o seu aplicativo para usar um construtor de sessão JBPMHelper adequado:
    • KieSession ksession = JBPMHelper.newKieSession(kbase);
    • KieSession ksession = JBPMHelper.loadKieSession(kbase, sessionId);
  2. Configure a persistência no arquivo jBPM.properties .

    Exemplo 12.1. Arquivo jBPM.properties de exemplo com persistência para o banco de dados H2 em memória

    # for creating a datasource
    persistence.datasource.name=jdbc/jbpm-ds
    persistence.datasource.user=sa
    persistence.datasource.password=
    persistence.datasource.url=jdbc:h2:tcp://localhost/~/jbpm-db
    persistence.datasource.driverClassName=org.h2.Driver
    
    # for configuring persistence of the session
    persistence.enabled=true
    persistence.persistenceunit.name=org.jbpm.persistence.jpa
    persistence.persistenceunit.dialect=org.hibernate.dialect.H2Dialect
    
    # for configuring the human task service
    taskservice.enabled=true
    taskservice.datasource.name=org.jbpm.task
    taskservice.transport=mina
    taskservice.usergroupcallback=org.jbpm.task.service.DefaultUserGroupCallbackImpl
Qualquer invocação na sessão disparará agora o processo de persistência.
Certifique-se de que a fonte de dados esteja ativa e em execução mediante o início do mecanismo. Caso esteja executando o banco de dados H2 em memória, você pode iniciar o banco de dados a partir do seu aplicativo usando a chamada de método JBPMHelper.startH2Server(); e registrá-lo com o mecanismo usando a chamada de método JBPMHelper.setupDataSource();.

12.4.3. Configurando a Persistência Usando JPAKnowledgeService

Para criar a sua sessão de conhecimento e configurar a sua persistência usando JPAKnowledgeService, siga as instruções a seguir:
  1. Defina o seu aplicativo para usar a sessão de conhecimento criada pelo JPAKnowledgeService:
    • Defina a sessão baseada em um banco de dados de conhecimento, uma configuração da sessão de conhecimento e um ambiente. O ambiente deve conter uma referência à sua Fábrica de Gerenciador de Entidades:
      // create the entity manager factory and register it in the environment
      EntityManagerFactory emf = Persistence.createEntityManagerFactory( "org.jbpm.persistence.jpa" );
      Environment env = KnowledgeBaseFactory.newEnvironment();
      env.set( EnvironmentName.ENTITY_MANAGER_FACTORY, emf );
      
      // create a new knowledge session that uses JPA to store the runtime state
      KieSession ksession = JPAKnowledgeService.newKieSession( kbase, null, env );
      int sessionId = ksession.getId();
      
      // invoke methods on your method here
      ksession.startProcess( "MyProcess" );
      ksession.dispose();
    • Defina a sessão baseada em uma id de sessão específica.
      // recreate the session from database using the sessionId
      ksession = JPAKnowledgeService.loadKieSession(sessionId, kbase, null, env );
  2. Configure a persistência no arquivo META-INF/persistence.xml : configure JPA para usar o Hibernate e o banco de dados respectivo.
    As informações sobre como configurar a fonte de dados no servidor do seu aplicativo devem estar disponíveis na documentação enviada com o servidor do aplicativo. Para esse tipo de informação para o JBoss Enterprise Application Platform, consulte o guia Administration and Configuration Guide deste produto.

    Exemplo 12.2. Arquivo persistence.xml de exemplo com persistência para uma fonte de dados H2 jdbc/jbpm-ds

    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
    <persistence
      version="1.0"
      xsi:schemaLocation=
        "http://java.sun.com/xml/ns/persistence
         http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd
         http://java.sun.com/xml/ns/persistence/orm
         http://java.sun.com/xml/ns/persistence/orm_1_0.xsd"
      xmlns:orm="http://java.sun.com/xml/ns/persistence/orm"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xmlns="http://java.sun.com/xml/ns/persistence">
      <persistence-unit name="org.jbpm.persistence.jpa" transaction-type="JTA">
        <provider>org.hibernate.ejb.HibernatePersistence</provider>
        <jta-data-source>jdbc/jbpm-ds</jta-data-source>
        <mapping-file>META-INF/JBPMorm.xml</mapping-file>
        <class>org.drools.persistence.info.SessionInfo</class>
        <class>org.jbpm.persistence.processinstance.ProcessInstanceInfo</class>
        <class>org.drools.persistence.info.WorkItemInfo</class>
        <properties>
          <property name="hibernate.dialect" value="org.hibernate.dialect.H2Dialect"/>
          <property name="hibernate.max_fetch_depth" value="3"/>
          <property name="hibernate.hbm2ddl.auto" value="update"/>
          <property name="hibernate.show_sql" value="true"/>
          <property name="hibernate.transaction.manager_lookup_class"
                    value="org.hibernate.transaction.BTMTransactionManagerLookup"/>
        </properties>
      </persistence-unit>
    </persistence>
Qualquer invocação na sessão disparará agora o processo de persistência.
Certifique-se de que a fonte de dados esteja ativa e em execução mediante o início do mecanismo. Caso esteja executando o banco de dados H2 em memória, você pode iniciar o banco de dados a partir do seu aplicativo usando a chamada de método JBPMHelper.startH2Server(); e registrá-lo com o mecanismo usando a chamada de método JBPMHelper.setupDataSource();.

Nota

Caso esteja executando o JBoss BPM Suite em um ambiente Java simples, a configuração da fonte de dados será semelhante ao seguinte:
PoolingDataSource ds = new PoolingDataSource();
ds.setUniqueName("jdbc/jbpm-ds");
ds.setClassName("bitronix.tm.resource.jdbc.lrc.LrcXADataSource");
ds.setMaxPoolSize(3);
ds.setAllowLocalTransactions(true);
ds.getDriverProperties().put("user", "sa");
ds.getDriverProperties().put("password", "sasa");
ds.getDriverProperties().put("URL", "jdbc:h2:tcp://localhost/~/jbpm-db");
ds.getDriverProperties().put("driverClassName", "org.h2.Driver");
ds.init();

Capítulo 13. Transações

13.1. Transações

O Mecanismo de Processo oferece suporte às transações JTA: as transações locais possuem suporte somente quando usam Spring. As transações locais puras não possuem suporte.
Por padrão, cada invocação de método é considerada uma transação. Para alterar esse comportamento, por exemplo, para agrupar comandos múltiplos em uma transação, você precisará especificar os limites da transação.

13.2. Definindo as Transações

Para definir uma transação, siga as instruções a seguir:
  1. Registre um gerenciador de transação no seu ambiente.

    Exemplo 13.1. Codifique com o registro do gerenciador de transação

    // create the entity manager factory
    EntityManagerFactory emf = EntityManagerFactoryManager.get().getOrCreate("org.jbpm.persistence.jpa");
    TransactionManager tm = TransactionManagerServices.getTransactionManager();
    Environment env = EnvironmentFactory.newEnvironment();
    env.set(EnvironmentName.ENTITY_MANAGER_FACTORY, emf);
    env.set(EnvironmentName.TRANSACTION_MANAGER, tm);
    	
    // setup the runtime environment
    RuntimeEnvironment environment = RuntimeEnvironmentBuilder.Factory.get()
    .newDefaultBuilder()
    .addAsset(ResourceFactory.newClassPathResource("MyProcessDefinition.bpmn2"), ResourceType.BPMN2)
        .addEnvironmentEntry(EnvironmentName.TRANSACTION_MANAGER, tm)
        .addEnvironmentEntry(EnvironmentName.PERSISTENCE_CONTEXT_MANAGER, new JpaProcessPersistenceContextManager(env))
        .addEnvironmentEntry(EnvironmentName.TASK_PERSISTENCE_CONTEXT_MANAGER, new JPATaskPersistenceContextManager(env))
        .get();
  2. Inicialize a KieSession:
    // get the KieSession
    RuntimeManager manager = RuntimeManagerFactory.Factory.get().newPerProcessInstanceRuntimeManager(environment);
    RuntimeEngine runtime = manager.getRuntimeEngine(ProcessInstanceIdContext.get());
    KieSession ksession = runtime.getKieSession();
  3. Defina o gerenciador de transação em jndi.properties.

    Exemplo 13.2. Definição do gerenciador de transação Bitronix em jndi.properties

    java.naming.factory.initial=bitronix.tm.jndi.BitronixInitialContextFactory

    Nota

    Para usar um gerenciador de transação JTA, edite hibernate.transaction.manager_lookup_class, a propriedade do gerenciador de transação, no arquivo persistence.xml para carregar o seu gerenciador de transação.

    Exemplo 13.3. Gerenciador de Transação JBoss definido como gerenciador de transações

    <property name="hibernate.transaction.manager_lookup_class" value="org.hibernate.transaction.JBossTransactionManagerLookup"/>
  4. Defina o início e o fim da transação.
     // start the transaction
    UserTransaction ut = InitialContext.doLookup("java:comp/UserTransaction");
    ut.begin();
    
    // perform multiple commands inside one transaction
    ksession.insert( new Person( "John Doe" ) );
    ksession.startProcess("MyProcess");
    
    // commit the transaction
    ut.commit();

13.3. Transações Gerenciadas por Contêiner

Nos casos em que o JBoss BPM Suite estiver inserido em um aplicativo que está em um contêiner que pode gerenciar as transações por si próprio (Transações Gerenciadas por Contêiner - CMT), um gerenciador de transação especial é fornecido usando a classe org.jbpm.persistence.jta.ContainerManagerTransactionManager. Isto é devido à implementação padrão do gerenciador de transação no JBoss BPM Suite ser baseada na classe UserTransaction que obtém o status de transação. No entanto, alguns servidores do aplicativo no modo CMT não permitem o acesso à instância UserTransaction a partir do JNDI.
As operações executadas nesse gerenciador são todas inoperantes, pois elas não podem afetar a CMT subjacente. A classe ContainerManagedTransactionManager espera que a transação esteja sempre ativa (retornando ACTIVE para o método getStatus()).

Nota

Apesar do contêiner gerenciar as transações, ele deve estar ciente de todas as exceções que ocorrem durante a execução da instância do processo. As exceções lançadas pelo mecanismo devem ser propagadas até o contêiner para que as transações sejam revertidas adequadamente.

Configurando o Gerenciador de Transação

Para configurar e usar ContainerManagedTransactionManager, é preciso que ele seja inserido no ambiente antes que você crie ou carregue uma sessão:
    Environment env = EnvironmentFactory.newEnvironment();
    env.set(EnvironmentName.ENTITY_MANAGER_FACTORY, emf);
    env.set(EnvironmentName.TRANSACTION_MANAGER, new ContainerManagedTransactionManager());
    env.set(EnvironmentName.PERSISTENCE_CONTEXT_MANAGER, new JpaProcessPersistenceContextManager(env));
Depois, configure o Provedor JPA no seu arquivo persistence.xml. Por exemplo, se estiver usando IBM WebSphere:
<property name="hibernate.transaction.factory_class" value="org.hibernate.transaction.CMTTransactionFactory"/>
<property name="hibernate.transaction.manager_lookup_class" value="org.hibernate.transaction.WebSphereExtendedJTATransactionLookup"/>

Descartando a KSession em uma CMT

Você não deve descartar a ksession diretamente em uma CMT (usando o método dispose()). Essa ação causa exceções na conclusão da transação, já que o Mecanismo de Processo precisa limpar o estado depois que a invocação tiver terminado.
Ao invés disto, utilize o método execute() da classe especializada org.jbpm.persistence.jta.ContainerManagedTransactionDisposeCommand. O uso desse comando garante que a ksession seja descartada quando a transação estiver, de fato, concluída.
Esse método verifica se a transação está ativa. Se sim, ele delega o descarte à fase afterDisposal da transação, ao invés de executá-lo diretamente. Caso não haja nenhuma transação ativa, a ksession é descartada imediatamente.

Capítulo 14. Registro em Log

O mecanismo de registro em log permite que você armazene informações sobre a execução de uma instância de processo. Ele é fornecido por um ouvinte de eventos especial que ouve o Mecanismo de Processos para qualquer evento relevante a ser registrado em log. Assim, as informações podem ser armazenadas separadamente de outras informações sem log armazenadas no banco de dados interno do servidor (h2) ou em uma fonte de dados conectada usando JPA ou Hibernate.
O módulo jbpm-audit fornece o ouvinte de eventos e também permite que você armazene diretamente informações relacionadas ao processo em um banco de dados usando JPA ou Hibernate. Os dados das entidades abaixo são armazenados, como a seguir:
  • Instância de processo, como processinstancelog
  • Instância de elemento, como nodeinstancelog
  • Instância de variável, como variableinstancelog

Tabela 14.1. Campos da Tabela ProcessInstanceLog

CampoDescriçãoAnulável
id
Chave primária da entidade de log
Não
end_date
Data de término da instância do processo
Sim
processid
Nome (id) do processo subjacente
Sim
processinstanceid
Id da instância do processo
Não
start_date
Data de início da instância do processo
Sim
status
Status da instância do processo
Sim
parentProcessInstanceId
Id da instância do processo da instância do processo pai, caso aplicável
Sim
outcome
Resultado da instância do processo (detalhes sobre a conclusão do processo, como código de erro)
Sim

Tabela 14.2. Campos da Tabela NodeInstanceLog

CampoDescriçãoAnulável
id
Chave primária da entidade de log
Não
log_date
Data do evento
Sim
nodeid
Id do nó do elemento de processo subjacente
Sim
nodeinstanceid
Id da instância do nó
Sim
nodename
Nome do nó subjacente
Sim
processid
Id do processo subjacente
Sim
processinstanceid
Id da instância do processo pai
Não
type
Tipo de evento (0 = evento de entrada, 1 = evento de saída)
Não

Tabela 14.3. Campos da Tabela VariableInstanceLog

CampoDescriçãoAnulável
id
Chave primária da entidade de log
Não
log_date
Data do evento
Sim
processid
Nome (id) do processo subjacente
Sim
processinstanceid
Id da instância do processo
Não
value
Valor da variável na hora do log
Sim
variableid
Id da variável estabelecida na definição do processo
Sim
variableinstanceid
Id da instância da variável
Sim
outcome
Resultado da instância do processo (detalhes sobre a conclusão do processo, como código de erro)
Sim
Se necessário, defina seu próprio modelo de dados das informações personalizadas e use os ouvintes de eventos do processo para extrair as informações.

14.1. Registrando Eventos no Log do Banco de Dados

Para registrar um evento que ocorre durante o tempo de execução em uma instância de processo, uma instância de elemento ou uma instância de variável, siga as instruções a seguir:
  1. Mapeie as classes de log na fonte de dados para que a fonte de dados fornecida aceite as entradas de log. No Red Hat JBoss EAP, edite as propriedades da fonte de dados no arquivo persistence.xml.

    Exemplo 14.1. Classes ProcessInstanceLog, NodeInstanceLog e VariableInstanceLog habilitadas por processInstanceDS

    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
    <persistence  version="1.0"  xsi:schemaLocation=
        "http://java.sun.com/xml/ns/persistence
         http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd
         http://java.sun.com/xml/ns/persistence/orm
         http://java.sun.com/xml/ns/persistence/orm_1_0.xsd"
      xmlns:orm="http://java.sun.com/xml/ns/persistence/orm"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xmlns="http://java.sun.com/xml/ns/persistence">
    
      <persistence-unit name="org.jbpm.persistence.jpa">
        <provider>org.hibernate.ejb.HibernatePersistence</provider>
        <jta-data-source>jdbc/processInstanceDS</jta-data-source>
        <class>org.drools.persistence.info.SessionInfo</class>
        <class>org.jbpm.persistence.processinstance.ProcessInstanceInfo</class>
        <class>org.drools.persistence.info.WorkItemInfo</class>
        <class>org.jbpm.process.audit.ProcessInstanceLog</class>
        <class>org.jbpm.process.audit.NodeInstanceLog</class>
        <class>org.jbpm.process.audit.VariableInstanceLog</class>
    
        <properties>
          <property name="hibernate.dialect" value="org.hibernate.dialect.H2Dialect"/>
          <property name="hibernate.max_fetch_depth" value="3"/>
          <property name="hibernate.hbm2ddl.auto" value="update"/>
          <property name="hibernate.show_sql" value="true"/>
          <property name="hibernate.transaction.manager_lookup_class"
                    value="org.hibernate.transaction.BTMTransactionManagerLookup"/>
        </properties>
      </persistence-unit>
    </persistence>
    
  2. Registre um agente na sua Sessão Kie.

    Exemplo 14.2. Importando os Agentes

    import org.jbpm.process.audit.AuditLogService;
    import org.jbpm.process.audit.AuditLoggerFactory;
    import org.jbpm.process.audit.AuditLoggerFactory.Type;
    import org.jbpm.process.audit.JPAAuditLogService;
    ...
    

    Exemplo 14.3. Registrando um Agente a uma Sessão Kie

    @PersistenceUnit(unitName = PERSISTENCE_UNIT_NAME)
      private EntityManagerFactory emf;
    
      private AuditLogService auditLogService;
    @PostConstruct
      public void configure() {
      
      auditLogService = new JPAAuditLogService(emf);
      ((JPAAuditLogService) auditLogService).setPersistenceUnitName(PERSISTENCE_UNIT_NAME);
      
      if( emf == null ) { 
      ((JPAAuditLogService) auditLogService).setPersistenceUnitName(PERSISTENCE_UNIT_NAME);
      }
      
      RuntimeEngine runtime = singletonManager.getRuntimeEngine(EmptyContext.get());
      KieSession ksession = runtime.getKieSession();
      AuditLoggerFactory.newInstance(Type.JPA, ksession, null);
    
      }
    
  3. Facultativamente, chame o método addFilter no agente para remover as informações irrelevantes. Apenas as informações aceitas por todos os filtros aparecem no banco de dados.
  4. As classes do agente podem ser exibidas no Modo de Exibição de Auditoria:
    <dependency>
    	<groupId>org.jbpm</groupId>
    	<artifactId>jbpm-audit</artifactId>
    	<version>6.0.1.Final</version>
    </dependency>
    

14.2. Funcionalidade Logback

O Red Hat JBoss BPM Suite fornece a funcionalidade logback para a configuração de registro em log.
Assim, tudo que é configurado é registrado em log em Simple Logging Facade for Java SLF4J, o qual delega qualquer log ao Logback, Apache Commons Logging, Log4j ou java.util.logging. Adicione uma dependência ao adaptador de registros para a estrutura de registros de sua preferência. Caso não esteja usando nenhuma estrutura de registros ainda, você pode usar a funcionalidade Logback adicionando essa dependência Maven:
 
  <dependency>
     <groupId>ch.qos.logback</groupId>
     <artifactId>logback-classic</artifactId>
     <version>1.x</version>
  </dependency>

Nota

slf4j-nop e slf4j-simple são ideais para um ambiente leve.

14.3. Configurando o Registro em Log

Para configurar o nível de log dos pacotes, crie um arquivo logback.xml em business-central.war/WEB-INF/classes/logback.xml. Para definir o nível de log do pacote org.drools para a "depuração" do registro extenso, você deve adicionar ao arquivo a linha a seguir:
<configuration>

    <logger name="org.drools" level="debug"/>

    ...

<configuration>
De forma semelhante, você pode configurar o registro em log para pacotes, tais como:
  • org.guvnor
  • org.jbpm
  • org.kie
  • org.slf4j
  • org.dashbuilder
  • org.uberfire
  • org.errai
  • etc...
Se estiver configurando com log4j, log4j.xml pode ser localizado em business-central.war/WEB-INF/classes/log4j.xml e pode ser configurado da seguinte forma:
<log4j:configuration xmlns:log4j="http://jakarta.apache.org/log4j/">

    <category name="org.drools">
      <priority value="debug" />
    </category>

    ...

</log4j:configuration>

Nota

O log adicional pode ser configurado no contêiner individual. Para configurar o registro em log no JBoss Enterprise Application Platform, por favor consulte a documentação Red Hat JBoss Enterprise Application Platform Administration and Configuration Guide.

Capítulo 15. Localização e Personalização

15.1. Idiomas Disponíveis

A interface web do usuário do Red Hat JBoss BPM Suite pode ser exibida em vários idiomas:
  • Inglês dos Estados Unidos (en_US)
  • Espanhol (es_ES)
  • Japônes (ja_JP)
  • Chinês (zh_CN)
  • Português (pt_BR)
  • Francês (fr_CA)
  • Alemão (de_DE)

Nota

Caso um idioma não seja especificado, o inglês dos Estados Unidos é usado por padrão.

15.2. Alterando os Parâmetros de Idiomas

Alterando o Idioma da Interface do Usuário no Business Central

O Business Central usa a localidade do sistema por padrão. Se você precisar alterá-lo, adicione o código correspondente da localidade no fim do URL do Business Central. Por exemplo, o URL a seguir definirá a localidade para o português (pt_BR).
http://localhost:8080/business-central/?locale=pt_BR

Alterando o Idioma da Interface do Usuário no Dashbuilder

Para alterar o idioma da interface do usuário no Dashbuilder, siga as instruções a seguir:
  1. Faça o login no Dashbuilder, depois que o servidor foi iniciado com êxito, e navegue até http://localhost:8080/dashbuilder em um navegador da web.
  2. Selecione o idioma de sua escolha clicando nas localidades disponíveis na parte superior central da interface do usuário do Dashbuilder para alterar o idioma.

Configurando o Idioma Padrão da Interface do Usuário no Dashbuilder

Segue abaixo um exemplo de como configurar o idioma padrão da interface do usuário no Dashbuilder:

Procedimento 15.1. Configurando o idioma padrão como francês

  1. Navegue até jboss-eap-6.1/standalone/configuration e defina o seguinte no arquivo standalone.xml.
    <system-properties>
        <property name="org.jboss.dashboard.LocaleManager.installedLocaleIds" value="en,es,de,fr,ja,pt,zh"/>
        <property name="org.jboss.dashboard.LocaleManager.defaultLocaleId" value="fr"/>
    </system-properties>
    
  2. O idioma padrão da interface do usuário do Dashbuilder está definido agora como francês.

Definindo as Localidades Instaladas no Dashbuilder

Segue abaixo um exemplo para definir as localidades instaladas no Dashbuilder:

Procedimento 15.2. Definindo as localidades instaladas

  • Navegue até jboss-eap-6.1/standalone/configuration e defina o seguinte no arquivo standalone.xml.
    <system-properties>
        <property name="org.jboss.dashboard.LocaleManager.installedLocaleIds" value="en,es,de,fr,ja,pt"/>
        <property name="org.jboss.dashboard.LocaleManager.defaultLocaleId" value="fr"/>
    </system-properties>
    
Nesse exemplo, o idioma chinês (zh) foi removido da lista de localidades instaladas, portanto os usuários não conseguirão alternar o dashbuilder para o chinês. O Dashbuilder apresentará seus conteúdos em francês, a localidade padrão. Os usuários poderão selecionar outros idiomas que estão definidos nesse arquivo (en, es, de, ja, pt).

Nota

No Business Central, o servidor do aplicativo não precisa ser reiniciado depois que a localidade foi alterada, caso você adicione o parâmetro de "localidade" ao URL do Business Central. No entanto, com o Dashbuilder, o servidor do aplicativo deve ser reiniciado após a alteração dos arquivos de configuração.

15.3. Executando JVM com a Codificação UTF-8

O Red Hat JBoss BPM Suite foi planejado para funcionar com a codificação UTF-8. Se um sistema de codificação diferente estiver sendo usado pela JVM, alguns erros inesperados podem ocorrer.
Para garantir que a codificação UTF-8 seja usada pela JVM, use a opção JVM "-Dfile.encoding=UTF-8".

Parte IV. Execução

Capítulo 16. Servidor de Execução

16.1. Regras de Atribuição

As regras de atribuição são regras executadas automaticamente quando uma Tarefa Humana é criada ou concluída. Esse mecanismo pode ser usado, por exemplo, para atribuir automaticamente uma Tarefa Humana a um usuário de um grupo em particular ou para evitar que um usuário conclua uma Tarefa, caso os dados estejam ausentes.

16.1.1. Definindo as Regras de Atribuição

Para definir as regras de atribuição, siga as instruções a seguir:
  1. Crie um arquivo que contenha a definição de regra no caminho de classe do Business Central (o local recomendado é $DEPLOY_DIR/standalone/deployments/business-central.war/WEB-INF/classes/):
    • default-add-task.drl com as regras a serem verificadas quando a Tarefa Humana é criada
    • default-complete-task.drl com as regras a serem verificadas quando a Tarefa Humana é concluída
  2. Defina as regras no arquivo.

Exemplo 16.1. Conteúdo default-add-task.drl

package defaultPackage

import org.kie.api.task.model.Task;
import org.kie.api.task.model.User;
import org.kie.api.task.model.Status;
import org.kie.api.task.model.PeopleAssignments;
import org.jbpm.services.task.rule.TaskServiceRequest;
import org.jbpm.services.task.exception.PermissionDeniedException;
import org.jbpm.services.task.impl.model.*;
import java.util.HashMap;
import java.util.List;


global TaskServiceRequest request;

rule "Don't allow Mary to complete task when rejected"
    when
        $task : Task()
        $actualOwner : User( id == 'mary') from $task.getTaskData().getActualOwner()
        $params : HashMap(this["approved"] == false)
    then
        request.setAllowed(false);
        request.setExceptionClass(PermissionDeniedException.class);
        request.addReason("Mary is not allowed to complete task with approved false");
end
Caso os proprietários potenciais de uma Tarefa Humana contenham o usuário Mary, a tarefa será atribuída automaticamente ao usuário mary.

Exemplo 16.2. Conteúdo default-complete-task.drl

package defaultPackage

import org.kie.api.task.model.Task;
import org.kie.api.task.model.User;
import org.kie.api.task.model.Status;
import org.kie.api.task.model.PeopleAssignments;
import org.jbpm.services.task.rule.TaskServiceRequest;
import org.jbpm.services.task.exception.PermissionDeniedException;
import org.jbpm.services.task.impl.model.*;
import java.util.HashMap;
import java.util.List;


global TaskServiceRequest request;

rule "Don't allow Mary to complete task when rejected"
    when
        $task : Task()
        $actualOwner : User( id == 'mary') from $task.getTaskData().getActualOwner()
        $params : HashMap(this["approved"] == false)
    then
        request.setAllowed(false);
        request.setExceptionClass(PermissionDeniedException.class);
        request.addReason("Mary is not allowed to complete task without approval.");
end
Caso os proprietários potenciais de uma Tarefa Humana contenham o usuário Mary, a tarefa será atribuída automaticamente ao usuário mary.

16.2. Sessão de Email

A sessão de email define as propriedades do servidor de email que serão usadas para enviar emails, caso exigido pelo aplicativo, como escalonamento ou mecanismos de notificação (consulte Red Hat JBoss BPM Suite User Guide).

16.2.1. Configurando a sessão de email

Para configurar a sessão de email para o seu mecanismo de execução, siga as instruções a seguir:
  1. Abra o respectivo arquivo de configuração do perfil (standalone.xml or host.xml) para edição.
  2. Adicione a sessão de email ao subsistema urn:jboss:domain:mail:1.1.

    Exemplo 16.3. Nova sessão de email no localhost

    <subsystem xmlns="urn:jboss:domain:mail:1.1">
        <!-- omitted code -->
    
        <mail-session jndi-name="java:/mail/bpmsMailSession" debug="true" from="bpms@company.com">
            <smtp-server outbound-socket-binding-ref="bpmsMail"/>
        </mail-session>
    </subsystem>
    
  3. Defina o soquete de saída da sessão no arquivo de configuração do perfil.

    Exemplo 16.4. Definição do soquete de saída

    <outbound-socket-binding name="bpmsMail">
        <remote-destination host="localhost" port="12345"/>
    </outbound-socket-binding>
    

Capítulo 17. Plug-in para o Red Hat JBoss Developer Studio

17.1. Plug-in

Parte V. Monitoramento

Capítulo 18. Monitoramento de Processos

18.1. JBoss Operations Network

Um plug-in do JBoss Operations Network pode ser usado para monitorar as sessões de regras para o Red Hat JBoss . O plug-in usa Java Management Extensions (JMX) para monitorar as sessões de regras.
Devido a uma limitação de transferência dos argumentos de monitoramento JVM através da linha de comando do Maven, todos os parâmetros com.sun.management.jmxremote.* devem ser transferidos para o aplicativo JBoss através do arquivo de configuração pom.xml.
Por favor, consulte o guia JBoss Operations Network Installation Guide para as instruções de instalação do servidor JBoss ON.

18.2. Instalando o Plug-in do JBoss BRMS no JBoss ON

O plug-in do Red Hat JBoss BRMS para o JBoss Operations Network pode ser instalado através da cópia dos arquivos JAR do plug-in no diretório do plug-in do JBoss Operations Network ou através da GUI do JBoss Operations Network.
O procedimento a seguir guia o usuário para copiar os arquivos JAR do plug-in no diretório do plug-in do JBoss Operations Network.

Procedimento 18.1. Copiando os arquivos JAR do plug-in do JBoss BRMS

  1. Extraia o pacote de plug-ins do JBoss BRMS colocando-o em um local temporário. Essa ação cria um subdiretório com o nome de jon-plugin-pack-brms-bpms-3.3.0.GA. Por exemplo:
    [root@server rhq-agent]# unzip jon-plugin-pack-brms-bpms-3.3.0.GA.zip -d /tmp
  2. Copie os arquivos JAR do plug-in do JBoss BRMS a partir do diretório jon-plugin-pack-brms-bpms-3.2.0.GA/ no diretório do plug-in do servidor JBoss ON. Por exemplo:
    [root@server rhq-agent]# cp /tmp/jon-plugin-pack-brms-bpms-3.3.0.GA/*.jar /opt/jon/jon-server-3.3.0.GA1/plugins
  3. Inicie o servidor do JBoss Operations Network para atualizar o plug-in do JBoss BRMS.
Para carregar o plug-in do JBoss BRMS através da GUI do JBoss Operations Network, siga os prodecimentos abaixo:

Procedimento 18.2. Carregando o plug-in do JBoss BRMS através da GUI

  1. Inicie o servidor do JBoss Operations Network e Faça o Login para acessar a GUI.
  2. Na navegação superior da GUI, abra o menu Administração.
  3. Na área de Configuração à esquerda, selecione o link Plug-ins do Servidor.
  4. No fim da lista dos plug-ins carregados do servidor, clique no botão Carregar um plug-in e selecione o plug-in do BRMS.
  5. O plug-in do JBoss BRMS para o JBoss Operations Network está agora carregado.

18.3. Monitorando as Bases Kie e Sessões Kie

Para que o JBoss Operations Network possa monitorar KieBases e KieSessions, os MBeans devem estar habilitados.
Os MBeans podem ser habilitados seja passando o parâmetro:
-kie.mbeans = enabled
Ou através da API:
KieBaseConfiguration kbconf = KieServices.Factory.get().newKieBaseConfiguration();
    kbconf.setOption(MBeansOption.ENABLED);

Nota

Kie Services foi implementado para o JBoss BRMS 6; já para o JBoss BRMS 5, a convenção de nomenclatura Drools Services foi usada e ela tinha diferentes medidas sobre as sessões. Por exemplo, a renomeação de ativaçãocorrespondência ocorreu na versão atualizada.
Por favor, consulte o guia JBoss Operations Network Resource Monitoring and Operations Reference para mais informações sobre a importação das Sessões Kie no Modo de Exibição de Inventário para fins de monitoramento.

Capítulo 19. Gerenciando Segurança para o Dashbuilder do Red Hat JBoss BPM Suite

19.1. Acessando o Dashbuilder do Red Hat BPM Suite

O Dashbuilder é a interface do usuário baseada na web do Red Hat JBoss BPM Suite para o Monitoramento de Atividades Empresariais. Para acessar o Dashbuilder do Business Central, vá até PainéisPainéis de Tarefas & Processos.
O painel exibido fornece as estatísticas sobre os dados do tempo de execução selecionados à esquerda. Você pode criar o seu próprio painel no Dashbuilder. Para fazê-lo, abra o Dashbuilder clicando em PainéisPainéis de Negócios.

19.2. Gerenciando Segurança

Para gerenciar a segurança, você pode definir políticas de autorização personalizadas concedendo ou negando acesso ao espaço de trabalho, páginas ou instâncias de painel por função.
Segue abaixo uma lista das funções disponíveis no Dashbuilder:
  • admin - administra o sistema Red Hat JBoss BPM Suite e possui total direito de acesso para fazer quaisquer alterações necessárias. Também possui a habilidade de adicionar e remover os usuários do sistema.
  • desenvolvedor - implementa os códigos necessários para os processos funcionarem. Usa, na maioria das vezes, a conexão JBDS para exibir os processos, mas também pode usar ocasionalmente a ferramenta web.
  • analista - responsável pela criação e pelo planejamento dos processos no sistema. Cria fluxos de processos e lida com os pedidos de alteração dos processos. Os processos criados devem ser testados. Também cria formulários e painéis.
  • usuário - usuário diário do sistema que trabalha nas tarefas de negócios que são necessárias para dar continuidade aos processos. Trabalha principalmente com as listas de tarefas.
  • gerenciador - visualizador do sistema que está interessado nas estatísticas referentes aos processos empresariais e seus desempenhos, indicadores de negócios e outros tipos de notificação do sistema, assim como às pessoas que interagem com o sistema.
Graças ao sistema de permissões, você pode criar uma estrutura de espaço de trabalho com várias páginas, menus e painéis, assim como definir quais páginas e painéis dentro de uma página estarão visíveis para cada função. Você também pode definir tipos especiais de usuários e fornecê-los acesso restrito a certos recursos de ferramentas ou até a subconjuntos de uma página.

19.3. Permissões do Espaço de Trabalho

Procedimento 19.1. Acessando as Permissões do Espaço de Trabalho

  1. Faça o login nos Painéis de Negócios a partir do Business Central (como descrito no tópico Acessando o Dashbuilder do Red Hat BPM Suite)
  2. Selecione o Painel apropriado a partir do menu suspenso do espaço de trabalho.
    Dashbuilder Workspace for BPMS 6.0.2

    Figura 19.1. Espaço de Trabalho do Dashbuilder

  3. Clique no botão Editar propriedades do espaço de trabalho selecionado para acessar o Painel do Espaço de Trabalho.
  4. Clique no rótulo Permissões para exibir a tela de gerenciamento das permissões.
    Permission Management Screen for BPMS 6.0.2

    Figura 19.2. Tela de Permissões

A seção Designação de permissões contém uma lista das ações permitidas que são aplicadas à função selecionada:
  • Acessar: permissão para fazer o login no aplicativo.
  • Administrar: permissão para acessar a barra de ferramentas e os recursos de configuração do sistema.
  • Criar páginas: habilidade para criar novas páginas de projetos.
  • Editar: permissão para alterar as propriedades do espaço de trabalho.
  • Limpar: habilidade para limpar o espaço de trabalho.
  • Editar permissões: habilidade para conceder/ negar permissões.
  • Alterar painéis permitidos: permissão para restringir os tipos de painéis que podem ser usados nesse espaço de trabalho.
Para atribuir uma permissão, você deve selecionar a função de destino e a lista de ações permitidas no lugar do recurso selecionado.
Permissions assignation image for BPMS 6.0.2

Figura 19.3. Designação de Permissões

  • Funções de destino (quem): quais usuários terão as permissões definidas concedidas/ negadas.
  • Ações permitidas: dependendo do tipo de recurso, é possível habilitar/desabilitar o que o usuário pode fazer com esse recurso.
  • Reverter (opcional): quando existe um conjunto de funções e há o interesse em conceder/negar uma permissão a todas as funções, com exceção de uma.

Nota

Por padrão, o conjunto completo de permissões é dado à função admin. Isto facilita a criação de um usuário que pode fazer tudo, desde que tenha atribuída a função de admin.

19.4. Permissões de Páginas

  1. Para acessar as Permissões de Páginas, localize o menu suspenso Páginas sob o Painel jBPM (ou sob qualquer outro Painel que desejar).
  2. Após expandir Páginas, expanda a opção Painel de processos.
  3. Selecione a opção Permissões de Páginas.
Permission management screen for BPMS 6.0.2

Figura 19.4. Permissões de Páginas

A seção Designação de permissões contém uma lista das ações permitidas que são aplicadas à função selecionada:
  • Visualizar: permissão para deixar a página visível.
  • Editar: habilidade para alterar as propriedades de uma página.
  • Limpar: habilidade para excluir uma página.
  • Editar permissões: habilidade para conceder/ negar permissões a uma página.

19.5. Permissões de Painel

  1. Para acessar a página Permissões de Painel, expanda a opção Instâncias de painel sob o Painel jBPM (ou sob qualquer outro Painel que estiver usando).
  2. Expanda a opção Painel e, então, expanda o Painel de processos.
  3. Expanda a opção Panéis e selecione o processo adequado.
  4. Abra a página Permissões de Painel.
Segue abaixo uma tela de gerenciamento de permissões para um dado painel (nesse exemplo, o Painel de processos):
Panel permissions for Dashbuilder in BPMS 6.0.2

Figura 19.5. Tela de configuração das permissões do painel

As ações permitidas são:
  • Visualizar: deixar o painel visível.
  • Editar: alterar as propriedades do painel.
  • Editar permissões: habilidade para conceder/ negar permissões para o painel.

Apêndice A. Histórico de Revisões

Histórico de Revisões
Revisão 1.0.0-1.1Tue Jan 5 2016Red Hat Localization Services
Tradução de arquivos sincronizados com a versão 1.0.0-1 de fontes do XML
Revisão 1.0.0-1Wed Aug 05 2015Petr Penicka
Construído a partir da Especificação do Conteúdo: 22829, Revisão: 765028 por ppenicka

Nota Legal

Copyright © 2015 Red Hat, Inc.
This document is licensed by Red Hat under the Creative Commons Attribution-ShareAlike 3.0 Unported License. If you distribute this document, or a modified version of it, you must provide attribution to Red Hat, Inc. and provide a link to the original. If the document is modified, all Red Hat trademarks must be removed.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.