InfoPath : Impossible d'exècuter la requête pour le DataObject

Lors de l'utilisation de formulaire InfoPath dans SharePoint, de nombreux utilisateurs font face au message d'erreur suivant suite à l'utilisation de connexion de données vers un site SharePoint :

Impossible d'exécuter la requête pour le DataObject suivant : NomDataObject
La réponse SOAP indique une erreur :
Le serveur n'a pas reconnu la valeur de l'en-tête HTTP SOAPAction :
http://schemas.microsoft.com/sharepoint/soap/GetObjectIdFromUrl.

Dans 99% des cas, cela provient du fait que la version d'InfoPath utilisée n'est pas identique à la version de votre SharePoint.

Il faudra ainsi tout d'abord vérifier que le mode de compatibilité de votre formulaire correspond. Pour cela, suivre les actions suivantes:

1. Cliquer sur "Fichier",
2. Cliquer sur "Options du formulaire",
3. Cliquer sur "Compatibilité",
4. Si vous publiez un formulaire sur SharePoint 2010, il faudra vérifier que vous n'êtes pas en mode de compatibilité "InfoPath Form Services" qui correspond à un InfoPath Forms Services pour SharePoint 2013:

Ainsi, InfoPath va pouvoir communiquer avec les web services de SharePoint sans erreurs (pas de problème de schéma ou autre,...)
Simple, mais cela peut éviter de sacrés nœuds au cerveau...

INFOPATH 2010 : Image liée

Une fonctionnalité sympathique d'InfoPath est de pouvoir embarquer des images liées depuis une url. Cela peut-être utile dans le cadre de formulaires comprenant de nombreuses images (bandeau, indicateurs, pictos,...):

Cette fonctionnalité disponible avec InfoPath Forms Services permet donc par exemple d'externaliser les images dans une bibliothèque de formulaires. Cela réprésente un double avantage à mes yeux:

