SharePoint

Criação de uma infra-estrutura de pesquisa avançada

Jim Bradley

Visão geral:

• Planejamento e implementação de uma solução de pesquisa
• Coleta e processamento de resultados de pesquisa em bibliotecas do SharePoint
• Gerenciamento de problemas de desempenho e segurança

Você não pode tomar boas decisões sem informações. Desconfianças não são suficientes – não quando suas decisões irão ter um impacto nos seus negócios. Isso é verdadeiro quer você esteja decidindo onde realizar uma festa

da equipe ou se estiver considerando a realocação de 50% dos recursos de sua empresa para o lançamento de um novo produto. Mas como você pode conseguir essa informação?

As pesquisas fornecem um método eficaz – e econômico – de obter comentários sobre tudo, desde o quanto os clientes estão satisfeitos com suas ofertas de produtos a se os funcionários gostaram ou não dos sanduíches oferecidos na última reunião da equipe. As pesquisas produzem a substância necessária para futuros aprimoramentos e desenvolvimento de produtos, sistemas ou processos. A pergunta é, como você, o profissional de TI, implementará um sistema de pesquisa que possa coletar dados e armazená-los de modo que as informações possam ser usadas de formas significativas?

Você provavelmente já tem uma ou mais das ferramentas necessárias para coletar, estruturar e analisar esse tipo de dados. O 2007 Microsoft® Office system fornece essas ferramentas e facilita seu uso. Na realidade, há várias formas para se realizar uma pesquisa. O segredo é selecionar a abordagem compatível com as suas necessidades específicas. Por exemplo, pesquisas com base em emails são uma boa escolha para coleta de dados improvisada em tempo real ao lidar com um pequeno número de pesquisados e dados não críticos. Para obter mais informações, consulte a barra lateral a seguir "Uso de email para pesquisas rápidas". Por outro lado, as pesquisas orientadas por bancos de dados são uma melhor escolha para iniciativas mais complexas que incluem um grupo maior de pesquisados relativos a dados considerados essenciais. Para obter mais informações sobre esse tópico, consulte a barra lateral a seguir "Criação de uma solução de pesquisa orientada por bancos de dados”.

Neste artigo, o foco será outra solução mais abrangente e flexível. As pesquisas online baseadas no SharePoint®. Essa abordagem é adequada para pesquisas essenciais e não essenciais de qualquer nível de complexidade. Como as pesquisas do SharePoint são baseadas na Web, elas podem ser concluídas por qualquer pessoa que acessar um navegador da Web – até mesmo dispositivos móveis são compatíveis. Com uma pesquisa do SharePoint, as respostas podem ser nomeadas ou anônimas, resultados em tempo real estão disponíveis e você tem acesso até mesmo a ferramentas de análise.

Esse tipo de pesquisa é implementado usando o Windows® SharePoint Services 3.0 (WSS) com Forms Server e o InfoPath® ou Microsoft Office SharePoint Server 2007 (MOSS) com Forms Services e o InfoPath® (consulte a Figura 1 para obter uma descrição de cada uma dessas tecnologias). Como esses cenários oferecem essencialmente a mesma funcionalidade, nesta discussão me concentrarei nesta última combinação. Para obter uma comparação abrangente dos produtos do SharePoint e sua funcionalidade, consulte o Microsoft Office SharePoint Server 2007 Products Comparison Download em office.microsoft.com/en-us/sharepointserver/HA101978031033.aspx.

Figure 1 Tecnologias Microsoft que habilitam pesquisas do SharePoint

Planejamento e implementação

Ao criar uma pesquisa, você precisa considerar vários fatores com antecedência. Isso requer certa análise anterior; portanto, reserve um período para desenvolver um plano de pesquisa bem elaborado. No estágio inicial do planejamento, você definirá o problema e o tipo de dados que deseja obter, determinará as tecnologias que precisará usar e estabelecerá os requisitos orçamentários e administrativos. Em seguida, você poderá prosseguir com a implementação. O fluxo de trabalho geral é criar um formulário de pesquisa, publicá-lo, coletar e validar respostas, agregar e analisar os dados e, em seguida, relatar os resultados.

