Guia de uso de webhooks
Os webhooks são uma maneira de os aplicativos da Web se comunicarem entre si automaticamente e em tempo real.
Diferentemente das APIs tradicionais, que aguardam um usuário solicitar informações, as APIs em tempo real compartilham dados no momento em que ocorrem. Os webhooks atuam como uma API em tempo real e ajudam a compartilhar os dados imediatamente sempre que o evento especificado ocorre.
Entidades
Para entender os eventos de webhooks, primeiro precisamos estar cientes das entidades envolvidas e das condições de acionamento desses eventos.
Objetos de aprendizado
Estes são os eventos compatíveis com objetos de aprendizado (curso, caminho de aprendizado ou certificações).
Rascunho
Sempre que um objeto de aprendizado é criado a partir da interface do usuário, ele começa no modo Rascunho. Isso significa que o objeto de aprendizado ainda não foi publicado e não está disponível para os alunos. O evento LEARNING_OBJECT_DRAFT é acionado desde que o objeto de aprendizado permaneça um rascunho. Todas as atualizações sucessivas ao rascunho também acionarão esse evento.
Atualização
Depois que o objeto de aprendizado é publicado, seu estado muda de Rascunho para Publicado. Durante esta transição, o Webhook gera o evento LEARNING_OBJECT_MODIFICATION porque o objeto de aprendizado está sendo modificado de Rascunho para Publicado. Todas as modificações e atualizações subsequentes no OA também acionarão um evento LEARNING_OBJECT_MODIFICATION.
O evento LEARNING_OBJECT_MODIFICATION também é acionado quando o objeto de aprendizado é desativado. Essa operação desativada marca as instâncias subjacentes como atualizadas, pois essas instâncias são desativadas quando o objeto de aprendizado pai está no estado desativado.
Excluir
Após a exclusão de um objeto de aprendizado, o evento LEARNING_OBJECT_DELETION é gerado. Esse evento indica que o objeto de aprendizado foi excluído e não está mais disponível para acesso dos alunos.
Além dos eventos em tempo real, os eventos do objeto de aprendizado também têm um equivalente em lote (não em tempo real), que é acionado como parte do evento LEARNING_OBJECT_MODIFICATION_BATCH. Esse evento ocorre durante a criação ou a modificação de um objeto de aprendizado por meio do fluxo de trabalho de migração. Como as operações de rascunho e exclusão do objeto de aprendizado não são suportadas por meio da migração, não há eventos de rascunho ou exclusão correspondentes para essas ações.
Instâncias do objeto de aprendizado
Veja a seguir os eventos compatíveis com instâncias de objetos de aprendizado.
Atualização
Depois que uma instância é criada, o evento LEARNING_OBJECT_INSTANCE_MODIFICATION é gerado. As instâncias do objeto de aprendizado no Adobe Learning Manager não têm um estado Rascunho; portanto, o Adobe Learning Manager não oferece suporte a um evento LEARNING_OBJECT_INSTANCE_DRAFT. Este evento é gerado sempre que uma instância é criada, modificada ou desativada.
Além de ser gerado quando uma instância é criada, atualizada ou desativada, este evento também é gerado automaticamente quando seu objeto de aprendizado pai está marcado como Desativado. Isso ocorre porque, quando um objeto de aprendizado é desativado, as instâncias subjacentes também precisam ser marcadas como Desativadas.
Excluir
Quando uma instância é excluída, o evento LEARNING_OBJECT_INSTANCE_DELETION é gerado. Esse evento se aplica somente a instâncias do curso que contêm módulos de ritmo individualizado, pois o Adobe Learning Manager permite que apenas administradores excluam instâncias do curso em que o tipo de módulo é de ritmo individualizado. O Adobe Learning Manager não oferece suporte a exclusões explícitas para outros tipos de módulos de curso, não para instâncias de caminho de aprendizado ou instâncias de certificação.
A instância do objeto de aprendizado também tem um equivalente que não é em tempo real, exposto como parte do evento LEARNING_OBJECT_INSTANCE_MODIFICATION_BATCH. Esse evento é acionado durante a criação ou modificação de uma instância do objeto de aprendizado por meio do fluxo de trabalho de migração. Como as operações de rascunho ou exclusão para instâncias de objetos de aprendizado não são suportadas na migração, os eventos de rascunho ou exclusão correspondentes não estão disponíveis.
Inscrição
Depois que um aluno executa uma ação de inscrição, um evento de inscrição em tempo real é acionado. Dependendo do tipo de objeto de aprendizado, o evento de inscrição em tempo real pode se enquadrar em uma das seguintes categorias:
- COURSE_ENROLLMENT
- LEARNING_PATH_ENROLLMENT
- CERTIFICATION_ENROLLMENT
Os eventos de inscrição têm contrapartes em lote além desses eventos em tempo real. Sempre que uma inscrição é acionada por um administrador, gerente ou plataforma, eventos de inscrição em tempo não real são acionados. Com base no tipo de objeto de aprendizado, o evento de inscrição em lote pode ser um dos seguintes:
- COURSE_ENROLLMENT_BATCH
- LEARNING_PATH_ENROLLMENT_BATCH
- CERTIFICATION_ENROLLMENT_BATCH
Cancelamento da inscrição
Quando um aluno executa uma ação de cancelamento de inscrição, um evento de cancelamento de inscrição em tempo real é acionado. Dependendo do tipo de objeto de aprendizado, o evento de cancelamento de inscrição em tempo real pode se enquadrar em uma das seguintes categorias:
- COURSE_UNENROLLMENT
- LEARNING_PATH_UNENROLLMENT
- CERTIFICATION_UNENROLLMENT
Além desses eventos, também há eventos de cancelamento de inscrição em lote. Sempre que um cancelamento de inscrição é marcado por um administrador, gerente ou plataforma, eventos de cancelamento de inscrição em tempo não real são acionados. Com base no tipo de objeto de aprendizado, o evento de cancelamento de inscrição em lote pode ser um dos seguintes:
- COURSE_UNENROLLMENT_BATCH
- LEARNING_PATH_UNENROLLMENT_BATCH
- CERTIFICATION_UNENROLLMENT_BATCH
Conclusão
O evento de conclusão em tempo real é acionado sempre que um aluno conclui um objeto de aprendizado. Com base no tipo de objeto de aprendizado, o evento de conclusão em tempo real pode se enquadrar em uma das seguintes categorias:
- COURSE_COMPLETED
- LEARNING_PATH_COMPLETED
- CERTIFICATION_COMPLETED
Além desses eventos em tempo real, também há eventos de conclusão de lote. Por exemplo, quando um administrador, gerente ou plataforma marca um objeto de aprendizado como concluído, os eventos de conclusão em tempo não real são acionados. Com base no tipo de objeto de aprendizado, o evento de conclusão de lote pode se enquadrar em uma das seguintes categorias:
- COURSE_COMPLETED_BATCH
- LEARNING_PATH_COMPLETED_BATCH
- CERTIFICATION_COMPLETED_BATCH
Progresso do aluno
Sempre que um aluno se inscreve em um objeto de aprendizado e inicia o módulo, seu progresso é monitorado. Estes dados estão incluídos no evento LEARNER_PROGRESS. O evento pode ser atrasado em até 15 minutos, já que o rastreamento do progresso depende de uma complexa lógica de agregação, que não é em tempo real.
Estatísticas de CI
O evento em tempo real CI_STATS é disparado sempre que há uma alteração na disponibilidade de vaga ou lista de espera para uma instância do curso. Esses dados são capturados somente no nível da instância. Além disso, esse evento é acionado para cursos e não para outros caminhos de aprendizado ou certificações, pois a disponibilidade de vaga e lista de espera são atributos específicos de um curso e sua instância.
Ordenação de eventos
O Adobe Learning Manager garante que os eventos sejam solicitados para cada conta. No entanto, pode haver discrepâncias ao correlacionar mensagens entre eventos de inscrição ou conclusão e andamento. Isso acontece porque o evento de progresso do aluno pode ser atrasado em até 15 minutos, pois o rastreamento do progresso depende de uma lógica de agregação complexa, que não é em tempo real. Além disso, os eventos de andamento vêm de diferentes fontes de dados, portanto, sua ordem não pode ser garantida em relação aos eventos de inscrição e conclusão. Portanto, a Adobe Learning Manager fornece práticas recomendadas para clientes ao ouvir esses eventos.
Se o evento de conclusão ocorrer antes do evento de progresso do aluno, o cliente poderá ignorar o evento de progresso do aluno. Isso ocorre porque o evento de progresso do aluno pode ser atrasado em até 15 minutos, enquanto o evento de conclusão pode ser acionado antes do evento de progresso ser recebido. Como o recebimento de um evento de conclusão indica que o objeto de aprendizado foi concluído, isso significa que o progresso atingiu 100%.
No caso raro em que o evento de inscrição ocorre após o evento de progresso do aluno, o cliente pode ignorar o evento de inscrição. Isso ocorre porque o progresso só pode ser acompanhado depois que o aluno se inscreve no objeto de aprendizado. Em outras palavras, receber um evento de progresso indica que o objeto de aprendizado foi iniciado, o que só acontece após uma inscrição bem-sucedida.
Eventos em tempo real vs. eventos em lote
Certos eventos têm equivalentes em tempo real e não em tempo real, conforme mencionado acima. Pode haver perguntas sobre quando inscrever-se em eventos em tempo real e quando inscrever-se em eventos que não são em tempo real. Veja a seguir as diretrizes que podem ser seguidas com base nas entidades descritas acima.
Eventos em tempo real
Acionado durante a criação ou modificação de uma instância do objeto de aprendizado.
Observação: é recomendável usar as instâncias do curso somente depois que o curso for publicado.
Eventos que não são de tempo real
Objetos de aprendizado e suas instâncias
- Assine eventos em tempo real sempre que quiser ouvir alterações em objetos de aprendizado feitas por meio de ações de interface do usuário por funções como administrador, autor etc.
- Inscreva-se em eventos em lote ou em tempo não real sempre que quiser ouvir as alterações feitas em objetos de aprendizado por meio de fluxos de trabalho de migração.
Inscrição, cancelamento de inscrição e conclusão
- Inscreva-se em eventos em tempo real sempre que desejar ouvir inscrições, cancelar inscrições ou conclusões executadas pelos alunos.
- Inscreva-se em eventos em lote ou que não sejam em tempo real sempre que desejar ouvir inscrições, cancelar inscrições ou conclusões marcadas por Administrador, Gerente, Plataforma etc.
Progresso do aluno
- Inscreva-se no evento sempre que quiser ouvir as alterações de progresso de um aluno.
Estatísticas da instância do curso
- Assine o evento CI_STATS em tempo real sempre que desejar ouvir alterações na disponibilidade de estação ou lista de espera.
Carga de evento do Webhook
Como parte da carga de resposta dos webhooks, o Adobe Learning Manager emitirá os atributos necessários para identificar exclusivamente uma entidade. Eles serão emitidos no mesmo formato e de acordo com os padrões usados pela API pública, garantindo que os dados do webhook estejam sincronizados com os dados da API pública. Exiba cargas de exemplo para ver cargas para os vários eventos.
Usar webhooks para criar um banco de dados externo ou serviço de notificação
Um dos casos de uso que ouvimos sobre a utilidade dos webhooks é a criação de um banco de dados do lado do cliente. O Adobe Learning Manager tem seu próprio banco de dados e esquema, mas os clientes não têm acesso a eles.
A pergunta é: como os clientes podem criar um banco de dados usando eventos de webhooks?
Como o Adobe Learning Manager não exibirá diretamente os registros de tabela e o esquema, os clientes podem confiar na solução Webhooks para criar um banco de dados externo utilizando os eventos para preenchê-lo. Nesta versão, estamos fornecendo eventos para objetos de aprendizado, instâncias de objeto de aprendizado, inscrição, cancelamento de inscrição, conclusão, progresso e estatísticas de instância do curso.
Criar um banco de dados a partir de eventos do objeto de aprendizado
Os eventos do objeto de aprendizado expõem loId e loType para identificar uma entidade. No entanto, esses atributos por si só não são suficientes para criar um banco de dados de objetos de aprendizado externo. Os clientes precisarão de campos adicionais para descrever melhor o objeto de aprendizado.
Há duas abordagens para obter os dados adicionais:
Gerar um relatório de dados de treinamento para buscar todos os dados
Essa abordagem deve ser usada quando os objetos de aprendizado são criados em massa por meio de fluxos de trabalho como a migração. A meta aqui é gerar o relatório de Dados de Treinamento com todos os objetos de aprendizado assimilados como parte do fluxo de trabalho de migração. Para otimizar o processo de importação, é recomendável definir a hora de início da exportação para a hora em que a migração foi acionada. Isso garantirá que apenas os objetos de aprendizado trazidos por meio da migração sejam exportados no relatório, pois os dados históricos já estarão disponíveis no banco de dados do cliente.
Consulte as informações da API pública GET /learningObjects - Admin scope
Essa abordagem deve ser usada quando os objetos de aprendizado são criados por meio de fluxos de trabalho em tempo real. O cliente deve ter sua própria camada de cache para colocar em lote os objetos de aprendizado emitidos por meio dos eventos e, em seguida, consultar a API GET /learningObjects passando essas IDs de objetos de aprendizado. O motivo para ter uma camada de cache é garantir que os limites de taxa da API pública não sejam excedidos. Atualmente, temos limites de taxa de administração definidos para 500 solicitações por hora para GET /learningObject APIs. Se esse limite for excedido, o serviço público da API responderá com uma mensagem HTTP 429 Muitas Solicitações.
Criação de banco de dados a partir da instância do objeto de aprendizado e eventos CI_STATS
O evento Instância do objeto de aprendizado emite os atributos loInstanceId, loId e loType para cursos e caminhos de aprendizado. Da mesma forma, o evento CI_STATS só é aplicável aos cursos, pois seatLimit, seatAvailability, waitListLimit, waitlistAvailability etc., só são aplicáveis aos cursos.
Em certos casos de uso, são necessários dados de instância adicionais, como nome de instância, estado etc. Para buscar dados de instância adicionais, deve-se seguir a seguinte abordagem:
Consulte as informações de public-api GET /learningobjects - Admin scope
Os clientes podem consumir a API GET /learningObjects conforme mencionado acima, juntamente com instâncias incluídas para buscar as informações sobre instâncias. Eles ainda devem seguir a abordagem mencionada na seção para garantir que os limites de taxa não sejam violados.
- As certificações não têm o conceito de instâncias no ALM.
- Não há necessidade de buscar dados adicionais para CI_STATS, pois as mesmas informações já teriam sido buscadas como parte dos eventos de Instância do objeto de aprendizado.
Criar banco de dados a partir de eventos de inscrição, cancelamento de inscrição, conclusão e progresso
A inscrição do aluno, o cancelamento de inscrição, a conclusão e o progresso são emitidos como eventos separados no Adobe Learning Manager. O aluno é identificado pelo atributo userId. No entanto, pode haver alguns cenários em que informações adicionais do aluno, como nome, e-mail etc., são necessárias para workflows downstream no lado do cliente. Para buscar esses dados, os clientes podem seguir a abordagem descrita abaixo:
Exportar o relatório de usuário do administrador ou conectores
Essa abordagem deve ser seguida sempre que houver fluxos de trabalho em massa envolvidos, como inscrição em massa, cancelamento de inscrição em massa etc. O Relatório de usuário do Adobe Learning Manager contém todas as informações relacionadas a um usuário. Ao correlacionar a userId obtida do evento do webhook, os clientes podem pesquisar este relatório (que pode ser exposto no lado do cliente como um banco de dados, cache ou ponto de extremidade de API) para buscar detalhes adicionais, como Nome, Email, UUID etc. Essa abordagem pode ser usada para sincronizar usuários semanalmente ou diariamente.
Consultar informações da API pública GET /users - Escopo do administrador
Essa abordagem pode ser seguida quando os usuários não estão disponíveis no relatório acima. A combinação das abordagens 1 e 2 garante que todos os usuários existentes que foram criados no passado possam ser cobertos pelo Relatório de usuários, enquanto os usuários recém-criados ainda podem ser buscados na API. Se o Relatório do Usuário não tiver os dados, o cliente poderá enviar as userIds como argumentos de entrada para a API GET /users para buscar informações do usuário. Essas informações devem ser armazenadas em cache no lado do cliente para evitar invocações repetidas da API pública para o mesmo conjunto de usuários. Observe que atualmente temos limites de taxa de administração definidos para 500 solicitações por hora para APIs GET /users. Qualquer solicitação além desse limite resultará em uma resposta HTTP 429 Muitas Solicitações.
Tolerância a falhas
O sistema de webhook ALM tolerante a falhas fornece recomendações para que os assinantes tratem de possíveis problemas, como perda de evento, eventos duplicados e entrega fora de ordem.
O ALM tem o tempo limite de conexão configurado para 10 segundos e o tempo limite do soquete configurado para 5 segundos. A expectativa é que o cliente confirme a mensagem assim que recebê-la. Isso garante que o cliente não fique atrasado ao processar mensagens. Caso haja algum processamento downstream que consuma muito tempo, o cliente ainda deve confirmar o evento instantaneamente e, em seguida, lidar com o processamento downstream no final.
Retenção de dados
Os eventos são mantidos por 7 dias. Se não forem processados dentro desse prazo, serão perdidos permanentemente. Se a recuperação ocorrer no último dia e mais tempo for necessário, o sistema não estenderá o período de retenção.
Se os eventos forem produzidos mais rapidamente do que são consumidos, alguns eventos podem ser perdidos. Embora isso seja incomum, os assinantes devem monitorar para evitar que se torne um problema de longo prazo.
Desativação de webhooks
Quando um assinante não responde a eventos de webhook, o sistema ALM tenta executar novamente os webhooks usando o backoff exponencial para evitar sobrecarregar o assinante.
O processo de repetição começa com um intervalo inicial de 5 segundos. Se o assinante não responder, o tempo de espera dobrará para 10, 20, 40 e 80 segundos, eventualmente aumentando para um máximo de 5 minutos. Quando atingir 5 minutos, o sistema continuará tentando a cada 5 minutos até que o período de retenção de 7 dias termine. Se o assinante ainda não responder durante esse período inteiro, o webhook será desativado automaticamente. Um e-mail de lembrete será enviado ao assinante em intervalos regulares.
Duplicar eventos
Se um assinante demorar mais de 5 segundos para responder após o processamento de um evento, o sistema poderá tentar processar o mesmo evento novamente. É recomendável usar IDs de eventos para controlar quais eventos já foram processados. Além disso, se o webhook falhar após enviar o evento, mas antes de salvar que ele tenha sido processado, o mesmo grupo de eventos poderá ser repetido. É recomendável usar IDs de lote ou IDs de evento individuais para reconhecer e ignorar duplicatas.
Recomendação para tolerância a falhas
Para evitar essas falhas, os assinantes devem monitorar ativamente os eventos do webhook e configurar alertas para problemas como eventos perdidos, entregas duplicadas ou sequências fora de ordem.
Diretrizes específicas para eventos de webhook
-
Se você receber um evento LEARNER_PROGRESS primeiro, ignore os eventos listados abaixo:
- COURSE_ENROLLMENT
- COURSE_ENROLLMENT_BATCH
- LEARNING_PATH_ENROLLMENT
- LEARNING_PATH_ENROLLMENT_BATCH
- CERTIFICATION_ENROLLMENT
- CERTIFICATION_ENROLLMENT_BATCH
-
Ignore o evento LEARNER_PROGRESS se ele vier após os seguintes eventos:
- COURSE_COMPLETED
- COURSE_COMPLETED_BATCH
- LEARNING_PATH_COMPLETED
- LEARNING_PATH_COMPLETED_BATCH
- CERTIFICATION_COMPLETED
- CERTIFICATION_COMPLETED_BATCH
-
Use o campo de data/hora para determinar se o evento deve ser ignorado ou processado, exceto para o evento LEARNER_PROGRESS.
Práticas recomendadas de consumo de eventos de webhooks
- A solução de webhook é usada para lidar com sistemas de alto throughput em que a velocidade e a baixa latência são essenciais. Portanto, o cliente deve garantir que o evento seja confirmado assim que for recebido. Mesmo se for necessário um processamento adicional por parte do cliente (como a busca de dados de relatórios, API ou a execução de outras ações), a confirmação deve ser enviada assim que o evento for recebido e cabe ao cliente processar o evento posteriormente.
- Não reconhecer o evento o mais rápido possível pode afetar a natureza em tempo real dos eventos, já que os eventos subsequentes só serão emitidos depois que a confirmação anterior for recebida.
- Os clientes podem responder com um código de status HTTP 202 Aceito para confirmar que o evento foi aceito.
Limitações
- As ajudas de tarefa não são consideradas para eventos do Webhook na categoria de OAs porque geralmente são usadas para ajudar os alunos a concluir outros objetos de aprendizado.
- Uma desativação da instância do objeto de aprendizado seria considerada um evento de atualização. Não haveria um evento de exclusão para uma instância, pois ela só pode ser desativada, e não excluída.
- As alterações de sessão seriam capturadas como parte do evento de atualização da instância. Isso se aplica apenas aos cursos. Não haverá propagação ascendente de entidades de nível inferior para instâncias do caminho de aprendizado ou instâncias de certificação.
- Se um caminho de aprendizado contiver um curso e um aluno concluir o curso por meio do caminho de aprendizado, dois eventos LearnerProgress serão gerados: um para o curso e outro para o caminho de aprendizado.
- Determinados fluxos de trabalho calculam atributos de objetos de aprendizado, como duração e tipo de entrega, de forma assíncrona. Portanto, os eventos para esses objetos de aprendizado serão gerados assim que o trabalho cron terminar o processamento.
- Se um curso for inscrito por meio de um programa de aprendizado ou certificação pai, os eventos de inscrição, cancelamento de inscrição e conclusão serão acionados apenas para o programa de aprendizado ou certificação pai. Esses eventos não serão acionados para o curso secundário, pois a inscrição ocorreu indiretamente.
- Os webhooks só têm suporte para contas com status ATIVO. Eles não estão disponíveis para contas DE AVALIAÇÃO ou INATIVAS.
Cargas de exemplo para os eventos
| code language-none |
|---|
|
| code language-none |
|---|
|
| code language-none |
|---|
|
| code language-none |
|---|
|
| code language-none |
|---|
|
| code language-none |
|---|
|
| code language-none |
|---|
|
| code language-none |
|---|
|
| code language-none |
|---|
|
| code language-none |
|---|
|
| code language-none |
|---|
|
| code language-none |
|---|
|
| code language-none |
|---|
|
| code language-none |
|---|
|
| code language-none |
|---|
|
| code language-none |
|---|
|
| code language-none |
|---|
|
| code language-none |
|---|
|
| code language-none |
|---|
|
| code language-none |
|---|
|
| code language-none |
|---|
|
| code language-none |
|---|
|
| code language-none |
|---|
|
| code language-none |
|---|
|
| code language-none |
|---|
|
| code language-none |
|---|
|
| code language-none |
|---|
|