Amélioration de la résilience du routage des données vers vos serveurs à compter du 27 mai 2026

A partir du 27 mai 2026, la résilience du routage vers vos serveurs sera améliorée sur tous vos comptes Live Objects.

En cas d’indisponibilité d’un ou plusieurs de vos serveurs, les messages routés en HTTP push ou MQTT application pourront être mis en attente pendant une durée garantie quelque soit la quantité de données routées sur votre compte, puis renvoyés vers votre serveur automatiquement dès qu’il est de nouveau disponible.

Quelle sera la durée garantie de mise en attente ?

Celle-ci dépend de votre offre :

• IoT Connect Low Power – Base : 24h
• IoT Connect Low Power – Premium : 7 jours

Pour les autres offres, contactez-nous via le formulaire de contact commercial.

Quelles sont les améliorations apportées ?

Auparavant si vous utilisez HTTP push, la politique de ré-essai est limitée à 24h maximum pour toutes les offres. Par ailleurs un fort ralentissement des temps de réponse de vos serveurs conjointement avec un niveau de trafic élevé pouvait rendre le mécanisme de ré-essai inopérant et occasionner des pertes de message.

A partir du 27 mai ces limitations seront levées, et vous pourrez en fonction de votre offre bénéficier d’un politique de ré essai étendue jusqu’à 7 jours selon votre offre.

Si vous routez vos données en MQTT (application mode), la durée de mise en attente était limitée par la taille mémoire que vous avez allouée à vos FIFO sur Live Objects. De plus il était nécessaire de détruire et recréer une FIFO pour augmenter la taille mémoire allouée à mesure que votre trafic augmente ou pour activer/désactiver la mise en attente. Cela nécessitait une opération de migration délicate. Ces limitations sont levées avec l’amélioration du 27 mai : la durée de mise en attente dépendra uniquement de votre offre et l’activation/désactivation de la mise en attente peut être faite à chaud.

Comment bénéficier de cette fonctionnalité ?

Cette amélioration est activée automatiquement sur tous vos comptes Live Objects à partir du 27 mai 2026.

Je souhaite désactiver la mise en attente lors du routage des données, comment procéder ?

Vous pouvez souhaiter ne pas mettre en attente les messages en cas d’indisponibilité de vos serveurs pour diverses raisons (flux de test, nécessité d’avoir uniquement des données “fraîches”, …).

Si vous utilisez MQTT

Il suffit de décocher l’option “Conserver les messages non consommés” dans les paramètres de la règle de routage. Ce paramètre pourra être modifié à tout moment.

Cette option est décochée par défaut sur les règles pointant vers des FIFOs sur lesquelles la rétention était désactivée avant le 27 mai.

Si vous utilisez HTTP push

Il suffit de cocher l’option “Réessayer” dans la Politique en cas d’échec.

Comment la gestion des FIFOs va-t-elle évoluer ?

Il était nécessaire de créer une file d’attente FIFO pour chaque topic de publication MQTT de vos règles de routage, en lui allouant une taille fixe en bytes et en configurant la durée de rétention maximum (TTL).

Depuis le 27 mai, il suffit de définir le topic MQTT de publication lors de la création de la règle de routage ; la FIFO associée au topic est automatiquement créée si elle n’existe pas déjà, et cela sans que vous ayez à en spécifier la taille ni la rétention. De la même façon la FIFO est supprimée automatiquement lors de la suppression de la règle de routage. Sur le portail Live Objects, la page listant les FIFOs sur votre compte se trouve désormais à côté des règles de routage.

Quel est l’impact de l’opération du 27 mai ?

Les FIFOs ont été automatiquement converties au nouveau format sans que vous ayez à intervenir, et sans perte de données.

J’utilise les APIs pour manipuler ou interroger les FIFOs, y-a-t-il des changements prévus ?

Dans le cadre ce cette évolution voici les changements prévus :

API	Fonction	à partir du 27 mai 2026	à partir du 30 octobre 2026
POST /api/v0/topics/fifo	Creating a new FIFO	Service maintenu, cependant les paramètres de taille mémoire et de TTL seront ignorés lors de la création de la FIFO puisque, d’une part la FIFO ne sera plus limitée en taille mémoire, et d’autre part le TTL dépendra du paramètre noRetention de la fifoPublishAction. L’API sera dépréciée, remplacée par POST /api/v1/event2action/actionPolicies	Supprimée
DELETE /api/v0/topics/fifo/{fifoName}	Deleting a FIFO	Service maintenu. Modification dans la réponse : l’API retournera 200 lorsque la FIFO n’existe pas ou a été supprimée. L’API sera dépréciée, remplacée par DELETE /api/v1/event2action/actionPolicies	Supprimée
GET /api/v0/topics/fifo GET/api/v0/topics/fifo/{fifoName}	Listing FIFO topics, Getting a FIFO	Service maintenu. Modifications dans les données renvoyées : messageTtl = durée de mise en attente selon l’offre, maxLengthBytes = -1. L’API est remplacée par GET /api/v1/event2action/fifos et GET /api/v1/event2action/fifos/{fifoName}. Pour connaître le nombre total de messages en attente sur une action de fifoPublish, vous pouvez également utiliser GET /api/v1/event2action/metrics/actionPolicies/{policyId}/actions/{actionId}. Par ailleurs si vous supervisez programmatiquement le nombre de message en attente pour détecter un incident de routage, sachez que vous pourrez à partir de fin avril être notifié par email en cas de non remise des message pendant une durée d’une heure ou plus en configurant un alerte dans le menu Alarmes & rapports > Configuration des alarmes > Routage des messages.	Supprimée

Je souhaite en savoir plus

Contactez-nous via le formulaire de contact commercial.