Archives des SharePoint - Page 5 sur 5

MOSS 2007 : Error logs 6482 7076 et 6398 toutes les minutes.

Solution naturelle à un bug surnaturel.
Comment réussir à stopper net ces trois erreurs récurrentes du minuteur : 6482, 7076 et 6398 ?
Pour ma part, j’avais toute les minutes ces erreurs de générées dans le journal des événements.
Les messages ressemblaient à ça : “ Old format or invalid type library ” ("Ancien format ou bibliothèque de types non valide") ou “ Not enough storage ” ("Espace insuffisant pour traiter cette commande").
Pour autant, ma ferme SharePoint fonctionnait normalement.
Solution :Installer les deux KB suivants disponibles via ce lien :

KB923028
KB918642

Ces vilaines traces devraient disparaitre… MSDN ? Lave plus blanc que blanc.

MOSS 2007 : Problème de backup dans une topologie 3-tiers

Dans une topologie 3-tiers (1 serveur de BDD, 1 serveur d’admin WSS, 1 serveur web frontal), il est important de respecter certaines proconisations pour lancer un stsadm -o backup :

Utiliser un chemin UNC (\SERVERNAMEetc.) pour décrire le chemin physique de stockage du fichier de backup. En effet, le serveur de BDD va écrire dans ce répertoire. Etant donné qu’il est « distant », il faut lui donner un chemin d’accès adéquat.
Donner les droits d’écriture pour ce répertoire au compte de service de SQL Server.

MOSS 2007 : Comment modifier une liste SharePoint via un WebService sous SSIS ?

Tutoriel.

SOMMAIRE

1. INTRODUCTION
2. VERIFIER L’EXISTENCE DU WEB SERVICE
3. CREER LA DLL DE PROXY
4. EXEMPLE DE PROJET SOUS SSIS
1. INTRODUCTION

1.1. Description

Voici une manière rapide de mettre à jour des métadonnées d’éléments d’une liste SharePoint grâce aux web services natifs de l’application. Ces web services seront appelés à partir de Microsoft SQL Server 2005 Integration Services (SSIS).

1.2. Pré-requis

Les logiciels suivants doivent être installés sur la machine :
2. VERIFIER L’EXISTENCE DU WEB SERVICE

Sous IE, taper l’URL suivante : http://serveur:port/_vti_bin/lists.asmx

» serveur:port » étant un site SharePoint dans lequel vous souhaitez attaquer les listes.

L’écran suivant devrait s’afficher avec la liste complète des opérations que propose le Web Service :

3. CREER LA DLL DE PROXY

Une DLL de proxy fournit toutes les classes qui permettent de communiquer avec le Web Service. Il serait possible de développer soi-même ces classes, mais ce serait inutile, car la création de cette DLL est très simple. Elle nous permet de faire abstraction, entre autres, de l’utilisation du protocole SOAP et du formatage des requêtes à envoyer au serveur.

Une DLL de proxy = Un Web Service.

NB : SSIS est capable de communiquer directement avec des Web Services grâce à la » Web Service Task « . Cependant, le Web Service List.asmx contient des paramètres de type complex qui ne sont pas gérés par SSIS. D’où la création de cette DLL qui sera fournie à SSIS.

3.1. Création de la DLL

Ouvrir Visual Studio 2005, même une version Express gratuite suffit. Ici nous utiliserons Visual C# 2005 Express Edition.

Ajout d’une référence vers le Web Service :
Avant de compiler notre solution, il va falloir signer l’assembly :
La DLL est créée !

3.2. Enregistrement dans le GAC
Copier la DLL, présente dans » Repertoire_de_la_solution / MOSSWebService / bin / Release / « , vers le répertoire » C: WINDOWS Microsoft.NET Framework v2.0.xxxxx « .
Ouvrir une fenêtre de commandes MSDOS.
Aller dans le répertoire » C:WINDOWSMicrosoft.NETFrameworkv2.0.xxxxx « .
Taper » gacutil –i MOSSWebService.dll » et faites ENTREE.
L’assembly et ajoutée dans le cache et est disponible pour SSIS.
NB : Certains diront qu’il suffit de faire un glisser-déposer de la DLL pour la placer dans le GAC. A cela je réponds : « C’est en faisant n’importe quoi qu’on devient n’importe qui » (L.Briand).

