Latest / M365.FM – Podcast de Microsoft 365, Copilot e IA em português / Webhooks do Microsoft Graph explicados: notificações em tempo real em vez de polling constante (Dublagem IA)

Transcript

Webhooks do Microsoft Graph explicados: notificações em tempo real em vez de polling constante (Dublagem IA) · M365.FM – Podcast de Microsoft 365, Copilot e IA em português

0:00
Pronto para 10 dias de Microsoft 365, Copilot, IA, Azure e as pessoas que estão moldando o futuro do trabalho?
0:07
Em janeiro, a M3M5Con está de volta e ainda maior.
0:11
IA em O.
0:12
Junte-se a nós para sessões ao vivo, demonstrações reais e conhecimento prático de MVPs e especialistas do setor em todo o mundo.
0:18
Nada de slides genéricos ou jargões intermináveis.
0:21
Estamos enfrentando os desafios reais.
0:23
Copilot Studio, agente de IA, fábrica, segurança, governança e automação e automação.
0:28
Seja você um profissional de TI, desenvolvedor ou líder de negócios, há sessões feitas para você.
0:35
Com 10 dias inteiros, você pode explorar várias tecnologias e se conectar com uma comunidade global.
0:40
Assista ao vivo e leve insights práticos de volta para sua organização.
0:45
Janeiro de 2027, 10 dias, uma comunidade Microsoft.
0:49
As inscrições já estão abertas.
0:51
Acesse m365.com.net e garanta sua vaga hoje mesmo.
0:55
É m365.com.net
0:58
Inscreva-se agora em m365.com.net e nos vemos ao vivo em janeiro.
1:04
Olá a todos e bem-vindos a mais um episódio de Microsoft Knowledge Nuggets aqui na M365 FM.
1:10
Eu sou seu apresentador, meu amigo.
1:11
O tema de hoje é algo que quase todo mundo que desenvolve com o Microsoft 305 já ouviu falar,
1:15
mas poucos sabem explicar com clareza.
1:17
O que exatamente são o Webhooks do Graph?
1:19
Por que você deveria se importar com eles em vez de continuar fazendo as coisas do jeito antigo?
1:22
Imagine que você está esperando uma carta importante.
1:24
Você vai até sua caixa de correio, ela está vazia.
1:25
Recebam.
1:26
10 minutos depois você verifica de novo.
1:28
Ainda nada.
1:29
Você faz isso o dia todo, perdendo tempo e energia.
1:30
Isso é polling.
1:31
Porém, imagine um mundo diferente.
1:32
O carteiro toca a campainha no momento em que uma carta chega.
1:35
Você não precisa ficar.
1:36
Você espera pelo toque.
1:37
Isso é um Webhook.
1:38
Ao final deste episódio, você entenderá o que são os Webhooks do Graph,
1:41
porque eles substituem a verificação constante e como tudo se encaixa.
1:45
Problema do polling.
1:46
Vamos analisar isso.
1:48
Para entender por que os Webhooks são importantes, você precisa entender por que o polling é prejudicial.
1:51
É assim que a maioria dos aplicativos funcionam hoje.
1:53
O aplicativo precisa de uma resposta.
1:54
Ele pergunta ao Microsoft Graph, tem algum usuário novo?
1:57
O Graph responde.
1:59
Então o seu app espera um pouco e pergunta de novo.
2:00
Tem algum usuário novo agora?
2:01
Ainda não.
2:03
Repetidamente, esse processo é o polling.
2:05
Pense nisso como ligar constantemente para um amigo para saber se ele tem novidades.
2:08
Ele atende, você pergunta.
2:09
Ele diz que não, você desliga.
2:10
Não, você desliga.
2:11
Depois você liga de novo, cinco minutos depois.
2:13
De novo.
2:13
Você está gastando o tempo dele e o seu.
2:15
Provavelmente você está incomodando.
2:16
Agora, imagine milhares de aplicativos fazendo isso com o Microsoft Graph ao mesmo tempo.
2:20
Todo aplicativo fazendo o polling a cada poucos minutos.
2:21
Perguntando as mesmas coisas, recebendo as mesmas coisas e recebendo as mesmas respostas.
2:24
Isso gera muito ruído.
2:25
A Microsoft tem um nome para quando você consulta de forma muito agressiva.
2:28
Limitação, throttling, ou como alguns envoldores chamam, a prisão do Graph.
2:32
Quando você envia solicitações demais, a Microsoft diz ok, chega por enquanto.
2:35
Eles limitam quantas chamadas seu aplicativo pode fazer.
2:37
Assim que você é limitado, tudo fica lento.
2:39
Solicitações legítimas se acumulam.
2:40
Seu aplicativo pode funcionar corretamente.
2:42
Você não faz ideia de quando será liberado.
2:43
De quantas solicitações estamos falando?
2:45
Digamos que seu app consulte a cada 5 minutos por alterações do usuário.
2:48
Isso resulta em 12 solicitações por hora.
2:50
Ao longo de um dia inteiro.
2:51
São 288 solicitações e isso é apenas para um recurso.
2:54
Se você também estiver consultando grupos, arquivos, mensagens e eventos de calendário,
2:57
você acumula milhares de solicitações desnecessárias por dia.
3:00
A maioria delas não retorna nada.
3:01
Zero alterações, mas você ainda fez a chamada.
3:03
E tem mais.
3:04
Mesmo consultando a cada 5 minutos, você ainda não recebe atualizações em tempo real.
3:08
Uma alteração pode ocorrer 1 minuto após a última consulta.
3:11
Você saberá disso 4 minutos depois.
3:12
Você está desperdiçando recursos e ainda perdendo o momento certo.
3:16
Agora, contraste isso com uma abordagem orientada.
3:18
Em vez de chamar o Microsoft Graph a cada poucos minutos,
3:20
você espera que o Microsoft Graph chame você.
3:21
Você configura um evento.
3:23
Quando algo muda, o Graph envia uma notificação para você.
3:25
Dando disco.
3:26
Você atende quando o telefone toca.
3:28
São webhooks.
3:29
Então, o que exatamente é um webhook?
3:31
Aqui está a definição mais simples.
3:32
Um webhook é uma solicitação HTTP enviada automaticamente quando algo acontece.
3:36
Você não pede, o servidor simplesmente envia para você.
3:39
Pense nisso com uma campainha.
3:40
Você não fica do lado de fora conferindo a cada poucos minutos.
3:43
Você instala uma campainha.
3:44
Quando alguém chega, a pessoa toca.
3:46
Você ouve o toque e atende.
3:47
A campainha faz a vigilância por você.
3:49
Webhooks às vezes são chamadas de APIs reversas.
3:52
Com uma API normal, seu app faz uma solicitação e o servidor responde.
3:55
Seu aplicativo está no controle.
3:56
Com um webhook, o servidor envia a solicitação para seu aplicativo.
3:59
O servidor está no controle, mas envia os dados em vez de esperar você pedir.
4:02
O Microsoft Graph também usa webhooks, mas a Microsoft chama de notificações de alteração.
4:06
É a mesma coisa, apenas um nome diferente.
4:09
Quando algo muda no Microsoft 365, o Graph envia um HTTP post para uma URL que você fornece.
4:15
Esse post contém informações sobre o que mudou.
4:17
Muitas coisas sobre as quais você pode ser notificado.
4:20
Um novo usuário é criado no seu tenant.
4:22
Um arquivo é atualizado no SharePoint.
4:23
Uma mensagem enviada no Teams.
4:25
Um evento de calendário é alterado ou um grupo recebe um novo membro.
4:28
Tudo isso pode disparar uma notificação.
4:30
Este é um exemplo real.
4:32
Digamos que você gerencie uma empresa com um sistema de controle de óleo.
4:33
Quando um novo funcionário entra, você deseja criar uma conta automaticamente.
4:37
Sem webhooks, você faz polling no endpoint de usuários a cada poucos minutos, verificando
4:40
se há novas pessoas.
4:41
Com webhooks, você se inscreve para eventos de criação de usuário.
4:44
Quando alguém entra, o Graph envia uma notificação por seu aplicativo.
4:47
Seu aplicativo a recebe, valida e cria a conta, tudo em questão de segundos, sem polling
4:52
e sem solicitações desperdiçadas.
4:54
Outro exemplo.
4:55
Você tem uma biblioteca de documentos de SharePoint e receboção carregada.
4:57
Sem webhooks, você faz polling constante na biblioteca.
5:00
Com webhooks, o Graph avisa você no momento em que um arquivo é adicionado.
5:02
Seu aplicativo captura, verifica se há um recibo e o processa automaticamente.
5:07
Esse é o poder do webhook.
5:08
Em vez de seu aplicativo perguntar constantemente alguma novidade, você deixa o cinema avisá-lo
5:12
quando algo contém.
5:13
É mais eficiente, mais confiável e muito mais rápido.
5:16
Como os webhooks do Microsoft Graph funcionam?
5:18
Agora você sabe o que são webhooks e por que o polling é um problema.
5:21
Vamos ver como os webhooks do Microsoft Graph realmente funcionam, porque o fluxo é mais
5:24
simples do que você imagina.
5:26
Tudo se resume a três coisas.
5:27
Uma inscrição, uma notificação e o seu endpoint.
5:29
Primeiro você cria uma inscrição.
5:32
Ei, quero saber quando essa coisa específica mudar.
5:36
Você fornece ao Graph os detalhes do que monitorar e para onde enviar a novidade.
5:39
Pense nisso como se inscrever para um alerta.
5:41
Você diz ao sistema o que é importante para você e fornece suas informações de conta.
5:44
Segundo, o Microsoft Graph monitora esse recurso e verifica essa alteração.
5:47
Quando algo acontece, como um usuário criado, um arquivo atualizado ou uma mensagem chegando,
5:51
o Graph percebe.
5:52
Terceiro, o Graph em notificação.
5:54
Ele dispara um HTTP post para o URL que você forneceu.
5:57
Esse post contém informações sobre o que foi alterado.
6:00
Seu endpoint o recebe e seu aplicativo processa.
6:02
Portanto, o fluxo de alto nível é simples.
6:04
Se você se inscreve, o Graph monitora.
6:05
O Graph envia um post quando algo muda.
6:08
Vamos detalhar um pouco mais esses três blocos de construção.
6:10
A inscrição é sua solicitação para ser alertado.
6:13
É como dizer, quero saber quando um novo usuário for adicionado ao meu tenant.
6:17
Envie essa solicitação ao Microsoft Graph e o Graph Armazen.
6:19
A partir desse momento, o Graph monitora em seu nome.
6:21
A notificação é o alerta em si.
6:24
Um HTTP post que o Graph envia para o seu endpoint.
6:26
O corpo do post contém detalhes sobre a mudança, como qual recurso mudou,
6:30
que tipo de mudança ocorreu e quando aconteceu.
6:32
Seu endpoint é a porta que você deixa aberta?
6:34
É uma URL em seu servidor, configurado para receber essas solicitações post.
6:37
Ele só precisa ouvir e responder rapidamente.
6:39
Essa.
6:40
Nenhuma lógica complexa é necessária na ponta receptor.
6:42
Apenas capture a notificação, confirme e processe-a.
6:45
Agora, compare isso com o Polen.
6:46
Com o Polen, você envia centenas de solicitações JET,
6:49
cada uma perguntando, tem algo novo?
6:50
Na maioria das vezes, a resposta é não.
6:52
Com o Webhooks, há apenas um post, uma notificação.
6:55
É só isso.
6:56
Uma mensagem em vez de centenas.
6:57
A diferença de eficiência é enorme.
6:59
E seu endpoint não precisa ser complicado.
7:01
Ele só precisa ser acessível publicamente, usar HTTPS e responder rapidamente.
7:05
Falaremos sobre o que rapidamente sem breve.
7:07
Mas a ideia central é simples.
7:09
Seu endpoint escuta, o Graph chama, você responde e pronto.
7:12
Criando uma assinatura.
7:15
Ou como você realmente configura uma dessa?
7:17
Vamos passar pela criação de uma assinatura passo a passo.
7:20
Você começa enviando uma solicitação HTTP post por uma URL específica no Microsoft Graph.
7:24
Essa URL é a HTTPS barra graph.microsoft.com barra v1.0.
7:28
Você está fazendo o post diretamente no endpoint de assinatura.
7:31
Dentro do corpo dessa solicitação, você inclui os detalhes do que deseja assinar.
7:35
Existem quatro campos principais que você precisa fazer.
7:37
O primeiro é a URL de notificação.
7:39
Esta é a URL do seu endpoint, o local para onde o Microsoft Graph enviará as notificações.
7:43
Ela deve ser HTTPS e precisa ser acessível publicamente porque o Graph precisa alcançá-la pela internet.
7:47
O segundo é o recurso.
7:49
Isso diz ao Graph o que se deseja monitorar.
7:51
Você especifica o caminho do recurso no Microsoft Graph.
7:53
Por exemplo, o User, se quiser monitorar alterações de usuários.
7:55
Ou o me barra mailfolders barra messages, se quiser monitorar novos e-mails na sua caixa de entrada.
8:00
O recurso diz ao Graph exatamente o que é importante para você.
8:02
O terceiro é o tipo de alteração.
8:04
Isso diz ao Graph sobre que tipo de alterações você deseja ser notificado.
8:07
Você pode especificar created, updated, deleted ou qualquer combinação.
8:11
Portanto, se você só se importa com novos usuários sendo criados, você define o tipo de alteração como created.
8:14
Se você também se importa com atualizações, você define como created, updated.
8:17
O quarto é a data e hora de expiração.
8:19
É quando a assinatura expira, porque as assinaturas não duram para sempre.
8:23
Você define uma data e o Graph para de enviar notificações após esse ponto.
8:27
A duração máxima depende do recurso que você está monitorando.
8:29
Para usuários e grupos, o máximo é de cerca de três dias.
8:32
Para itens de unidade no SharePoint ou OneDrive, pode ser de até 30 dias.
8:35
Você precisa verificar a documentação para cada tipo de recurso.
8:38
Há também um campo opcional que vale a pena mencionar.
8:40
O Client State.
8:42
Esta é uma string secreta que você crie.
8:43
Pode ser o que você quiser.
8:45
Uma string aleatória é um GUID que você escolher.
8:47
O Microsoft Graph inclui esse valor em cada notificação enviada ao seu Endpoint.
8:51
E você usa para verificar se a notificação realmente veio da sua assinatura.
8:54
Se alguém tentar enviar notificações falsas para o seu Endpoint, o Client State não
8:58
corresponderá e você poderá rejeitá-lo imediatamente.
9:01
É uma medida de segurança simples, mas importante.
9:03
Criar uma assinatura é como assinar a entrega de um jornal.
9:07
Você fornece ao jornal o seu endereço.
9:08
Essa é a sua URL de notificação.
9:10
Você diz quais sessões deseja, esse é o seu recurso e tipo de alteração, e informa
9:14
por quanto tempo deseja que a entrega continue.
9:16
Essa é a sua data e hora de expiração.
9:18
O jornal cuida do resto.
9:19
Mas aqui está o detalhe, as assinaturas expiram.
9:21
Você não pode criar uma e esquecê-la.
9:23
Após a data e hora de expiração, o Graph para de enviar notificações e sua assinatura
9:27
desaparece.
9:29
Se quiser continuar recebendo notificações, você precisa renovar a assinatura, antes
9:32
que ela expire enviando uma solicitação PTCH para o Endpoint da assinatura com uma
9:35
nova data e hora de expiração.
9:37
Portanto, criar uma assinatura é o primeiro passo, mas não é o último.
9:39
Você precisa gerenciar o ciclo de vida.
9:41
Falaremos mais sobre isso mais tarde.
9:43
O Renshig vai da ação.
9:44
Antes que sua assinatura entre em vigor, há uma etapa que você não pode pular.
9:47
O Microsoft Graph não aceita apenas sua solicitação de assinatura e começa a enviar
9:50
notificações.
9:51
Ele primeiro precisa confirmar se seu Endpoint é real e está pronto para recebê-las.
9:55
Veja como funciona.
9:56
Quando você envia sua solicitação post para criar uma assinatura, o Microsoft Graph dispara
9:59
imediatamente um post de teste para sua URL de notificação.
10:03
Esse post de teste inclui um parâmetro de consulta chamado Validation Token.
10:06
É apenas uma string eletro.
10:07
Seu Endpoint precisa capturar esse token e enviá-lo de volta com uma resposta de texto
10:10
simples e você deve fazer isso em até 10 segundos.
10:13
Pense nisso com um entregador entregando um pacote.
10:15
Eles aparecem na sua porta e perguntam, este é o endereço certo?
10:18
Pode confirmar.
10:18
Você precisa assinar o recebimento.
10:20
Se não o fizer, eles vão embora.
10:21
O entregador não deixa o pacote.
10:23
Eles simplesmente vão embora.
10:24
É exatamente isso que está acontecendo aqui.
10:25
O Microsoft Graph está dizendo, estou prestes a enviar notificações importantes.
10:29
Prova que você é a pessoa certa no endereço certo.
10:33
Seu Endpoint responde ecoando o token de validação, o que diz ao Graph.
10:36
Sim, estou aqui.
10:37
Estou aqui.
10:38
Ouvindo.
10:39
Envie minhas notificações.
10:40
Agora é aqui que muitos desenvolvedores tropeçam.
10:43
Token de validação deve ser retornado como texto simples, não JSON, não HTML e texto
10:47
simples.
10:48
E a resposta deve ter um cabeçalho de tipo de conteúdo definido como text-parerplan.
10:51
Se você enviá-lo envolvido em JSON ou codificado, de qualquer forma, a validação falha.
10:55
Sua assinatura não será criada.
10:57
O Microsoft Graph retorna um erro e você fica se perguntando o que deu errado.
11:00
Há outro detalhe técnico que vale a pena conhecer.
11:02
O serviço de validação do Microsoft Graph não suporta TLS 1.3 de forma confiada.
11:05
Ele negocia o TLS 1.2.
11:08
Portanto, se seu Endpoint aceita apenas conexões TLS 1.3, o handshake de validação falha
11:12
antes mesmo de o código da sua aplicação ser executado.
11:14
Você precisa garantir que seu Endpoint suporte TLS 1.2, pelo menos para a etapa de validação.
11:19
Depois disso, você pode impor qualquer versão de TLS que desejar para as notificações
11:22
propriamente ditas.
11:23
A boa notícia é que esse handshake de validação ocorre apenas uma vez por santo.
11:27
Não é algo que seu Endpoint precise lidar toda vez que uma notificação chega apenas
11:30
na primeira vez.
11:31
Uma vez que o Graph confirma que seu Endpoint é real, ele passa a confiar nele durante toda
11:34
a vida daquela assinatura.
11:36
Portanto, você só precisa fazer isso corretamente.
11:38
Dando com notificações de segurança.
11:40
Assim que o handshake de validação é concluído e sua assinatura entra em vigor, o Microsoft
11:44
Graph começa a enviar essas notificações.
11:46
Então, como elas realmente se parecem na prática?
11:49
Quando algo muda, o Graph envia um HTTP POST para seu Endpoint com um objeto JSON no corpo.
11:54
Esse objeto contém um recurso que foi alterado, o tipo de alteração criado, atualizado ou
11:58
excluído e um carimbo de data, barra hora.
12:00
Ele também inclui o valor de estado do cliente que você definiu ou criou a assinatura.
12:03
Essa é sua string secreta, sua maneira de saber que a mensagem é real.
12:07
Então, aqui está a primeira coisa a fazer quando uma notificação chega.
12:10
Valide o estado do cliente.
12:11
Compare o valor na notificação com o segredo que você armazenou ao criar a assinatura.
12:14
Se eles não corresponderem, descarte imediatamente, pois pode ser falsa.
12:18
Alguém tentando enganar seu sistema para processar dados ruins.
12:21
Isso é importante porque seu Endpoint reside na internet pública.
12:24
Qualquer pessoa que saiba a sua URL pode enviar um POST para ele.
12:27
Sem a validação do estado do cliente, você não teria como distinguir entre uma notificação
12:30
real do Microsoft Graph e uma falsa.
12:33
Uma notificação simples, mas é sua primeira linha de defesa.
12:35
Depois de confirmar que a notificação é legítima, você precisa responder rapidamente.
12:39
O Microsoft Graph espera uma resposta HTTP de nível 200 dentro de 3 segundos.
12:43
Se você demora, o Graph percebe.
12:45
E se acontecer com frequência, o Graph começa a tratar você de forma diferente.
12:48
Veja como funciona a limitação.
12:49
Se mais de 10% das suas respostas excederem a janela de 3 segundos em qualquer período
12:53
de 10 minutos, o Microsoft Graph marca seu Endpoint como lento.
12:57
Quando isso acontece, as novas notificações são atrasadas em 10 minutos.
13:00
Elas ainda chegam eventualmente, mas você perde e entrega em tempo real.
13:03
E se a situação piorar, com mais de 15% das suas respostas excedendo 10 segundos,
13:07
o Graph marca seu Endpoint como descartado.
13:09
Nesse estado, as notificações são descartadas totalmente por 10 minutos.
13:12
Aqui está a parte assustadora.
13:14
Notificações descartadas não podem se recuperar.
13:15
Elas se foram e você nunca as terá de volta.
13:17
Pense nisso com uma linha telefônica.
13:19
Se você não atender rápido, que ligotei novamente mais tarde.
13:21
Mas se você nunca atender, eventualmente a pessoa desiste.
13:25
O Microsoft Graph é quem liga e seu Endpoint é o telefone.
13:28
Atenda rápido ou corra o risco de perder a mensagem.
13:30
Então qual é a melhor prática aqui?
13:31
Reconheça imediatamente e procese forma a símbolo.
13:34
Seu Endpoint deve validar o estado do cliente,
13:36
aceitar a notificação e retornar uma resposta 200 ou 222 o mais rápido possível.
13:41
Então envia a notificação para uma fila para processamento em segundo plano.
13:44
Embarramento de serviço, embarramento de serviço ou até mesmo uma tabela simples de banco.
13:47
O objetivo é sair do ciclo de resposta rapidamente
13:49
e deixar que seus processos em segundo plano lidem com o trabalho pesado.
13:52
E mais um lembre de segurança.
13:53
Seu Endpoint deve ser HTTPS.
13:55
Sem exceções, o Microsoft Graph não enviará notificações para um Endpoint HTTP.
14:00
Seu Endpoint deve ser acessível no caminho.
14:01
Se estiver atrás de um firewall ou VPN, o Graph não conseguirá algo.
14:04
Para desenvolvimento, você pode usar ferramentas como o Ingrok
14:07
para criar um túnel público para sua máquina local.
14:09
Mas em produção, seu Endpoint precisa estar em um local onde o Graph possa encontrá-lo.
14:13
Mantendo o ciclo de vida das notificações vivo.
14:16
Então você configurou sua inscrição, as notificações estão fluindo e tudo parece estar bem.
14:20
Mas aqui está algo que pega muita gente surpresa.
14:22
Sua inscrição tem uma data de validade.
14:24
Ela não dura para sempre.
14:25
Dependendo do recurso que você está monitorando,
14:27
a duração máxima da inscrição geralmente é entre 3 e 7 dias.
14:30
Para alguns recursos como itens de unidade no SharePoint, você pode obter até 30 dias.
14:33
Mas o ponto é que não é permanente.
14:35
Você não pode criar uma inscrição e esquecer dela.
14:38
Pense nisso com uma assinatura de revista.
14:40
Você se inscreve, começa a receber as edições e tudo parece ótimo.
14:43
Mas se você não renovar antes da assinatura e expirar, as edições param de chegar.
14:46
Uma coisa assim.
14:47
Se sua assinatura e expirar, o Microsoft Graph para de enviar notificações.
14:50
E você pode não perceber até se perguntar por que nada está acontecendo.
14:53
Tanto você precisa de uma estratégia de ambas.
14:54
A forma de renovar é sim.
14:56
Envie uma solicitação para T.H. ao Endpoint da assinatura usando o ID da assinatura.
15:00
E atualize a data e hora de expiração para uma data futura.
15:02
Isso estende a vida útil da assinatura.
15:04
Você pode fazer isso quantas vezes quiser, desde que o faça antes que a expiração atual ocorra.
15:09
Bem, o Microsoft Graph ajuda você com algo chamado notificações de ciclo de vida.
15:13
Ao criar uma assinatura, você pode fornecer uma URL separada chamada URL de notificação de ciclo de vida.
15:18
O Microsoft Graph envia alertas para essa URL quando certas coisas acontecem.
15:22
Como quando sua assinatura está prestes a expirar, quando seu token de acesso vai vencer ou quando as permissões do seu app mudam.
15:28
Essas notificações de ciclo de vida servem um aviso prévio.
15:30
Você não precisa adivinhar quando sua assinatura vai expirar.
15:32
O Graph avisa.
15:33
Ei, sua assinatura expira em algumas horas.
15:35
Talvez você queira renovar.
15:37
É como receber um lembrete da editora da sua revista de que sua assinatura está terminando.
15:41
Muito útil se você tiver prestes a atenção.
15:43
O que acontece é algo de errado mesmo assim?
15:45
Talvez seu Endpoint saia do ar por um tempo ou notificações sejam perdidas porque você foi lento.
15:49
É aí que entra o Delta Query, um recurso separado do Microsoft Graph que permite perguntar o que mudou desde a última vez que verifiquei.
15:56
E ele retorna apenas as alterações e nada mais.
15:59
Veja como sumiu.
16:00
Na primeira vez que você executa um Delta Query, um recurso ligando os usuários, o Graph retorna todos os usuários no seu local.
16:05
Mas ele também retorna algo extra, um link especial chamado LinkDelta.
16:08
Você salva esse link.
16:09
Na próxima vez que executar a mesma consulta, você usa esse LinkDelta.
16:12
E em vez de obter todos os usuários novamente, você obtém apenas os que mudaram desde sua última solicitação.
16:16
Novos usuários atualizados, usuários excluídos.
16:19
É isso.
16:19
Pense nisso como ler uma lista de novidades em vez de ler enciclopédia inteira toda vez.
16:24
Muito mais rápido, muito menos dado.
16:26
Agora aqui está o padrão inteligente.
16:27
Combine o Webhooks com o Delta Query.
16:29
Use o Webhooks para saber quando algo mudou.
16:31
Depois use o Delta Query para descobrir exatamente o que mudou.
16:34
Deixa eu explicar por tanto.
16:35
Webhooks são rápidos, mas não são perfeitos.
16:37
Notificações podem ser perdidas, assinaturas podem expirar e seu Endpoint pode sair do ar.
16:41
Mas o Delta Query é confiado.
16:42
Você pode executá-lo a qualquer momento e ele fornece uma lista completa de alterações desde a sua última verificação.
16:46
Assim, mesmo que perca uma notificação, você pode se atualizar.
16:49
Aqui está o fluxo típico.
16:51
Configure uma assinatura de Webhook para alterações de usuário.
16:53
Execute uma consulta Delta inicial para obter o estado base e salve o link Delta.
16:57
Quando um Webhook chegar informando que um usuário foi alterado,
16:59
execute uma consulta Delta usando seu link Delta salve.
17:02
Isso lhe dará a alteração exata.
17:03
Processe e, em seguida, salve o novo link Delta dessa resposta.
17:06
A próxima vez que um Webhook chegar, repita o processo.
17:08
E se você perdeu uma notificação ou se sua assinatura expirar, basta executar a consulta Delta novamente.
17:14
Perceberá tudo o que perdeu em uma rede segura.
17:16
Webhooks oferecem velocidade e a consulta Delta oferece confiabilidade.
17:19
Juntos, eles são uma combinação poderosa.
17:22
Exemplo do mundo real e próximo espaço.
17:24
Imagine que um novo funcionário entre na sua empresa amanhã.
17:26
Alguém no RH cria a conta dele no Microsoft Entre-ID e a sua única ação.
17:30
Inicia uma reação.
17:31
Em cadeia.
17:32
Se você configurou uma assinatura de Webhook para alterações de usuário,
17:35
o Microsoft Graph percebe instantaneamente e envia um post para o seu endpoint.
17:39
Mas o que acontece é seguir.
17:40
Seu endpoint recebe a notificação,
17:42
valida o estado do cliente e, se corresponder ao seu segredo, você sabe que é legítimo.
17:46
Você retorna uma resposta 202 Accepted dentro de 3 segundos,
17:49
confirmando a notificação e, então, seu worker em segundo plano do processo.
17:53
O worker vê que um usuário foi criado, mas a notificação não inclui todos os detalhes,
17:56
então ele executa uma consulta Delta usando seu link salvo.
17:59
Isso retorna as informações completas do novo usuário.
18:01
Um nome e-mail, departamento, cargo, gerente, tudo o que você precisa.
18:05
Agora, seu worker usa essas informações para criar uma conta para o novo funcionário
18:08
no seu sistema de controle de pontos de terceiros.
18:10
Ele envia o e-mail de boas-vindas.
18:12
Ele os adiciona às listas de distribuição apropriadas.
18:14
Tudo isso acontece segundos após o RH criar a conta no EntraID.
18:18
Sem polling.
18:19
Etapas manuais.
18:20
E sem atraso.
18:21
Pense no alternativo.
18:23
Sem o Webhooks, você teria que consultar o endpoint de usuário a cada poucos minutos,
18:26
centenas de requisições por dia,
18:27
e mesmo assim poderia levar vários minutos para detectar um novo usuário.
18:30
O Webhooks é instantâneo.
18:32
Uma notificação, uma consulta Delta, pronto.
18:34
Esse é o valor real.
18:34
Seu sistema se torna mais rápido, eficiente e menos propenso a atingir limites de limitação.
18:39
Em vez de perguntar constantemente ao Graph por atualizações,
18:41
você deixa que o Graph lhe avise quando algo acontecer.
18:43
É uma mudança fundamental na forma como você cria integrações.
18:45
Então aqui está o que eu quero que você tenha.
18:47
Pense em um processo para o qual você está fazendo o endpoint.
18:49
Talvez você esteja verificando novos e-mails em uma caixa compartilhada.
18:52
Talvez você esteja monitorando alterações de arquivos em uma biblioteca do SharePoint.
18:55
Talvez você esteja acompanhando atualizações de usuários no seu sistema de arreglo.
18:57
Será que um Webhook poderia ser verificação superior?
18:59
Na maioria dos casos, a resposta é sim.
19:00
E você não precisa construir tudo.