Dans une transaction distribuée Azure, quelle est la meilleure approche pour annuler l'opération complète en cas d'échec d'un appel http?

Question

J'ai une application api Azure (AzureApi1) qui comporte une action dans laquelle plusieurs requêtes http sont effectuées. L'opération insère des données dans plusieurs tables dans un Azure Sql Db.

Il effectue ensuite un appel API externe (ExApi) à partir du même code. En utilisant les résultats de l'appel externe, il insère/met à jour d'autres tables. Ce n'est pas dans Azure.

Ensuite, il appelle une autre API (AzureApi2) qui se trouve dans le même groupe de ressources que le premier et qui insère des données dans un autre DQ Azure Sql qui se trouve également dans le même groupe de ressources.

J'ai utilisé TransactionScope dans AzureApi1 et AzureApi2 qui fonctionne bien pour eux individuellement. Cependant, comme il y a une API externe entre les deux et qui n'est pas sous mon contrôle, en cas de défaillance de cet appel API, je dois annuler l'opération complète. Actuellement, la première API est en train de revenir correctement, car le deuxième appel API est un appel http différent, il ne tombe pas avec la portée de la transaction du premier. J'ai besoin d'une approche pour annuler les données de la seconde base de données Sql en cas de défaillance.

Quelle est la meilleure option pour reculer manuellement dans une situation comme celle-ci?

Answer 1

Pour une transaction distribuée entre plusieurs bases de données SQL Azure, vous pouvez utiliser elastic database transactions. Mais les transactions de base de données élastiques ne peuvent pas s'étendre sur les bases de données SQL Server et Azure SQL. Vous devez créer votre propre coordinateur de transactions distribuées pour cette situation.

Je vous suggère de créer une nouvelle API Web qui fonctionne comme un coordinateur pour surveiller l'état de toutes les opérations. Les étapes peuvent être comme suit,

1. Si une opération est en panne, elle doit envoyer un message (succès ou échec) au coordinateur.

2. Si toutes les opérations sont terminées, le coordinateur enverra un message (commit ou rollback) à toutes les opérations. Le message dépend de tous les messages reçus de chaque opération. Chaque opération validera les modifications et enverra le résultat de la validation (succès ou échec) au coordinateur.

3. Le coordinateur enverra l'état final à chaque opération en fonction du résultat de validation reçu à chaque opération.

4. Nous pourrions ajouter un délai d'attente pour ces communications. Si le délai d'attente est arrivé, nous devons annuler toute l'opération.