Conventions de nommage

L'application de conventions de nommage homogènes à vos objets Automation Engine vous aide dans votre travail quotidien ainsi que dans les tâches de maintenance, l'identification et la compréhension facile des alertes, des problèmes de sécurité, du transport d'objets et de processus d'un système vers un autre, etc.

Cette rubrique contient les sujets suivants :

Introduction

Il est toujours possible de renommer des objets. Cependant, l'attribution de noms cohérents aux objets vous aide de plusieurs manières :

Conseil : Utilisez des bases de données et des serveurs différents pour séparer les environnements de production de ceux de test et développement. De cette manière, environnement de production n'est pas impacté par les exécutions et les mises à niveau effectuées sur environnement de test. Cependant, si le besoin se fait sentir, les trois environnements peuvent s'exécuter sur un même système Automation Engine. Afin de pouvoir transporter sans problème des objets et des processus d'un environnement vers un autre, il est extrêmement important d'utiliser des noms d'objet homogènes.

Conventions typographiques

Les noms d'objet peuvent contenir jusqu'à 200 caractères. Les caractères suivants sont autorisés :

Les limitations suivantes, spécifiques aux objets, doivent être prises en compte :

Conventions de nommage pour les clients

Les clients agissent comme des environnements autonomes. Ils sont représentés par les objets client.

S'il n'y a aucune dépendance entre les tâches des domaines, départements individuels ou les clients, vous avez la possibilité d'exécuter des clients distincts pour chaque domaine. Cela présente l'avantage de pouvoir facilement configurer un concept d'autorisation utilisateur. D'un autre côté, fusionner des clients ultérieurement peut prendre beaucoup de temps.

Le tableau ci-dessous illustre comment diviser le nombre de catégories pour vos différents domaines. Les numéros des clients utilisés pour chaque département ou client sont uniformément différents dans les systèmes de test, de développement et de production. Ce type d'allocation numérique est utile pour la définition de tâches, car les tâches sont en mesure de déterminer sur quel client (à savoir dans quel système) elles s'exécutent. Pour un concept de numérotation logique donné, les tâches peuvent donc configurer automatiquement les paramètres requis. Cela peut éliminer la nécessité de configurer manuellement les tâches pour chaque environnement distinct.

Système de test Système de développement

Système de production
0001 formation    

0100 maintenance interne

 0200 maintenance interne 0300 maintenance interne
1000 FA Finance 1100 FA Finance 1200 FA Finance
2000 FA Assurance 2100 FA Assurance 2200 FA Assurance
3000 FA Stockage 3100 FA Stockage 3200 FA Stockage

Conventions de nommage pour les agents

Au moment de définir un concept de nommage pour les agents, prenez en compte le fait qu'il existe deux types d'agents : Les agents pour les systèmes d'exploitation et les agents pour les applications.

Agents pour les systèmes d'exploitation

Utiliser le nom du système sur lequel l'agent est installé est un bon choix dans ce cas. Vous pouvez également utiliser le nom du DNS primaire du système, dans le cas où il est différent du nom du système.

De cette manière, vous pouvez immédiatement identifier sur quel système d'exploitation un client s'exécute, ce qui vous aide beaucoup lors de la création et de l'allocation de jobs sur le système d'exploitation.

Un inconvénient potentiel de cette approche est que, dans le cas où le système est migré vers un nouveau système matériel, le nom du système peut également changer. Si le concept de nommage doit être préservé, cela nécessite la mise à jour des noms de tous les agents impactés, ainsi que des noms des objets job.

Pour les jobs générés de manière dynamique, dans le cas où l'agent est uniquement déterminé au moment de l'exécution puis défini par un script, le renommage de l'objet agent peut également prendre du temps s'il est effectué par la suite. Afin d'éviter que cela devienne un problème majeur, les noms des agents doivent être stockés de manière centralisée pour chaque client ou processus (dans les variables Automation Engine ou les objets de type Include). Cette approche est cohérente si vous désirez transporter des objets d'un client vers un autre par la suite.

Agents pour les applications

