I. Introduction▲
Cet article a pour vocation d'aider les utilisateurs du client traditionnel SAS à passer sur le client SAS Enterprise Guide (EG). L'idée de ce papier est venue de discussions avec des utilisateurs contraints de migrer vers ce nouvel outil par les évolutions technologiques de l'entreprise : en supprimant par exemple la possibilité d'exécuter bon nombre de programmes en local ou en imposant une migration vers SAS en client-serveur ou plus fréquemment, à arrêter la gestion des licences PC. Cela peut sembler surprenant, mais un utilisateur, habitué à se servir l'interface du client traditionnel de SAS, est très souvent dérouté par EG lorsqu'il souhaite travailler « comme avant » dans un éditeur de programme alors que cette nouvelle interface le contraint d'abord à créer un projet.
L'objectif de l'article est de présenter les différentes façons de gérer ses données et ses programmes afin que l'utilisateur du client traditionnel SAS ne soit pas surpris en découvrant l'interface Entreprise Guide et qu'il puisse sereinement choisir la stratégie d'utilisation qui lui convient le mieux.
L'interface EG offre plusieurs possibilités pour travailler avec : elle permet d'utiliser des assistants qui vont développer le code à la place de l'utilisateur ou de créer des programmes SAS similaires à ceux développés par l'utilisation du client traditionnel de SAS. Ces possibilités sont déroutantes au départ, car l'utilisateur n'est jamais certain d'avoir choisi la bonne méthode (pour accéder aux données, pour enregistrer ses programmes, etc.) et c'est encore une fois avec la pratique que les choses s'éclaircissent.
Après avoir réalisé dans une première partie une présentation générale et synthétique de SAS EG ainsi qu'un lexique des termes fondamentaux nécessaire à la compréhension du fonctionnement de l'interface, nous répondrons aux questions que se pose un programmeur du client traditionnel de SAS sur deux sujets primordiaux
- Comment utiliser les programmes SAS du client traditionnel dans un projet ?
- Comment accéder aux bases de données lors de l'utilisation de SAS EG ?
Une dernière partie présentera des fonctionnalités que l'auteur de cet article a jugées intéressantes avant de conclure sur quelques propositions dans l'utilisation des programmes.
Pour prolonger la discussion vers les environnements SAS BI, un chapitre en aparté proposera un premier niveau d'explication dans l'accès aux données au travers des LIBNAME META.
Nous illustrerons tout cela avec EG installé en local et :
- un moteur d'exécution installé sur le PC faisant office de serveur local ;
- un moteur d'exécution installé sur un serveur distant (qui peut être Windows, Unix, zOS).
Cet article se base sur les versions allant de EG 4.2 à 4.31. Quelques différences sont à noter avec EG 4.1, mais on retrouve globalement le même mécanisme.
II. Présentation de SAS Enterprise Guide▲
Rappelons que l'objectif de cet article n'est pas de détailler EG. Par conséquent, la présentation sera assez succincte et ne servira qu'à comprendre les fonctionnalités majeures de l'outil. Les détails des différentes configurations des modes de communication entre EG et le serveur SAS ne seront pas non plus exposés, car ce document suppose que l'installation et le paramétrage ont été réalisés par ailleurs par les administrateurs.
SAS Enterprise Guide est une interface développée en .NET et doit être considérée comme un studio de développement, c'est-à-dire un environnement de travail proposant des assistants pour l'extraction, la transformation et le chargement des données, ainsi que des assistants pour l'analyse statistique et le reporting. À côté de ces fonctions standards, l'interface propose des assistants pour exporter le code, améliorer la lisibilité des programmes SAS et ordonner l'exécution des projets.
L'objectif premier de l'outil est de permettre à un utilisateur de travailler avec les procédures SAS au travers d'assistants (environ 80) sans avoir à toucher une ligne de code. À partir de la version 4.3 des assistants viennent aider l'utilisateur d'EG à développer ses propres programmes. Il n'y a pas besoin d'être développeur SAS pour utiliser EG. Toutefois, l'expérience montre que les programmeurs avertis savent anticiper le code généré par EG et comment l'amener à être plus performant (ou moins catastrophique).
L'outil permet également de mêler l'utilisation d'assistants avec du code développé par soi-même. C'est idéal lorsqu'il s'agit de récupérer des morceaux déjà développés ou tout simplement d'incorporer des macro-programmes là où les assistants sont incapables de répondre au besoin de l'utilisateur.
L'outil Entreprise Guide exploite les composants Windows et peut être enrichi de nouveaux assistants développés en C# ou VB par exemple, par l'utilisateur ou par ceux que SAS fournit sur son site (le lien se trouve en dernière partie du document).
II-A. Lexique de SAS Enterprise Guide▲
Un projet
EG permet à l'utilisateur d'organiser le travail d'analyse ou de gestion des données dans un fichier appelé « projet » qui est un fichier non éditable dont l'extension est egp. Il contient les références aux données utilisées ainsi que les synthèses générées.
Avec EG, on ne peut travailler que sur un seul projet à la fois. Pour travailler sur plusieurs projets en même temps, il faut ouvrir autant de sessions EG que de projets. Autant de sessions SAS indépendantes seront alors ouvertes sur le serveur.
Un flux de processus
Un flux de processus permet de regrouper les objets d'un projet entre eux. Plusieurs flux peuvent être créés lorsqu'il s'agit d'obtenir un flux par besoin fonctionnel. Par exemple, un flux pour l'extraction des données, un flux sur les analyses, etc.
Les assistants
On dénombre à peu près 80 assistants, ce sont des interfaces multifenêtrées entre l'utilisateur et le code SAS. Les fenêtres des assistants sont composées de cases à cocher et de boîtes à remplir par l'utilisateur à partir de listes de variables ou de valeurs issues de la ou tables sources. Le plus connu étant « Filtre et requêtes » qui est une interface pour la proc SQL. Une fois les renseignements fournis par l'utilisateur, l'assistant stocke dans le projet le code correspondant.
Un programme
Pour activer l'éditeur de programmes, il convient simplement d'ouvrir ou de créer un programme dans le flux de processus. L'éditeur est similaire à celui du client traditionnel. Il possède la coloration syntaxique dans toutes les versions et, à partir de la version EG 4.3 : la saisie semi- automatique, le formatage automatique, l'aide contextuelle et la correspondance des parenthèses. La LOG apparaît lors de l'exécution dudit programme et chaque exécution annule et remplace la LOG précédente.
Un serveur
Ce terme désigne la machine sur laquelle l'utilisateur va ouvrir une session de travail (on se réfère dans la documentation à l'ouverture d'une workspace session) et exécuter son programme ou son projet.
Cette session peut être sur la même machine physique que EG, on parle alors de serveur local et correspond à l'ouverture d'une session SAS en arrière-plan sur le poste. Autrement le serveur peut être distant, sur une machine Unix, zOS ou Windows.
Depuis une même session EG, il est possible de passer d'un serveur local à un serveur distant, ou d'un serveur distant à un autre. C'est à l'utilisateur de choisir où d'exécuter son traitement, mais le passage de l'un à l'autre n'est pas aussi souple que ce que permet de faire le module CONNECT, car cela revient à clore sa session d'origine pour en ouvrir une nouvelle.
II-B. Présentation de l'interface▲
L'interface est organisée autour d'un espace de travail nommé par défaut « flux de processus » dans lequel on y met les programmes ou les tâches issues des assistants.
Interface SAS Enterprise Guide 4.2 et 4.3.
La barre de menus déroule les mêmes fonctionnalités qu'un client Office (Fichiers, Edition, etc.), puis enchaîne avec les tâches spécifiques à EG.
Dans l'interface EG 4.1, deux bandeaux permettent d'accéder aux tâches directement ou bien au serveur d'exécution. Dans les interfaces plus récentes, les bandeaux sont regroupés avec le gestionnaire des paramètres dans un menu spécifique. Autant les bandeaux étaient visibles sur la droite de l'interface en 4.1, autant désormais le nouveau menu se retrouve en bas à gauche avec une barre de sélection spécifique permettant de passer des serveurs aux assistants ou encore aux macro-paramètres (ces fenêtres d'invites amenant une interactivité entre le projet et l'utilisateur avec la gestion de macro-variables renseignées par l'utilisateur et utilisées dans les assistants).
- Dans l'interface EG 4.2+, il faut noter l'apparition des OLAP servers qui permettent de se connecter au serveur OLAP et d'accéder aux cubes SAS. Curieusement, il n'est pas possible de les enlever sans passer par un serveur de métadonnées.
Note : si l'environnement de travail ne correspond plus à la visualisation faite ici ou à celle que vous avez connue à la première ouverture, il est possible de revenir à l'organisation initiale des fenêtres en cliquant sur Outils > Options puis sur le bouton « Restaurer la disposition des fenêtres ».
II-C. Présentation des modes de communication du client EG et d'un serveur SAS▲
Pour travailler avec EG, il est nécessaire de l'installer dans un environnement Windows. Comme l'assistant va générer du code, il faut un serveur pour l'exécuter, car l'interface en elle-même ne contient aucun module SAS.
C'est bien le premier point à comprendre, car selon le mode ou les modes de communication permis, la stratégie d'utilisation de l'outil varie fortement.
- Pour faire fonctionner EG avec un serveur local, il faut avoir le module Integration Technologies (IT) sur la machine. Le serveur local est déclaré dans les profils utilisateurs de EG. Par défaut, ce serveur se nommera LOCAL dans la liste des serveurs.
- Pour faire fonctionner EG avec un serveur distant, il faut le module IT sur le serveur pour pouvoir communiquer avec les métadonnées ou bien avec un Object Spawner. Ce dernier point n'est vrai que pour EG 4.1 ; il est alors possible de se connecter à un serveur SAS 9.1 ou 9.2 en déclarant la machine distante dans l'explorateur de EG. Au-delà de la version 4.1, un serveur de métadonnées est requis. Dans ce cas, les serveurs d'exécution (appelés dans la documentation Workspace servers) visibles par l'utilisateur ont été préalablement créés dans les métadonnées. Par défaut, si le serveur est déclaré dans les métadonnées il se nomme SASMAIN pour EG 4.1/SAS9.1 et SASAPP pour EG4.2+/SAS9.2+. Par contre, l'utilisation d'un Object Spawner laisse l'utilisateur libre dans le nommage du serveur.
Il est possible également de faire communiquer un serveur LOCAL et un serveur distant au travers des modules CONNECT installés en local et sur le serveur. L'utilisateur rompu à l'usage des blocs rsubmit; . endrsubmit; peut concevoir des programmes manuellement et les exécuter sur le serveur. La déclaration dans l'explorateur EG est donc inutile. Ensuite, il est obligatoire d'avoir le module BASE sur le serveur d'exécution. Le reste des modules à acquérir dépend des besoins des utilisateurs.
II-D. Créer un profil dans EG▲
L'utilisateur qui se connecte à EG doit créer un profil. En termes d'administration BI, cela regroupe les informations permettant de se connecter à un serveur de métadonnées.
Lorsque le serveur est réalisé en local, il faut SAS installé sur le poste. Il est alors nécessaire d'indiquer à EG qu'aucun profil n'est nécessaire. L'utilisateur doit alors cliquer sur Outils > Options > Administration puis Modifier le profil. Il faut alors choisir < Ne pas utiliser de profil > et cliquer sur Activer. Tout le travail se fera en local.
Lorsqu'un serveur de métadonnées est utilisé, il convient d'ajouter un profil avec les renseignements fournis par l'administrateur. Après activation du profil, l'utilisateur pourra exécuter ses traitements sur un serveur défini dans les métadonnées.
Dans l'illustration suivante, la connexion au serveur distant Windows via le port 8561, permet à l'utilisateur de travailler sur deux serveurs d'exécution ayant des paramètres spécifiques.
III. Utiliser les programmes dans un projet▲
Comme nous venons de le voir précédemment, l'interface EG oblige à travailler dans un projet qui va regrouper les références aux tables et les assistants déployés par l'utilisateur. Il peut également contenir un ou plusieurs programmes qui vont être soit la seule chose que l'utilisateur va développer, soit apparaître comme une brique du projet au milieu des autres assistants.
III-A. Créer un programme▲
Un programme peut être créé dans n'importe quel flux de processus. Il suffit de cliquer sur Fichier > Nouveau > Programme. L'éditeur s'ouvre alors et le programmeur peut travailler.
III-B. Ouvrir un programme▲
Un programme peut être ouvert dans EG s'il se trouve sur le réseau local ou sur le serveur d'exécution distant.
EG laisse également la possibilité de parcourir le serveur distant au travers de l'arborescence « Fichiers » (placé avec le menu des bibliothèques SAS) qui peut s'assimiler à l'explorateur Windows.
Si l'utilisateur recherche son programme dans cette arborescence et le trouve, il peut l'ouvrir dans le projet courant et travailler dessus. Si le serveur est sous Unix, il n'est pas nécessaire de descendre le fichier via un client FTP avant de l'ouvrir, car EG se charge du transfert.
III-C. Sauvegarder un programme▲
Le nouvel utilisateur doit comprendre que la création d'un projet est obligatoire dans l'utilisation de ce client SAS. Toutefois, il peut programmer ce qu'il a à réaliser puis ne sauvegarder que ce fichier .sas sans sauvegarder le projet. Par conséquent, si le programmeur souhaite toujours avoir des fichiers .sas et non des projets, il peut sauver ses programmes sans sauvegarder son projet.
Si le projet est sauvegardé après avoir travaillé sur un programme déjà existant, ce dernier sera référencé dans le projet EG sous la forme d'un raccourci. Lors de la réutilisation de ce projet, le programme SAS créé sera appelé par EG comme s’il s'agissait d'un %INCLUDE.
Un programme SAS peut facilement être incorporé à un projet EG. C'est un avantage lorsqu'un projet doit être transmis d'un chargé d'études à un autre, car si le raccourci du programme ne permet pas d'accéder au code (utilisateur sur deux sites différents, programme sauvegardé sur un répertoire non partagé.), il ne pourra pas être appelé.
Plutôt que d'être stocké individuellement dans un répertoire, le code fait alors partie intégrante du fichier projet.
Autrement, le programmeur peut enregistrer simplement son programme sans ce projet. Il est nécessaire de cliquer sur le programme puis de sélectionner Fichier > Enregistrer le programme.
III-D. Ce qui est à supprimer des programmes▲
Indépendamment des modifications à apporter au chemin des LIBNAME lorsque l'on passe de son PC à un serveur, a fortiori Unix ou zOS, il est nécessaire d'enlever certains éléments des programmes, car ils ne fonctionneront plus.
Voici une liste des principaux éléments à supprimer :
- les appels DDE, si l'utilisateur n'est pas membre du groupe administrateur du serveur d'exécution ;
- les étapes WINDOW et les procédures comme la proc PMENU ;
- les composants AF
Voici la liste des éléments à valider selon la nouvelle architecture :
- tout élément lié au module CONNECT (Rsubmit, proc Upload, macro de type %SYSRPUT) est obsolète si aucun serveur local ne communique avec un serveur distant ;
- le lancement de commande système si l'option XCMD n'est pas activée dans le serveur d'exécution.
III-E. Exécuter un programme▲
Après avoir ouvert ou conçu un programme et s'être assuré que les données sont accessibles depuis les étapes DATA, celui-ci peut être exécuté.
III-E-1. Exécuter le programme sur le serveur actif▲
Le programmeur a deux possibilités :
- il fait un clic droit sur le programme et choisit « Exécuter Programme sur? ». Dans l'illustration, l'utilisateur a choisi d'exécuter ses traitements sur SASApp, l'un de ces deux serveurs ;
- il peut également utiliser la barre de menu du programme pour réaliser cette même action.
III-E-2. Choisir entre plusieurs serveurs pour exécuter son programme▲
Dans le cas où l'utilisateur souhaite changer de serveur d'exécution, il doit modifier le serveur dit « actif » par le menu du clic-droit : « Sélectionner un serveur » et prendre celui qui l'intéresse ou bien dans la barre de menu du programme. Dans l'illustration, le serveur choisi se nomme « SAS_Datametric ».
L'utilisateur peut alors demander son exécution.
SAS fera alors une demande de connexion au serveur puis exécutera le traitement. Aucune autre demande de connexion ne sera faite et l'utilisateur choisira avec discernement le serveur d'exécution pour ces prochains traitements.
IV. Comment accéder aux données▲
L'interface EG fut créée à l'époque pour des utilisateurs n'ayant pas le souci technique d'un statisticien rompu au développement en lignes de commande, aussi l'outil propose quatre façons d'accéder aux données, de la plus évidente dans une interface Windows à la plus traditionnelle en SAS.
- Par les menus : il est nécessaire de faire un effort de simplicité pour cette méthode et d'admettre que EG est bien une interface d'un client Windows.
- Par le serveur : l'utilisateur va chercher ses tables au travers du serveur. En ouvrant le serveur, il peut chercher ses tables dans les bibliothèques déjà déclarées. Il peut également les rechercher dans les répertoires accessibles au travers du menu « Fichiers ».
- Par l'assistant « Attribuer une bibliothèque » : destiné à l'affectation d'une bibliothèque dans un projet cet assistant permet de recréer l'étape LIBNAME.
- Par une ligne de commande : en créant un programme directement, l'utilisateur peut écrire une étape LIBNAME.
IV-A. Accéder aux données par les menus▲
Lorsque l'on est sur MS-Excel ou MS-Word, l'ouverture d'un fichier se fait via le menu Fichier > Ouvrir. Sous EG c'est une même possibilité et l'utilisateur féru du LIBNAME doit admettre alors que cette commande devient inutile.
Nota : en réalité, il n'a jamais été utile (mais confortable) d'utiliser un LIBNAME. Il est parfaitement possible de recréer par le code une situation similaire dans laquelle le développeur définit explicitement le nom et la localisation d'une table.
data test;
set "D:\Data\Observatoire\pme_adr.sas7bdat";
run;À première vue, le fait de passer par le menu permet de pointer sur un fichier de données SAS puis d'utiliser les assistants pour poursuivre son travail d'analyse. Lorsque le projet est sauvegardé, le raccourci vers le fichier de données est bien entendu conservé.
Comme le montre l'illustration suivante, en réalité, les fichiers de données accédés par le menu Fichier > Ouvrir ne sont pas obligatoirement des fichiers SAS. Un utilisateur va pouvoir indifféremment utiliser ce menu pour ouvrir un fichier ou une table SAS.
IV-A-1. Ouvrir une table SAS▲
Dans le cas des tables SAS, EG crée un raccourci dans le flux de processus. Un assistant peut y être attaché, mais il va être difficile de programmer sans LIBREF associé.
Il faut savoir que EG 4.3 peut lire les tables SAS en local sans un serveur local. Lorsque SAS Enterprise Guide analyses des données sur le poste en utilisant un serveur distant, il les lit en utilisant un connecteur SAS OLEDB et écrit les données dans la WORK sur le serveur distant dès qu'un assistant est connecté à cette table.
Dans l'illustration suivante, EG 4.3 est installé en local sans autre client SAS. Une table est ouverte depuis le répertoire Documents and settings du poste. L'assistant Filtre et requêtes rattaché à cette table est lancé sur le serveur distant AIX, mais ce n'est pas la seule action : une étape invisible à l'utilisateur monte la table dans la WORK auparavant afin que le traitement puisse avoir lieu.
Il faut noter qu'en EG l'exécution d'une tâche rattachée à une table en local ne fonctionne pas. Il faut installer l'assistant prévu à cet effet pour monter les tables sur le serveur en premier lieu.
IV-A-2. Ouvrir un fichier autre que SAS▲
Ouvrir un fichier autre que SAS aura pour conséquence de lancer automatiquement l'assistant d'importation de données sauf pour les tables STATA, SPSS ou JMP. Pour celles-ci, dans l'interface EG 4.2+, il est nécessaire d'ouvrir l'assistant Tâches > Données > Importer les données STATA ou SPSS ou JMP. Dans l'interface EG 4.1 cela n'est pas possible.
IV-A-3. Conclusion▲
Cette méthode doit être évitée si l'utilisateur souhaite développer un programme. En effet, il est plus cohérent de spécifier un LIBNAME, car le serveur ne saura pas comment pointer sur sa table si celle-ci ne se retrouve pas dans une bibliothèque affectée. Par cette méthode il ne pourra pas non plus accéder à des données dans un SGBD. Il faut un LIBNAME ou l'affectation d'une bibliothèque par l'utilisateur (ou par l'administrateur dans les métadonnées) sur le serveur d'exécution.
En conclusion, cette méthode ravira les utilisateurs ayant EG et voulant s'affranchir de la programmation. Pour les autres, cette mécanique est à déconseiller, car elle exploite des composants Windows invisibles pour le programmeur.
IV-B. Accéder aux données par le serveur▲
Cette méthode permet d'ouvrir une table dans les bibliothèques SAS définies dans le serveur ou les fichiers de données visibles au travers de l'arborescence « Fichiers » du serveur d'exécution.
IV-B-1. Ouvrir une table SAS▲
L'utilisateur peut glisser la table sur son flux de processus et utiliser les assistants pour poursuivre son étude.
Si l'utilisateur souhaite programmer son traitement, il devra identifier le LIBREF à associer à cette source pour l'utiliser dans ses étapes DATA ou PROC. La méthode la plus simple est de regarder les propriétés de la bibliothèque, car le LIBREF y est mentionné comme le montre la capture suivante.
IV-B-2. Ouvrir des données externes▲
Les fichiers pris dans l'arborescence « Fichiers » sont de toute nature. S'il s'agit de données externes à SAS, l'assistant d'importation des données sera lancé automatiquement et la table cible sera dans l'une des bibliothèques SAS que l'utilisateur aura choisies. Autrement, s'il s'agit de données SAS, le raccourci vers cette table apparaîtra dans le flux de processus.
Si l'utilisateur souhaite programmer l'importation, il devra spécifier le FILEREF à associer au fichier. Toutefois, le chemin n'est pas disponible via « Fichiers » comme le montre la capture suivante. On saura que le fichier est stocké dans un répertoire, mais la racine symbolisée par « Fichiers » n'est pas visualisable.
Si l'information ne peut être obtenue, la proc IMPORT ne pourra pas fonctionner. Si l'on essaye de prendre l'information fournie dans EG comme dans le code suivant, cela ne fonctionne pas non plus.
filename t "Observatoire des entreprises\2.Files\code commune.txt" ;
proc import datafile=t dbms=dlm out=work.test ;
delimiter=TAB;
run;L'assistant d'importation est à utiliser obligatoirement.
IV-B-3. Conclusion▲
Cette méthode est plus simple, car elle permet de pointer directement sur les tables d'une bibliothèque. Lorsqu'il s'agit de partir de données SAS au travers de l'arborescence « Fichiers », il sera difficile de programmer avec, car aucun LIBREF ne permet au serveur de les localiser. On retombe sur les mêmes problématiques d'ouverture de fichiers au travers du menu Fichier > Ouvrir.
En conclusion, l'environnement de travail se précise ici, car l'utilisateur prend forcément ses données là où le serveur d'exécution les voit. Cette méthode est plus robuste, car elle fonctionne même si EG n'est pas au même endroit que le serveur d'exécution. À noter que si l'utilisateur programme, il ne pourra pointer sur ses données qu'à la condition de connaître le LIBREF de la bibliothèque.
IV-C. Accéder aux données par l'assistant « Attribuer une bibliothèque »▲
Cette méthode se rapproche de l'usage courant des programmeurs et s'éloigne un peu plus de la simple ouverture de table par les menus.
On retrouve ici la conception classique d'une étude SAS dans laquelle la ou les bibliothèques sont définies en premier avant d'enchaîner avec des traitements sur les données.
L'outil d'attribution d'une bibliothèque est un assistant graphique pour l'instruction LIBNAME. Il permet de renseigner le LIBREF ainsi que le moteur de connexion et les chemins d'accès. Positionné en début de projet, l'utilisateur poursuit son projet ou son programme à partir d'une bibliothèque SAS visible sur le serveur.
L'assistant permet de pointer sur un répertoire auquel accède le serveur de traitement ou bien, si la licence le permet au travers des modules ACCESS TO, de pointer sur une base de données voire des fichiers SPSS, STATA, FAME, etc. L'utilisateur est alors libre de choisir s'il souhaite programmer ses traitements à partir de ce LIBREF connu ou bien d'utiliser les assistants.
IV-C-1. Conclusion▲
Cette méthode permet de pointer sur des tables SAS ou sur un SGBD comme à l'ancienne, mais à l'aide d'un assistant. Il pourra ensuite enchaîner indifféremment avec les assistants ou les programmes.
IV-D. Accéder aux données en ligne de commande▲
Cette méthode dérive de la précédente, car ce n'est ni plus ni moins que l'écriture directe du LIBNAME dans un programme.
IV-D-1. Ouvrir un fichier SAS▲
Les prérequis sont alors les mêmes que pour l'assistant. Il s'agit de pointer sur un répertoire auquel accède le serveur de traitement (local ou distant) ou bien, si la licence le permet au travers des modules ACCESS TO, de pointer sur une base de données voire des fichiers SPSS, STATA, FAME, etc. L'utilisateur est alors libre de choisir s'il souhaite programmer ses traitements à partir de ce LIBREF connu ou bien d'utiliser les assistants.
IV-D-2. Ouvrir un fichier externe▲
La méthode de programmation pure permet également d'éviter les assistants d'importation basés sur les composants Windows et de spécifier l'usage des PROC IMPORT. Encore une fois, le fichier à importer doit être visible depuis le serveur d'exécution et si celui-ci est positionné sur le poste local et que le serveur d'exécution est distant, jamais ce fichier ne pourra être atteint par la proc IMPORT.
En conclusion, cette méthode permet de s'affranchir de tous les assistants pour quelqu'un ne souhaitant pas en entendre parler et retrouver ainsi peu ou prou le même environnement de travail que sur le client traditionnel. Il bénéficiera des assistants syntaxiques des dernières versions de EG, mais rien d'autre.
V. Quelques fonctionnalités intéressantes de SAS EG▲
Progressivement, le programmeur va exploiter les assistants. Tout d'abord ceux qui aident à la programmation syntaxique, mais certaines nouveautés devraient assez vite attirer l'?il des curieux. Voici quelques facilités intéressantes, les autres restent à découvrir.
V-A. Créer plusieurs flux▲
Dans un projet EG, il est possible de créer plusieurs flux de processus tout comme l'on crée plusieurs onglets dans Excel. Cela permet d'organiser son travail selon différentes thématiques. Il est tout à fait possible de copier-coller les objets d'un flux dans un autre.
V-B. Correspondance entre les PROC et les assistants▲
Afin de ne pas rechercher durant des heures le nom d'un assistant, il est possible de partir du nom de la procédure et de retrouver la tâche associée. La liste des tâches est prévue pour cela.
V-C. Formater le code▲
SAS Enterprise Guide fournit une méthode en un seul clic pour le reformatage du programme pour le rendre plus lisible.
Un code non optimisé n'est pas facile à lire et à comprendre. Pour formater le programme SAS, clic-droit au sein de l'éditeur de programme et choisissez Format de code.
Le résultat est déjà plus lisible.
V-D. Analyser le code pour l'éclater en sous-programmes▲
SAS Enterprise Guide peut analyser un programme et proposer une transformation en un flux de processus.
Pour cela, il faut ouvrir un programme et cliquer sur le bouton « Analyser le programme ».
Une analyse est réalisée par SAS tout en exécutant le programme.
En cliquant sur « Créer un flux de processus » chaque étape du programme sera mise dans un programme spécifique. Tous ces programmes seront alors reliés entre eux comme des assistants.
Le résultat est un flux de processus avec des programmes pour chaque étape, ainsi que les raccourcis de chaque source de données référencée et bien entendu pour le résultat.
Espérons que dans une étape ultérieure d'évolution du client EG, le découpage en petits programmes puisse également amener à la transformation de l'étape en un assistant. On aurait ainsi visuellement le remplacement d'un programme traitant une proc SQL en un assistant Filtre et requêtes par exemple.
V-E. Créer un flux Autoexec▲
Lorsque l'utilisateur ouvre un projet existant, si un flux de processus dans le projet est nommé « Autoexec », SAS Enterprise Guide va l'exécuter automatiquement.
Il y a une nouvelle option pour contrôler ce comportement. Par défaut, SAS Enterprise Guide affichera un message de confirmation avant l'exécution automatique d'un flux « Autoexec ».
Il est possible de changer l'option de réglage de sorte à ce que ce flux s'exécute automatiquement.
VI. Conclusion et première stratégie d'utilisation▲
EG ne peut plus être perçu comme une simple surcouche à une session SAS. Il se base également sur des composants Windows pour accéder aux données et les visualiser, les importer et les exporter. Il apporte une aide au programmeur, certes perfectible, mais qui améliore la productivité.
Le programmeur souhaitant reprendre son travail développé naguère sur le client traditionnel sera dérouté par la profusion de possibilités d'accès aux données, de mélange des genres entre l'usage d'assistants et de ces programmes. Il faut donc veiller à adopter une démarche basée sur les indications faites dans ce document.
Fort de son expérience, le programmeur aura à cœur ensuite de profiter des nouvelles fonctionnalités et peut-être d'utiliser davantage les assistants que du code.
Ce tableau résume les principales recommandations dans l'accès aux données et dans la sauvegarde de ses programmes.
- L'utilisateur n'ayant aucun code doit sauvegarder le projet et peut ouvrir ses données soit par l'arborescence du serveur, soit par le menu fichier > Ouvrir.
- L'utilisateur ayant plusieurs programmes devrait sauvegarder le projet en incorporant les programmes dedans. L'accès aux données se fait par une commande LIBNAME lorsqu'aucun assistant n'est utilisé.
- Le programmeur ne souhaitant pas conserver des projets, mais un unique programme devra sauvegarder son code dans un fichier sas.
|
Utilisation de programmes |
Utilisation d'assistants |
Sauvegarde |
Accès aux données |
|
Non |
Oui |
Le projet est à sauver |
Tout type |
|
Oui |
Non |
Le projet est inutile pour un programme monobloc. Seul le .sas est à considérer. Si un flux contient plusieurs programmes, il vaut mieux sauver le projet. |
LIBNAME BASE lorsque les chemins sont connus |
|
Oui |
Oui |
Le projet est à sauver. Si des programmes sont ajoutés, ils devraient être incorporés |
LIBNAME si le programme est la première étape. Autrement, il faut commencer par un assistant |
VII. Gestion des bibliothèques et tables META▲
Ce chapitre est un aparté concernant la création des bibliothèques et leur mise à disposition depuis la SAS Management Console (SMC). Si le lecteur de l'article ne possède pas EG avec un serveur distant SASAPP ayant requis une connexion à des métadonnées pour une quelconque authentification, ce chapitre ne le concerne pas.
Avec la mise en place des métadonnées dans une architecture SAS (9.2/9.3 dans cet article, mais cela vaut pour la version 9.1), certains administrateurs techniques souhaitent fournir des bibliothèques de données. L'utilisateur de EG verra alors des bibliothèques dans son explorateur dès le démarrage sans qu'il ait eu à faire quoi que ce soit. L'objectif affiché des administrateurs est souvent de vouloir aider les utilisateurs en leur préparant ce travail, mais cela sert également à ne pas afficher certaines tables (du SGBD ou du répertoire) et d'autre part cela sert aux équipes informatiques qui utilisent les autres outils SAS comme Data Integration Studio (DIS) ou OLAP cube Studio (OCS) à accéder aux données.
Illustrons cela. L'administrateur de la plate-forme crée dans la SMC une bibliothèque pointant sur un répertoire contenant quatre tables de données sur les entreprises. L'administrateur renomme les deux tables concernant les PME et ajoute deux commentaires.
Un utilisateur de EG verra une bibliothèque n'ayant pas un nom respectant la convention de nommage usuelle. Mais à l'intérieur il verra les quatre tables avec les noms physiques et non pas les noms inscrits dans les métadonnées.
En réalité, tout utilisateur de EG voit les bibliothèques créées physiquement et dans les métadonnées et peut ensuite requêter librement dessus : même si les tables sont renommées dans les métadonnées, EG passe outre ces indications.
L'utilisateur de EG souhaitant programmer pourra donc accéder à ces tables en ayant préalablement assigné la bibliothèque par un clic droit sur celle-ci puis en cliquant sur « Affecter » ou bien en demandant à l'administrateur de les affecter automatiquement.
Autrement, les étapes DATA ou les PROC ne fonctionneront pas tant que l'affectation n'est pas faite (ce qui revient à lancer une commande LIBNAME sur le répertoire).
Si le programmeur voulait tout de même tenter de créer une étape DATA directement avec le LIBREF de la bibliothèque Observatoire, il pourrait le retrouver dans ses propriétés, comme le montre l'illustration suivante.
Malheureusement, le code suivant ne fonctionnera pas, car l'affectation n'est pas faite.
Si par contre, le programmeur utilise d'abord un assistant « Filtre et Requêtes » dans son flux de processus puis son programme, la bibliothèque sera affectée automatiquement.
Enfin, le programmeur exigeant de ne pas passer par un assistant et ne sachant pas où se trouvent ses données afin de produire son propre LIBNAME, devra alors obligatoirement ajouter un LIBNAME avec le moteur META à son programme. L'illustration suivante montre l'affectation du LIBREF MYDATA à partir des informations de « Observatoire » dans les métadonnées et une étape DATA basée dessus.
À noter que le programmeur pourrait reprendre, dans ce cas, le LIBREF de la bibliothèque « Observatoire » au lieu de créer une nouvelle bibliothèque dans son serveur (MYDATA en plus de « Observatoire »). Pour ce faire, il suffit de récupérer dans les propriétés de la bibliothèque le LIBREF et de l'exploiter dans sa propre ligne de commande.
Quant aux utilisateurs des autres clients SAS comme DIS qui se basent sur les métadonnées, ils ne verront que ce qui est proposé dans les métadonnées. L'illustration suivante présente l'interface DIS, l'ETL de SAS.
VIII. Remerciements▲
J'adresse tous mes remerciements à Fabrice Morlais et Jacques Thery de l'équipe de rédaction « Developpez.com » pour le temps qu'ils m'ont accordé pour la correction et l'amélioration de cet article.
IX. À propos de l'auteur▲
Stéphane COLAS dirige DATAMETRIC, société qu'il a fondée en 2002 pour proposer un ensemble de services autour du CRM analytique et dans le choix et la mise en œuvre d'environnements BI. D'abord statisticien, puis consultant et maintenant expert et enseignant à Paris-Dauphine, il mêle désormais des actions de conseil en architecture, de développement de bases de données marketing et de formations personnalisées auprès des équipes d'analystes.