2014-07-23 4 views
-1

I ci-dessous ont des requêtes dans DFC et WDK: -requêtes dans DFC et WDK dans documentum

1) est TBO objets de base de type et de type d'objet spécifique dans documentum. SBO est pour une utilisation mondiale. Peut-on faire un code SBO pour agir comme un TBO, si oui alors comment? Comment puis-je rendre mon SBO spécifique pour un type d'objet particulier.

2) Comment puis-je appeler une classe de comportement à partir d'un fichier action.xml en WDK? Si je ne veux pas utiliser le composant dans ma personnalisation WDK. Tous les exemples pour soutenir ces requêtes seront appréciables.

3) Pourquoi la portée est-elle requise en WDK? Quel est son rôle et sa portée peut l'emporter sur les privilèges en termes de hiérarchie. Si un utilisateur se voit attribuer une portée pour un composant dans WDK, il ne dispose pas de privilèges suffisants pour y accéder dans documentum. L'utilisateur peut-il toujours accéder au composant particulier?

4) Les valeurs de sécurité de dossier peuvent-elles remplacer les autorisations de niveau d'objet de base? Quel sera le premier niveau de sécurité du dossier ou des autorisations ou privilèges de base?

Merci! Deb

+0

S'il vous plaît jeter un oeil à http://stackoverflow.com/tour sur la façon de poser des questions pratiques et détaillées, et s'il vous plaît poser une question par question :) – eivamu

+0

@eivamu ok man !! – ScriptLearner

Répondre

0

Ce n'est pas genre de question pour SO, au moins dans la plupart des parties. Cependant:

1.) TBO et SBO sont juste des approches architecturales pour des besoins spécifiques. Si vous avez un code spécifique que vous souhaitez exécuter pour des objets de type spécifique et pas seulement pour des objets de sous-types, vous devez modifier le modèle objet pour appliquer une logique à tous les objets de la hiérarchie de types. Ce n'est pas un problème avec le modèle objet/type Documentum.

Par exemple: Vous avez custom_document comme sous-type de dm_document et custom_child1_document et custom_child2_document, les deux sous-types de custom_document. Vous avez défini TBO sur custom_child2_document. Vous ne voulez pas appliquer SBO pour que la logique personnalisée soit disponible sous dm_document. Ajoutez simplement TBO pour taper custom_documentm et vous aurez votre logique pour tous les types sous dm_document.

2.) Vous ne pouvez pas appeler la classe de comportement sans appeler le composant. Si vous avez un code spécifique que vous voulez exécuter à partir d'autres endroits, isolez-le à un autre endroit et exécutez-le à volonté.

3.) Vous n'avez pas besoin de spécifier la portée de votre configuration WDK. Cependant, une fois que vous apprendrez WDK dans les détails, vous le trouverez utile.

4.) Le dossier est un objet. Vous devez savoir que lorsque vous accédez à des objets via des dossiers, vous avez besoin d'une autorisation d'accès pour le dossier et le document liés à ce dossier (Read le niveau est suffisant). Vous n'avez besoin que d'autorisations sur l'ID d'objet pour accéder à cet objet à partir de DQL par exemple. Les autorisations de base et étendues sont destinées à être utilisées dans des cas spécifiques, vous n'avez pas besoin d'autorisations étendues pour lire le contenu de l'objet si vous avez Lire autorisation de base sur votre objet. Vous devez cependant Relier autorisation de base + Exécuter la procédure Permsission étendue sur le workflow cible pour démarrer le workflow avec cet objet spécifique en tant que pièce jointe/package. Des règles différentes vont quand vous voulez ajouter un objet dans un dossier spécifique. Mais c'est une longue histoire.

En ce qui concerne la sécurité du dossier - vérifier l'article this.

Questions connexes