Um fluxo de trabalho de implementação de pesquisa geralmente inclui pelo menos um designer de pesquisa, pesquisados e um analista (como mostra a Figura 2). É claro, os fluxos de trabalho de pesquisa podem variar muito em complexidade. Uma pesquisa abrangendo toda a empresa, por exemplo, provavelmente teria várias edições e aprovações de design. Ela provavelmente utilizaria lembretes automatizados para os pesquisados, ofereceria várias formas de suporte e solução de problemas, forneceria exibições em tempo real nos resultados para os gerentes e teria um processo claro para determinar e fornecer a análise final. Um fluxo de trabalho complexo desse tipo realmente exigiria um sistema baseado na Web que oferecesse suporte a recursos de fluxo de trabalho e relatórios.

Figura 2** Um fluxo de trabalho de pesquisa desde a criação de formulários até a análise de dados **(Clique na imagem para aumentar a exibição)

O que procurar em uma solução abrangente

Há uma longa lista de requisitos importantes que você deve esperar que uma solução de pesquisa abrangente atenda. A solução deve permitir que equipes individuais ou unidades de negócio criem, distribuam e coletem resultados de pesquisa com o mínimo envolvimento do departamento de TI – e isso não deve exigir habilidades de programação. A ferramenta de criação de formulários deve oferecer uma interface WYSIWYG fácil de usar, bem como um conjunto avançado de recursos que facilite a canalização, a ramificação e a lógica condicional. E, não é preciso dizer, a ferramenta de criação de formulários de pesquisa deve acomodar todas as pesquisas, independentemente do tamanho e da complexidade.

Além disso, a pesquisa deve ser executada em um servidor Web e integrada com um banco de dados SQL Server® mantido centralmente, eliminando a necessidade de departamentos individuais para manter bancos de dados SQL dedicados. Qualquer pesquisado com acesso à Internet poderá responder à pesquisa de qualquer navegador em conformidade com os padrões.

O processo de pesquisa deve ser facilmente vinculado a fluxos de trabalho e deve atender a necessidades comerciais sem comprometer a segurança. E, para muitas organizações, a solução de pesquisa deve fornecer suporte a vários idiomas.

Quando utilizados juntos, o MOSS 2007, o WSS 3.0 e o InfoPath 2007 criam uma solução integrada que soluciona todos esses requisitos. A Figura 3 mostra como os vários componentes se encaixam na pilha do SharePoint. Mas antes de me aprofundar nessa solução de pesquisa completa, quero apresentar rapidamente o que você pode atingir apenas com o WSS. Em seguida, mostrarei a você as vantagens agregadas que você terá ao adicionar o MOSS e o InfoPath a essa combinação.

Figura 3** Componentes da pilha do SharePoint **(Clique na imagem para aumentar a exibição)

Como trabalhar somente com o WSS

Mesmo sem os outros componentes, você pode usar o WSS para criar e implementar uma pesquisa. Na realidade, o WSS inclui um modelo de pesquisa interno que facilita o processo. Para criar uma pesquisa, clique em Iniciar | Todos os programas | Ferramentas administrativas e selecione Administração Central do SharePoint 3.0. A partir da lista suspensa, selecione Ações de Site e, em seguida, clique em Criar. A página Criar será exibida, mostrando a você os cabeçalhos para Bibliotecas, Comunicações, Controle, Listas personalizadas e Páginas da Web. Em cada cabeçalho, há opções de modelo. Em Controle, clique em Pesquisa.

