Méthodes conseillées pour InfoPath Forms Services

  • Article

Mise à jour : 2006-12-01

Nous vous recommandons de suivre ces méthodes conseillées lors de la gestion de votre environnement InfoPath Forms Services.

Limite de 2 000 documents dans les bibliothèques de documents Windows SharePoint Services

Si un modèle de formulaire est rempli et envoyé plus de 2 000 fois au total, vous devez soit écrire du code dans le modèle de formulaire à soumettre à une base de données en utilisant un service Web, soit créer une fonction d’envoi personnalisée qui place les formulaires dans plusieurs bibliothèques. Cela est dû à une limite de la capacité des bibliothèques de documents Windows SharePoint Services 3.0, qui peut entraîner une dégradation des performances si plus de 2 000 documents existent dans la bibliothèque.

Si vous pensez qu’un modèle de formulaire peut être envoyé plus de 2 000 fois, il est plus facile de commencer par programmer le formulaire pour utiliser une autre méthode d’envoi que de résoudre ce problème une fois qu’il est détecté, en particulier si le modèle de formulaire est disponible pour un site Web accessible publiquement.

Utiliser le mode formulaire lors de la configuration de l’état de session pour InfoPath Forms Services

Vous pouvez configurer InfoPath Forms Services pour utiliser le service d’état de session (option par défaut) ou le Mode Formulaire pour contrôler la manière dont les sessions utilisateur sont gérées. Lorsque vous configurez InfoPath Forms Services pour utiliser le service d’état de session, toutes les sessions de navigateur sont gérées sur la base de données SQL Server correspondant au fournisseur de services partagés associé à l’application Web sur lequel le modèle de formulaire est hébergé. Ce scénario utilise peu de bande passante réseau mais a un impact sur les performances cumulées sur l’ordinateur qui exécute SQL Server. Lorsque vous utilisez le mode Formulaire, les sessions sont conservées sur le navigateur client, et toutes les données de session sont incluses dans chaque publication sur le serveur, jusqu’à 40 kilo-octets de données de session. Ce mode utilise davantage de bande passante que l’état de session, mais n’affecte pas l’ordinateur qui exécute SQL Server. Une fois que la taille des données de session a atteint 40 Ko, la session passe automatiquement à la gestion d’état de session.

Il est recommandé d’utiliser le mode Formulaire dans des environnements impliquant de petits groupes d’utilisateurs, car cette méthode a un impact moindre sur l’ordinateur qui exécute SQL Server. En revanche, si votre déploiement d’InfoPath Forms Services doit comporter de nombreux utilisateurs, en particulier si la taille des données de session est inférieure à 40 Ko pour la plupart des modèles de formulaire à forte utilisation, il est préférable de choisir la méthode d’état de session. En mode Formulaire, vous pouvez surveiller la bande passante utilisée par les sessions de navigateur de 40 Ko maximum si vous pensez que cela risque de nuire aux performances du réseau.

Il n’est pas recommandé d’exécuter SQL Server sur un serveur Web frontal

Si vous exécutez SQL Server sur un serveur Web frontal Office SharePoint Server (par exemple, dans un déploiement d’évaluation à un seul serveur), le cache ASP.NET libère la mémoire système à un seuil plus faible que SQL Server, ce qui pourrait entraîner une insuffisance de mémoire dans InfoPath Forms Services.

ASP.NET utilise une stratégie de ciblage de l’utilisation de la mémoire maximale des services Internet (IIS), de 800 mégaoctets ou 60 % de RAM physique disponible, la plus faible utilisation l’emportant. Ces paramètres sont configurables dans le Gestionnaire des services IIS. ASP.NET surveille également l’utilisation de la RAM physique, pas seulement pour le processus W3wp.exe, mais pour l’ensemble du système. Lorsque 80 % de la mémoire physique sur le serveur est validée, ASP.NET supprime régulièrement 5 % de la plus ancienne et la plus basse priorité du cache. Lorsque 85 % de mémoire physique est validée, ASP.NET supprime régulièrement 50 % du cache. À 90 % ou plus, ASP.NET tronque de manière agressive le cache et définit une limite faible sur le nombre maximal d’entrées, qui reste en vigueur jusqu’à ce qu’ASP.NET réévalue la pression de la mémoire sur le serveur et déclenche le seuil.

Le seuil d’utilisation de la mémoire pour SQL Server est plus élevé par défaut que le cache ASP.NET. Dans ce scénario, SQL Server ne libère jamais la mémoire, étant donné que le cache ASP.NET a déjà libéré de la mémoire avant que le seuil de SQL Server ne soit atteint. Cette situation peut conduire à une condition dans laquelle le débit d’InfoPath Forms Services est réduit avec un impact sur les performances.

Pour atténuer ce problème, vous devez configurer des limites de mémoire SQL Server manuellement lorsque SQL Server est installé sur le même ordinateur qu’Office SharePoint Server. Pour plus d’informations sur le réglage des paramètres de mémoire SQL Server, voir Options de mémoire serveur (https://msdn.microsoft.com/library/default.asp?url=/library/en-us/adminsql/ad\_config\_9zfy.asp) sur le site Web de Microsoft.

Méthodes conseillées pour les formulaires accessibles de manière anonyme

Lorsque vous déployez un formulaire dans un emplacement où il est exposé aux utilisateurs anonymes, comme une bibliothèque de documents SharePoint publique ou un formulaire incorporé dans une page Web sur Internet, assurez l’intégrité de votre formulaire. Il existe plusieurs étapes supplémentaires que vous devez effectuer pour atténuer le risque d’utilisation inappropriée, les attaques par déni de service et les problèmes de performances potentiels.

  • Vous devez vous assurer que les modèles de formulaires ne sont pas accessibles par des scripts ou d’autres processus automatisés ou non humains. Vous pouvez pour cela obliger les utilisateurs qui envoient un modèle de formulaire à entrer un code d’identification, par exemple une courte chaîne alphanumérique affichée dans une image, qui ne peut pas être « lue » par un script ou un processus automatisé.

  • Les modèles de formulaires qui contiennent des informations sensibles telles que des informations d’authentification, des noms de serveur ou de base de données ou du code propriétaire ne doivent jamais être proposés aux utilisateurs anonymes.

  • Les modèles de formulaires qui contiennent une connexion de données d’envoi de message électronique ne doivent pas être déployés sur les serveurs qui sont accessibles de manière anonyme, car les messages électroniques générés lorsque le formulaire est envoyé affichent « envoyé par utilisateur anonyme » dans la ligne Objet.

  • Les modèles de formulaires qui contiennent du code ou des fonctionnalités qui peuvent appeler des processus sur un serveur doivent être évalués et testés soigneusement pour garantir que la sécurité ne peut pas être compromise en rendant le modèle de formulaire accessible aux utilisateurs anonymes.

  • Pour empêcher les utilisateurs d’envoyer plusieurs exemplaires d’un formulaire, vous pouvez inclure du code qui détecte l’adresse IP de chaque utilisateur qui envoie un formulaire et empêcher ainsi les envois en double à partir de la même adresse IP.

  • Pour protéger l’intégrité des modèles de formulaires, activez la protection afin d’empêcher la modification du modèle de formulaire.