Explorando o SharePointIntegrando aplicativos do Office

Pav Cherny

Conteúdo

Integração de aplicativo do Office
Estendendo a interface do usuário do SharePoint
Usando o controle OpenDocuments do Office
Comunicando-se com o SharePoint
Implementando uma solução OpenControl personalizada
Resumindo

O WSS (Microsoft Windows SharePoint Services) 3.0 e o MOSS (Microsoft Office SharePoint Server) 2007 se integram diretamente a aplicativos de área de trabalho no 2007 Microsoft Office system, o que facilita a colaboração em documentos, planilhas, calendários, informações de contato e muito mais. Na verdade, a integração é tão direta que você

pode afirmar que o 2007 Office system é uma plataforma de soluções corporativas unificada.

Isso é ótimo para organizações que se concentram na tecnologia Microsoft® Office para aumentar a produtividade do profissional da informação. No entanto, as organizações que contam com um portfólio diversificado de aplicativos do Office não podem aproveitar o mesmo nível de interoperabilidade imediato. O 2007 Office system fornece os recursos de integração necessários, e as interfaces e os componentes estão minimamente documentados, não funcionando em todas as circunstâncias. Isso dificulta a integração da tecnologia do SharePoint® por parte de fornecedores terceiros a seus aplicativos e ainda mais para que seus clientes proporcionem aos profissionais da informação uma experiência unificada.

Nesta coluna, mostrarei como os aplicativos do Office se integram e se comunicam com o SharePoint, além de como é possível, de acordo com os mesmos princípios, integrar ao SharePoint aplicativos que não sejam da Microsoft. Mas primeiro abordarei as definições de configuração do servidor, os componentes do lado do cliente e os protocolos de comunicação usados na obtenção da integração direta.

Uma vez esclarecidos esses detalhes, posso abordar a integração dos aplicativos que não vêm acompanhados de suporte interno ao SharePoint. Com essa iniciativa, irei além do nível habitual que normalmente se concentra na implementação dos componentes IFilter para estender os recursos de pesquisa e adicionar ícones personalizados em servidores do SharePoint. Estender a pesquisa e os resultados retornados com ícones apropriados não atinge a integração de aplicativo total; os usuários talvez queiram também abrir esses documentos diretamente na interface do usuário do SharePoint.

É onde as coisas se complicam. Você precisa de um componente do lado do cliente que não está prontamente disponível caso não tenha implantado o Office nas estações de trabalho. Mas mesmo que tenha implantado, você pode achar que esse componente não funciona de maneira confiável, dependendo da topologia e da configuração do site do SharePoint.

Para resolver esse problema, criei uma solução personalizada que permite integrar qualquer aplicativo como, por exemplo, Bloco de Notas, Adobe Reader ou Autodesk AutoCAD, sem que haja requisitos de implantação do Office. Essa solução personalizada também ilustra por que há falha na integração do aplicativo com base nos componentes do Office em algumas situações. É possível encontrar essa solução, bem como instruções passo a passo para implantação e configuração, no material complementar desta coluna, disponível na seção Download de Código de .com.

Integração de aplicativo do Office

Do ponto de vista do usuário, os menus do SharePoint parecem funcionar como o menu Iniciar do Windows®. Criar um novo documento em uma biblioteca é simples: clique em New, em New Document, e o Microsoft Office Word 2007 é iniciado. Editar um documento existente também é bem simples. Focalize o documento, abra o menu suspenso Edit Control Box (ECB) e clique em Edit in Word. É difícil imaginar que você iniciou o Word 2007 em uma página da Web usando JavaScript, que você está executando o aplicativo localmente enquanto o documento está bem longe, em um banco de dados do SQL Server® e que há um servidor Web no caminho do acesso aos dados, como ilustra a Figura 1.

Figura 1 Trabalhando com um documento do Word no SharePoint (Clique na imagem para ampliá-la)

Apesar dessa complexidade, a experiência do usuário em uma estação de trabalho do Windows com o 2007 Office system instalado é direta. Trabalhar com documentos em uma biblioteca do SharePoint é bem semelhante a trabalhar com arquivos locais ou arquivos em um compartilhamento de rede.

No entanto, em uma estação de trabalho com o Windows, mas sem o Office 2003 ou o 2007 Office system, a interface do usuário é diferente. Clicar em New Document ou Edit in Word só abre uma caixa de diálogo informando que um aplicativo compatível com o Windows SharePoint Services não está disponível.

