Aplazamiento de mensajes
Cuando un cliente de cola o suscripción recibe un mensaje que se desea procesar, pero cuyo procesamiento no es posible en ese momento debido a circunstancias especiales, tiene la opción de "aplazar" la recuperación del mensaje para un momento posterior. El mensaje permanece en la cola o la suscripción, pero se reserva.
Nota:
Los mensajes diferidos no expiran y se mueven automáticamente a una cola de mensajes fallidos hasta que una aplicación cliente intenta recibirlos mediante una API y el número de secuencia. Este comportamiento es por diseño. Cuando un cliente intenta recuperar un mensaje diferido, se comprueba si hay una condición expirada y se mueve a una cola de mensajes fallidos si ya ha expirado. Un mensaje expirado se mueve a una subconsulta de mensajes fallidos solo cuando la característica de mensajes fallidos está habilitada para la entidad (cola o suscripción).
Escenarios de ejemplo
El aplazamiento es una característica creada específicamente para escenarios de procesamiento de flujo de trabajo. Los marcos de los flujos de trabajo pueden requerir que ciertas operaciones se procesen en un orden particular. Es posible que tengan que posponer el procesamiento de algunos mensajes recibidos hasta que se haya completado el trabajo previo indicado por otros mensajes.
Un ejemplo sencillo es una secuencia de procesamiento de pedidos en la que una notificación de pago de un proveedor de pago externo aparece en un sistema antes de haberse propagado el pedido de compra correspondiente desde el escaparate al sistema de suministro. En ese caso, el sistema de suministro puede aplazar el procesamiento de la notificación de pago hasta que haya un pedido con el que se vaya a asociar. En escenarios de encuentro, donde los mensajes de orígenes diferentes conducen a un desvío de flujo de trabajo, el orden de ejecución en tiempo real puede, de hecho, ser correcto pero los mensajes que reflejan los resultados pueden llegar fuera de orden.
En última instancia, el aplazamiento contribuye a volver a ordenar los mensajes de su orden de llegada a un orden en el que se pueden procesar, lo que permite dejar los mensajes de forma segura en el almacén de mensajes cuyo procesamiento tiene que posponerse.
Si no se puede procesar un mensaje porque un recurso concreto para controlar ese mensaje no está disponible temporalmente, pero el procesamiento de mensajes no debe suspenderse sumariamente, una forma de apartar ese mensaje durante unos minutos es recordar el número de secuencia de un mensaje programado que se vaya a publicar en unos minutos, y volver a recuperar el mensaje aplazado cuando llega el mensaje programado. Tenga en cuenta que, si un controlador de mensajes depende de una base de datos para todas las operaciones y esa base de datos no está disponible temporalmente, esta no debe usar el aplazamiento, sino que, en su lugar, debe suspender la recepción de mensajes por completo hasta que la base de datos vuelva a estar disponible.
Recuperación de mensajes aplazados
Los mensajes aplazados permanecen en la cola principal junto con todos los demás mensajes activos (a diferencia de los mensajes fallidos que están activos en una subcola), pero ya no se reciben mediante las funciones de recepción habituales. Los mensajes diferidos se pueden detectar a través de la exploración de mensajes o viendo el código sin salir si una aplicación pierde su pista.
Para recuperar un mensaje aplazado, su propietario es responsable de recordar la propiedad el número de secuencia cuando se aplaza. Cualquier receptor que conozca el número de secuencia de un mensaje aplazado puede recibir el mensaje más adelante 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, consulte Secuenciación y marcas de tiempo de los mensajes.
Pasos siguientes
Pruebe los ejemplos en el lenguaje que prefiera para explorar las características de Azure Service Bus.
- Ejemplos de la biblioteca cliente de Azure Service Bus para .NET (versión más reciente): consulte el ejemplo de resolución de mensajes.
- Ejemplos de la biblioteca cliente de Azure Service Bus para Java (versión más reciente)
- Ejemplos de la biblioteca cliente de Azure Service Bus para Python: consulte el ejemplo de receive_deferred_message_queue.py.
- Ejemplos de la biblioteca cliente de Azure Service Bus para JavaScript: consulte el ejemplo de advanced/deferral.js.
- Ejemplos de la biblioteca cliente de Azure Service Bus para TypeScript: consulte el ejemplo de advanced/deferral.ts.
Aquí puede ver ejemplos de las bibliotecas cliente de .NET y Java anteriores:
- Ejemplos de la biblioteca cliente de Azure Service Bus para .NET (versión heredada): consulte el ejemplo de aplazamiento.
- Ejemplos de la biblioteca cliente de Azure Service Bus para Java (versión heredada)
El 30 de septiembre de 2026, retiraremos las bibliotecas del SDK de Azure Service Bus WindowsAzure.ServiceBus, Microsoft.Azure.ServiceBus y com.microsoft.azure.servicebus, que no se ajustan a las directrices del SDK de Azure. También retiraremos el soporte del protocolo SBMP, por lo que ya no podrás usar este protocolo después del 30 de septiembre de 2026. Migre a las bibliotecas más recientes del SDK de Azure, que ofrecen actualizaciones de seguridad críticas y funcionalidades mejoradas, antes de esa fecha.
Aunque las bibliotecas anteriores todavía se pueden usar después del 30 de septiembre de 2026, ya no recibirán soporte técnico oficial ni actualizaciones de Microsoft. Para obtener más información, consulte el anuncio de retirada de soporte técnico.