4. EXEMPLE DE PROJET SOUS SSIS
Lancer SQL Server Business Intelligence Development Studio, et faire » Fichier > Nouveau > Projet » puis sélectionner » Project Integration Service » et faire OK.
Faire un » Glisser – déposer » d’une tâche de script de la boite à outils vers la page Flux de contrôle :
Double-cliquer sur la tache de script.
Une fenêtre d’édition de la tâche s’ouvre. Cliquer sur » Script » à gauche, puis sur le bouton » Créer un script » en bas :
Une nouvelle fenêtre Visual Studio s’ouvre, avec du code source prédéfini.
Dans l’ » explorateur de projet » (ici à gauche), faire un clic-droit sur » Références » et cliquer sur » Ajouter une référence » :
Choisir la nouvelle DLL fraichement créée (MOSSWebService.dll), faire » Ajouter » puis » OK « .
Faire de même pour les deux DLL suivantes :
Modifier le code comme suit :

Public Sub Main()
        Try
            ’’’ URL du Web Service
            Dim sUrl As String = "http://URL/_vti_bin/lists.asmx"
            ’’’ Objet représentant le Web Service
            Dim oListWS As New Lists
            oListWS.Credentials = System.Net.CredentialCache.DefaultCredentials
            oListWS.Url = sUrl
            ’’’ Génération de la requête CAML de mise à jour de la liste
            Dim xDoc As New System.Xml.XmlDocument
            Dim xBatch As System.Xml.XmlElement = xDoc.CreateElement("Batch")
            xBatch.SetAttribute("OnError", "Return")
            ’’’ Corps de la requête CAML : Cette requête va simplement changer la metadonnée "Title"
            ’’’ de l’item d’identifiant 20.
            Dim sBatch As String = ""
            sBatch += "20"
            sBatch += "Nouveau Titre"
            sBatch += ""
            xBatch.InnerXml = sBatch
            ’’’ Lancement de la fonction de MAJ de la liste "Bibliothèque des sinistres".
            Dim xReturn As System.Xml.XmlNode = oListWS.UpdateListItems("Bibliothèque des sinistres", xBatch)
            ’’’ Affichage de la réponse renvoyée par le serveur.
            Dts.Events.FireInformation(1, "", xReturn.InnerXml, "", 0, False)
            ’’’ La tâche s’est bien passée
            Dts.TaskResult = Dts.Results.Success
        Catch Ex As Exception
            ’’’ La tâche a échoué
            Dts.TaskResult = Dts.Results.Failure
        End Try
	End Sub

Faire CTRL + S, et fermer la fenêtre Visual Studio.
De retour sur le SSIS, faire F5 pour lancer le package.
L’item d’identifiant 20 (s’il existe) aura son titre à » Nouveau Titre » (à vérifier sous le site SharePoint).

MOSS 2007 : Problème de MAJ de workflow et cache du Designer

Les modifications apportées aux workflows dans le designer ne sont pas pris en compte !
Voici la manipulation à effectuer, inspirée de cet article de MSDN.

Fermer de Designer
Recherche le répertoire %System Drive%Documents and Settings\%user%Local SettingsApplication DataMicrosoftWebSiteCache.
Supprimer le répertoire dont le nom correspond au site concerné.
Les modifications apportées au designer seront prises en compte.

La meilleure chose à faire serait de créer un batch qui supprime ces fichiers à la demande…

MOSS 2007 : Les liens relatifs vers les bibliothèques de connexions de données situées sur des collections de sites SharePoint différentes ne sont pas pris en charge.

Cette erreur peut arriver lorsque vous publiez un formulaire Infopath même si vos connexions de données viennent de la même bibliothèque !
Cette erreur n’a alors aucune raison d’être, vu que toutes vos connexions font bien partie de la même collection de site.
Que se passe-t-il ? Voici le problème que j’ai rencontré, et qui arrive assez fréquemment :
Editez le fichier manifest.xsf avec le bloc note.
Allez sur les lignes où sont déclarées toutes les connexions (xsf2:adoAdapterExtension ou xsf2:webServiceAdapterExtension).
Maintenant comparez bien les attributs siteCollection… la moindre majuscule de différence, et l’erreur surgira !
Il faut bien que toutes les attributs siteCollection des balises xsf2:connectoid soient parfaitement identiques, à la majuscule près !

MOSS 2007 : Problème de style en mode anonyme.