Isso não chega a ser uma surpresa. Existem vários elementos que devem funcionar juntos para proporcionar a experiência unificada que os usuários do Office usufruem. O SharePoint deve reconhecer os tipos de conteúdo mantidos na biblioteca de documentos para renderizar os comandos desejados nos menus New e ECB. Em resposta a cliques do mouse nesses comandos, o código JavaScript deve ser executado para iniciar o aplicativo associado, passando o caminho para o documento. Essa parte não independe da configuração da estação de trabalho porque o código JavaScript é executado localmente. Além disso, o aplicativo associado deve se comunicar com o SharePoint para ler e possivelmente gravar arquivos. Esses são os elementos que você deve agrupar caso queira integrar os aplicativos ao SharePoint.

Por outro lado, a comunicação entre o SharePoint e o servidor de banco de dados é transparente para o aplicativo, assim como os processos de indexação no servidor Web para facilitar as pesquisas. Por esse motivo, não abordarei mais a fundo esses aspectos neste artigo, embora recomende que você consulte o Microsoft Filter Pack documentado no artigo da Base de Dados de Conhecimento Microsoft "Como registrar Microsoft Filter Pack com Windows SharePoint Services 3.0", disponível em support.microsoft.com/kb/946338. Agora voltemos nossas atenções para a adição de comandos, a implementação dos componentes do lado do cliente necessários e a facilitação da comunicação do aplicativo.

Estendendo a interface do usuário do SharePoint

Há várias opções disponíveis para estender a interface do usuário e a funcionalidade do SharePoint. É possível alterar o design dos sites, personalizar as páginas do ASP.NET, desenvolver Web Parts ou alterar o código JavaScript incluído no WSS e no MOSS para iniciar diretamente os aplicativos.

Não há nada que impeça a abertura do arquivo Ows.js em um editor de texto (o arquivo pode ser encontrado na pasta COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\12\Template\Layouts\1033 dos servidores front-end do SharePoint) e a alteração da forma com que operam as funções createNewDocumentWithProgIDCore, editDocumentWithProgIDNoUI e DispDocItem. Mas existe um método melhor que não exige a alteração da base de código do WSS de forma para a qual não há suporte: usar tipos de conteúdo e mapeamentos de tipo de documento.

No meu artigo "Padronize o gerenciamento de dados com tipos de conteúdo personalizados" (consulte a TechNet Magazine, de fevereiro de 2008, technet.microsoft.com/magazine/cc194408.aspx), expliquei como criar tipos de conteúdo globais e específicos do site para gerenciar documentos e outro conteúdo nas bibliotecas de documentos e listas do SharePoint. Também é possível conferir a planilha Text Content Type.pdf no material complementar deste artigo, que ilustra como criar um novo tipo de conteúdo para arquivos .text e associar esse tipo a uma biblioteca de documentos. O resultado é que é possível selecionar o comando Text Content no menu New assim que o comando Document é selecionado para documentos do Word (consulte a Figura 2).

Figura 2 Um tipo de conteúdo personalizado na interface do usuário do SharePoint (Clique na imagem para ampliá-la)

O menu ECB é extensível da mesma forma. Você talvez estivesse esperando que o menu ECB reconhecesse o tipo de conteúdo, mas essa não é a forma como a versão do WSS atual implementa esse menu. Na verdade, você deve registrar o tipo de documento em Docicon.xml, que é possível localizar na pasta %COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\12\Template\Xml em todos os servidores front-end do SharePoint.

Adicionando o seguinte mapeamento do tipo de documento à seção <ByExtension> de Docicon.xml, por exemplo, você fará com que o SharePoint exiba o comando Edit in Notepad (consulte o arquivo Text Content Type.pdf para obter instruções mais detalhadas):

<Mapping Key="text" Value="ictxt.gif" 
  EditText="Notepad"
  OpenControl="SharePoint.OpenDocuments"/>

O parâmetro Key identifica a extensão do nome de arquivo, o parâmetro Value define o ícone do documento a ser exibido na interface do usuário, o parâmetro EditText define a seqüência de caracteres que o SharePoint acrescenta ao comando "Edit in" e o parâmetro OpenControl especifica ProgID de um componente COM do lado do cliente. Trata-se de ProgID que as funções JavaScript do SharePoint passam para uma chamada ActiveXObject (consulte Ows.js para obter detalhes) a fim de criar uma instância do objeto COM, que pode ser o próprio aplicativo ou um controle auxiliar que inicia o aplicativo com base no tipo de arquivo associado.

