SharePoint

Uma abordagem inteligente para coleta de dados na empresa

Keith Deshaies

Visão geral:

• Coletando e processando dados
• Separando a lógica de apresentação da lógica de gerenciamento de informação
• Usando as tecnologias do Microsoft Office 2007 para criar uma solução de coleta de dados

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

As empresas coletam enormes quantidades de informação usando uma variedade e métodos. Os dados chegam por email, pesquisas, formulários da Web e outros mecanismos de coleta de dados. Dados são, geralmente, algo

bom. No entanto, gerenciar a matriz de ferramentas de coleta de dados e todas as informações distintas é difícil. A integração confiável e o compartilhamento seguro de dados são desafios constantes para as organizações de TI. Padrões e arquiteturas orientadas a serviços estão evoluindo, tornando mais fácil para os profissionais de TI tornar os dados mais acessíveis de maneira mais segura. Mas enquanto você tem as ferramentas e tecnologias necessárias para criar uma arquitetura empresarial eficiente, é muito comum ficar preso em uma rede de interfaces proprietárias—e isso leva a soluções isoladas.

Tome as tecnologias disponíveis no sistema Microsoft® Office como exemplo. É possível criar de maneira rápida uma pesquisa departamental baseada no Windows® SharePoint® Services 3.0, mas se essa é uma solução padrão vai depender da sua organização. Se a sua empresa usa ASP.NET e SharePoint como plataforma para colaboração e integração de dados baseados na Web, então essa pesquisa fornece uma solução padronizada. Mas se o seu ambiente for como aquele onde trabalho, o SharePoint é somente uma plataforma entre outras.

Certo, o SharePoint fornece muitas opções para a integração com os sistemas da IBM, HP, Siebel e assim por diante. Essa é uma boa notícia para os usuários avançados que desejam criar soluções ad hoc e ter ainda o fluxo de dados resultante em uma variedade de sistemas back-end. No entanto, se você for um arquiteto de soluções, há uma maneira ainda melhor—o InfoPath® 2007.

Com o InfoPath 2007, que é parte do sistema Office 2007, é possível separar a lógica de apresentação das suas soluções da lógico de gerenciamento de informação nos seus servidores. Com a tecnologia baseada em CML do InfoPath, é possível criar soluções de coleta de dados prontas para a empresa. Na maior parte do tempo, os designer de formulário do InfoPath não necessitam de conhecimentos detalhados sobre XML, serviços Web, arquiteturas de solução, ASP.NET ou modelo de objeto do SharePoint.

Neste artigo, discutirei sobre como é possível criar soluções de coleta de dados flexíveis usando o InfoPath 2007, Office SharePoint Server 2007 e Forms Services. E mostrarei como o XML permite a você separar a lógica de apresentação da lógica de negócios em uma arquitetura empresarial de várias camadas.

Observe que ao me referir a “coleta de dados”, me referiro ao processo de coleta de informações de origens humanas. Existem, é claro, outras maneiras de coletar dados, como o rastreamento de origens de dados, mas esses métodos automáticos estão além do escopo deste artigo.

Adquirindo e manipulando dados

Os requisitos de aquisição de dados podem ser complicados, mas esses processos têm algumas coisas em comum. Ao tratar essas semelhanças em módulos centralizados enquanto manipula requisitos exclusivos em componentes descentralizados, é possível limitar esforços redundantes, sobrecarga de manutenção e o custo total de propriedade.

Por exemplo, os regulamentos de conformidade para empresas públicas resultam em requisitos de negócios que, por sua vez, são convertidos em diretivas de gerenciamento de informação para toda a empresa. Essas diretivas afetam as soluções de coleta de dados em limites departamentais e muitas vezes levam à esforços duplicados em departamentos individuais—por exemplo, regras sobre a coleta de informações de identificação pessoal coletadas por um departamento de RH (manipulando informações de funcionários) e um departamento de serviços ao cliente (manipulando informações de clientes). Mesmo processos de negócios entre departamentos individuais semelhantes porém não relacionados fornecem oportunidades para a unificação de soluções de gerenciamento de informações.

