O papel do SharePoint como sistema de gerenciamento de conteúdo empresarial pode ser antiquado, mas isso não significa que a plataforma esteja imutável. Com o tempo, a Microsoft adiciona novos recursos e descontinua e remove os antigos. A empresa até começou a transformar os recursos do SharePoint em aplicativos separados.
À medida que o SharePoint transita de uma forma de trabalho para outra, essas mudanças geralmente exigem que reescrevamos e retrabalhemos nossos aplicativos e códigos de extensão. O SharePoint está atualmente iniciando uma dessas transições, abandonando suas próprias APIs de pesquisa e adotando um novo modelo baseado no Microsoft Graph.
Felizmente, uma das principais razões para o sucesso do SharePoint é a sua adaptabilidade, apoiada pela sua própria estrutura de extensibilidade e um modelo de programação fácil de aprender.
Por que usar o Microsoft Graph?
Embora não haja uma data de fim de vida para as APIs de pesquisa existentes, as novas funcionalidades só estarão disponíveis através do Microsoft Graph. Portanto, vale a pena começar a reescrever o código agora, especialmente porque o Microsoft Graph é fundamental para fornecer a base para os assistentes Microsoft Copilot AI para Microsoft 365. Essas mudanças se aplicam não apenas ao SharePoint, mas também ao OneDrive.
Como parte dessa mudança, todas as pesquisas passarão por uma única API. Isso significa que o código que você escreve para o SharePoint também funcionará com outros serviços do Microsoft 365, incluindo o Outlook, sempre que houver um índice de pesquisa. Usar uma API de pesquisa comum para todo o conteúdo do Microsoft 365 faz sentido, especialmente com o foco da Microsoft em IA, onde esse conteúdo fornecerá base para IA generativa e grandes modelos de linguagem.
Estabelecer uma API de pesquisa comum para todos os serviços do Microsoft 365 inicia um afastamento há muito esperado da metáfora da pasta antiga. Com bons recursos de pesquisa e marcação de metadados eficaz, não há necessidade real de uma estrutura artificial para ajudar a navegar nos arquivos. Em vez disso, as informações são entregues conforme necessário a partir de um único índice, proporcionando uma ponte transparente entre silos de aplicativos.
Pesquisando com a API do Microsoft Graph
A API Microsoft Graph é uma API REST típica, usando POST com uma carga JSON. Cada carga útil JSON é composta por um conjunto de solicitações, que são executadas em entidades e que contêm consultas. As consultas são strings e podem ser usadas para definir o escopo de suas solicitações. Assim, você pode incluir sites específicos do SharePoint em seu locatário ou excluir seções de seu locatário que você não deseja que sejam pesquisadas.
Existem alguns problemas menores que precisam ser considerados ao construir uma consulta. Por exemplo, como uma loja do OneDrive for Business é na verdade uma entidade do SharePoint, ela deve ser consultada de forma diferente de uma loja OneDrive pessoal.
Depois de construir sua consulta básica JSON, você pode começar a refinar sua operação. Você pode classificar os resultados usando técnicas de paginação familiares, ou exemplo, e pode aplicar filtros adicionais, como uma janela de tempo específica.
Observe que você não está limitado à estrutura hierárquica das consultas gráficas, porque pode usar a linguagem de consulta de palavras-chave (KQL) da Microsoft como parte de suas consultas. As consultas podem então ser agregadas, oferecendo a capacidade de construir consultas complexas que funcionam em diferentes entidades do Microsoft 365. Essa abordagem permite coletar não apenas os documentos relacionados a uma consulta, mas também e-mails e listas de pessoas relevantes.
Você também não está limitado a pesquisar apenas dados do Microsoft Graph. Se você usar um conector do Graph para vincular sistemas de linha de negócios à sua instância do Graph, as pesquisas do Graph poderão extrair todos os tipos de dados corporativos: RH, ERP, CRM e muito mais. Além de uma biblioteca de conectores pré-construídos, a Microsoft fornece ferramentas que você pode usar para criar seus próprios conectores personalizados para aplicativos personalizados ou para trabalhar com dados legados em mainframes ou minicomputadores.
Pense no Microsoft Graph subjacente como um índice dinâmico e constantemente atualizado para seus dados não relacionais. À medida que novo conteúdo é armazenado no Microsoft 365 e em plataformas como o SharePoint Online, esse índice é atualizado automaticamente e disponibiliza seu conteúdo em seu locatário do Microsoft 365 e para todos os seus usuários.
Trabalhando com o KQL no Microsoft Graph
Depois de ter as consultas básicas sob controle, você desejará migrar para formas mais avançadas de trabalhar com o Microsoft Graph. É aqui que você pode aproveitar as vantagens das habilidades existentes usando a linguagem de consulta de palavras-chave (que não deve ser confundida com outra KQL da Microsoft, a linguagem de consulta de dados em grande escala, Kusto).
KQL permite usar texto livre como base para uma consulta, procurando palavras ou frases no conteúdo, com suporte para preenchimentos curinga simples. Além de pesquisar texto, KQL permite usar metadados de documentos para restringir pesquisas a arquivos e autores específicos. Você pode misturar e combinar restrições para criar consultas mais complexas, usando parênteses para agrupar termos de pesquisa onde você pode ter usado uma instrução AND em SQL ou linguagens de consulta semelhantes.
Existem alguns requisitos KQL que podem parecer confusos à primeira vista. Por exemplo, datas e horas precisam ser expressas no formato ISO 8601, então você usa o padrão AAAA-MM-DD para uma data e AAAA-MM-DDThh:mm:ss para data e hora (o T é usado como delimitador entre dados e tempo). Existe até a opção de usar tempos relativos, portanto “hoje” e “este ano” são termos de consulta válidos e fornecerão resultados diferentes quando executados em dias diferentes. Outras opções úteis incluem booleanos, operadores de proximidade e o operador ONEAR, que utiliza a ordem dos termos para retornar resultados.
Se você estiver usando KQL em consultas do Microsoft Graph, é uma boa ideia usar KQL para criar modelos de consulta. Eles fornecem uma consulta KQL pronta, então tudo que você precisa fazer é passar seu termo de pesquisa específico. Isso pode ser especialmente útil se você estiver construindo programaticamente a carga JSON de uma pesquisa, usando uma consulta pré-construída e passando o termo de pesquisa como uma string de consulta.
Uma API para pesquisar todos eles
Acostumámo-nos a tratar o SharePoint como uma ferramenta autónoma, mas agora é uma das tecnologias fundamentais do Microsoft 365 e do Power Platform. Usar o Microsoft Graph para consultar toda a plataforma é uma mudança importante, que visa encapsular toda a saída de trabalho de um usuário ou equipe, em todas as ferramentas que eles usam em seu trabalho diário.
Há ainda outro motivo para usar uma única API de pesquisa: ela pode ajudar a garantir que os dados regulamentados sejam acessados por usuários autorizados. Envolver suas consultas do Microsoft Graph em um esquema de autenticação baseado em função ajuda a garantir que o acesso aos dados seja auditado e que os usuários possam acessar apenas os dados permitidos para sua função ou grupo.
Novamente, não há data de fim de vida para as antigas ferramentas de pesquisa do SharePoint, então você está livre para continuar a usá-las. No entanto, agora que os recursos de desenvolvimento da Microsoft estão focados no Microsoft Graph, você pode usar isso como uma oportunidade para começar a reescrever aplicativos e extensões existentes do SharePoint, bem como experimentar os recursos de aplicativos cruzados do Microsoft Graph.
Afinal, temos muitos dados armazenados no Microsoft Graph, então podemos muito bem usá-los. A pesquisa no SharePoint, Outlook e OneDrive oferece acesso unificado talvez à maior base de conhecimento da sua empresa, permitindo extrair informações e insights que você não teria encontrado de outra forma. Essa seria a melhor razão de todas para fazer a mudança.
