INFOPATH : Champ Password

Vous avez pu être amené dans le cadre de l'utilisation d'Infopath à vouloir saisir un password dans un formulaire (credentials pour un web services, authentification,...).
Seulement le type de champ "Password" utilisé en asp et window form n'est pas présent sous InfoPath. Le password saisi sera donc affiché en clair à l'écran de l'utilisateur ...

Pourquoi?
Cela provient du fait qu'Infopath stocke les données présentes dans le formulaire au format xml.. Il est donc très facile d'aller obtenir le mot de passe d'un utilisateur en ouvrant le fichier xml.
D'ou le fait que les développeurs d'InfoPath n'ont pas jugés utile d'avoir un tel contrôle qui du coup ne garantit pas la sécurité des Informations.

Solution de contournement : Faites votre propre contrôle password!
Si malgré cela, vous souhaitez tout de même saisir un password dans un formulaire infopath, il existe une astuce consistant en utiliser les polices windings ou webdings au niveau du champ texte pour cacher le mot de passe saisi (il n'est pas souhaitable de taper son mdp en clair à l'écran).

Cette méthode sommaire fonctionne mais il faut faire attention au xml ensuite enregistré.
2 techniques sont utilisables:

• Crypter le mot de passe enregistré selon un algorithme de cryptage (Personne ne pourra connaitre le password sans avoir la clé de cryptage).
• Effacer ce mot de passe à la fermeture du formulaire (si ce mdp est à utiliser une seule fois).

INFOPATH : WebService UserProfileService

Il est souvent utilisé dans les formulaires InfoPath 2007 la fonction forte utile nommée « NomUtilisateur() ».
Il est à présent possible d’utiliser les web services MOSS pour récupérer diverses informations sur la personne connectée (Nom, Prénom, Mail, Téléphone, Grade, Supérieur, numéro de salarié, etc).

Le web service « UserProfileService.asmx » permet d’obtenir les informations provenant de la base de profil SharePoint (la base de profil correspond à l’équivalent de l’AD plus éventuellement des attributs étendus).

Il faut donc créer une connexion de données  :

• Se placer dans le menu Outils/Connexion de données et sélectionner le type « Réception de données » puis « Web Service »,
• Saisir une URL de la forme : « http://Serveur/_vti_bin/UserProfileService.asmx » puis sélectionner la web méthode « GetUserProfileByName ».
• Cliquer sur OK 3 fois tout en laissant la checkbox « Extraire les données à l’ouverture du formulaire » sélectionnée.
  Aucun paramètre n’ayant été précisé dans la connexion de données, le webservice prendra l’utilisateur par défaut en paramètre.

La connexion étant réalisée, il faut à présent plugguer ce webservice sur un de nos champs:

• Ajouter une zone de texte sur le formulaire,
• Cliquer sur le bouton « fx » dans les propriétés de la zone de texte.
• Cliquer sur « Insérer un champ ou un groupe »,
• Se déplacer sur la source de données secondaire nommée : « GetUserProfileByName » (zone de liste déroulante).
• Se placer sur le champ « Value » dans l’arobrescence visible ci-dessous :
  
  
  
