Plan asynchrone et courtiers
ConceptProduitDepuis la version 1.5.0
Guide produit : ce que la capacité apporte, pour qui, ses limites et la version qui l'a livrée - sans syntaxe de configuration.
| Ce que ça fait | Met un courtier de messages derrière les mêmes contrôles que HTTP, dans les deux sens, sous un contrat AsyncAPI. Un service HTTP ou un outil d'agent publie sans embarquer de client du courtier (202 une fois le message accusé) ; un navigateur ou une application s'abonne en SSE ou en WebSocket (au moins une fois) ; un partenaire reçoit des webhooks signés (Standard Webhooks), avec reprises et file de rebut |
| Pourquoi c'est important | Chaque abonné ne lit que son tenant, voire seulement ses propres messages. Les messages portent une enveloppe standard (CloudEvents) et la trace. Plus besoin d'exposer un courtier à Internet ni de distribuer ses identifiants |
| Courtiers | Kafka, RabbitMQ (AMQP 0-9-1), MQTT 5 et 3.1.1 (1.5.0) ; NATS Core et JetStream, AMQP 1.0 - RabbitMQ 4, Azure Service Bus, ActiveMQ Artemis, Solace (1.6.0) |
| Charges binaires | Avro, Protobuf et CBOR sous schéma, validés quand l'opération le demande, convertis en JSON vers SSE et webhooks ; registre de schémas en lecture (API Confluent) (1.6.0) |
| Cas d'usage | Notifier un écran client en direct des évènements de sa commande ; livrer des factures à un partenaire par webhook signé ; publier depuis un service sans dépendance Kafka ; diffuser un flux public à des visiteurs anonymes |
| Limites | La passerelle ne crée aucun topic ni file ; elle est client du courtier, pas un courtier ; les appareils MQTT branchés sur la passerelle (IoT, Sparkplug B, OPC UA) arrivent en 1.7.0 |
| Depuis | 1.5.0 ; 1.6.0 pour NATS, AMQP 1.0 et les charges binaires |
| Configurer | Publier et consommer sur un courtier |