| This post was kindly contributed by Business Intelligence Notes for SAS® BI Users - go there to comment and to read the full post. |
SAS Programmer meets SAS Enterprise Guide Process Flows
When an old school SAS programmer meets Enterprise Guide, I suspect often the first questions are along the lines of “what’s a Project?” “what’s a Process Flow?” and of course “Why do I need them, can’t I just code???” The honest answer is yes, you can open Enterprise Guide, open a code window, and just code. But I’ve found that process flows are useful to me as a programmer, even though I use them in a non-traditional way.
The “Bad”
First, process flows are not really “bad.” But if you like to write code, process flows can seem like annoying window dressing at first glance. More importantly, I’ll do anything for a blog post theme, and I love a good Spaghetti Western.
Many introductions to Enterprise Guide start with an explanation of a process flow. As shown below, a process flow is a series of tasks (code modules) which will be executed in series.
The above process flow starts with a source dataset, PRDSALE, then the Summary Statistics task creating a summary dataset, and finally the Bar Chart task creating a chart. Each task node of process flow is SAS code generated by Enterprise Guide. The Summary Statistics task is PROC MEANS. The Bar Chart task is PROC GCHART. The arrows connecting the nodes are NOT SAS code. They are defined as part of the Enterprise Guide project file, but are not represented in the code. If you want to be able to run your code outside of Enterprise Guide, you can’t rely on process flows to define the order in which code should be executed. (Actually to be fair, there is an export utility in Enterprise Guide which will convert a process flow, including the connections, to a SAS program for you.)
Modular programming in SAS is a good idea. SAS programmers may employ a variety of methods to support modular programming, without relying on Enterprise Guide node connectors. One approach is to have a driver program, driver.sas, which invokes other SAS programs via %include calls. Another approach is to use the macro language to define and invoke modules. (For more on structured programming in SAS, see this excellent paper by Ed Heaton.) These methods allow you to develop a logical process flow (i.e. code modules/nodes executed in sequence, perhaps with conditional logic controlling which modules execute), without requiring that code be executed in Enterprise Guide.
The Good
When I said that process flows are “bad”, what I meant was that I don’t like the connections in process flows, because I like to write those connections myself in SAS code. And I don’t like clicking menus to generate nodes of SAS code, because I find it easier to just write SAS code myself. And I don’t know (and don’t really want to learn) how to debug a process flow, because I’m more comfortable debugging SAS code. But I love that process flows provide a great visual interface to my SAS code.
Suppose I’m working on a stored process which generates a simple report. I might end up a process flow which looks like:
The process flow serves as a desktop with links to everything I need for a project. The first icon is the stored process. This is one of my minimalist stored processes, so it %includes RunReport.sas, which in turn %includes GetData.sas, MakeTable.sas, and MakePlot.sas. If I want to update the stored process itself (change which server it executes on, or update the prompts), I open the stored process. If I need to modify the plot, I open MakePlot.sas. The actual .sas files are sitting in our standard directory structure. Every icon in the process flow is a link. I often add links to secondary items in the process flow as well. These might be links to code samples, utility macros, descriptive notes, even non-SAS files such as Word documents with data dictionaries, or meeting minutes.
I love using process flows for this sort of organization. Over time I’ve become a big fan of modular programming. I have grown so fond of using an Enterprise Guide process flow as a desktop providing easy access to all of my shortcuts for a project, that now when I am using DM SAS it sometimes feels like a hassle when I have to open a code module (File->Open->navigate through windows dialog box… ugh).
Multiple Process Flows
I recently learned that a single Enterprise Guide project file can contain multiple process flows. When I don’t have access to separate servers for development, test, and production, I sometimes use directory structures to approximate these environments. In a /Project directory, I might have Project/Dev/Code, Project/Test/Code, and Project/Prod/Code. I’ve been playing with having separate process flows named Dev, Test, and Prod. With this setup, I can easily navigate among the “environments.”
The Ugly
Much as I’ve come to appreciate process flows, there is one ugly aspect to how I use them. I start with a pretty process flow like above, with all my links laid out precisely in some visual organizational scheme. Then when I run code, Enterprise Guide adds new icons for the data sets created, output files, and log files. And my beautiful process flow becomes uglified by those icons and connectors:
These extra icons aren’t a problem, but I wish there was a way to keep them from being added. Actually, while writing this post I realized I can turn off generation of icons for output files by unchecking Tools->Options->Project Views->Show generated results. If anyone knows a way to turn off creation of icons for created datasets, please let me know.
What’s Your Process?
If you’re a SAS programmer using Enterprise Guide, do you have a favorite tip for developing or utilizing process flows? If so, please drop a note in the comments.
The post SAS Enterprise Guide Process Flows: The Good, The Bad, and The Ugly appeared first on Business Intelligence Notes for SAS® BI Users. Written by Quentin McMullen.
| This post was kindly contributed by Business Intelligence Notes for SAS® BI Users - go there to comment and to read the full post. |