SharePoint

Padronize o gerenciamento de dados com tipos de conteúdo personalizados

Pav Cherny

Visão geral:

• Gerenciamento do ciclo de vida do conteúdo com o SharePoint
• Criando painéis de informações de documentos
• Editando documentos do Office e SharePoint por meio do InfoPath

Faça download do código deste artigo: ContentTypes2008_02.exe (779KB)

O grande número de documentos e outros itens de conteúdo geralmente encontrados em u ambiente empresarial representam desafios comerciais e técnicos para o gerenciamento de documentos, seus

metadados e seus comportamentos em uma maneira centralizada e reutilizável. O Microsoft® Office SharePoint® Server 2007 promove a colaboração em toda a empresa permitindo às equipes distintas dentro de uma organização compartilhar espaços de trabalho em sites, bibliotecas de documentos e listas.

O SharePoint 2007 possibilita a padronização de muitos aspectos das características de conteúdo e ciclo de vida por meio de tipos de conteúdo. Tipos de conteúdo de sites são definições de metadados que podem ser estabelecidos independentemente de qualquer conjunto de sites, sites, listas ou bibliotecas de documentos específicos. Isso permite o estabelecimento de propriedades, fluxos de trabalho, diretivas de gerenciamento de informações e outros elementos em toda a empresa de maneira consistente enquanto permite também aos departamentos individuais e proprietários de sites personalizar os tipos de conteúdo para objetivos específicos.

Netse artigo mostrarei como usar o novo modelo de conteúdo do SharePoint apresentado com o Windows® SharePoint Services (WSS) 3.0 e o Microsoft Office SharePoint Server (MOSS) 2007 para criar hierarquias para conteúdos empresariais baseados em características gerais. Essas hierarquias de conteúdo habilitam a aplicação uniforme de metadados, fluxos de trabalho e diretivas de gerenciamento de informações em um nível global enquanto fornecem também a flexibilidade de acomodar necessidades de gerenciamento de conteúdo exclusivas no nível de conjuntos de sites, sites, bibliotecas de documentos e listas.

Para ilustrar alguns dos aspectos de nível baixo dos tipos de conteúdo do SharePoint, incluí uma série de ferramentas personalizadas no material de acompanhamento e também o código-fonte, caso você deseje estender essas ferramentas conforme suas necessidades específicas. Lembre-se de que essas ferramentas não foram totalmente testadas e não devem ser usadas em sistemas de produção. É possível baixar o código na TechNet Magazine em technetmagazine.com/code08.aspx.

Definições de ciclo de vida de conteúdo e tipo de conteúdo

Recursos do SharePoint

• Blog da equipe do InfoPath
• Fluxos de trabalho no Office SharePoint Server 2007
• TechNet Webcast: Instalação e configuração de pesquisa no SharePoint Server 2007
• InfoPath Forms Services

Há muitos detalhes a considerar ao gerenciar documentos e outros conteúdos em uma organização. Entre outras coisas, é necessário definir quais pessoas ou processos devem realizar quais ações quando o conteúdo é criado, publicado, arquivado e descartado. Muitas vezes é necessário para uma organização desenvolver modelos específicos para criação de conteúdo, definir funções para atribuir responsabilidades e privilégios de acesso a usuários, fornecer controle de versão, monitorar a conformidade, armazenar e arquivar, definir metadados e assim por diante.

Por mais complexo que um ciclo de vida de conteúdo específico possa ser, o modelo de conteúdo do SharePoint reconhece que há características gerais e fases típicas que determinam como os itens de conteúdo individual devem ser manipulados. Por exemplo, é possível estruturar a criação de conteúdo por meio de modelos e formulários de entrada, e a exibição de conteúdo e pesquisas por meio de metadados. É possível usar edição, aprovação ou outros requisitos de fluxo de trabalho, requisitos de arquivamento, períodos de tempo de expiração e diretivas de gerenciamento de informação aplicáveis para distinguir as partes de conteúdo individual. Algum conteúdo pode não necessitar de modelos especiais ou nunca ser arquivado, mas mesmo essas são características de ciclo de vida que se distinguem esses itens de outros.

