Passer au contenu principal
Connexion |
  Aide (nouvelle fenêtre)

dnt91's Blog [MVP SharePoint]

Lancer la recherche
dnt91's Blog [MVP SharePoint]
  

Catégories
Certifications
.net
C#
SQL Server
Produits & Technologies SharePoint
Windows Mobile
Divers
MS Project, Project Server, PWA...
InfoPath 2007, InfoPath Forms Services, Office Forms Server
Exchange Server 2010
Autres blogs
le blog de Jay
Gaetan Bouveret
Edgar Maucourant
Liens
Nos Articles
dnt91's Blog [MVP SharePoint] > Catégories

17/04/2008

Comment éviter (certaines) erreurs Event ID : 5566 avec InfoPath Forms Services

Récemment, en développement un formulaire « web enable », je me suis retrouvé confronté à une erreur « event id 5566 »

Après une longue investigation sur le web, j'ai pu glaner quelques infos, mais aucune ne fut utile dans mon cas ;

Certaines parlaient de désactiver l'accès anonyme (je ne l'avais pas appliqué) au niveau de l'application web, afin de récupérer un contexte d'exécution de l'utilisateur courant (http://www.dotnetking.com/TechnicalLog.aspx ),

D'autres de désactiver le renforcement de la sécurité d'internet explorer (qui était déjà dans mon cas désactivé) ou encore d'activer le proxy et de rajouter des adresses qui « bypassent » le proxy (dans mon cas, je n'utilisais pas de proxy, de plus je débogguais en local) (http://blogs.technet.com/jasbro/archive/2008/02/05/eventid-5566-troubleshooting-in-infopath-form-services.aspx ).

Et le plus étrange, c'est bien qu'ayant été jusqu'à mettre le niveau de log à verbeux en logguant tout, je n'avais aucune info dans mes fichiers de log concernant cet event ID.

Finalement, après quelques (ré)investigations (intempestives) de mon formulaire, ne sachant plus quoi faire, j'ai utilisé le design checker (qui est un outil plus utile qu'on ne le pense, meme quand on est certain d'avoir tout fait correctement), et la, quelle ne fut ma surprise de recevoir un message d'avertissement.

Tiens donc !

Après un rapide tour de mes sources de données, je me suis rendu compte que mes connexions secondaires, utilisées pour remplir mes listes déroulantes utilisaient des requêtes paramétrées, mais surtout étaient (malencontreusement) configurée pour récupérer les données au chargement du formulaire, sauf qu'au moment du chargement du formulaire, mes paramètres ne sont pas encore initialisés !

Depuis, tout fonctionne à merveille.

Moralité : Pensez au design checker, il vous fera gagner des heures !

Publié à 22:29 par N'TAMACK Dieudonne | Catégorie: InfoPath 2007, InfoPath Forms Services, Office Forms Server | Lien permanent | Envoi de cette publication par courrier électronique | Commentaires (2)

26/03/2008

Quelques paramètres de QueryString à connaitre

Je vous présentais déjà dans un précédent post comment forcer l'ouverture de vos formulaires, soit depuis le client InfoPath 2007 (si ce dernier est installé sur le poste), soit depuis le navigateur web en passant le paramètre de QueryString OpenIn.

Ce post vient donc compléter la liste des paramètres utilisables avec InfoPath Forms Services et votre navigateur web.

Les paramètres sont les suivants :

  • XmlLocation=url_du_formulaire, va nous permettre d'ouvrir un formulaire déjà existant et présent sur notre serveur (les données InfoPath sont enregistrées au format XML et portent l'extension .xml).
  • XslLocation=url_du_modele, va nous permettre de créer un nouveau formulaire basé sur un modèle de formulaire InfoPath présent sur notre serveur (les modèles InfoPath portent l'extension .xsn).
  • Source=url_dans_la_collection, va nous permettre de rediriger l'utilisateur lors de la fermeture du formulaire.
  • Option=DisableSave, va nous permettre de désactiver les boutons et options de sauvegarde
  • SaveLocation=url_dossier_existant, affiche une boite de dialogue afin d'enregistrer notre formulaire dans le dossier spécifié

  • NoRedirect=false(par défaut)/true, si la valeur est true, ne fait pas le test de détection du client et propose de télécharger le formulaire en local.

Quelques remarques sur l'utilisation de ces paramètres :

  1. On ne peut pas passer les 2 paramètres XmlLocation & XsnLocation dans la même QueryString, ce qui à mon sens parait normal, car cela signifierait que l'on souhaite ouvrir à la fois un nouveau fichier basé sur un modèle InfoPath et un fichier existant.

  2. Pour éviter de se retrouver sur une page « Le formulaire a été fermé » lors de l'utilisation du paramètre XslLocation, il convient de le coupler avec les paramètres SaveLocation pour spécifier un dossier de sauvegarde et Source pour rediriger ensuite l'utilisateur. Ci-dessous, voici le résultat de l'ouverture d'un formulaire en spécifiant ces 3 paramètres (url = http://pc-de-test/sites/wssdev/_layouts/FormServer.aspx?XsnLocation=http://pc-de-test/sites/wssdev/Formulaire%20Projet/Forms/template.xsn&SaveLocation=http%3A%2F%2Fpc%2Dde%2Dtest%2Fsites%2Fwssdev%2FFormulaire%20Projet&Source=http%3A%2F%2Fpc%2Dde%2Dtest%2Fsites%2Fwssdev%2FFormulaire%2520Projet%2FForms%2FAllItems%2Easpx)

  3. Il existe un dernier paramètre, DefaultItemOpen, utilisé par SharePoint pour spécifié si le formulaire doit être ouvert dans le navigateur (valeur = 1) ou de télécharger le fichier (valeur = 0).
Publié à 01:44 par N'TAMACK Dieudonne | Catégorie: InfoPath 2007, InfoPath Forms Services, Office Forms Server | Lien permanent | Envoi de cette publication par courrier électronique | Commentaires (0)

11/03/2008

Forcer l’ouverture d’un formulaire dans le navigateur

Comme vous le savez surement déjà tous, il est possible de spécifier dans les paramètres d'une doclib que l'on souhaite ouvrir un document Office soit depuis le navigateur, soit depuis une application cliente.

Cependant, avec Infopath, les choses se passent un peu différemment.

Tout d'abord, les documents Office « classiques » (Word, Excel) ouvert de cette facon le sont grace à des visionneuses, et sont donc accessible uniquement en lecture seule, tandis que grâce aux InfoPath Forms Services, nous allons pouvoir éditer nos formulaires directement depuis le navigateur web.

L'autre particularité, c'est que nous avons également la possibilté, en passant le paramètre OpenIn à l'url, de spécifier le mode d'ouverture de notre formulaire.

Pour cela, nous avons 4 possibilités :

  • OpenIn=Browser, force l'ouverture dans le navigateur
  • OpenIn=Client, force l'ouverture dans InfoPath 2007, ou propose de récupérer le fichier
  • OpenIn=PreferClient, si InfoPath est installé sur le client, l'ouvre avec, sinon l'ouvre depuis le navigateur
  • OpenIn=Mobile, redirige la requete vers MobileFormServer.aspx, responsable du rendu mobile du formulaire

Voici les résultats obtenu pour chacune des valeurs :

OpenIn=Browser, le formulaire s'affiche dans le navigateur.

OpenIn=Client, une boite de dialogue « SaveAs » apparait

OpenIn=PreferClient, dans notre cas, la doclib est configuré comme ci-dessus pour permettre un affichage directement dans le navigateur, et nous avons l'application InfoPath 2007 installée en local ; dans ce cas, InfoPath nous propose de le récupérer depuis le client.

OpenIn=Mobile, dans notre cas, le formulaire n'est pas concu pour un affichage mobile, aussi nous obtenons des erreurs. Le plus important ici est de noter l'appel à la page MobileFormServer.apsx.

Publié à 23:39 par N'TAMACK Dieudonne | Catégorie: InfoPath 2007, InfoPath Forms Services, Office Forms Server | Lien permanent | Envoi de cette publication par courrier électronique | Commentaires (0)