Nesse momento, o WSS o conduzirá por todas as etapas do processo de criação de pesquisa. Você pode criar perguntas abertas ou fechadas e especificar se uma pergunta pode ficar sem resposta. Você também pode criar pesquisas lógicas de ramificação, que conduzirão os pesquisados a diferentes caminhos, dependendo das suas respostas. As pesquisas podem ser anônimas ou, se necessário, identificar o pesquisado. Você também tem a opção de atribuir um fluxo de trabalho à pesquisa.

A pesquisa é baseada no navegador; portanto, nenhum software especial é necessário para criar ou responder a pesquisa. Para responder a pesquisa, os pesquisados simplesmente acessam o site do SharePoint e preenchem o formulário. As permissões de acesso são herdadas do site pai mas pode ser editadas diretamente a partir do menu de Ações do SharePoint. As respostas da pesquisa são salvas no site de pesquisa do SharePoint e os resultados podem ser visualizados no formulário da lista ou em resumos gráficos ou exportados para o Excel®.

Para reiterar, essa solução (com o processo mostrado na Figura 4) pode ser atingida com o WSS e sem software adicional. Supondo que você já tenha um site bem elaborado do SharePoint, um departamento individual deverá criar e implementar uma pesquisa com pouca ou nenhuma assistência de TI.

Figura 4** Uma pesquisa baseada no Windows SharePoint Services **(Clique na imagem para aumentar a exibição)

Uma limitação do processo apenas do WSS se torna aparente quando uma pesquisa requer personalização. O WSS cria listas de pesquisa usando várias páginas ASPX padrão (AllItems.aspx, DispForm.aspx, EditForm.aspx, NewForm.aspx, overview.aspx e summary.aspx). Embora a personalização de página além dos parâmetros inerentes no WSS seja possível, a maioria dos recursos são originados de Web Parts que não são prontamente personalizáveis. Além disso, a solução apenas do WSS é mais bem adequada para pesquisas que não precisam integrar fontes de dados externos, como o sistema ERP da sua empresa.

Quando você precisar expandir a solução de pesquisa para incluir uma IU personalizada ou integrá-la com fontes de dados adicionais, deverá considerar seriamente uma solução que combine o MOSS, o WSS e o InfoPath.

A solução de pesquisa completa

O MOSS inclui muitos recursos que estendem o WSS, mas por agora vou me concentrar em apenas um componente – o InfoPath Forms Services. Com o InfoPath Forms Services, somente o designer de pesquisa precisa do InfoPath instalado no computador. Outros podem acessar a pesquisa por meio de um navegador da Web.

No InfoPath, o designer seleciona a opção que permite que o formulário seja preenchido com o uso de um navegador. O InfoPath então cria um formulário que pode ser visualizado em qualquer navegador Web em conformidade com os padrões. Esse formulário baseado na Web funciona da mesma forma que o formulário do InfoPath, com a exceção de alguns recursos avançados do InfoPath (como funções de usuário, texto vertical, ações da caixa de diálogo e controles avançados). O formulário é então publicado em uma biblioteca ou lista do SharePoint. Enquanto isso, outro recurso do InfoPath, denominado Verificador de Design, garante que o formulário de pesquisa seja compatível com o InfoPath Forms Services.

Não há diferença entre a biblioteca de formulários do InfoPath e uma biblioteca de formulários habilitada por navegador. Em cada caso, um modelo de formulário é um arquivo .xsn. O InfoPath Forms Services exibe o formulário em um navegador ou o arquivo é baixado para o cliente e exibido diretamente no InfoPath. Se um designer de pesquisa tiver pelo menos permissões de Colaborador para um site do SharePoint, poderá usar as bibliotecas de documento do SharePoint para publicar modelos de formulário.

Um pesquisado com um navegador em conformidade com os padrões poderá preencher a pesquisa do InfoPath Forms Services e as respostas serão então perfeitamente retornadas ao servidor do SharePoint. No SharePoint, os dados podem ser armazenados, analisados, compartilhados e analisados com segurança (usando o Excel, o SQL ou outras ferramentas disponíveis na rede). Tudo isso pode ser realizado com a mínima assistência de administração de TI.

