Transactions atomiques
Vous pouvez concevoir les orchestrations BizTalk de sorte qu'elles exécutent des tâches discrètes, selon le concept 'ACID' classique d'une transaction. Ces unités de travail discrètes ou atomiques, quand elles sont exécutées, permettent de faire passer le processus d'entreprise d'un état cohérent à un autre état, nouveau, cohérent et durable, qui se trouve isolé des autres unités de travail. Cette opération est généralement effectuée à l’aide de la construction Scope qui encapsule les unités de travail avec la sémantique transactionnelle. Vous pouvez également définir l'orchestration complète en tant que transaction atomique sans utiliser d'étendues. Les étendues ne peuvent toutefois être transactionnelles que si l'orchestration elle-même est de type transaction atomique ou à long terme. Les transactions atomiques garantissent que les mises à jour partielles sont automatiquement annulées en cas d'échec lors de la mise à jour transactionnelle et que les effets de la transaction sont effacés (à l'exception des effets des appels .NET effectués dans la transaction). Les transactions atomiques des orchestrations BizTalk sont similaires aux transactions DTC (distributed transaction coordinator) dans le sens où elles sont généralement de courte durée et où elles possèdent les quatre attributs « ACID » (atomicité, cohérence, isolation et durabilité) :
Atomicité
Une transaction représente une unité de travail atomique. Toutes les modifications d'une transaction sont appliquées, ou aucune d'entre elles.
Cohérence
La validation d'une transaction ne doit pas altérer l'intégrité des données d'un système. Si des modifications sont apportées par une transaction dans une base de données jugée cohérente en interne avant le début de la transaction, il faut que la base de données conserve sa cohérence une fois la transaction validée. C'est essentiellement au développeur d'applications qu'il revient de garantir cette propriété.
Isolement
Les modifications apportées par des transactions simultanées doivent être isolées des modifications effectuées par d'autres transaction simultanées. Les transactions isolées s'exécutant simultanément procèdent à des modifications qui préservent la cohérence interne de la base de données de la même façon que si elles étaient exécutées en série.
Durabilité
Après la validation d'une transaction, toutes les modifications demeurent définitivement en place par défaut dans le système. Les modifications sont conservées même en cas de défaillance du système.
Les niveaux d'isolation suivants sont pris en charge par les transactions atomiques utilisées dans les orchestrations BizTalk :
Lecture validée
Les verrous partagés sont conservés pendant la lecture des données afin d'éviter tout défaut de lecture, mais les données peuvent être modifiées avant la fin de la transaction, entraînant ainsi des données fantômes ou des lectures qui ne peuvent pas être répétées.
Lecture renouvelée
Des verrous sont placés sur toutes les données utilisées dans une requête afin d’empêcher d’autres utilisateurs de mettre à jour les données. Cette opération permet d'empêcher les lectures non renouvelées, mais les lignes fantômes sont toujours possibles.
Sérialisable
Un verrou de plage est placé afin d'empêcher les autres utilisateurs de mettre à jour ou d'insérer des lignes dans la base de données avant la fin de la transaction.
BizTalk Server veille à ce que les modifications d'état apportées au sein d'une transaction atomique, telles que les modifications de variables, de messages et d'objets, ne soient visibles hors de l'étendue de la transaction atomique qu'après la validation de la transaction. Les modifications d'état intermédiaires sont isolées des autres parties d'une orchestration.
Notes
Si une transaction atomique contient une forme De réception , une forme d’envoi ou une forme d’orchestration de démarrage , les actions correspondantes n’ont pas lieu tant que la transaction n’est pas validée.
Si des propriétés ACID complètes sont exigées pour les données, par exemple, si les données doivent être isolées des autres transactions, vous devez uniquement faire appel aux transactions atomiques.
Lors de l'échec d'une transaction atomique, tous les états sont réinitialisés comme si l'instance d'orchestration n'avait jamais été dans l'étendue. La règle BizTalk sur les transactions atomiques veut que toutes les variables (et pas seulement les variables locales à l'étendue) participent à la transaction. Toutes les variables non sérialisables et les messages utilisés dans une transaction atomique doivent être déclarés locaux à l'étendue, faute de quoi, le compilateur génère une erreur de type « la variable….n'est pas marquée comme sérialisable ». Toutes les étendues atomiques sont supposées être « synchronisées » et le compilateur d'orchestration génère un avertissement en cas d'utilisation redondante si le mot clé synchronisé est vraiment employé pour les étendues atomiques. Le domaine de synchronisation des données partagées s'étend du début de l'étendue jusqu'à l'achèvement complet de cette dernière (persistance de l'état, à la fin de l'étendue, incluse) ou jusqu'à la fin du gestionnaire d'exceptions (en cas d'erreurs). Il ne s'étend pas jusqu'au gestionnaire de compensation.
Il est possible d'associer les transactions atomiques à des délais d'expiration, de sorte que l'orchestration arrête la transaction et suspend l'instance. Si une transaction atomique contient une forme Réception, Envoi ou Démarrer orchestration, les actions correspondantes n'auront lieu qu'après la validation de la transaction.
Une transaction atomique retente lorsque l’utilisateur lève délibérément une exception RetryTransactionException ou si une persistenceException est déclenchée au moment où la transaction atomique tente de valider. Ce dernier cas peut se produire lorsque la transaction atomique fait partie d'une transaction DTC distribuée et qu'un des autres participants met fin à la transaction, par exemple. De même, s’il y avait des problèmes de connectivité de base de données au moment où la transaction tentait de valider, une persistanceException serait également déclenchée. Si cela se produit pour une étendue atomique qui a Retry=True, elle effectue une nouvelle tentative jusqu’à 21 fois. L'intervalle entre chaque nouvelle tentative est, par défaut, de deux secondes, mais vous pouvez changer cette valeur. Une fois que 21 nouvelles tentatives sont épuisées, si la transaction ne peut toujours pas être validée, l’ensemble du instance d’orchestration est suspendu. Vous pouvez la reprendre manuellement, auquel cas le cycle complet redémarre avec un compteur réinitialisé au début de l'étendue atomique problématique.
Notes
Seules retryTransactionException et PersistenceException peuvent provoquer une nouvelle tentative d’étendue atomique. Toute autre exception levée dans une étendue atomique ne peut pas provoquer une nouvelle tentative, même si la propriété Retry a la valeur True. Le délai par défaut de deux secondes entre chaque nouvelle tentative consécutive peut être remplacé à l’aide d’une propriété publique sur RetryTransactionException (s’il s’agit de l’exception utilisée pour provoquer les nouvelles tentatives).
Les étendues atomiques ont des restrictions sur l’imbrication d’autres transactions qui ne peuvent pas imbriquer d’autres transactions ou inclure des blocs Catch - Exception .
Transactions DTC
Les transactions atomiques ont beau se comporter comme des transactions DTC, elles n'en sont pas par défaut. Vous pouvez les rendre DTC de manière explicite, à condition que les objets utilisés dans les transactions soient des objets COM+ dérivés de System.EnterpriseServices.ServicedComponents, et que les niveaux d'isolation des composants de transaction soient compatibles.
Notes
Une transaction atomique ne peut pas contenir d'autres transactions en son sein, de même qu'elle ne peut contenir de gestionnaires d'exception.
Notes
Une transaction atomique ne peut pas contenir d'actions d'envoi et de réception correspondantes, à savoir une paire requête-réponse ou des actions d'envoi et de réception se servant du même ensemble de corrélations.
Objets non sérialisables
Pour utiliser un objet non sérialisable dans une orchestration, il vous faut le faire au sein d'une transaction atomique. Toute utilisation d'objet non sérialisable hors d'une transaction atomique risque d'entraîner la perte de données chaque fois que l'orchestration est conservée par le moteur.
Attention
Chaque étendue atomique représente un point de persistance. En d'autres termes, l'état de l'orchestration est enregistré dans la base de données au niveau de chaque point de persistance. Une utilisation fréquente de l'étendue atomique augmente la latence dans l'orchestration. Au lieu d'avoir recours à l'étendue atomique pour la création d'objets non sérialisables, utilisez la méthode Static qui ne requiert aucune étendue atomique, supprimant ainsi la nécessité des points de persistance.
Voir aussi
Scénarios utilisant des transactions atomiques
Transactions de longue durée