Tous les serveurs utilisent la même base de données et un partage de fichiers commun. Le partage de fichiers est utilisé pour les journaux et plusieurs autres répertoires, notamment logs, var/email, var/plugins et var/repository. Chaque serveur gère également individuellement certaines informations de configuration, telles que les ports et les hôtes. La base de données est utilisée pour les informations de configuration, les données d'exécution, etc.
Etant donné que les serveurs partagent la base de données, ils s'exécutent tous dans le même intervalle.
Certains propriétés de configuration restent sur le serveur, comme les informations de base de données et de connexion JMS. La configuration de la base de données est traitée lors de l'installation du produit ; aucune configuration supplémentaire n'est requise après l'installation.
Les flux de travail se composent d'activités. Les activités peuvent être exécutées de façon séquentielle, en parallèle ou selon une combinaison de ces deux types d'exécution. Un flux de travail classique se compose de plusieurs activités séquentielles, par exemple :
Pour les communications reposant sur JMS, les agents peuvent être configurés de plusieurs façons :
Tous les serveurs interrogent constamment les flux de travail en instance ; par conséquent, n'importe quel serveur peut initier le flux de travail. Le serveur qui acquiert ce flux de travail exécute les tâches suivantes :
Une fois le travail terminé, l'agent envoie un message de réponse sur JMS. Le message est écrit dans la base de données (par l'un des serveurs) et l'activité suivante est démarrée (par l'un des serveurs). Le serveur qui a démarré l'activité B exécute les mêmes étapes que celles décrites précédemment.
Dans le flux de travail simple esquissé ici, les activités peuvent toutes être traitées par le même serveur ou par des serveurs différents (ou une combinaison). Bien entendu, il en irait de même si ce flux de travail comportaient trois activités parallèles.
Un flux de travail d'application est géré par un enregistrement unique dans la base de données (une seule unité d'exécution traite un flux de travail simultanément).
Lors du traitement d'une application, les échecs de commande sont signalés dans le flux de travail. L'auteur de l'application est en charge de la gestion des erreurs. La restauration de composant peut être gérée avec une commande/des étapes de restauration. La restauration, telle qu'appliquée ici, consiste à réinstaller une version de composant antérieure.
Si le serveur est défaillant alors qu'un agent exécute une commande, le maillage JMS affecte le flux de travail à un autre serveur.
Si un agent est défaillant ou qu'il disparaît lors de l'exécution d'une commande (n'oubliez pas que l'échec d'une étape n'entraîne pas l'échec de l'agent lui-même), le serveur suppose que la commande est toujours en cours d'exécution ; il n'existe pas de délai d'attente automatique. Normalement, il n'est pas possible d'affecter un intervalle de délai d'attente.