Homepage (deutsch) Firmenprofil (deutsch) Tools (deutsch) Homepage (English)

WS

SAS® Software Applications on an Application Server in the Intranet:
First Year Experiences

Wilfried Schollenberger
Paper held on SEUGI 1998 in Prague
(text version with additional technical hints)

Abstract

With SAS/IntrNet® software all users in an enterprise can easily access SAS applications without needing to install the SAS software on their workstations and even without any SAS know how. This paper discusses the basic differences between "fat client" and intranet applications and provides some hints on how to quickly transfer fat client solutions to an intranet platform.

Furthermore the paper discusses the different alternatives of implementing a SAS application server and introduces an easy and straightforward method of developing intranet applications.

The paper is based on extensive evaluations of the different available techniques and the implementation of a project management system at EURESCOM GmbH.

Contents

The Scenario

With SAS/IntrNet software SAS Institute offers a number of opportunities to bring the data and evaluations via an intranet or the internet to users who have not installed any SAS software. Depending on the goals you want to achieve, you will choose one option or a combination of the different techniques. In this paper I discuss how to provide the information from a data warehouse or another database to many users in a company, who regularly or seldom need some of this information. They need some way to access the information easily, but they do not need the whole power of the SAS® System for data analyses.

I also assume that you already have a TCP/IP network running in the company and that some kind of Web browser is installed on the user's PCs.

In this case it is quite easy to install an HTTP (Web) server and SAS/IntrNet software on one or more application servers. You simply set up the machines, connect them to the network, and every member in the company can access the applications.

In order to reach the goal of saving costs, the applications on the SAS application server should be:

support their tasks.

The easiest way to achieve these goals is to use the compute services of SAS/IntrNet software in combination with HTML.

The Advantages

At SEUGI 97 in Madrid some of us were discussing how the number of SAS software licences would dramatically decrease, now that the users are able to enter the SAS code on their Web browser and submit it to a SAS application server. Although it is easy to provide such an application, you do not really need SAS/IntrNet software to accomplish this task. Every multi user environment is a suitable solution for that.

But the users we are addressing with an Intranet solution are not SAS users. Normally they do not have any SAS skills, and they are not able or willing to enter some kind of code. They need an application like a SAS/AF® or a SAS/EIS® application. And often they do not like the interface of a mainframe terminal.

With the compute services of SAS/IntrNet software we have an option

Though software distribution and maintenance of "fat clients" has become much easier, application servers in an intranet are still easier to maintain and are more scaleable. Furthermore in most cases you achieve a better performance: Since you cannot provide all figures users may need as precalculated data in the data warehouse, most of the resources are needed to retrieve the data from the database, compile and summarize the data, and calculate index figures. This leads to a lot of data transfer via the network. When you put the database server and the application server into one fast segment of your network, this data traffic is limited to that segment while only the results, usually some kilobytes HTML or GIF file, are then transferred to the users.

Compute Services via CGI and HTML

Using the Common Gateway Interface (CGI) with the SAS Broker and the SAS application server with SAS/AF SCL programs is a powerful solution which is easy to implement. The communication with the client (browser) is based solely on HTML (Rel. 3.2). Using SAS/IntrNet software in this way has some important advantages:

The greatest advantage of this way compared to Java is that you do not have to learn a new programming language. But even if you are currently learning Java, I do not recommend using it now for the development of information or controlling applications. The releases of Java develop faster than any serious project can terminate, and you always have to keep in mind whether all the clients in your company support a particular feature or not. With the new features we currently get some important and pleasant changes, e.g. the new message model in rel. 1.1, which also leads to a much simpler and clearer coding. So if you start now, you will gain some early experience, but in two years' time you will see a number of different coding schemes in your applications, which are not state of the art anymore. The situation is very different in software companies which currently develop and sell applications like office suites or communication clients. They have to get the experiences and open the market now, and in many cases it is a reasonable decision to buy and use these products. But the 'individual' development of information systems inside a company must follow different rules.

When you need some processing on the user's PC, it is usually easier to transfer a tab delimited file and process it in a spreadsheet. And if a user really needs more power, e.g. locking algorithms for concurrent update of some planning figures, it might currently be better and easier to give him a real SAS/AF application. But in many situations even locking algorithms for data entry and maintenance can sufficiently be implemented using the CGI/HTML approach with a SAS application server.

The Design of Intranet Applications compared to SAS/AF Applications

The main difference between intranet applications and state of the art SAS/AF applications is that intranet applications are based on transactions while SAS/AF applications are object oriented. In SAS/AF applications each object in a frame immediately handles the input of the user. In intranet applications the user fills in a form and submits the input to the server process. There is no additional help feature for the objects on the screen. Therefore the HTML file must provide all information to enable the user to fill in the fields correctly, either by checkboxes and selection lists, or by sufficient descriptive text. When some information is missing or another error occurs, you should preserve the input of the user in displayed or hidden fields of an HTML form and prompt him for the additional information.