A Figura 1 mostra um exemplo de processo de negócios típico. Um funcionário que deseja negociar uma atribuição com um colega deve primeiro obter um acordo com o colega, depois a aprovação de um gerente ou coordenador da programação de atribuições e, finalmente, do supervisor. Isso pode envolver funcionários trocando turnos de trabalho, por exemplo. Embora essas trocas ocorram em departamentos diferentes e possam recorrer a formas diferentes, os fluxos de trabalho e a lógica de gerenciamento de informação podem ser compartilhadas entre as várias soluções de departamentos.

Figura 1** Processo de coleta de dados de exemplo que pode ser compartilhado entre departamentos **(Clique na imagem para aumentar a exibição)

Claro, consolidar componentes redundantes é uma tarefa árdua. Orientar alterações organizacionais em uma empresa não é fácil, mas com as tecnologias do sistema Office é possível criar uma base sólida para facilitar essas alterações. O InfoPath 2007 permite aos departamentos individuais criar aplicativos de formulários que se integram a sistemas de gerenciamento de informação centralizados e padronizados. O SharePoint 2007, enquanto isso, permite aos departamentos de TI delegar o controle administrativo sobre conjuntos de sites, sites e bibliotecas de documentos a departamentos e equipes individuais. Como resultado, as equipes podem criar e implantar as suas próprias soluções com o envolvimento mínimoo de TI, enquanto os departamentos de TI permanecem controlando todos os serviços e componentes compartilhados, como fluxos de trabalho, diretivas de gerenciamento de informação e procedimentos de backup.

Centralizando os seus esforços de coleta de dados

As empresas muitas vezes oferecem às equipes servidores de aplicativos departamentais para acomodar as necessidades de gerenciamento de informação individuais. O departamento de TI é responsável somente pela manutenção do hardware e do sistema operacional em execução, enquanto os departamentos individuais cuidam de todos os aspectos de duas soluções. Há pouca coordenação entre os departamentos, e o compartilhamento de informações é difícil.

Os desafios técnicos de centralizar os esforços de coleta de dados giram principalmente em torno da segurança, desempenho, manutenção e suporte de componentes personalizados hospedados em um ambiente compartilhado. Por exemplo, os efeitos de um componente com funcionamento incorreto são isolados se as soluções individuais forem hospedadas em servidores de aplicativos departamentais. No entanto, em um ambiente compartilhado, um componente com funcionamento incorreto pode afetar processos de negócios em uma escala muito maior. É por isso que o departamento de TI deve estabelecer diretivas rigorosas em relação à implantação e manutenção de componentes personalizados em sistemas centralizados.

A hospedagem de soluções departamentais do SharePoint em um farm de servidor central exige a implantação e manutenção de todos os componentes personalizados das soluções departamentais nos servidores de aplicativos centrais. Uma solução pode recorrer a tipos de campo personalizados para estender a interface do usuário da solução com listas suspensas populadas de serviços da Web de back-end. Outra solução seria recorrer a Web Parts com o mesmo objetivo enquanto outros usam fluxos de trabalho personalizados—todos escritos em código gerenciado e implantados como assemblies do Microsoft .NET Framework.

Mover até mesmo um número relativamente pequeno de soluções do SharePoint para um farm de servidor de aplicativo central pode levar a configurações difíceis e problemas de suporte. Se os assemblies devem ser implantados no GAC (Global Assembly Cache), a segurança se torna um problema pois esses assemblies são executados em confiança total. Componentes mal programados podem abrir o sistema a injeções SQL, scripts entre sites ou ataques de negação de serviço. É necessário certificar-se de que os componentes possam sustentar a carga de trabalho típica, bem como os picos de demanda e operações de longa duração. É necessário certificar-se de que os componentes não bloqueiem outros processos, manipulando eventos de modo síncrono, e que os componentes executem validação de entrada confiável—para que os usuários não insiram declarações ou scripts SQL em colunas usadas para atualizar o banco de dados ou sistema da Web remoto.

Em resumo, a meta é enfatizar a configuração do servidor de maneira escalar e segura baseado em recursos de produto padrão. Recorrendo a soluções reutilizáveis e totalmente testadas, é possível evitar a armadilha de criar numerosos componentes personalizados. Faz sentido manter o front-end descentralizado e o back-end, centralizado. A chave é integrar os componentes de uma maneira flexível que promova a reutilização de soluções existentes