O modelo de conteúdo do SharePoint permite a definição de tipos de conteúdo individuais e o estabelecimento de relações hierárquicas. Em uma relação hierárquica, os filhos herdam características gerais dos tipos de conteúdo pais, adicionando características específicas conforme necessário.

A melhor forma de ilustrar isso é examinando os tipos de conteúdo internos do SharePoint. O WSS 3.0 e o MOSS 2007 incluem uma série de tipos de conteúdo para itens típicos que podem ser armazenados em uma biblioteca de documentos ou lista, incluindo documentos e tarefas. É possível encontrar as definições desses tipos de conteúdo padrão em um servidor SharePoint na pasta %CommonProgramFiles%\Microsoft Shared\Web Server Extensions\12\Template\Features\Ctypes. Lá você encontrará um arquivo de manifesto chamado feature.xml. Examinando esse arquivo, é possível observar que o SharePoint implementa as definições de tipo de conteúdo padrão como um recurso oculto (Hidden="TRUE") com um escopo de conjunto de sites (Scope="Site") e que o arquivo de manifesto Element contendo os elementos de tipo de conteúdo reais é ctypeswss.xml (<ElementManifest Location="ctypeswss.xml" />).

Se você estiver interessado em aprender mais sobre os recursos do SharePoint, recomendo a leitura da coluna Espaço do Office de Ted Pattison na MSDN® Magazine entitulada "Recursos do SharePoint", disponível em msdnmagazine.com/issues/07/05/OfficeSpace.

Agora, vamos abrir o arquivo ctypeswss.xml no Notepad para examinar os tipos de conteúdo padrão independentemente de sua visibilidade na interface do usuário do SharePoint. Você não deve modificar o ctypeswss.xml. Se você pensar em editar o ctypeswss.xml para adicionar novos campos aos tipos de conteúdo padrão ou tornar visíveis os tipos de conteúdo ocultos para que os usuários do SharePoint possam usá-los para derivar novos tipos, observe que isso não é geralmente necessário. Além disso, isso leva a configurações sem suporte e a instalação posterior de service packs pode substituir as suas personalizações e desfazer as suas soluções de gerenciamento de conteúdo.

Uma abordagem melhor é copiar o que for necessário em um novo arquivo de manifesto, adicionar as suas personalizações conforme necessário e implantar os seus tipos de conteúdo personalizados como um novo recurso com um escopo de conjunto de sites para que possam estar disponíveis para todos os sites dentro do conjunto de sites.

A definição baseada na Collaborative Application Markup Language (CAML) do tipo de conteúdo System como especificada no ctypeswss.xml é revelada a seguir:

<ContentType ID="0x"
    Name=$Resources:System
    Group="Hidden"
    Sealed="True"
    Version="0">
   <FieldRefs>
      <FieldRef ID="{c042a256-787d-4a6f-8a8a-cf6ab767f12d}" Name="ContentType"/>
   </FieldRefs>
</ContentType>

Os atributos Group e Sealed mostram que o tipo de conteúdo System é oculto e selado para que não possa ser alterado na interface de usuário do SharePoint. O tipo de conteúdo System tem somente um elemento FieldRef que faz referência a uma coluna de site interno chamado ContentType. Esse é o maior nível de abstração. Todos os outros tipos de conteúdo do SharePoint herdam essa propriedade do tipo de conteúdo System. Desse modo, o SharePoint certifica que todos os itens de conteúdo armazenados em qualquer biblioteca de documentos ou lista tenha essa propriedade em comum.

A Figura 1 mostra uma Web Part ContentTypeHierarchy incluída no material de acompanhamento deste artigo, que ilustra as hierarquias mais intuitivamente. O System está na raiz de todos os outros tipos de conteúdo, seguido de Item e assim por diante. O tipo de conteúdo Item, por exemple, estabelece o nível de detalhe posterior. Se você verificar o ctypeswss.xml, é possível observar que o Item define um único campo de metadados que faz referência a uma coluna de site chamada Title. Desse modo, todos os tipos de conteúdo internos em níveis mais baixos têm uma propriedade Title.

Figura 1** Hierarquia de tipo de conteúdo interna do WSS 3.0 **(Clique na imagem para aumentar a exibição)

