Bewährte Methoden für InfoPath Forms Services

  • Artikel

Bei der Verwaltung Ihrer InfoPath Forms Services-Umgebung sollten Sie die folgenden bewährten Methoden befolgen.

Maximal 2.000 Dokumente in Windows SharePoint Services-Dokumentbibliotheken

Wenn eine Formularvorlage insgesamt mehr als 2.000-mal ausgefüllt und gesendet werden soll, sollten Sie entweder Code in die Formularvorlage schreiben, um die Daten mithilfe eines Webdiensts an eine Datenbank zu senden, oder eine benutzerdefinierte Sendefunktion erstellen, mit der Formulare in mehreren Bibliotheken platziert werden. Der Grund hierfür ist eine Einschränkung in der Kapazität von Windows SharePoint Services 3.0-Dokumentbibliotheken: Bei mehr als 2.000 Dokumenten in der Bibliothek können Leistungseinbußen auftreten.

Wenn Sie davon ausgehen, dass eine Formularvorlage mehr als 2.000-mal gesendet werden könnte, ist es in der Regel einfacher, von vornherein eine alternative Sendemethode für das Formular zu programmieren, als das Problem nachträglich zu korrigieren, insbesondere, wenn die Formularvorlage auf einer öffentlich zugänglichen Website verfügbar ist.

Verwenden der Formularansicht beim Konfigurieren des Sitzungsstatus für InfoPath Forms Services

Sie können InfoPath Forms Services so konfigurieren, dass entweder der Sitzungsstatusdienst (die Standardoption) oder die Formularansicht verwendet wird, um die Verwaltung von Benutzersitzungen zu steuern. Wenn Sie InfoPath Forms Services so konfigurieren, dass der Sitzungsstatusdienst verwendet wird, werden alle Browsersitzungen in der SQL Server-Datenbank verwaltet, die dem Anbieter für gemeinsame Dienste (Shared Services Provider, SSP) für die Webanwendung entspricht, von der die Formularvorlage gehostet wird. In diesem Szenario wird eine geringe Netzwerkbandbreite beansprucht, es hat jedoch einen kumulativen Effekt auf die Leistung des Computers mit SQL Server. Wenn Sie die Formularansicht verwenden, werden die Sitzungen im Clientbrowser verwaltet, und alle Sitzungsdaten werden bei jedem Postback an den Server aufgenommen – bis zu 40 KB an Sitzungsdaten. Dabei wird eine höhere Bandbreite als für den Sitzungsstatus verwendet, der Computer mit SQL Server wird jedoch nicht beeinträchtigt. Wenn die Sitzungsdaten eine Größe von 40 KB erreichen, geht die Sitzung automatisch in die Sitzungsstatusverwaltung über.

Die Verwendung der Formularansicht empfiehlt sich in Umgebungen mit kleineren Benutzergruppen, da damit die Auswirkungen auf SQL Server reduziert werden. Wenn in der InfoPath Forms Services-Bereitstellung viele Benutzer vorhanden sind, insbesondere dann, wenn die Sitzungsdaten für viele häufig verwendete Formularvorlagen kleiner als 40 KB sind, ist der Sitzungsstatus wahrscheinlich die bessere Wahl. Wenn die Formularansicht verwendet wird, kann die von Browsersitzungen mit einer Größe von maximal 40 KB verwendete Bandbreite überwacht werden, wenn Bedenken vorliegen, dass die Netzwerkleistung beeinträchtigt werden könnte.

Die Ausführung von SQL Server auf einem Front-End-Webserver wird nicht empfohlen

Wenn Sie SQL Server auf einem Front-End-Webserver mit Office SharePoint Server ausführen (z. B. in einer Evaluierungsbereitstellung mit einem einzigen Server), wird vom ASP.NET-Cache Systemspeicher bei einem niedrigeren Schwellenwert freigegeben als in SQL Server, was ungenügenden Arbeitsspeicher in InfoPath Forms Services zur Folge haben könnte.

