You can sign off from a SAS/CONNECT session by using Run X Signoff. No arguments are necessary, since the default is to sign off from the currently active session.
Remote Compute Services
Following a successful signon, the RSUBMIT command is used to send the program to the remote system, where it executes as shown in the following example:
Example 4.6 Remote Compute Services
rsubmit;
proc tabulate data=SASHELP.RETAIL;
title "Retail Sales In Millions Of $";
class YEAR/descending;
var SALES;
table YEAR="" all="Total", SALES="" * (sum="Total Sales"*f=dollar8.
pctsum="Overall Percent"*f=8.2 n="Number of Sales"*f=8.
Chapter 4 Remote Access to SAS 89
mean="Average Sale"*f=dollar8.2 min="Smallest Sale"*f=dollar8.
max="Largest Sale"*f=dollar8.)/
box="Year" rts=8;
run;
endrsubmit;
The results are generated remotely but displayed on the local system. The ENDRSUBMIT statement signals SAS to stop sending program statements to the remote system and start executing locally again. Note that on the procedure statement, the data set name
SASHELP.RETAIL refers to the copy of the library on the remote server, not the local version.
In addition to Remote Compute Services, SAS/CONNECT also supports the following:
Remote Library Services – similar to SAS/SHARE
Data Transfer Services – upload and download of SAS data sets
Remote SQL Pass-Through – similar to SAS/SHARE
The online documentation for SAS AppDev Studio includes a detailed explanation of when it is appropriate to use SAS/CONNECT as opposed to SAS/SHARE. Generally, SAS/CONNECT will do everything that SAS/SHARE can do and more, but the latter choice may be somewhat easier to deploy, since it has fewer bells and whistles.
Distributed Computing with the Integrated Object Model
The complexities of managing Integrated Object Model (IOM) servers are covered in detail in Chapter 10, “Using the Open Metadata Architecture with the Integrated Object Model.” At this point, it is sufficient to note that IOM provides an alternative to SAS/SHARE and
SAS/CONNECT for sites where these products are not available. The difference between IOM and the two older products is in the way the server can be accessed. There are three ways to connect to an IOM server:
1. using SAS Enterprise Guide to run SAS programs on the remote host
2. using SAS Stored Processes, either from SAS Enterprise Guide or from a Web application 3. directly using the Java, C++, or Visual Basic classes supplied by SAS
Since these components require some background in configuring and running the Open Metadata Architecture, discussion of the IOM server will be deferred until the appropriate chapters later in this book.
Like the dinosaurs, who grew feathers and evolved into birds, the client/server model has grown wings for the 21st century. In this new approach, called the distributed object model, objects are packaged as components such as JavaBeans and COM objects. These objects are then distributed across the network using technologies such as CORBA and DCOM. For developers who need to implement this level of functionality, SAS Integration Technologies are available as a
comprehensive set of distributed object solutions; one would be hard pressed to find dinosaurs in North Carolina.
References
Client/Server
Lowe, Doug, and David Helda. 1999. Client/Server Computing for Dummies. 3rd ed.
Foster City, CA: IDG Books
Orfali, Robert, Dan Harkey, and Jeri Edwards. 1995. Client/Server Survival Guide. 3rd ed. New York, NY: John Wiley & Sons.
SAS Documentation
URL references are current as of the date of publication.
SAS Institute Inc. 2004. Communications Access Methods for SAS/CONNECT 9.1 and SAS/SHARE 9.1. Cary, NC: SAS Institute Inc.
http://support.sas.com/apps/pubscat/bookdetails.jsp?catid=1&pc=58986
SAS Institute Inc. 2004. SAS/CONNECT 9.1 User's Guide. Cary, NC: SAS Institute Inc.
http://support.sas.com/apps/pubscat/bookdetails.jsp?catid=1&pc=58984
SAS Institute Inc. 2004. SAS/SHARE 9.1 User's Guide. Cary, NC: SAS Institute Inc.
http://support.sas.com/apps/pubscat/bookdetails.jsp?catid=1&pc=58985
SAS Institute Inc. 2004. SAS 9.1.2 Management Console: User’s Guide.
Cary, NC: SAS Institute Inc.
http://support.sas.com/apps/pubscat/bookdetails.jsp?catid=1&pc=59903
C h a p t e r 5
Web Applications Programming
Server-Side or Client-Side? 91 The Common Gateway Interface 92 A CGI Example 94
Passing Parameter Values to Web Applications 96 References 100
Server-Side or Client-Side?
All of the Web page examples shown in Chapter 3, “Creating Static HTML Output,” are static.
That is, each page is the output of one or more batch procedures, the results of which are fixed and unchanging. An ordinary HTML page does not allow dynamic Web content; some kind of additional scripting is required for the Web page to be interactive. In general, there are two ways to accomplish this:
client-side Web programming using Java applets or JavaScript
server-side Web programming using CGI, PHP, ASP.NET or Java servlets and JSP The first approach is to create code that executes on the Web client. Programs of this type are stored on the server and are downloaded and run by the client, providing “just-in-time”
applications services. The appendices to this book cover some of the strategies for providing SAS content on the client using DHTML (Appendix A, DHTML: Dynamic Programming on the Web Client with JavaScript) and Java Applets (Appendix B, Client-Side Programming with
JavaApplets).
The main advantage of client-side programming is that it shifts the processing load from the Web server, allowing more simultaneous connections. However, there are several disadvantages as well:
The Web application program has to be compatible with the client. Many older browsers do not support all JavaScript functions, and applets require the Java plug-in to function fully.
Network traffic can increase as relatively large code segments are transferred to the client to be executed there.
Consequently, the decision as to where to locate Web applications programs depends on the type of application and the capabilities of the server and the network. Corporate Intranets may well have the bandwidth to support downloading applets, as well as the ability to make sure that all of the client systems have the necessary software installed. However, concern for these issues has led many developers to favor server-side applications programs for use on the World Wide Web.
A number of strategies are available for this, falling into two major groupings. The earliest approach to server-side Web programming was the Common Gateway Interface (CGI), included in the original NCSA HTTP Server. An alternative approach developed more recently is the use of embedded scripting languages. Of the latter, the most widespread are ASP.NET (Microsoft’s Active Server Pages), PHP (Linux-based freeware), and JSP (JavaServer Pages). Part 4 of this book discusses the last of these in detail, and shows how webAF software can be used to create dynamic Web applications.
SAS/IntrNet software, included as part of SAS AppDev Studio 3.1, provides two Web development tools based on the older CGI technology:
Application Dispatcher is a set of modules that allow parameters to be passed to SAS from Web pages.
htmSQL provides access to SAS data from a Web page.
Chapter 6, “SAS Intr/Net: the Application Dispatcher,” and Chapter 7, “SAS Intrnet: htmSQL,”
cover the use of each of these tools in turn. First, however, it is important to understand what CGI can and cannot do and how this affects Web development using SAS.
The Common Gateway Interface
Mosaic, the original HTML browser, was developed at the National Center for Supercomputing Applications (NCSA) located at the University of Illinois Champaign-Urbana. The NCSA scientists proposed a standard for serving dynamic Web content:
The Common Gateway Interface (CGI) is a standard for interfacing external applications with information servers, such as HTTP or Web servers. A plain HTML document that the Web daemon retrieves is static, which means it exists in a constant state: a text file that doesn't change. A CGI program, on the other hand, is executed in real-time, so that it can output dynamic information.
(http://hoohoo.ncsa.uiuc.edu/cgi/intro.html)
Note that CGI is not itself a programming language, any more than is HTML. CGI is simply a standard interface for programs that execute on the Web server. A Web page can include a request that asks the server to run a CGI script (written in C, Java, Visual Basic, or Perl) that supplies the requested service.
Chapter 5 Web Applications Programming 93
A CGI program is simply an applications program, installed on the server or accessible from it, that follows the rules required to work with the CGI standard. The most important of these rules specify where the program must be located, how it reads input parameters, and how it outputs the results.
One obvious problem with CGI scripts is one of security. As the NCSA documentation points out:
Since a CGI program is executable, it is basically the equivalent of letting the world run a program on your system, which isn't the safest thing to do. Therefore, there are some security precautions that need to be implemented when it comes to using CGI programs. Probably the one that will affect the typical Web user the most is the fact that CGI programs need to reside in a special directory, so that the Web server knows to execute the program rather than just display it to the browser. This directory is usually under direct control of the webmaster, prohibiting the average user from creating CGI programs. There are other ways to allow access to CGI scripts, but it is up to your webmaster to set these up for you. At this point, you may want to contact them about the feasibility of allowing CGI access.
(http://hoohoo.ncsa.uiuc.edu/cgi/intro.html)
As we shall see, a number of steps required to set up the SAS/IntrNet result from these security concerns. It is important to determine whether CGI access is allowed on your server at all; as pointed out previously, the Web administrator should be contacted to determine the appropriate directories, URLs, and permissions. In particular, running a CGI program on a server requires that the Web host be able to access the directory that contains the executable program. Usually, this directory is on the same physical platform as the Web server, although this is not required. The NCSA default was that the directory must be called cgi-bin, and all implementations of CGI since then have used this convention. (It is possible to customize the location of this directory so that more than one set of applications programs are available. How this is accomplished differs for Apache and IIS and is beyond the scope of this discussion; the developer is referred to the appropriate documentation.)1
SAS/IntrNet software is available in several versions for different operating system platforms.
SAS has used system specific methods for each. On Linux and UNIX systems, Web applications programs are implemented as binary executables in the cgi-bin directory; on the Windows platform, in contrast, they are implemented as Windows .exe files. In addition, if Microsoft IIS is used as the Web server, SAS/IntrNet application programs are installed in the scripts directory, not cgi-bin.
1 For the Apache HTTP server, see http://httpd.apache.org/docs-2.0/howto/cgi.html. Note that a number of security holes have been reported in installations using CGI scripts with IIS. Microsoft suggests converting from CGI to their proprietary ISAPI technology; see “Internet Programming Frequently Asked Questions” at
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore98/HTML/
_core_how_does_isapi_compare_with_cgi.3f.asp.
A CGI Example
In order to appreciate how SAS/IntrNet is implemented, you might find it useful to review some simple examples of server-side Web application programs. Most CGI programs are written in Perl, although this is not required. Perl (Practical Extraction and Reporting Language) has been around longer than the World Wide Web. It was originally developed as a UNIX scripting language, and it is still widely used for purposes that have nothing to do with Web programming, although it is sufficiently integral to Web development that it has been called “the duct tape of the Internet.”
(http://www.unixreview.com/)
The ubiquity of Perl scripts is a result of a combination of three factors:
Perl is available for free.
Perl is cross-platform, running on a variety of operating systems and hardware.
The standard Perl distribution has a built-in module, CGI.pm, to automate many common Web programming tasks.
The following examples are implemented as Perl scripts. A number of excellent online Perl tutorials are available. However, knowledge of Perl is not necessary for SAS/IntrNet developers;
consequently, it will not be covered here. 2 Nevertheless, it is instructive to see how CGI programming is generally accomplished using Perl scripts to dynamically generate Web content on the server. Example 5.1 shows some of the features of CGI scripting in Perl:
Example 5.1 Hello World CGI Program
#!/usr/bin/perl
##
## HelloWorld.pl – My first Perl program
##
use CGI ':standard'; # include CGI module
print header; # generate MIME content line
print start_html "CGI Examples"; # generate starting HTML tags
# print "Hello World"
print h1( { -style=>'color: blue; '}, 'Hello World!');
# generate date/time field
( $s, $m, $h, $d, $mm, $y ) = localtime(time);
$y+=1900; # convert 2-digit year to 4
$mm++; # months start with 0
print p( {-style=>'font-weight: bold; font-size: 24;'}, "The time now: $h:$m on $mm/$d/$y:");
print end_html; # generate ending HTML tags
2See http://directory.google.com/Top/Computers/Programming/Languages/Perl/WWW/ Tutorials/, and see the references at the end of this chapter.
Chapter 5 Web Applications Programming 95
Perl syntax might seem familiar to SAS programmers. Semicolons are used as statement
separators; most Perl programmers put them at the end of every statement. Coding is free format and the use of white space is encouraged. One important difference between Perl and SAS programming is that all Perl scalar variable names (including both numeric and character types) must begin with dollar signs ($). Comments start with pound signs (#) and can appear at the end of the line or as a separate statement. Perl PRINT statements are the equivalent of SAS PUT statements; they send any results to the standard output.
This program makes extensive use of Perl’s built-in HTML generating tools (and none at all of Perl regular expressions, which have befuddled many a programmer). Six standard functions are illustrated:
header – generates the MIME content-type line and is required if the output is to be displayed in a Web browser (generates line 1 in the previous example)
start_html – generates the XHTML heading (lines 2-10)
end_html – generates the XHTML footer (lines 14-15)
h1 – encloses the text in an HTML <h1> tag (line 11)
p – text is enclosed in an HTML <p> tag (lines 12-13)
localtime(time) – displays the current system time as an array of six numbers:
seconds, minutes, hours, day of the month, month and year
Generally, CGI scripts are initiated by a client application (usually a Web browser) and execute on the Web server, which then directs the output back to the client. It is possible, however, to run this program from the command line, with the resulting output (modified slightly for readability):
Example 5.2 Perl-Generated HTML Source
Content-Type: text/html; charset=ISO-8859-1
<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
lang="en-US" xml:lang="en-US">
<head>
<title>CGI Examples</title>
</head>
<body>
<h1 style="color: blue; ">Hello World!</h1>
<p style="font-weight: bold; font-size: 24;">
The time now is 10:44 on 12/22/2005.</p>
</body>
</html>
Specifying the Perl script filename in the URL causes the server to route the output of Example 5.1 to the client’s browser, with the result shown below.