EG is way cool for registering stored processes using the Stored Process Wizard -- but I consider EG to be the "automated" way to create your SP from either a task or an entire project or even from existing code.
When I create stored processes for the Stored Process class, however, I use good, old-fashioned DMS and then I manually register the SPs with SAS Management Console. Almost all of the SPs that I write for class are PROC REPORT examples, since that is currently something that you cannot do with EG.
In a regular BI configuration, there is already a location built in for your SAS macro library and your "code snippet" collection and your format library. Macro programmers do have to make a few changes to their macro code -- but the changes are minor and they should be able to convert their legacy programs to SPs fairly easily. This is the subject of one of my SGF presentations this year. Of course, my macro program won't be as complex as those used by most Pharmas, because I only have 50 minutes to talk.
At any rate, I don't think that Stored Processes are difficult to write. What was difficult for me was the "paradigm shift" from the DMS way of doing things to the BI way of doing things. But since I'd already gone through that same kind of shift with SAS/IntrNet, it wasn't such a huge change.
One of the notes in my SGF paper is the observation that "Stored Process Consumers Don't F3" -- and I'm just hoping that there are enough folks in the audience who actually use F3 enough to get the lighthearted joke. Of course, Stored Process AUTHORS might still use F3 -- but there's a real difference between how you test and debug the SP, as an author, and how the end user or SP consumer will experience and execute the SP.
For the really heavy duty SAS programmers, I agree that they may not do more than use EG in order to use the Stored Process Wizard. In class, we tell students that they don't actually have to open SAS to modify their programs and sometimes, I challenge them to make the required code changes just using Notepad -- which is an interesting exercise because it reinforces that in order to test their code, they have to break out of their dependency on DMS and actually test in the client applications.
But SAS in batch (via DMS or via command programs) still has a place in the BI platform -- there's no reason to put all of the nightly number-crunching and file updating into Stored Processes -- these processes might be better turned into DIStudio jobs or even kept as batch SAS jobs to update the appropriate files. Then you can let your SPs zip in and out of the data to do the on-demand reporting against the updated files.
So that's my 2 cents plus your 2 cents and we still can't go to Starbucks on that!
;-)
cynthia
... View more