In ASP.NET wird eine Strategie genutzt, nach der eine maximale IIS-Speicherauslastung (Internetinformationsdienste) von 800 MB oder 60 % des physischen Arbeitsspeichers (je nachdem, was zuerst erreicht wird) angestrebt wird. Diese Einstellungen können im IIS-Manager konfiguriert werden. In ASP.NET wird zudem die physische Arbeitsspeicherauslastung nicht nur für den Prozess w3wp.exe, sondern für das gesamte System überwacht. Wenn 80 % des physischen Arbeitsspeichers auf dem Server zugesichert sind, werden von ASP.NET zunächst regelmäßig die 5 % der Daten aus dem Cache gelöscht, die am ältesten sind oder die niedrigste Priorität aufweisen. Wenn 85 % des physischen Arbeitsspeichers zugesichert sind, werden von ASP.NET regelmäßig 50 % des Caches gelöscht. Ab 90 % wird der Cache von ASP.NET stark gekürzt und ein niedriges Limit für die maximale Anzahl von Einträgen festgelegt, das gültig bleibt, bis der Arbeitsspeicher auf dem Server von ASP.NET neu bewertet und der Schwellenwert erhöht wird.

Der Schwellenwert für die Speicherauslastung ist für SQL Server standardmäßig höher als für den ASP.NET-Cache. In diesem Szenario gibt SQL Server niemals Arbeitsspeicher frei, da vom ASP.NET-Cache bereits Arbeitsspeicher freigegeben wurde, bevor der SQL Server-Schwellenwert erreicht wird. Diese Situation kann zu einer Bedingung führen, in der der Durchsatz von InfoPath Forms Services reduziert und nachfolgend die Leistung entsprechend beeinträchtigt wird.

Sie können dieses Problem verringern, indem Sie Speicherlimits für SQL Server manuell konfigurieren, wenn SQL Server auf demselben Computer wie Office SharePoint Server installiert ist. Weitere Informationen zum Anpassen der Arbeitsspeichereinstellungen für SQL Server finden Sie im Artikel Serverspeicheroptionen (in englischer Sprache) (https://msdn.microsoft.com/de-de/library/aa196734.aspx) (in englischer Sprache) auf der Microsoft-Website.

Bewährte Methoden für anonym zugängliche Formulare

Wenn Sie ein Formular an einem Speicherort bereitstellen, an dem es für anonyme Benutzer zugänglich ist, z. B. in einer öffentlichen SharePoint-Dokumentbibliothek oder einem eingebetteten Formular auf einer Webseite im Internet, müssen Sie die Integrität des Formulars sicherstellen. Es sind mehrere zusätzliche Schritte notwendig, um das Risiko einer unsachgemäßen Formularnutzung, von Denial-of-Service-Exploits und potenziellen Leistungsproblemen abzuwehren.

  • Stellen Sie sicher, dass Skripts oder andere automatisierte Prozesse nicht auf die Formularvorlagen zugreifen können. Eine Möglichkeit, mit der dies erreicht werden kann, besteht darin, die Benutzer, die eine Formularvorlage senden, zur Eingabe eines Identifikationscodes (z. B. einer in einem Bild angezeigten alphanumerischen Zeichenfolge) zu zwingen, der nicht von einem Skript oder einem automatisierten Prozess "gelesen" werden kann.

  • Formularvorlagen mit vertraulichen Informationen (z. B. mit Authentifizierungsinformationen, Server- oder Datenbanknamen oder proprietärem Code) dürfen niemals für anonyme Benutzer verfügbar gemacht werden.

  • Formularvorlagen mit einer E-Mail-Datenverbindung zum Senden von Daten sollten nicht auf Servern bereitgestellt werden, auf die anonym zugegriffen werden kann, da in der Betreffzeile der E-Mail-Nachrichten, die beim Senden des Formulars generiert werden, angezeigt wird, dass sie von einem anonymen Benutzer gesendet wurden.

  • Formularvorlagen mit Code oder Funktionen, die Prozesse auf einem Server auslösen können, müssen sorgfältig ausgewertet und getestet werden, um sicherzustellen, dass die Sicherheit nicht beeinträchtigt werden kann, wenn der Zugriff auf die Formularvorlage für anonyme Benutzer ermöglicht wird.

  • Wenn Sie verhindern möchten, dass Benutzer mehrere Kopien eines Formulars senden, können Sie Code aufnehmen, mit dem die IP-Adresse jedes Benutzers nachverfolgt wird, der ein Formular sendet, und mit dem doppelte Sendevorgänge von derselben IP-Adresse verhindert werden.

  • Schützen Sie die Integrität von Formularvorlagen, indem Sie den Schutz vor Änderungen der Formularvorlage aktivieren.