Problemas de desempenho e postbacks

No entanto, há possíveis problemas de desempenho. Por exemplo, os formulários habilitados por navegador são executados no contexto de uma conta do sistema do servidor SharePoint, que significa que, se um formulário incluir conexões de dados ou código (como mostra a Figura 5), as conexões de dados ou código serão executados no servidor, não no cliente. Além disso, os formulários podem exigir com freqüência postbacks de dados no servidor, o que aumenta a carga de trabalho no servidor.

Figura 5** A solução de pesquisa baseada no InfoPath Forms Services com conexões de dados adicionais **(Clique na imagem para aumentar a exibição)

Quanto mais postback uma pesquisa usar, maior será a carga nos servidores Web de front-end. No entanto, haverá momentos em que o postback será inevitável, como ao implementar a ramificação de resposta. Para minimizar possíveis efeitos adversos no sistema, os designers de pesquisa devem estar cientes dos problemas de postback e compreender qual a melhor forma de implementar pesquisas quando não for possível evitar postback. Por exemplo, os designers devem usar pesquisas do tipo assistentes que façam o postback de dados para o servidor quando o usuário clicar no botão Próximo. Isso ajuda a reduzir o número de postbacks.

O InfoPath Forms Services deve manter o estado de cada formulário atualmente ativo no servidor. O tempo limite de sessão padrão é de 60 minutos, o que significa que se uma pesquisa complexa demorar mais de 60 minutos para ser preenchida e não houver postbacks durante esse período, a sessão será encerrada no servidor. Os dados que forem inseridos mas não enviados serão perdidos e o pesquisado deverá iniciar novamente.

Tais problemas são ampliados quando um número maior de pesquisados estiver trabalhando simultaneamente em um formulário de pesquisa e quando as pesquisas tiverem fontes de dados maiores ou incluírem anexos de arquivo. Para obter mais informações, consulte "Aprimorando o desempenho do InfoPath 2007 Forms" em msdn2.microsoft.com/bb380251.

Considerações sobre segurança

Embora uma discussão mais profunda sobre segurança esteja além do escopo deste artigo, é importante destacar algumas considerações sobre a segurança. Para iniciantes, o SharePoint e o InfoPath 2007 aderem à Iniciativa de computação confiável que a Microsoft adotou no início de 2002. Os formulários do InfoPath têm três níveis de segurança possíveis: restrito, de domínio e confiança total. E, por padrão, o InfoPath determina e aplica automaticamente um nível de segurança recomendado para o formulário.

A funcionalidade de assinatura digital pode ajudar a assegurar que um formulário seja criado ou preenchido por um usuário específico e não seja alterado. Além disso, o IRM (Information Rights Management, Gerenciamento de Direitos de Informação) pode restringir o acesso a modelos e formulários preenchidos. Para impedir que usuários maliciosos carreguem formulários que têm código nocivo ou usem a plataforma SharePoint para iniciar ataques contra outros sistemas por meio de conexões de dados, o InfoPath diferencia entre formulários implantados pelo usuário e pelo administrador. Os usuários podem carregar formulários, desde que os formulários não tenham qualquer código personalizado e possam usar somente o nível de segurança de domínio, o que limita as conexões de dados entre os domínios. Esses parâmetros são suficientes para a maioria das soluções de pesquisa.

Quando um design de pesquisa exigir o nível de segurança Confiança total, a fim de permitir o acesso irrestrito aos recursos, a publicação de formulário exigirá a aprovação da administração de TI. Por padrão, a aprovação da administração de TI é necessária quando um formulário tiver código gerenciado, quando conexões de dados entre domínios forem definidas no modelo de formulário, quando o formulário utilizar conexões de dados definidas na biblioteca de conexão de dados gerenciada centralmente e quando a opção de oferecer suporte a processamento em dispositivos móveis estiver habilitada.

