A Home for my runMacro Stored Process

In my last post I talked about my runMacro Stored Process and one approach for storing/managing the macro code. Now it is time to talk about where to store the stored process code itself.

In the SAS Metadata (using SAS Management Console, aka SMC) you can define a logical hierarchy for your Stored Processes which is completely independent of how/where they are physically stored.

For the physical location on the file system, I like to use a directory structure comparable directory comparable to how Macros are organized for my Stored Processes, e.g.,

• /Projects/ProjectA/storedProcesses
  
• /Projects/ProjectB/storedProcesses
  
• . . .
  
• /Projects/Tools/storedProcesses
  

So, I would stored my runMacro stored process as /Projects/Tools/storedProcesses/runMacro.sas.

Given that the folder hiearchy in the SAS Metadata can be different, there are lots of options for packaging the runMacro Stored Process. Two examples (and there are lots of variations) are described below.

A single Stored Process

This option has the advantage that it can be used to run any macro in any of my project (or application) specific autocall libraries. So the location/name of the Stored Process in SMC might be:

• /Projects/Tools/runMacro

with Project as a required parameter (perhaps with a default that pointed to the Tools autocall macro location).

This has the advantage that one can easily run any macro merely by providing a value for Project in the hyperlink or HTML form.

Project Specific Stored Processes

Recall that the location in the SAS Metadata is completely independent of the physical location of the code. So we can have multiple instances of a runMacro Stored Process defined in SMC. Specifically, we can create

• /Projects/ProjectA/runMacro
  
• /Projects/ProjectB/runMacro
  

Note that

• there is no need for a folder hierarchy that specifies that these are Stored Processes
• the file extension of sas is not used as that is an artifact of the physical implementation.
• both Stored Processes can point to the sas program

Using this option, you would define Project as a parameter that is not viewable or editable. The instance in the ProjectA folder would have ProjectA specified as the default value and the instance in the ProjectB folder would have ProjectB specified as the default value.

Such an approach allows you to have completely separate macro libraries for the two projects (but with shared macros still available). As a result you can use the security features availble in SMC to specify what users/groups are allowed to run the ProjectA or the ProjectB macros.