Ordonnancement.org

Présentation R11

Architecture

Nouveaux agents

CA a racheté Cybermation en Avril 2006 principalement pour sa partie agent jugée plus performante. La R11 commencera donc a intégrer les agents de la gamme dseries (distributed). Ces agents se déclinent en 3 groupes : system agent, business agent (sap, peoplesoft…) et database agent (oracle…).

Communication Agent-Base de données

Les clients de base de données sont supprimés au profit d’un serveur d’application. L’agent dialogue directement avec le serveur d’application qui se charge de la gestion des informations en base de données. Outre le fait de simplifier grandement la configuration des agents et d’éliminer un client de base de données, on peut maintenant faire communiquer n’importe quel agent avec une base de données, on pense entre autre à des agents Unix avec du MSSQL mais il devrait être possible de mettre en place des cross dependencies entre une instance sybase et une instance oracle.

Base de données MDB

Une base de données générique nommée MDB permettra de centraliser les informations des produits CA, par défaut il s’agit d’une base Ingres [1] mais cette base sera prochainement disponible sur les autres SGBD.

L’ensemble des informations des produits CA se retrouvera sur la base, ainsi une machine sur laquelle on a installé du UWCC contiendra de fait une base Autosys.

En toute logique, les tables des bases de données sont maintenant préfixés par le nom de produit.

Définition de Jobs

Nouveaux champs

2 nouveaux champs : Group et Application permettent de lier des jobs entre eux. Ces champs sont utilisables par les outils en ligne, il est donc possible de forcer le démarrage d’un groupe de job par une commande de type

sendevent -E FORCE_JOBSTART -G TOUSLESJOBSDUGROUPE

Types de traitement

Il existait jusqu’à présent 2 types de traitement : les commandes et les file watchers. Sur le même principe, on trouve maintenant des commandes prédéfinies telles que : FTP, J2EE, SAP… Cette intégration permet de disposer de menus contextuels pour ces différents traitements.

Calendriers

La gestion des calendriers est amélioré avec l’utilisation de 3 types de calendriers : le standard (l’actuel), le calendrier étendu et le calendrier cyclique. Le calendrier étendu permet l’utilisation de mots clés tels que FOMWORK pour « First Workday of the month ». le calendrier cyclique gère les répétitions.

Moins révolutionnaire qu’annoncé, le principe est de mélanger ce que CA avait dans les poches, le calendrier étendue est grosso modo ce que l’on a déjà manuellement : je défini un calendrier avec des jours (jours fériés français par exemple), je lui applique une règle (ex : 3eme jours ouvrés) en indiquant un éventuel report par rapport aux dates précédemment définies. A cela, on ajoute des mots clés comme on peut le faire avec workload.

L’autocal_asc prend en compte ces nouveaux calendriers ainsi que les fonctions d’import/export.

Dépendances et plages horaires

Un paramètre supplémentaire dans l’indication de condition permet de spécifier la plage horaire pendant laquelle le statut est valide. Ex : s(job,01:00) signifie que la condition est un SUCCES du job et que le job s’est terminé dans l’heure précédente. Ceci évite les problèmes de jobs qui se déclenchaient avec une condition antérieure à celle attendue.

On peut indiquer un nombre illimité de conditions. On notera que cela a du se faire sans profonde modification de la base de données puisqu’il existait déjà une une ligne par conditions dans la base données, le mécanisme interne du serveur était donc déjà capable de traiter un nombre illimité de conditions. Par contre la limitation étaient au niveau de la saisie et de la visualisation, donc l’interface a du être revue.

Remontées d’erreurs

Des champs de notification permettent d’envoyer des messages sur fin de traitement.

Le serveur indique l’exit code dans ses logs. Ce que l’on sait est que l’exit code est indiqué dans les logs, donc à priori il sera partie contenu dans le message d’erreur, je demande la confirmation.

Arrêt/Relance des machines

Les machines peuvent être mise directement en online/offline. Cela pouvait être fait par le blocage de queue batch ou par un conditionnement de job mais cette nouvelle option permet de systématiser la fonctionnalité.

Lorsque la machine est offline, les traitements sont mis en attente et peuvent reprendre lors de la remise en ligne.

[1] Racheté par CA mais dont la partie services à été déléguée à une société tierce

Le document issu de http://Ordonnancement.org est mis à disposition sous les termes de la licence Creative Commons, vous pouvez l'utilisez dans vos documents à condition de citer l'auteur E. Angenault, vous êtes aussi libre de le modifier. Par contre, vous devez le redistribuer dans les mêmes conditions et la commercialisation ne peut se faire qu'avec l'accord de l'auteur.