Dividindo a lógica de negócios

Então, como criar soluções de coleta de dados flexíveis que possam ser configuradas nos nossos servidores? A melhor estratégia é separar a arquitetura de solução em camadas individuais como mostrado na Figura 2: armazenamento de dados, lógica de negócios e apresentação ou interface do usuário. Atualmente, a interface do usuário é geralmente baseada no navegador enquanto a lógica de negócios reside nos servidores de aplicativos Web. Esses, por sua vez, acessam bancos de dados e repositórios de dados não relacionais.

Figura 2** Uma solução empresarial típica criada em uma arquitetura de três camadas **(Clique na imagem para aumentar a exibição)

A lógica de negócios muitas vezes inclui uma lógica de transação para garantir que as transações sejam aplicadas automaticamente em sistemas de gerenciamento de banco de dados. A lógica de negócios pode também integrar vários serviços de camadas intermediárias por meio de HTTP, enfileiramento de mensagens, RPCs e assim por diante. A arquitetura de solução geral, no entanto, permanece essencialmente um modelo de três camadas.

O que a Figura 2 não ilustra é q complexidade da lógica de negócios em um ambiente empresarial. Parece que o servidor de aplicativo nessa figura está concentrado simplesmente no processamento de um formulário baseado no navegador e manipulando os dados enviados; mas essa representação não leva em consideração os requisitos de fluxo de trabalho, conformidade ou gerenciamento de informação. Para tratar esses requisitos, é necessário dividir a lógica de negócios em duas—a lógica de apresentação e a lógica de gerenciamento de informação. Isso permite a você misturar e combinar os componentes de camada intermediária conforme necessário sem a recriação de componentes do zero para cada solução.

A Figura 3 mostra essa arquitetura. No centro está o conteúdo ou dados, rodeados pela lógica de gerenciamento de informação, que governa o conteúdo por todo o seu ciclo de vida. A lógica de apresentação faz a interface com a lógica de gerenciamento de informação para fornecer acesso aos dados por meio da interface do usuário.

Figura 3** Separando a lógica de apresentação da lógica de gerenciamento de informação **

Coletando e processando XML

Em ambientes de aplicativos orientados a serviços (SOA), o XML é o padrão dominante usado para definir e compartilhar dados e estruturas de dados entre componentes. E o XML é, portanto, uma boa escolha para fazer a interface entre componentes de apresentação e gerenciamento de informação.

A comunicação deve se mover em duas direções: será necessário converter o XML em um documento inteligível para o navegador, bem como um documento CML gerado pelo formulário. Até recentemente, criar aplicativos de formulário baseados em XML exigia habilidades de programação extensas. Isso era especialmente verdadeiro quando os dados XML resultantes tinham que aderir a um esquema da indústria para facilitar a troca de informações interorganizacionais.

O InfoPath 2007 torna o desenvolvimento de formulários baseados em XML muito mais fácil. Um bom entendimento dos detalhes do XML é certamente útil, mas os designers de formulários e usuários avançados não precisam ser magos do XML para criar aplicativos de formulários baseados em XML. O designer de formulários simplesmente importa um documento ou esquema XML para o InfoPath e mapeia o atributo individual e nós de elemento daquela origem de dados para os campos no formulário. Um designer de formulários pode também começar com um serviço da Web, banco de dados do SQL Server® ou de um modelo em branco e criar um formulário do zero enquanto o InfoPath cria automaticamente o esquema subjacente e as ligações de dados no segundo plano.

A padronização de formulários usando o InfoPath e esquemas XML tem várias vantagens. Se você já tem um esquema XML bem definido, os designers de formulários e desenvolvedores de fluxo de trabalho e componentes de gerenciamento de informação podem criar soluções para as mesmas estruturas de dados. Se um designer de formulários começa do zero, os desenvolvedores devem esperar até que o formulário seja concluído para ver como ele afeta as estruturas de dados subjacentes. E quando as estruturas de dados forem definidas, soluções futuras, como novos modelos de formulários, podem reutilizar fluxos de trabalho existentes e componentes de gerenciamento de informação se recorrerem às mesmas estruturas de dados. Os componentes de fluxo de trabalho e gerenciamento de informação futuros poderão trabalhar juntamente com formulários e dados existentes. Se você criar soluções de coleta de dados baseadas em esquemas estabelecidos do setor, os resultados se tornam ainda mais flexíveis. Na verdade, essas soluções serão compatíveis com soluções criadas por outras empresas que usam os mesmos esquemas.

