Your SAS programs, embedded in web apps and elsewhere

Return text file Output to Browser

Posts: 0

Return text file Output to Browser


We are trying to do a quick transition of customer written reports to stored processes. These report were essentially batch reports that wrote their output to a text files and that text file was emailed to the customers. We want to return the text file to the browser when the user runs the reports through the SAS Web Stored Processes interface. The report output has been created with put statements with complex formatting logic, so it is not an easy or quick job to convert them to listing etc. Is there an easy way of returning a text file or put output to the web browser?

Dave B Message was edited by: Delta Serpentis
Posts: 8,743

Re: Return text file Output to Browser

A review of this example:

may help you figure out how to alter the programs. The programs WILL have to change. Depending on how you were creating the reports (FILE PRINT vs FILE PRINT ODS), you will probably have to change your FILE statement to FILE _WEBOUT. In addition, you might have to include your own HTML "wrapper" code.
Then, before your "main" body of the report (immediately after you insert the <BODY> tag into the file), you would then insert a <PRE> tag before the current set of PUT statements begin. Then, before you write the </BODY> tag, you would write the </PRE> tag.

Remember that you will be creating a stored process that can only be accessed via URL using the Stored Process Web Application because only some of the client applications in the BI platform can "receive" HTML results from the stored process server.

For example, if I create a SAS program called and save it in a stored process repository location named STP_Orion and call the stored process registration name SP_forum_SPWA , then I can build a URL to invoke the SP with the SPWA. But, first, here's the .SAS program:


data _null_;
set sashelp.class end=eof;
file _webout ;
if _n_ eq 1 then do;
put '<HTML>';
put '<BODY>';
put '<H1>Hello World</H1>';
put '<PRE>';
put @23 "Test Code";
put @10 "Output results from a DATA step using a FILE PRINT:";
put ' ';
put 'The main output: ';

put @13 "Student Name = " @28 name @40 "Age = " age @50 "Height = " height 5.1;

if eof=1 then do;
put '<H1>The END</H1>';
put '</PRE>';
put '</BODY>';
put '</HTML>';

And then I register the SP using SAS Management Console -- the execution options were for this SP to run on the Stored Process Server and return Streaming results. (You
-could- register this SP with SAS Enterprise Guide, however, you have to be VERY, VERY careful to avoid ANY of the automatic macros %stpbegin/%stpend or any ODS statements getting added to this SP.

Next, I built an HTML page like this:
<!-- SP_forum_SPWA.html -->
<title>Demonstration of Stored Process Web Application</title>
<p>First, start the SAS Services Application then start TomCat. <br>
Then click on the links below to test the use of stored processes with the
Stored Process Web Application</p>
<p><b>Note that in a production environment,
these servers will be automatically started.</b></p>
<a target="new" href="http://localhost:9090/SASStoredProcess/do?
Run the Class Report with DATA _NULL_ and _WEBOUT</a>

I show a relative name as the location of the _PROGRAM= name/value pair. My SP was registered in the default Foundation Repository in the STP_Orion stored process repository. When this HTML page loads into the browser, and I click on the link, the <PRE> results look as they would look in the LISTING window. The <H1> tag output looks as you would expect header tag lines to look.

Remember that FILE _WEBOUT is not the same as FILE PRINT. So some print-oriented or "page" oriented FILE or PUT options, like PUT _PAGE_, N=PS or LINESLEFT or "line feed" controls like PUT / may not work as you expect. I have not ever experimented with a really complex DATA _NULL_ program using the SPWA in the BI platform. My warnings are based on some of things that were true when I converted DATA _NULL_ programs to produce streaming output in SAS/IntrNet (whose application server is very similar to the stored process server). Also, you may need to change the FORMCHAR option if your program is writing its own table lines using '----------' and '+' characters.

The only other thing I can think of is to look up the old formatting macros, these were macro programs introduced in SAS 6, in order to help people generate output from SAS procedures and processes so the output could have the HTML wrapper code generated automatically. There were %DS2HTM, %TAB2HTM and %OUT2HTM macro programs. I believe the one you might investigate is the %OUT2HTM macro program -- however, I believe that it had a "linesize limit" of 195 characters and I don't know whether it would work with the SPWA. The macro programs worked very much like PROC PRINTTO or ODS, you had a macro call before your program and then you had a closing macro call after your program. Any output created by the program between the 2 macro calls would be placed within <PRE> tags. But, as I said, I don't know whether these macros would still work with the SP server and the SPWA.

For more help with this task, you might wish to work with SAS Tech Support.

Occasional Contributor
Posts: 6

Re: Return text file Output to Browser

Hi Delta,

We are encountering the same issue with highly customized reports that were written to text files. We now want to display it via SAS Web.

Were you able to find a solution on how to output to web browser fairly easily?

Thank you.
SAS Employee
Posts: 285

Re: Return text file Output to Browser

The HTML Formatting Tools, and OUT2HTM in particular, may provide temporary relief:

HTML Output Formatter

Here is a basic usage example:

%OUT2HTM(window=output, capture=on);
  * Your existing SAS code here;
%OUT2HTM(window=output, capture=off, htmlfref=_webout);

If you want to spruce up the output a bit without too much additional work, refer to:

Customizing Output Using PUT and FILE Statements

Let me know if you need more details or a sample.

Vince DelGobbo
Ask a Question
Discussion stats
  • 3 replies
  • 4 in conversation