Procedimientos recomendados para InfoPath Forms Services

Se recomienda seguir estos procedimientos recomendados al administrar el entorno de InfoPath Forms Services.

Límite de 2.000 documentos en las bibliotecas de documentos de Windows SharePoint Services

Si una plantilla de formulario se va a rellenar y enviar más de 2.000 veces en total, debe escribir código en la plantilla de formulario para que envíe los datos a una base de datos mediante un servicio web o crear una función de envío personalizada que coloque formularios en varias bibliotecas. Esto se debe a un límite en la capacidad de las bibliotecas de documentos de Windows SharePoint Services 3.0, cuyo rendimiento puede disminuir si hay más de 2.000 documentos en la biblioteca.

Si cree que es posible que una plantilla de formulario se envíe más de 2.000 veces, es más sencillo empezar por programar el formulario para que use un método de envío alternativo que corregir esta situación cuando ya se haya convertido en un problema, especialmente si la plantilla de formulario está disponible en un sitio web de acceso público.

Uso de la vista Formulario al configurar el estado de sesión para InfoPath Forms Services

Se puede configurar InfoPath Forms Services para que use el servicio de estado de sesión (la opción predeterminada) o la vista Formulario para controlar la forma en que se administran las sesiones de usuario. Si configura InfoPath Forms Services para usar el servicio de estado de sesión, todas las sesiones del explorador se mantienen en la base de datos de SQL Server correspondiente al proveedor de servicios compartidos (SSP) asociado con la aplicación web que hospeda la plantilla de formulario. En este escenario se usa poco ancho de banda de red, pero tiene un impacto acumulativo en el rendimiento del equipo que ejecuta SQL Server. Si se usa la vista Formulario, las sesiones se mantienen en el explorador cliente y todos los datos de sesión se incluyen en cada devolución al servidor, hasta 40 KB de datos de sesión. En este caso, se usa más ancho de banda que con el estado de sesión, pero el equipo que ejecuta SQL Server no queda afectado. Cuando el tamaño de los datos de sesión alcanza los 40 KB, la sesión pasa automáticamente a la administración de estado de sesión.

Se recomienda usar la vista Formulario en entornos con grupos más pequeños de usuarios, ya que reduce el impacto en SQL Server. Si la implementación de InfoPath Forms Services va a tener muchos usuarios, especialmente si los datos de sesión son inferiores a 40 KB para muchas de las plantillas de formulario de uso intensivo, el estado de sesión es probablemente una mejor opción. Si se usa la vista Formulario, el ancho de banda que usarán las sesiones del explorador de 40 KB o menos puede supervisarse si le preocupa que el rendimiento de la red se vea afectado negativamente.

No se recomienda ejecutar SQL Server en un servidor cliente web

Si ejecuta SQL Server en un servidor cliente web de Office SharePoint Server (por ejemplo, en una implementación de evaluación en un único servidor), la memoria caché de ASP.NET liberará memoria del sistema en un umbral inferior al de SQL Server, lo cual podría causar una falta de memoria en InfoPath Forms Services.

La estrategia de ASP.NET consiste en dirigir el uso de memoria máximo de Internet Information Services (IIS) a lo que sea menor: 800 MB o el 60% de la memoria RAM disponible. Estos valores se pueden configurar en el Administrador de IIS. ASP.NET también supervisa el uso de RAM física, no sólo para el proceso w3wp.exe, sino para todo el sistema. Cuando se asigna el 80% de la memoria física del servidor, ASP.NET empieza a descartar periódicamente el 5% más antiguo y con menor prioridad de la memoria caché. Cuando se asigna el 85% de la memoria física, ASP.NET descarta el 50% de la memoria caché de forma periódica. Cuando se alcanza el 90% o más, ASP.NET recorta de forma agresiva la memoria caché y establece un límite bajo en el número máximo de entradas, que permanece en vigor hasta que ASP.NET vuelve a evaluar la presión de la memoria en el servidor y aumenta el umbral.

De forma predeterminada, el umbral de uso de memoria de SQL Server es más alto que el de la memoria caché de ASP.NET. En este escenario, SQL Server no libera nunca memoria, porque la memoria caché de ASP.NET ya habrá liberado memoria antes de alcanzar el umbral de SQL Server. Esta situación puede dar lugar a un estado en que se reduce la capacidad de InfoPath Forms Services, con el consiguiente impacto en el rendimiento.

Para mitigar este problema, debe configurar los límites de memoria de SQL Server manualmente si SQL Server está instalado en el mismo equipo donde está instalado Office SharePoint Server. Para obtener más información acerca de cómo ajustar la configuración de memoria de SQL Server, vea el artículo acerca de las opciones de memoria del servidor (en inglés) (https://msdn.microsoft.com/es-es/library/aa196734.aspx) (en inglés) en el sitio web de Microsoft.

Procedimientos recomendados para los formularios accesibles de forma anónima

Al implementar un formulario en una ubicación donde se expone a usuarios anónimos, como una biblioteca de documentos pública de SharePoint o un formulario incrustado en una página web de Internet, garantice la integridad del formulario. Hay varios pasos adicionales que debe realizar para mitigar el riesgo de un uso incorrecto del formulario, ataques de denegación de servicio (DoS) y posibles problemas de rendimiento.

• Asegúrese de que ni los scripts ni otros procesos automatizados puedan obtener acceso a las plantillas de formulario. Una forma de lograrlo es hacer que los usuarios que envían plantillas de formulario especifiquen un código de identificación, como una pequeña cadena alfanumérica que se muestre en una imagen, que un script o un proceso automatizado no pueden "leer".

• Las plantillas de formulario que contienen información confidencial, como información de autenticación, nombres de servidores o bases de datos, o códigos de propiedad, no se deben exponer nunca a usuarios anónimos.

• Las plantillas de formulario que contienen una conexión de datos de envío de correo electrónico no se deben implementar en servidores accesibles de forma anónima, puesto que los mensajes de correo electrónico generados al enviar el formulario mostrarán una indicación de envío por parte de un usuario anónimo en la línea Asunto.

• Las plantillas de formulario que contienen código o funcionalidad que puede invocar procesos en un servidor deben evaluarse cuidadosamente y comprobarse para garantizar que la seguridad no se pone en peligro al permitir el acceso a la plantilla a usuarios anónimos.

• Para evitar que los usuarios envíen varias copias de un formulario, puede plantearse la posibilidad de incluir código que realice el seguimiento de la dirección IP de cada usuario que envía un formulario y evite envíos duplicados desde la misma dirección IP.

• Para proteger la integridad de las plantillas de formulario, habilite la protección para impedir modificaciones en la plantilla de formulario.