Aplazamiento de mensajes en Azure Service Bus

Cuando un cliente de cola o suscripción recibe un mensaje que está dispuesto a procesar, pero el procesamiento no es posible actualmente debido a circunstancias especiales, el cliente puede aplazar la recuperación del mensaje a un punto posterior. El mensaje permanece en la cola o la suscripción, pero se reserva.

Cuándo usar el aplazamiento de mensajes

El aplazamiento es una característica creada específicamente para escenarios de procesamiento de flujos de trabajo. Los marcos de flujo de trabajo pueden requerir que determinadas operaciones se procesen en un orden determinado. Es posible que tengan que posponer el procesamiento de algunos mensajes recibidos hasta que se complete el trabajo previo indicado por otros mensajes.

Un ejemplo ilustrativo sencillo es una secuencia de procesamiento de pedidos en la que una notificación de pago de un proveedor de pagos externo aparece en un sistema antes de que el pedido de compra coincidente se propague desde el escaparate al sistema de suministro. En ese caso, el sistema de suministro podría aplazar el procesamiento de la notificación de pago hasta que haya un pedido para asociarlo. En escenarios de encuentro, donde los mensajes de diferentes orígenes impulsan un flujo de trabajo hacia delante, el orden de ejecución en tiempo real podría ser correcto, pero los mensajes que reflejan los resultados podrían llegar fuera del orden.

El aplazamiento ayuda a reordenar los mensajes desde el orden de llegada a un orden en el que se pueden procesar, al tiempo que deja esos mensajes de forma segura en el almacén de mensajes cuando es necesario posponer el procesamiento.

Si no se puede procesar un mensaje porque un recurso determinado para controlar ese mensaje no está disponible temporalmente, pero el procesamiento de mensajes no debe suspenderse, puede dejar ese mensaje a un lado durante unos minutos. Recuerde el número de secuencia de un mensaje programado que se publicará en unos minutos y vuelva a recuperar el mensaje diferido cuando llegue el mensaje programado. Si un controlador de mensajes depende de una base de datos para todas las operaciones y esa base de datos no está disponible temporalmente, no use el aplazamiento. En su lugar, suspenda la recepción de mensajes por completo hasta que la base de datos vuelva a estar disponible.

Recuperación de mensajes diferidos

Los mensajes diferidos permanecen en la cola principal junto con todos los demás mensajes activos (a diferencia de los mensajes fallidos que residen en una subconsulta), pero ya no se pueden recibir mediante las operaciones de recepción normales. Puede descubrir mensajes diferidos mediante la exploración o la inspección de mensajes si una aplicación les pierde el rastro.

Para recuperar un mensaje diferido, el propietario es responsable de recordar el número de secuencia al aplazar el mensaje. Cualquier receptor que conozca el número de secuencia de un mensaje diferido puede recibir más adelante el mensaje mediante métodos de recepción que toman el número de secuencia como parámetro. Para obtener más información sobre los números de secuencia, vea Secuenciación de mensajes y marcas de tiempo.

Nota:

Los mensajes diferidos no expiran y permanecen en la cola de mensajes fallidos hasta que una aplicación cliente intenta recibirlos mediante una API y el número de secuencia. Este comportamiento se debe al diseño. Cuando un cliente intenta recuperar un mensaje diferido, se comprueba si cumple la condición de expirado y, en ese caso, se mueve a una cola de mensajes no entregables si ya ha expirado. Un mensaje expirado se mueve a una subcola de mensajes fallidos solo cuando la funcionalidad de mensajes fallidos está habilitada para la entidad (cola o suscripción).

Comportamientos clave de mensajes diferidos

  • Los mensajes diferidos permanecen en la cola principal, no en una subcola.
  • Debe usar el número de secuencia del mensaje para recuperar un mensaje diferido.
  • Los mensajes diferidos se pueden detectar a través de la exploración de mensajes (inspección).
  • Los mensajes diferidos no expiran hasta que un cliente intenta recibirlos.
  • La comprobación de expiración solo se produce cuando un cliente llama a una API de recepción con el número de secuencia.

Pasos siguientes

Pruebe los ejemplos en el lenguaje que prefiera para explorar las características de Azure Service Bus.

Contenido relacionado

  • Last updated on