É possível também remover um campo herdade, como demonstra a definição do tipo de conteúdo Document no ctypeswss.xml. O tipo de conteúdo Document inclui vários elementos RemoveFieldRef correspondentes, mas talvez você deseje manter o campo Title no local nos seus tipos de conteúdo personalizados porque a coluna Title fornece acesso ao menu suspenso Edit Control Box (ECB) nas exibições de biblioteca de documentos e lista do SharePoint.

Um bom exemplo para ilustrar como renomear campos herdados é o tipo de conteúdo Far East Contact no ctypeswss.xml. Pesquise por 0x0116, que é o ID de tipo de conteúdo correspondente e marque o elemento FieldRef com o atributo Name="Title" para observar como é possível usar o atributo DisplayName para renomear um campo na interface do usuário. Nesse exemplo específico, o atributo DisplayName altera o nome do campo Title na interface do usuário para um valor de dados localizado referenciado por "$Resources:core,Last_Name;".

Se você analisar melhor a Figura 1, é possível observar o atributo ID do elemento ContentType identificando de maneira exclusiva o tipo de conteúdo e estabelecendo a relação hierárquica. Todos os IDs começam com o ID do tipo de conteúdo pai anexado com valores hexadecimais adicionais. Os tipos de conteúdo padrão têm dois valores hexadecimais adicionais anexados para criar um novo ID exclusivo para o tipo de conteúdo filho. Outra técnica é anexar um “00” e um GUID hexadecimal. É assim que os tipos de conteúdo Office Data Connection File e Universal Data Connection File derivam do tipo de conteúdo Document, por exemplo.

Um ponto importante a ser lembrado pelos usuários é que o atributo ID do elemento ContentType não pode ter mais de 1,024 caracteres. Isso pode se tornar um problema em relações hierárquicas grandes se todos os tipos de conteúdo usarem a técnica de solução de GUID hexadecimal. No entanto, não é uma boa idéia começar com a técnica menor porque esses IDs podem não ser exclusivos.

Para garantir a exclusividade, use a técnica GUID para estabelecer um namespace global para os tipos de conteúdo da sua empresa e alternar para a técnica menor dentro desse namespace. Para obter informações detalhadas sobre o atributo ID e outros elementos de definição de tipo de conteúdo, consulte o tópico "Content Type Definition Schema" no WSS 3.0 SDK.

Dependências de tipo de conteúdo

Agora vamos examinar a questão de como usar os tipos de conteúdo do SharePoint 2007 para estruturar o gerenciamento de itens de conteúdo. É necessário levar em consideração várias dependências, como as interdependências entre bibliotecas de documentos e listas, tipos de conteúdo, colunas de site e tipos de campo. As bibliotecas e listas fazem referência a tipos de conteúdo, que fazem referência a colunas de site, que por sua vez fazem referência a tipos de campo (como os tipos de campo do WSS padrão texto, nota, escolha, número, moeda e assim por diante), que por sua vez reside nos assemblies do Microsoft .NET Framework, como o principal assembly WSS Microsoft.SharePoint.dll.

Por exemplo, retornemos ao tipo de conteúdo System conforme ilustrado anteriormente na definição CAML da entrada de arquivo de manifesto de tipo de conteúdo System. Como você viu, esse tipo de conteúdo contém um elemento FieldRef que faz referência a uma coluna de site chamada ContentType. Observe que a definição de tipo de conteúdo não define a coluna de site ContentType real. O ContentType é um campo Text, definido no manifesto Elementos fieldswss.xml, localizado na pasta %CommonProgramFiles%\Microsoft Shared\Web Server Extensions\12\Template\Features\Fields. O tipo de campo Text, novamente, é definido em fldtypes.xml, que pode ser encontrado em %CommonProgramFiles%\Microsoft Shared\Web Server Extensions\12\Template\XML. Um ponto importante a se observar nessa árvore de dependência é que é necessário garantir que todos os recursos estejam disponíveis nos seus servidores SharePoint.