Another important rule is that you have to create each transaction as independent from all others. On the server side the SAS broker module should select the first available server session which might be different from the session of the previous transaction. On the client side, the user may jump between the different screens in the cache of the browser. So it usually makes no sense to store intermediate results or parameters for the user on the server side.

In the first view this transaction based model may appear to be a great disadvantage and you may want to keep the fat client applications or move immediately to Java applications. But as long as you simply retrieve information in almost any case the transaction based model leads to a very clear, simple and easy to use design of the whole application. If you need more interactive facilities, e.g. to create a nice chart, it is quite easy to provide a tab delimited file and load it into a spreadsheet.

The greatest advantage of HTML is, in my opinion, that it was originally developed to provide information as documents on different platforms and to create links so that the reader can easily access corresponding documents. This leads to a new kind of information system, since you now compile the data in the same way as you would for paper reports. Many fat client information systems, especially OLAP systems, provide data from one table, view, or MDDB. For HTML applications it is often better to access several tables or MDDBs in one transaction and assemble this information in one HTML output. In this way, the user gets comprehensive information in a very easy way. Instead of "slice and dice" in an OLAP cube the user now gets for each piece of information in the HTML output the appropriate link to more information, which may be a chart, a picture, or a written document.

Avoid gimmicks and tricks, e.g. image maps to provide a graphical drill down. In order to speed up the whole application and reduce the network traffic you should make your HTML screens as simple as possible and use the standard CUA controls provided by HTML such as check-boxes, radio-buttons, selection lists and push-buttons. As an example, compare the graphical SAS homepage (www.sas.com) with the text version (www.sas.com/SASHome.txt.html). You can choose whether you want to access the information quickly or wait for the nice screen. Unfortunately HTML screens with a lot of graphics such as www.ibm.com look ugly if the user turns off the automatic load of graphs. Also be careful with frames. Although they seem to be necessary in order to have the customers' and users' approval there are real disadvantages: It is difficult to bookmark an output with multiple frames. The advantage is that you can present the selections in one frame and the output of the SAS Web Publishing Tools in the other, but in many cases I would recommend to use two different screens.

A Stepwise Approach

Taking into account the great benefits which can be achieved by this kind of intranet application, it is usually not appropriate to simply 'convert' SAS/AF applications into intranet applications. A better way is to analyze the existing information system and rearrange the information it provides into units of comprehensive information. In the second step create the appropriate menus an HTML forms to access the information. And finally determine the useful links between the different parts.

As a result an intranet application for information delivery consists mainly of

Each of these parts must be comprehensive, e.g. the user must be able to enter all parameters for a query in a single HTML form and the HTML file with the results should contain all necessary information to answer a question. In this way you can minimize the number of transactions necessary. Finally, define the links between the different parts of the application, which, in most cases, is simply adding some HREF tags to the HTML templates. Only in some cases, when you provide different options for the same item, do you need to add an HTML form.

Developing Intranet Applications with HTMLOUT

Basically, developing an Intranet application is much easier than developing a similar SAS/AF application because you can concentrate on transaction processing and do not need to handle all the different events which may occur in a PC application.

The front-end is HTML. You can use a WYSIWYG editor to create the HTML pages, but HTML is so easy to learn and to use that even a simple text editor is suitable. Meanwhile, I prefer writing the HTML code manually using a freeware editor because then I have better control over the appearance of the page under different circumstances.

When the HTML output is created by the SAS application, I do not like to combine SAS code and HTML code. It would make the whole application unnecessarily complex. Instead I developed a special WS tool called HTMLOUT, which takes an HTML template and replaces the placeholders in that template with data from SAS datasets and macro variables. In this way I can design and maintain the presentation of the data quite similar to HTML pages with server side includes (Type text/x-server-parsed-html). It is also easy to pass these HTML parts to persons who are familiar with HTML but do not know anything about the SAS System.

On the other hand, the SAS program becomes very simple. I do not call anything else but SCL entries via the broker. These SCL entries receive the parameters and some other information from CGI via an SCL list. Now the SCL program simply has to evaluate these parameters and create the appropriate steps to prepare the data. Then it calls HTMLOUT with the appropriate template and the results are transferred to the user. When you have to provide some graphs, these can be directly transferred as GIF files via the appropriate SAS/GRAPH® driver.

As a very simple example the SCL entry displays selected records of SASUSER.CLASS and looks like this:

ENTRY sl_parameters 8;

init:
 * get parameters for query ;
 sex = getnitemc(sl_parameters,"SEX",1,1," ");
 age = getnitemc(sl_parameters,"AGE",1,1," ");

 * create dataset or view with the data to display;
 submit;
   PROC sql;
    create view work.ergview as
      select *
        from sasuser.class
      where (0=0)
 endsubmit;

 * create where clauses ;
 if sex GT " " then do;
    sex = quote(sex);
    submit;
       and sex = &sex
    endsubmit;
 end;         
 
 if age GT " " then do;
    submit;  
       and age = &age
    endsubmit; 
 end; 
 
 * submit the code;
 submit continue;
     ; 
  QUIT;
 endsubmit;

 * display the data;
 call display("HTMLOUT.SCL",0,"SASUSER.HTML","WORK.ERGVIEW");
