Accueil - dnt91's Blog

24/10/2008

Envie de publier vos partages réseau sur vos sites SharePoint ?

Pensez au PageViewerWP…

…qui vous propose nativement cette option.

On regrettera simplement l'absence de bouttons de navigation ; alors du coup, pour naviguer utilisez le bouton précédent de IE (pour remonter d'un niveau) en plus du double clic sur le dossier (pour descendre d'un niveau et/ou exécuter une action).

Publié à 01:41 par N'TAMACK Dieudonne | Catégorie: Produits & Technologies SharePoint | Lien permanent | Envoi de cette publication par courrier électronique | Commentaires (2)

17/10/2008

[WF] Que voulez vous analyser ?

Je viens de publier un article sur le suivi de workflow à l'aide du SQLTrackingService, qui nous simplifie grandement la vie !

Dans cet article, vous y verrez comment faire du tracking sur votre workflow, mais également comment le monitorer, à l'aide de l'object SQLTrackingQuery entre autre.

L'article est téléchargeable ici.

Bonne lecture.

Publié à 01:48 par N'TAMACK Dieudonne | Catégorie: .net | Lien permanent | Envoi de cette publication par courrier électronique | Commentaires (0)

15/10/2008

Comment autoriser du script dans les pages de contenu de SharePoint.

Avez-vous déjà essayé d'exécuter du script dans une page de contenu SharePoint ?

Essayez de rajouter ce code snippet dans une zone de contenu d'une de vos pages.

<% Response.Write("Executing a script in a Content Page...."); %>

Tandis que SPDesigner ne signale pas d'erreur dans le rendu de la page,

SharePoint vous retourne cependant un beau message d'erreur on ne peut plus explicite !

Effectivement, pour des raisons de sécurité évidente, SharePoint n'autorise pas du script inline a être exécuté depuis vos pages de contenu, mais uniquement depuis les pages applicatives.

Rappelez vous que SPDesigner va être utilisé par un grand nombre de profils différents, parmi lesquels des développeurs, mais aussi des designers, et meme des utilisateurs avancés (notamment pour les fonctionnalités de WF) ; vous ne voulez surement pas que tous ces utilisateurs puissent insérer du code directement dans vos pages de contenu, qui rappelons le, sont stockées dans la BD de contenu.

Les pages applicatives, contrairement aux pages de contenu sont situés dans le système de fichier sur le serveur SharePoint, et nécessite donc un accès au serveur ou de respecter une procédure de déploiement via des features/solutions pour déployer de nouvelles pages d'application ; seuls un nombre restreint d'utilisateurs, majoritairement vos développeurs, ainsi que les administrateurs au niveau de la ferme SharePoint, vont donc pouvoir les mettre en œuvre.

Quoi qu'il en soit, il peut arriver que vous ayez besoin de contourner cette propriété, ne serait ce que sur quelques pages de vos sites, par exemple pour du test ou sur un serveur de développement, et la est l'objectif de ce billet.

Pour cela, localiser le web.config de l'application sur laquelle effectuer ces changements, puis localiser la balise

</PageParserPaths>

Rajoutez y une entrée comme ceci

</PageParserPaths>

Dans leVirtualPath, rajoutez le path vers le dossier qui contient les pages ciblées ; si vous souhaitez le faire pour tout un site, rajoutez tout simplement un /* derrière le nom du site, ici

VirtualPath="/dev/*"

Et voici donc le résultat !

N'en abusez tout de même pas trop !

Publié à 01:08 par N'TAMACK Dieudonne | Catégorie: Produits & Technologies SharePoint | Lien permanent | Envoi de cette publication par courrier électronique | Commentaires (0)

14/10/2008

[WF] Modifier un workflow en cours d’exécution.

WF fournit un certain nombre de fonctionnalités des plus surprenantes. Parmi celles-ci, celle que je vais vous présenter aujourd'hui concerne les modifications de vos workflow en cours d'exécution.

Une fois votre workflow conçu, WF, vous donne encore la possibilité de modifier ce dernier en cours d'exécution, soit depuis l'application hôte hébergeant votre workflow, soit directement depuis le workflow lui-même.

Prenons un exemple de workflow tout simple ; nous allons exécuter une boucle While 10 fois, et dans cette boucle While, nous allons y positionner une CodeActivity qui sera chargée de rajouter une activité Delay à notre workflow en cours d'exécution.

RQ : Souvenez vous qu'une activité While ne peut contenir qu'un seul élément enfant ; étant donné que nous souhaitons rajouter une activité Delay à l'intérieur de notre boucle, il nous faut donc les encapsuler (notre activité Code et notre activité Delay) dans une activité Sequence.

Notre activité While va utiliser une condition de code que nous allons appeler EvaluateCondition qui va se charger de contrôler la valeur de notre variable i et éventuellement l'incrémenter :

int i = 0;

private void EvaluateCondition(object sender, ConditionalEventArgs e) {

if (i != 10) {

i++; e.Result = true;

}

else e.Result = false;

}

Notre activité Code quant à elle va implémenter notre modification de workflow via la méthode DoChanges :

private static bool FindDelayActivity(Activity delay) {

return (delay.Name == "delayActivity1");

}

private void DoChanges(object sender, EventArgs e){

//Nos Changements seront stockés dans un objet WorkflowChange

WorkflowChanges changes = new WorkflowChanges(this);

//On clone l'arborescence du workflow et on travaille sur le clone

WhileActivity whileActivity =

(WhileActivity)changes.TransientWorkflow.Activities["whileActivity1"];

SequenceActivity sequenceActivity =

(SequenceActivity)whileActivity.Activities["sequenceActivity1"];

DelayActivity delayActivity = new DelayActivity("delayActivity1");

if (sequenceActivity.Activities.Exists(FindDelayActivity))

sequenceActivity.Activities.Remove(sequenceActivity.Activities["delayActivity1"]);

sequenceActivity.Activities.Add(delayActivity);

delayActivity.TimeoutDuration = new TimeSpan(0, 0, i);

//Une fois nos changements effectués, on lance un processus de validation

ValidationErrorCollection errorCollection = changes.Validate();

if (errorCollection.Count != 0) {

Console.WriteLine("Les modifications ne peuvent être prise en compte car il y'a {0} erreurs.\nCorrigez d'abord les erreurs suivantes : ", errorCollection.Count);

foreach (ValidationError error in errorCollection) {

Console.WriteLine("* {0}", error.ErrorText);

}

else {

//Si tout s'est déroulé correctement, on applique nos changments à l'instance en cours.

this.ApplyWorkflowChanges(changes);

Console.WriteLine("Le prochain timeout va durer {0} secondes",

delayActivity.TimeoutDuration.Seconds);

}

Et voila !

Modification effectué !

Après validation des changements, les intervalles sont de plus en plus longs entre les divers appels à la console.

Publié à 02:58 par N'TAMACK Dieudonne | Catégorie: .net | Lien permanent | Envoi de cette publication par courrier électronique | Commentaires (0)

10/10/2008

[WF] Quelles sont vos conditions ?

Je viens de publier un 2^nd article sur WF (je vous avais prévenu ;) ), ce dernier traitant des différentes activités que WF met à notre disposition pour gérer les conditions.

Vous y retrouverez l'activité IfElse,

L'activité While,

L'activité CAG,

Et enfin l'activité Replicator.

L'article quant à lui, vous le retrouverez ici.

Bonne lecture !

Publié à 02:13 par N'TAMACK Dieudonne | Lien permanent | Envoi de cette publication par courrier électronique | Commentaires (0)

09/10/2008

[WF] Quelles règles faut-il suivre ?

Je viens de publier un article sur WF (le 1^er d'une longue série).

Cet article a pour but de présenter l'activité Policy et les RuleSets, ainsi que le chainage avant dans WF.

Vous verrez notamment comment une activité Policy peut avoir différentes sorties en fonction du paramétrage, et vous comprendrez le pourquoi de ces différences.

Cette activité Policy peut générer ce résultat…

…ou celui-ci.

Vous apprendrez également à utiliser le concepteur pour contrôler ce que doit faire votre Policy.

Contrôler le chainage avant en 2 étapes.

Bonne Lecture !

Publié à 00:57 par N'TAMACK Dieudonne | Catégorie: .net | Lien permanent | Envoi de cette publication par courrier électronique | Commentaires (0)

01/10/2008

[Wss 3.0]SPNavigateur !

Avec les sites SharePoint basés sur un modèle de navigation wss 3.0 (seuls les sites ayant les fonctionnalités de publication activées ne sont pas concernés), on va pouvoir très facilement travailler au niveau de la navigation des sites ; dans ce post, nous allons voir comment travailler principalement avec 2 contrôles, la QuickLaunch et la TopNavigation.


Une Quicklaunch typique !	Une TopNavigationBar bien remplie !

Ces 2 contrôles sont très similaires, pour ne pas dire identique ; en effet, il s'agit du même contrôle, un AspMenu ; seuls les paramètres d'initialisation vont différer.

Parmi ces paramètres, on retrouve :

Paramètre	Utilisation
DataSourceID	C'est ce paramètre qui va être responsable des informations affichées ; dans le cas de la QuickLaunch, par défaut, il liste le contenu du site courant et des sous-sites, tandis que dans le cas de TopNav, il liste les sites du même niveau et du niveau inférieur.
StaticDisplayLevels	Il va être responsable de définir le nombre de niveaux hiérarchique qui seront affichés ;
MaximumDynamicDisplayLevels	Va nous permettre d'afficher des niveaux hiérarchiques supplémentaires par le biais de menu « Fly out »
Orientation	Horizontal pour la TopNavBar et vertical pour la quicklaunch !

Si nous naviguons dans les paramètres du site et que nous essayons de modifier notre TopNav afin d'y rajouter des éléments, nous constatons que nous sommes limités à une structure à plat ; il nous est impossible depuis l'interface graphique, d'y définir des niveaux hiérarchiques.

De même, si nous essayons de modifier notre quicklaunch, cette fois-ci, nous allons pouvoir y définir des éléments enfants, cependant, encore une fois, nous sommes limités, cette fois ci à 2 niveaux hiérarchiques.

La seule façon pour nous de passer outre cette limitation est de rajouter des éléments par code.

Ci-dessous, voici une méthode que vous pourriez utiliser pour ajouter des éléments de navigation à vos contrôles.

/// <summary>

/// Ajoutes des noeuds aux controles de navigation

/// </summary>

/// <param name="NavigationControl">

/// prend comme valeur "QuickLaunch" | "TopNavigationBar"

/// </param>

public static void AddNodes(string NavigationControl) {

using (SPSite siteColl = new SPSite("http://dev02:9000")) {

using (SPWeb web = siteColl.RootWeb) {

SPNavigationNodeCollection quickNodes = null;

switch (NavigationControl) {

//la QuickLaunch ou la TopNav ?

case "QuickLaunch": quickNodes = web.Navigation.QuickLaunch ; break;

case "TopNavigationBar": quickNodes = web.Navigation.TopNavigationBar; break;

default: throw new Exception("Ce contrôle n'existe pas dans la navigation Wss");

}

//définition des noeuds que nous souhaitons rajouter

SPNavigationNode coforcert = new SPNavigationNode("Coforcert Blogs", "http://blogs.coforcert.com", true);

SPNavigationNode dnt91 = new SPNavigationNode("dnt91' Blog", "http://blogs.coforcert.com/dntamack", true);

SPNavigationNode jay = new SPNavigationNode("Jay' Blog", "http://blogs.coforcert.com/jlemay", true);

SPNavigationNode navPost = new SPNavigationNode("Talking about navigation", "http://blogs.coforcert.com/dntamack/Lists/Billets/Post.aspx?ID=62", true);

SPNavigationNode subNavPost1 = new SPNavigationNode("More test 1", "http://blogs.coforcert.com/dntamack/Lists/Billets/Post.aspx?ID=62", true);

SPNavigationNode subNavPost2 = new SPNavigationNode("More test 2", "http://blogs.coforcert.com/dntamack/Lists/Billets/Post.aspx?ID=62", true);

SPNavigationNode subNavPost11 = new SPNavigationNode("More test 1 > 1", "http://blogs.coforcert.com/dntamack/Lists/Billets/Post.aspx?ID=62", true);

//construction de notre hiérarchie.

quickNodes.AddAsLast(coforcert);

coforcert.Children.AddAsFirst(jay);

coforcert.Children.AddAsFirst(dnt91);

dnt91.Children.AddAsFirst(navPost);

navPost.Children.AddAsFirst(subNavPost2);

navPost.Children.AddAsFirst(subNavPost1);

subNavPost1.Children.AddAsFirst(subNavPost11);

}

Une fois ceci fait, il va également falloir redéfinir les paramètres StaticDisplayLevels et MaximumDynamicDisplayLevels afin d'afficher nos nouveaux éléments. La méthode la plus simple de le réaliser est d'ouvrir le site avec SharePoint Designer, de localiser ensuite la masterpage default.master dans _catalogs > masterpages, puis de l'éditer après l'avoir extraite (ne pas oublier de l'archiver afin de valider les modifications !).

Pour la QuickLaunch, affectons par exemple une valeur de 1 StaticDisplayLevels à et une valeur de 7 à MaximumDynamicDisplayLevels ; voici le résultat :

Remarque : Comme vous pouvez le constater, l'affichage est très « laid » ; cependant vous pouvez améliorer les choses en y intégrant du css directement dans le contrôle AspMenu.

Pour la TopNavBar, affectons par exemple une valeur de 2 StaticDisplayLevels à et une valeur de 7 à MaximumDynamicDisplayLevels ; voici le résultat :

Et maintenant libre à vous de customiser à souhait la navigation dans vos sites Wss !

Publié à 01:20 par N'TAMACK Dieudonne | Catégorie: Produits & Technologies SharePoint | Lien permanent | Envoi de cette publication par courrier électronique | Commentaires (0)

24/09/2008

Convertir un document en ligne de commande en utilisant les document converters.

Vous connaissez tous la fonction de conversion de documents fournies avec MOSS 2007, et qui vous permet de convertir notamment vos documents word 2007, infopath ou xml directement sous forme de pages web ;

Vous savez aussi que vous pouvez développez vos propres document converters ; et bien savez vous que ces outils de conversion sont également accessibles depuis la ligne de commande ?

Si vous êtes familier du processus (nous le décrirons dans un autre article/billet…), vous savez que lorsque vous initiez le processus de conversion depuis votre page web, vous appelez en fait le service DocumentConversionLoadBalancer ; ce service, à son tour, appelle le DocumentConversionLauncher, qui fait tout un tas de choses pour finir par appeler un exécutable qui va en fait se charger de réaliser la transformation à proprement parler.

Dans le cadre d'un déploiement standard, ces exécutables, au nombre de 3 donc, se situent dans le dossier « C:\Program Files\Microsoft Office Servers\12.0\TransformApps ».

On y retrouve donc :

DocXPageConverter.exe, qui va se charger de convertir vos documents Word 2007 en page web,
InfoPathPageConverter.exe, qui va se charger de convertir vos formulaires InfoPath en page web, et
XslApplicatorConverter.exe, qui va se charger de convertir vos fichiers XML en page web.

Ces document converters utilisent des fichiers de configuration (fichiers se terminant par config.xml dans le même répertoire), qui vont spécifier les paramètres à passer au converter, et éventuellement une feuille de style (par exemple, DocX2Html.xsl) ; rien ne vous empêche de personnaliser ces fichiers (du moins si vous êtes chargés d'implémenter un document converter custom)

Pour convertir vos fichiers, il vous suffit alors d'appeler le bon exécutable et de lui fournir en entrée, au minimum, le fichiers que vous souhaitez convertir (en entrée), puis le fichier qui doit être généré (la sortie.). Par exemple, pour convertir le fichier document.docx en document.html, il vous suffit d'exécuter la commande suivante :

DocXPageConverter.exe –in « document.docx » -out « document.html »

Il pourrait également être intéressant, dans certaines circonstances, d'obtenir des informations de log sur le processus de conversion ; pour cela, il vous suffit de rajouter le paramètre –log comme ceci :

DocXPageConverter.exe –in « document.docx » -out « document.html » -log « document.log »

Dans l'hypothèse ou vous auriez développé un fichier de configuration custom, il vous faudra également renseigner ce dernier, toujours en y rajoutant un paramètre, -config, par exemple :

DocXPageConverter.exe –in « document.docx » -out « document.html » -log « document.log » -config « document.config »

J'ai joint à ce billet un dossier compressé avec un document exemple, converti, en utilisant les document converters ; vous pourrez de cette façon, analyses les différents fichiers.

Vous remarquerez sans doute (mais vous devriez déjà le savoir….) que les images n'ont pas été conservées lors de la conversion de notre document. Nous verrons donc ultérieurement comment rectifier ce problème.

Publié à 02:30 par N'TAMACK Dieudonne | Catégorie: Produits & Technologies SharePoint | Lien permanent | Envoi de cette publication par courrier électronique | Commentaires (0)

17/09/2008

Limiter le people picker à rechercher des utilisateurs uniquement dans la collection de site.

SharePoint offre un composant assez pratique dès lors que l'on doit, par exemple, rajouter des utilisateurs et/ou des groupes dans nos sites, il s'agit du people picker.

Ce composant est capable de rechercher des utilisateurs dans votre annuaire, et ceci à partir d'une chaine de caractères que vous lui spécifiez en entrée.

Cependant, il est souvent souhaitable de ne pas afficher la liste de nos utilisateurs à l'utilisateur final. Par exemple, un hébergeur de sites SharePoint ne souhaiterait pas que l'un de ses clients soit capable de visualiser les autres clients enregistrés dans l'annuaire, ou plus simple encore, dans le cas d'un extranet, vous ne souhaitez surement pas que vos clients/partenaires puissent browser votre annuaire à partir de l'un de vos sites.

Heureusement, stsadm vient (encore une fois) a notre secours ; en effet, il existe une commande nous permettant de limiter le scope du people picker à une collection de site. Pour cela, exécutez la commande suivante :

Stsadm –o setproperty –url http://sitecoll –pn « peoplepicker-onlysearchwithinsitecollection » -pv yes

Avant l'exécution de la commande, voici ce que l'on obtient :

Et après avoir ajouté uniquement les utilisateurs en jaune, puis exécuté la commande, voici le résultat de la même requête :

Pour pouvoir à nouveau browser tout l'AD, réexécutez la commande stsadm, en mettant cette fois ci la valeur à no.

Publié à 20:40 par N'TAMACK Dieudonne | Catégorie: Produits & Technologies SharePoint | Lien permanent | Envoi de cette publication par courrier électronique | Commentaires (0)

30/07/2008

[Article]A la découverte du BDC – Round 2 – Modifications majeures

Suite à la lecture, puis critique constructive de Stéphane, j'ai donc repris l'article, publié il y'a environ 1 mois, afin d'y ajouter des informations pour le moins capitale lorsque l'on travaille avec le BDC.

J'ai ce sens, j'ai donc rajouté une partie intitulée « Points supplémentaires », et traitant de :

L'intégration de plusieurs LobSystemInstances dans le même fichier ADF,
Les différentes méthodes de connexions au BDC.

Dans la partie traitant notamment des différentes méthodes de connexion au BDC, vous verrez notamment comment utiliser et configurer le service SSO, afin de passer des informations d'authentification (login/mot de passe), que l'on soit en authentification Windows ou non.

Dans la partie traitant de plusieurs LobSystemInstances, vous verrez également comment et surtout pourquoi utiliser plusieurs LobSystemInstances, et ensuite les intégrer à notre application BDC.

Enfin, il me semble également judicieux de joindre les fichiers de code (adf et sql), afin que vous puissiez directement travailler dessus J.

Ces fichiers sont disponibles ici ; attention à remplacer toutes les références afin qu'ils fonctionnent dans votre environnement ; pensez également à configurer votre service SSO.

Le nouvel article quant à lui est disponible à la même adresse, il vient donc en remplacement du précédent.

SPEnjoy !

Publié à 23:33 par N'TAMACK Dieudonne | Catégorie: Produits & Technologies SharePoint | Lien permanent | Envoi de cette publication par courrier électronique | Commentaires (0)

Flux RSS