INFOPATH 2013 : Gestion des pièces jointes

Aujourd'hui un post sur un problème récurrent rencontré par les utilisateurs d'InfoPath et plus généralement InfoPath Forms Services : La gestion des pièces jointes.

 

Nativement, les pièces jointes téléchargées via le formulaire sont stockées dans le XML de l'instance. 

Cela implique généralement une quadruple problématique pour les utilisateurs :

1. Le formulaire est alourdi par cette pièce jointe encodée dans le XML,
2. Le temps de chargement du formulaire est grandement dégradé,
3. La gestion de la sécurité du document (droit de modification, lecture ou confidentiel) ne peut pas être décorrélée de celle du formulaire,
4. Les pièces jointes insérées dans le formulaire ne sont pas indexées via le moteur de recherche.

Note : Les formulaires de "liste" modifiés via  InfoPath ne sont pas concernés par le sujet car ils héritent du fonctionnement natif des listes SharePoint.

 

En tant que solution de contournement à ces problématiques, je conseille généralement (lorsque le besoin s'y prête) de réaliser un peu de code managé permettant de changer légèrement le fonctionnement du contrôle.

Le fonctionnement devient ainsi le suivant:

1. La pièce jointe est téléchargée dans le formulaire,
2. L'évènement "Changed" est déclenché dans le code managé dès l'ajout du fichier dans le contrôle,
3. Le code associé à cet évènement dépose la pièce jointe dans une bibliothèque de document SharePoint (possibilité de stocker dans un fichier dédié, nettoyage du nom de fichier, gestion des autorisations,...),
4. Alimentation d'une section extensible pour afficher la liste des fichiers associés à l'intérieur du formulaire,
5. Suppression du fichier dans le contrôle de pièce jointe du formulaire.

 

 

Voici le rendu:

 

Nous pouvons voir que :

• Le contrôle des pièces jointes reste vide. Le données ne sont pas stockées dans l'instance de formulaire elle-même => Optimisation du temps d'ouverture et de traitement,
• Les fichiers sont ajoutés dans une bibliothèque SharePoint (ce qui permet de les regrouper, gérer leur sécurité, les rendre indexable,...) => Plus grande flexibilité sur les règles de gestion métier,
• La suppression de fichiers depuis le formulaire via le petit bouton rouge (nécessitant quelques lignes de code managé sur le clic du bouton) est aussi prévue.

N'hésitez pas à me contacter si besoin.

INFOPATH : Fonction msxsl:string-compare

Lors de l'utilisation d'InfoPath, vous pouvez parfois avoir la nécessité de comparer divers éléments saisis ou récupérés dans le formulaire : texte et dates.

Malheureusement, les fonctions proposées nativement pas l'interface d'InfoPath peuvent ne pas correspondre à vos besoins. Sachez qu'il est possible d'utiliser d'autres fonctions cachées via l'interface natives!

 

Cela est le cas par exemple pour la fonction msxsl:string-compare.

Voici 2 cas concrets d'utilisation de cette fonction pouvant venir en aide :

• Comparaison de texte non sensible à la casse : msxsl:string-compare(my:ChampUtilisateur, xdUser:get-UserName(), "", "i") = 0 (où le paramètre "i" signifie case-insensitive),
• Comparaison de dates pour vérifier la validité d'une date de fin par rapport à une date initiale : msxsl:string-compare(my:DateDebut, my:DateFin) <= 0

 

Afin d'utiliser cette fonction, il sera nécessaire de passer en mode "Modifier l'expression XPath" puis copier les lignes:

 

 

INFOPATH : Filtrer connexion de données

Aujourd'hui un article sur une optimisation de formulaires InfoPath! Dans 90% des cas, les concepteurs de formulaires InfoPath vont chercher des informations dans des listes ou bibliothèques SharePoint (liste des clients, projets, produits, fournisseurs, références,...).

 

Dans la plupart des cas d'utilisation, tout se passe très bien. Mais dans certaines configurations, l'utilisateur peut rencontrer de gros problèmes de performances lors de la récupération de données:

• Connexion internet limitée,
• Très grand nombre d'éléments à récupérer.

 

La solution la plus simple reste de filtrer les résultats à renvoyer à l'aide d'une zone de texte de recherche ou d'une barre de lettre : A, B, C, D,...

 

Une fois la méthode de filtre créée, il sera nécessaire de filtrer la source de données.

Pour se faire, il ne faudra pas utiliser la connexion de données vers une bibliothèque ou liste SharePoint proposée nativement par InfoPath.

Mais plutôt une connexion de données en mode "réception de données" de type "Service web REST" (voir ci-dessous) :

 

 

 

 

Cette méthode de connexion de données permettra d'utiliser le service "listdata.svc" (API Rest) qui est proposé nativement depuis SharePoint 2010.

Pour les novices, ce service permet d'accéder aux données de votre liste  SharePoint nommée par exemple "Produits" en utilisant l'url suivante : http://monsite/_vti_bin/listdata.svc/Produits . Vous pourrez vérifier en tapant l'url dans votre navigateur que SharePoint vous renvoie le résultat au format XML.

 

Techniquement le but sera de modifier l'url de la connexion de données à l'aide des méthodes de filtre proposées par le service REST.

Vous trouverez quelques exemples basiques d'utilisation sur le site de Microsoft : http://msdn.microsoft.com/fr-fr/library/ff521587(v=office.14).aspx

 

Il sera donc nécessaire de modifier l'url de connexion afin de filtrer les valeurs renvoyées. Par exemple, si vous placez un  bouton à côté de votre zone de texte de recherche dans InfoPath, il suffira de rajouter une action sur celui-ci.

Cette action aura pour but de modifier l'url d'accès à la connexion de données de la façon suivante:

concat("http://monsite/_vti_bin/listData.svc/Produits?$filter=substringof('", txtZonedetexteRecherche, "',tolower(NomColonneSharePoint)) eq true")

 

où:

• "txtZonedetexteRecherche" correspond au champ du formulaire InfoPath permettant de réaliser le filtre,
• "NomColonneSharePoint" correspond au nom de la colonne permettant de réaliser le filtre dans la liste "Produits".

INFOPATH 2010 : Erreur SecurityException

Aujourd'hui, un court article sur un problème souvent rencontré par les débutants InfoPath qui souhaitent utiliser du code managé dans leur formulaire.

Lors de l'utilisation de votre formulaire dans SharePoint, vous pouvez rencontrer ce genre de problèmes :

 

System.Security.SecurityException Request for the permission of type ‘Microsoft.SharePoint.Security.SharePointPermission, Microsoft.SharePoint.Security, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c’ failed

 

 

Comme l'exception l'indique, il s'agit d'un problème de sécurité du formulaire. En effet, pour utiliser du code managé dans votre formulaire, il vous faut un niveau élévé.

Pour corriger ce dysfonctionnement, il vous faudra suivre les opérations suivantes:

1. Ouvrir le formulaire en mode conception,
2. Cliquer sur "Options du formulaire" dans la partie "Fichier",
3. Cliquer sur "Sécurité et approbation",
4. Décocher "Déterminer automatiquement le niveau de sécurité",
5. Cliquer sur "Autorisation totale"
6. Republier le formulaire.

 

 

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 2010 : Optimiser les performances du code managé

Aujourd'hui, voici un petit article concernant l'optimisation de vos formulaires InfoPath comprenant du code managé.
Il peut arriver que vous ayez des actions assez longues à réaliser sur le XML de votre formulaire.
Je penses notamment à l'ajout automatique de lignes dans une section extensible.

Les vues InfoPath étant liées directement au XML, une modification dans ce dernier entraine une mise à jour de la vue.
Pour s'abstenir de ce genre de comportement, il est possible d'utiliser la méthode DisableAutoUpdate.
Cette méthode permet d'attendre la fin des modifications du XML avant de rafraichir la vue InfoPath (ce qui permet de gagner un gain non négligeable de performances).

Pour se faire, il faut utiliser la méthode de la manière suivante:

// Décorrelation de la vue avec le XML
this.CurrentView.DisableAutoUpdate();

// Modification sur le XML (par exemple ajout de 100 lignes dans un tableau extensible)
...

// Corrélation de la vue avec le XML
this.CurrentView.EnableAutoUpdate();

Vous pourrez trouver un article du MSDN concernant cette méthode à cette adresse:
http://msdn.microsoft.com/en-us/library/microsoft.office.infopath.view.disableautoupdate(v=office.11).aspx

Attention toutefois à bien repositionner le "EnableAutoUpdate() à la fin du traitement sous peine d'avoir de sérieux dysfonctionnements dans le formulaire...

INFOPATH : Concaténation zone de liste selection multiple

Aujourd'hui, voici un petit tip permettant de concaténer les valeurs sélectionnées dans un champ de type "Zone de liste à sélection multiple" sans pour autant avoir à utiliser de code managé.

Pour cela, il faut utiliser une zone d'expression, puis réaliser les actions suivantes:
- Cliquer droit sur le champ calculé,
- Cliquer sur "Propriétés",
- Cliquer sur "fx" dans la zone XPath,
- Coller la formule suivante : éval(éval(champ1; 'concat(., ";")'); "..")
Dans cette formule "champ1" représente le champ pluggué sur le contrôle zone de liste à sélection multiple.

Le tour est joué. Cette formule permet de regrouper les valeurs sélectionnées en les séparant par un ";".

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 : Ajout ligne tableau extensible

Il existe différentes méthodes permettant d'ajouter des lignes à un tableau extensible par programmation. Le but étant par exemple de pré-remplir un tableau à l'ouverture du formulaire ou selon une action dans le formulaire.

Ces méthodes d'insertion consistent souvent à redéfinir tous les champs à l'intérieur de cette zone extensible un par un. Ceci  est bien souvent source d'erreur si la structure de votre zone extensible est régulièrement amenée à être modifiée.

Il existe cependant une méthode toute simple (en une seule ligne de code) qui permet d'ajouter une ligne dans un tableau:

this.CurrentView.ExecuteAction(ActionType.XCollectionInsert, "mongroupe");

où le nom "mongroupe" est obtenu en réalisant un clic droit sur la zone extensible, puis en allant dans la partie propriété. Ensuite se positionner dans la zone "XmlToEdit" disponible dans l'onglet avancé.

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!!!

SHAREPOINT 2010 : Personnaliser liste avec InfoPath

Comme nous l'avons vu précédemment, une des nouvelles fonctionnalités de SharePoint 2010 est l'apparition de la possiblilité de modifier des formulaires de liste directement avec InfoPath.

Que ce soit pour la création d'un élément de liste, sa consultation ou sa modification.

Dans la version 2007, il fallait développer un nouveau formulaire ASP.Net héritant de l'original SharePoint afin de réaliser ceci. Autant dire qu'InfoPath simplifie encore une fois grandement le développement et permet un gain de temps énorme.

Les deux tutoriels suivants permettront d'appréhender facilement la méthode à suivre (ce sont de très bons tutos) :

• 1ère méthode
• 2ème méthode

A noter toutefois que la deuxième méthode à l'avantage de pouvoir accueillir du code personnalisé (l'onglet "Développeur" étant disponible dans le formulaire InfoPath)... Ce qui n'est pas la cas lors du clic sur le ruban d'une liste SharePoint.

