Edgar Maucourant - Expert / Formateur SharePoint

Aller au contenu | Aller au menu | Aller à la recherche

Tag - SharePoint 2010

Fil des billets - Fil des commentaires

dimanche 11 septembre 2011

Ajouter une PJ à un élément de liste par modèle objet client dans SharePoint 2010

Bonjour à tous,

Ceux qui l'ont déjà expérimenté le savent bien, il y a des choses que le modèle objet client de SharePoint 2010 sait faire à merveille et d'autres qui semblent avoir complètement été oubliées, y compris les plus basiques....

Comme vous l'aurez compris au titre de ce post, l'une d'elles est la possibilité d'ajouter une pièce jointe à un élément de liste. Il semble que Microsoft n'est pas envisagé ce cas, ou que pour des raisons obscures ils ne l'aient pas implémenté.

Qu'à cela ne tienne, voici deux méthodes pour les ajouter, une n'est utilisable que si vous avez déjà au moins une pièce jointe attachée à votre élément, l'autre est utilisable tout le temps mais fait référence aux WebServices de SharePoint...


Première méthode :

Cette méthode ne fonctionne que si le répertoire contenant les pièces jointes de l'élément existe déjà, sinon vous recevrez une erreur "409 : Erreur de conflit"

Vous remarquerez au passage que Microsoft n'a toujours pas amélioré son système de message d'erreur. D'un point de vue développeur il ne s'agit pas d'un conflit mais de l'absence du répertoire pour stocker la pièce jointe.

Le seul moyen que ce répertoire existe est que vous ayez ajouté une ou plusieurs pièces jointes à votre élément, soit par l'interface utilisateur, soit par le deuxième méthode ci-dessous.

Ne cherchez pas à créer ce répertoire, j'ai testé toutes les méthodes que j'ai pu trouvé sur Internet et aucune ne fonctionne pour créer un sous-répertoire dans le répertoire "Attachments" de la liste. Il semble que ce soit un comportement confirmé par Microsoft...


string uploadLocation = string.Format("{0}/Lists/{1}/Attachments/{2}/{3}", webName, listName, itemId, Path.GetFileName(fileName));
Microsoft.SharePoint.Client.File.SaveBinaryDirect(clientContext, uploadLocation, fileStream, true);


Dans ce code :

  • webName est le nom (url) du site Web,
  • listName est le nom (url) de la liste,
  • itemId est l'Id (int) de l"élément sur lequel ajouter la pièce jointe,
  • filename est le nom de la pièce jointe,
  • clientContext représente le context client pour le site web contenant la liste,
  • enfin fileStream correspond au contenu du fichier représenté sous forme de stream.

Deuxième méthode :

Cette méthode fonctionne à tous les coups mais nécessite de faire une référence web au webservice de liste de SharePoint.


ListsWebService.Lists listsWS = new ListsWebService.Lists();
listsWS.UseDefaultCredentials = true;
byte[] buffer = new byte[fileStream.Length];
fileStream.Read(buffer,0,(int)fileStream.Length);
fileStream.Close();
listsWS.AddAttachment(listName, itemId.ToString(), fileName, buffer);

