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

Overview of Sessions

The Web is a stateless environment. A client request to a server does not know about preceding requests. The Web is a simple environment for client and server developers, but it is difficult for application programmers. Often, programmers want to carry information from one request to the next. This is known as maintaining state. Sessions provide a convenient way to maintain state across multiple stored process requests.

A session is the data that is saved from one stored process execution to the next. The session data consists of macro variables and library members (data sets and catalogs) that the stored process has explicitly saved. The session data is scoped so that all users have independent sessions. For more information, see ..

Creating a Session

The stored process must explicitly create a session with the STPSRV_SESSION function, as follows:

 In macro
 %let rc=%sysfunc(stpsrv_session(create));

 In DATA step or SCL
 rc=stpsrv_session('create');

Creating a session sets the global macro variables _SESSIONID and _THISSESSION and creates the SAVE session library.

Using the Session

A session saves all global macro variables whose names begin with SAVE_. For example, the following statements cause the macro variable save_mytext to be available in subsequent stored processes that share the same session:

 %global save_mytext;
 %let save_mytext="Text to be saved 
 for the life of the session";

Data sets and catalogs can also be saved across program requests using the SAVE library. Data sets and catalogs that are created in or copied to this library are available to all future stored processes that execute in the same session.

Creating a session causes the automatic variables _THISSESSION and _SESSIONID to be set. Sample values for these variables are as follows:

 %let rc=%sysfunc(stpsrv_session(create));
 %put _SESSIONID=&_SESSIONID;
 _SESSIONID=7CF645EB-6E23-4853-8042-BBEA7F866B55
 %put _THISSESSION=&_THISSESSION;
 _THISSESSION=/SASStoredProcess/do?_sessionid=
    7CF645EB-6E23-4853-8042-BBEA7F866B55

These variables can be used to construct URLs or HTML forms that execute another stored process in the same session. For example:

 %let rc=%sysfunc(stpsrv_session(create));
 data _null;
 file _webout;
 put '<HTML>';
 put '<BODY>';
 put '<H1>Session Test Page</H1>';

 /* Link to another stored process in the same session */
 put '<A HREF="' "&_THISSESSION" 
 '&_PROGRAM=/Test/Test2">Test</A>';
 put '</BODY>';
 put '</HTML>';
 run;

Note: The _THISSESSION variable is not identical to the _THISSESSION variable that is used in SAS/IntrNet. If you are converting an existing SAS/IntrNet program to a stored process, any references to symget('_THISSESSION') should generally be replaced with "&_THISSESSION". For more information, see Converting SAS/IntrNet Programs to SAS Stored Processes.

Deleting the Session

Sessions expire after a period of inactivity. The default expiration time is 15 minutes. The expiration time can be changed using the STPSRVSET function, as follows where the time-out is specified in seconds:

 In macro
 %let rc=%sysfunc(stpsrvset(session timeout,300));

 In DATA step or SCL
 rc=stpsrvset('session timeout',300);

If the session is not accessed for the length of the time-out, the server deletes the session, the associated SAVE library, and all associated macro values. Any further attempts to access the session result in an invalid or expired session error.

Sessions can be explicitly destroyed using the STPSRV_SESSION function, as follows:

 In macro
 %let rc=%sysfunc(stpsrv_session(delete));

 In DATA step or SCL
 rc=stpsrv_session('delete');

Submitting this code does not immediately delete the session. The session is marked for deletion only at the completion of the stored process. For this reason, a stored process cannot delete a session and create a new session.

Limitations

Stored process sessions are supported only by the stored process server. Stored processes that execute on a workspace server cannot create or access sessions.

A session exists in the server process where it was created. All stored processes that access that session must execute in the same server process. Load balancing and other execution dispatching features are typically ignored when using sessions that might have an impact on application performance and scalability. Sessions are not recommended for applications with small amounts of state information; use a client-based method for maintaining state instead.