Un proveedor de IoT expone un servicio de eventos personalizado a sus socios. Los socios proporcionan puntos de conexión de webhook HTTPS que pueden estar intermitentemente fuera de línea. Debe publicar eventos utilizando un esquema estándar entre lenguajes, filtrar eventos por prefijo eventType, reintentar durante un máximo de 24 horas con retroceso exponencial y, si la entrega finalmente falla, almacenar los eventos no entregados en una cuenta de almacenamiento para auditoría. ¿Qué debe implementar?

La opción correcta es Azure Event Grid porque cumple con todos los requisitos. Un tema personalizado de Event Grid permite publicar eventos desde un proveedor de IoT. El esquema CloudEvents v1.0 es un estándar entre lenguajes. Las suscripciones de eventos permiten filtrar por eventType y configurar una política de reintentos de hasta 24 horas con retroceso exponencial, esencial para puntos de conexión intermitentes. El dead-lettering a una cuenta de Azure Storage garantiza que los eventos no entregados se almacenen para auditoría. Las otras opciones son incorrectas: Azure Service Bus Topics no ofrece dead-lettering directo a Storage para fallos de entrega HTTP y no es ideal para eventos de IoT de baja latencia. Azure Event Hubs es para ingesta de datos a gran escala, no para distribución de eventos a puntos de conexión HTTP externos con reintentos avanzados y dead-lettering. Un dominio de Event Grid es para gestionar múltiples temas, pero la opción incorrecta especifica deshabilitar los reintentos y no aborda el dead-lettering automático. Azure Logic Apps es una solución de integración, no un servicio nativo de publicación/suscripción de eventos con las capacidades de filtrado y reintentos automáticos requeridas.