Os tipos de conteúdo que você desejar usar devem ser criados no nível do site das suas bibliotecas de documentos e listas ou em posição superior na hierarquia do site. De maneira semelhante, os campos de metadados dos seus tipos de conteúdo devem fazer referência às colunas de site existentes. É possível adicionar colunas de site padrão ou personalizadas baseadas nos tipos de campo padrão ou personalizados para seus tipos de conteúdo, mas você deve certificar-se de que as colunas de site existam no site local. Além disso, se você desejar usar tipos de campo personalizados, será necessário também certificar-se de que os assemblies .NET subjacentes sejam implantados nos seus servidores SharePoint.

Existem dependências similares para tipos de conteúdo que fazem referência a modelos de documentos, receptores de eventos personalizados, fluxos de trabalho e outros componentes. Por exemplo, a definição de tipo de conteúdo pode conter um elemento DocumentTemplate que aponta para o modelo de documento associado com o tipo de conteúdo. A definição de tipo de conteúdo pode também conter um elemento XmlDocument com um ou mais elementos filho XmlDocument que definem características adicionais do tipo de conteúdo, como definições de namespace, definições de painel de informações de documento ou qualquer informação personalizada.

Estabelecendo tipos de conteúdo global

Os usuários com permissões de autoria podem criar novos tipos de conteúdo e colunas de site diretamente na interface de usuário do SharePoint, mas os tipos de conteúdo estão disponíveis então somente no site local e em posição inferior na hierarquia do site. As colunas de site personalizadas estão disponíveis apenas no site local. Isso não é suficiente se você desejar estabelecer tipos de conteúdo globais. É necessário certificar-se de que os tipos de conteúdo globais estejam disponíveis em todos os conjuntos de sites no seu ambiente. É aqui que os recursos do SharePoint se mostram realmente úteis. É simples instalar e ativar os recursos do SharePoint em vários conjuntos de sites para aplicar a coluna de site e definições de tipo de conteúdo correspondentes de maneira consistente em todos os locais.

O material de acompanhamento deste artigo inclui um recurso de exemplo chamado AdventureWorks que demonstra como estabelecer um tipo de conteúdo global. O recurso define um tipo de conteúdo geral chamado Customer Documentation que pode ser usado para criar qualquer tipo de materiais de cliente, como propostas e cartas de venda. É razoável pressupor que todos esses tipos de documentos devam estar associados com informações de cliente como nome da empresa, detalhes de contato e endereço. Eu criei especificamente um campo personalizado chamado Customer Name para o seu tipo de conteúdo e adicionei campos internos como Department e Primary Phone. É possível alterar o tipo de conteúdo e campos editando o arquivo ContentTypes.xml e as referências de campo editando o arquivo SiteColumns.xml no exemplo de acompanhamento.

Se você implantar o recurso conforme descrito no arquivo readme.htm, é possível ativá-lo consistentemente em vários conjuntos de sites. O tipo de conteúdo Customer Documentation estará, então, disponível globalmente. Com isso, os departamentos individuais podem criar documentação do cliente específica por meio de tipos de conteúdo derivados associados com modelos de documento Por exemplo, a definição de tipo de conteúdo pode conter um elemento DocumentTemplate que aponta para o modelo de documento associado com o tipo de conteúdo de destino. O material de acompanhamento inclui modelos de documento de exemplo que podem ser usados em vendas e consultoria. A Figura 2 mostra os tipos de conteúdo resultantes.

Figura 2** Tipos de conteúdo pais e filhos para documentação do cliente **(Clique na imagem para aumentar a exibição)

Há várias opções de escolha para criar recursos para colunas de site personalizados e tipos de conteúdo no WSS 3.0 e MOSS 2007. É possível estudar o WSS 3.0 SDK e escrever arquivos XML do zero. É possível também escolher usar o SharePoint Designer para exportar uma lista para um pacote da Web pessoal, renomear o arquivo .fwp resultante para um arquivo .cab, extrair o arquivo manifest.xml do arquivo .cab e pesquisar pelas definições ContentType no arquivo manifest.xml. Infelizmente as duas abordagens são inconvenientes e propensas a erro.