Il peut arriver que certains fichiers (images, feuilles CSS) soient inaccessibles en mode anonyme, notamment dans les sous-sites d’une collection de sites SharePoint.
La solution est simple : tous les fichiers inhérents au style que vous avez créés doivent être placés dans le répertoire _catalogs/masterpage.
Ainsi, tous vos fichiers seront accessibles, même via une connexion anonyme. De plus, cela permet de centraliser vos sources autour de votre nouvelle masterpage.

MOSS 2007 : Optimiser le chargement d’un formulaire Infopath.

SOMMAIRE

1. INTRODUCTION
2. DEUX TYPES DE TEMPS DE CHARGEMENT : COTE SERVEUR ET COTE CLIENT
3. ENVISAGER DES CHARGEMENTS EN » DUR » VIA DES LISTES XML
- 3.1. Cas d’utilisation
- 3.2. Comment faire ?
- 3.3. Bilan
4. LE MEILLEUR COMPROMIS : UTILISER DES LISTES SHAREPOINT
- 4.1. Cas d’utilisation
- 4.2. Comment faire ?
- 4.3. Bilan
5. SCINDER EN DIFFERENTES VUES
6. CONNEXIONS DIRECTES A LA BDD VIA DES FICHIERS UDCX EN CAS D’UTILISATION INTENSIVE DE SERVICES WEB
- 6.1. Cas d’utilisation
- 6.2. Comment faire ?
- 6.3. Bilan
7. MESURE DES GAINS
8. BILAN

1. INTRODUCTION

En cas de lenteur de chargement d’un formulaire Infopath Form Services client léger (affichage sur navigateur web), une première piste à étudier serait les connexions de données. En effet, le temps de chargement des paramètres de connexion peuvent être longs, surtout si un grand nombre de données est rapatrié sur le client pour alimenter des listes déroulantes.

2. DEUX TYPES DE TEMPS DE CHARGEMENT : COTE SERVEUR ET COTE CLIENT.

Côté serveur, les traitements qui mettront le plus de temps sont :
– Toute la logique programmée dans le Form_Load du formulaire dans le code managé.
– La connexion aux sources de données et la mise en forme des données à envoyer au client.
Côté client, surtout sous IE6, ce qui mettra le plus de temps est l’ingestion des données servant à alimenter les listes déroulantes. Plus ces données sont nombreuses, plus le client subira un temps » bloqué » où le CPU se caractérise par un taux d’occupation à 100%.
C’est donc sur ces deux aspects qu’il faudra jouer pour limiter le temps global de chargement d’un formulaire.

3. ENVISAGER DES CHARGEMENTS EN » DUR » VIA DES LISTES XML.

Le plus gros gain de temps à gagner est en utilisant des fichiers XML qui alimentent les listes déroulantes.

3.1. Cas d’utilisation

Pour des connexions secondaires alimentant des listes déroulantes dont le contenu ne change pas souvent, voire jamais.
NB : On aurait pu entrer manuellement ces données dans la liste, mais l’utilisation de listes XML permet une maintenance plus simple (on n’aura pas a retoucher le formulaire, mais seulement les fichiers XML avant de republier).

3.2. Comment faire ?

Le fichier XML peut simplement être de la forme :


mon_id
ma_valeur
�

Pour déclarer le fichier XML en tant que source de données, il suffit de faire :

Outils > Connexions de données > Ajouter.
Créer une connexion dans > Réception des données.
» Suivant « .
Choisir » Document XML « .
» Suivant « .
Donner le chemin vers le fichier XML créé.
» Suivant « .
Sélectionner » Inclure les données� « .
» Suivant « .
» Terminer « .

La source de données est utilisable comme n’importe quelle autre. En tant que connexion secondaire, voici ce que cela donnerait pour une liste déroulante :

3.3. Bilan

Avantage : Le plus gros gain de temps de chargement côté serveur.
Inconvénients : Nécessité de republier le formulaire si la liste change. Stockage et mise à jour des fichiers XML via des lots DTS ou des moulinettes.

4. LE MEILLEUR COMPROMIS : UTILISER DES LISTES SHAREPOINT

Rapatrier des données à partir de liste SharePoint constitue le meilleur gain de temps côté serveur ET côté client.

4.1. Cas d’utilisation

Pour des connexions de données secondaires utilisées pour les listes déroulantes.

4.2. Comment faire ?