• Facilité de modification d'une image sans republier le formulaire (très utile pour des formulaires approuvés par l'administrateur qui doivent être publiés via l'administration centrale),
• Allègement de la taille du formulaire (notamment dans le cas d'utlisation de bannières ou de nombreuses images),

 

Malgré tout, il existe un petit problème avec ce contrôle.

Prenons un exemple simple: Un formulaire comprenant une image liée et une section masquée ou non selon le clic sur des boutons "Plier"/"Deplier".

 

Lors de l'ouverture du formulaire dans InfoPath Forms Services, l'image est correctement affichée:

 

Par contre, lors du clic sur le bouton "+" pour afficher les champs, la section s'affiche correctement mais l'image disparaît lors du postback (et laisse sa place à une icône) :

Lors du prochain postback, l'image réapparaitra comme par magie... En gros, ce n'est pas utilisable en l'état.

 

Le problème provient tout simplement du fait de l'utilisation d'une URL relative pour afficher l'image (par exemple "/_layouts/images/siteicon.png"). L'url relative permet de retrouver l'image lors du premier affichage mais pas lors de tous les postbacks, ce qui nous fait un joli bug...
J'ai détecté cette erreur en testant sur un SharePoint 2010 post SP1 mais après quelques tests, il s'avère que le problème est toujours présent sur le SP2 de SharePoint 2010...

Moralité : N'oubliez donc pas de positionner une URL complète pour l'image liée lorsque vous utilisez ce type de champ.

INFOPATH : This form has been closed

Aujourd'hui un court article sur Forms Services dans SharePoint 2007.

Parfois, il peut arriver d'avoir l'erreur suivante à l'ouverture d'un formulaire InfoPath web:

The form has been closed.

The server is currently being taken down for maintenance. Check with your system administrator to see when this server is scheduled to come back online.

Assez embêtant comme erreur!

Le moyen pour corriger ce genre d'erreur est assez simple, il faut aller dans l'administration centrale sur la partie "Opérations" puis sélectionner "Quiesce farm" puis reset.

Si cela ne fonctionne toujours pas en réalisant ces opérations depuis l'interface, il faudra utiliser une commande 'stsadm' (cet éxécutable est sité dans le répertoire "%ProgramFiles%/Common Files/ Microsoft Shared/Web Server Extensions/12/BIN".

Il faudra ainsi la commande suivante : stsadm.exe -o unquiescefarm

Cette commande permet de spécifier que le server SharePoint n'est plus en mode maintenance. Comme l'affirme le tehcnet, cette commande reprend la capacité de la batterie de serveurs à accepter de nouvelles sessions qui sont indispensables pour le rendu des formulaires InfoPath sur un serveur.

Assez simple mais encore faut-il le savoir!

INFOPATH 2010 : Modèle de formulaire

InfoPath possède une fonctionnalité très utile mais aussi trop peu rarement utilisée en entreprise.

Elle consiste en la possibilité de pouvoir créer un modèle de template qui pourra par la suite être réutilisé dans tous vos formulaires.

L'avantage conséquent de l'utilisation de ces modèles est une uniformisation du design de vos formulaires (entête, pied de page, etc). Les utilisateurs sont ainsi moins déroutés lorsqu'ils utilisent les formulaires grâce à une charte graphique unique.

Pour utiliser ce genre de modèle, il faut suivre les étapes suivantes:

• Lancer Microsoft Office InfoPath Designer,
• Sur la page de sélection du type de modèle, sélectionner "Template vierge":

• Créer votre modèle en rajoutant un logo et un titre par exemple,
• Enregistrez ce modèle au format précisé par InfoPath,
• Re-ouvrir InfoPath,
• Sur la page de sélection du type de modèle, sélectionner "Formulaire vierge",
•  Se placer dans la section contrôles, puis cliquer sur "Ajouter/Supprimer des contrôles personnalisés",
• Sélectionner "Modèle" comme ci-dessous :

• Saisir le chemin pour accéder au formulaire "Modèle" enregistré plus haut,
• Cliquer sur "Ajouter". Le modèle est à présent ajouté aux contrôles personnalisés :

 

• A présent, ce contrôle apparaitra ainsi dans la liste des contrôles personnalisés de votre programme InfoPath comme ci-dessous :

• Lors du clic sur ce modèle, une section se rajoutera automatiquement dans votre formulaire. Voici ici le cas d'une entête simple qui est insérée dans vos formulaires. Cette entête permettra à tous les formulaires de l'entrepris d'être homogène en terme de présentation.



Si vous disposez uniquement de 2 formulaires InfoPath dans votre entreprise, l'avantage de cette fonctionnalité ne vous parait peut-être pas évident.

Mais je peux vous garantir qu'au delà, il est nécessaire de privilégier cette approche qui permettra:

• De gagner du temps lors de la conception,
• De ne pas dérouter les utilisateurs en leur proposant une multitude de chartes.

INFOPATH FORMS SERVICES : Tracer exceptions

InfoPath offre la grande puissance de pouvoir utiliser du code managé pour réaliser tous les besoins de chaque formulaire qui ne sont pas réalisable par l'interface. Mais même un code très bien conçu peut générer des exceptions (problème matériel, de configuration, de paramètrage...).

Il est donc primordial de tracer ou afficher ces erreurs lorsqu'une exception est remontée dans un formulaire Forms Services ou un formulaire client lourd.

Les 2 meilleures solutions pour tracer les erreurs dans un formulaire Forms Services restent les suivantes :

• Afficher l'erreur à l'écran : Affecter le message de l'exception à un champ compris dans le XML de votre formulaire. Il est même préférable de créer une vue d'erreur comprenant ce champ et d'afficher celle-ci dès qu'une erreur survient.
• Logguer l'erreur dans les logs SharePoint : Pour cela il faut utiliser la méthode suivante: Microsoft.Office.Server.Diagnostic.PortalLog.LogString("mon exception");
  Il est de même possible d'utiliser la méthode DebugLogString (description ici: http://msdn.microsoft.com/en-us/library/microsoft.office.server.diagnostics.portallog.debuglogstring.aspx) qui permet de préciser un niveau de log : verbose, critique, information...

Ces 2 méthodes permettent à la fois d'afficher l'erreur à l'utilisateur final mais aussi de la tracer par le même temps dans les logs SharePoint afin qu'un administrateur puisse étudier les problèmes rencontrés.

Bon dev'.

INFOPATH FORMS SERVICES : Erreur service d'état

Il existe différentes stratégies pour configurer sa ferme SharePoint 2010.
Certains préfèrent instancier tous les services applicatifs tandis que d'autres préfèrent les instancier au fil de l'eau en fonction du besoin.
J'avoue faire partie de la seconde école par soucis de performances.

Lorsque vous utilisez cette méthode, vous pouvez rencontrer l'erreur suivante si vous essayez d'ouvrir un formulaire InfoPath Forms Services: "An error has occurred with the Form Service there is a misconfiguration of the Microsoft SharePoint State Service" ou en bon Français "Une erreur est survenue suite à une mauvaise configuration du service d'état Microsoft".

Cela provient du fait que ce fameux service "Service d'état" n'a pas été instancié sur la ferme.
Encore une fois et comme d'autres services, ce service ne peut pas être instancié par l'interface SharePoint... Par contre, on peut réaliser ceci par l'utilisaton de cmdlets powershell.
Pour cela, il faut suivre les manipulations suivantes:

1/ Se connecter sur le serveur hébergeant l'administration centrale,
2/ Lancer la console Powershell de SharePoint en mode admin (la SharePoint 2010 Management Shell),
3/ Créer le service d’état en utilisant la commdande suivante :
$stateservice = New-SPStateServiceApplication -Name "Service d’état SharePoint 2010"
4/ Associer une base de donnée à ce service :
New-SPStateServiceDatabase -Name "SP2010_StateServiceDB" -ServiceApplication $stateservice
5/ Créer le proxy associé à ce service :
New-SPStateServiceApplicationProxy -Name "Service d’état SharePoint 2010 Proxy" -ServiceApplication $stateservice -DefaultProxyGroup


Et voila, le tour est joué, vous pouvez à présent ouvrir correctement vos formulaires InfoPath Forms Services!

INFOPATH FORMS SERVICES 2010 : Ajouter script

Aujourd'hui un petit post sur une méthode de customisation de vos formulaires InfoPath Forms Services sous SharePoint 2010.
Il est à présent possible d'ajouter du script dans votre page du formulaire en utilisant du code managé. Cela ouvre les perspectives suivantes:
- Modifier les styles CSS en les surchargeant,
- Ajouter du javascript dans le formulaire (par exemple lancer un alert javasscrpit lors du clic sur un bouton pour confirmer bon fonctionnement d'une action),

L'exemple suivant permet d'afficher une alert lors du clic sur un bouton:

// Désolé l'éditeur de blogger écrase le javascript, il faut donc encapsuler le alert ci-desssous dans une balise script javascript pour réaliser l'action
string script = "alert('Modification réalisée sur le clic du bouton');";
Page page = HttpContext.Current.Handler as Page;
ClientScriptManager csm = page.ClientScript;
csm.RegisterClientScriptBlock(typeof(Page), "AddAlert", script, true);

Il est de même possible d'utiliser par exemple du JQuery en réferençant la librairie selon la méthode précédente.
Cette opportunité permet de réaliser des formulaires répondant à quasiment tous les besoins clients.
La seule limite reste l'imagination!

InfoPath Forms Services 2010 : Erreur CU Juin

Petit billet au sujet d'une erreur survenue après le passage de la CU de Juin pour SharePoint 2010. Lors de l'utilisation d'un formulaire InfoPath Form Services, l'erreur suivante est apparue:

• Version EN : The security Validation for this page is invalid. Click back in your Web Browser, refresh the page and try your operation again.
• Version FR : La validation de la sécurité de cette page n'est pas valide. Cliquez sur Précédente de votre navigateur et retentez l'opération.

Ce problème est issu de l'installation de la CU de Juin. Il peut survenir lors d'un changement de vue, l'utilisation d'une pièce jointe ou l'utilisation d'un sélecteur de personne par exemple. Cette erreur survient de même sur des formulaires ne possèdant pas de code managé.

Cela est du à la modification du fonctionnement d'InfoPath Form Services dans cette CU : un postback est à présent généré mais celui-ci nécessite une validation qu'il ne trouve pas sur la page.

Il existe deux solutions pour contourner ce problème:

• Désactiver la validation de la sécurite. Cette méthode est déconseillée clairement pour des notions de sécurité. La désactivation peut causer des effets non désirés.

• Modifier la page FormServer.aspx du serveur SharePoint.
  La marche à suivre pour modifier le fichier est la suivante:
• Se placer dans le répertoire "14" de SharePoint.
• Aller dans "Templates/Layouts".
• Se placer sur la page "FormServer.aspx",
• Ouvrir ce fichier et ajouter la balise au dessous de la balise body de la page.
• Enregistrer la modification
• Réaliser cette action sur tous les frontaux de la ferme SharePoint.

Attention cette seconde solution n'est que temporaire car elle consiste à aller modifier une page dans le répertoire 14 de SharePoint. Ceci est déconseillé par Microsoft car un passage de KB ou CU peut écraser votre modification.

En attendant, elle fonctionne à merveille car les formulaires fonctionnent parfaitement par la suite.

Seulement actuellement, il semble qu'il n'existe pas de correctif officiel sur ce problème.

A priori, ce correctif devrait être installé dans les prochaines CU.

So wait and see!!!

INFOPATH 2007 : Validation de données

De nombreux clients réalisent des retours concernant l'utilisation d'InfoPath Form Services dans SharePoint 2007. Le principal est le petit tooltip qui s'affiche sur un champ obligatoire "Ne peut pas être vierge".

Ce petit tooltip à le don d'agacer de nombreux utilisateurs car il se positionne souvent à l'intérieur d'un autre champ de saisie.

Cet affichage est défini par le CSS utilisé par Form Services. Celui-ci étant dans SharePoint, il n'est pas concevable de modifier la page originelle de SharePoint (sous peine de se faire écraser les modifications lors d'un passage de cumulative update ou de service pack).

La solution la plus "propre" consiste à aller modifier manuellement le fichier "manifest.xsf" présent dans le formulaire InfoPath (un fichier XSN d'infopath n'étant qu'un type particulier de cab).

Vous trouverez dans ce fichier les validations de données de votre formulaire:

Ne peut pas être vierge

Il faut modifier l'attribut ShortMessage en le mettant à vide.

Ainsi le petit tooltip ne sera plus affiché.

INFOPATH 2010 : Contrôle de saisie

Voici un petit tutoriel concernant la définition d'un contrôle de saisie sur un champ InfoPath. Le contrôle est à réaliser au niveau d'un champ InfoPath ( comme ici une zone de texte par exemple) et cliquer sur "Gérer les règles".

Ensuite il faut sélectionner le type de règle "Validation" comme ci-dessous:

Il faut ensuite définir une condition de déclenchement du contrôle de validation. Par exemple ici nous allons vérifier que la valeur saisie par l'utilisateur correspond au formatage d'un numéro de téléphone.

Pour se faire, il faut suivre les étapes suivantes:

• Cliquer sur 'Condition',
• Sélectionner le champ actuel sur la zone de liste déroulante située sur la gauche.
• Sélectionner "ne correspond pas au modèle" dans la zone de liste déroulante centrale.

• Sélectionner "Sélectionner un modèle ..." dans la zone de liste déroulante de droite.
• Il faut ensuite préciser un modèle de contrôle des données. Les modèles par défaut sont Email, URL, Numéro de sécurité sociale... Il est de même possible de définir un modèle personnalisé par exemple pour le cas qui nous intéresse, le formatage du numéro de téléphone en rentrant la valeur suivante : "(\d{2}\s){4}\d{2}". A noter que les modèles ressemblent d'assez près aux espressions régulières. Donc un peu de recherche sur le net et vous trouverez votre bonheur.
• Définir une info-bulle lorsque la valeur saisie ne correspond pas au modèle que nous avons précisé (Exemple:"La valeur saisie ne correspond pas à un numéro de carte de crédit"). 

INFOPATH 2010 : Debug solution form services

Lors d'un précédent article, j'avais traité du fait de l'absence de template Visual Studio dédié à InfoPath. Ce manque empechait le debug simple d'un formulaire InfoPath Form Services.
Il existe tout de même solution trouvée après quelques recherches sur le net.

Pour cela, il faut possèder les outils suivants:

• Microsoft Office InfoPath Designer,
• Visual Studio Tools for Application (VSTA),
• Visual Studio 2010.

Il faut ensuite suivre les étapes suivantes pas à pas:

• Se placer dans VSTA,
• Cliquer sur le menu "Projet" puis sur "Propriétés du projet",
• Se placer sur l'onglet "Générer",
• Cliquer sur "Options avancées",
• Sélectionner le mode "full" pour le debug (voir copie d'écran) :

• Publier le formulaire InfoPath dans l'administration centrale (Très important : Décocher la case "Mettre à jour le modèle de formulaire"),
• Ouvrir le code C# dans Visual Studio 2010,
• Debugguer en s'attachant au processus w3wp.exe.

Et le tour est joué.

Comment faire compliqué quand on peut faire simple...

InfoPath 2010 : Déploiement par commande Powershell

Aujourd'hui, un article destiné à énumérer les applets de commandes PowerShell utilisables pour déployer un formulaire InfoPath dans SharePoint 2010.

Les commandes "stsadm" vont être poussées vers la sortie par POWERSHELL qui est l'outil de script du futur. Autant se familiariser rapidement en mettant de côté les commandes stsadm.

Voici la liste des applets de commandes relatifs à InfoPath et aux connexion de données:

Partie formulaire InfoPath :

Install-SPInfoPathFormTemplate : Téléchargement du formulaire InfoPath dans l'administration centrale dans form services.

Test-SPInfoPathFormTemplate : Testant si le formulaire InfoPath est valide pour être compatible navigateur.

Uninstall-SPInfoPathFormTemplate : Suppression du formulaire InfoPath renseigné en paramètre.

Enable-SPInfoPathFormTemplate : Permet d'activer un formulaire InfoPath sur une collection de sites.

Disable-SPInfoPathFormTemplate : Permet de désactiver un formulaire InfoPath d'une collection de sites.

Update-SPInfoPathFormTemplate : Mettre à jour tous les formulaires InfoPath de la ferme SharePoint.

Get-SPInfoPathFormTemplate : Obtention du formulaire InfoPath ainsi que ces paramètres.

Set-SPInfoPathFormsService : Affectation du paramètrage d'InfoPath Form Services.

Set-SPInfoPathFormTemplate : Affectation du paramètrage des proprités d'un formulaire passé en paramètre.

 

Partie connexions de données :

Install-SPDataConnectionFile : Installation de la connexion de données précisée en paramètre.

Uninstall-SPDataConnectionFile : Commande supprimant la connexion de données passée en paramètre.

Get-SPDataConnectionFile : Enumération des connexions de données présentes.

Get-SPDataConnectionFileDependent : Enumération des formulaires utilisant la connexion de données précisée en paramètre.

Set-SPDataConnectionFile : Affectation des propriétés du fichier de connexion de données.

 

Après la théorie, voici un exemple des applets de base pour un formulaire InfoPath:

// Installation du formulaire dans l'administration centrale en précisant en paramètre la localidation du formulaire

Install-SPInfoPathFormTemplate -Path "C:\MonFormulaire.xsn"

// Activation du formulaire sur une collection de sites

Enable-SPInfoPathFormTemplate -Identity "MonFormulaire.xsn" -Site "http://MonServeurSP2010/MaCollectionSites"

// Désactivation du formulaire d'une collection de sites

Disable-SPInfoPathFormTemplate -Identity "MonFormulaire.xsn" -Site "http://MonServeurSP2010/MaCollectionSites"  

// Suppression du formulaire
Uninstall-SPInfoPathFormTemplate -Identity "MonFormulaire.xsn"

Bon powershell.

INFOPATH 2010 : Utiliser TFS

Il y a quelques temps, j'avais rédigé un post basé sur ma surprise concernant la suppression du template Visual Studio Office (VSTO) au nivrau des modèles de formulaires InfoPath.

Le template Visual Studio qui existait auparavant était très fonctionnel pour les raisons suivantes:

• Modifications unitaires de fichiers du XSN (qui n'est autre qu'un fichier archive comprenant divers éléments : fichier manifest, vues, fichiers connexions de données), 
• Archivage de la solution dans TFS (Team Foundation Server) simple et éfficace notamment grâce à l'intégration dans VS,
• Intégration complète du formulaire dans Visual Studio (code et design du formulaire situés au même endroit).

Malheureusement dans la version 2010, le template InfoPath pour Visual Studio a été supprimé (sauvagement)... Il est à présent obligatoire de passer par VSTA si l'on souhaite utiliser du code managé.

Cela va s'en dire que cela change considérablement la méthode de travail qui était beaucoup plus permissive auparavant.

En cherchant quelques sources sur le web, je suis tombé sur le post suivant:

http://blogs.msdn.com/b/infopath/archive/2010/06/10/using-tfs-for-source-control-in-infopath-2010.aspx

Ce tutoriel, très bien réalisé, indique les démarches à mettre en oeuvre afin de pouvoir utiliser un contrôleur de code de source sur un template InfoPath et par la même occasion de travailler sur chaque fichiers du formulaire InfoPath.

Ce qui peut-être très utiles pour certaines sociétés de développement...

INFOPATH : Deploiement formulaire InfoPath Form Services

Voici un petit post qui permet de gagner du temps dans le déploiement de formulaire InfoPath form Services.

Ces actions souvent fastidieuses peuvent être regroupées dans un même fichier bat.
Les principales commandes à connaitre pour déployer un formulaire InfoPath Form Services sont les suivantes:

// Déplacement dans le répertoire BIN de SharePoint pour utiliser l'outil STSADM
c:\Program Files\common files\microsoft shared\web server extensions\12\bin

// Verification de la validité du formulaire pour le déployer sur l'administration centrale (phase non obligatoire):
stsadm.exe -o VerifyFormTemplate -filename "c:/Partage/FormulaireInfoPathFormServices.xsn"

// Téléchargement du formulaire dans l'administration centrale de SharePoint:
stsadm.exe -o UploadFormTemplate -filename "c:/Partage/FormulaireInfoPathFormServices.xsn"

// Activation du formulaire sur la collection de site souhaitée:
stsadm.exe -o ActivateFormTemplate -url "http://MaWebAppSharePoint/MaCollectionDeSite" -filename "c:/Partage/FormulaireInfoPathFormServices.xsn"

// Désactivation du formulaire d'une collection de site souhaitée:
stsadm.exe -o DeactivateFormTemplate -url "http://MaWebAppSharePoint/MaCollectionDeSite" -filename "c:/Partage/FormulaireInfoPathFormServices.xsn"

// Suppression d'un formulaire InfoPath de l'administration centrale:
stsadm.exe -o RemoveFormTemplate -filename "c:/Partage/FormulaireInfoPathFormServices.xsn"

Remarques importantes :

• Il est possible d'activer un même formulaire sur plusieurs collections de sites en lançant X fois la ligne de commande de l'activation,
• La publication du formulaire InfoPath form services nécessite que le service SharePoint Timer soit démarré.Le cas échéant, il est possible d'utiliser la commande suivante qui force le passage du timer: "stsadm.exe -o execadmsvcjobs"Cette opération doit être effectuée sur tous les serveurs de la ferme SharePoint.Le cas échéant, le formulaire restera en état "Installation" ("Installing") ou "Mise à jour" ("Upgrading").Un formulaire n'est disponible que lorsqu'il est dans l'état "Prêt" ("Ready"),
• En phase de développement, lorsque le déploiement du formulaire commence à prendre plus de 5 minutes, il faut se déplacer dans le répertoire local "Features" de la machine SharePoint et supprimer les anciens dossiers de solutions qui restent dans le feature et ralentissent le déploiement.

INFOPATH : Envoi Mail

Une question qui revient souvent : Comment envoyer un mail depuis Infopath.

Cet envoi peut être réalisé de plusieurs façons:

1. Utilisation d'une classe d'envoi de mail personnalisée,
2. Utilisation d'une connexion de données permettant d'envoyer un mail,

Mais aussi, utilisation de la fameuse classe SPUtility.SendEmail...

Cette classe est accessible en utilisant du code personnalisé (C# ou VB).

Celle-ci permet d'envoyer un mail classique et prend plusieurs paramètres:

• Le SPWeb,
• L'encodage HTML,
• Le mail de destination,
• L'objet,
• Le corps du mail.

Cette classe comporte malheureusement 3 inconvénients majeurs:

• Impossibilité d'insérer de pièces jointes...
• Impossibilité de préciser l'envoyeur du mail...Ce sera celui configuré dans les outgoing email de Sharepoint qui sera utilisé.
• Tronque les mails trop long. Mais il y a vraiment de la marge.

Pour des petits mails d'informations, ou de soumission à approbation, cette classe est largement suffisante et fonctionne sans problème.

INFOPATH : Contact selector

Aujourd'hui un tip pouvant être très utile :

"Comment utiliser le contact selector de Sharepoint dans un formulaire Infopath."

Le contact selector est l'un des rares contrôle Activex que l'on peut utiliser dans infopath form services...Et il peut s'avérer fort utile puisqu'il permet d'aller rechercher des utilisateurs ou groupes Sharepoint sur un site précis.

Pour cela, il faut suivre avec attention les étapes suivantes :

• Utilisation d'un fichier de mappage du serveur nommé context
  (Il permet de préciser sur quel serveur Sharepoint le contact selector va se pluguer)
  
  Il faut tout d'abord ouvrir un éditeur de texte et y coller le texte suivant Context siteUrl=http://servername/  (en précisant le nom de votre serveur sharepoint),
  Puis enregistrer ce document xml avec le nom "Context.xml" sur votre bureau.
  Ajouter dans infopath une nouvelle connexion de données de la forme suivante "Réception de données / Document XML / Inclure ce fichier en fichier de ressource du formulaire " tout en allant chercher le fichier context.xml que vous venez d'enregistrer.
  
• Recherche de l'activex dans la galerie de contrôles
  
  
  Il faut donc cliquer sur "Ajouter ou supprimer des contrôles personnalisés" puis allez sélectionner le "Contact Selector".Il sera donc disponible dans la section contrôle "Personnalisé" comme ci-dessus.

• Construction de la source de données.
  La source de données répend à une nomenclature bien spécifique.
  Il est obligatoire d'avoir un groupe comprenant un groupe extensible nommé "Person" :
  
  
            Le groupe "Person" et ses fils doivent être nommés de la façon ci-dessus pour que le contact selector fonctionne.Ensuite faire un drag and drop du contrôle et le pluguer sur le groupe contenant 'Person' dans la source de données.

NB : Si vous voulez insérer plusieurs contact selector dans un seul formulaire, faire un clic droit sur le groupe extensible "Person" dans la source de données puis cliquer sur "Référence" et le placer à l'endroit voulu.
Ainsi vous pourrez avoir plusieurs fois dans la structure le groupe person.

INFOPATH : Tableau extensible

Vous pouvez être amené dans le développement Infopath à vouloir insérer des lignes dynamiquement dans une section ou un tableau extensible

Par exemple, l'image suivante nous montre une structure extensible gérée par Infopath:

Il faudra donc insérer un bloc "ExtProduit" à chaque fois que l'on voudra insérer une nouvelle ligne...
Le code à implémenter est le suivant:

XmlDocument doc = new XmlDocument();

XmlNode group = doc.CreateElement("ExtProduit", NamespaceManager.LookupNamespace("my"));

XmlNode field = doc.CreateElement("Code", NamespaceManager.LookupNamespace("my"));

XmlNode node = group.AppendChild(field);

node.InnerText = "Valeur du code";

field = doc.CreateElement("Descriptif", NamespaceManager.LookupNamespace("my"));

node = group.AppendChild(field);

node.InnerText = "Valeur descriptif";

//Ajout du group au document

doc.AppendChild(group);

//Ajout du document à la source de données concernée

MainDataSource.CreateNavigator().SelectSingleNode("//my:RecProduit", NamespaceManager).AppendChild(doc.DocumentElement.CreateNavigator());

Plutôt simple non?

Après à vous de mixer ceci selon les besoins mais le principe de base est le précédent.

Ouvrir formulaire Infopath en mode web

L'intérêt d'InfoPath Form Services est de toucher un grand potentiel d'utilisateur puisqu'il ne nécessite pas d'avoir Infopath sur son poste pour ouvrir ce genre de formulaires qui s'ouvre sur une page Web.

Enfin ça, après une ou deux modifications sur la bibliothèque comme vu ci-dessous:

1. Se déplacer dans les "Paramètres avancés de la bibliothèque de documents,
2. Autoriser la gestion des types des contenus sur cette bibliothèque,
3. Puis cocher "Afficher en tant que page Web" à la pla ce de "Ouvrir dans application cliente".

Et voila, le tour est joué, vous vous retrouvez avec un maginifique formulaire ouvert en mode web sans infopath...
Elle est pas belle la vie!

INFOPATH : Premiere lettre en majuscule

Voici un petit tip qui fera du plus bel effet sur vos formulaires Infopath 2003 ou 2007.

Il permet de mettre automatiquement la première lettre d'un texte saisi par l'utilisateur en majuscule et ce sans une ligne de code.

1. Pour cela, il faut se placer sur la zone de texte, puis clic droit et sélectionner "Propriété de la zone de texte",
2. Ensuite cliquer sur "Règle" et ajouter une nouvelle règle,
3. Cliquer sur "Ajouter une action",
4. Dans la zone "Champ" sélectionner le champ sur lequel vous êtes situé,
5. Dans la zone "Valeur", entrez la formule suivante: concat(substring(translate(., "abcdefghijklmnopqrstuvwxyz", "ABCDEFGHIJKLMNOPQRSTUVWXYZ"), 1, 1), substring(., 2, string-length(.) - 1)),
6. Valider le tout.

Et hop l'affaire est réglée, dès que l'utilisateur aura saisi son texte et que le focus ne sera plus sur le champ, la première lettre de votre champ se transformera en majuscule.