Em contraste, é consideravelmente fácil criar colunas de site e tipos de conteúdo personalizadas na interface do usuário do SharePoint. Ainda assim, a interface não fornece uma opção para editar os arquivos XML de um recurso. Os recursos são uma forma eficiente de provisionar recursos SharePoint, mas uma vez provisionados os recursos existem somente no banco de dados de conteúdo. Talvez uma versão futura do WSS inclua a capacidade de exportar colunas de site e tipos de conteúdo em arquivos XML por meio da interface do usuário do SharePoint, de maneira semelhante à exportação de Web Parts. Por enquanto, é necessário trabalhar com o que você tem.

O material de acompanhamento inclui uma Web Part chamada ContentTypeSchema que pode ser usado como ponto de partida. Ele usa o modelo de objeto do SharePoint para extrair a propriedade SchemaXML do tipo de conteúdo selecionado. Por meio de transformações baseadas em eXtensible Stylesheet Language Transformation (XSLT), a Web Part deriva definições Field ou definições ContentType dependendo da opção selecionada na interface do usuário antes de clicar no botão Display.

A Figura 3 mostra essa Web Part em ação. Ela exibe o tipo de conteúdo Active Directory® Documentation, que baseei no tipo de conteúdo Customer Documentation. O tipo de conteúdo Active Directory Documentation é associado a um modelo do Microsoft Word personalizado (Active Directory Template.dot). Observe que esse tipo de conteúdo não tem campos adicionais. Todos os campos são herdados do tipo de conteúdo pai.

Se você planeja usar a Web Part ContentTypeSchema no seu próprio ambiente, lembre-se de que essa Web Part não foi totalmente testada. Minha Web Part usa transformações XSL relativamente complexas para criar um delta entre a propriedade SchemaXML do tipo de conteúdo selecionado e seu tipo de conteúdo pai. Ainda assim, XSLT 1.0 não é realmente desenvolvido para conversões de documentos XML avançadas. Não há recursos internos para comparar nós XML. Além disso, namespaces XML, bem como seções CDATA, representam dificuldades que o XSLT 1.0 não consegue manipular de maneira eficiente.

O SharePoint armazena a definição de colunas de site e tipos de conteúdo de site criados usando a interface do usuário do SharePoint ou modelo de objeto do SharePoint no banco de dados de conteúdo em uma tabela chamada ContentTypes. Na Figura 3, observe o ID do meu tipo de conteúdo personalizado. Da mesma forma, a declaração T-SQL a seguir fornece resultados exatos: SELECT Definition FROM ContentTypes WHERE ContentTypeId = <content type ID>.

Figura 3** Definição de tipo de conteúdo personalizado no ContentTypeSchema Web Part **(Clique na imagem para aumentar a exibição)

Seja qual for a abordagem que você decida usar, criar recursos para tipos de conteúdo para toda a empresa é muito simples depois que você obtém as definições da coluna do site e tipo de conteúdo. Recomendo que você use um recurso único para todas as colunas de site e tipos de conteúdo globais do seu departamento ou empresa. Desse modo, fica claro onde adicionar novas definições de coluna de site e tipo de conteúdo.

Pesquisas em toda a empresa por metadados personalizados

Uma vantagem imediata das hierarquias de tipo de conteúdo é que todos os tipos de conteúdo filhos herdam os campos de metadados do tipo de conteúdo pai. Como todos os tipos de conteúdo têm campos de metadados em comum, é realmente fácil para os usuários criarem exibições e filtros personalizados nas bibliotecas de documentos.

O recurso de exemplo AdventureWorks demonstra isso de maneira intuitiva. Independentemente do conteúdo que um consultor ou vendedor cria, salvar o documento do Word 2007 resultante na biblioteca de documentos exige a especificação de um Customer Name, pois o tipo de conteúdo pai Customer Documentation define esse campo de metadados como obrigatório. Por meio do agrupamento ou filtragem dos itens em uma exibição da biblioteca de documentos de acordo com o Customer Name, os consultores e os membros da equipe de vendas podem localizar toda a documentação existente de um cliente de maneira rápida e conveniente, como mostrado na Figura 4.

Figura 4** Agrupando vários documentos em uma biblioteca baseada em metadados comuns **(Clique na imagem para aumentar a exibição)