Dans ce code :

  • ListsWebService et le nom de la classe proxy vers le webservice de listes de SharePoint (http://urldevotresite/_vti_bin/lists.asmx),
  • fileStream représente le contenu de la pièce jointe sous forme de Stream,
  • listName est le nom de la liste,
  • enfin itemId correspond à l'ID (int) du listitem auquel ajouter la pièce jointe.

Bonus :

Aller parce que je suis sympa (les fleurs sont pas chers en ce moment), je vous donne la méthode complète pour ajouter l'élément de liste et la première pièce jointe. La petite difficulté vient du fait que lors de l'ajout de l'élément à la liste, l'ID de celui n'est pas connu et qu'il est nécessaire de le recharger ensuite pour le connaître.


using (ClientContext clientContext = new ClientContext(siteUrl))
{
   var list = clientContext.Web.Lists.GetByTitle(listName);
   clientContext.Load(list);
   ListItemCreationInformation itemInformation = null;
   ListItem listItem = list.AddItem(itemInformation);
   listItem["Nom"] = Nom;
   listItem["Prenom"] = Prenom;
   listItem["email"] = Email;
   listItem.Update();
   clientContext.ExecuteQuery();
   CamlQuery query = new CamlQuery();
   query.ViewXml = @"
         <Query>
            <Where>
               <And>
                  <And>
                     <Eq>
                        <FieldRef name="Nom" />
                        <Value type="Text">" + Nom + @"</Value>
                     </Eq>
                     <Eq>
                        <FieldRef name="Prenom" />
                        <Value type="Text">" + Prenom + @"</Value>
                     </Eq>
                  </And>
                  <Eq>
                     <FieldRef name="email" />
                     <Value type="Text">" + Email+ @"</Value>
                  </Eq>
               </And>
            </Where>
         </Query>
      </View>";
   var refreshedItem = list.GetItems(query);
   clientContext.Load(refreshedItem);
   clientContext.ExecuteQuery();
   if (refreshedItem.Count != 1)
   {
      // TODO Manage Error
   }
   if (!string.IsNullOrEmpty(fileName) && fileStream.Length > 0)
      {
         ListsWebService.Lists listsWS = new ListsWebService.Lists();
         listsWS.UseDefaultCredentials = true;
         byte[] buffer = new byte[fileStream.Length];
         fileStream.Read(buf,0,(int)fileStream.Length);
         fileStream.Close();
         listsWS.AddAttachment(listName, refreshedItem[0].Id.ToString(), fileName, buffer);
      }
}


Bon code à tous ! Edgar

dimanche 7 août 2011

SharePoint 2007&2010 : Limite de taille de fichier qui ne fonctionne pas en mode explorateur ?

Bonjour à tous,

Vous est-il déjà arrivé de sombrer lentement dans la folie à l'utilisation de SharePoint ? (Si vous répondez non c'est que vous ne l'utilisez pas depuis assez longtemps :p).

Cela pourrait bien vous arriver si un jour vous modifier la taille maximum d'un fichier pouvant être téléchargé dans SharePoint (au niveau de la Web Application) mais que ce comportement ne semble pas être pris en compte lorsque vous travaillez en mode Explorateur... Après avoir vérifié la configuration de votre SharePoint maintes fois, vous commencez à vous demandez si la vie vaut encore la peine d'être vécue... Quand tout à coup, vous avez l'éclair de génie (ouais bon il aura fallut du temps mais saluons tout de même votre pugnacité) : Si le problème ne vient pas du serveur c'est qu'il vient du client !

Eurêka !

En effet, le WebClient notamment utilisé par l'explorateur client en mode WebDav limite par défaut les fichiers transférable à environ 50 000 000 Bytes soit approximativement 47 Mo. Pour modifier cela il faut depuis l'ordinateur utilisant le mode explorateur (et non le serveur), modifier une clé de registre pour augmenter la taille maximum supportée. Pour cela :

  • Ouvrir Regedit
  • Aller dans le dossier : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WebClient\Parameters
  • Faire un clic droit sur le fichier : FileSizeLimitInBytes
  • Passer en mode décimal et saisir votre valeur en octects ! (Valeur Max : 4294967295 soit 4 Go).
  • Valider votre saisie et fermer Regedit
  • Redémarrer le service WebClient (en utilisant la console de services Windows)
  • Fermer puis réouvrir tout explorateur Windows

Et voilà vous pouvez à présent transférer des fichiers de la taille maximum indiquée ou de celle fixée dans SharePoint (suivant celle qui est la plus petite).

Bon code à tous

Edgar

samedi 28 mai 2011

SharePoint 2010 & DPM 2010 : Pourquoi je ne vois pas SP dans la console ?

Bonjour à tous,

Tout d'abord,

DPM c'est quoi ? (sautez ce passage si vous savez ;))

Quiconque souhaite sauvegarder son système SharePoint doit nécessaire passer par un outil externe, les possibilités de sauvegarde intégrées à l'outil n'étant vraiment pas assez fiables. Il existe plusieurs outils intéressants et parmi ceux-là Microsoft fournit même son propre outil : Data Protection Manager dit DPM. Ce n'est pas un outil de sauvegarde dédiée à SharePoint mais plutôt une solution de sauvegarde générale capable de sauvegarder des serveurs, des postes clients, des VMs Hyper-V, Exchange, SQL Server, et SharePoint (entre autres). Nous en somme à la version 2010, et c'est de cet outil et d'un problème de configuration dont je vais vous parler à présent.

Quel est le problème ?

Lorsque vous installez le client DPM sur un serveur SharePoint afin de procéder à sa sauvegarde, vous avez un certain nombre d'étapes à réaliser (je ne vais pas les donner ici, de nombreux tutoriaux sont disponibles). Lorsque tout se passe bien, vous devez apercevoir dans la console DPM, sur au moins un des serveurs, un onglet SharePoint vous permettant de sauvegarder celui-ci. Cependant il arrive que cet onglet n'apparaisse pas, vous empêchant ainsi de pouvoir sauvegarder SharePoint. Le plupart du temps il s'agit du service VSS (Virtual Shadow Service) qui n'est pas complètement opérationnel sur le serveur à sauvegarder (bien que souvent démarré).

Quelles sont les causes ?

Les causes peuvent être multiples mais voici l'une des plus vicieuses que j'ai vue (car totalement non documentée). Parmi les services de SharePoint Server (donc pas foundation ni wss) il existe deux services de recherche, le service de recherche SharePoint et le service de recherche d'aide SharePoint (appelée également recherche SharePoint Foundation ou WSS). La recherche d'aide comme son nom l'indique n'est utilisée que dans la fenêtre d'aide de SharePoint. Pour toutes les autres recherches (sur SharePoint Server) c'est le service de recherche SharePoint qui est utilisé. Cette recherche d'aide peut être démarrée sur plus d'un serveur, et c'est cela qui pose problème pour DPM. Visiblement si vous démarrez le service de recherche d'aide sur plus d'un serveur, le service VSS de SharePoint se mélange les pinceaux et ne s'enregistre pas en tant que "VSS Writer" (nécessaire pour que DPM puisse savoir quel type de sauvegarde sont possibles sur ce serveur). Bien évidemment aucun message d'erreur, ni aucune indication ne vous ai donné, le service VSS de SharePoint démarre sans problème mais il ne s'enregistre pas, ce qui implique que DPM ne le "voit" pas et n'affiche pas la possibilité de sauvegarder SharePoint.

A titre d'information voici les autres causes possibles que je ne détaille pas car on trouve sur internet plusieurs articles à leur sujet :

  • Absence de configuration du service SharePoint (ConfigureSharePoint.exe -EnableSharePointProtection),
  • Service SharePoint VSS non enregistré correctement (stsadm -o enablewsswriter, atention c'est bien écrit wss et non vss),
  • Service SharePoint VSS Writer non démarré,
  • Compte exécutant VSS incorrect (défini par ConfigureSharePoint.exe).
Il en existe sûrement d'autres mais celles-ci sont les plus communes.

Comment résoudre le problème décrit ?

La résolution du problème est simple : n'activez le service de recherche d'aide que sur un seul serveur de la ferme, idéalement le serveur d'application qui héberge l'admin centrale comme c'est le cas dans la plupart des fermes multi-serveurs. Pensez à redémarrer le service SharePoint VSS Writer après cette modif et tout devrait rentrer dans l'ordre. Le service de recherche d'aide étant en général peu sollicité dans une ferme, l'avoir sur un seul serveur ne devrait pas être (trop) gênant.

Je n'ai testé cette manip que sur un environnement SharePoint 2010, je ne sais pas si le problème était le même avec MOSS 2007, mais il est probable que oui, si quelqu'un à l'info je suis preneur ;)

Bon code à tous,
Edgar

mercredi 11 mai 2011

SharePoint 2010 et Windows Server 2008 R2 SP1 : Attention [MAJ 28/05/2011 : Pb résolu]

Bonjour,

Mise à jour du 28/05/2011 : Problème résolu, Cf. en bas de l'article pour le détail et la résolution


Comme vous l'avez peut-être remarqué je n'ai plus bloggué depuis quelques temps, ce ne sont pourtant pas les sujets qui manquent mais le temps pour les traiter avec qualité (enfin je l'espère ;). Le problème ci-dessous est assez important pour que je le poste malgré ma faible investigation sur la résolution possible.

Chez un des mes clients suite à l'installation du SP1 de Windows Server 2008 R2, sur un environnement multiserveurs (2 frontaux virtualisés), nous avons constaté des problèmes qui sont résumés ci-dessous :

  • Le service NLB ne fonctionne plus (pb déjà identifié par les équipe de TMG, mais qui visiblement s'applique aussi sans ce produit). Le Workaround est d'arrêter puis redémarrer le service sur chaque frontal (un reboot du serveur ne corrige pas le problème) : "net stop wlbs" puis "net start wlbs" (attention de ne pas faire cette manip en Terminal server sous peine de se couper une patte et de ne plus pouvoir accéder à la machine...)
  • La réplication des index du serveur d'indexation vers les serveurs de requête (query) ne s'opére plus, en cause un décryptage des tickets Kerberos qui foire et qui empêche l'authentification entre les services SharePoint. Le Workaround a été d'installer le rôle de requête sur le serveur d'indexation et de couper le rôle de requête sur tous les autres serveurs.
  • Excel Services ne répond plus entre machine, problème visiblement lié lui aussi à l'authentification Kerberos entre service (WCF). Le workaround a été de couper Excel Services sur l'un des noeuds et de ne le laisser que sur un seul (pourquoi cela fonctionne avec un seul noeud, reste un mystère).

Ma recommandation est donc de ne pas installer le SP1 de Windows Server 2008 R2 sur un environnement SharePoint 2010 pour le moment tant que ces points ne seront pas réglés. Je n'ai pas testé sur d'autres fermes, ni sur un environnement MOSS 2007. Il est cependant problable que le problème NLB soit le même pour les autres problème rien n'est sûr. Nous avons ouvert un call chez MS pour élucider ces problèmes, et vérifier que le SP1 est bien en cause. Si je trouve des meilleurs workarounds ou que le problème peut-être résolu je vous tiendrai au courant.

Mise à jour du 28/05/2011 : Le problème venait d'une mauvaise configuration des cartes réseaux sur la partie IPV6 qui ne posait aucun problème avant le SP1 mais qui suite à l'installation de celui-ci provoquait des erreurs de déchiffrement des ticket Kerberos. Ces problèmes de ticket Kerberos étaient à l'origine du problème de communication entre les noeuds et donc entre les différents service SharePoint.

Résolution : nous avions pensé que la couche IPv6 des cartes réseaux serait désactivée en décochant ce protocole dans les propriétés de la carte réseau, mais ce n'était pas suffisant et a amené la configuration réseau dans un mode non supporté par MS. Même si vous ne souhaitez pas faire d'IPv6 il est préférable de laisser ce protocole actif car de nombreux services Windows reposent sur celui-ci en priorité. Notre action a donc été de recocher le protocole IPv6 sur toutes les cartes réseaux et de forcer Windows à utiliser IPv4 en priorité en enregistrant la clé de registre "DisabledComponents" d'IPv6 à la valeur 0x20 (plus d'infos là : http://support.microsoft.com/kb/929852/en-US, attention l'article anglais contient plus de "fix-it" que sa traduction française automatique.). Après un redémarrage, nous avons constasté que tous les services fonctionnaient correctement, et nous avons pu répartir à nouveau nos services SharePoint entre les différents serveurs de la ferme.

J'espère que ceci vous permettra d'éviter une rupture de service sur votre infrastructure, ce problème nous a montré qu'il est toujours important de bien se renseigner sur l'action d'une case à cocher qui peut paraître anodine mais à complètement mis notre ferme K.O., IPv6 : 1, Edgar : 0 ;)

Bon code à tous,
Edgar

jeudi 4 février 2010

SP2010 : Assistant de configuration ? Pas besoin j'suis un pro ! A moins que...

Bonjour à tous,

Si vous êtes comme moi et que vous aimez bien vous passer d'assistant pour mettre en place les choses vous-même, vous serez sûrement confronté à un problème avec l'installation de SharePoint Server 2010.

En effet une fois l'installation de SharePoint terminée (elle ressemble comme deux gouttes d'eau à celle de MOSS 2007), il reste encore à paramètrer la ferme, et là c'est plus du tout pareil qu'en version 2007. Heureusement Microsoft a mis en place un nouvel assistant (rien à voir avec l'assistant de configuration lancé pour créer la ferme qui existe toujours d'ailleurs). Cet assistant vous aidera à paramétrer et déployer les services d'applications dans votre ferme.

Sauf que moi je voulais les déployer à la main pour bien comprendre chacun d'eux et leur dépendance, et là c'est le drame... (ouais j'aime bien l"effet mélodramatique pour encourager à lire la suite...)

Lire la suite...