Paramètres du service de transaction

Cette page permet de définir les paramètres du service Transactions. Le service Transactions est un composant d'exécution du serveur qui peut coordonner les mises à jour sur plusieurs gestionnaires de ressources pour assurer la mise à jour atomique des données. Les transactions sont lancées et arrêtées par les applications ou le conteneur dans lequel les applications sont déployées.

Pour afficher cette page de la console administrative, cliquez sur Serveurs > Types de serveurs > WebSphere application servers > nom_serveur > [Paramètres du conteneur] Services du conteneur > Service de transaction.

Répertoire du journal des transactions

Indique le nom d'un répertoire pour le serveur où le service Transactions stocke les fichiers de journalisation pour la reprise. En option, vous pouvez indiquer la taille des fichiers de journaux de transaction. Pour la plateforme z/OS, définit l'emplacement du journal de partenaire JTA.

Définissez cette propriété pour changer le répertoire du fichier journal des transactions d'un serveur d'applications uniquement si les applications utilisent des ressources distribuées ou des transactions XA, par exemple lorsqu'une même transaction accède à plusieurs bases de données et ressources.

Définissez cette propriété pour changer le répertoire du fichier journal des transactions d'un serveur d'applications dans l'une des situations suivantes :
  • Si les applications utilisent des ressources distribuées ou des transactions XA ; par exemple, lorsqu'une même transaction accède à plusieurs bases de données et ressources.
  • Si vous configurez le système pour une haute disponibilité des transactions. Dans ce cas, le répertoire du journal des transactions doit être unique pour chaque serveur du cluster et tous les serveurs du cluster doivent pouvoir y accéder.

    Dans un environnement à haute disponibilité, les répertoires du journal des transactions et du journal de compensation de chaque serveur d'un cluster doivent être uniques.

Si vous n'indiquez pas ce répertoire pendant la configuration du serveur, le service de transaction utilise un répertoire par défaut fondé sur le répertoire d'installation : racine_serveur_app/ tranlog/nom_cellule/nom_noeud/nom_serveur.

Lorsqu'une application exécutée sur WebSphere Application Server a accès à plusieurs ressources, le serveur d'applications stocke les informations sur la transaction dans le répertoire du produit afin de coordonner et de gérer correctement la transaction distribuée. Quand la charge de transaction est plus élevée, le stockage des informations persistantes peut ralentir considérablement les performances du serveur d'applications, car ce dernier est tributaire du système d'exploitation et des systèmes de stockage sous-jacents. Pour de meilleures performances, indiquez un nouveau répertoire pour les fichiers journaux sur un système de stockage distinct, physiquement plus grand.

Si votre serveur d'applications présente un ou plusieurs des symptômes suivants, changez le répertoire du journal des transactions :
  • L'utilisation de l'unité centrale reste faible malgré l'augmentation du nombre de transactions
  • Les transactions échouent après plusieurs dépassements du délai d'expiration.
  • Des transactions sont annulées en raison de l'exception "échec de l'inscription de la transaction".
  • Le serveur d'applications se bloque en plein milieu d'une exécution et doit être redémarré
  • Le disque sur lequel le serveur d'applications s'exécute présente une plus grande activité
Voici les recommandations qui s'appliquent pour le système de stockage des fichiers journaux :
  • Stockez les fichiers journaux sur un réseau redondant de disques indépendants (RAID).

    Dans les configurations RAID, la tâche qui consiste à enregistrer des données sur un support physique est partagée entre plusieurs unités. Cette technique permet un nombre plus élevé d'accès simultanés pour la conservation des informations relatives aux transactions et un accès plus rapide à ces données dans les journaux. Selon la conception de l'application et du sous-système de stockage, une optimisation de 10 à 100 % des performances peut être obtenue dans plusieurs cas.

  • Ne stockez pas les fichiers journaux avec le mode d'E-S du système d'exploitation associé à la valeur CIO (E-S simultanée).

    Lorsque vous définissez un répertoire pour le journal des transactions, vérifiez que le système de fichiers utilise uniquement des opérations d'écriture immédiate et de sérialisation d'écriture synchrones. Certains systèmes d'exploitation tels qu'AIX JFS2 prennent en charge un mode CIO (E-S simultanée) facultatif où le système de fichiers n'applique pas la sérialisation des opérations d'écriture. N'utilisez pas le mode CIO pour les fichiers journaux de reprise de transaction du serveur d'applications sur ces systèmes.