Metadados comuns também tornam fácil localizar conteúdo em várias bibliotecas de documentos e sites usando as capacidades de pesquisa do WSS 3.0 e MOSS 2007. O WSS oferece suporte de pesquisa em bibliotecas, listas e sites dentro de um único conjunto de sites. O MOSS 2007 vai além dessas capacidades básicas permitindo a implementação de um Centro de Pesquisa em toda a empresa e o gerenciamento de metadados personalizados na interface do usuário da Administração Central do SharePoint 3.0. Por esse motivo, as explicações seguintes se concentram no MOSS 2007.

Ao configurar um Shared Service Provider (SSP) no MOSS 2007 e rastrear os seus sites do SharePoint, o MOSS 2007 pode descobrir automaticamente os campos de metadados personalizados usados nas fontes de conteúdo. Da mesma forma, é possível encontrar os campos de metadados personalizados na lista de propriedades rastreadas.

Os campos de metadados definidos nos recursos do SharePoint geralmente se encaixam na categoria SharePoint. Para encontrar o seu local na Administração Central do SharePoint, no menu Inicialização Rápida em Shared Services Administration, clique no link para o seu SSP, nas configurações de Pesquisa, em mapeamentos de propriedade de Metadados, em Propriedades Rastreadas no menu Inicialização Rápida e abra a categoria SharePoint.

Mostrarei um exemplo desta ação. O campo de metadados nomeado Customer Name acaba como uma propriedade rastreada chamada ows_Customer_x0020_Name. O SharePoint coloca um prefixo nas propriedades rastreadas com "ows_" e "_x0020_" é a versão codificada de um espaço único. Se você exibir os detalhes dessa propriedade rastreada, é possível encontrá-la incluída no índice de pesquisa por padrão para que os usuários possam empregar os valores dessa propriedade rastreada para realizar pesquisas de conteúdo. No entanto, para aumentar a precisão da pesquisa, talvez você não deseje mapear a propriedade rastreada para uma propriedade gerenciada para que os usuários possam pesquisar explicitamente pelo conteúdo por nome do cliente.

Há duas opções ao mapear propriedades rastreadas para propriedades gerenciadas. É possível gerar automaticamente uma nova propriedade gerenciada para cada propriedade rastreada ou mapear propriedades rastreadas manualmente para propriedades gerenciadas. A primeira opção está disponível quando são exibidas as configurações da categoria de propriedade rastreada desejada (ao exibir as propriedades rastreadas em uma categoria, como a categoria SharePoint, clique na opção Editar Categoria no link Inicialização Rápida). Em Configurações de Propriedades Rastreadas em Massa, seria necessário selecionar a caixa de seleção “Gerar automaticamente uma nova propriedade gerenciada para cada propriedade rastreada descoberta nesta categoria”. No entanto, o SharePoint coloca um em propriedades gerenciadas criadas automaticamente com "ows" e escapa espaços com "_x0020_". A propriedade gerenciada da propriedade rastreada ows_Customer_x0020_Name seria owsCustomerx0020Name. No entanto, esse não é um nome de propriedade muito amigável.

Talvez uma estratégia melhor seja mapear as propriedades rastreadas para propriedades gerenciadas manualmente depois de implantar os seus tipos de conteúdo em toda a empresa. É possível mapear uma propriedade rastreada para uma ou mais propriedades gerenciadas. Para criar novas propriedades gerenciadas, na Administração Central do SharePoint, no menu Inicialização Rápida Shared Services Administration, clique no link para o seu SSP, nas configurações de Pesquisa, em mapeamentos de propriedade de Metadados e em Nova Propriedade Gerenciada para especificar as informações necessárias e associar a nova propriedade gerenciada com a propriedade rastreada desejada.

Os usuários podem então localizar itens de conteúdo relevantes usando as propriedades gerenciadas tanto em property: syntax ou usando a pesquisa avançada. Por exemplo, se você mapear a propriedade rastreada ows_Customer_x0020_Name para uma propriedade gerenciada nomeada Customer, os usuários poderão pesquisar por todos os documentos de um cliente simplesmente especificando Customer: <Nome do cliente> na caixa de pesquisa padrão, como Customer: Contoso.

