SAS/IntrNet:Application Dispatcher Error

[deleted_user]

Folks,
I have situation here. I use SAS/IntrNet frequently to generate web reports in Excel for the end users. Previously I used normal ODS HTML statement to generate my Excel reports. But now I'm using Excelxp tagset approach and my program is taking more time to execute the program on the server which is causing Time Out Error. I see the following error message.

The program ran longer than its allotted timeout period (100 seconds). This could happen if the timeout is too short, if the server is unavailable or busy, or there was an error invoking the SAS server. Note: program may still be running.

This request took 100.02 seconds of real time (v9.1 build 1461).


--- Appreciate your help folks..

Regards,
Matt

[Cynthia_sas]

Hi:
Long ago, in a galaxy far, far away, when I was using SAS/IntrNet, I have some memory that timeout settings were put in the file that either started up or configured the Application Server. You might want to work with Tech Support on this issue.

Meanwhile, these links might prove useful:
http://support.sas.com/kb/7/113.html
http://support.sas.com/kb/5/892.html
http://support.sas.com/onlinedoc/913/getDoc/en/dispatch.hlp/refconf.htm
http://support.sas.com/onlinedoc/913/getDoc/en/dispatch.hlp/appreq.htm
http://support.sas.com/onlinedoc/913/getDoc/en/dispatch.hlp/sesssamp.htm

cynthia

PS...Spreadsheet Markup Language XML (created by TAGSETS.EXCELXP) -IS- more verbose than ODS HTML, so not only could it take longer to create, but depending on your suboptions, could be quite a bit bigger and could take longer to transmit and load.

[deleted_user]

Cynthia,
I changed the service timeout parameter settings and is working fine. As you said it taking longtime but my output opens up in excel with no excel tagset options ( styles, frozen headers etc.. ) I ended up with a normal excel file which really looks bad. Here is my code.

%let RV=%sysfunc(appsrv_header(Content-type, application/vnd.ms-excel));
%let RV=%sysfunc(appsrv_header(Content-disposition,
%str(attachment; filename=Validate.xls)));
%include 'C:\Addy\excelxp.sas';
OPTIONS orientation=landscape ;
ods listing close;

ODS tagsets.ExcelXP body=_webout style=XLsansPrinter;
footnote h=10pt f=TimesRoman j=l "%sysfunc(today(),mmddyy10.)";

ods tagsets.ExcelXP options(embedded_titles='yes' embedded_footnotes='yes'
sheet_name='Visit 2' absolute_column_width='9' Frozen_rowheaders='4' FROZEN_HEADERS='4' autofilter='2 7');
Title ' Validate Particiapants in OC for Visit 2';
footnote;
proc print data=OC_Twooo;
var STUDY_ID VISIT FULLNAME substatus IN_SM In_OC Total_CRFs Entered_CRFs;
var CBC COMP_CHEMISTRY CONSENT VITALS_EKG HEPATITIS
MEDICATIONS PHYS_EXAM INCLU_EXCLU HARBOR_LABS MEDICAL_HX SYS_REVIEW URINALYSIS
PROGRESS_NOTES PT_DISCHARGE / style(data)=data_bullet ;
Run;
Quit;
ods tagsets.ExcelXP close;

If I use validate.xml in the %str function(line 3 on my code) I see a weired output in my browser I pasted part of it below
/***********************?

-
-
SYSTEM
SYSTEM
2010-01-27T16:20:50
2010-01-27T16:20:50
SAS Institute Inc. http://www.sas.com
9.01.01M3P11032004

-
-

[deleted_user]

I'm missing

ods path(prepend) work.template(update);

before the appsrv statements.

Thanks
Addy

[Cynthia_sas]

Hi:
As I said, my SAS/IntrNet days were long ago and far away. I'm not sure you actually -need- the Content-disposition, since the stream comes back to the client machine and the Content-type should cause Excel to be launched.

Whether a file extension of .XML versus .XLS "works", may have to do with the version of Excel/Office that you are running or it could have to do with the default registry setting for opening an XML file on your system. For example, on my system, for an XML file the default is to open the XML file in a browser. If I want the default application for XML to be Notepad, I have to change the file extension association in the Windows registry. When you use the Content-type with SAS/IntrNet, it is instructing the receiving machine (the client) to launch the helper application, such as "application/vnd.ms-excel".

TAGSETS.EXCELXP is creating -exactly- the XML file that you posted a clip from. It is up to Excel to render that XML in spreadsheet form. TAGSETS.EXCELXP is not creating a "true, binary .XLS" file. TAGSETS.EXCELXP conforms to the Microsoft Office Spreadsheet Markup Language XML specification for how to describe a workbook and worksheets in XML markup tags.

The TAGSETS.EXCELXP XML that you create with ODS is just an ASCII text file. The XML created by TAGSETS.EXCELXP is -NOT- intended to be viewed in a browser. My suspicion is that when you name the content-disposion with .XML -- it somehow overrides the content-type instruction to open the streamed file with Excel -- and the browser (the -usual- rendering application for XML) is used instead.

But that's just a guess. You could see what happens without a CONTENT-DISPOSITION in the job. As long as Excel 2003 or higher is launched on the receiving system, the TAGSETS.EXCELXP XML file should be opened without an issue. However, just because Excel opens the XML file and it LOOKS like a worksheet in the Excel application, does not mean that the file just opened IS a "true binary" Excel Worksheet. TAGSETS.EXCELXP will ONLY, ONLY, ONLY create an XML file. If you do a File --> Save As, you will see that Excel "knows" that you just sent it an XML file. If you use XML as the file type to save, you can then open the saved file in Notepad and you will see the Spreadsheet Markup Language tags.

When you say that your output opens with no Excel tagset options, and that the output looks bad -- both of those issues could be issues with not having the most current version of the tagset template. Because you say you are using ODS PATH PREPEND and because you are %including a file called "EXCELXP.SAS" I wonder whether you are correctly updating the template item store on the server machine??? Generally, the Application Server machine will not have any visibility of your local machine's C drive. So it's possible that your %include is not having any impact on the server. You can use the _DEBUG option when you invoke your Application Dispatcher program to return the SAS log so you can find out specifically what the issue is.

This is the the type of issue where it would be better for you to open a track with Tech Support. They can look at your code, help you get the log results and help you update the tagset template correctly and then invoke the Application Dispatcher program with the correct AppSrv_Header function.

cynthia