Architecture Générale

La base Desktop Project va s'ajouter à une architecture Desktop Manager existante. Elle sera généralement installée au côté de la base Desktop Manager (DskMgr.nsf), dans le même répertoire. S'il existe plusieurs répliques de la base Desktop Manager, il conviendra également de répliquer la base Desktop Manager Project (DskMgrProject.nsf).

Le schéma d'architecture générale est le suivant :

Côté Poste Client, il n'y a aucune modification à apporter, car la base Desktop Project utilise le fait que le produit Desktop Manager y soit installé en mode récurrent (activation quotidienne).

Côté Serveur, la base Desktop Project (DskMgrProject.nsf) est installée dans le même répertoire que la base Desktop Manager. Les 4 agents Project (Project 1 : Local Replica Mode, Project 2 : Change Mail Server, Project 3 : Move Application, Project 4 : Clean-Up Workspace) présents dans la base Desktop Manager Project for Consolidation sont copiés dans la base Desktop Manager.

En fonction des projets en cours, il conviendra de déclarer les agents Project dans un document Profile des utilisateurs, dans la base Desktop Manager. Ainsi, tous les jours, ces agents seront exécutés sur les postes des utilisateurs. La première action réalisée par les agents Project est d'ouvrir la base Desktop Project pour vérifier si l'utilisateur est concerné par un des projets en cours. Si ce n'est pas le cas, l'exécution de l'agent s'arrête là.

Ces agents sont en charge de la partie 'Modification de la configuration des postes clients' dans les projets. Ils sont exécutés par l'application Desktop Manager et disposent ainsi de toutes les fonctions de Desktop Manager pour aller modifier les différentes structures de données du client Notes (Icones du Workspace, Pages du Replicateur, Documents Sites, Fichier Notes.ini, Création des répliques locales...).

Les agents utilisent la base Desktop Project à la fois pour déterminer si une action particulière est requise sur le poste de l'utilisateur, mais également pour récupérér dans le document de Setup les paramètres requis à la modification des paramètres du poste. Il n'y a donc pas modification de code à faire au niveau du code des agents, simplement du paramétrage à effectuer au niveau de la base Desktop Manager Project.

La base Desktop Project est synchronisée avec la base Desktop Manager via un outil externe appelé SynchroNSF. Cet exécutable, planifié une fois par jour, assure que chaque utilisateur enregistré dans la base Desktop Manager est également présent dans la base Desktop Project. Ces documents User sont utilisés pour sélectionner quels sont les utilisateurs devant être traités et pour suivre leur progression dans les différentes étapes du Workflow. Il est également possible de remplir la base Desktop Manager Project depuis le Carnet d'adresse (NAB database), toujours à l'aide de SynchroNSF. Si Desktop Manager est déjà installé sur les poste, il est plus facile de remplir la base Project à partir de la base Desktop Manager. Si l'installation de Desktop Manager sur les poste doit coïncider avec l'exécution des Agents de migration, il sera nécessaire de pré-remplir la base Project depuis le NAB.

Du côté du poste client, nous disposons donc de l'application Desktop Manager qui assure une exécution quotidienne des agents et côté serveur, nous avons la base Desktop Project qui contrôle, pour chaque utilisateur, le déclenchement des différents traitements à travers un Workflow. Quand les Agents s'exécutent sur le poste client, la décision de modifier ou pas le poste est dicté par l'état du document User dans la base Desktop Project.

En plus de servir de support aux documents du Workflow, la base Desktop Project est utilisée par les administrateurs pour les différentes étapes du Workflow qui nécessitent la modification des resources côté serveur (Création des répliques sur le nouveau serveur, modification des documents Person du NAB, changement du serveur d'administration des bases, création des répliques sur les autres membres du cluster...). Comme ces actions nécessitent un niveau d'accès que les utilisateurs n'ont pas, ces actions se feront directement depuis la base Desktop Manager Project for Consolidation, par les administrateurs Domino.

Toute la complexité d'un projet requérant des modifications à la fois côté Serveur mais également côté Client est dans la synchronisation des différentes actions. Elles doivent s'enchaîner sans provoquer de blocage. De plus, chaque utilisateur avance à son rythme. Il n'est pas question d'attendre que tout me monde ait terminé une étape pour commencer la suivante. Chaque utilisateur gère donc seul son rythme de progression au sein du Workflow. Toutes ces contraintes ont été intégrées au produit Desktop Manager Project for Consolidation.

Exemple du séquencement des actions lors un Projet : Changement de Serveur de Mail de plusieurs utilisateurs

Back to Top