Page Exécution

Une grande quantité de données sur la durée d'exécution est nécessaire aux diverses fonctions de planification et de surveillance proposées par Automation Engine. Ces données sont issues des informations sur la durée d'exécution réelle (RRT = Real Runtime). C'est à partir de ces informations que peut être calculé la durée d'exécution estimée (ERT = Estimated Runtime). Cette rubrique décrit la RRT et l'ERT. Elle présente les options dont vous disposez pour calculer l'ERT.

Si vous êtes développeur et concepteur d'objets, ces informations sont indispensables pour planifier vos tâches. Vous devez définir la méthode de calcul de la durée d'exécution des objets exécutables dans leurs pages Exécution.

Cette rubrique contient les sujets suivants :

Durée d'exécution réelle et estimée

Durée d'exécution réelle (RRT)

La RRT est la durée pendant laquelle la tâche est active, c'est à dire entre son début et sa fin.

Les laps de temps suivants ne sont pas pris en compte dans la RRT de la tâche.

Temps nécessaire à son activation.
Temps passé à attendre le statut de l'hôte.

Les 25 dernières RRT de chaque objet exécutable sont enregistrées avec les données de l'objet. Ces données servent de base au calcul de la durée d'exécution estimée (ERT = Estimated Runtime). Seules les exécutions s'étant terminées avec le statut ENDED_OK sont prises en compte.

La RRT la plus petite est d'une seconde. Les tâches dont la RRT est inférieure sont arrondies à une seconde.

Durée d'exécution estimé (ERT)

L'ERT est la durée d'exécution attendue pour la prochaine exécution d'une tâche. Ces données sont primordiales pour la surveillance dynamique des durées d'exécution et le calcul des simulations ainsi que pour le calcul de l'heure de fin la plus récente d'une tâche. L'ERT est calculée juste après l'exécution d'une tâche, à partir de ses 25 dernières RRT.

Important :

La qualité du calcul de l'ERT dépend des données disponibles. En cas de réorganisation de la base de données, la quantité de jeux de données disponibles peut ne pas être suffisante. Ce qui peut dans ce cas fausser le calcul.
Un grand nombre de données historiques sont lues dans l'objet pour ce calcul. Ainsi, cette fonction doit être uniquement activée pour les objets individuels et non pour l'ensemble du client. Voir Données d'exécution.
Il est assez rare qu'une tâche s'exécute et se termine plusieurs fois en même temps. Si tel est le cas, il peut arriver que l'une des exécutions ne soit pas prise en compte dans le calcul de l'ERT. Cela est dû aux mécanismes de verrouillage de la base de données AE.

Mode de calcul de l'ERT pour les clients

L'objet VARA système UC_CLIENT_SETTINGS contient des paramètres s'appliquant à l'ensemble des clients. Dans son code ERT_METHOD, les administrateurs système peuvent spécifier une méthode de calcul de l'ERT applicable aux objets du client. C'est la méthode utilisée si vous sélectionnez Méthode telle que définie dans UC_CLIENT_SETTINGS, dans la liste déroulante Méthode de calcul.

Pour plus d'informations, voir UC_CLIENT_SETTINGS - Divers paramètres du client.

Important ! Les paramètres de calcul de l'ERT que vous définissez dans cette page remplacent les valeurs par défaut définies dans UC_CLIENT_SETTINGS.

Pour définir les paramètres d'exécution

Spécifiez les statuts précis (codes retour) que vous considérez comme terminés normalement (ENDED_OK) dans la section Traitement du code retour. Pour plus d'informations sur la signification des codes retour, voir Codes retour système des objets exécutables.

Important ! Les règles suivantes ne s'appliquent qu'aux objets Job :
- Windows
  
  Si le code retour est -1 dans Windows, le job n'est considéré comme ENDED_OK que si le code retour est égal à 0.
  
  Cela vous permet de réagir aux erreurs de protection dans les jobs Windows (par exemple code retour : -1073741819).
- z/OS
  
  Le code retour doit être spécifié sous forme de valeur décimale. Il est également possible, dans z/OS, de comparer le code retour de chaque étape à une entrée de la liste des étapes. En résultat de ces vérifications, le job sera alors évalué comme terminé normalement ou interrompu.
- Vous pouvez définir le code retour via l'élément de script :MODIFY_STATE.
Si vous souhaitez qu'un autre objet soit exécuté lorsqu'une tâche se termine avec un code retour différent, cochez la case Action, puis sélectionnez l'objet dans Exécution de.
Définissez la méthode de calcul de l'ERT. La section Exécution estimée (ERT) vous propose les options suivantes :
- Méthode définie dans UC_CLIENT_SETTINGS
  
  Sélectionnez cette option si vous souhaitez appliquer la méthode et les paramètres spécifiés par votre administrateur système dans l'objet VARA UC_CLIENT_SETTINGS.
  - Nouveaux objets
    
    Aucune exécution passée ne permet de calculer l'ERT. Étant donné que vous en avez besoin pour la surveillance des simulations et de la durée d'exécution, par exemple, les champs ERT courant / de secours sont activés, afin que vous puissiez saisir une suggestion. Cette valeur est remplacée dès que la tâche a terminé sa première exécution. Elle est ensuite remplacée par la valeur de l'ERT calculée avec la méthode spécifiée dans l'objet VARA.
  - Objets déjà exécutés
    
    Dès que l'objet a été exécuté, ces champs sont désactivés et affichent les valeurs réelles, actuelles.
    
    Pour les réinitialiser, cliquez sur le bouton Initialiser les valeurs, en bas du graphique Statistiques d'exécution. Cela réactive ces champs.