Afin de mieux distinguer les agents destinés aux applications de ceux destinés aux systèmes d'exploitation, leurs noms doivent comporter un préfixe qui identifie de manière unique l'application, suivi du nom de l'instance de l'application. La structure d'un tel nom d'agent est la suivante :

<PREFIXE-APP>_<APP_INSTANCE>

Par exemple :

SAP_P01

Conventions de nommage pour les groupes d'agents

Les groupes d'agents englobent les agents utilisant le même système d'exploitation ou la même application. Dans les jobs, il est possible de spécifier des groupes d'agents plutôt que des agents individuels pour les opérations d'équilibrage de charge, de parallélisation de processus ou bien pour garantir une disponibilité élevée. Par conséquent, leur nommage doit être basé sur les caractéristiques communes des agents appartenant au même groupe. Afin de mieux les distinguer et de faciliter la recherche de groupes d'agents, il est possible d'utiliser un préfixe, tel que 'AG_'. Par exemple :

Nom d'objet

 Description
AG_UNX_ALL Groupe composé de tous les agents UNIX.

AG_UNX_ORA

Groupe composé de tous les agents UNIX s'exécutant sur des serveurs de bases de données Oracle.
AG_WIN_SQL Groupe composé de tous les agents Windows s'exécutant sur des serveurs de bases de données MS SQL.

AG_SAP_BASIS

 Groupe composé de tous les agents SAP à utiliser pour l'exécution de jobs SAP Basis.

Agents en cluster

Si des agents doivent s'exécuter dans un cluster, il est recommandé d'utiliser un préfixe ou un suffixe pour les distinguer des agents s'exécutant en dehors des clusters. Par exemple :

Nom d'objet

 Description
P01_UNX_CLUSTER_A Agent UNIX pour l'instance SAP P01 dans le cluster "A".

P02_WIN_CLUSTER_X

Agent Windows pour l'instance SAP P02 dans le cluster "X".

Conventions de nommage pour les objets - considérations générales

Les objets utilisés pour la conception de processus sont des objets exécutables ou bien des objets globaux. Les objets de type Login, Inclure, Variable, Notification et Calendrier sont des exemples d'objets globaux. Ils peuvent être utilisés par tous les processus au sein d'un client. Par ailleurs, les objets de type job, Transfert de fichiers et Workflow sont des exemples d'objets exécutables.

En choisissant le nom des objets, il est très important d'avoir en mémoire votre concept d'autorisation d'accès. Un concept d'autorisation qui est à la fois efficace et facile à maintenir repose sur un concept de nommage structuré de manière logique. Lors de l'attribution des noms, assurez-vous de prendre en compte les chemins de transport qui seront utilisés. Par exemple, si des clients doivent fusionner au sein d'un même client dans le futur, les objets portant le même nom causeront des problèmes.

Si vous prévoyez de transporter des processus entre des clients Automation Engine, par exemple entre les clients de test et de production, tous les paramètres dépendants des clients pour chaque processus autonome (unité de transport) doivent être stockés dans un emplacement de processus central (par exemple dans un objet variable Automation Engine). Cela inclut les agents et les chemins de traitement qui peuvent changer entre le test et la production.

Cet objet de configuration central contient soit la configuration pour tous les clients exécutant le processus, auquel cas il est toujours intégré au transport, soit uniquement la configuration du client exécutant actuellement le processus, auquel cas il peut ne pas faire partie du transport. La première de ces deux approches est plus coûteuse en temps en termes de maintenance mais elle propose également un fonctionnement plus fiable.

Dans l'Automation Engine, les autorisations peuvent uniquement être contrôlées au moyen de noms d'objet et de types d'objet ; elles ne peuvent pas être contrôlées en utilisant des structures de dossiers définies par l'utilisateur. Pour cette raison, les objets globaux qui sont uniquement modifiables par un groupe restreint d'utilisateurs doivent être nommés en conséquence.

Les noms d'objet doivent donc comporter les éléments suivants :

Exemple

Concept de nommage pour les objets individuels

La convention suivante permet aux noms d'être composés de 6 fragments d'information et définit les séparateurs systématiquement utilisés :

