Tour 2: Choosing a Component

What skills are available in your organization?

The following table provides a list of the SAS/IntrNet components. Also listed are the technologies that each component represents and the skills that application developers need in order to develop applications with that component.

SAS/IntrNet Component Name	Technology		Required Programming Skills
	CGI	Java	Java	SQL	HTML	SAS Languages
Application Dispatcher	X				X	external .sas file  SOURCE entry  macro  SCL program
htmSQL	X			X	X
SAS/CONNECT Driver for Java		X	X	if submitting requests to a SAS/SHARE server	minimal	SAS procedures

• If you have limited or no knowledge of CGI, HTML, Java, and other Web technologies, then first consider using the Application Dispatcher.

• If your staff is mainly skilled in SAS programming, then first consider the Application Dispatcher.

• If your staff is skilled in SQL and HTML programming, then first consider htmSQL.

• HTML is fairly easy to learn but JavaScript and Java are more difficult to learn; therefore, a minimal investment in HTML training can greatly expand your options. You can learn quite a bit about HTML in just a few days.

• Programmers with some experience in object-oriented programming should have an easier time with JavaScript and Java programming than those without object-oriented experience. Programmers with C or C++ experience should be able to learn Java in a reasonable amount of time.

• The interactivity and flexibility offered by both JavaScript and Java can make the investment in learning them (or hiring staff who already know them) more worthwhile.

What level of interactivity does your application require?

Pure CGI/HTML implementations do not provide instantaneous interactivity--each request requires a round trip to the server. Java, on the other hand, executes locally. If you require a lot of interactivity, then consider JavaScript, Java, and Dynamic HTML.

How frequently is your application used?

If the application is run only occasionally to deliver specific reports, then CGI/HTML solutions are a better choice. CGI/HTML applications can be downloaded quickly and can do the majority of their work on the server. If the application is used frequently or for a significant length of time, then the extra time that is required to download a large and sophisticated Java applet is worthwhile.

What is the timeframe for deploying your application?

If you have a lot of time, then you can give yourself the option of learning new technologies (such as Java and HTML) while using your existing skills to create interim solutions (for example, using the Application Dispatcher to Web-enable your existing SAS programs).

Can you safely assume which browsers will be used to access your Web applications?

A simple CGI/HTML application should run in any browser. However, if you decide to use JavaScript, ActiveX, Dynamic HTML, Java, then your application will not be able to run on all browsers.

What kind of processing is needed?

For simple queries and tabular displays, use htmSQL.

For applications that require complex data management or data analysis, first consider Application Dispatcher or the SAS/CONNECT driver for Java.

Do you have a fixed set of output requirements or does each user need the ability to request customized output?

If your reports can be generated by a batch process and then published on a Web site, then you can use the Output Delivery System (ODS) or the HTML Formatting Tools. If your reports require customization, then you need a dynamic SAS/IntrNet application.

Many dynamic reports can be easily generated using the Application Dispatcher and ODS or the HTML Formatting Tools; however, if you need more exact control over the layout of the reports and output, then you need some knowledge of HTML when using either Application Dispatcher (with custom Data steps using PUT statements) or htmSQL.

Do you have existing SAS programs that you need to use to make output available to any or all users in your organization?

If so, then the options to consider include

• using ODS or the HTML Formatting Tools and batch processing to statically generate reports on a scheduled basis

• using the Application Dispatcher to dynamically run the SAS programs based on user input

• using Dynamic HTML, JavaScript, or a Java applet if the SAS programs' front-end menus are complex and very interactive

• packaging the code using the IDE and ROCF if the current code makes use of SAS/AF software's object-oriented capabilities

• moving existing SAS/AF applications to the Web if the applications are designed using a model-viewer architecture.

Where is your data stored?

If you require multi-user update access or cross platform access as provided by SAS/SHARE software, then use Application Dispatcher and htmSQL, which can access any data as long as TCP/IP is available and SAS/SHARE software is installed in the same machine as the data.

When you use Java applets, either your data must be located on your Web server or you must use the tunnel feature of the SAS/CONNECT driver for Java to access your data on other platforms.

How large are your data files?

It is important to reduce the amount of data that lives on your server because the download time for large files can have a significant impact on performance.

Also, many Web browsers cannot handle large HTML files, especially if the files contain HTML tables. Large tables are difficult for browsers to parse and can hang a browser. To display a large (but not extremely large) data set as an HTML table, create separate HTML tables for subsets of the data to circumvent the parsing problem. The HTML Data Set Formatter (one of the HTML Formatting Tools) supports BY GROUP processing which creates separate HTML tables.

Are your reports generated from static data or does the data change frequently?

If the data is static and the reports do not need to be customized with user preferences, then you may want to choose ODS or the HTML Formatting Tools.

If your reports consist of simple tables, which can be generated with SQL, then consider htmSQL. htmSQL sends SQL requests to a data server, which typically is faster than running a program using either the Application Dispatcher or the SAS/CONNECT driver for Java.