Re: Modify HTML header section

MarcTC · Posted 12-03-2010 05:24 AM

When I use %STPBEGIN/%STPEND to generate HTML output, SAS stored processes would output the html header section like this:

SAS Output

Is it possible to modify this section?

Cynthia_sas · Posted 12-03-2010 12:24 PM

Hi:
ODS has the HEADTEXT= option and the METATEXT= options that allow you to add <head> or <meta> tags to your output. It will be a bit tricky to use them in a stored process, but it is possible to do.

Can you explain a bit more about what you want/need to do?

cynthia

MarcTC · Posted 12-03-2010 11:50 PM

Stored Processes Server has some SP samples. One of them is called stpeuro. Its code structure is like this:

%STPBEGIN;
proc gmap...;
%STPEND;
data _null_; file _webout; put '

2 things observed:

1. The web page title is SAS Output. I want to change to my company title. How to do it?

2.

Cynthia_sas · Posted 12-04-2010 11:44 AM

Hi:
Look at the Hello World stored process sample and the way that it uses _webout with DATA _NULL_ statements to write custom HTML. Basically, if you were going to use this method, you would NOT use %STPBEGIN/%STPEND in your stored process because the automatic %STPBEGIN/%STPEND macros write "pre-defined" HTML tags (the ones you find unacceptable).

If you are writing your own HTML and HTML form tags, then you can put whatever <HEAD> or <META> tags you want. Do note, however, that not all client applications will be able to run stored processes that are coded with custom HTML. For example, SAS Web Report Studio and PowerPoint both expect stored process results to come to them as SASReport XML -- not as custom HTML forms. So if you go down this road, you will be building a stored process that can only be executed from the Stored Process Web Application or within the Information Delivery Portal.

cynthia

MarcTC · Posted 12-04-2010 09:36 PM

I will use SPWA for our web reprots.

If I remove %STPBEGIN & %STPEND and use custom code from STPUG.pdf like below, it results in a binary code output to the web page for the gplot.

data rpt;
a=1; b=1; output;
a=3; b=2; output;
a=2; b=4; output;
run;

ods html body=_webout(nobot) rs=none;

proc print data=rpt;
run;

ods html close;

%let old=%sysfunc(stpsrv_header(Pragma, nocache));

goptions gsfname=_webout gsfmode=replace
dev=png xpixels=800 ypixels=900; ;

proc gplot data=rpt;
plot a*b;
run; quit;

Cynthia_sas · Posted 12-05-2010 01:11 PM

Hi:
In this instance, I would expect a couple of things:
1) that you have the ODS HTML CLOSE -after- the GPLOT step, not before
2) that if you do #1, you do not use the GSFNAME= method but instead would just have:
goptions device=png xpixels=800 ypixels=900;
and
3) that you define the results as transient package output (depending on your version of SAS) or package output

It looks to me like your example was modelled from this example of direct graphics in the stored process user guide:
http://support.sas.com/rnd/itech/doc9/dev_guide/stprocess/embedgrf.html

Note, that the description of this method says:
"In some cases, you might want to generate image output directly from a stored process with no HTML container. This might be useful if you want to include a dynamically generated graphic in static HTML pages or HTML generated by an unrelated stored process." And then they provide an example of an <IMG> tag that will kick off that stored process (which uses GSFNAME and only generates an image):
This stored process expects XPIXELS and YPIXELS to be passed as input parameters. A typical IMG tag to invoke this stored process might be

<IMG SRC="/SASStoredProcess/do?_program=/WebApps/Utilities/Sales+by+Product&XPIXELS=400&YPIXELS=300">

The above <IMG> tag would then run the stored process with GSFNAME using the SPWA and the results would be returned. Note that in this direct graphics example, there is NO other step -- NO PROC PRINT, NO other code that would generate output -- there is only the SAS/GRAPH related code.

If you want to see the PROC PRINT output followed by the GPLOT image, then you would follow the OTHER example at that web site, the one BEFORE the direct graphic example. That stored process looks like this:
[pre]
/* Sales by Region and Product */

*ProcessBody;
%stpbegin;

proc gchart data=sashelp.shoes;
. . . more code . . .
run;
quit;

proc report data=sashelp.shoes;
. . . more code . . .
run;

%stpend;
[/pre]

And if you were going to modify the SP to use _webout, then you would do something like this:
[pre]
ods html body=_webout(title="My SAS Report") rs=none;

goptions device=png xpixels=800 ypixels=900;
proc gchart data=sashelp.shoes;
. . . more code . . .
run;
quit;

proc report data=sashelp.shoes;
. . . more code . . .
run;

ods html close;
[/pre]