Pour indiquer la taille des fichiers journaux de transaction, précisez la taille des fichiers. Utilisez l'un des formats suivants, où nom_répertoire est le nom du répertoire de journal de transaction et taille_fichier est la nouvelle allocation d'espace du disque pour les fichiers journaux de transactions mesurée en ko (nK) ou Mo (nM). La taille minimale de fichier journal des transactions que vous pouvez spécifier est 64 ko. Si vous spécifiez une valeur inférieure à 64 ko ou si vous ne spécifiez pas de valeur, la valeur par défaut de 1 Mo est utilisée.

;file_size   <!-- Ce format maintient le répertoire par défaut -->
directory_name;file_size
dir://directory_name/directory_name;file_size
/directory_name/directory_name;file_size

[AIX Solaris HP-UX Linux Windows] [iSeries] Pour plus d'informations sur les tailles des journaux des transactions, voir Gestion de la journalisation des transactions pour une disponibilité optimale du serveur.

Type de données Chaîne
Valeur par défaut Nom du répertoire : racine_serveur_app/tranlog/nom_cellule/nom_noeud/nom_serveur

Taille du fichier : 1 Mo

Recommandé Créez un système de fichiers comportant au moins trois ou quatre unités de disque reliées entre elles par une configuration RAID-0. Créez ensuite le journal des transactions sur ce système de fichiers en lui affectant la taille par défaut. Lorsque le serveur traite une charge de travail, vérifiez les entrées et sorties des disques. Si la durée des entrées et sorties des disques est supérieure à 5 %, il est conseillé d'ajouter davantage de disques pour réduire ce pourcentage.

Sous z/OS, ce journal est utilisé pour la récupération des ressources XA. Lorsque l'application exécutée dans WebSphere accède à des ressources XA, WebSphere stocke les informations sur la ressource pour permettre la récupération de la transaction XA. Utilisez la syntaxe suivante :