- Valeur fixée
  
  Saisissez une valeur statique dans Durée, en la vérifiant de temps en temps, afin de vous assurer qu'elle correspond toujours à vos besoins.
  
  Les champs ERT courante sont désactivés quand la durée est enregistrée.
  
  Remarque : La simulation utilise toujours l'ERT actuel pour les calculs de simulation. Lorsqu'une valeur fixe est définie, elle est utilisée pour d'autres exécutions de tâches pais pas pour la simulation. Pour utiliser une valeur fixe, vous devez réinitialiser le calcul de l'ERT avant et également après l'exécution suivante. La valeur fixe correspond également à l'ERT actuel.
  
  Important !
  
  Attention à l'impact d'une valeur fixe trop élevée :
  - Simulations : L'exécution terminée est évaluée trop à la hausse car elle commence toujours à partir de la durée d'exécution maximum autorisée (pire cas). La simulation ne peut donc pas donner de valeurs réalistes.
  - La surveillance de la durée d'exécution minimum active toujours les actions définies en cas d'écart de la durée d'exécution, car la RRT est toujours inférieure à l'ERT.
  - La surveillance de la durée d'exécution maximum n'active jamais les actions définies en cas d'écart de la durée d'exécution, car le l'ERT n'est jamais atteinte.
  Attention à l'impact d'une valeur fixe trop basse :
  - Simulations : L'exécution terminée est évaluée trop à la basse car la RRT est généralement supérieure à la valeur définie. La simulation ne peut donc pas donner de valeurs réalistes.
  - La surveillance de la durée d'exécution minimum active parfois les actions définies en cas d'écart de la durée d'exécution car la RRT est généralement supérieure à l'ERT spécifiée.
  - La surveillance de la durée d'exécution maximum active beaucoup trop souvent les actions définies en cas d'écart du temps d'exécution car l'ERT spécifiée est dépassée.
