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?
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.
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;
3) that you define the results as transient package output (depending on your version of SAS) or package output
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
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:
/* Sales by Region and Product */
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
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?
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.
<A target="new" href="http://localhost:9090/SASStoredProcess/do?_program=/STP_Orion/Reports/myprogram">
Click here to run program
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:
Click here to run program
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.