Initializing the values of stored process prompts?

[ScottBass]

SAS 9.3

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:

%let foo=ABC;

%let bar=123;

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.

So:

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)?

Thanks,

Scott

[Kurt_Bremser]

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.

[BrunoMueller]

Hi

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.

Overview: STP Procedure

The STP procedure enables stored process execution from a SAS program. PROC STP can be executed in an interactive, batch, or server SAS session and can also be executed by another stored process.

The stored process executes locally, but it runs within an independent execution environment with its own WORK library and macro symbol table. Data, files, and macro values can be passed between the SAS environment and the stored process environment by using optional PROC STP statements.

Note: PROC STP must have access to the stored process metadata in order to locate the stored process source code. PROC STP also checks input parameters against the input parameters that are defined in the metadata. In order to specify the metadata server and connection profile to use with PROC STP, use the following system options: METASERVER, METAPORT, METAUSER, and METAPASS. Define these options before running PROC STP.

Bruno

[ScottBass]

Hi,

Thanks for the replies so far.  Some additional context may be useful:

• Due to my site's security requirements, the stored process must run under the workspace server, and under the logged in user's context.
• Therefore, the sassrv user has not been setup in the correct AD groups to access the source data anyway.
• While this doesn't preclude the use of the Stored Process Web Application Server, it does prevent a "streaming" stored process, which is a bummer.

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:

• User sets the initial 20 prompts
• Next week the user changes say 5 of them, and does another run
• Next week the user changes say 3 of them, and does another run
• Next month the user changes all 20 prompts
• Rinse and repeat

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"???).

Kind Regards,

Scott