É também uma boa idéia incluir propriedades gerenciadas para os campos de metadados mais importantes dos seus tipos de conteúdo na lista de propriedades na página Pesquisa Avançada. Para tanto, exiba a página Pesquisa avançada, clique em Ações do Site e selecione o comando Editar Página. Agora é possível clicar em Editar na Caixa de Seleção Avançada para selecionar a opção Modify Shared Web Part. Ao expandir a categoria Properties e colocar o cursor no campo de texto correspondente, é possível clicar no botão para editar o documento XML Properties. É necessário adicionar uma definição de propriedade ao elemento <PropertyDefs>, como <PropertyDef Name="Customer" DataType="text" DisplayName="Customer Name"/> e é necessário também adicionar uma referência a essa definição de propriedade em um elemento ResultType (por exemplo, o elemento <ResultType DisplayName="All Results" Name="default">), como <PropertyRef Name="Customer" />. A Figura 5a exibe a interface do usuário Pesquisa Avançada resultante. A Figura 5b exibe os resultados da pesquisa.

Figura 5a** Pesquisa por documentação de infra-estrutura de TI baseado no nome do cliente **(Clique na imagem para aumentar a exibição)

Figura 5b** Os resultados da pesquisa de nome de cliente **(Clique na imagem para aumentar a exibição)

Garantindo a consistência da informação

Nesse ponto, padronizei com êxito os campos de metadados e tipos de conteúdo mais importantes e estendi as capacidades de pesquisa em conjuntos de site na minha empresa baseado no MOSS 2007. Agora é importante garantir que os usuários insiram informações precisas nos campos de metadados.

Há duas maneiras de fazer isso. Primeiro, é possível substituir o painel de informações de documento padrão nos seus modelos de documentos com um formulário do InfoPath® personalizado que fornece aos seus usuários uma seleção predefinida de opções de entrada, como você tem em uma caixa de listagem. Em segundo lugar, é possível ligar um receptor de eventos ao tipo de conteúdo e verificar a precisão dos metadados e outras informações sempre que os usuários criarem, modificarem ou excluírem itens de conteúdo correspondentes.

As duas opções complementam uma à outra. Um formulário do InfoPath fornece principalmente uma maneira conveniente de editar as propriedades de um tipo de conteúdo do SharePoint, enquanto um receptor de eventos pode garantir metadados válidos mesmo que os usuários editem as propriedades do tipo de conteúdo fora do formulário do InfoPath. É possível ligar manipuladores de eventos a tipos de conteúdo específicos, o que permite a você especificar eventos e suas respostas para todos os documentos associados com um tipo de conteúdo individual em todos os conjuntos de sites, independentemente da biblioteca de documentos. É possível encontrar mais informações sobre como desenvolver e implantar manipuladores de eventos em msdn2.microsoft.com/ms453149.

Talvez o método mais fácil para associar um tipo de conteúdo com um painel de informações de documento personalizado seja exibir as configurações do Painel de Informações de Documento do tipo de conteúdo na interface do usuário do SharePoint em um computador com o InfoPath 2007 instalado. É possível então clicar no link Criar um Novo Modelo Personalizado em Modelo de Painel de Informações de Documento para iniciar o InfoPath 2007 no modo de design. No entanto, se o seu tipo de conteúdo de site inclui colunas de site sem um atributo SourceID explícito, talvez você encontre uma situação na qual o InfoPath não possa criar um esquema XSD válido para o formulário Painel de Informações de Documento. Por exemplo, o tipo de conteúdo Customer Documentation apresentado anteriormente inclui várias colunas específicas de contato como Department, Office e e-mail que podem causar esse problema, conforme ilustrado na Figura 6.

Figura 6** Incompatibilidades com o esquema XSD no InfoPath 2007 **(Clique na imagem para aumentar a exibição)

Nesse ponto, há duas opções caso você encontre esse problema. É possível remover as referências a colunas de site sem um atributo SourceID explícito da definição de tipo de conteúdo ou substituir as colunas de site internas que causam o problema com colunas de site personalizadas que sejam compatíveis com o InfoPath 2007. Lembre-se de que não é possível alterar as referências de campo de um tipo de conteúdo baseado em CAML depois de ter sido provisionado no banco de dados de conteúdo, especialmente se você já tiver criado tipos de conteúdo filhos. Não é mais possível simplesmente atualizar o arquivo de definição de tipo de conteúdo baseado em CAML ou empurrar alterações nos tipos de conteúdo filhos porque o Windows SharePoint Services não controla alterações realizadas em definições de tipo de conteúdo pai.