- Dynamique
  
  Les méthodes dynamiques disponibles sont les suivantes :
  - Adaptatif
    
    Cette méthode calcule l'ERT proactivement (basée sur l'apprentissage machine), en considérant divers facteurs et paramètres d'exécution des précédentes exécutions. Étant donné qu'elle est basée sur les données historiques, elle est affectée par les réorganisations.
    
    Saisissez la valeur de ERT de secours, qui est la valeur de secours codée utilisée en l'absence de certains paramètres.
    
    Important ! Pour que cette méthode soit efficace, il faut que la quantité de données historiques soit suffisante (au moins 30 exécutions d'une tâche)
    
    Conditions :
    - Il faut au moins 1 JWP (Java-based work process = processus de travail basé sur Java) disponible.
    - Une autre méthode de calcul est définie dans le code ERT_ADAPTIVE_FALLBACK_METHOD (UC_CLIENT_SETTINGS) si aucun JWP n'est disponible.
    - ERT_ADAPTIVE est définie à Y (UC_CLIENT_SETTINGS).
    Remarques :
    - L'ERT n'est pas calculée tant que le JWP n'est pas démarré. Cela peut prendre un certain temps. Dans ERT_ADAPTIVE_JWP_TIMEOUT (UC_SYSTEM_SETTINGS), les utilisateurs administrateurs peuvent définir le délai d'attente du système après démarrage du JWP et avant qu'une autre méthode soit utilisée.
    - Le statut des tâches en attente de calcul d'ERT adaptatif est En attente d'ERT. Cela s'applique aux tâches pour lesquelles le temps d'exécution minimum ou maximum est calculé en fonction de l'ERT.
    - Les variables d'objets peuvent être utilisés comme facteurs externes pour le calcul de l'ERT de l'objet avec cette méthode. Pour plus d'informations, voir Variables d'objet.
  - Régression linéaire
    
    C'est la méthode par défaut. Elle met l'accent sur l'augmentation ou la diminution du temps d'exécution.
    - Si vous spécifiez une valeur dans ERT courante, cette dernière s'appliquera jusqu'à ce qu'une ERT soit calculée après la prochaine exécution.
    - Saisissez le nombre d'exécutions précédentes devant être utilisé pour le calcul de l'ERT.
    - Afin d'éviter l'évaluation d'écarts trop importants, saisissez l'écart max. Il s'agit du niveau d'écart maximum. Si la RRT dépasse cette limite, elle n'est pas prise en compte pour le calcul de l'ERT. Il est, en outre, possible d'indiquer le nombre d'exécutions à utiliser.
  - Moyenne
    
    Calcul de l'ERT moyenne à partir des dernières RRT d'une tâche. Définissez ici le nombre de RRT à prendre en compte.
    - Si le nombre de RRT est trop faible, l'ERT suivra n'importe quelle tendance existante dans son comportement d'exécution.
    - Si le nombre de RRT est trop élevé, les écarts excessifs avec les RRT ne seront pas visibles.
    Pour maintenir un écart entre l'ERT et la RRT, il est possible de définir une valeur de correction (+ Correction ERT). Cette valeur est rajoutée aux ERT pour garantir que l'ERT suivra la RRT d'une tâche selon l'écart spécifié.
    
    De même que pour la méthode de régression linéaire, vous pouvez définir ici l'ERT courante et le nombre d'exécutions précédentes.
    
    De plus, afin d'éviter toute évaluation d'écarts trop importants, vous pouvez définir des seuils selon lesquels vous les ignorez. Si la durée d'exécution réelle dépasse cette limite, cette valeur ne sera pas prise en compte pour le calcul de l'ERT :
    - Etendue de l'écart : Si la limite (en %) dépasse la durée d'exécution actuelle, la durée d'exécution estimée sera ignorée.
    - Exécutions min. : Nombre d'exécutions passées à prendre en compte indépendamment des écarts. Valeurs autorisées : 0 à 25.
  - Valeur maximale
    
    La valeur maximale de la liste des RRT est utilisée pour le calcul de l'ERT. Si un grand nombre d'exécutions doit être calculé, l'ERT s'adapte immédiatement aux temps d'exécution en augmentation. Toutefois, si la RRT est en baisse, cela se traduit par un ajustement lent.
    
    Pour que les tendances à la baisse puissent être prises en compte plus rapidement, il est possible de réduire le nombre des exécutions à calculer.
    
    Pour maintenir un écart entre l'ERT et la RRT, il est possible de définir une valeur de correction en pourcentage. Cette valeur de correction est ajoutée aux ERT. Cela vous permet de ne définir une alarme qu'en cas d'extrêmes augmentations de la durée d'exécution.
La section Statistiques d'exécution propose une interprétation graphique des durées d'exécution réelles (en bleu) et estimées (en vert), permettant de comprendre la relation entre les deux. En affichant les deux à la fois, vous pouvez comparer leur comportement ou en désactiver une, en cliquant sur la zone correspondante de la boîte, en bas du graphique.
Si nécessaire, cliquez sur le bouton Initialiser les valeurs en bas du graphique. Cela supprimera toutes les données relatives à la durée d'exécution.

Important !
- La réinitialisation des valeurs supprime toutes les données relatives à la durée d'exécution, même celles antérieures à l'enregistrement de l'objet.
- Les données réelles de durée d'exécution ne peuvent être restaurées à partir des données d'archives.
- Cette fonction n'est utile que si d'importants écarts de durée d'exécution sont attendus pour les exécutions futures (par exemple après la modification de la tâche).
Dans la section Exécution max. & min., activez Surveiller MRT et / ou Surveiller SRT si vous souhaitez surveiller les durées d'exécution maximum et / ou minimum. Les méthodes de calcul disponibles sont les suivantes :
- Valeur fixe : Saisissez une durée fixe.
- ERT + durée supplémentaire / ERT - durée négative
  
  Sélectionnez cette option pour ajouter ou soustraire la durée ERT et saisir la durée corrigée en %. La valeur saisie ici est ajoutée (pour une durée max.) ou soustraite (pour une durée min.) de l'ERT.
- Date réelle + durée supplémentaire (pour la durée d'exécution maximale uniquement)
  
  Vous pouvez définir un délai particulier au bout duquel la tâche doit se terminer. Vous pouvez combiner les options suivantes :
  - Le nombre de jours, dans le champ Durée supplémentaire.
  - Une heure spécifique, dans les champs de saisie Heure de fin.
  - Un objet Fuseau horaire.
Pour plus d'informations, voir Impact de l'intervalle de vérification dans le MRT.
Vous pouvez également définir les Actions sur les écarts d'exécution.
Dans Paramètres de prévision, sélectionnez le statut de fin devant être renvoyé par une tâche en cas de calcul de prévision. Voir Simulations et simulations automatiques.

Impact de l'intervalle de vérification dans le MRT

La variable UC_JOB_CHECKINTERVAL définit l'intervalle qui s'applique à tout le système pour la vérification des heures. Cette vérification est nécessaire lorsque des dépendances d'heures sont définies dans des objets. Tenez compte de cet intervalle lors de la définition des paramètres MRT.

Pour plus d'informations, voir UC_JOB_CHECKINTERVAL - Vérification périodique de l'heure dans le AE.