SAS 9.1.3 Integration Technologies » Developer's Guide

SAS Stored Processes
Software Requirements
Creating Stored Processes
Input Parameters
Result Types
Reserved Macro Variables
Stored Process Server Functions
Converting SAS/IntrNet Programs
Using Stored Processes
Building a Web Application
SAS Stored Process Web Application
HTTP Headers
Embedding Graphics
Chaining Stored Processes
Using Sessions
IOM Direct Interface Stored Processes
SAS Stored Processes


The Web is a stateless environment. A client request to a server knows nothing of any preceding requests. This creates 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. It 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. See Using Sessions for a sample Web application that uses sessions.

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

Creating a session will set the global macro variables _SESSIONID and _THISSESSION and create the SAVE session library.

Using the Session

A session saves all global macro variables whose names begin with SAVE_. For example, the statements

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

cause the macro variable save_mytext to be available in subsequent stored processes that share the same 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));

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" 
   put '</BODY>';
   put '</HTML>';

Note: The _THISSESSION variable is not identical to the _THISSESSION variable 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". See Converting SAS/IntrNet Programs for more information.

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

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

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

where the timeout is specified in seconds. If the session is not accessed for the length of the timeout, the server will delete the session, the associated SAVE library, and all associated macro values. Any further attempts to access the session will 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

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


Stored process sessions are supported only by the stored process server. Stored processes executing 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.