Série de conférences ASP (21) Création de scripts transactionnels
Auteur：Eve Cole
Date de mise à jour：2009-05-30 19:58:32
Les applications métier nécessitent souvent la possibilité d'exécuter des scripts et des composants au sein des transactions. Une transaction est une opération de serveur Même si l'opération comprend de nombreuses étapes (par exemple, commander, vérifier l'inventaire, payer les factures, etc.), elle ne peut renvoyer que le succès ou l'échec global de l'opération. Les utilisateurs peuvent créer des scripts ASP qui s'exécutent dans une transaction. Si une partie du script échoue, la transaction entière se terminera.
Le traitement des transactions ASP est basé sur Microsoft Transaction Server (MTS). Microsoft Transaction Server (MTS) est un système de traitement des transactions permettant de développer, de configurer et de gérer des applications serveur Internet et Intranet d'entreprise hautes performances, évolutives et robustes. Transaction Server fournit un modèle de conception d'applications pour développer des applications distribuées basées sur des composants. Il fournit également un environnement d'exécution pour configurer et gérer ces applications.
La possibilité de créer des scripts transactionnels est intégrée à Internet Information Server et à Personal Web Server. Si Microsoft Transaction Server est installé, vous pouvez empaqueter les composants afin qu'ils s'exécutent dans une transaction.
À propos des transactions Une transaction est le succès ou l'échec global d'une opération. Le traitement des transactions est utilisé pour mettre à jour la base de données de manière fiable. Lorsque vous apportez de nombreuses modifications connexes à une base de données ou mettez à jour plusieurs bases de données simultanément, assurez-vous que toutes les modifications sont exécutées correctement. Si l'une de ces modifications échoue, l'état d'origine des tables de base de données doit être restauré.
Sans MTS, vous auriez besoin d'écrire des scripts et des composants pour suivre manuellement les modifications demandées afin de récupérer les données en cas d'échec de certaines modifications. En utilisant MTS, vous déclarez simplement vos scripts et composants comme « nécessitant des transactions » et laissez MTS gérer la cohérence transactionnelle. Le traitement des transactions s'applique uniquement à l'accès à la base de données ; MTS ne peut pas récupérer les modifications apportées au système de fichiers ou à d'autres ressources non transactionnelles. La base de données accessible par l'application doit être prise en charge par MTS. Actuellement, MTS prend en charge SQL Server et tout serveur prenant en charge le protocole XA (spécifié par l'association X/Open). MTS continuera d'étendre la prise en charge d'autres bases de données.
Les transactions ne peuvent pas s'étendre sur plusieurs pages ASP. Si une transaction nécessite des objets provenant de plusieurs composants, les opérations qui utilisent ces objets doivent être combinées dans une page ASP. Par exemple, supposons que vous disposiez d'un composant qui met à jour une base de données de paie et d'un composant qui met à jour les enregistrements des employés dans une base de données de ressources humaines. Afin d'enregistrer de nouvelles informations salariales pour un employé, vous devez écrire un script qui appelle ces deux composants dans un contexte de transaction, l'un pour mettre à jour la base de données de paie et l'autre pour mettre à jour le grade de l'employé dans la base de données des ressources humaines.
Déclaration de scripts transactionnels Lorsque vous déclarez une page comme transactionnelle, toutes les commandes de script et tous les objets de la page s'exécutent dans le même environnement de transaction. Transaction Server gère les détails de la génération des transactions et détermine si la transaction réussit (valide) ou échoue (se termine). Pour déclarer une page comme transactionnelle, ajoutez la directive @TRANSACTION en haut de la page :
<%@ TRANSACTION = valeur %>
Le paramètre value peut être l’un des éléments suivants :
valeur signification
Requires_New démarre une nouvelle transaction.
Obligatoire démarre une nouvelle transaction.
Pris en charge ne démarre pas de transaction.
Not_Supported Ne démarre pas la transaction.
La directive @TRANSACTION doit être sur la première ligne d'une page, sinon une erreur sera générée. Cette directive doit être ajoutée à chaque page qui doit s'exécuter dans le cadre d'une transaction. Lorsque le traitement du script se termine, la transaction en cours se termine.
La plupart des applications nécessitent un environnement de transaction uniquement pour certaines opérations. Par exemple, le site d'une compagnie aérienne peut nécessiter uniquement des scripts transactionnels pour gérer la billetterie et la disposition des sièges, tandis que tous les autres scripts peuvent s'exécuter en toute sécurité sans environnement transactionnel. Étant donné que les transactions ne doivent être utilisées que pour les pages nécessitant un traitement de transaction, ne déclarez pas le fichier Global.asa de votre application comme étant transactionnel.
Si une transaction est abandonnée, Transaction Server annule toutes les modifications apportées aux ressources basées sur la transaction. Actuellement, seuls les serveurs de bases de données prennent entièrement en charge les transactions, car les données de la base de données sont les plus critiques pour les applications d'entreprise. Transaction Server ne restaure pas les modifications apportées aux fichiers, aux variables de session et d'application, aux collections, etc. sur le disque dur. Toutefois, vous pouvez créer un script de restauration de variables et de collections en écrivant des événements de transaction, comme décrit dans la rubrique suivante. À certains moments, votre script peut également explicitement valider ou mettre fin à une transaction, par exemple lorsque l'écriture de données dans un fichier échoue.
Valider ou terminer des scripts Étant donné que Transaction Server assure le suivi du traitement des transactions, il détermine si la transaction a complètement réussi ou échoué. Un script peut mettre fin explicitement à une transaction en appelant ObjectContext.SetAbort. Par exemple, un script doit mettre fin à une transaction lorsqu'il reçoit un message d'erreur d'un composant, viole les spécifications commerciales (par exemple, le solde d'un compte est inférieur à 0) ou échoue pour des opérations non transactionnelles telles que la lecture et l'écriture de fichiers. Si la page expire avant que la transaction ne soit terminée, la transaction doit également être terminée.
L'écriture de scripts d'événements de transaction ne détermine pas à elle seule si une transaction réussit ou échoue. Cependant, vous pouvez écrire des événements appelés lorsqu'une transaction est validée ou terminée. Par exemple, si vous disposez d'un script qui confirme un compte bancaire et que vous devez renvoyer différentes pages à l'utilisateur pour différents états de la transaction, vous pouvez utiliser les événements OnTransactionCommit et OnTransactionAbort pour écrire différentes réponses à l'utilisateur.
<%@ TRANSACTION = Obligatoire %>
<%
'Sortie tampon pour que différentes pages puissent être affichées.
Réponse.Buffer = True
%>
<HTML>
<CORPS>
<H1>Bienvenue sur le service bancaire en ligne</H1>
<%
Définir BankAction = Server.CreateObject("MyExample.BankComponent")
BankAction.Deposit(Request("AcctNum"))
%>
<P>Merci. Votre transaction est en cours de traitement.</P>
</CORPS>
</HTML>
<%
' Afficher cette page si la transaction réussit.
SubOnTransactionCommit()
Réponse.Écrivez "<HTML>"
Réponse.Écrivez "<BODY>"
Réponse.Écrivez "Merci. Votre compte a été crédité."
Réponse.Écrivez "</BODY>"
Réponse.Écrivez "</HTML>"
Réponse.Flush()
fin du sous
%>
<%
' Afficher cette page si la transaction échoue.
SubOnTransactionAbort()
Réponse.Clear()
Réponse.Écrivez "<HTML>"
Réponse.Écrivez "<BODY>"
Réponse.Écrivez « Nous ne sommes pas en mesure de finaliser votre transaction. »
Réponse.Écrivez "</BODY>"
Réponse.Écrivez "</HTML>"
Réponse.Flush()
Fin du sous-marin
%>
Enregistrement d'un composant dans le gestionnaire de ressources MTS Afin de participer à une transaction, le composant doit être enregistré dans le package MTS et doit être configuré pour exiger des transactions. Par exemple, si votre script gère les commandes en appelant deux composants, l'un met à jour la base de données d'inventaire et l'autre met à jour la base de données de paiements. Ensuite, ces deux composants doivent s'exécuter dans le même environnement de transaction. Transaction Server garantit qu'en cas de défaillance d'un composant, aucune base de données ne sera mise à jour. Certains composants ne nécessitent pas de transactions ; par exemple, le composant Ad Rotator.
Enregistrez et configurez les composants transactionnels à l'aide de MTS Resource Manager. Les propriétés de la transaction doivent être définies sur Exiger une transaction ou Exiger une nouvelle transaction. Les composants de la transaction doivent être enregistrés dans le package MTS. Plutôt que de placer des composants dans des packages IIS en cours, créez vos propres packages. En règle générale, tous les composants doivent être placés dans une bibliothèque de composants. Les composants de la bibliothèque de composants peuvent être utilisés par plusieurs applications ASP et exécutés dans le processus d'application ASP. Utilisez MTS Explorer pour créer un nouveau package et définissez la propriété d'activation du package sur Bibliothèque.
Les composants transactionnels peuvent également être enregistrés dans le package Serveur. Les packages serveur s'exécutent généralement en tant que processus distinct sur le serveur. Si vous souhaitez utiliser la vérification de sécurité basée sur les groupes fonctionnels ou si vous souhaitez que vos composants soient accessibles aux applications sur des ordinateurs distants, utilisez le package Serveur pour les composants transactionnels.
Pour utiliser MTS Explorer, Microsoft Transaction Server doit être installé.
Portée de l'objet En général, ne stockez pas les objets créés à partir de composants MTS dans des objets d'application ou de session ASP. Les objets MTS disparaissent une fois la transaction terminée. Étant donné que l'objet Session et l'objet Application sont conçus pour des instances d'objet utilisées entre différentes pages ASP, ne les utilisez pas pour stocker des objets libérés à la fin d'une transaction.
Le script ASP est la racine de la transaction déclarée, le point de départ. Tout objet MTS utilisé par une page ASP transactionnelle est considéré comme faisant partie de la transaction. Une fois la transaction terminée, les objets MTS utilisés dans la page disparaîtront, y compris les objets stockés dans l'objet Session ou Application. Après ce point, toute tentative d’appel d’un objet de portée session ou d’application à partir d’une autre page transactionnelle échouera.
Mise en file d'attente des transactions Les mises à jour d'une base de données à partir d'un serveur distant peuvent entraîner le retard ou l'arrêt des transactions en raison de retards ou de pannes du réseau. Étant donné que toutes les parties de la transaction doivent être validées, l'application peut se bloquer en attendant un message de validation ou d'abandon du serveur distant, ou la transaction peut être abandonnée car les mises à jour de la base de données ne peuvent pas être envoyées.
Pour les mises à jour qui doivent être effectuées simultanément, l'approche correcte consiste à mettre fin à la transaction ou à retarder l'achèvement de la transaction jusqu'à ce que tous les participants à la transaction soient en mesure de s'engager. Par exemple, le processus de réservation d'une compagnie aérienne doit simultanément débiter le compte bancaire du client et créditer le compte bancaire de la compagnie aérienne. Si une mise à jour fait partie d'une transaction globale, mais peut être postérieure à d'autres mises à jour, vous ne souhaiterez peut-être pas faire attendre le client jusqu'à la fin du processus de mise à jour. Par exemple, une transaction de réservation de vol peut également envoyer une commande de nourriture à un fournisseur de produits alimentaires ou mettre à jour l'indemnité de déplacement d'un client. Même si ces opérations doivent être réalisées, elles peuvent être réalisées ultérieurement.
Microsoft Message Queue Server vous permet de regrouper une mise à jour ou un ensemble de mises à jour dans un message transactionnel envoyé à un serveur distant. Message Queue Server garantit que les mises à jour seront envoyées au serveur distant même si le réseau est actuellement indisponible. Votre application recevra un message de validation et pourra continuer à traiter la transaction.