De plus, un problème connu dans cette version de SharePoint est le fait que le bouton "Personnaliser le formulaire" disponible dans le ruban n'est parfois pas cliquable. Si tel est le cas, il suffit de modifier la zone de votre site SharePoint dans Internet Explorer (en le plaçant dans les sites de confiance par exemple).

Bonne customisation.

SHAREPOINT 2010 : Utiliser REST

Une des nouveautés de SharePoint 2010 est l'utilisation des services REST (Representational State Transfer) à l'aide du web service WCF nommé ListData.svc. Ce web service permet de mettre en place une architecture client serveur (utilisable depuis le client : Silverlight, JQuery,...) et facilite la lecture et écriture des données depuis SharePoint.

Le lien suivant permet de mettre en avant la facilité d'utilisation de REST : http://msdn.microsoft.com/fr-fr/library/ff521587.aspx

Les web services REST peuvent être appelés entre autre depuis des formulaires InfoPath 2010.

Par exemple, lors de l'installation d'une plateforme de développement SharePoint, j'ai souhaité utiliser ce web service depuis InfoPath en renseignant l'URL:

http://monserveurSP2010/_vti_bin/listdata.svc

Mallheureusement, un message d'erreur apparait. En tapant l'URL dans un navigateur, nous obtenons l'URL suivante :