[balise URL de type d'emplacement] spécification_emplacement
  • balise d'URL de type d'emplacement indique le type d'emplacement facultatif du journal JTA Partner :
    • La valeur par défaut est dir://, qui indique que l'emplacement du journal JTA Partner se trouve dans un répertoire de système hiérarchique de fichiers qualifié complet spécifié par spécification_emplacement.
  • spécification de l'emplacement indique l'emplacement du journal JTA Partner :
    • Pour spécifier un flot de journalisation, utilisez la syntaxe logstream://HLQ
      Si l'installation du serveur d'applications a suivi la convention de configuration des flots de journalisation dans l'unité de couplage (CF), le flot de journalisation est nommé en fonction de la syntaxe HLQ.server.X, où HLQ est une valeur de 1 à 8 caractères définie par l'utilisateur dans la boîte de dialogue d'installation. Utilisez cette valeur HLQ pour indiquer l'emplacement du journal JTA Partner.
      Eviter les incidents : Définissez AUTODELETE(NO) pour les flux de consignation.gotcha
    • Si la balise d'URL de type d'emplacement est dir://, utilisez un répertoire HFS complet pour la spécification d'emplacement. Le nom complet du répertoire doit être unique dans le noeud WebSphere.

La valeur par défaut est dir://racine_serveur_app/tranlog/nom_serveur.

Pour indiquer la taille des fichiers journaux de transaction, précisez la taille des fichiers. Utilisez l'un des formats suivants, où nom_répertoire est le nom du répertoire de journal de transaction et taille_fichier est la nouvelle allocation d'espace du disque pour les fichiers journaux de transactions mesurée en Ko (nK) ou Mo (nM). La taille minimale de fichier journal des transactions que vous pouvez spécifier est 64 ko. Si vous spécifiez une valeur inférieure à 64 ko ou si vous ne spécifiez pas de valeur, la valeur par défaut de 1 Mo est utilisée.

dir://directory_name/directory_name;file_sizeK
/directory_name/directory_name;file_sizeK
;file_sizeK   <!-- Ce format maintient le répertoire par défaut -->

Si vous migrez un noeud WebSphere Application Server version 5 vers la version 6, l'emplacement de stockage de cette propriété de configuration est transféré du niveau serveur au niveau noeud (index du serveur). Si vous avez spécifié un répertoire de journalisation autre que celui utilisé par défaut pour un serveur d'applications version 5, vous êtes invité à sauvegarder à nouveau les paramètres du service de transaction pour confirmer que le répertoire de journalisation doit être sauvegardé au niveau du noeud.

Dépassement du délai autorisé pour la durée de vie des transactions

Temps maximal par défaut, en secondes, dont dispose une transaction démarrée sur ce serveur pour se terminer. Toutes les transactions qui ne lancent le processus d'arrêt avant ce délai d'attente sont annulées.

Ce délai d'expiration des transactions est utilisé uniquement si le composant d'application ne définit pas lui-même le sien.

[z/OS] Après l'expiration du délai, les transactions sont autorisées à poursuivre leur exécution durant une période de grâce d'environ quatre minutes. Si la transaction est validée ou annulée pendant cette période de grâce, la sortie de la transaction est toujours annulée. Si la transaction n'est pas terminée après la période de grâce, le contrôleur arrête anormalement la région serviteur dans laquelle le composant d'application s'exécute, avec ABEND EC3 RSN=04130002 ou 04130005.
Remarque : Seul le délai de la durée de vie totale de la transaction et le délai d'expiration maximal de la transaction possèdent des périodes de grâce. Vous pouvez désactiver les périodes de grâce à l'aide de la propriété personnalisée DISABLE_TRANSACTION_TIMEOUT_GRACE_PERIOD.

La limite supérieure de ce délai d'expiration dépend du délai d'expiration maximal des transactions. Si, par exemple, vous attribuez la valeur 500 au paramètre de dépassement du délai autorisé pour la durée de vie des transactions et la valeur 300 au délai d'expiration maximal des transactions, les transactions expireront après 300 secondes.

Si vous définissez le paramètre de dépassement du délai sur 0, il ne s'applique pas et la valeur du délai maximal est utilisée en son lieu et place.

Type de données Entier
Unité Secondes
Valeur par défaut 120
Intervalle

[AIX Solaris HP-UX Linux Windows] [iSeries] 0 à 2 147 483 647

Intervalle

[z/OS] 0 à 2 147 040

Délai d'attente de réponse asynchrone

Indique le temps d'attente en secondes dont dispose le serveur pour répondre au protocole WS-AT entrant avant de renvoyer le message du protocole WS-AT précédent.

Type de données Entier
Unité Secondes
Valeur par défaut 30
Intervalle 0 à 2 147 483 647
Dépassement du délai d'inactivité du client

Indique la durée maximale, en secondes, entre deux demandes transactionnelles d'un client distant. Toute période d'inactivité du client qui dépasse cette expiration entraîne l'annulation de cette transaction sur ce serveur d'applications.

Si vous définissez cette valeur sur 0, aucune limite de dépassement du délai n'est appliquée.

Type de données Entier
Unité Secondes
Valeur par défaut 60
Intervalle 0 à 2 147 483 647
Délai d'expiration maximal des transactions

Indique la limite supérieure du délai de transaction en secondes pour les transactions exécutées sur ce serveur. Cette valeur doit être supérieure ou égale à la valeur spécifiée pour le délai total des transactions.

Ce délai contraint la limite supérieure de tous les délais d'expiration des transactions. Le tableau suivant indique comment les différents paramètres de délai d'expiration s'appliquent aux transactions s'exécutant sur le serveur.
Tableau 1. Paramètres de délai d'expiration des transactions.
Paramètre de dépassement du délai Transactions concernées
Délai d'expiration maximal des transactions Toutes les transactions s'exécutant sur ce serveur qui ne sont pas concernées par le paramètre de dépassement du délai autorisé pour la durée de vie des transactions ou par le délai d'expiration d'un composant d'application. Ces transactions incluent les transactions importées, c'est-à-dire qui ne proviennent de ce serveur, par exemple celles importées d'un client.
Dépassement du délai autorisé pour la durée de vie des transactions Toutes les transactions dont le serveur est à l'origine et qui ne sont pas concernées par le délai d'expiration d'un composant d'applications, c'est-à-dire un composant d'applications associé qui n'a pas défini son propre délai d'expiration.
Délai d'expiration d'un composant d'application Transactions qui sont spécifiques à un composant d'application.

Il est impossible de définir ce délai d'expiration des transactions à l'aide de la console d'administration.

Si le composant est un bean géré par le conteneur, indiquez ce délai dans le descripteur de déploiement du composant. Par exemple, vous pouvez utiliser un outil d'assemblage, tel que Rational Application Developer.

Si le composant est un bean géré par un bean, indiquez ce délai à l'aide d'un programme en utilisant la méthode UserTransaction.setTransactionTimeout.

Si vous définissez un délai d'expiration sur 0, le délai ne s'applique pas et est désactivé. Si vous définissez tous les délais d'expiration sur 0, les transactions n'expirent jamais.

Par exemple, envisagez les valeurs suivantes pour les délais d'expiration :
Tableau 2. Exemples de valeurs de délai d'expiration
Paramètre de dépassement du délai Valeur
Délai d'expiration maximal des transactions 360
Dépassement du délai autorisé pour la durée de vie des transactions 240
Délai d'expiration d'un composant d'application 60
Dans cet exemple, des transactions spécifiques du composant d'application expirent au bout de 60 secondes. Les autres transactions locales expirent au bout de 240 secondes, et les transactions qui proviennent de ce serveur expirent au bout de 360 secondes. Si vous remplacez le délai d'expiration du composant d'application par 500, les transactions expirent au bout de 360 secondes, c'est-à-dire après le délai d'expiration maximal. Si vous définissez le délai d'expiration maximal des transactions sur 0, les transactions du composant d'application expirent après 500 secondes. Si vous supprimez le délai d'expiration du composant d'application, ses transactions expirent après 240 secondes.

Pour déterminer rapidement l'occurrence d'un délai et éviter d'autres verrouillages de ressources, le serveur d'applications bloque les autres travaux de transaction sur le chemin transactionnel où la condition d'expiration a eu lieu. Cela s'applique également aux tentatives de travaux sous le contexte transactionnel en cours et sous un contexte transactionnel différent.

Type de données Entier
Unité Secondes
Valeur par défaut 300
Intervalle 0 à 2 147 483 647
Intervalle 0 à 2 147 040
Limite de nouvelles tentatives heuristiques

Indique le nombre de fois que le serveur d'applications tente de renvoyer un signal d'achèvement, comme la validation ou l'annulation. Les nouvelles tentatives ont lieu après une exception transitoire d'un gestionnaire de ressources ou d'un partenaire distant, ou si le délai d'attente de réponse asynchrone configuré expire avant la réponse de tous les partenaires WS-AT (Web Services Atomic Transaction).

Si le serveur d'applications n'effectue pas de nouvelle tentative, le gestionnaire de ressources ou le partenaire éloigné est alors chargé de vérifier que la branche de la ressource ou du partenaire de la transaction a été exécutée de manière appropriée. Le serveur d'applications lance une exception (au nom de la ressource ou du partenaire) qui indique un risque heuristique. Si une validation a été demandée, l'émetteur de la transaction reçoit une exception dans l'opération de validation ; si la transaction est lancée par le conteneur, ce dernier renvoie une exception distante ou une exception Enterprise JavaBeans (EJB) au client d'EJB.

Lors de la récupération d'un serveur subordonné dans une transaction distribuée, si le nombre de nouvelles tentatives heuristiques est dépassé, la propriété de direction de l'achèvement heuristique indique comment la transaction est effectuée.

Type de données Entier
Valeur par défaut 0
Intervalle 0 à 2 147 483 647

La valeur 0 (par défaut) correspond à un nombre illimité de nouvelles tentatives.

Attente des nouvelles tentatives heuristiques

Indique le nombre de secondes que le serveur d'applications attend avant de tenter à nouveau un signal d'exécution (une validation ou une annulation, par exemple) après une exception temporaire émise par un gestionnaire de ressources ou un partenaire distant.

Type de données Entier
Valeur par défaut 0
Intervalle 0 à 2 147 483 647

[AIX Solaris HP-UX Linux Windows] [iSeries] La valeur 0 indique que le serveur d'applications détermine le délai d'attente entre chaque nouvelle tentative ; ce délai est doublé après chaque séquence de 10 tentatives ratées.

[z/OS] Si vous conservez la valeur 0, le serveur d'applications tente plusieurs fois d'effectuer la transaction. Le temps d'attente entre chaque tentative s'allonge régulièrement afin d'améliorer le rendement système.

Activation de la journalisation d'états heuristiques [AIX Solaris HP-UX Linux Windows] [iSeries]

Indique si le serveur d'applications consigne les événements liés aux ressources à validation en une phase associées à des transactions faisant appel à une ressource de validation à une et deux phases.

Cette propriété active la journalisation d'états heuristiques. Si la configuration de certaines applications autorise des ressources de validation à une phase à participer à des transactions de validation à deux phases, la consignation d'événements heuristiques dans le journal des transactions en cas de panne du serveur peut nécessiter des informations supplémentaires. Dans ce cas, un autre enregistrement est effectué dans le journal pour toute transaction impliquant des ressources de validation à une phase et à deux phases. Aucun autre enregistrement n'est inscrit pour les transactions n'impliquant pas de ressource de validation à une phase.

[AIX Solaris HP-UX Linux Windows] [iSeries]
Type de données Case à cocher
Valeur par défaut Désélectionné
Intervalle
Désélectionné
Le serveur d'applications ne consigne pas les événements liés à la validation des ressources en une phase associés à des transactions faisant appel à une ressource de validation à une phase et des ressources de validation à deux phases.
Sélectionné
Le serveur d'applications consigne les événements liés à la validation des ressources en une phase associés à des transactions faisant appel à une ressource de validation à une phase et des ressources de validation à deux phases.
Direction de l'achèvement heuristique

Indique la direction suivie pour terminer une transaction avec un résultat heuristique : le serveur d'applications valide ou annule la transaction, ou bien dépend d'une exécution manuelle par l'administrateur.

La propriété de direction de l'achèvement heuristique indique comment une transaction est effectuée dans les cas suivants :
  • Le gestionnaire des transactions signale un résultat heuristique pour une ressource de support du dernier participant.
  • La limite des nouvelles tentatives heuristiques est dépassée lors de la reprise d'un serveur subordonné dans une transaction répartie.
  • La transaction est importée à partir d'un fournisseur JCA (Java EE Connector Architecture).

Cette propriété ne s'applique qu'aux transactions qui se trouvent dans les situations décrites précédemment.

Type de données Liste déroulante
Valeur par défaut ANNULATION
Intervalle
VALIDATION
Le serveur d'applications valide la transaction de manière heuristique.
ANNULATION
Le serveur d'applications annule la transaction de manière heuristique.
MANUEL
Le serveur d'applications dépend d'un administrateur pour achever manuellement ou annuler les transactions comportant une sortie heuristique.
Accepter les risques heuristiques

Indique si toutes les applications sur ce serveur acceptent la possibilité qu'un danger heuristique survienne dans une transaction à deux phases contenant une ressource à phase unique. Cette valeur configure la prise en charge du participant (LPS) pour le serveur. Le support du dernier participant est une extension du service de transaction permettant à une ressource à phase unique de participer à une transaction à deux phases avec une ou plusieurs ressources à deux phases.

Si l'option Accepter les risques heuristiques n'est pas sélectionnée, vous devez configurer individuellement les applications pour accepter le risque heuristique. Vous pouvez configurer les applications soit lors de leur assemblage soit après le déploiement à l'aide du panneau Extension au support du dernier participant.

Type de données Case à cocher
Valeur par défaut Désélectionné
Intervalle
Sélectionné
Toutes les applications déployées sur le serveur acceptent le risque accru d'une sortie heuristique.
Désélectionné
Les applications doivent être configurées individuellement pour accepter le risque accru d'une sortie heuristique.
Activer le verrouillage de fichiers

Indique si l'utilisation de verrous de fichiers est activée lors de l'ouverture du journal de reprise du service Transactions.

Si vous activez ce paramètre, un verrou de fichier est extrait avant l'accès aux fichiers journaux de reprise du service de transaction. Dans un déploiement WebSphere Application Server à haute disponibilité, le verrouillage des fichiers n'autorise qu'un seul serveur d'applications à accéder à un journal de reprise du service de transaction particulier à un moment donné. Ce paramètre n'a pas d'impact dans un déploiement standard pour lequel vous n'avez pas configuré la prise en charge haute disponibilité.
Avertissement : Ce paramètre requiert un système de fichiers en réseau, tel que Network File System (NFS) version 4, pour fonctionner correctement.
Type de données Case à cocher
Valeur par défaut Sélectionné
Activer l'autorisation de coordination de transactions

Indique si l'échange sécurisé de messages de protocole du service Transactions est activé.

Ce paramètre est sans effet si la sécurité de WebSphere Application Server est désactivée sur le serveur.

Type de données Case à cocher
Valeur par défaut Sélectionné
Niveau de spécification de WS-Transaction

Indique le niveau de spécification par défaut de WS-Transaction à utiliser pour les demandes sortantes qui incluent un contexte de coordination WS-AT (Web Services Atomic Transaction) ou WS-BA (Web Services Business Activity).

Vous avez le choix entre WS-Transaction 1.1 et WS-Transaction 1.0. Pour plus de détails sur ces spécifications, reportez-vous aux rubriques sur le support WS-AT ou WS-BA sur le serveur d'applications.

Le niveau de spécification WS-Transaction par défaut est utilisé si le niveau de spécification requis par le serveur ne peut pas être déterminé à partir de la règle du fournisseur (assertion WS-Transaction WS-Policy). Par exemple, l'assertion de règle n'est pas disponible, ni à partir du WSDL du service Web cible ni à partir du type de règle WS-Transaction du client, ou l'assertion de règle est disponible mais les deux niveaux de spécification sont applicables.

Type de données Liste déroulante
Valeur par défaut 1.0
Préfixe d'URL HTTP(S) WS-Transaction

Sélectionnez ou spécifiez le préfixe de l'URL HTTP(S) WS-Transaction externe.

Sélectionnez ou indiquez une de ces zones si vous utilisez un noeud intermédiaire tel qu'un serveur HTTP ou un serveur proxy pour WebSphere afin d'envoyer des demandes conformes aux protocoles de transaction atomique de services Web (Web Services Atomic Transaction) ou d'activité métier de services Web (Web Services Business Activity).

Si la sécurité de WebSphere Application Server et l'autorisation de coordination de transaction sont activées, le préfixe HTTPS est utilisé. Sinon, le préfixe HTTP est utilisé.

Si le noeud intermédiaire n'est pas un serveur proxy, le préfixe doit être unique pour chaque serveur.

Si vous utilisez un serveur proxy, les préfixes peuvent être identiques pour tous les serveurs d'un cluster, car le serveur proxy détermine de façon dynamique le serveur auquel transmettre la demande.

Sélectionner le préfixe

Sélectionnez cette option pour sélectionner les informations sur l'URL du noeud final externe à utiliser pour les noeuds finaux de service WS-AT et WS-BA dans la liste.

Type de données Liste déroulante
Valeur par défaut Aucune
Spécifier le préfixe personnalisé

Sélectionnez cette option pour définir les informations sur l'URL du noeud final externe à utiliser pour les noeuds finaux de services WS-AT et WS-BA dans cette zone.

Utilisez l'un des formats suivants pour le préfixe, où nom_hôte et port représentent le noeud intermédiaire qui est un proxy HTTP ou HTTPS pour le serveur.
http://nom_hôte:port
https://nom_hôte:port
Type de données Chaîne
Valeur par défaut Aucune
Transactions manuelles

Indique le nombre de transactions devant être achevées manuellement par un administrateur.

Si des transactions doivent être achevées manuellement, vous pouvez cliquer sur le lien Consulter pour en afficher la liste dans le panneau Transactions pour lesquelles une action manuelle est requise.

Type de données Entier
Valeur par défaut 0
Transactions avec nouvelles tentatives

Indique le nombre de transactions comportant des ressources faisant l'objet de nouvelles tentatives.

Si des transactions comportent des ressources faisant l'objet de nouvelles tentatives, vous pouvez cliquer sur le lien Consulter pour en afficher la liste dans le panneau Transactions pour lesquelles une action manuelle est requise.

Type de données Entier
Valeur par défaut 0
Transactions heuristiques

Indique le nombre de transactions ayant été achevées de manière heuristique.

Si des transactions ont été achevées de manière heuristique, vous pouvez cliquer sur le lien Consulter pour en afficher la liste dans le panneau Transactions avec sortie heuristique.

Type de données Entier
Valeur par défaut 0
Transactions préparées importées

Indique le nombre de transactions importées et préparées, mais pas encore validées.

Si des transactions ont été importées et préparées mais non encore validées, vous pouvez cliquer sur le lien Consulter pour en afficher la liste dans le panneau Transactions importées et préparées.

Type de données Entier
Valeur par défaut 0



Les liens marqués (en ligne) requièrent un accès à Internet.

Concepts associés
Tâches associées
[AIX Solaris HP-UX Linux Windows] [iSeries]
Information associée
Transactions nécessitant un achèvement manuel
Transactions comportant des ressources à retenter
Transactions avec issue heuristique
Transactions importées et préparées
Ressources de transactions


Nom du fichier : udat_contranserv.html