2.4. 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:

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.

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).

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:

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.

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.

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.

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).

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>

Os Descritores de Implantação podem ser editados através do Business Central de duas formas: graficamente (clicando em Criação → Criação de Projeto e, depois, selecionando Ferramentas → Descritor de Implantação) ou clicando no menu Criação → Administraçã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.

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.

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.