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:


I urge you to check them out and see what the possibilities are.

Out in left field and loving it,



Anonymous said…
All of what you have here is great; however, do you have any methods for going from a web service into SAS; meaning that we need to take SQL data and push it into a SAS dataset
Alan Churchill said…
Writing to a SAS dataset is possible if you have SAS installed on the server. I would use my Data Management utilities (at http://utilities.savian.net) to help you create the SAS datasets and then determine how to push this via a web service. Contact me at my website if you need further information.
Anonymous said…
I am trying to call a SAS job (.sas) from a webservice. I have tried two different methods. One method is to call a batch file with the command line. The other method is to use SAS.Workspace and use submit call. Both methods work on my workstation, but when I try moving it out to the server (running IIS 6), neither works. I have tried all the standard procedures to allow IIS and the directories to have enough permissions to allow this. But still I'm missing something. Do you have any ideas why?
Alan Churchill said…
Almost 100% of the time, it is security related. Always use the Submit within the workspace object.

The first thing to check is the Event viewer and see if you are throwing an exception. That will lead to the rest of the issue. Search for the message in Google becuase I think I have discussed this on SAS-L at some point.

Most likely, you need to set up DCOMCNFG to allow SAS Int Tech to run.

Here is a document to help:


Popular posts from this blog

DNN Error

SAS XPT Files, IBM Floats, and C#

SAS Deployment Manager and Meadow Muffins