{"id":12471,"date":"2021-11-15T10:34:56","date_gmt":"2021-11-15T18:34:56","guid":{"rendered":"https:\/\/www.couchbase.com\/blog\/?p=12471"},"modified":"2025-06-13T22:39:19","modified_gmt":"2025-06-14T05:39:19","slug":"couchbase-eventing-handling-errors-and-retries","status":"publish","type":"post","link":"https:\/\/www.couchbase.com\/blog\/pt\/couchbase-eventing-handling-errors-and-retries\/","title":{"rendered":"Manipula\u00e7\u00e3o de eventos do Couchbase: erros e novas tentativas"},"content":{"rendered":"

O <\/span>Servi\u00e7o de eventos do Couchbase<\/span><\/a> permite que voc\u00ea aja prontamente em rela\u00e7\u00e3o a muta\u00e7\u00f5es (ou altera\u00e7\u00f5es) em seus dados. Todas as a\u00e7\u00f5es em Eventos<\/a> s\u00e3o realizados com a execu\u00e7\u00e3o de um lambda, uma pequena parte da l\u00f3gica comercial escrita em JavaScript.<\/span><\/p>\n

Os casos de uso comuns incluem enriquecimento de dados, arquivamento de documentos e integra\u00e7\u00e3o com servi\u00e7os REST externos. Veja mais detalhes <\/span>aqui<\/span><\/a>.<\/span><\/p>\n

No blog a seguir, descreveremos como os erros durante a execu\u00e7\u00e3o do ouvinte de eventos podem ser tratados. Ao usar um mecanismo de repeti\u00e7\u00e3o, garantimos que a a\u00e7\u00e3o prevista seja executada, mesmo que o ouvinte de eventos falhe durante a execu\u00e7\u00e3o.<\/span><\/p>\n

Aplicativo de amostra<\/i><\/b><\/p>\n

Como exemplo, implementamos parte de um aplicativo de com\u00e9rcio eletr\u00f4nico que armazena os pedidos dos clientes em uma cole\u00e7\u00e3o do Couchbase. Assim que o status de um pedido \u00e9 alterado para <\/span>pago<\/b>Se o cliente n\u00e3o tiver uma confirma\u00e7\u00e3o de pedido, queremos enviar uma confirma\u00e7\u00e3o de pedido para o cliente.<\/span><\/p>\n

Para isso, integramos um ouvinte de eventos do Couchbase com um <\/span>servi\u00e7o de e-mail<\/span><\/i>. O ouvinte de eventos do Couchbase captar\u00e1 todas as altera\u00e7\u00f5es no documento do pedido, verificar\u00e1 se o pedido foi pago e, em seguida, chamar\u00e1 o servi\u00e7o de e-mail para acionar a mensagem de confirma\u00e7\u00e3o.<\/span><\/p>\n

O servi\u00e7o de e-mail \u00e9 um microsservi\u00e7o aut\u00f4nomo que fornece um ponto de extremidade REST. Usamos o suporte cURL incorporado diretamente no Couchbase Eventing para chamar o microsservi\u00e7o a partir do ouvinte de eventos.<\/span><\/p>\n

\"\"<\/p>\n

Fluxo conceitual: \u00c0 medida que os pedidos s\u00e3o atualizados no Couchbase, os eventos s\u00e3o acionados e captados por um ouvinte de eventos. Em seguida, o ouvinte de eventos chama o servi\u00e7o de e-mail externo.<\/span><\/i><\/p>\n

\u00a0<\/span>Servi\u00e7o de e-mail que retorna um erro<\/b><\/p>\n

O cen\u00e1rio descrito funciona muito bem se o <\/span>servi\u00e7o de e-mail<\/span><\/i> est\u00e1 operacional. No entanto, o que acontece se o <\/span>servi\u00e7o de e-mail<\/span><\/i> est\u00e1 retornando um erro? As solicita\u00e7\u00f5es do ouvinte de eventos para o servi\u00e7o de e-mail falhar\u00e3o e, portanto, nenhuma mensagem de confirma\u00e7\u00e3o ser\u00e1 enviada ao cliente. Como no momento da falha o evento de altera\u00e7\u00e3o de documento do Couchbase j\u00e1 foi processado, nenhum novo evento para o mesmo documento \u00e9 acionado, a menos que haja outra altera\u00e7\u00e3o nele. Para garantir que a confirma\u00e7\u00e3o seja enviada, precisamos tratar o erro e implementar um mecanismo de nova tentativa. Ao fazer isso, podemos contornar qualquer problema tempor\u00e1rio do servi\u00e7o externo e, ao mesmo tempo, garantir que a confirma\u00e7\u00e3o seja enviada.<\/span><\/p>\n

\u00a0<\/span>H\u00e1 diferentes maneiras de abordar isso. No meu exemplo abaixo, optei por criar uma nova cole\u00e7\u00e3o chamada \"retry\", que armazenar\u00e1 refer\u00eancias aos documentos para os quais a execu\u00e7\u00e3o do ouvinte de eventos falhou.<\/span><\/p>\n

\"\"<\/p>\n

\u00a0<\/span>O ouvinte de eventos captar\u00e1 as altera\u00e7\u00f5es nos documentos do pedido (etapa #1) e, em seguida, chamar\u00e1 o servi\u00e7o de e-mail (etapa #2). Se a chamada para o servi\u00e7o de e-mail for bem-sucedida, o ouvinte de eventos atualizar\u00e1 o status da mensagem de confirma\u00e7\u00e3o no documento do pedido (etapa #3). No entanto, em caso de falha, um documento de nova tentativa \u00e9 criado e colocado na cole\u00e7\u00e3o 'retry' (etapa #3*).<\/span><\/p>\n

Manter uma refer\u00eancia aos documentos nos permite identificar todas as atualiza\u00e7\u00f5es que falharam e nos permite execut\u00e1-las novamente mais tarde. Isso pode ser feito por meio da interven\u00e7\u00e3o manual de um operador ou por uma nova tentativa autom\u00e1tica usando os cron\u00f4metros de eventos do Couchbase.<\/span><\/p>\n

\"\"<\/p>\n

    \n
  1. Iniciamos o processo de repeti\u00e7\u00e3o adicionando um documento com um ID de documento especificado \u00e0 cole\u00e7\u00e3o de repeti\u00e7\u00e3o. Um cron\u00f4metro recorrente \u00e9 criado com um intervalo de cron\u00f4metro fornecido.<\/span><\/li>\n
  2. Na execu\u00e7\u00e3o do cron\u00f4metro, todos os documentos mais antigos do que um pequeno quanta de tempo no <\/span>tentar novamente<\/span><\/i> s\u00e3o atualizados. Ao adicionar um atributo como <\/span>fireRetry = true<\/span><\/i> para os documentos de nova tentativa, acionamos outro evento de atualiza\u00e7\u00e3o que \u00e9 captado pelo ouvinte de eventos para executar o mecanismo de nova tentativa. Isso nos d\u00e1 uma muta\u00e7\u00e3o recursiva que ilumina todos os documentos na cole\u00e7\u00e3o de tentativas em paralelo. A fun\u00e7\u00e3o de nova tentativa agora \u00e9 executada usando todos os threads de trabalho dispon\u00edveis em paralelo.<\/span><\/li>\n
  3. Um evento de atualiza\u00e7\u00e3o de documento \u00e9 acionado para cada documento de nova tentativa individualmente.<\/span><\/li>\n
  4. O documento de pedido correspondente \u00e9 recuperado da cole\u00e7\u00e3o de entrada<\/span><\/li>\n
  5. Agora o servi\u00e7o de e-mail \u00e9 chamado.<\/span><\/li>\n
  6. Se a chamada para o servi\u00e7o de e-mail for bem-sucedida, o ouvinte do evento atualizar\u00e1 o status da mensagem de confirma\u00e7\u00e3o no documento do pedido e remover\u00e1 o documento de nova tentativa\u00a0<\/span><\/li>\n
  7. Em caso de falha, o documento de nova tentativa \u00e9 atualizado e colocado na cole\u00e7\u00e3o \"retry\".<\/span><\/li>\n<\/ol>\n

    Revis\u00e3o do c\u00f3digo<\/b><\/p>\n

    \u00a0<\/span>Agora que j\u00e1 estabelecemos o projeto conceitual, vamos dar uma olhada no exemplo de implementa\u00e7\u00e3o:<\/span><\/p>\n

    Pr\u00e9-requisitos<\/b>:<\/span><\/p>\n