RETURN;

Of course real applications often require a lot more processing, but the example shows that you can really concentrate on retrieving and preparing the data.

Data Entry and Update

However, when you want to maintain data via an HTML application, you must store some information on the server side. At least you must lock and release some records in the database in order to provide a proper handling of concurrent updates. There are two ways to accomplish this task:

  1. Store this information in a place which can be accessed by all server sessions. This is the method I usually recommend, but you cannot use the features of the DBMS.
  2. Make sure that the following transaction is handled by the same server session: In the configuration file of the SAS broker module you must provide different services. The default service accesses the first available session. Additionally you need a distinct service for each available session. When a server session sends the HTML form to maintain data to a user it sets the service parameter to its own service, so that the next transaction uses this server session again.
In both cases you must provide a timestamp and some mechanisms to clean up locks and other data after a defined period if the user does not respond as expected, e.g. if he has turned off his computer or the connection is broken for any other reason.

To recognize corresponding transactions you can create a unique ID, e.g. one that is composed from the datetime function and the IP address of the user which is always passed to the SAS server session, and put this ID in the HTML form as a hidden field. You do not need to place a cookie on the user's machine.

Although I said earlier that transactions had to be independent from each other and you could not store intermediate results on the server, this is also a way to circumvent this limitation. For simple information systems I avoid this method because, for simplicity, I do not want to implement these timestamp and clean-up methods and the corresponding overhead.

Special Tips

Setting up a Development Environment

When you develop or maintain an intranet application you may want to modify an SCL entry without stopping and restarting the server session. This is not possible in a production environment because, for performance reasons, the SCL entries are cached with the AF option RESIDENT=64 (or similar). When you start a distinct development and test server and change the option to RESIDENT=-64, this SAS session will only cache methods which explicitly have the RESIDENT option in the METHOD statement. Then you can edit the SAS catalogues of this server while the server keeps running.

On the HTTP server side there are two ways to set-up a test environment for SAS/IntrNet:

Identifying a User

HTTP transactions are usually anonymous, but sometimes you must identify the user. This can be done by means of the HTTP server. You can protect the SAS broker by restricting the access to authorized users so that the user has to enter a userid and password. This userid will be passed to your SAS server session together with the TCP/IP address of the user's machine. Then the permission is checked in more detail by your program.

Improve Security

SAS/IntrNet software provides a distinction between libraries with modules which can be called via the broker and 'data libraries' which can only be accessed by this modules. The libnames for callable modules are stored in the file SRVAUTO. The other libnames are stored in PERMDATA. The easiest way to protect your programs is to put only one SCL entry into the callable library defined in SRVAUTO. In this SCL entry you can implement a first check of permission. This becomes a unique place for all parts of the application. Then the program calls another SCL entry in a 'data library' which cannot be accessed directly from outside and which contains the real program.

Tuning

In order to provide a sufficient performance of the whole system, you must measure the time of each transaction on the server side. Using the design I am recommending in this paper, the SCL programs become quite simple and it is easy to tune them, e.g. to compare different methods to retrieve the data.

Data Protection

In some countries, at least in Germany, data protection in the sense of protecting the people is a hot topic. An HTTP server is able to create a detailed log file containing

Depending on how sensitive the people in your company are, you may have to switch this logging off for most of your intranet applications. Then you must set-up a separate server for transactions where you really need this kind of logging for security or documentation purposes.

You do not have to set-up different SAS server sessions since the brokers can pass a variable with different values to signal whether a request was passed via the server with logging enabled or not.

Conclusions

With SAS/IntrNet software the SAS System has become a powerful tool for information delivery applications in an intranet or internet environment. There are many options from WEB publishing up to client/server applications with Java applets from which to choose.

Regarding the state of the art and taking into account the development of the different components, especially the Java programming language, using the compute services with the CGI interface and HTML and GIF output is, in most cases, the best choice for companies which are not mainly developing software, but need running information delivery systems. This technology is very easy to implement and to maintain, especially with a tool like HTMLOUT. In many cases the resulting applications can provide information in a better way and a more comprehensive compilation than standard fat client OLAP applications can. HTML as a standard user interface is easy to understand and in most cases is well accepted by the users.

The option to integrate Java applets and applications in many different ways provides security for the future. Currently, however, it is not the first choice I recommend to customers.

Contact:
Wilfried Schollenberger
WS Unternehmensberatung und Controlling-Systeme GmbH
Friedrich-Weinbrenner-Straße 20
D-69126 Heidelberg

EMail: wisch@ws-unternehmensberatung.de

Note: SAS System, SAS/AF, SAS/EIS, SAS/GRAPH, and SAS/IntrNet are registered trademarks of SAS Institute, Cary, North Carolina