Para o nível de segurança Confiança total, o designer de pesquisa criará um formulário do InfoPath e salvará um modelo de formulário. O modelo ou o arquivo .xsn será enviado para o administrador do SharePoint como um anexo de email ou será enviado por meio de um compartilhamento de rede. O administrador de TI então verifica os recursos de pesquisa e qualquer código que ela tenha antes de disponibilizá-la no sistema de produção. O administrador de TI concluirá a implantação ao carregar o modelo de pesquisa em um conjunto de sites e ativá-lo. Ambos os procedimentos são concluídos na página Gerenciamento de Aplicativos do console de Administração Central do WSS. O resultado final é que um administrador de TI pode delegar a publicação de formulários a departamentos individuais e ainda manter a supervisão do processo de publicação se os formulários ultrapassarem as atividades básicas de coleta de dados.

A supervisão do administrador de TI é necessária em determinados cenários comuns: quando os formulários precisarem ser preenchidos com dados padrão e quando os resultados de pesquisa forem enviados a várias fontes de dados. Por padrão, os modelos de formulário de confiança por domínio não podem estabelecer conexões de dados entre os domínios, mas há algumas ações que você pode tomar para resolver essa limitação, incluindo:

• Concessão de permissões de confiança total ao formulário
• Criação de confiança por domínio usando conexões de dados a partir da biblioteca de conexão de dados.
• Uso da confiança por domínio com a biblioteca de conexão gerenciada centralmente.

As opções de Confiança total e biblioteca de conexão gerenciada centralmente exigem a aprovação do administrador durante a publicação de formulários. No entanto, a DCL (data connection library, biblioteca de conexão de dados), permite que os formulários publicados pelo usuário ultrapassem os limites do domínio usando a DCL mantida no nível de conjunto de sites. Essa DCL pode estar sob o controle de um departamento específico. No entanto, é importante compreender que permitir que departamentos específicos definam suas próprias conexões de dados com base em servidor pode ser um problema de segurança.

A opção mais segura é definir as conexões de dados na biblioteca de conexão gerenciada centralmente e, em seguida, o administrador de TI deverá implantar formulários avançados de pesquisa que utilizem essas conexões de dados. A biblioteca de conexão gerenciada centralmente é vantajosa, pois está disponível em todos os conjuntos de sites e em todo o farm de servidor. Isso permite que um administrador defina configurações de autenticação central para acesso a fontes de dados que não estejam no servidor local do SharePoint. Para obter mais informações, leia o artigo online intitulado "Sobre conexões de dados, autenticação e mapeamento de acesso alternativo" em msdn2.microsoft.com/ms771995.

Conclusão

As pesquisas fornecem um modo excelente de coletar informações consideradas críticas (e nem tão críticas) para cada empresa, em todos os níveis. No entanto, a criação de uma pesquisa eficaz requer as ferramentas corretas, um plano sonoro e uma combinação equilibrada de arte e ciência. Um planejamento elaborado com antecedência ajudará você a criar uma solução que permite que cada departamento na sua organização crie, envie, receba, armazene e analise dados de pesquisa.

As pesquisas mais eficazes são aquelas que fornecem informações relevantes e em tempo hábil. Para coletar informações quando for necessário, a sua solução deve facilitar a criação e o gerenciamento de pesquisas no nível de departamento – sem comprometer a segurança. O InfoPath capacita os operadores de informações a criarem pesquisas de qualidade superior ao fornecer uma interface intuitiva que pode ser usada com pouco treinamento. Além disso, o InfoPath permite que você colete dados com pesquisas de qualidade superior sem exigir muito da administração de TI.

O InfoPath 2007 funciona perfeitamente com o WSS e o MOSS para facilitar soluções de pesquisa avançadas e complexas que são compatíveis com várias plataformas e navegadores. Isso permite também que sua empresa explore um de seus ativos mais importantes: a informação.

Uso de email para pesquisas rápidas

