2.4. Descripteurs de déploiement

Les descripteurs de déploiement permettent à l'utilisateur de configurer le serveur d'exécution sur plusieurs niveaux :

Les éléments de configuration granulaire spécifiés par les descripteurs de déploiement ont préséance sur ceux niveau serveur, sauf dans le cas d'éléments de configuration basés collection, qui sont fusionnés. La hiérarchie fonctionne comme ceci : configuration du temps de déploiement > configuration kjar > configuration du serveur.

Ainsi, si le mode de persistance (l'un des éléments que vous pouvez configurer) défini au niveau du serveur est NONE, mais que le même mode est spécifié comme JPA au niveau kjar, le mode réel sera JPA pour cette kjar. Si rien n'est spécifié pour le mode de persistance dans le descripteur de déploiement pour ce kjar (ou s'il n'y a aucun descripteur de déploiement), cela renverra à la configuration niveau serveur, qui est dans ce cas NONE (aucun) (ou JPA s'il n'y a aucun descripteur de déploiement au niveau du serveur).

Oui. Dans le mode par défaut, s'il existe des descripteurs de déploiement présents à plusieurs niveaux, les propriétés de configuration seront fusionnées avec les propriétés granulaires se substituant aux valeurs brutes, et avec les éléments de configuration manquants au niveau granulaire fournis par les valeurs présentes aux niveaux supérieurs. Le résultat final est une configuration fusionnée de descripteur de déploiement. Ce mode de fusion par défaut s'appelle le mode MERGE_COLLECTIONS. Mais vous pouvez en changer (Section 2.4.2, « Gestion des descripteurs de déploiement ») si cela ne convient pas à votre environnement :

Les descripteurs de déploiement des kjars dépendants sont mis à un niveau inférieur à celui auquel le kjar est déployé, mais ils sont toujours situés à un niveau supérieur par rapport au serveur.

Non. Et c'est ici précisément que la fusion entre différents fichiers peut vous être utile. Il est possible et recommandé de fournir des descripteurs de déploiement partiels. Par exemple, si vous souhaitez substituer le mode auditing dans un kjar, vous aurez juste besoin de fournir ceci et le reste des valeurs sera fusionné du niveau serveur aux kjars de niveaux supérieurs.

Il est important de noter que quand on utilise le mode OVERRIDE_ALL, tous les éléments de configuration doivent être spécifiés car le kjar pertinent les utilisera toujours et ne mergera avec aucun autre descripteur de déploiement dans la hiérarchie.

Les informations de configuration technique de haut niveau peuvent être configurées par les descripteurs de déploiement. Le tableau suivant en donne la liste, ainsi que des valeurs autorisées et par défaut pour chacun.

Dans le tableau d'éléments de configuration valide vu plus haut, vous aurez sans doute remarqué que les valeurs valides pour les éléments basés collection sont soit ObjectModel, soit NamedObjectModel. Les deux sont similaires et fournissent une définition de l'objet à construire ou créer pendant le runtime, sauf que les informations sur l'objet NamedObjectModel nomment l'objet à observer. Ces deux types sont définis à l'aide d'un identificateur, de paramètres facultatifs et d'un résolveur (qui résoudre l'objet).

Ainsi, si vous avez construit une stratégie de marshaling personnalisée et que vous souhaitez que vos déploiements utilisent cette stratégie plutôt que de la valeur par défaut, vous devrez fournir cette stratégie comme ObjectModel, avec pour identificateur com.mycompany.MyStrategy, le programme de résolution étant reflection (le plus simple et la valeur par défaut) et tous les paramètres requis pour que votre stratégie fonctionne. Reflexion servira ensuite pour créer une instance de cette stratégie en utilisant le nom de classe qualifié complet que vous avez fourni comme identificateur.

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

Dans le cas où un programme de résolution basé reflection ne suffise pas (comme c'est le cas dans l'exemple précédent), vous pourrez utiliser un programme de résolution basé MVEL comme identificateur du modèle d'objet. Quand vous évaluez les expressions, vous pouvez substituer les paramètres out-of-the-box. Exemple :

<marshalling-strategy> 
  <resolver>mvel</resolver> 
  <identifier>new com.myCompany.CustomStrategy(runtimeManager)</identifier> 
</marshalling-strategy>

Le programme de résolution Spring vous permet de chercher un bean par son identificateur à partir d'un contexte d'application Spring. Chaque fois que JBoss BPM Suite est utilisée avec Spring, ce programme de résolution aide à déployer les kjars dans l'environnement de runtime. A titre d'exemple (à noter que l'identificateur est, dans ce cas, un bean nommé en contexte Spring) :

<marshalling-strategy>
 <resolver>spring</resolver> 
 <identifier>customStrategy</identifier> 
</marshalling-strategy>

Les descripteurs de déploiement peuvent être modifiés via Business Central d'une des deux façons suivantes. Soit graphiquement (en cliquant sur Création → Création de projet, puis en sélectionnant Outils → Descripteur de déploiement) ou soit en cliquant sur le menu Création → Administration, puis en cliquant sur le dossier META-INF de File Explorer. Cliquer sur le fichier kie-deployment-descriptor.xml pour pouvoir le modifier manuellement.

À chaque fois qu'un projet est créé, un fichier kie-deployment-descriptor.xml de stockage est généré avec les valeurs par défaut décrites plus haut.

Pour changer le mode par défaut de MERGE_COLLECTIONS à KEEP_ALL, OVERRIDE_ALL ou OVERRIDE_EMPTY, vous pouvez utiliser une des méthodes suivantes, selon les besoins.

Un des éléments de configuration discutés plus tôt, required-roles, peut être modifié par les descripteurs de déploiement. Cette propriété limite l'accès au moteur d'exécution sur la base d'un kjar ou par niveau de serveur, en veillant à ce que l'accès à certains processus ne soit accordé qu'aux utilisateurs qui appartiennent à des groupes définis par cette propriété.

Le rôle de sécurité peut être utilisé pour limiter l'accès aux définitions de processus ou pour restreindre l'accès pendant le runtime.

Le comportement par défaut consiste à ajouter des rôles requis à cette propriété sur la base des restrictions du référentiel. Vous pouvez, biensûr, modifier ces propriétés manuellement si nécessaire, comme décrit ci-dessus, en fournissant des rôles qui correspondent aux rôles définis dans le domaine de sécurité.