Présentation des bundles de serveur

L'application peut être déployée dans une ou plusieurs charges de travail, appelées bundles de serveur. Un bundle de serveur isole les processus de charge de travail afin qu'ils puissent être gérés de manière indépendante.

Les bundles de serveur peuvent être mis à l'échelle et gérés de manière indépendante en fonction de vos besoins. Par exemple, le bundle de serveur d'interface utilisateur permet aux utilisateurs d'accéder à l'interface utilisateur à l'aide d'un navigateur Web. Un bundle de serveur de tâche périodique permet aux utilisateurs d'exécuter des travaux en arrière-plan. Lorsqu'une charge de travail d'interface utilisateur et une charge de travail de tâche périodique sont déployées en tant que deux bundles de serveur distincts, l'unité centrale et la mémoire utilisées par ces charges de travail n'ont pas d'incidence l'une sur l'autre.

Un bundle de serveur est composé d'un ou de plusieurs pods. Chaque bundle de serveur peut être configuré individuellement pour sa configuration de serveur supplémentaire, ses options jvm et ses propriétés de niveau bundle. Différents bundles de serveur peuvent être associés à des volumes persistants identiques ou différents.

Tous les bundles de serveur se connectent à la même base de données.

Un bundle de serveur que vous déployez est désigné comme serveur par défaut. Le groupe de serveurs que vous désignez par défaut est utilisé pour établir l' URL par défaut, c'est-à-dire la route qui mène à l'application Manage dans l'espace de travail.

Lorsque vous créez vos bundles de serveur, gardez à l'esprit les exigences et comportements suivants:

Vous pouvez configurer plusieurs bundles de serveur en fonction de votre charge de travail. Le type de bundle détermine les capacités du serveur. Par exemple, un bundle cron ne peut pas servir de demandes d'interface utilisateur mais uniquement pour exécuter des tâches périodiques.
Vous pouvez avoir plusieurs bundles de serveur du même type si le regroupement de charges de travail pour différentes configurations est nécessaire. Par exemple, vous pouvez définir deux tous les bundles de serveur dans lesquels un bundle de serveur est utilisé pour le premier groupe d'utilisateurs et un pour le deuxième groupe.
Si un seul bundle de serveur est spécifié, vous devez spécifier all comme type de bundle. Si vous ne spécifiez pas tous les as du type par défaut, le déploiement peut sembler réussi. Toutefois, l'application ne fonctionne pas correctement.
Le bundle de serveur par défaut doit posséder le type de bundle all ou ui. Si vous ne spécifiez pas l'un de ces types pour la valeur par défaut, le déploiement peut sembler réussi, mais l'application ne fonctionne pas correctement. Si votre bundle de serveur par défaut est un bundle d'interface utilisateur, vous devez également disposer d'un bundle de serveur mea car ce dernier est nécessaire pour la synchronisation des utilisateurs.
Si vous créez un seul bundle de serveur et que vous ne spécifiez pas de bundle par défaut, ce bundle est sélectionné comme bundle par défaut.
Si vous créez plusieurs bundles de serveur et que vous ne spécifiez pas de valeur par défaut, un bundle de serveur dont le type est all est sélectionné de manière aléatoire comme serveur par défaut.

Lorsque vous déployez l'application, vous spécifiez des paramètres qui contrôlent le déploiement des pods de bundle de serveur et de leurs services et routes associés.

Vous pouvez spécifier les paramètres de bundle de serveur suivants pour configurer le déploiement :

Nom: Nom défini par l'utilisateur du bundle de serveur. Vous pouvez également indiquer si le bundle de serveur est celui par défaut.

Nombre de pods: Nombre de pods à déployer pour le bundle de serveur.

Type

Type du bundle de serveur. Les six types de bundle suivants sont disponibles:

tout: Inclut les types de bundle ui, cron, mea et report.
interface: Composants de l'interface utilisateur.
cron: Composants requis pour les tâches périodiques.
mea: L'API des services Web d'entreprise. Ce type de bundle de serveur est nécessaire pour la synchronisation des utilisateurs.
Rapport: Composants des rapports.
Standalonejms: Spécifiez standalonejms pour le type de bundle de serveur afin d'ajouter un bundle de serveur JMS (Java Message Service) lors du déploiement de Maximo® Manage. Pour plus d'informations, voir Configuration de serveurs JMS pour Maximo Manage.

Propriétés de serveur supplémentaires

Vous pouvez éventuellement ajouter les propriétés suivantes :

Sous-domaine de route

Si vous spécifiez un sous-domaine, il est ajouté en tant que préfixe au domaine principal lorsque la route est créée pour le bundle de serveur. Par exemple, si vous spécifiez maximoui comme sous-domaine, votre domaine complet est similaire à l'exemple suivant: maximoui.workspaceid.manage.domain.com.

Configurations de serveur supplémentaires

Pour configurer le serveur d'applications WebSphere® Application Server Liberty , vous pouvez fournir des paramètres personnalisés, comme illustré dans l'exemple suivant:

  server-custom.xml: |-
    <!-- Enable features -->
    <featureManager>
        <feature>jsp-2.3</feature>
    </featureManager>

    <!-- To access this server from a remote client add a host attribute to the following element, e.g. host="*" -->
    <httpEndpoint id="defaultHttpEndpoint"
                  httpPort="9080"
                  httpsPort="9443" />
    <!-- Automatically expand WAR files and EAR files -->
    <applicationManager autoExpand="true"/>

Propriétés de niveau bundle

Pour ajouter des propriétés système Gérer à des bundles de serveur spécifiques, vous pouvez spécifier des noms et des valeurs de propriété lorsque vous déployez l'application.