Para empurrar as alterações, é necessário alterar o tipo de conteúdo pai por meio da interface do usuário ou do modelo de objeto do SharePoint, ou definir um novo tipo de conteúdo que seja derivado do existente. A segunda técnica permite a você remover os campos críticos e adicionar novas colunas. Os seus usuários podem então derivar tipos de conteúdo futuros do novo tipo de conteúdo. Para evitar que os usuários escolham o tipo de conteúdo errado, adicione o tipo de conteúdo anterior ao grupo de tipo de conteúdo _Hidden.

Como eu disse antes, não é possível atualizar tipos de conteúdo baseados em CAML depois de implantá-los e ativá-los. Desse modo, é muito importante testar os tipos de conteúdo globais antes da implantação. Para obter mais informações, consulte o artigo da MSDN “Atualizando tipos de Conteúdo” em msdn2.microsoft.com/aa543504.

Depois de criar um tipo de conteúdo com as referências de campo apropriadas, é possível criar um painel de informações de documento personalizado no InfoPath 2007. A melhor estratégia é deixar que os proprietários de sites criem painéis de informações de documento personalizado para os seus tipos de conteúdo filhos. O InfoPath 2007 fornece a opção de publicar os painéis de informações de documento personalizados diretamente nos tipos de conteúdo selecionados, facilitando o cenário de implantação. Ainda assim, é possível também publicar o formulário do InfoPath em um local central, como uma biblioteca de documentos, e incluir uma referência ao painel de informações de documento no tipo de conteúdo. Essa é a melhor opção se você planeja fornecer um painel de informações de documento personalizado juntamente com os seus tipos de conteúdo CAML. A Figura 7 ilustra a arquitetura de implementação.

Figura 7** Implementação de arquivo XSN em um local central no MOSS 2007 **(Clique na imagem para aumentar a exibição)

O download de acompanhamento deste artigo inclui um recurso chamado AdventureWorks_Update que estende o recurso AdventureWorks anterior adicionando colunas de site adicionais que funcionam com o InfoPath 2007. O recurso AdventureWorks_Update marca o tipo de conteúdo Customer Documentation original como oculto e deriva um novo tipo de conteúdo chamado Customer Docs, que substitui os campos internos herdades com a nova coluna de site e associa o novo tipo de conteúdo a um painel de informações de documento personalizado.

A nova definição de tipo de conteúdo Customer Docs inclui um elemento XmlDocument que fornece informações sobre o painel de informações de documento. O elemento xsnLocation aponta especificamente para o formulário do InfoPath http://companyresources/DIPs/customerDIP.xsn, que implementa o painel de informações de documento. Para obter instruções detalhadas sobre como aplicar o recurso AdventureWorks_Update, consulte o arquivo readme.htm na pasta AdventureWorks_Update.

Conclusão

É possível usar os tipos de conteúdo do SharePoint para criar diretivas de metadados e usá-las de maneira consistente na empresa para o gerenciamento de conteúdo. A hierarquia de tipos de conteúdo permite padronizar características relevantes à todo o ambiente empresarial e sua aplicação uniforme em todos os sites por meio de herança.

Entre outras coisas, é possível estender as capacidades de pesquisa internas do MOSS 2007 para que os usuários possam localizar conteúdo específico de maneira mais rápida e conveniente. É possível também impor a consistência das informações relacionadas a metadados e estabelecer diretivas de gerenciamento de informações centralizadas. A melhor estratégia é padronizar os tipos de conteúdo globais nas características de metadados mais abstratas para minimizar a necessidade de alterações posteriores. Baseado em um modelo de conteúdo cuidadosamente desenvolvido, os tipos de conteúdo do SharePoint forneces novas capacidades de padronização de gerenciamento de ciclo de vida de conteúdo na empresa.

Pav Cherny é presidente da Biblioso Corporation, especialista em TI e autor especializado em tecnologias Microsoft para colaboração e comunicação unificada. Seus trabalhos publicados se concentram em operações de TI e administração de sistemas.

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