WA Autosys Ed. : Nouvelles fonctionnalités

Workload Automation Autosys Edition est la nouvelle version d’Autosys, elle reprend le moteur de la version 11.0 avec l’intégration des agents Cybermation.
12 janvier 2011
POPULARITE : 919 visites
Le System Agent
L’agent Cybermation remplace définitivement l’agent Autosys, ce dernier proposait 2 types de commandes : la commande système et l’attente de fichiers ainsi que des connecteurs pour les logiciels comme SAP ou PeopleSoft.
La nouvelle structure de l’agent permet d’intégrer de nouveaux types à travers un mécanisme de plugin, les anciens connecteurs étant eux-mêmes de nouveaux plugins. L’agent est en Java, et chaque plugins correspond à des jars supplémentaires.
Les agents suivants sont supportés :
CA Workload Automation Agent for i5/OS
CA Workload Automation Agent for Linux
CA Workload Automation Agent for UNIX
CA Workload Automation Agent for Windows
CA Workload Automation Agent for z/OS
Le moteur reste compatible avec les anciens agents 4.5 et R11, les anciennes options restent accessibles. La migration en sera facilitée, d’autant qu’il est possible d’installer un agent Autosys des versions précédentes avec l’agent R11.3.
Les plugins permettent d’étendre l’agent. L’installation se fait à travers le ’PluginInstaller’ dont le rôle est de copier le jar correspondant dans le répertoire des modules et d’ajouter le paramètrage associé dans le fichier de configuration de l’agent. Les modules suivant sont actuellement supportés sur Unix/Linux et Windows :
CA Workload Automation Agent for Application Services
CA Workload Automation Agent for Databases
CA Workload Automation Agent for PeopleSoft
CA Workload Automation Agent for Oracle E-Business Suite
CA Workload Automation Agent for SAP
CA Workload Automation Agent for Web Services
Un fichier de sécurité locale permet de spécifier les autorisations pour les différents utilisateurs :
x a | d manager_userID agent_userID path
Agents supportés
CA Workload Automation
Agent for UNIX or Linux
Command (CMD)
CPU Monitoring (OMCPU)
Disk Monitoring (OMD)
File Trigger (FT)
File Transfer Protocol (FTP)
IP Monitoring (OMIP)
Process Monitoring (OMP)
Secure Copy (SCP)
Text File Reading and Monitoring (OMTF)
CA Workload Automation
Agent for Windows
Command (CMD)
CPU Monitoring (OMCPU)
Disk Monitoring (OMD)
File Trigger (FT)
File Transfer Protocol (FTP)
IP Monitoring (OMIP)
Process Monitoring (OMP)
Secure Copy (SCP)
Text File Reading and Monitoring (OMTF)
Windows Event Log Monitoring Jobs (OMEL)
Windows Service Monitoring (OMS)
Bases de données :
Database Monitor (DBMON)
Database Stored Procedure (DBPROC)
Database Trigger (DBTRIG)
Structured Query Language (SQL)
Mainframe :
Agent for i5/OS
i5/OS (I5)
Oracle E-Business Suite :
Oracle E-Business Suite Copy Single Request (OACOPY)
Oracle E-Business Suite Request Set (OASET)
Oracle E-Business Suite Single Request (OASG)
PeopleSoft :
PeopleSoft (PS)
SAP :
SAP Batch Input Session (SAPBDC)
SAP BW InfoPackage (SAPBWIP)
SAP BW Process Chain (SAPBWPC)
SAP Data Archiving (SAPDA)
SAP Event Monitor (SAPEVT)
SAP Job Copy (SAPJC)
SAP Process Monitor (SAPPM)
SAP R/3 (SAP)
Application Services :
Entity Bean (ENTYBEAN)
Hypertext Transfer Protocol (HTTP)
Java Remote Method Invocation (JAVARMI)
JMS Publish (JMSPUB)
JMS Subscribe (JMSSUB)
JMX-MBean Attribute Get (JMXMAG)
JMX-MBean Attribute Set (JMXMAS)
JMX-MBean Create Instance (JMXMC)
JMX-MBean Operation (JMXMOP)
JMX-MBean Remove Instance (JMXMREM)
JMX-MBean Subscribe (JMXSUB)
Plain Old Java Object (POJO)
Session Bean (SESSBEAN)
Web Services :
Plain Old Java Object (POJO)
Web Service (WBSVC)
Traitements z/OS :
z/OS Data Set Trigger (ZOSDST)
z/OS Manual (ZOSM)
z/OS Regular (ZOS)
Les types command, box et filewatcher restent accessible pour la compatibilité des anciens JIL.
Tous les types ne sont pas encore implémentés dans la 11.3, il devraient l’être dans les prochains Service Pack :
Micro Focus (MICROFOCUS)
SNMP Value Get (SNMPGET)
SNMP Value Set (SNMPSET)
Wake on LAN (WOL)
Définitions
Appel de commandes
La méthode d’exécution de la commande est paramètrable. En 4.5, la commande était directement soumise après chargement éventuel du profil, dans le cas de commande comme le dir, l’agent préfixait automatiquement par un "cmd.exe /c".
Ce n’est plus le cas en 11.3 sauf si on a défini au préalable le paramètrage comme suit :
oscomponent.lookupcommand=true
oscomponent.cmdprefix.force=trueSubstitution de commandes
On ne peut plus utiliser la substitution de commande dans le champ watch_file comme on pouvait le faire en 4.5 ou en 4.5 :
watch_file: \tmp\`date`
File watcher
Pour conserver la compatibilité, le file watcher est toujours présent pour les anciens agents. Si ce type de job est utilisé un nouvel agent le fonctionnement est le suivant :
le traitement vérifie le fichier toutes les 30 secondes
si le fichier est créé ou mis à jour entre 2 vérifications, on attend 1 minute de plus (par défaut). Si le fichier n’a pas évolué pendant cette période, le traitement se termine.
On peut toujours modifier l’intervalle de polling en utilisant le paramètre watch_interval.
Dieze dans les noms d’objet
L’utilisation caractère # (dièze) dans les noms d’objets n’est plus permise.
Ressources
On peut maintenant définir des ressources virtuelles et les utiliser comme des dépendances. Il existe 3 types de ressources :
depletable
renewable
threshold
Ce type de ressources permet de gérer les accès concurrents.
La fréquence de vérification peut être spécifiée dans la configuration du serveur avec le champ ResourceWaitPollInterval.
Alertes de planifications
Deux nouveaux évènements ont ajoutés :
le must_start_times qui permet de définir une heure ou une liste d’heures. Si le traitement ne démarre pas à l’heure spécifié, une alarme est envoyée. Cet évènement correspond à une heure au plus tard.
le must_complete_times qui définit l’heure ou les heures de fin. Si l’heure est dépassée, une alarme est envoyée. Cet évènement est pratique dans le cadre de SLA.
Configuration Agent
variables d’environnement
Les variables sont maintenant définies dans un fichier de configuration dont la localisation est précisé dans l’agentparm.txt, on distingue les variables pour les différents agents agents et les variables spécifiques à une instance. Le champ envvar du jil qui permet de passer une variable au traitement.
Journaux
Le nouvel agent 11.3 écrit les logs dans les répertoires suivants :
Répertoire_d’installation/SystemAgent/Nom_agent/log pour les logs internes à l’agent
Répertoire_d’installation/SystemAgent/Nom_agent/spool pour les logs d’exécution
Agent Windows
Le format de profile sur Windows n’est plus stocké en base de registres, la migration de ce format vers celui de la 11.3 est pris en charge dans la procédure d’upgrade. Sinon, la commande autoprofm peut être exécutée manuellement.
Configuration Serveur
Calcul de charge machine
Le vmstat n’est plus utilisé par les nouveaux agents, on utilise maintenant le job type CPUMON.
Localhost
Localhost est devenu un mot réservé. On se rappelle les versions antérieures ou on pouvait définir le serveur comme suit :
`hostname`qui permettait de récupérer le nom du serveur mais obligeait le serveur a exécuter cette commande.
locahost qui n’était valide que pour les serveurs disposant de licence globale type entreprise
$$serveur qui plantait les traitement en cas de bascule (à moins de bidouiller avec les notify).
Maintenant, c’est simplement "localhost" a qui on peut éventuellement attribuer un nom plus joli avec le paramètre LocalMachineDefinition.
Paramètres de démarrage
Les paramètres de démarrage du serveur Autosys qui étaient passées en ligne de commande dans les précédentes versions, sont maintenant définies dans le fichier de configuration. Elles ne sont plus accessibles en tant que paramètres de l’eventor.
Global Auto Hold (ancienne option -G) est maintenant défini dans le champ GlobalAutoHold
Chase (ancienne option -n) correspond au champ ChaseOnStartup
Maintenance
L’option LOGROLLOVER permet de spécifier le moment l’heure à laquelle le journal du serveur sera sauvegardé. Il est aussi possible d’indiquer une taille maximum pour le journal, la sauvegarde se fera alors dés que la taille du fichier est atteinte.
Support IPv6
IPv6 est maintenant supporté, c’était une demande des Etats-Unis car en France je ne connais pas beaucoup de site en IPv6. Ce format est compréhensible par la JIL pour la définition des machines.
Supervision
La partie alerte a évoluée pour une meilleure intégration avec des outils de supervision, plus particulièrement avec NSM et son Event Manager.
Surveillance continue
La surveillance continue peut être activée sur les traitements suivants :
CPU Monitoring (OMCPU)
Database Monitor (DBMON)
Database Trigger (DBTRIG)
Disk Monitoring (OMD)
File Trigger (FT)
Text File Reading and Monitoring (OMTF)
Windows Event Log Monitoring (OMEL)
Windows Services Monitoring (OMS)
Lorsque les seuils sont atteints, un évènement ALERT est écrit dans le journal du serveur. Ces informations sont ensuite accessibles par la commande
autorep -J -d
On regrettera que ces évènements ne puisse être traités autrement que par un outil de supervision comme NSM. Une simple intégration dans le notify aurait permi d’éviter de passer par un gestionnaire d’alertes.
L’arrêt de ce type de traitement se fait comme pour un file watcher :
kill de job par un sendevent -KILLJOB
Message d’évènements dans le journal
Le texte associé à un évènement est écrit dans le journal du serveur, cette information permet l’ajout d’explication dans les logs et facilite la gestion des messages.
Evènements STATE_CHANGE
Certains nouveaux traitemens, comme le type z/OS, passent par différents changements d’état pendant l’exécution.
Ces états sont inscrits dans le journal et accessible par un autorep -d.
Cross instance
les changements sur les instances croisées sont les suivants :
les évènements externes sont stockés dans le table ujo_ext_event
on peut croiser une instance 4.5 et 11.3 en utilisant un serveur d’application léger installé sur la partie 11.3.
les instances peuvent utiliser des cryptages différents qu’on spécifie avec l’attribut xcrypt_key.
Mainframe
On peut définir et surveiller des dépendances inter instances entre Autosys Edition et CA7 Edition. Ces dépendances permettent de définir des chaînes contenant des traitements exécutés aussi bien du mainframe que sur distribué.
Commandes
Prévisions
Une nouvelle commande de forecast permet de créer un rapport pour les traitements futurs suivant une date spécifiée.
Autoping
Le paramètre -S de la commande autoping permet de vérifier la connexion de l’agent vers le serveur en passant par le serveur d’application. Si l’agent est inférieur à la version 11.3, c’est un test de connexion de base de données qui est effectué.
Clean files
Le clean_files ne sert plus que pour les anciens agents. Le nettoyage des fichiers est prise en charge par l’agent 11.3.
Commandes supprimées
Les commandes suivantes ne sont plus disponibles :
autodwp
autosys_report
autosys_wv
job_delete (remplacée par archive_jobs)
job_profiles
ntgetdate
xql / zql










































Job-scheduling
Workload Automation Autosys Edition
Sites connexes
Licence
Partenariat
Rechercher
Recherche globale
Annonces