But if ALL you want to do is generate text and graphics from a stored process, it seems to me that the %STPBEGIN/%STPEND method should be OK for you. You can pass in other options (such as HEADTEXT and METATEXT (if you want) via the &_ODSOPTIONS reserved parameter, described here:
http://support.sas.com/rnd/itech/doc9/dev_guide/stprocess/reserved.html

But, if you want to write your own HTML forms (which is what I thought you wanted to do), then you should read the documentation topic on Chaining Stored Processes and Using Sessions:
http://support.sas.com/rnd/itech/doc9/dev_guide/stprocess/datapass.html
http://support.sas.com/rnd/itech/doc9/dev_guide/stprocess/sesssamp.html

You might want to work with Tech Support for more help on the use of _WEBOUT especially when you are mixing text reports, graphics and forms, you may need to use SESSIONS and/or use &_TMPCAT or &_SESSIONID in order to get things working correctly. The SPWA is most like the Application Dispatcher/Broker setup that was used to invoke SAS/IntrNet programs -- so you might find this section useful in the doc - -where it talks about how to convert SAS/IntrNet programs to stored processes that run on the SPWA:
http://support.sas.com/rnd/itech/doc9/dev_guide/stprocess/inet2stp.html

cynthia

MarcTC · Posted 12-04-2010 09:58 PM

Cynthia-

Our data are stored as SAS datasets. If we want SAS to process all the backend work and present output in HTML form, besides SPWA and delivery portal, what are other options? Can we use JPS or PHP as html processor and SAS as backend processor? If so, how to set it up or is there any documentation for this?

MarcTC · Posted 12-04-2010 10:45 PM

Cynthia-

Is SAS/IntrNet not recommended by SAS for web development? You mentioned SPWA and Deliver Portal. Also Appendix 2 of STPUG.pdf talks about converting SAS/IntrNet to SPWA.

Cynthia_sas · Posted 12-05-2010 02:12 PM

Hi:
SAS/IntrNet is a great tool for generating web report dynamically. I love htmSQL (a component of SAS/IntrNet) for its ability to go out to SAS data and query a list of regions, for example, and then build an HTML form dynamically that shows the list of regions for the user to pick from and the the <FORM> ACTION= is the name of the Application Dispatcher program that you want to run when they finish making selections on the form. Totally cool. But SAS/IntrNet, however cool, is older "CGI" (Common Gateway Interface" technology.

The closest componenet to SAS/IntrNet in the BI platform is the Stored Process Web Application. The SAS Stored Process owes a lot to the concept of the SAS/IntrNet Application Dispatcher program. With an Application Dispatcher program, the program lived in a special location, registered to the Dispatcher and you invoked the program via URL. This is very similar to how the SPWA works with a stored process. The difference, of course, is the fact that the SPWA and stored processes work with the BI Platform Metadata Server and SAS/IntrNet technology pre-dated the whole concept of metadata and the metadata server and the Business Intelligence Platform.

In the BI Platform, the SPWA is only one component of the Platform -- it allows users to design their own HTML and their own web pages and/or integrate stored process output into existing web sites or web server structures. Your web server could use JavaScript or PHP or .NET or Java servlets and you could still invoke a stored process using the SPWA -- because you use a URL (such as that shown in the <IMG> (shown in my other posting) tag to kick off the stored process. Another example of an <A> tag that would kick off a stored process is:
[pre]
<A target="new" href="http://localhost:9090/SASStoredProcess/do?_program=/STP_Orion/Reports/myprogram">
Click here to run program
</A>
[/pre]

This <A> tag could be worked into just about ANY web page or web site -- and assuming that all the other web infrastructure was in place, when the user clicked on the link, the request would go to the SPWA and the stored process would execute and results would get streamed back to the requesting browser.

Compare the above URL to a SAS/IntrNet URL for dynamically submitting a SAS program:
[pre]
<A href="/cgi-bin/broker.exe?_debug=2&_program=web1samp.myprogram.sas&_service=appserv">
Click here to run program
</A>
[/pre]

As you can see, there are a lot of similarities between SAS/IntrNet programs and SAS Stored Processes, as far as how you invoke them via URL -- but all the infrastructure is different. The advantages of stored process over SAS/IntrNet programs (in my opionion) are:
1) Metadata: Metadata with stored process defines security, tables, type of access as well as having a central repository in the metadata where the stored process parameters are defined

2) Servers (and reusability): SAS/IntrNet programs can only be executed via the "broker" program installed on a web server, whereas stored processes (depending on how you write them) can be executed from many of the client applications in the BI Platform and from more than one type of server used by the Platform configuration. So someone sitting at a web browser and someone sitting at a Windows/Microsoft Word application could both request the same stored process to run; whereas, with SAS/IntrNet programs -- they were only requested from a URL coded in an HTML page.

3) Parameters: The ability to define stored process parameters in the metadata and to have the automatic prompting interface for the stored process parameters is WAY better than using parameters with SAS/IntrNet programs. With IntrNet programs, the developer had to just know what the required parameters were and had to code for them in an HTML form or a hidden form items -- very do-able, but required knowledge of HTML and building URLs, etc that is not required to define or use stored process parameters.

Of course, if you write a stored process that builds a custom form, using streaming output -- then that stored process will not run on client apps like PowerPoint or Web Report Studio - -but one of the reasons that folks moved to the BI Platform was the ability to create 1 stored process that would run on multiple client applications and where the authorization to control who could run the stored process and who could access the data - -was all defined in a central metadata repository -- and where the parameters used with the stored process were defined in the metadata.

You can also write your own custom web services, as described here:
http://support.sas.com/rnd/itech/doc9/dev_guide/websrvcs/index.html and
http://support.sas.com/rnd/itech/doc9/dev_guide/websrvcs/decide.html

Again, there are some samples posted on the above sites and you can always work with Tech Support for more help once you have decided on a direction (custom BI Web Services, SPWA, SAS/IntrNet).

cynthia

SAS Innovate 2025: Register Now

SAS Training: Just a Click Away