Se connecter à Azure Service Bus à partir de workflows dans Azure Logic Apps
S’applique à : Azure Logic Apps (Consommation + Standard)
Ce guide explique comment accéder à Azure Service Bus à partir d’un workflow dans Azure Logic Apps à l’aide du connecteur Service Bus. Vous pouvez ensuite créer des workflows automatisés qui s’exécutent lorsqu’ils sont déclenchés par des événements dans Service Bus ou exécutent des actions pour gérer les éléments Service Bus, par exemple :
- Surveillance de la réception des messages (semi-automatique ou passage furtif) dans les files d’attente, les rubriques et les abonnements aux rubriques
- Envoi de messages
- Création et suppression des abonnements de rubrique
- Gestion des messages dans les files d’attente et les abonnements aux rubriques, par exemple : obtention, obtention différée, exécution, report, abandon et lettre morte
- Renouvellement des verrous sur les messages et les sessions dans les files d’attente et les abonnements aux rubriques
- Clôture des sessions dans les rubriques et les files d’attente
Vous pouvez utiliser des déclencheurs afin d’obtenir des réponses d’Azure Service Bus et mettre la sortie à la disposition d’autres actions dans vos workflows d’applications logiques. Vous pouvez également faire en sorte que d’autres actions utilisent la sortie d’actions Service Bus.
Référence technique du connecteur
Le connecteur Service Bus a différentes versions, en fonction du type de workflow et de l’environnement hôte.
| Application logique | Environnement | Version du connecteur |
|---|---|---|
| Consommation | Azure Logic Apps multilocataire | Connecteur managé, qui apparaît dans la galerie de connecteurs sous Runtime>Partagé. Remarque : les déclencheurs de connecteur managés par Service Bus suivent le modèle de déclencheur d’interrogation longue, ce qui signifie que le déclencheur vérifie périodiquement la présence de messages dans l’abonnement à la file d’attente ou à la rubrique. Pour plus d’informations, consultez la documentation suivante : - Référence du connecteur géré Service Bus - Connecteurs managés dans Azure Logic Apps |
| Standard | Azure Logic Apps monolocataire et App Service Environment v3 (plans Windows uniquement) | Connecteur managé (hébergé par Azure), qui apparaît dans la galerie de connecteurs sous Runtime>Partagé, et connecteur intégré qui apparaît dans la galerie de connecteurs sous Runtime>Dans l’application et qui est basé sur le fournisseur de services. Les déclencheurs de connecteur managés par Service Bus suivent le modèle de déclencheur d’interrogation longue, ce qui signifie que le déclencheur vérifie périodiquement la présence de messages dans l’abonnement à la file d’attente ou à la rubrique. Les déclencheurs non liés à la session du connecteur intégré Service Bus suivent un modèle de déclencheur d’interrogation continue complètement managé par le connecteur. Ce modèle contient le déclencheur qui vérifie constamment les messages dans l’abonnement file d’attente ou rubrique. Les déclencheurs de session suivent le modèle de déclencheur d’interrogation longue, mais sa configuration est régie par le paramètre Azure Functions nommé clientRetryOptions :tryTimeout. La version intégrée offre généralement de meilleures performances, fonctionnalités, conditions tarifaires, et ainsi de suite. |
Pour plus d’informations, consultez la documentation suivante : - Référence du connecteur géré Service Bus - Opérations du connecteur intégré Service Bus - Connecteurs intégrés dans Azure Logic Apps |
Prérequis
Un compte et un abonnement Azure. Si vous n’avez pas d’abonnement Azure, inscrivez-vous pour bénéficier d’un compte Azure gratuit.
Un espace de noms et une entité de messagerie Service Bus, telle une file d’attente. Pour plus d’informations, consultez la documentation suivante :
Le workflow dans lequel vous vous connectez à votre espace de noms Service Bus et l’entité de messagerie. Pour démarrer votre flux de travail avec un déclencheur Service Bus, vous devez commencer par un flux de travail vide. Pour utiliser une action Service Bus dans votre workflow, démarrez votre workflow avec n’importe quel déclencheur.
Si votre ressource d’application logique utilise une identité managée pour authentifier l’accès à votre espace de noms et à votre entité de messagerie Service Bus, assurez-vous que vous avez attribué des autorisations de rôle aux niveaux correspondants. Par exemple, pour accéder à une file d’attente, l’identité managée nécessite un rôle disposant des autorisations nécessaires pour cette file d’attente.
Chaque ressource d’application logique doit utiliser une seule identité managée, même si un workflow de l’application logique accède à différentes entités de messagerie.
Chaque identité managée qui accède à une file d’attente ou à un abonnement de rubrique doit utiliser sa propre connexion d’API Service Bus.
Les opérations Service Bus qui échangent des messages avec diverses entités de messagerie et exigent des autorisations différentes doivent utiliser leur propre connexion d’API Service Bus.
Pour obtenir plus d’informations sur les identités managées, consultez Authentifier l’accès aux ressources Azure avec des identités managées dans Azure Logic Apps.
Par défaut, les opérations du connecteur intégré Service Bus sont sans état. Pour exécuter ces opérations en mode avec état, consultez Activer le mode avec état pour les connecteurs intégrés sans état.
Considérations relatives aux opérations Azure Service Bus
Boucles infinies
Important
Soyez prudent lorsque vous sélectionnez un déclencheur et une action qui ont le même type de connecteur et que vous les utilisez pour travailler avec la même entité, telle qu’une file d’attente de messagerie ou un abonnement à une rubrique. Cette combinaison peut créer une boucle infinie, ce qui aboutit à une application logique dont l’exécution ne se termine jamais.
Limite des sessions enregistrées dans le cache du connecteur
À partir d’un bus de service, le connecteur Service Bus peut enregistrer jusqu’à 1 500 sessions uniques à la fois dans le cache du connecteur, par entité de messagerie Service Bus, comme un abonnement ou une rubrique. Si le nombre de sessions dépasse cette limite, les anciennes sessions sont supprimées du cache. Pour plus d’informations, consultez les sessions de messages.
Envoyer des messages corrélés dans l'ordre
Lorsque vous devez envoyer des messages connexes dans un ordre spécifique, vous pouvez créer un workflow à l’aide du connecteur Service Bus et du modèle de convoi séquentiel. Les messages corrélés possèdent une propriété qui définit la relation qu’ils entretiennent, comme l’ID de la session dans Azure Service Bus.
Lorsque vous créez un workflow d’application logique Consommation, vous pouvez sélectionner le modèle Livraison corrélée dans l’ordre à l’aide de sessions Service Bus, qui implémente le modèle de convoi séquentiel. Pour plus d'informations, consultez Envoyer des messages connexes dans l'ordre.
Prise en charge des messages volumineux
La prise en charge des messages volumineux est disponible uniquement pour les workflows Standard lorsque vous utilisez les opérations de connecteur intégré Service Bus. Par exemple, vous pouvez recevoir et envoyer des messages volumineux à l’aide des déclencheurs et des actions intégrés, respectivement.
Pour le connecteur managé Service Bus, la taille maximale des messages est limitée à 1 Mo, même lorsque vous utilisez un espace de noms Service Bus de niveau Premium.
Augmenter le délai d’expiration pour la réception et l’envoi de messages
Dans les workflows Standard qui utilisent les opérations intégrées Service Bus, vous pouvez augmenter le délai d’expiration pour la réception et l’envoi de messages. Pour recevoir un message, vous pouvez augmenter le délai d’attente en modifiant le paramètre suivant dans l’extension Azure Functions :
{
"version": "2.0",
"extensionBundle": {
"id": "Microsoft.Azure.Functions.ExtensionBundle.Workflows",
"version": "[1.*, 2.0.0)"
},
"extensions": {
"serviceBus": {
"batchOptions": {
"operationTimeout": "00:15:00"
}
}
}
}
Pour augmenter le délai d'expiration d'envoi d'un message, ajoutez le paramètre d'applicationServiceProviders.ServiceBus.MessageSenderOperationTimeout.
Déclencheurs du connecteur géré Service Bus
Pour le connecteur managé Service Bus, tous les déclencheurs sont d’interrogation longue. Ce type de déclencheur traite tous les messages, puis attend 30 secondes que d’autres messages apparaissent dans la file d’attente ou l’abonnement à la rubrique. Si aucun message n’apparaît au bout de 30 secondes, l’exécution du déclencheur est ignorée. Dans le cas contraire, le déclencheur poursuit la lecture des messages jusqu’à ce que la rubrique d’abonnement ou la file d’attente soit vide. La prochaine interrogation de déclencheur est basée sur l’intervalle de récurrence spécifié dans les propriétés du déclencheur.
Certains déclencheurs (par exemple, Quand un ou plusieurs messages arrivent dans une file d’attente (autocomplétion)) peuvent retourner un ou plusieurs messages. Quand ces déclencheurs sont activés, ils retournent entre un et le nombre de messages spécifié par la propriété Nombre maximal de messages du déclencheur.
Remarque
Le déclencheur d’autocomplétion rédige automatiquement un message, mais la saisie semi-automatique se produit uniquement lors de l’appel suivant à Service Bus. Ce comportement peut affecter la conception de votre workflow. Par exemple, évitez de modifier la concurrence sur le déclencheur d’autocomplétion, car cette modification peut entraîner la duplication de messages si votre workflow entre dans un état limité. La modification du contrôle d’accès concurrentiel crée les conditions suivantes :
Les déclencheurs limités sont ignorés avec le code
WorkflowRunInProgress.L’opération d’achèvement ne s’exécutera pas.
L’exécution du déclencheur suivant se produit après l’intervalle d’interrogation.
Vous devez définir la durée de verrouillage du bus de service sur une valeur supérieure à la fréquence d’interrogation. Toutefois, malgré ce réglage, le message peut ne pas être complet si votre workflow reste à un état limité à l’intervalle d’interrogation suivant.
Si vous devez changer la concurrence sur un déclencheur de saisie semi-automatique Service Bus, n’effectuez pas ce changement avant d’avoir initialement enregistré votre workflow. Créez et enregistrez d’abord votre workflow avant de modifier le déclencheur pour changer la concurrence.
Déclencheurs de connecteur intégré Service Bus
Pour le connecteur intégré Service Bus, les déclencheurs non liés à la session suivent un modèle de déclencheur d’interrogation continue complètement managé par le connecteur. Ce modèle contient le déclencheur qui vérifie constamment les messages dans l’abonnement file d’attente ou rubrique. Les déclencheurs de session suivent le modèle de déclencheur d’interrogation longue, avec sa configuration qui est régie par le paramètre Azure Functions nommé clientRetryOptions :tryTimeout. Actuellement, les paramètres de configuration du déclencheur intégré Service Bus sont partagés entre l’extension hôte Azure Functions, qui est définie dans le fichier host.json de votre application logique, et les paramètres de déclencheur définis dans le flux de travail de votre application logique, que vous pouvez configurer via le concepteur ou la vue de code. Cette section couvre les deux emplacements des paramètres.
Dans les flux de travail Standard, certains déclencheurs, tels que le Lorsque les messages sont disponibles dans une file d’attente déclencheur, peuvent retourner un ou plusieurs messages. Lorsque ces déclencheurs se déclenchent, ils renvoient entre un et le nombre de messages. Pour ce type de déclencheur et où le nombre maximal de messages paramètre n’est pas pris en charge, vous pouvez toujours contrôler le nombre de messages reçus à l’aide de la propriété maxMessageBatchSize dans le fichier host.json . Pour trouver ce fichier, consultez Modifier les paramètres de l’hôte et de l’application pour les applications logiques Standard.
"extensions": { "serviceBus": { "maxMessageBatchSize": 25 } }Vous pouvez également activer la simultanéité sur le déclencheur Service Bus, via le concepteur ou dans le code :
"runtimeConfiguration": { "concurrency": { "runs": 100 } }Lorsque vous configurez la simultanéité à l'aide d'un lot, conservez un nombre d'exécutions simultanées supérieur à la taille globale du lot. De cette façon, les messages lus ne passent pas en état d'attente et sont toujours récupérés lorsqu'ils sont lus. Dans certains cas, le déclencheur peut avoir jusqu'à deux fois la taille du lot.
Si vous activez la simultanéité, la limite SplitOn est réduite à 100 éléments. Ce comportement est vrai pour tous les déclencheurs, pas seulement pour le déclencheur Service Bus. Assurez-vous que la taille du lot spécifiée est inférieure à cette limite sur tout déclencheur pour lequel vous activez la simultanéité.
Il existe certains scénarios dans lesquels le déclencheur peut dépasser les paramètres de concurrence. Plutôt que d’échouer ces exécutions, Azure Logic Apps les met en file d’attente jusqu’à ce qu’elles puissent être démarrées. Le paramètre maximumWaitingRuns contrôle le nombre d'exécutions autorisées en état d'attente :
"runtimeConfiguration": { "concurrency": { "runs": 100, "maximumWaitingRuns": 50 } }Avec le déclencheur Service Bus, assurez-vous de tester soigneusement ces modifications afin que les exécutions n’attendent pas plus longtemps que le délai d’expiration du verrouillage des messages. Pour plus d’informations sur les valeurs par défaut, consultez limites de concurrence et de dé-traitement par lot ici.
Si vous activez la simultanéité, un délai de 30 secondes existe par défaut entre les lectures par lots. Ce délai ralentit le déclencheur pour atteindre les objectifs suivants :
Réduisez le nombre d’appels de stockage envoyés pour vérifier le nombre d’exécutions sur lesquelles appliquer la simultanéité.
Imitez le comportement du déclencheur du connecteur géré Service Bus, qui effectue une interrogation de 30 secondes lorsqu’aucun message n’est trouvé.
Vous pouvez modifier ce délai, mais assurez-vous de tester soigneusement toute modification de la valeur par défaut :
"workflow": { "settings": { "Runtime.ServiceProviders.FunctionTriggers.DynamicListenerEnableDisableInterval": "00:00:30" } }
Étape 1 : Vérifier l’accès à l’espace de noms Service Bus
Pour vérifier que votre ressource d’application logique dispose des autorisations nécessaires pour accéder à votre espace de noms Service Bus, procédez comme suit :
Accédez à votre espace de noms Service Bus sur le Portail Azure.
Dans le menu de l’espace de noms, sous Paramètres, sélectionnez Stratégies d’accès partagé. Sous Revendications, vérifiez que vous disposez des autorisations Gérer pour cet espace de noms.
Étape 2 : Obtenir les exigences d’authentification de connexion
Plus tard, lorsque vous ajoutez un déclencheur ou une action Service Bus pour la première fois, vous êtes invité à entrer des informations de connexion, y compris le type d’authentification de connexion. En fonction du type de workflow de votre application logique, de la version du connecteur Service Bus et du type d’authentification sélectionné, vous aurez besoin des éléments suivants :
Authentification par connecteur managé (workflows Consommation et Standard)
| Type d'authentification | Informations requises |
|---|---|
| Clé d’accès | La chaîne de connexion pour votre espace de noms Service Bus. Pour plus d’informations, consultez Obtenir la chaîne de connexion pour l’espace de noms Service Bus |
| Authentification intégrée Microsoft Entra | L’URL du point de terminaison pour votre espace de noms Service Bus. Pour plus d’informations, consultez Obtenir l’URL du point de terminaison pour l’espace de noms Service Bus. |
| Identités managées par applications logiques | L’URL du point de terminaison pour votre espace de noms Service Bus. Pour plus d’informations, consultez Obtenir l’URL du point de terminaison pour l’espace de noms Service Bus. |
Authentification du connecteur intégré (workflow Standard uniquement)
| Type d'authentification | Informations requises |
|---|---|
| Chaîne de connexion | La chaîne de connexion pour votre espace de noms Service Bus. Pour plus d’informations, consultez Obtenir la chaîne de connexion pour l’espace de noms Service Bus |
| OAuth Active Directory | - Nom complet de votre espace de noms Service Bus, par exemple <, votre-espace-de-noms-Service-Bus>.servicebus.windows.net. Pour plus d’informations, consultez Obtenir le nom complet de l’espace de noms Service Bus. Pour découvrir les autres valeurs de propriété, consultez OAuth avec Microsoft Entra ID. |
| Identité gérée | Nom complet de votre espace de noms Service Bus, par exemple <votre-espace-de-noms-Service-Bus>.servicebus.windows.net. Pour plus d’informations, consultez Obtenir le nom complet de l’espace de noms Service Bus. |
Obtenir la chaîne de connexion pour l’espace de noms Service Bus
Pour créer une connexion lorsque vous ajoutez un déclencheur ou une action Service Bus, vous devez disposer de la chaîne de connexion de votre espace de noms Service Bus. La chaîne de connexion commence par le préfixe sb://.
Accédez à votre espace de noms Service Bus sur le Portail Azure.
Dans le menu de l’espace de noms, sous Paramètres, sélectionnez Stratégies d’accès partagé.
Dans le volet Stratégies d’accès partagé, sélectionnez RootManageSharedAccessKey.
En regard de la chaîne de connexion principale ou secondaire, sélectionnez le bouton de copie.
Remarque
Pour vérifier que la chaîne correspond à l’espace de noms, et non à une entité de messagerie spécifique, recherchez le paramètre
EntityPathdans la chaîne de connexion. Si vous trouvez ce paramètre, la chaîne de connexion correspond à une entité spécifique. De fait, il ne s’agit pas de la chaîne appropriée à utiliser avec votre workflow.Enregistrez la chaîne de connexion en vue d’une utilisation ultérieure.
Obtenir l’URL du point de terminaison pour l’espace de noms Service Bus
Si vous utilisez le connecteur managé Service Bus, vous avez besoin de cette URL de point de terminaison si vous sélectionnez l’un ou l’autre type d’authentification pour Microsoft Entra intégré ou Identité managée Logic Apps. L’URL du point de terminaison commence par le préfixe sb://.
Accédez à votre espace de noms Service Bus sur le Portail Azure.
Dans le menu d’espace de noms, sous Paramètres, sélectionnez Propriétés.
Sous Propriétés, en regard de l'point de terminaison Service Bus, copiez l’URL du point de terminaison et enregistrez-la pour une utilisation ultérieure lorsque vous devez fournir l’URL du point de terminaison Service Bus.
Obtenir un nom complet pour l’espace de noms Service Bus
Accédez à votre espace de noms Service Bus sur le Portail Azure.
Dans le menu de l’espace de noms, sélectionnez Vue d’ensemble.
Dans le volet Vue d’ensemble, recherchez la propriété Nom d’hôte et copiez le nom complet, qui ressemble à <votre-espace-de-noms-Service-Bus>.servicebus.windows.net.
Étape 3 : Option 1 - Ajouter un déclencheur Service Bus
Les étapes suivantes utilisent le portail Azure, mais avec l’extension Azure Logic Apps appropriée, vous pouvez également utiliser les outils suivants pour créer des flux de travail d’application logique :
- Workflows de consommation : Visual Studio Code
- Workflow Standard : Visual Studio Code
Dans le portail Azure, ouvrez votre ressource d’application logique Consommation avec un workflow vide dans le concepteur.
Dans le concepteur, suivez ces étapes générales pour ajouter le déclencheur Azure Service Bus souhaité.
Cet exemple continue avec le déclencheur nommé Quand une file d’attente reçoit un message (saisie semi-automatique)
Si vous y êtes invité, fournissez les informations suivantes pour votre connexion. Sélectionnez Créer lorsque vous avez terminé.
Propriété Obligatoire Description Nom de connexion Oui Nom de votre connexion Type d’authentification Oui Type d’authentification à utiliser pour accéder à votre espace de noms Service Bus. Pour plus d’informations, consultez Authentification du connecteur managé. Chaîne de connexion Oui Chaîne de connexion que vous avez copiée et enregistrée précédemment. Par exemple, cette connexion utilise l’authentification par clé d’accès et fournit la chaîne de connexion pour un espace de noms Service Bus :
Une fois que la zone d’informations du déclencheur s’affiche, fournissez les informations nécessaires, par exemple :
Propriété Obligatoire Description Nom de la file d’attente Oui File d’attente sélectionnée à laquelle accéder Type de file d'attente Non Type de la file d’attente sélectionnée How often do you want to check for items? (À quelle fréquence souhaitez-vous rechercher des éléments ?) Oui Intervalle et fréquence d’interrogation pour vérifier les éléments de la file d’attente 
Pour ajouter toutes autres propriétés disponibles au déclencheur, ouvrez la liste Ajouter un nouveau paramètre, puis sélectionnez les propriétés souhaitées.
Ajoutez toutes les actions dont votre workflow a besoin.
Par exemple, vous pouvez ajouter une action qui envoie un e-mail lorsqu’un nouveau message arrive. Lorsque votre déclencheur vérifie la file d’attente et trouve un nouveau message, votre workflow exécute les actions que vous avez sélectionnées pour le message trouvé.
Lorsque vous avez terminé, enregistrez votre flux de travail. Dans la barre d’outils du Concepteur, sélectionnez Enregistrer.
Étape 3 : Option 2 - Ajouter une action Service Bus
Les étapes suivantes utilisent le Portail Azure, mais avec l’extension Azure Logic Apps appropriée, vous pouvez également utiliser les outils suivants pour créer des workflows d’application logique :
- Workflows de consommation : Visual Studio Code
- Workflow Standard : Visual Studio Code
Sur le portail Azure, ouvrez votre workflow d’application logique Consommation dans le concepteur.
Dans le concepteur, suivez ces étapes générales pour ajouter l’action Azure Service Bus souhaitée.
Cet exemple continue avec l’action Envoyer un message.
Si vous y êtes invité, fournissez les informations suivantes pour votre connexion. Sélectionnez Créer lorsque vous avez terminé.
Propriété Obligatoire Description Nom de connexion Oui Nom de votre connexion Type d’authentification Oui Type d’authentification à utiliser pour accéder à votre espace de noms Service Bus. Pour plus d’informations, consultez Authentification du connecteur managé. Chaîne de connexion Oui Chaîne de connexion que vous avez copiée et enregistrée précédemment. Par exemple, cette connexion utilise l’authentification par clé d’accès et fournit la chaîne de connexion pour un espace de noms Service Bus :
Une fois que la zone d’informations de l’action s’affiche, fournissez les informations nécessaires, par exemple :
Propriété Obligatoire Description Nom de la file d’attente/rubrique Oui La file d’attente ou la destination de rubrique sélectionnée pour l’envoi du message ID de session Non ID de session si vous envoyez le message à une file d’attente ou une rubrique sensible à la session Propriétés système Non - Aucun
- Détails de l’exécution : Ajoutez des informations de propriétés de métadonnées sur l’exécution en tant que propriétés personnalisées dans le message.
Pour ajouter toutes autres propriétés disponibles à l’action, ouvrez la liste Ajouter un nouveau paramètre, puis sélectionnez les propriétés souhaitées.
Ajoutez toutes les autres actions dont votre flux de travail a besoin.
Par exemple, vous pouvez ajouter une action qui envoie un e-mail confirmant que votre message a bien été envoyé.
Lorsque vous avez terminé, enregistrez votre flux de travail. Dans la barre d’outils du Concepteur, sélectionnez Enregistrer.
Paramètres de l’application connecteur intégrée
Dans une ressource d’application logique Standard, le connecteur intégré Service Bus inclut des paramètres d’application qui contrôlent différents seuils, comme le délai d’attente pour l’envoi de messages et le nombre d’expéditeurs de messages par cœur de processeur dans le pool de messages. Pour plus d’informations, consultez Référence sur les paramètres d’application - local.settings.json.
Lire des messages à partir de files d’attente de lettres mortes avec des déclencheurs intégrés Service Bus
Dans les workflows Standard, pour lire un message à partir d’une file d’attente de lettres mortes dans une file d’attente ou un abonnement à une rubrique, effectuez ces étapes à l’aide des déclencheurs spécifiés :
Dans votre workflow vide, en fonction de votre scénario, ajoutez le déclencheur de connecteur intégré Service Bus nommé Lorsque des messages sont disponibles dans une file d’attente ou Lorsque des messages sont disponibles dans un abonnement à une rubrique (PeekLock).
Dans le déclencheur, définissez les valeurs de paramètres suivantes pour spécifier la file d’attente ou la file d’attente de lettres mortes par défaut de votre abonnement à la rubrique, à laquelle vous pouvez accéder comme n’importe quelle autre file d’attente :
Déclencheur Lorsque des messages sont disponibles dans une file d’attente : définissez le paramètre Nom de la file d’attente sur queuename/$deadletterqueue.
Déclencheur Lorsque des messages sont disponibles dans un abonnement à une rubrique (PeekLock) : définissez le paramètre Nom de la rubrique sur topicname/Subscriptions/subscriptionname/$deadletterqueue.
Pour plus d’informations, consultez Vue d’ensemble des files d’attente de lettres mortes Service Bus.
Dépannage
Retards dans l’entrée en vigueur des mises à jour de votre workflow
Si l’intervalle d’interrogation d’un déclencheur Service Bus est faible, par exemple 10 secondes, les mises à jour de votre workflow peuvent ne pas prendre effet avant 10 minutes. Pour contourner ce problème, vous pouvez désactiver la ressource d’application logique, effectuer les modifications, puis réactiver la ressource.
Pas de session disponible ou susceptible d’être verrouillée par un autre récepteur
Occasionnellement, des opérations comme terminer un message ou renouveler une session produisent l’erreur suivante :
{
"status": 400,
"error": {
"message": "No session available to complete the message with the lock token 'ce440818-f26f-4a04-aca8-555555555555'."
}
}
Parfois, un déclencheur basé sur une session peut échouer avec l’erreur suivante :
{
"status": 400,
"error": {
"message": "Communication with the Service Bus namespace 'xxxx' and 'yyyy' entity failed. The requested session 'zzzz' cannot be accepted. It may be locked by another receiver."
}
}
Le connecteur Service Bus utilise le cache en mémoire pour prendre en charge toutes les opérations associées aux sessions. Le récepteur de messages Service Bus est mis en cache dans la mémoire de l’instance de rôle (machine virtuelle) qui reçoit les messages. Pour traiter toutes les requêtes, tous les appels pour la connexion sont routés vers cette même instance de rôle. Ce comportement est nécessaire, car toutes les opérations Service Bus d’une session nécessitent le même récepteur qui reçoit les messages pour une session spécifique.
Pour des raisons comme une mise à jour de l’infrastructure, un déploiement de connecteur, etc., la possibilité existe que des requêtes ne soient pas routées vers la même instance de rôle. Si cet événement se produit, les requêtes échouent pour une des raisons suivantes :
Le récepteur qui effectue les opérations dans la session n’est pas disponible dans l’instance de rôle qui traite la requête.
La nouvelle instance de rôle tente d’obtenir la session, qui a expiré dans l’ancienne instance de rôle ou qui n’a pas été fermée.
Tant que cette erreur se produit seulement de façon occasionnelle, l’erreur est normale. Quand l’erreur se produit, le message est néanmoins toujours conservé dans Service Bus. L’exécution suivante du déclencheur ou du workflow tente à nouveau de traiter le message.