Installation dans IBM WebSphere (recommandé)

Ci-dessous un exemple de déploiement d’ARender pour FileNet dans le serveur d’application IBM WebSphere.

Environnement pour l’exemple de déploiement :

• Système d’exploitation : Windows Server 2016
• Filenet 5.5
• Serveur d’application Websphere 9.0.5.0
• ARender HMI pour FileNet version 2023.15.0

Récupérer l’EAR du serveur de présentation pour FileNet

En utilisant l’identifiant et mot de passe préalablement fournis, vous pouvez récupérer l’application web en format EAR ici.

Déploiement de l’EAR dans IBM Websphere

• Ouvrir une console WebSphere

https://serveur_websphere:9043/ibm/console

• Aller dans l’onglet « Applications », puis cliquer sur « Applications d’entreprise »

• Pour lancer l’installation, cliquer sur « Installer »

• Choisir le chemin de l’EAR à déployer et cliquer sur « Suivant »

• Pour accepter les paramètres par défaut, cliquer sur « Suivant »

• Sélectionner le(s) webserver(s) et/ou serveur(s), puis cliquer sur « Suivant »

• Pour accepter les paramètres par défaut (hôte virtuel : default_host), cliquer sur « Suivant »

• Dans la fenêtre récapitulative de l’installation, cliquer sur « Terminer » pour procéder à l’installation avec ces paramètres après les avoir vérifié

Configuration post installation

Ordre de chargement des librairies

Il faut s’assurer que l’ordre de chargement des librairies soit configuré de telle sorte de Websphere charge ses librairies en dernier.

• Dans la liste des applications d’entreprise cliquer l’application ARender 2023.0.X for FileNet 5.x

• Cliquer sur Gestion des modules

• Cliquer sur le module ARender

• Sélectionner, dans la liste déroulante « Ordre du chargeur de classes » : « Classes chargées en premier avec un chargeur de classe local (dernier parent)

• Cliquer sur OK puis sauvegarder les modifications.

• Démarrer l’application ARender

Installation dans CPE terminé

Vous pouvez accéder à un document FileNet via une URL formée comme ceci :

http://{server_arender}:{port_arender}/ARender/?id={id}&objectStoreName=OS1

🧭 Répartition de charge et gestion de session pour ARender sur IBM WebSphere

Cette section vous guide pour mettre en place une architecture de répartition de charge robuste pour l'HMI ARender déployée sur IBM WebSphere Application Server. Cette configuration garantit des performances optimales, la stabilité des sessions et une haute disponibilité en s’appuyant sur IBM HTTP Server (IHS) comme répartiteur de charge.

🎯 Objectifs de la mise en œuvre

• Répartir efficacement les requêtes HTTP entrantes entre plusieurs nœuds WebSphere (HMI ARender)
• Garantir la persistance des sessions (affinité de session) entre les requêtes.
• Permettre la configuration de suffixes de cookie de session pour supporter le routage par affinité.

🧩 Vue d’ensemble de l’architecture

Rôle d’IHS (IBM HTTP Server)

IHS agit comme reverse proxy et répartiteur de charge (load balancer), distribuant les requêtes entrantes vers deux nœuds WebSphere hébergeant l'HMI ARender (appelés node1 et node2). Le comportement du routage dépend de la présence d’un cookie de session.

Cas 1 : La requête HTTP ne contient pas de cookie SESSION

👉 IHS transmet la requête à l’un des nœuds de façon aléatoire ou selon un poids défini.

Cas 2 : La requête HTTP contient un cookie SESSION

👉 IHS extrait le suffixe du cookie de session (après le séparateur :), et le compare aux valeurs CloneID définies dans le fichier plugin-cfg.xml.

• Si une correspondance est trouvée, la requête est routée vers le nœud correspondant (affinité de session).
• Si aucune correspondance n’est trouvée, la requête retombe sur le comportement du cas 1.

⚙️ Configuration sur WebSphere

Objectif : Générer des cookies de session spécifiques à chaque nœud

Chaque nœud WebSphere doit ajouter un suffixe personnalisé au cookie SESSION pour s’identifier de façon unique : <sessionId>:<cloneId>

Exemples :

• Pour node1 : {cookieValue}:cloneId1
• Pour node2 : {cookieValue}:cloneId2

Paramètres de configuration JVM

Dans la console d’administration WebSphere :

Chemin :
Serveurs > Types de serveurs > Serveurs d’applications WebSphere > {Nom du serveur} > Infrastructure du serveur > Gestion des processus et Java > Définition des processus > Propriétés supplémentaires > Machine virtuelle Java

Ajoutez les options JVM suivantes dans Arguments JVM génériques :

Pour node1 :

• -Dcom.uxopian.arender.session.jvm.route=node1
• -Dcom.uxopian.arender.session.jvm.route.separator=:
• -Dcom.uxopian.arender.session.jvm.base64=false

Pour node2 :

• -Dcom.uxopian.arender.session.jvm.route=node2
• -Dcom.uxopian.arender.session.jvm.route.separator=:
• -Dcom.uxopian.arender.session.jvm.base64=false

Explication des paramètres :

Le cookie SESSION doit ressembler à ceci

Dans l’exemple ci-dessus, le cloneId pour node1 est node1

🛠️ Configuration IHS (plugin-cfg.xml)

La configuration IHS implique quatre éléments principaux :

1. VirtualHostGroup – définit les adresses d’écoute.

2. ServerCluster – liste les nœuds WebSphere en backend.

3. UriGroup – définit les patterns d’URL gérés.

4. Route – relie les composants ci-dessus.

   Exemple de configuration :

<ServerCluster CloneSeparatorChange="false" GetDWLMTable="true" IgnoreAffinityRequests="false" LoadBalance="Round-Robin" Name="ARender_ServerCluster" PostBufferSize="0" PostSizeLimit="-1" RemoveSpecialHeaders="true" RetryInterval="60" ServerIOTimeoutRetry="-1">
   <Server CloneId="node1" Name="node1" ServerIOTimeout="900">
      <Transport Hostname="localhost" Port="9080" Protocol="http"/>
   </Server>
   <Server CloneId="node2" Name="node2" ServerIOTimeout="900">
      <Transport Hostname="localhost" Port="9081" Protocol="http"/>
   </Server>
</ServerCluster>
<UriGroup Name="ARender_UriGroup">
   <Uri AffinityCookie="SESSION" AffinityURLIdentifier="jsessionid" Name="/ARender/*"/>
</UriGroup>
<Route ServerCluster="ARender_ServerCluster" UriGroup="ARender_UriGroup" VirtualHostGroup="ARender_VirtualHostGroup"/>

Explications :

• Toutes les URL correspondant à /ARender/* sont routées vers node1 ou node2.
• Le cookie SESSION est utilisé pour l’affinité de session.
• Les communications internes se font via les ports 9080 et 9081 sur localhost.

✅ Résultat attendu

Avec cette configuration :

• Chaque session utilisateur est systématiquement routée vers le bon nœud HMI, selon le suffixe du cookie.
• Les sessions restent stables et ininterrompues dans un environnement clusterisé.
• Le système est extensible et supporte la montée en charge future.