Continuer à programmer avec SAS Enterprise Guide
Passer sous Enterprise Guide et poursuivre son travail de programmation
Date de publication : 09/12/2011. Date de mise à jour : 09/12/2011.
Par
DATAMETRIC 
Ce document liste les différentes méthodes de gestion d'un programme et d'accès aux données pour qu'un programmeur en SAS puisse, d'une part s'organiser après être passé du client traditionnel au nouvel environnement et d'autre part reprendre son travail.
I. Introduction
II. Présentation de SAS Enterprise Guide
II-A. Lexique de SAS Enterprise Guide
II-B. Présentation de l'interface
II-C. Présentation des modes de communication du client EG et d'un serveur SAS
II-D. Créer un profil dans EG
III. Utiliser les programmes dans un projet
III-A. Créer un programme
III-B. Ouvrir un programme
III-C. Sauvegarder un programme
III-D. Ce qui est à supprimer des programmes
III-E. Exécuter un programme
III-E-1. Exécuter le programme sur le serveur actif
III-E-2. Choisir entre plusieurs serveurs pour exécuter son programme
IV. Comment accéder aux données
IV-A. Accéder aux données par les menus
IV-A-1. Ouvrir une table SAS
IV-A-2. Ouvrir un fichier autre que SAS
IV-A-3. Conclusion
IV-B. Accéder aux données par le serveur
IV-B-1. Ouvrir une table SAS
IV-B-2. Ouvrir des données externes
IV-B-3. Conclusion
IV-C. Accéder aux données par l'assistant « Attribuer une bibliothèque »
IV-C-1. Conclusion
IV-D. Accéder aux données en ligne de commande
IV-D-1. Ouvrir un fichier SAS
IV-D-2. Ouvrir un fichier externe
V. Quelques fonctionnalités intéressantes de SAS EG
V-A. Créer plusieurs flux
V-B. Correspondance entre les PROC et les assistants
V-C. Formater le code
V-D. Analyser le code pour l'éclater en sous-programmes
V-E. Créer un flux Autoexec
VI. Conclusion et première stratégie d'utilisation
VII. Gestion des bibliothèques et tables META
VIII. Remerciements
IX. À propos de l'auteur
X. Liens
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é 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 session 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 connu à 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 si 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é 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.
| sas |
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 choisi. 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.
| sas |
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 n'ait eu à faire quoique 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 ajoutent 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 trouve 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 oeuvre 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.
X. Liens


Copyright © 2011 Stéphane COLAS. Aucune reproduction, même partielle, ne peut être faite
de ce site et de l'ensemble de son contenu : textes, documents, images, etc.
sans l'autorisation expresse de l'auteur.
Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 €
de dommages et intérêts.
Cette page est déposée.