• Une fois sur « Value », cliquer sur « Filtrer les données » puis sélectionner « Name » dans la partie de gauche (provenant de la source de données secondaires » puis sélectionner le texte « PreferredName » dans la partie de droite. En fait, il suffit de préciser ici le nom du champ de la base de profil à récupérer…
  
  

Cliquer sur OK jusqu’à revenir sur le template puis vous pouvez passer en mode aperçu pour apprécier le fonctionnement….
En supplément, voici un ptit tour rapide des informations disponibles sur une base de profil originale: “UserProfile_GUID”, “AccountName”, “FirstName”, “LastName”, “PreferredName”, “WorkPhone”, “Office”, “Department”, “Title”, “Manager”, “AboutMe”, “PersonalSpace”, “PictureURL”, “UserName”, “QuickLinks”, “WebSite”, “PublicSiteRedirect”, “Assistant”, “WorkEmail”, “CellPhone”, “Fax”, “HomePhone”

SHAREPOINT : Utiliser impersonation

Dans le développement d'un formulaire Infopath (et plus particulièrement lorsque vous développez un fomulaire Infopath Form Services, vous êtes amené à aller chercher des informations sur Sharepoint.

Parfois, les utilisateurs n'ont pas le droit d'y accéder et vous devez passer par l'impersonnation en utilisant la méthode dîtes du RunWithElevatedPrivileges...

Celle-ci peut-être rapidement un casse-tête si elle est mal utilisée.

Elle doit se présenter de la façon suivante:

     Guid webGuid = SPContext.Current.Web.ID;

     Guid siteGuid = SPContext.Current.Site.ID;

     SPSecurity.RunWithElevatedPrivileges(delegate()

    {

         // Context du site dans le RunWithElevatedPrivileges

         using (SPSite site = new SPSite(siteGuid))

         {

               // Context du webdans le RunWithElevatedPrivileges

               using (SPWeb web = site.OpenWeb(webGuid))

              {

                     // ...

              }

         }

    });

Attention à bien récupérer les GUID avan pour les utiliser ensuite dans le delegate.

En effet si l'on utilise par exemple "SPWeb web = SPContext.Current.Web;", l'impersonnation ne fonctionnera pas puisque l'on récupérera le contexte de l'utilisateur.

Ce code est donc à manipuler avec la plus grande attention.

Notez qu'il n'est pas necessaire d'utiliser un site.Dispose() ou web.Dispose() de par l'utilisation des instructions using...

INFOPATH : Parametre URL

Si vous avez déja étudié l'url d'un formulaire Infopath Form Services, vous avez pu constaté qu'on retrouvait pas mal de d'informations la-dedans.

Si tout cela vous parait barbare, ce petit post va vous aider à voir plus clair.

Les paramètres les plus souvent rencontrés sont les suivants:

• XmlLocation= xml_url : Permet d'ouvrir un formulaire déjà existant sur le serveur en précisant l'adresse du xml,
• XsnLocation=model_url : Permet de créer un formulaire basé sur un modèle de formulaire InfoPath en précisant l'adresse du template (".xsn"),
• SaveLocation=save_url : Permet de spécifier ou le formulaire sera enregistré,
• Source=source_url: Permet de rediriger l'utilisateur après la fermeture du formulaire. Permet de ne pas afficher "Le formulaire a été fermé",
• OpenIn=Browser : Permet d'ouvrir le formulaire dans le navigateur. Qui est équivalent à DefaultItemOpen=1.

Petite précision: Ces paramètres peuvent être combinés dans l'url. Il n'y a que XmlLocation et XsnLocation qui ne peuvent pas apparaitre ensemble. Logique puisque soit nous ouvrons un modèle pour créer un nouveau formulaire, soit nous ouvrons un formulaire déja existant...

Petite info en plus: A noter que l'on peut rajouter n'importe quel autre paramètre personnalisé dans l'url... En faisant un peu de code, ces paramètres sont récupérables au load du formulaire grâce à la méthode "e.InputParamaters".

En espérant que tous ces paramètres vous paraissent à présent moins barbare, bonne continuation...

INFOPATH : Bases de donnees

Beaucoup de personnes se demandent s'il est possible de connecter un formulaire Infopath à une base Oracle voir n'importe qu'elle autre base de données.

En effet, nativement, Infopath permet de se connecter uniquement à SQL Server (en passant par l'onglet connexions de données de l'interface) sans développement spécifique.

Mais il est tout de même possible de se connecter à n'importe quelle base par la puissance du code managé (C# ou VB.Net) en passant par un web service par exemple (ou un connecteur).

Il vous sera alors possible de vous connecter à n'importe qu'elle base à l'aide d'un peu de code personnalisé.

C'est là ou repose d'ailleurs la grande force d'infopath => le code managé, couplé à l'interface d'infopath , nous permet de réaliser à peu prêt tout ce que l'on souhaite...

INFOPATH : Retrouver HREF

Lorsque vous utilisez InfoPath, il peut-être parfois utile de récupérer la localisation exacte du template sur lequel vous travaillez (par exemple pour savoir sur quelle bibliothèque SharePoint le formulaire est publié).

Cette information est stockée dans la processing-instruction de chaque instance xml.

Pour la récupérer, il suffit d'utiliser la fonction "sous-chaine" présente dans l'éditeur de fonction InfoPath:

substring-before(substring-after(/processing-instruction(), 'href="'), '"')

Vous récupérerez donc l'information suivante:

• si le formulaire est publié sous SharePoint : http://NomServeur/sitecollection/NomBibliotheque/Forms/template.xsn
• si le formulaire est publié en local : T:/InfoPath/template.xsn,

Cette petite astuce vous permet de ne pas utiliser de code pour pouvoir retrouver tous les attributs de la PI (processing instruction) infopath : name,href,PIVersion,solutionVersion.

SHAREPOINT : Creation sous-site

La plupart de mes recherches sur le net pour créer un sous-site sharepoint à distance se sont soldées par des échecs...

Pour pouvoir créer un sous-site sous SharePoint à distance, il faut utiliser un web-service exposé par SharePoint. En effet le code managé ne fonctionne pas lorsque l'on est pas sur le serveur.

Beaucoup parlent de devoir créer un webservice custom car celui-ci n'existe pas par défaut sur SharePoint. Ce qui est complètement FAUX! Ce webservice existe bien sur WSS3 (et après quelques recherches, il existait aussi en WSS V2). Il s'agit du service "Meetings.asmx" et plus particulièrement de la web méthôde : "CreateWorkspace" qui permet de créer un sous-site rapidement). Le code à mettre en place est le suivant:

//Création du sous-site

RMN_Subsite.Meetings meetobj = new RMN_Subsite.Meetings();

RMN_Subsite.TimeZoneInf tz = new RMN_Subsite.TimeZoneInf();