Site dos Produtos e Tecnologias do SharePoint

• Site dos Produtos e Tecnologias do SharePoint
• TechCenter do Windows SharePoint Services
• Windows SharePoint Services Developer Center
• Blog da equipe de Produtos e Tecnologias do Microsoft SharePoint

Você deve observar que OpenControl nomeado SharePoint.OpenDocuments está se referindo a um controle ActiveX® que acompanha as versões recentes do Office (%PROGRAMFILES%\Microsoft Office\Office12\Owssupp.dll). Caso esse arquivo esteja nas estações de trabalho e o ícone do documento especificado (parâmetro Value) esteja na pasta %COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\12\Template\Images dos servidores do SharePoint, você talvez já tenha realizado grande parte do trabalho de integração necessário.

O SDK do Windows SharePoint Services 3.0 inclui algumas informações sobre APIs do lado do cliente que acompanham o 2007 Office system, inclusive o controle OpenDocuments. Consulte a seção "Referência API do cliente" em msdn2.microsoft.com/ms440037.

Usando o controle OpenDocuments do Office

O controle OpenDocuments atende às necessidades de integração do aplicativo mais importantes, embora exija o Office 2003 ou o 2007 Office system, além dos recursos estarem, de certa forma, limitados. Os comandos do menu New talvez não funcionem sempre, e eles, às vezes, exibem o que pode ser uma notificação do usuário falsa.

Conforme ilustrado na Figura 3, o controle OpenDocuments informa ao usuário que o aplicativo obrigatório não está instalado corretamente ou que o arquivo de modelo não pode ser aberto, embora nenhum desses seja o caso. Edit também apresenta problemas, em termos de funcionalidade. A segunda mensagem de erro mostrada no primeiro plano da Figura 3 é vista com freqüência. Trata-se da minha favorita em todos os tempos porque engana até mesmo especialistas em SharePoint, mas falarei mais a respeito daqui a pouco.

Figura 3 Mensagens de erro falsas do controle OpenDocuments (Clique na imagem para ampliá-la)

No entanto, o controle OpenDocuments é útil em ambientes com versões recentes do Office instalado em todas as estações de trabalho. Dentre todas as outras coisas, é possível ocultar os tipos de documento no menu New (exibir Document Library Settings, clicar em Change New Button Order And Default Content Type e desmarcar a caixa de seleção Visible de todos os tipos de conteúdo em questão), para que os usuários não encontrem a primeira mensagem de erro. Também é possível manter a topologia do site simples para evitar problemas de comunicação do WebDAV (Web-Based Distributed Authoring and Versioning); isso elimina essa segunda mensagem de erro.

Comunicando-se com o SharePoint

Até aqui, consegui estender a interface do usuário do SharePoint e talvez iniciar um aplicativo por meio do controle OpenDocuments, mas o meu aplicativo continua precisando de uma forma para se comunicar com o SharePoint e acessar os dados. Como sempre, o SharePoint oferece suporte a vários métodos para fazer isso como, por exemplo, Microsoft Office FrontPage® Server Extensions, RPCs (chamadas de procedimento remoto) do WSS, WebDAV e Web services. Na verdade, aplicativos do Office como, por exemplo, o Word 2007 podem usar todos esses métodos de comunicação, dependendo de como você acessa um documento como por meio das pastas da Web, unidades de rede mapeadas ou a interface do usuário do SharePoint.

Os métodos de comunicação cliente/servidor do SharePoint contam com o HTTP como protocolo subjacente. Por exemplo, o FrontPage e as RPCs do WSS usam todos as solicitações HTTP POST e HTTP GET direcionadas para extensões ISAPI que residem em servidores do SharePoint na pasta %COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\12\ISAPI e em todas as suas subpastas.

Uma das extensões ISAPI mais importantes é Owssvr.dll, que implementa, dentre outras coisas, a funcionalidade para trabalhar com listas e bibliotecas de documentos. A Figura 4 mostra a caixa de diálogo Save do SharePoint no Word 2007 (lado esquerdo) e em um navegador (lado direito) aberta diretamente por meio da solicitação de URL https://sharepoint/HR/Administration/_vti_bin/owssvr.dll?dialogview=FileSave&location=Shared%20Documents&FileDialogFilterValue=*.docx. As semelhanças entre as duas capturas de tela são evidentes.