Considérons que les listes SharePoint existent, et qu’elles possèdent simplement deux colonnes : » _id » et » _value » :
Pour créer une connexion de données secondaire liée à cette liste sous InfoPath, il faut :

Cliquer sur Outils > Connexions de données > Ajouter.
Créer une connexion dans > Réception des données.
Faire » Suivant « .
Choisir » Bibliothèque ou liste SharePoint « .
Faire » Suivant « .
Donner l’URL du site SharePoint.
Faire » Suivant « .
Choisir la liste SharePoint correspondante (ici, ce serait » FE_SITE « ).
Faire » Suivant « .
Choisir les colonnes » _id » et » _value « .
Faire » Suivant « .
Faire » Suivant « .
Cliquer sur » Terminer « .

La connexion de données est prête à être utilisée en tant que connexion secondaire.

4.3. Bilan

Avantage : Gains de chargement des deux côtés, serveur et client. Plus simple à maintenir que des listes en dur dans le formulaire (via XML ou non).
Inconvénient : Les modifications sont faciles, il est donc aussi plus facile aussi de corrompre d’intégrité des données en modifiant un identifiant par exemple.

5. SCINDER EN DIFFERENTES VUES

Même s’il s’avère que l’ensemble des connexions de données et des données sont rapatriées sur le client même si elles ne seront pas utilisées par la vue affichée, cette solution est intéressante pour gagner en temps de chargement côté client.
Avantage : Meilleur gain de temps à gagner côté client.
Inconvénients : Les fonctionnalités du formulaire ne sont peut-être pas adaptées à un fonctionnement par vues.

6. CONNEXIONS DIRECTES A LA BDD VIA DES FICHIERS UDCX EN CAS D’UTILISATION INTENSIVE DE SERVICES WEB

Si l’utilisation de Services Web est obligatoire pour recevoir ET mettre à jour des données, elle ne l’est pas pour simplement recevoir des données.

6.1. Cas d’utilisation

Pour des connexions de données secondaires utilisées pour les listes déroulantes.
En effet, utiliser des services web en connexion secondaire qui retournent simplement des libellés est quelque peu abusif. Il faut envisager des connexions directes à la base de données.
Attention, dans notre cas de formulaires Infopath client léger, il faut utiliser obligatoirement des connexions de données stockées dans les fichiers UDCX eux-mêmes présents dans une bibliothèque SharePoint. Des connexions directes embedded dans le formulaires sont impossibles, sous peine d’erreurs 6932 au chargement.

6.2. Comment faire ?

Etape 1 : Créer une connexion de données classique :

Outils > Connexions de données > Ajouter.
Créer une connexion dans > Réception des données.
» Suivant « .
Choisir » Bases de données « .
» Suivant «
Cliquer sur le bouton » Sélectionner une base de données » et choisir le fichier ODC de liaison vers la BDD adéquat (le créer si nécessaire).
Choisir la table de laquelle seront extraites les données.
Cliquer sur » OK » si un message d’avertissement sur les mots de passe apparait.
» Suivant « .
» Suivant « .
» Terminer « .

Etape 2 : Convertir en fichier UDCX hébergé dans une bibliothèque SharePoint :

Outils > Connexions de données.
Choisir la connexion fraichement créée
Cliquer sur » Convertir «
Une popup s’affiche, cliquer sur » Parcourir « .
Entrer l’URL puis un nom de fichier UDCX pour cette connexion. L’URL est celle du site SharePoint + la bibliothèque de connexion de données. Exemple : http://203.34.222.205/sites/DevSAGA/DC.
Cliquer sur » OK « .
» Fermer « .

La source de données est utilisable comme n’importe quelle autre dans InfoPath.

6.3. Bilan

Avantages : Gains en temps de chargement Serveur.
Inconvénients : Il n’y en a pas en particulier.

7. MESURE DES GAINS

Voici un tableau qui récapitule des temps de chargements du même formulaire, mais avec quatre versions de connexions de données différentes :

Par Normal, il faut entendre un formulaire utilisant 38 connexions de données, toutes se servant de Web Services pour recevoir ou envoyer des données. Ce formulaire contient 19 listes déroulantes (!!).
UDCX : Signifie que 13 connexions sur les 38 ont été remplacées par des liens directs vers la base de données. Ces connexions secondaires sont toutes utilisées pour rapatrier les libellés des données affichées dans les listes déroulantes.
MOSS : 13 connexions vers des web services sur 38 sont remplacées connexions sur des listes SharePoint.
XML : Ces mêmes connexions de données sont cette fois ci des listes en dur dans le formulaire, alimentées à la base par un fichier XML.
VUES : On reprend le formulaire normal et ses 38 connexions de données, mais on le scinde en deux vues. La vue chargée par le navigateur contient alors » seulement » 12 listes déroulantes au lieu de 19.

