Partager une bibliothèque LotusScript entre des bases de données

Question

Est-il possible de créer une bibliothèque LotusScript dans une base de données, puis d'y accéder à partir d'une autre base de données?

Sans simplement copier la bibliothèque dans chaque base de données qui doit l'utiliser.

Ce que je voudrais réaliser est un emplacement unique où je peux mettre à jour la bibliothèque et ne pas devoir la copier manuellement dans chaque base de données qui l'utilise. Je ne peux pas utiliser un modèle de conception car les bases de données qui utilisent cette bibliothèque de scripts utilisent toutes des modèles de conception différents.

Je suppose qu'une autre solution consisterait à créer un agent pour copier la bibliothèque sur toutes les bases de données à chaque mise à jour. Donc, si quelqu'un a déjà fait quelque chose comme ça auparavant, j'aimerais aussi en parler ici.

Answer 1

L'héritage de conception dans Lotus Notes n'est pas uniquement au niveau de la base de données: des éléments de conception individuels (tels que votre bibliothèque de scripts) peuvent être hérités explicitement d'un modèle différent. Voir Linking individual design elements to a template. Avec l'héritage configuré comme ceci, la tâche designer sur le serveur Domino mettra automatiquement à jour l'élément de conception. Pour que cela fonctionne, les modèles doivent être répliqués sur le même serveur.

Vous souhaiterez peut-être désactiver cet héritage lorsque vous publiez votre modèle afin d'éviter de mauvaises surprises dans l'environnement de production. J'ai créé une solution pour cela il y a un certain temps: Remove Lotus Notes design element inheritance programatically.

Answer 2

Anders a très bien répondu à la question. Comme Anders l'a déjà dit, Domino, malheureusement, ne peut pas partager des bibliothèques de code entre les bases de données. Tout le code est autonome, ce qui est dans ce scénario une limitation.

Copier l'agent dans toutes les bases de données pour lesquelles vous souhaitez l'utiliser, puis utiliser l'héritage de conception est un moyen rapide et facile de distribuer l'agent. Une autre idée consiste à avoir une seule base de données qui sert de référentiel d'agents, donc si vous avez besoin de réutiliser le même agent encore et encore, son design est toujours dans une base de données, mais vous devrez le concevoir de sorte qu'il puisse effectuer des opérations sur toute la base de données que vous devez mettre à jour.

Effectivement, en utilisant chaque base de données en tant que source de données seulement, et le ou les agents pertinents opérant à partir d'un emplacement. Cela nécessitera un peu plus de travail qui vous permettra de définir des documents de configuration supplémentaires que les agents utiliseront pour identifier les bases de données sur lesquelles l'agent doit s'exécuter.

Les avantages de cette approche sont:

• Vous n'êtes pas obligé de composer avec l'héritage de la conception. Il peut être compliqué à grande échelle lorsque vous avez des structures de conception/script complexes, vous devrez peut-être acheter des outils tiers pour vous aider à le faire.

• Vous pouvez réellement contrôler quelles bases de données sont mises à jour via une série de documents de configuration de manière centralisée avec un champ "actif/inactif" qui marque la base de données pour mise à jour. Plutôt que de «toucher» directement les agents, vous devez vous salir les mains en activant/désactivant l'agent. Dans certains environnements d'entreprise étroitement contrôlés, vous devez demander à l'administrateur Notes de le faire pour vous.

• Vous pouvez coder l'agent afin qu'il signale l'activité dans vos propres documents de journal personnalisés lorsqu'il s'exécute sur chaque base de données et qu'il stocke de manière centralisée.

espère que cela vous donne quelques options ...