Eu criei um esquema DirectReports simples que associa os funcionários aos gerentes. Os gerentes podem usar o formulário resultante para avaliar seus relatórios diretos. É possível encontrar o esquema, o formulário e um arquivo readme.htm com instruções para recriar o formulário na pasta Direct Reports no download que acompanha este artigo, disponível em technetmagazine.com/code08.aspx. O formulário é básico, mas ilustra o conceito geral.

Este é um ponto muito importante: eu não criei nenhuma lógica de validação no InfoPath, mas o InfoPath ainda exige que sejam inseridos os ID de usuário e endereços de email em um formato específico (domínio\conta e destinatário@domínio.tld). Caso contrário, o documento XML resultante não será válido. Isso ocorre porque o esquema XML define esses formatos. É possível salvar o formulário com dados inválidos mas você não poderá enviá-lo, como mostra a Figura 4. (Eu adicionei uma regra de envio fictícia para o formulário para que você possa testar isso sem realmente enviar dados para local nenhum). A validação do InfoPath 2007 garante automaticamente que o formulário esteja preenchido totalmente e sem esse tipo de erro.

Figura 4a** Validação de erros evitam que o usuário envie um formulário **(Clique na imagem para aumentar a exibição)

Figura 4b** A mensagem de erro gerada **(Clique na imagem para aumentar a exibição)

O esquema XML funciona como o contrato de ligação entre a lógica de apresentação e a lógica de gerenciamento de informação. O InfoPath bloqueia o esquema para que os designers de formulários não possam alterar intencionalmente as estruturas de dados. Isso é importante pois alterar um esquema XML estabelecido pode potencialmente quebrar as soluções empresariais existentes, como módulos de fluxo de trabalho que você tenha a intenção de usar em combinação com o novo modelo de formulários.

O InfoPath fornece uma abundância de recursos para a criação de lógicas de apresentação avançadas em aplicativos de formulários. É possível consumir dados de arquivos XML, serviços da Web, bibliotecas e listas do SharePoint, bancos de dados e assim por diante para obter valores padrão significativos. É possível alterar valores de campo baseados na seleção do usuário por meio de regras, incluindo lógica de validação, adição de código gerenciado para os requisitos de personalização mais avançados e o uso do Forms Service para tornar o modelo de formulário acessível na Web. De qualquer modo, os dados do formulário eventualmente atingem a lógica de gerenciamento de informação como um documento XML compatível com uma definição de esquema.

Trabalhando com XML ou metadados

Você pode imaginar se deve aplicar a lógica de gerenciamento de informação diretamente ao documento XML enviado ou, em vez disso, usar um analisador que extraia as informações necessárias em metadados. O SharePoint oferece suporte às duas abordagens. Os desenvolvedores estão acostumados a trabalhar diretamente com documentos XML, mas os metadados oferecem mais flexibilidade.

Para demonstrar isso, criei um serviço da Web simples que analisa um documento XML passado do formulário Direct Reports mostrado na Figura 4. (O código-fonte, arquivos de configuração e um arquivo readme.htm com instruções passo a passo podem ser encontrados na pasta XMLParsingWebService no download de acompanhamento). O serviço da Web simplesmente lê o ID de usuário do gerente a partir do documento XML, divide o ID do usuário em partes de domínio e nome de usuário, cria uma mensagem baseada nessas partes e gera uma exceção genérica para retornar e exibir a informação processada na forma de uma mensagem de pseudo-erro no formulário do InfoPath. Essa é uma forma fácil de gerar uma caixa de diálogo popup no InfoPath depois que os dados forem enviados. O serviço da Web funciona bem, mas se você alterar a origem de dados subjacente (por exemplo, se você renomear o elemento OrgPerson para Manager no DirectReports.xsd e atualizar o formulário do InfoPath com o novo esquema conforme descrito no arquivo readme.htm) o serviço da Web falha. Mas isso não deve ser uma surpresa. O documento XML é agora diferente e a antiga expressão XPath para acessar o elemento user-id é inválida. Os esquemas OrgPerson e Manager são quase idênticos, os formulários do InfoPath são idênticos, e os resultados de processamento desejados são os mesmos, mas apesar das diferenças serem mínimas, ainda é necessária implantar e manter serviços da Web duplicados.

