INFOPATH : Connexion compte SQL

Lors de l'utilisation d'une connexion de données à une base de données SQL, vous devez utiliser un des modes d'authentification suivant:

• Authentification intégrée (compte de domaine),
• Un compte SQL SERVER en précisant un login sql et un mot de passe (tel le compte 'sa').

Si vous choisissez la deuxième option dans un formulaire InfoPath Form Services, vous obtiendrez le message d'erreur suivant lors de l'utilisation du formulaire:

"System.Net.WebException: Les paramètres de configuration actuels n'autorisent pas l'incorporation du nom d'utilisateur et du mot de passe dans la chaîne de connexion de base de données."

Il s'agit d'un problème de sécurité qui peut se contourner en allant modifier les paramètres de la configuration d'InfoPath Form Services (disponible via l'administration centrale de SharePoint).

Une fois positionné dans le panneau de la configuration, il faudra sélectionner "Autoriser l'authentification SQLincorporée" et cocher "Oui".

Ainsi votre formulaire fonctionnera à merveille avec une connexion à une base de données via un compte SQL SERVER.

SHAREPOINT : Migrer sous site en collection de sites

Nouveau post au sujet d'une demande formulée par un client récemment : "Comment migrer un sous-site SharePoint en une collection de sites?".

A première vue, chose compliquée, mais en ayant la bonne méthode, cela se fait sans soucis majeurs.
La méthode à employer est la suivante:

1. Exportation du contenu du site à l'aide d'une commande SharePoint dans un cmd:

stsadm.exe -o export -url "http://serveur/collectiondesite/soussite" -filename "c:\temp\Migration_SousSite_Date.bak" -includeusersecurity

2. Création dans l'administration centrale SP de la nouvelle collection de site qui va accueillir le site à migrer (avec le bon modèle de site obligatoirement).

3. Exportation du contenu du site à l'aide d'une commande SharePoint dans un cmd:2. Création dans l'administration centrale SP de la nouvelle collection de site qui va accueillir le site à migrer (avec le bon modèle de site obligatoirement).

stsadm.exe -o import -url "http://serveur/NouvelleCollectionSite" -filename "c:\temp\Migration_SousSite_Date.bak" -includeusersecurity

La méthode est simple, encore faut-il y penser!

Les opérations d'importation et d'exportation sont tracées dans un fichier de log (placé à l'endroit où est déposé le backup du sous-site).

Il est nécessaire de les consulter afin de vérifier que toute la migration a été réalisée sans soucis.

Infopath 2010 : Solution Visual Studio

Aujourd'hui, nouvelle surprise en essayant de créer une solution Visual Studio 2010 pour InfoPath 2010. Le module VSTO (Tools for Office) pour InfoPath destiné à réaliser des formulaires intelligents (avec du code) n'existe plus!!!

Il faut à présent utiliser VSTA (Tools for Applications) afin d'utiliser du code personnalisé.

En clair, il est impossible de créer une solution Visual Studio pour InfoPath comme cela était le cas dans Visual Studio 2003, 2005 et 2008.

Cela signifie que le seul moyen d'aller modifier le xsl ou le fichier manifest sera de décompresser le fichier xsn (ce qui n'est pas le moyen le plus rapide et intuitif...).

Et cela signifie par la même occasion que le contrôle de code source sur un formulaire n'existera plus sachant qu'il n'y aura plus de solutions. Ceci est encore un gros point noir...

Cela risque de représenter un gros problème pour les sociétés développant des formulaires intelligents. Et pourtant, InfoPath reste tout de même un bon point d'entrée pour la modification et la customisation dans SharePoint 2010. Devant une demande grandissante, le choix est d'enlever des fonctionnalités aux développeurs!

En clair, le choix de microsoft de supprimer le modèle Visual Studio pour InfoPath est selon moi incompréhensible! Si quelqu'un à un début explication concernant ce changement soudain et brutal de politique, je suis preneur...

SHAREPOINT : BD SUSPECT

Aujourd'hui une explication suite à un problème survenu lors du crash en plein vol d'une Virtual Machine...
La base SQL SERVER 2005 reliée à SharePoint est tout à coup passée en mode "SUSPECT".
Le problème étant que lorsque la base passe dans cet état, le site SharePoint ne fonctionne plus.

Si un problème tel que celui-ci se produit, il faut éxecuter les commandes suivantes dans SQL SERVER Managment Studio (en changeant NomDB par le nom de la base de données incriminée):

EXEC sp_resetstatus 'NomDB'

ALTER DATABASE NomDB SET EMERGENCY

DBCC checkdb('NomDB')

ALTER DATABASE NomDB SET SINGLE_USER WITH ROLLBACK IMMEDIATE

DBCC CheckDB ('NomDB', REPAIR_ALLOW_DATA_LOSS)

ALTER DATABASE NomDB SET MULTI_USER

SHAREPOINT : Export WebPart

Aujourd'hui petite astuce pour l'exportation d'une webpart SharePoint de liste d'un environnement à une autre (validation à production par exemple) sans passer par l'utilisation de SharePoint Designer.

Pour exporter la webpart, il suffit de cliquer dans le menu contextuel de la webpart sur le menu Exporter.

Il suffit de préciser le nom du fichier avec l'extension ".webpart".

Techniquement ce fichier ".webpart" n'est rien d'autre que du XML et peut être modifié avec un éditeur de texte. Pour que la webpart fonctionne sur le nouvel environnement, il faut modifier le GUID de la liste pour le remplacer par celui de la liste dans le nouvel environnement.

Une fois le fichier modifié, il faut à présent importer la webpart dans le nouvel environnement.

Pour cela suivre les étapes suivantes:

• Insérer une nouvelle webpart dans la page du nouvel environnement,
• Cliquer sur le lien "Galerie de webpart avancée" dans la liste des webpart disponible,
• Remplacer "Parcourir" par "Importer dans le menu disponible en haut,
• Télécharger le fichier "*.webpart" modifié précédemment,
• Sélectionner une position dans la page et cliquer sur "Importer".

La webpart fonctionne à présent sur le nouvel environnement sans avoir à utiliser SharePoint designer pour réaliser des modifications.