Figura 4 A caixa de diálogo Save do SharePoint no Word 2007 e no Internet Explorer (Clique na imagem para ampliá-la)

Outras extensões ISAPI importantes são Author.dll, que implementa o FrontPage e as RPCs do WSS para operações de edição do lado do cliente como, por exemplo, carregar, renomear e excluir documentos; Admin.dll para gerenciar sites e realizar várias outras tarefas administrativas e Shtml.dll para oferecer suporte a envios de formulário HTML.

Costuma ser impossível adicionar suporte a FrontPage e RPC do WSS aos aplicativos existentes como, por exemplo, o Bloco de Notas ou o Adobe Reader, sem que haja acesso ao código-fonte. Mas você poderia fornecer as instalações da comunicação necessárias por meio do recurso cliente Web incluído no Windows.

O SharePoint também oferece suporte a WebDAV por meio de Httpext.dll, que reside na pasta %WINDIR%\System32\Inetsrv\, mas fiquemos no lado do cliente. Os computadores com o Windows Server® 2008 ou o Windows Vista® em execução contam com o recurso do cliente Web instalado por padrão. É possível localizar um serviço WebClient correspondente no miniaplicativo Serviços de Ferramentas Administrativas no Painel de Controle. No Windows XP e no Windows Server 2003, você deve instalar explicitamente o cliente Web. De qualquer forma, verifique se o serviço WebClient foi iniciado e se Tipo de inicialização está definido como Automático.

A Figura 5 é uma representação da arquitetura do cliente Web. O serviço WebClient é implementado em uma DLL em modo de usuário (Webclnt.dll) carregada por Gerenciador de Controle de Serviços em um processo de host Svchost.exe. Webclnt.dll fornece a interface do provedor de rede para operações que não sejam de E/S (como, por exemplo, autenticar o usuário tendo em vista o acesso a WebDAV; montar sites do SharePoint como unidades de rede; enumerar sites do SharePoint, listas e documentar bibliotecas como recursos de rede, além de desconectar unidades montadas).

Figura 5 A arquitetura do Redirecionador do cliente WebDav (Clique na imagem para ampliá-la)

Para realizar esse trabalho, Webclnt.dll se comunica com um driver do sistema de arquivos em modo kernel que fornece a funcionalidade de redirecionamento efetiva. O driver redirecionador do cliente WebDAV (Mrxdav.sys) se baseia no RDBSS (Redirected Drive Buffering Subsystem), que se integra ao Gerenciador E/S e aos demais componentes de kernel para proporcionar os serviços de um sistema de arquivos remoto. Mrxdav.sys implementa as instalações de comunicação de WebDAV para oferecer suporte ao acesso em nível de sistema aos sites do SharePoint e às bibliotecas de documentos.

