07-24-2016 08:25 PM - edited 07-24-2016 08:28 PM
EG 6.1 M1
I have a stored process that will be launched from EG using a workspace server (the processing must run under the end user's context).
Say I have two text prompts named FOO and BAR.
I would like to initialize those values when the user first launches the stored process. Say I want &FOO=ABC and &BAR=123.
I tried adding a program entry containing:
But unfortunately the current value of the macro variables is not picked up by the stored process prompt.
Also, if I RMB the process flow, I would expect the program entry to run, then the stored process to display. See attached picture.
1) Is there a way to initialize stored process prompts, without setting a default value in the metadata? That will not be an acceptable approach.
2) Why doesn't the program entry run if I RMB the process flow containing the two items (program and stored process)?
07-25-2016 02:48 AM
A stored process does not react to previously defined macro variables; it does this because the stored process server is a pooled server where every STP call can be executed in a different server instance. Therefore the "state" has to be kept outside SAS code, because every STP call is executed in a "clean" environment (or supposed to happen in one).
One way to do set prompt values is by keeping them in the URL when calling a STP from the web via /SASStoredProcess. But in this case, since the value is already provided, the prompt is not executed at all.
The only way to initialize default values for user prompts is in the metadata for the prompt itself.
In a small web app I created, I solved it like that:
When the STP is first called (via /SASStoredProcess), the URL contains dummy values for the prompt variables.
The STP recognizes them, and sets default values specified in the program code.
It then creates and displays a HTML web form with the default values.
Once the "submit" button is hit, the newly entered (or taken from the default) values are incorporated in the URL that calls the STP again.
The STP does its work and exits or comes back with a new form.
07-25-2016 05:33 AM
Which Server ist used for execution of the STP can be choosen in the Metadata definition of the Stored Process. So there is no need to call an STP using SAS Enterprise Guide to make it run on a workspace server.
For having a STP with prompts that should be individual by the user, there is no easy way using the standard prompting framework.
If you want the STP to pickup the prompt values from macros variables you have set earlier in your code, have a look at Proc STP.
Proc STP allows you to run the code for a Stored Process from a SAS program, see also the overview section in the doc, copied here for convenience.
07-25-2016 11:02 PM
Thanks for the replies so far. Some additional context may be useful:
For these and other reasons, the stored process will be launched from EG. The purpose of the stored process is to collect runtime parameters from the user via the prompt manager. Once the prompts (macro variables) are set, the user will submit another EG process flow and/or program entry to run a long-running program in "batch".
I'd rather use the SPWAS to collect the prompts, then submit a proper batch job on the server, with proper logging, etc. But ALLOWXCMD is not switched on the SPWAS.
I know I could just associate prompts with the long running job via EG, but I prefer the STP to collect the prompts. I don't want the end user fiddling with all the backend error checking on the prompt values.
My "real" program could have say 20 prompts, plus a selection group to display different prompts based on the user's choice. The workflow could be something like:
I have Use prompt value throughout project set for all the prompts.
One thing I have noticed is that the prompts persist across EG invocations; if I set prompts, close EG, open EG, and relaunch the STP, the prompts are as they were when the project was closed. Although I lose the previous settings from the other selection groups, which is a bummer.
So, I'm guessing the state of the prompts is buried in the EG project somewhere, with no direct way for the end user (or programmer) to change them other than via the Prompt Manager UI.
The end users are fairly advanced, and will want to view the SAS log when the process ends. They may also do minor tweaks to the base code of the program (which is readonly) before submitting the run.
I hope this context helps. If you know of a better approach, please let me know. (I will investigate whether the long running job can be a STP and I can use PROC STP to run the program "in batch"???).