Fragment d'information dans le nom d'objet

 Description
SYS

Préfixe qui identifie les objets pouvant être utilisés globalement dans l'ensemble du client. Leur modification est limitée à un groupe d'utilisateurs spécifique.
AA Code pays composé de deux caractères, conforme à la norme ISO 3166.
BBBB Département (quatre caractères)
CCCC Abréviation standard de type d'objet (OBP, JOBS, JSCH, etc.).
DDD Plate-forme (trois caractères).
DESCRIPTION Texte défini par l'utilisateur décrivant la tâche

. _ #

 Séparateurs

Selon ce schéma, vous pouvez obtenir les noms d'objets suivants :

Nom d'objet

 Description
SYS.LOGIN#WINDOWS

Objet Login global pour tous les agents Windows
SYS.CALE#PRODUCTION Calendrier global pour la production
UK.FIAC.JOBS_UNX#MONTH_END_CLOSE$STEP1 Job UNIX étape 1 pour règlement mensuel du département de comptabilité financière au Royaume-Uni
UK.FIAC.JOBP#MONTH_END_CLOSE$MASTER Workflow principal pour règlement mensuel du département de comptabilité financière au Royaume-Uni
UK.FIAC.SCRI#MONTH_END_CLOSE$CHECK_FILES Script de vérification de fichiers pour règlement mensuel du département de comptabilité financière au Royaume-Uni

Conventions de nommage pour les objets globaux

Afin de simplifier la maintenance des processus, les objets globaux doivent être utilisés dès le début, c'est-à-dire, avant le transfert de tout processus vers le système de production. À titre d'exemple, les objets globaux peuvent déjà faire partie des modèles d'objets lors de la création de nouveaux processus.

Il s'agit par exemple des objets globaux de type Include (composants de scritps) pour toutes les cartes de script disponibles pour les objets, qui permettent par la suite la mise à jour rapide de multiples objets, ou de la définition d'au moins un objet central de type notification pour les terminaisons au sein d'un processus. Les deux exemples nécessiteraient non seulement la définition des objets correspondants mais également la mise à jour du ou des modèles d'objet(s) pour que les objets centraux soient disponibles pour tous les nouveaux processus. Toutes les tâches de processus existantes encore basées sur les anciens modèles devraient être adaptées manuellement. C'est la raison pour laquelle il est judicieux de prévoir l'utilisation de ces objets globaux le plus tôt possible.

Ce tableau fournit des exemples sur la façon de nommer et d'utiliser les objets globaux :

Nom d'objet

 Description
SYS.INC#JOBS_UNX.PRE

Include pour la carte de pré-script du modèle de job UNIX
SYS.INC#JOBS_UNX.SCRI Include pour la carte de script du modèle de job UNIX
SYS.INC#JOBS_UNX.POST Include pour la carte de post-script du modèle de job UNIX
SYS.CALL#OPERATING Include pour la carte d'attribut du modèle de Workflow (évaluation des résultats par tâche)

Conventions de nommage pour les objets exécutables

Les objets exécutables peuvent déterminer leur nom au lancement. Toutes les informations utiles contenues dans leur nom peuvent être utilisées pour configurer les paramètres de l'objet.

Exemple : Les conventions de nommage suivantes permettent aux utilisateurs d'inclure le nom du rapport SAP et sa variante associée dans le nom d'objet et distingue les jobs SAP des autres.

Nom d'objet (syntaxe)

 Description
<AA>.<BBBB.CCCC_DDD>#DESCRIPTION

Jobs généraux
<AA>.<BBBB.CCCC>_DDD>#<report>@<variant>#DESCRIPTION Jobs SAP

Les commandes de script Automation Engine permettant de décortiquer le nom sont de nouveau stockées dans des objets centraux de type Include. Ces Includes sont rajoutés aux modèles de job (SAP) dès le début de la constitution du système Automation Engine. De cette manière, chaque nouveau job créé possède déjà l'objet Include dont il a besoin.

Liens utiles

Cette rubrique contient des références vers un certain nombre de fonctions que vous souhaiterez peut-être connaitre un peu mieux.