Cette erreur n'est pas bloquante, il s'agit d'un prérequis de configuration.
En effet pour résoudre ce problème, il suffit de télécharger la mise à jour ADO.Net pour le framework 3.5 SP1 de votre serveur SharePoint:

• Pour Windows 2008 R2: http://www.microsoft.com/downloads/en/details.aspx?familyid=79d7f6f8-d6e9-4b8c-8640-17f89452148e&displaylang=en
• Pour les autres OS : http://www.microsoft.com/downloads/en/details.aspx?familyid=4B710B89-8576-46CF-A4BF-331A9306D555&displaylang=en

Et petit reboot et c'est parti!
Bon REST...

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 : AutoNumber section extensible

Bonjour,

Voici un petit post non technique sur InfoPath 2010 concernant un besoin récurrent : "La numérotation automatique des lignes d'un tableau ou d'une zone extensible".

Pour réaliser ceci, il faut suivre les étapes suivantes:

• Se placer sur votre champ dans l'éditeur InfoPath,
• Cliquer sur "Propriété",
• Cliquer sur le bouton "fx",
• Cocher la case "Modifier une expression XPath avancé",
• Coller le texte suivant : "count(../preceding-sibling::*) + 10",
• Cliquer sur OK,
• Cliquer sur OK.
  
  

  Le tour est joué, vos lignes extensibles sont à présent numérotées:

  
  

  

  
  

  Le code "count(../preceding-sibling::*) + 10" signifie que vous additionnez 1 à la valeur de ce champ sur la ligne précédente.

  La mise en oeuvre reste tout de même abordable.