meetobj.Credentials = myNetworkcreds;

meetobj.Url = string.Format("{0}/{1}", strUrlCollectionSite, "_vti_bin/meetings.asmx");

meetobj.CreateWorkspace(strNomSite, "STS", 1036, tz);

INFOPATH : Ouvrir nouveau formulaire

Il est parfois nécessaire d'ouvrir  un autre formulaire InfoPath depuis un formulaire existant.

Infopath permet d'utiliser d'utiliser les méthodes suivantes du modèle objet pour faire ce que l'on veut:

• Ouverture d'un nouveau formulaire vierge : Application.XDocuments.NewFromSolution(urlToXsnFile)
• Ouverture d'une instance XML déja créée : Application.XDocuments.Open(urlToXmlFile)

Il faut simplement connaitre l'url du template du formulaire Infopath ou de l'instance du formulaire pour utiliser ces méthodes.

INFOPATH : Performance formulaire Form Services

Dans un post précédent, je vous parlais des contrôles richtext et du problème de performances qu'ils pouvaient causer sur un formulaire 'Browser Enabled' (Form Services). Les performances sont souvent un sujet sensible lors du développement informatique.

Pour tous ceux qui sont soucieux d'obtenir de bonnes performances, les points suivants sont à respecter à la lettre:

http://blogs.msdn.com/infopath/archive/2008/06.aspx

Les principales causes de ralentissement repérées pour un formulaire "InfoPath Form Services" sont:

1. Connection réseau qui n'est pas bonne. Comme pour toutes les applis web, la vitesse de rendu dépend de la connexion... A la limite ça, on y peut rien.
2. Beaucoup de HTML à transformer. Si le formulaire comprend beaucoup de champs affichés sur une seule vue, il y aura beaucoup d'informations à transformer en HTML par le form services et le rendu ne sera pas immédiat. N'hésitez pas à découper votre template en plusieurs vues simple... Les performances n'en seront que meilleures.
3. Structure XML complexe. Plus la structure est complexe, plus le formulaire mettra du temps à s'afficher à l'écran de l'utilisateur.
4. Connexion de données. Attention à n'utiliser les connexions de données qu'au moment opportun et non pas toutes lors du chargement car cela risque de ralentir le formulaire. Il est préférable d'utiliser du code pour lancer la connexion de données quand vous le souhaitez.
5. Contrôles de saisie et postback. L'accumulation de contrôles de saisies et postback peut entrainer des ralentissements lors de la saisie du formulaire InfoPath.
6. Conditon de formatage. Définir un trop grand nombre de condition de formatage peut entrainer un ralentissement excessif du formulaire. J'ai eu le cas sur une section extensible conprenant 5 cases à cocher sur 300 lignes. L'affichage du formulaire mettait 1minute. Ceci est un cas extrème bien-sûr mais il faut faire attention lorsque l'on en utilise beaucoup sur des zones extensibles.
7. Contrôles Rich Text. Ce contrôle est à utiliser avec modération car son accumulation dégrade les performances d'InfoPath pour un formulaire browser enabled...

Si vous suivez les diverses conseils, il n'y a pas de raison que votre formulaire InfoPath Browser Enabled n'ait pas de très bonnes performances.

INFOPATH : Deployer sur Sharepoint

De nombreuses questions reviennent souvent sur les forum ou les blogs infopath au sujet du déploiement d'un formulaire InfoPath 2007...

Ce très bon article en anglais vous aidera très certaineemnt à vous guider lors du déploiement d'un formulaire (en fonction de votre formulaire : avec du code, formulaire navigateur, etc):

http://www.bizsupportonline.net/blog/2009/06/3-ways-deploy-infopath-form-templates-sharepoint/

Bonne lecture et bon déploiement...

INFOPATH : Rich Text

L'utilisation du richtext dans InfoPath permet d'avoir une richesse (!!!) supplémentaire par rapport à une page asp classique.

Voici deux codes qui peuvent être très utiles lorsque vous voulez manipuler ce genre de contrôle dans InfoPath 2007:

• Affectation d'un text au richtextbox en Csharp:
  
  XPathNavigator DOMNavigator = MainDataSource.CreateNavigator();
  DOMNavigator.SelectSingleNode("//my:rtfField", NamespaceManager).InnerXml = "Bonjour, ceci est un test";
  
  Nous aurons donc affiché "Ceci est un test".

• Ajout de valeurs au richtextbox en Csharp:
  
  XPathNavigator DOMNavigator = MainDataSource.CreateNavigator();
  DOMNavigator.SelectSingleNode("//my:rtfField",NamespaceManager).AppendChild("Ceci est le deuxième test.");

Attention toutefois: Je vous déconseille d'utiliser plus de 3 richtext box dans une même vue d'un formulaire Infopath Form Services.
En effet, si vous utilisez trop de "rich text control" dans un formulaire InfoPath Form Services, votre formulaire risque de ralentir singulièrement et certains contrôles auront des fonctionnements modifiés...