As pesquisas improvisadas são uma ferramenta essencial para coletar rapidamente dados de um pequeno grupo de pesquisados. As pesquisas baseadas em email são perfeitas para esse tipo de pesquisa em tempo real – elas podem ser criadas rapidamente e não exigem servidores dedicados nem assistência de TI. Uma das abordagens mais simples, os botões de voto incorporados em uma mensagem do Microsoft® Outlook®, permite que você envie, receba e organize uma pesquisa unidimensional.

Depois de iniciar uma pesquisa com botões de voto, os seus destinatários receberão uma mensagem de email com um faixa de voto, que exibirá uma lista suspensa de opções. O destinatário responderá clicando em uma das opções. Uma janela pop-up então exibirá uma mensagem "Você escolheu responder: <sua escolha>" e oferece a escolha para Enviar ou Editar a resposta.

O designer de pesquisa, ou um representante atribuído, receberá as respostas individuais em um email e organizará manualmente os resultados. Se a pesquisa incluir um grande número de destinatários, você deverá criar uma regra no Outlook (usando o assistente de regras) que roteará automaticamente as respostas a uma pasta dedicada, como demonstrado na Figura A.

Figura A** As respostas da pesquisa serão automaticamente roteadas para uma pasta dedicada **(Clique na imagem para aumentar a exibição)

No entanto, os botões de voto são um tanto limitados. Os formulários de pesquisa inseridos em mensagens de email podem coletar muito mais dados, mas a recuperação e a organização manual desses dados podem se tornar impossíveis de gerenciar. No lado mais complexo de pesquisas baseadas em email está o uso de VBScript para personalizar pesquisas do Outlook. Os formulários personalizados podem facilitar a coleta e a análise de grandes quantidades de dados mais complexos. Para acessar a funcionalidade do desenvolvedor no Outlook 2007, você deve primeiro exibir a guia do desenvolvedor, mostrada na Figura B.

Figura B** Guia do desenvolvedor no Outlook 2007 **(Clique na imagem para aumentar a exibição)

A criação de formulários personalizados do Outlook está além do conhecimento do usuário característico do Outlook. Mas o InfoPath® 2007 fornece novos recursos que facilitam a implementação de formulários personalizados. Sem conhecimento especial, os designers de pesquisa podem criar formulários do InfoPath e modelos de três maneiras:

• Ao importar documentos do Microsoft Word ou planilhas do Excel® existentes.
• Ao fazer o download de modelos pré-desenvolvidos do InfoPath e modificá-los para atender a necessidades específicas.
• Ao criar modelos a partir do zero usando a funcionalidade de criação de formulários do InfoPath.

Em todos os três casos, os modelos podem ser publicados no Outlook e distribuídos por email. Com o InfoPath 2007 e o Outlook 2007, algumas horas e pouca ou nenhuma assistência de TI, um operador de informações poderá criar uma pesquisa com vinte perguntas, enviá-la por email para um grupo, receber os resultados no Outlook e analisá-los em uma planilha do Excel.

O único requisito real nesse cenário é que todos os participantes tenham o InfoPath e o Outlook instalados em seus computadores. Além disso, como o InfoPath 2007 na verdade estende a funcionalidade do Outlook 2007, os destinatários podem responder à pesquisa diretamente na interface do Outlook.

Mas o InfoPath oferece muito mais suporte do que apenas pesquisas baseadas em email. Você pode criar modelos que consultem e enviem dados a serviços Web e bancos de dados SQL Server® ou usar um documento XML ou esquema XML existente como a fonte de dados. Em outras palavras, com o mínimo treinamento e pouco ou nenhum código adicionado, um usuário será capaz de explorar a potência e a flexibilidade do XML.

O email como uma solução de pesquisa tem desvantagens notáveis. Por exemplo, essas pesquisas não são anônimas, pois o endereço de email dos pesquisados está disponível. Isso pode reduzir a sinceridade e desviar os resultados. Há também preocupações com a segurança, como ataques de phishing, pois há um limite para o tipo e a profundidade de informações que você pode coletar usando pesquisas baseadas em email.

