{"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\/es\/couchbase-eventing-handling-errors-and-retries\/","title":{"rendered":"Couchbase Eventing Manejo de Errores y Reintentos"},"content":{"rendered":"

En <\/span>Servicio de eventos Couchbase<\/span><\/a> le permite actuar r\u00e1pidamente en caso de mutaciones (o cambios) en sus datos. Todas las acciones en Eventos<\/a> se llevan a cabo mediante la ejecuci\u00f3n de una lambda, un peque\u00f1o fragmento de l\u00f3gica de negocio escrito en JavaScript.<\/span><\/p>\n

Entre los casos de uso m\u00e1s comunes se incluyen el enriquecimiento de datos, el archivo de documentos y la integraci\u00f3n con servicios REST externos. M\u00e1s informaci\u00f3n <\/span>aqu\u00ed<\/span><\/a>.<\/span><\/p>\n

En el siguiente blog, describiremos c\u00f3mo se pueden manejar los errores durante la ejecuci\u00f3n del listador de eventos. Mediante el uso de un mecanismo de reintento nos aseguramos de que la acci\u00f3n prevista se lleva a cabo, incluso si el receptor de eventos falla durante la ejecuci\u00f3n.<\/span><\/p>\n

Ejemplo de solicitud<\/i><\/b><\/p>\n

Como ejemplo, implementamos parte de una aplicaci\u00f3n de comercio electr\u00f3nico que almacena los pedidos de los clientes en una colecci\u00f3n de Couchbase. En cuanto el estado de un pedido cambia a <\/span>pagado<\/b>Queremos enviar una confirmaci\u00f3n de pedido al cliente.<\/span><\/p>\n

Para lograrlo, integramos un receptor de eventos de Couchbase con una aplicaci\u00f3n externa <\/span>servicio de correo electr\u00f3nico<\/span><\/i>. El receptor de eventos de Couchbase recoger\u00e1 cualquier cambio en el documento del pedido, verificar\u00e1 que el pedido se ha pagado y, a continuaci\u00f3n, llamar\u00e1 al servicio de correo electr\u00f3nico para activar el mensaje de confirmaci\u00f3n.<\/span><\/p>\n

El servicio de correo electr\u00f3nico es un microservicio independiente que proporciona un punto final REST. Usamos el soporte cURL integrado directamente en Couchbase Eventing para llamar al microservicio desde el receptor de eventos.<\/span><\/p>\n

\"\"<\/p>\n

Flujo conceptual: A medida que los pedidos se actualizan en Couchbase, los eventos se disparan y son recogidos por un listener de eventos. A continuaci\u00f3n, el receptor de eventos llama al servicio de correo electr\u00f3nico externo.<\/span><\/i><\/p>\n

\u00a0<\/span>El servicio de correo electr\u00f3nico devuelve un error<\/b><\/p>\n

El escenario descrito funciona muy bien si el <\/span>servicio de correo electr\u00f3nico<\/span><\/i> est\u00e1 operativo. Sin embargo, \u00bfqu\u00e9 ocurre si el <\/span>servicio de correo electr\u00f3nico<\/span><\/i> devuelve un error? Las peticiones del escuchador de eventos al servicio de correo electr\u00f3nico fallar\u00e1n y, por tanto, no se enviar\u00e1 ning\u00fan mensaje de confirmaci\u00f3n al cliente. Dado que en el momento del fallo el evento de cambio de documento de Couchbase ya ha sido procesado, no se dispara ning\u00fan nuevo evento para el mismo documento a menos que haya otro cambio en \u00e9l. Para asegurar que la confirmaci\u00f3n es enviada necesitamos manejar el error e implementar un mecanismo de reintento. Haciendo esto podemos solucionar cualquier problema temporal del servicio externo y al mismo tiempo garantizar que la confirmaci\u00f3n es enviada.<\/span><\/p>\n

\u00a0<\/span>Hay diferentes maneras de enfocar esto. En mi ejemplo de abajo elijo crear una nueva colecci\u00f3n llamada 'retry', que almacenar\u00e1 referencias a los documentos para los que fall\u00f3 la ejecuci\u00f3n del listener de eventos.<\/span><\/p>\n

\"\"<\/p>\n

\u00a0<\/span>El receptor de eventos recoger\u00e1 los cambios en los documentos de pedido (paso #1) y luego llamar\u00e1 al servicio de correo electr\u00f3nico (paso #2). Si la llamada al servicio de correo electr\u00f3nico tiene \u00e9xito, el receptor de eventos actualiza el estado del mensaje de confirmaci\u00f3n en el documento de pedido (paso #3). Sin embargo, en caso de fallo, se crea un documento de reintento y se coloca en la colecci\u00f3n \"reintento\" (paso #3*).<\/span><\/p>\n

Mantener una referencia a los documentos nos permite identificar todas las actualizaciones fallidas y nos permite volver a ejecutarlas m\u00e1s tarde. Esto podr\u00eda ser mediante la intervenci\u00f3n manual de un operador o el reintento autom\u00e1tico utilizando temporizadores de eventos de Couchbase.<\/span><\/p>\n

\"\"<\/p>\n

    \n
  1. Iniciamos el proceso de reintento a\u00f1adiendo un documento con un id de documento especificado a la colecci\u00f3n de reintentos. Se crea un temporizador recurrente con un intervalo proporcionado.<\/span><\/li>\n
  2. En la ejecuci\u00f3n del temporizador, todos los documentos m\u00e1s antiguos que un peque\u00f1o cuanto de tiempo en el <\/span>reintentar<\/span><\/i> se actualizan. A\u00f1adiendo un atributo como <\/span>fireRetry = true<\/span><\/i> a los documentos de reintento disparamos otro evento de actualizaci\u00f3n que es recogido por el escuchador de eventos para ejecutar el mecanismo de reintento. Esto nos da una mutaci\u00f3n recursiva que enciende todos los documentos de la colecci\u00f3n retry en paralelo. La funci\u00f3n de reintento se ejecuta ahora utilizando todos los hilos de trabajo disponibles en paralelo.<\/span><\/li>\n
  3. Se activa un evento de actualizaci\u00f3n de documento para cada documento de reintento individualmente.<\/span><\/li>\n
  4. El documento de pedido correspondiente se recupera de la colecci\u00f3n de entrada<\/span><\/li>\n
  5. Ahora se llama al servicio de correo electr\u00f3nico.<\/span><\/li>\n
  6. Si la llamada al servicio de correo electr\u00f3nico tiene \u00e9xito, el receptor de eventos actualiza el estado del mensaje de confirmaci\u00f3n en el documento de pedido y elimina el documento de reintento.\u00a0<\/span><\/li>\n
  7. En caso de fallo, el documento de reintento se actualiza y se coloca en la colecci\u00f3n \"reintento\".<\/span><\/li>\n<\/ol>\n

    Revisi\u00f3n de c\u00f3digos<\/b><\/p>\n

    \u00a0<\/span>Ahora que ya hemos establecido el dise\u00f1o conceptual, echemos un vistazo al ejemplo de implementaci\u00f3n:<\/span><\/p>\n

    Requisitos previos<\/b>:<\/span><\/p>\n