Compartilhar via

Práticas recomendadas do InfoPath Forms Services

  • Artigo

Atualizado em: 2006-12-01

Siga estas práticas recomendadas ao gerenciar o ambiente do InfoPath Forms Services.

Limite de 2.000 documentos nas bibliotecas de documentos do Windows SharePoint Services

Se um modelo de formulário será preenchido e enviado mais de 2.000 vezes no total, você deve escrever o código no modelo de formulário para o envio a um banco de dados por meio de um serviço Web ou criar uma função de envio personalizada que coloque formulários em várias bibliotecas. Isso se deve a uma limitação na capacidade de bibliotecas de documentos do Windows SharePoint Services 3.0, que pode ter uma redução de desempenho caso haja mais de 2.000 documentos na biblioteca.

Se você acreditar que um modelo de formulário possa ser enviado mais de 2.000 vezes, é mais fácil começar programando o formulário para usar um método alternativo de envio do que corrigir o problema quando ele ocorrer, principalmente se o modelo de formulário estiver disponível em um site publicamente acessível.

Use o Modo Formulário ao configurar o estado da sessão do InfoPath Forms Services

Você pode configurar o InfoPath Forms Services para usar o Serviço do Estado da Sessão (a opção padrão) ou o Modo Formulário para controlar a forma como sessões de usuário são gerenciadas. Quando você configura o InfoPath Forms Services para usar o Serviço do Estado da Sessão, todas as sessões de navegador são mantidas no banco de dados do SQL Server que corresponde ao SSP (Provedor de Serviços Compartilhados) associado ao aplicativo Web no qual o modelo de formulário é hospedado. Esse cenário usa pouca largura da banda de rede, mas tem um impacto de desempenho cumulativo no computador com o SQL Server. Quando você estiver usando o Modo Formulário, as sessões serão mantidas no navegador do cliente e todos os dados de sessão serão incluídos em cada postback ao servidor, até 40 kilobytes de dados de sessão. Isso usa mais largura de banda que o estado de sessão, mas não afeta o computador com o SQL Server. Quando os dados de sessão atingem 40 KB de tamanho, a sessão automaticamente alterna para o gerenciamento de estado de sessão.

Recomendamos o uso do Modo Formulário em ambientes com grupos menores de usuários, porque reduz o impacto sobre o SQL Server. Se a implantação do InfoPath Forms Services terá muitos usuários, principalmente se o volume de dados de sessão for menor que 40 KB para muitos modelos de formulário de uso intenso, o estado de sessão provavelmente é a melhor opção. Se o Modo Formulário for usado, a largura de banda de 40 KB por sessão do navegador, ou menor, pode ser monitorada, caso haja a preocupação de que o desempenho de rede possa ser prejudicado.

Não é recomendável executar o SQL Server em servidores Web front-end

Se o SQL Server for executado em um servidor Web front-end do Office SharePoint Server (por exemplo, em uma implantação de avaliação de servidor único), o cache do ASP.NET liberará memória do sistema em um limite mais baixo que o SQL Server, o que pode causar falta de memória para o InfoPath Forms Services.

O ASP.NET emprega a estratégia de definir o máximo de uso de memória dos Serviços de Informações da Internet (IIS) como 800 megabytes ou 60% da RAM física disponível (o que for menor). Essas opções podem ser configuradas no gerenciador do IIS. O ASP.NET também monitora o uso da RAM física, não só para o processo do w3wp.exe, mas para todo o sistema. Quando 80% da memória física no servidor estão confirmados, o ASP.NET começa a cancelar periodicamente os 5% de cache com a prioridade mais baixa e antiga. Quando 85% de memória física estão confirmados, o ASP.NET cancela periodicamente 50% do cache. Com 90% ou mais, o ASP.NET corta agressivamente o cache e define um limite baixo para o número máximo de entradas, que continua em vigor até que o ASP.NET reavalie a pressão de memória no servidor e aumente o limite.

O limite de uso de memória do SQL Server é mais alto por padrão do que o cache do ASP.NET. Nesse cenário, o SQL Server nunca libera memória, porque o cache do ASP.NET já terá liberado memória antes de o limite do SQL Server ser atingido. Essa situação pode conduzir a uma condição na qual o rendimento do InfoPath Forms Services seja reduzido com um impacto subsequente sobre o desempenho.

Para minimizar o problema, configure os limites de memória do SQL Server manualmente quando o SQL Server for instalado no mesmo computador que o Office SharePoint Server. Para obter mais informações sobre como ajustar as configurações de memória do SQL Server, consulte o artigo sobre opções de memória do servidor (https://msdn.microsoft.com/library/default.asp?url=/library/pt-br/adminsql/ad\_config\_9zfy.asp) no site da Microsoft.

Práticas recomendadas para formulários com acesso anônimo

Quando você implantar um formulário em um local em que ele esteja exposto a usuários anônimos, como uma biblioteca de documentos pública do SharePoint ou um formulário incorporado em uma página da Web na Internet, verifique a integridade do formulário. Há vários passos adicionais que você deve seguir para minimizar o risco de uso indevido do formulário, explorações de Negação de Serviço (DoS) e possíveis problemas de desempenho.

  • Certifique-se de que modelos de formulário não possam ser acessados por scripts ou outros processos automatizados. Um modo de garantir isso é forçar usuários que estão enviando modelos de formulário a digitar um código de identificação como uma cadeia de caracteres alfanumérica curta exibida em uma imagem que não possa ser "lida" por scripts ou processos automatizados.

  • Modelos de formulário que contenham informações confidenciais, como informações de autenticação, nomes de servidores ou bancos de dados ou código proprietário, nunca devem ser expostos a usuários anônimos.

  • Modelos de formulário que contenham uma conexão de envio de dados de email não devem ser implantados em servidores que permitam o acesso anônimo, pois as mensagens de email geradas quando o formulário for enviado exibirão "enviado por usuário anônimo" na linha de Assunto.

  • Modelos de formulário que contenham código ou funcionalidades que possam invocar processos em um servidor devem ser cuidadosamente avaliados e testados para garantir que a segurança não seja comprometida ao se tornar o modelo de formulário acessível a usuários anônimos.

  • Para impedir que usuários enviem várias cópias de um formulário, convém incluir código que localize o endereço IP de cada usuário que rastreie o formulário e impeça envios duplicados do mesmo endereço IP.

  • Proteja a integridade de modelos de formulário habilitando a proteção para impedir que o modelo de formulário seja alterado.