Criação de uma solução de pesquisa orientada por bancos de dados

As pesquisas baseadas em email não são adequadas para estudos mais complexos que envolvam números elevados de pesquisados – usar uma pasta no Outlook® não é suficiente para gerenciar e analisar todos os dados. Uma solução mais robusta é direcionar as respostas da pesquisa para um banco de dados. Os recursos avançados de armazenamento, indexação, processamento e relatórios que você obtém com um banco de dados podem ser muito úteis. O Microsoft® SQL Server® 2005, por exemplo, inclui o SQL Server Reporting Services, que pode ser usado para processar automaticamente os resultados da pesquisa.

Para criar um modelo de formulário do InfoPath que enviará respostas a um banco de dados, você deverá primeiro criar um banco de dados do Access® ou SQL Server na sua rede. Então, no InfoPath®, você poderá iniciar o processo de criação de modelos usando o assistente de criação de modelos de formulário. Isso abrirá o assistente de conexão de dados, que o guia no processo de vinculação do seu formulário ao banco de dados. O InfoPath usa as informações no seu banco de dados para criar os campos de dados e consulta de fonte de dados.

A maioria dos operadores terá conhecimento suficiente para concluir e enviar a pesquisa com pouco treinamento ou suporte. No entanto, nesse cenário (no qual os dados são passados diretamente para o banco de dados), os pesquisados devem ter o InfoPath e o Outlook instalados e eles devem estar por trás do firewall corporativo ou ter acesso de VPN à rede corporativa.

O assistente de conexão de dados do InfoPath tem uma interface somente com bancos de dados Microsoft SQL Server 2000 ou posterior e Access que estiverem usando nativamente ADOXML. O envio direto ao banco de dados não é compatível com outros bancos de dados. Outras limitações são que o InfoPath não permite que controles de rich text sejam vinculados aos campos do banco de dados e tipos de dados binários elevados não são compatíveis.

Como a topologia de rede se torna cada vez maior e mais complexa, ela se torna cada vez mais vantajosa para o envio de dados a um serviço Web intermediário para, em seguida, passar esses dados para um banco de dados. O desacoplamento do front-end do formulário de pesquisa do back-end do banco de dados, por meio de um serviço Web, também facilita a implementação da lógica comercial no servidor Web. E, como o serviço Web é realizado em conexões HTTP ou HTTPS, os participantes podem enviar dados por meio de firewalls, como mostra a Figura C. Observe, no entanto, que os pesquisados ainda devem ter o InfoPath 2003 ou o 2007 instalado.

A desvantagem desse cenário é que a implementação requer a participação de TI. Descrever esse processo em detalhes está além do escopo deste artigo, mas desejo alertá-lo que a criação de uma solução de banco de dados a partir do zero é uma realização significativa. Ela requer planejamento com antecedência, bom design de pesquisa, programação do serviço Web e design do back-end do banco de dados. O InfoPath 2007 simplifica o aspecto de design dos formulários do processo, mas a solução completa requer programação sólida e habilidades de design de banco de dados. Além disso, o acréscimo de funcionalidade avançada, como suporte a vários idiomas e fluxo de trabalho, aumenta rapidamente o custo da implementação.

Figura C** Fluxo de dados do InfoPath por meio de um serviço Web **(Clique na imagem para aumentar a exibição)

Jim Bradley é o proprietário da CoyoteTech LLC, uma empresa de comunicações técnicas especializada em documentação de assistência a usuários de produtos de servidor Microsoft. Os projetos de documentação incluem "Transporte de Borda do Microsoft Exchange Server 2007 e proteção das mensagens", "Adotando os 64 bits com o Exchange Server 2007" e "Guia de Referência Técnica do Microsoft Exchange 2003".

© 2008 Microsoft Corporation e CMP Media, LLC. Todos os direitos reservados. A reprodução parcial ou completa sem autorização é proibida..