Essa não é uma boa abordagem se você deseja minimizar a superfície de código personalizado nos seus servidores de aplicativos. Em contraste, mapear os nós XML para campos de metadados e executar o processamento baseado nos metadados permite o uso dos mesmos fluxos de trabalho e lógica de gerenciamento de informação para estruturas de dados semelhantes mesmo que os esquemas XML sejam diferentes. É necessário somente certificar-se de que os elementos filhos sejam mapeados para o campo de metadados correto e que o formato de dados atenda às exigências de processamento—então você poderá reutilizar o código existente.

Mapear nós XML para campos de metadados é semelhante a ligar nós XML a controles de interface do usuário em um formulário do InfoPath, como mostrado na Figura 5. No SharePoint, campos de metadados correspondem a colunas definidas no nível do site ou lista e são referenciados nas definições de tipo de conteúdo. Tipos de conteúdo definem as características de itens de conteúdo, como campos de metadados, fluxos de trabalho e formulários. Para manter os campos de metadados de um tipo de conteúdo sincronizados com os nós correspondentes nos documentos XML associados, o SharePoint recorre a um analisador XML interno que executa promoções e rebaixamentos de propriedade. Durante a promoção de propriedades, o analisador XML extrai valores de nó de um documento XML para colunas correspondentes na biblioteca de documentos. O rebaixamento de propriedade se refere ao processo reverso no qual valores de coluna são retirados da biblioteca de documentos e gravados novamente no documento. O ponto mais importante é que o analisador XML mantém sincronizados os campos de metadados e nós XML mapeados.

Figura 5** Mapeamentos de esquema XML entre o InfoPath e o SharePoint **(Clique na imagem para aumentar a exibição)

Ao usar o modelo de objeto do SharePoint, suas Web Parts, fluxos de trabalho e lógica de gerenciamento de informação podem funcionar com campos de metadados bem como os documentos XML subjacentes. Alterar o valor de um campo de metadados mapeado altera o valor do nó no documento XML e vice-versa. Ainda assim, trabalhar diretamente com o documento XML liga rigidamente a lógica de negócios com o esquema XML. Os campos de metadados mapeados, por outro lado, aumentam a capacidade de reutilização do código. Obviamente, é necessário decidir qual abordagem é a melhor para o seu ambiente, mas em sua maior parte as soluções do SharePoint que recorrem a campos de metadados fornecem maior flexibilidade e mais oportunidades para reutilização do código.

Para ilustrar como o SharePoint associa os nós XML com campos de metadados, incluí um recurso do SharePoint no material de acompanhamento para provisionar uma biblioteca de documentos personalizada (consulte o arquivo OrgPersonContentType.xml localizado na pasta OrgPersonLib no download de acompanhamento). O tipo de conteúdo OrgPerson faz referência a quatro campos: UserID, FullName, EMail e Direct_x0020_Reports. FullName e EMail são campos internos. UserID r Direct_x0020_Reports são campos personalizados definidos em OrgPersonSiteColumns.xml.

As definições de campo são bem simples. É possível ligar campos a nós XML diretamente nas definições de campo e é possível também substituir essa informação nos tipos de conteúdo. Decidi usar a segunda técnica porque ela me permite usar os campos personalizados em tipos de conteúdo não relacionados a documentos XML bem como em tipos de conteúdo que recorrem a diferentes estruturas XML. O tipo de conteúdo OrgPerson liga os campos de metadados aos nós XML que correspondem à sua disposição no esquema OrgPerson discutido anteriormente. Há também um arquivo AdditionalContentTypes.xml que define mais tipos de conteúdo que ligam os mesmos campos de metadados a diferentes nós XML. É possível observar as diferenças se você examinar as expressões XPath nos atributos Node.

