With SAS® 9.3 the SAS code for a Stored Process can be located in metadata rather than located the file system (as was required with earlier versions). I had often wondered whether this meant the SAS code was really in metadata or whether it appeared to be in metadata but was really kept in the SAS Content Server (as is done with SAS Web Report Studio report definition .srx XML files). I don’t like not knowing the answers to questions, even ones I ask myself, so today I went looking for an answer.
I remember hearing about this new SAS 9.3 feature a while back on Angela Hall’s Real BI for Real Users blog. In her 2011 post Metadata source code storage in 9.3 stored processes she explained some of the benefits.
To try to answer my question about where the source code was located (metadata or WebDAV), I created a very simple stored process (but with a very grand name) and selected the option to “Store source code in metadata” and then clicked the Edit Source Code… button and added some code.
After creating the stored process with metadata located code, I logged into the SAS Content Server and looked for a .sas file in the equivalent WebDAV folder. I couldn’t find it. This suggested it was indeed located in metadata. I then used our Metacoda Metadata Explorer plug-in to search for the stored processes metadata and browse it’s attributes and associations (the SAS metabrowse tool can also be used to view this technical metadata). I saw the SAS code in an associated TextStore object confirming that the stored processes code is stored in the metadata repository (rather than in WebDAV).
So why does it matter whether it’s in metadata or WebDAV? Other than answering a nagging question I had been wondering about for a while now? Well, one of the benefits of having the source code located in metadata is that the entire stored process, metadata and code, is in metadata and would therefore be role-forward recoverable purely from metadata.
Which reminds me of a 1970’s commercial for the Museum of Science in Boston, the theme of which was, “It’s fun to find out.”
As SAS programs don’t usually occupy lots of space, I think it’s a good option to store the program in metadata. It’s also one fewer “moving part” to get involved when adding/editing/running stored processes. You don’t have to worry about file system nuances or web tier glitches — rare in a properly configured system, but sometimes tricky to track down if things go wrong.
So true Quentin!
Good points Chris. It made me realize that it also means no discrepancy between metadata access controls and file system access controls for the SAS code too (leaving only the stored process data sources/targets to consider). No more incorrectly moved/renamed .sas code either. Nice.