Ok, so for some reason, flash wasn't working on my Windows Server 2003 running IIS 6.0. This impacted me since I wanted to run RoboHelp Flash. After a lot of tinkering and searching, turns out that IIS wouldn't allow the flashhelp_default.fhs file to run because IIS wouldn't allow the MIME type of fhs to run.This is a simple fix. Go into the properties of the web server and add in the mime type of fhs with a desscription of text/xml. Voila!! life is happy again.
I hope this helps someone else in this same boat.
Alan
Monday, February 27, 2006
Thursday, February 09, 2006
Web Services and SAS
The traditional field of Application Integration (you know, creating a SAS program on Unix that creates Excel spreadsheets) has been a muddied water for a long time. People tend to stick with the tried and true and just use API-type of mentatlity for delivering information. This is problematic for a lot of reasons:
- An API has to be created and maintained over time
- Neither application plays to its strengths but instead each one 'dumbs' down to the lowest common denominator of both applications
- You always have to search for the specific API to use to get anything done
- There is no central way of managing these APIs and you get a lot of code bloat
To solve these issues, web services were born. Now web services may sound like voodoo or black magic but they are very, very simple. Everyone, and I mean everyone (including SAS), agreed to have a common means (XML) of transporting information between each other. I won't go into the ugly details of web services because the web is rife with them but let's talk about how they could be used to solve the typical SAS scenario I mentioned above.
You have SAS running on a Unix server and all of your users want it in Excel.
Old solution: Use SAS\Access to create an Excel file, use ODS to create a very bloated Excel file, write out to CSV, etc. Run the code, ftp the file to a server for delivery, have the end users read in the data and parse it themselves, or again use ODS and figure out the coding needed to create an Excel report.
New solution: Create a web service on Unix that reads in the SAS data using OleDB, ODBC, etc. and just expose a service (let's call it GetSasData("ExcelData"). Next have Excel consume that service and parse the data into the exact Excel report you need.
Ok. You may say that the new solution doesn't sound much better than the old. But wait!! Your boss now comes along and says can you please make that same data available to Lotus 1-2-3 and StarOffice. AHHHHH!!!! Under the old method you need to rewrite all of that ODS or just create an entirely new package. The boss then asks you to also support SAP and Oracle. AHHH!!
Ok, web services wouldn't require any changes because Oracle, SAP, etc. support web services. They can just consume that service the same as Excel. But, you claim, CSV is supported by everyone as well.
Actually, it isn't. Take the following CSV file:
Name Age Gender
Bill 29 M
Mary 32 F
Now is name a numeric, string, what does Name mean? CSV doesn't tell you and never will. Web services have support for typing information so you know what it is.
This blog merely scratches the surface. Don Henderson and I have put up some sample web services for people to play with over here:
http://demo.savian.net/SasWebServicesDemo/Service.asmx
I urge you to check them out and see what the possibilities are.
Out in left field and loving it,
Alan
Web Services and SAS
The traditional field of Application Integration (you know, creating a SAS program on Unix that creates Excel spreadsheets) has been a muddied water for a long time. People tend to stick with the tried and true and just use API-type of mentatlity for delivering information. This is problematic for a lot of reasons:
- An API has to be created and maintained over time
- Neither application plays to its strengths but instead each one 'dumbs' down to the lowest common denominator of both applications
- You always have to search for the specific API to use to get anything done
- There is no central way of managing these APIs and you get a lot of code bloat
To solve these issues, web services were born. Now web services may sound like voodoo or black magic but they are very, very simple. Everyone, and I mean everyone (including SAS), agreed to have a common means (XML) of transporting information between each other. I won't go into the ugly details of web services because the web is rife with them but let's talk about how they could be used to solve the typical SAS scenario I mentioned above.
You have SAS running on a Unix server and all of your users want it in Excel.
Old solution: Use SAS\Access to create an Excel file, use ODS to create a very bloated Excel file, write out to CSV, etc. Run the code, ftp the file to a server for delivery, have the end users read in the data and parse it themselves, or again use ODS and figure out the coding needed to create an Excel report.
New solution: Create a web service on Unix that reads in the SAS data using OleDB, ODBC, etc. and just expose a service (let's call it GetSasData("ExcelData"). Next have Excel consume that service and parse the data into the exact Excel report you need.
Ok. You may say that the new solution doesn't sound much better than the old. But wait!! Your boss now comes along and says can you please make that same data available to Lotus 1-2-3 and StarOffice. AHHHHH!!!! Under the old method you need to rewrite all of that ODS or just create an entirely new package. The boss then asks you to also support SAP and Oracle. AHHH!!
Ok, web services wouldn't require any changes because Oracle, SAP, etc. support web services. They can just consume that service the same as Excel. But, you claim, CSV is supported by everyone as well.
Actually, it isn't. Take the following CSV file:
Name Age Gender
Bill 29 M
Mary 32 F
Now is name a numeric, string, what does Name mean? CSV doesn't tell you and never will. Web services have support for typing information so you know what it is.
This blog merely scratches the surface. Don Henderson and I have put up some sample web services for people to play with over here:
http://demo.savian.net/SasWebServicesDemo/Service.asmx
I urge you to check them out and see what the possibilities are.
Out in left field and loving it,
Alan
Subscribe to:
Posts (Atom)