As bibliotecas de documentos do tipo OrgPersonLib podem armazenar tipos diferentes de documentos XML enquanto os valores de nó são expostos por meio das mesmas colunas de bibliotecas. Essa técnica de mapeamento simples permite também a reutilização de fluxos de trabalho e lógica de gerenciamento de informação já que os quatro tipos de conteúdo (OrgPerson, Manager, Supervisor e User) fazem referência a um conjunto comum de campos de metadados.

A Figura 6 mostra o elemento FieldRef do tipo de conteúdo OrgPerson de Direct_x0020_Reports, que mapeia o campo para os nós user-id de relatórios diretos de acordo com a expressão XPath /OrgPerson/direct-report/user-id. Como o documento XML pode incluir várias entradas de relatório direto, é importante especificar um atributo Aggregation. Isso define como o analisador XML manipulará a coleção de valores retornada. Se este atributo for omitido, o analisador XML extrai somente o primeiro valor de nó. Os valores de agregação com suporte são sum, count, average, min, max, merge, plain text, first e last.

Figura 6** Campo de metadados mapeado para uma expressão XPath **(Clique na imagem para aumentar a exibição)

Todos os tipos de conteúdo de exemplo usam a página upload.aspx padrão como DocumentTemplate para que seja possível carregar arquivos XML na biblioteca de documentos ao clicar no botão New na interface de usuário do SharePoint. Desde que você carregue arquivos com uma extensão de nome de arquivo .xml, o SharePoint invocará automaticamente o analisador XML interno (com exceção dos arquivos WordProcessingML, para os quais o SharePoint invoca um analisador WordProcessingML). O analisador XML examina o arquivo .xml carregado para determinar o tipo de conteúdo associado. É assim que ele extrai os valores de nó dos locais especificados nas definições de campo e executa a promoção de propriedade. (É possível verificar esse processo ao carregar o arquivo OrgPerson.xml incluído na pasta OrgPersonLib\XMLFiles). A estrutura desse documento XML corresponde às expressões XPath especificados na definição de tipo de conteúdo OrgPerson. Da mesma forma, o SharePoint extrai os dados do arquivo .xml, grava os dados nas colunas de biblioteca correspondentes e exibe os dados na página EditForm.aspx para que seja possível verificar e atualizar as propriedades do documento que não estão marcadas como somente leitura. A Figura 7 mostra o formulário EditForm.aspx com os dados extraídos de OrgPerson.xml.

Figura 7** Formulário EditForm.aspx com dados extraídos **(Clique na imagem para aumentar a exibição)

Se você alterar os valores User ID, Full Name ou E-Mail no EditForm.aspx, o SharePoint executa o rebaixamento de propriedade para alterar os valores de nó no documento XML subjacente. Observe, no entanto, que o SharePoint não impõe restrições de Esquema XML a menos que você implemente a lógica necessária no formulário por conta própria.

O SharePoint também não executa a lógica de apresentação de um aplicativo de formulários. Por exemplo, ao alterar o User ID, o SharePoint não valida se o novo valor está de acordo com as convenções NetBIOS e não atualiza automaticamente os campos Full Name e E-Mail para corresponder à nova seleção. Portanto, você deve marcar a coluna correspondente na definição de tipo de conteúdo como somente leitura se a alteração de um campo individual causar inconsistências. Isso força o usuário a usar o aplicativo de formulários, como o InfoPath, para atualizar os dados. E o analisador XML promoverá qualquer alteração do documento XML para os campos de metadados correspondentes no SharePoint.

No exemplo OrgPersonLib, é possível carregar qualquer um dos arquivos .xml da pasta OrgPersonLib\XMLFiles. Os arquivos .xml files usam estruturas de dados muito diferentes, mas o SharePoint reconhece os tipos de conteúdo e promovem os valores de nó corretos nas colunas de site. Isso ocorre porque usei uma instrução de processamento nos arquivos XML para associar os documentos XML com seus tipos de conteúdo correspondentes. O arquivo OrgPerson.xml, no entanto, não inclui essa informação, mas isso não é um problema. Se o SharePoint não consegue associar um documento XML a um tipo de conteúdo por meio de uma instrução de processamento ou modelo de documento, ele usa o tipo de conteúdo padrão. No caso do OrgPersonLib, este é o tipo de conteúdo OrgPerson e, portanto, o documento XML é analisado corretamente.