InfoPath 2010 : Modèle de formulaire démonstration

Cela fait plusieurs articles que je vous parle des fonctionnalités offertes par InfoPath 2010.

Mais rien de tel qu’un petit aperçu concret pour se faire une idée des possibilités offertes par ce logiciel.

Voici à présent un exemple d’un formulaire basique que j’ai réalisé avec cette version d’InfoPath.

J’ai décidé de me créer un mini-frontal InfoPath connecté aux flux RSS de mon site de sport favori.

Ce formulaire de démonstration a donc pour but final de consulter l’actualité sportive en temps réel (cliquer sur l'image pour l'afficher dans sa taille normale).

Côté technique, les flux RSS proviennent de sources de données secondaires du formulaire (connexion en réception de données de type document XML).

Les éléments principaux de ce formulaire sont les suivants :

1. Possibilité de sélectionner un sport particulier ou tous les sports. Pour naviguer, j’ai choisi d’utiliser des boutons personnalisés.

Pour l’utilisateur, ces boutons ont trois états :

• Etat classique tel le Football dans la copie d’écran,
• Etat survol tel le « Tennis - Golf » dans la copie d’écran,
• Etat sélection en cours tel le « Rugby » dans la copie d’écran.

L’état survol d’un bouton n’était pas disponible dans les versions précédentes d’InfoPath et cela rajoute un petit plus dans l’interface.

 

2. Le clic sur le lien hypertexte nous envoie évidemment vers l’article concerné sur le site d’actualité sportive,

3. Intégration des images contenues dans la description du flux RSS (pour cela il a fallu convertir le HTML contenu dans le flux en XHTML afin que le contrôle « Zone de texte enrichi » affiche correctement la valeur,

4. Coloration des actualités ( 1ligne avec fond bleu puis une ligne avec fond blanc),

5. Possibilité de filtrer selon le nombre d’actualités à afficher (5 dernières, les 10 dernières, toutes) et/ou selon la date de publication des éléments (Moins d’une heure, Moins d’un jour, Moins d’une semaine).

 

J’espères avoir convaincu les plus réfractaires du potentiel de la technologie InfoPath 2010. L’intérêt de ce formulaire reste bien-sûr très limité pour une entreprise (quoique…). Il faut surtout imaginer les possibilités offertes par ce logiciel pour la dématérialisation des supports papiers (ordre de mission, notes de frais,).

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 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...

INFOPATH 2010 : Nouveautés, Tutoriels, Démo

Pour découvrir InfoPath 2010 ou tout simplement se faire une idée du large potentiel de ce magnifique outil, voici un petit lien utile qui pourra vous éclairer :

http://channel9.msdn.com/learn/courses/Office2010/InfoPathUnit/

In english of course, but very well explain...

Petit plus non négligeable, ces vidéos sont téléchargables depuis le lecteur Windows média.