topic Re: Stored process sessions in enterprise guide in SAS Enterprise Guide

Stored process sessions in enterprise guide

TimCampbell — Tue, 06 Aug 2013 10:27:44 GMT

Hi,

I am trying to get some stored processes to use stored process sessions to access the same work area using the SAVE library that is defined when a stored process session is created.

I need to be able to trigger one stored process in Enterprise Guide, view the results and then trigger a second stored process to run in the stored process session that was created by the first.

Does anyone have any idea how to do this? All the documentation I found online only covered using a web front end for this.

Tim Campbell.

Re: Stored process sessions in enterprise guide

jakarman — Tue, 06 Aug 2013 11:32:04 GMT

Tim, The web concept is build to be "stateless" no information is being held from to the next page. A Transactional approach would be impossible. To solve that the concept of sessions (like cookies) has been implemented. So sessions are bound to the web.

With Eguide you are getting bound to a WS or a SP server.

- When the WS is bound to your personal keys and handling your SP request this can be the same session (no mp-connect)

- When the request is going to a SP server it will one that is often one of several for serving load-balancing.

The best approach designing logic moving form 1 step (SP) to a next one would be a permanent like dataset defined to you project.

You could call it "StagingArea" as an often used naming convention.

Do not forget to add the logical checkings into your processing.

Re: Stored process sessions in enterprise guide

TimCampbell — Fri, 09 Aug 2013 10:53:38 GMT

Thanks Jaap,

I have gone down the route or creating a staging area for the data that needs to be shared across stored processes.

I created a macro that will create me a new directory called tmp_&SYSPROCESSID that I can use to store the data in a way that is uniquely identifyable to all programs or stored processes triggered from an EG session.

I want to make this as generic as possible for future developments so do you know if there is a nice simple function or macro variable that I could use to identify if my code is running in stored process environment or not?

I want different parts of the macro to run for a stored process compared to an EG program.

Tim

Re: Stored process sessions in enterprise guide

jakarman — Fri, 09 Aug 2013 11:52:41 GMT

There are a lot of options to think about.

I was thinking of a fixed functional process.

program A1 - processing data and creating temporay data for a next program say B2

program B2 - processing data and incorporating temporory data coming from program A1

As A1 en B2 are part of a project and these are scheduled by hand with no session requirment ->

... The easy approach is defining a permanent locations and name it "StagingArea"
The deletion and checking should be part of the program/project design.

IF you think on keeping a dataset during a shorter period of time like a web-session the logic-requiremet is different.

WS:

IF you have followed the advice of WS running by the personal-key. Than that key is unique having an own SASWork area.

Closing a WS-session should close all. (sysprocessid is an random number during the lifetime of a WS stable)

The additional data could be created as submap of SASwork. The physical name can be retieved by: %sysfunc(pathname(saswork))

This only works when no Mp-connect is involved. In that case and the requiement of possible sharing a temporay file at the %sysfunc(pathname(sasuser)) could be a solution. This only when sufficient storage is setup for that.

SP:

These are started at first request and will run some time running at their Own process possible serving several requests from different users.

Here you need to know the metauser-id. _Metauser is a macrovariable. The processid will be possible shared by multiple users as that is what a SP does.

If you have a naming convention of personal keys and those of that SP's that differentiates well you could use &SYSuser to know whether a WS or SP is running. _Metafolder and _program are macrovars dedicated for SP's

There are a lot of macro-variables being used. The standard base ones and those with SP's

SAS(R) 9.4 Stored Processes: Developer's Guide (Using Reserved Macro Variables) See SYSProcesname as anew feature.

SAS(R) 9.3 Stored Processes: Developer's Guide

The common base macrovars are:

SAS(R) 9.4 Macro Language: Reference (Automatic Macro Variables) SAS(R) 9.3 Macro Language: Reference

Re: Stored process sessions in enterprise guide

jakarman — Fri, 09 Aug 2013 13:02:46 GMT

Tim,
It will try it to do short (lost all first attempt)

SAS(R) 9.3 Stored Processes: Developer's Guide (Using Reserved Macro Variables) wordt uitgebreid met SAS(R) 9.4 Stored Processes: Developer's Guide (sysprocessmode) SAS(R) 9.4 Macro Language: Reference

The following could be used now I suppose: _metauser _program _metafolder and SYSUSERID (the last one I have Always used).

OPtions:

a/ fixed stagingarea as part of a project

My situation was a fixed solution as part of a project needing a staging dataset for data going from program A to Program B. Not session related but as flow of a logic. (ETL like)

b/ WS session related

This session is normally started/stopped running by personal key (well defined OS security). By that you can place

b1/ Staging-area like a SASWork (storage location). With Mp-connect processing it will create many of those

b2/ Staging-area like a SASuser (storage location). Wiht MP-connect all of them will share this (watch/care locking)

the physical naming of those existing libname can be retrieven by %sysfunc(pathname((SAS...))

c/ SP session related

This session is serving possible many users after being started automatically by the first one.

You will need &_METAUSER to do some segregation and decide in temporary path for it.

&SYSUSERID is the OS-level key running the process.
A simple method for recognizing sassrv and alike keys is an easy segregation between SP en WS processing.

This also allows in ohter ways of running processes, the only requirement is a well designed OS (host-security) layer.