Six mesures ont été faites, chacune prend en compte le temps de chargement serveur (S), client ( C) et le temps total (T).

Test N�	1			2			3			4			5			6			Moyenne
S	C	T	S	C	T	S	C	T	S	C	T	S	C	T	S	C	T	S	C	T
Normal	13,2	9,04	22,2	14,75	8,60	23,35	18,14	8,74	26,88	14,89	8,88	23,77	14,81	8,97	23,78	15,82	9,01	24,83	15,26	8,87	24,14
UDCX	10,9	9,02	19,9	14,26	9,27	23,53	12,20	9,15	21,35	12,53	9,22	21,75	12,04	9,20	21,24	12,54	9,20	21,74	12,41	9,18	21,59
MOSS	9,64	8,18	17,8	10,12	7,89	18,01	10,94	8,22	19,16	12,70	7,95	20,65	11,15	7,72	18,87	11,79	7,96	19,75	11,06	7,99	19,04
XML	9,35	8,88	18,2	9,76	8,71	18,47	10,37	9,37	19,74	9,93	8,62	18,55	9,54	8,67	18,21	9,95	8,77	18,72	9,82	8,84	18,65
VUES	14,4	7,09	21,5	14,85	7,00	21,85	15,24	6,97	22,21	15,48	6,98	22,46	15,41	6,88	22,29	14,24	6,87	21,11	14,93	6,97	21,90

Tableaux des gains en % :

Serveur	Client	Total
Normal	0,00	0,00	0,00
UDCX	18,69	-3,42	10,56
MOSS	27,55	9,99	21,10
XML	35,68	0,41	22,71
VUES	2,15	21,51	9,27

Trois résultats sont intéressants :

En vert, on se rend compte d’un gain important de chargement côté serveur lorsqu’on utilise des listes en dur inclues dans le formulaire.
En jaune, un gain évident de temps de chargement côté client lorsqu’on scinde de formulaire en plusieurs vues.
En bleu, l’utilisation de listes SharePoint fait gagner en performance sur les deux fronts !

8. BILAN

Dans un formulaire InfoPath complexe et qui comprend de nombreuses connexions de données, il ne faut pas hésiter à utiliser divers types de connexions, chacun ayant son cas d’utilisation :

Des listes en » dur » pour les données qui n’évoluent jamais. On gagne en connexions gourmandes. Cette solution est tout de même à éviter.
Des listes alimentées directement par des connexions directes à la BDD, c’est toujours moins lourd que de passer par des Web Services.
Scinder le formulaire en vues, ce qui limite ostensiblement la casse côté client.
Un choix judicieux : l’utilisation de listes SharePoint. Des gains ostensibles côté serveur et client, mais obligation de créer des listes (ce qui peut être fastidieux à faire) et attention aux droits d’accès à ces données.

SOMMAIRE

1. INTRODUCTION

1.1. Description

1.2. Pré-requis

2. VERIFIER L’EXISTENCE DU WEB SERVICE

3. CREER LA DLL DE PROXY

3.1. Création de la DLL

3.2. Enregistrement dans le GAC

4. EXEMPLE DE PROJET SOUS SSIS

SOMMAIRE

1. INTRODUCTION

2. DEUX TYPES DE TEMPS DE CHARGEMENT : COTE SERVEUR ET COTE CLIENT.

3. ENVISAGER DES CHARGEMENTS EN » DUR » VIA DES LISTES XML.

3.1. Cas d’utilisation

3.2. Comment faire ?

3.3. Bilan

4. LE MEILLEUR COMPROMIS : UTILISER DES LISTES SHAREPOINT

4.1. Cas d’utilisation

4.2. Comment faire ?

4.3. Bilan

5. SCINDER EN DIFFERENTES VUES

6. CONNEXIONS DIRECTES A LA BDD VIA DES FICHIERS UDCX EN CAS D’UTILISATION INTENSIVE DE SERVICES WEB

6.1. Cas d’utilisation

6.2. Comment faire ?

6.3. Bilan

7. MESURE DES GAINS

8. BILAN