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.,
- . . .
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 ProcessThis 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:
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 ProcessesRecall 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
- 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
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.