A Figura 8 mostra como associar um documento XML explicitamente a um tipo de conteúdo. A instrução de processamento MicrosoftWindowsSharePointServices define o ContentTypeID como 0x010100668E393E4F0EFF4294DBD202D5D8321D. Isto é o ID do tipo de conteúdo User, conforme definido em AdditionalContentTypes.xml.

Figura 8** Instruções de processamento e dados XML do arquivo de exemplo User.xml **(Clique na imagem para aumentar a exibição)

O analisador XML processa a instrução de processamento MicrosoftWindowsSharePointServices e grava o valor do ContentTypeID no campo de metadados ContentType. Todos os tipos de conteúdo do SharePoint compartilham esse campo de metadados, pois ele é definido no nível raiz do tipo de conteúdo System. Se você abrir o arquivo fieldswss.xml em um servidor do SharePoint (localizado na pasta %CommonProgramFiles%\Microsoft Shared\Web Server Extensions\12\Template\Features\Fields) e pesquisar por MicrosoftWindowsSharePointServices, é possível observar como o SharePoint associa as instruções de processamento com o campo ContentType. O atributo PITarget aponta para o MicrosoftWindowsSharePointServices (essa é a instrução de processamento) e o atributo PIAttribute aponta para o ContentTypeID (que contém o ID do tipo de conteúdo User).

Associações de tipo de conteúdo no InfoPath

Os aspectos técnicos da análise XML e das associações de tipo de conteúdo são intimidadoras para muitos designers de formulários, mas o InfoPath 2007 cuida de todos os detalhes essenciais. O arquivo readme.htm que acompanha o exemplo OrgPersonLib inclui instruções para a publicação do modelo de formulário Direct Reports no SharePoint e cria um tipo de conteúdo que se liga novamente aos mesmos campos de metadados (UserID, FullName, EMail e Direct_x0020_Reports). É possível adicionar facilmente o novo tipo de conteúdo à biblioteca de documentos OrgPersonLib na interface do usuário do SharePoint. Mas o novo tipo de conteúdo também aponta para o modelo de formulário do InfoPath já que o modelo de documento invoca o aplicativo de formulários ao atualizar os documentos XML existentes. A Figure 9 listra como o Assistente de Publicação do InfoPath simplifica o mapeamento de propriedades entre valores de nó XML e colunas de site do SharePoint. E, novamente, se você associar os valores de nó com as colunas de site existentes, é possível reutilizar os componentes do SharePoint existentes.

Figura 9** Mapeamento de propriedades no InfoPath 2007 **(Clique na imagem para aumentar a exibição)

Conclusão

Recursos on-line adicionais

• Blog da equipe do InfoPath 2007
• Especificações e Desenvolvimento do Esquema XML do W3C
• Introdução aos Esquemas XML
• Fluxos de trabalho no Office SharePoint Server 2007
• InfoPath 2007 Forms Services

Com as tecnologias disponíveis no Office, os arquitetos empresariais podem criar soluções de coleta de dados que promovem prontamente a reutilização de código e a troca de informações. O InfoPath 2007 permite aos departamentos a criação de soluções que obtém informações de várias fontes e os dados podem então ser enviados a vários sistemas, como o SharePoint. O SharePoint também fornece aos desenvolvedores um conjunto abrangente de serviços da Web e interfaces para criar componentes de fluxos de trabalho e gerenciamento de informações. Ao hospedar esses componentes em servidores do SharePoint centralizados, os departamentos têm a infra-estrutura necessária para criar seus aplicativos individuais.

Enquanto isso, os departamentos individuais podem criar as suas soluções de coleta de dados de maneira mais rápida. Os regulamentos de conformidade e outros requisitos de negócios globais podem ser tratados em um nível entre departamentos e a facilidade de manutenção e confiabilidade do ambiente de TI aumentam com o uso de menos componentes personalizados ou servidores de aplicativo.

Keith Deshaies é redator técnico freelancer e analista de TI para uma grande empresa de telecomunicações. Ele é especialista em tecnologias do Microsoft Office e SharePoint e membro da STC (Sociedade de comunicação técnica).

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