Ter acesso a sites do SharePoint e a bibliotecas de documentos por meio de um redirecionador de rede elimina a necessidade do suporte ao FrontPage e a RPCs do WSS nos aplicativos do usuário. É possível mapear unidades de rede para bibliotecas de documentos (como, por exemplo, net use x: http://wss/doclib/Shared%20Documents), e você também pode acessar os recursos do SharePoint por meio de caminhos UNC.

A URL http://wss/doclib/Shared%20Documents é mapeada para \\wss\doclib\Shared%20Documents. Dessa forma, você tem opções para abrir um documento em um aplicativo. Por exemplo, é possível abrir um documento no Bloco de Notas com o caminho HTTP http://wss/doclib/Shared%20Documents/New%20Text%20Document.txt ou o caminho UNC \\wss\doclib\Shared%20Documents\New%20Text%20Document.txt.

Infelizmente, o recurso cliente Web tem várias limitações. Não é possível acessar propriedades personalizadas ou aplicativos Web que usem portas TCP personalizadas. O cliente Web que acompanha o Windows Vista também apresenta falha caso o usuário não tenha acesso a um site pai na hierarquia, como ilustrado em WebDAV Access.pdf (consulte o material complementar).

O caminho https://sharepoint/HR/Administration/Shared%20Documents/ inclui um site raiz inexistente (ou seja, https://sharepoint), ainda sem acesso à raiz, o cliente Web não pode determinar os recursos do servidor Web. O servidor Web rejeita a solicitação OPTIONS do cliente Web com Código de Status 401, que informa que o acesso não é autorizado e, dessa forma, o cliente Web continua solicitando as credenciais do usuário, como mostrado na Figura 6, ainda que o usuário tenha acesso administrativo ao conjunto de sites sharepoint/HR e a todos os sites nele contidos.

Figura 6 Acesso a WebDAV malsucedido (Clique na imagem para ampliá-la)

Ao usar o controle OpenDocuments, você recebe a mensagem de erro exibida na Figura 3 caso o cliente Web falhe ao abrir um documento. O aplicativo está disponível, e o mapeamento do tipo de documento está correto. Trata-se do documento que pode ser acessado por meio do redirecionador WebDAV.

Implementando uma solução OpenControl personalizada

Geralmente, você tem duas opções para contornar as limitações do cliente Web. É possível aguardar até que a Microsoft forneça uma versão atualizada do cliente Web ou até que você possa implementar uma solução OpenControl personalizada capaz de lidar com a situação atual. Implementar um OpenControl personalizado não é uma tarefa habitual, embora elimine a necessidade do Office nas estações de trabalho, permita tratar o comando New, além do comando Edit in, de maneira significativa e possibilite resolver situações nas quais ocorre uma falha no cliente Web.

Caso algum desses problemas seja atraente na sua opinião, observe o código-fonte AppStart incluído no material complementar. Ele mostra como expor as interfaces COM OpenControl de um assembly do Microsoft .NET Framework, que o código JavaScript do SharePoint pode chamar. O código-fonte AppStart também demonstra uma forma possível de verificar a acessibilidade do arquivo e baixá-lo para o computador local por meio do http, caso não seja possível o acesso direto por meio de WebDAV. Por fim, o código-fonte AppStart responde ao comando New, baixando o modelo associado ao tipo de conteúdo para o computador local de que o usuário possa começar a trabalhar no documento. As planilhas Text Content Type.pdf e Adobe Reader Support.pdf descrevem como implantar essa solução OpenControl.

O diagrama mostrado na Figura 7 exibe a arquitetura de AppStart. O meu componente OpenControl personalizado (chamado Biblioso.dll) expõe duas interfaces COM idênticas que o JavaScript do SharePoint chama para criar novos documentos ou abrir documentos já existentes para edição (Biblioso.AppStart.2 e Biblioso.AppStart.3).

Figura 7 A arquitetura de AppStart (Clique na imagem para ampliá-la)

Caso um documento seja aberto para edição, Biblioso.dll verifica se o arquivo existe e inicia o aplicativo associado com o caminho para o documento em caso de acessibilidade direta do arquivo por meio de WebDAV. Caso o arquivo não esteja acessível, Biblioso.dll inicia um servidor COM fora de processo que, por sua vez, carrega OpenDocsUtility.dll para baixar o arquivo por meio de HTTP e iniciar o aplicativo com o caminho para o documento baixado.

O servidor COM fora de processo permite que a solução interrompa o processo do Internet Explorer®, o que restringe downloads à pasta Temporary Internet no modo protegido. Os usuários devem ser capazes de baixar arquivos sem restrições no modo protegido, e um servidor COM fora de processo que funciona como um agente do aplicativo fornece essa opção.

Como não há suporte para o desenvolvimento de servidores COM fora de processo no .NET, recorri ao C/C++ nesse executável. Implementei somente o mínimo, a caixa de diálogo Save As no C++. Para que a solução permanecesse o mais direta possível e manter a sobrecarga de desenvolvimento baixa, coloquei o código para download real em um assembly do .NET (OpenDocsUtility.dll), que acabo chamando por meio de uma outra interface COM.

Para facilitar o desenvolvimento, adicionei um projeto de instalação à solução. Dentre outras coisas, a rotina de instalação registra todos os componentes COM e grava configurações específicas do aplicativo em HKEY_LOCAL_MACHINE\SOFTWARE\Biblioso\AppStart. Os parâmetros mais importantes são AllowedApps e AllowedFileTypes. A solução AppStart só funcionará com esses aplicativos e os tipos de arquivo que você deve especificar explicitamente nesses parâmetros.

A rotina de instalação também cria uma diretiva de elevação para o servidor COM fora de processo de forma que Biblioso.dll no processo do Internet Explorer possa iniciar AppBrokerEngine.exe sem disparar avisos de segurança. Caso você esteja interessado em saber mais sobre o modo protegido do Internet Explorer e sobre como lidar com ele no desenvolvimento de aplicativos, é altamente recomendável a leitura do artigo de Marc Silbey e Peter Brundrett, "Compreendendo e trabalhando no modo protegido do Internet Explorer", disponível em msdn2.microsoft.com/bb250462.

Durante o exame dos componentes de AppStart, tenha em mente que essa solução foi desenvolvida apenas para mostrar o que se pode fazer; ela ainda não está pronta para ambientes de produção. Não houve tempo suficiente para otimizar o código e testar integralmente a solução, ou documentar os recursos, além dos comentários feitos sobre o código-fonte.

Você deve usar essa solução por sua conta e risco. Caso você esteja interessado em estudar o código-fonte e criar uma solução própria, inicie AppStart.cs no projeto de código Biblioso. Esse arquivo implementa a interface COM OpenControl e os pontos de entrada das chamadas JavaScript em Ows.js.

Resumindo

O WSS 3.0 e o MOSS 2007 fornecem amplos recursos para integração de aplicativos destinados a uma experiência do usuário direta em meio ao trabalho com documentos e outros itens em bibliotecas de documentos e listas do SharePoint. Os aplicativos de área de trabalho do 2007 Office system demonstram isso de maneira muito clara, sendo possível obter o mesmo nível de integração e usabilidade também com aplicativos que não sejam do Office.

Na base da arquitetura de integração de aplicativos estão os componentes COM, usados pelas funções JavaScript do SharePoint, além do caminho do documento, para iniciar o aplicativo. O 2007 Office system fornece vários desses componentes COM, otimizados tendo em vista necessidades específicas do aplicativo do Office, ainda que também seja possível reutilizar o controle OpenDocuments do Office para integrar aplicativos que não sejam da Microsoft. O controle OpenDocuments atende às necessidades mais básicas. Tendo em vista requisitos de integração de aplicativos mais avançados, é possível implementar um controle personalizado.

Integrar totalmente um aplicativo ao SharePoint exige não apenas instalar componentes IFilter e documentar ícones para estender os recursos de pesquisa e exibição, mas também envolve criar tipos de conteúdo personalizados e mapeamentos de tipo de documento nos servidores do SharePoint para fornecer os comandos New e Edit in apropriados na interface do usuário do SharePoint. Esses comandos chamam funções JavaScript que invocam métodos expostos por meio de um componente OpenControl. O componente OpenControl também deve estar disponível na estação de trabalho.

Outra peça importante do quebra-cabeça é o cliente Web, incluído e instalado por padrão no Windows Vista. O cliente Web implementa um redirecionador WebDAV e um driver do sistema de arquivos remoto para que qualquer aplicativo possa acessar recursos em listas e bibliotecas de documentos do SharePoint, semelhantes a compartilhamentos de arquivos na rede. Muito embora tenha limitações, o cliente Web que acompanha o Windows Vista é peça fundamental na história da integração do aplicativo.

O suporte a WebDAV também preenche a lacuna entre aplicativos em execução em estações de trabalho que não sejam do Windows e o SharePoint. Como a tecnologia de controle COM e ActiveX não costuma estar disponível nesses sistemas operacionais, não é possível usar componentes OpenControl para iniciar automaticamente os aplicativos, mas a maioria dos sistemas operacionais inclui redirecionadores WebDAV para que os usuários possam pelo menos acessar documentos diretamente em bibliotecas de documentos sem que seja necessário baixar os arquivos para as estações de trabalho locais.

O WSS 3.0 e o MOSS 2007 são os fundamentos da história de sucesso do 2007 Office system, e os usuários de aplicativos de terceiros baseados no Office podem usufruir o SharePoint da mesma maneira. Os recursos de integração vão muito além do Office. Usufruindo o SharePoint por completo, é possível criar uma plataforma de soluções corporativas unificada que proporciona a mesma experiência do usuário para o Office e o software de terceiros e, dessa forma, aumenta a produtividade dos profissionais da informação.

Pav Cherny é especialista em TI e autor especializado em tecnologias Microsoft para colaboração e comunicação unificada. Entre suas publicações estão white papers, manuais de produto e livros com foco nas operações de TI e na administração do sistema. Pav é presidente da Biblioso Corporation, empresa especializada em serviços de documentação gerenciada e de localização.

© 2008 Microsoft Corporation e CMP Media, LLC. Todos os direitos reservados; é proibida a reprodução total ou parcial sem permissão.