Head's Up: content on this page hasn't been updated in a few years so the playing field has certainly changed (e.g. Flash option may no longer be viable).

Navigating information-packed SAS result sets frequently requires highly interactive user interfaces. Traditional web apps have generally fallen short in this regard. Rich internet applications (RIAs) created through products like Flex and Silverlight, on the other hand, can deliver UI's with functionality almost on par with that of desktop apps (and bring other benefits such as consistency across browsers). The rich UI's of RIAs and the incredible analytical power of SAS are a perfect complement.

This primer describes options for putting RIA front-ends onto SAS back-end processes. Since RIA integration with SAS is often done through web services that will be the focus of this primer. While most of this content applies to RIAs in general, some is Flex-specific.

While this overview may be useful to SAS programmers it is primarily targeted at RIA developers unfamiliar with SAS. Though high level in scope all sections include links to more detailed resources.

SAS backgrounder for RIA developers

SAS supports a variety of industry-standard APIs used by RIA developers. However, support varies based on the SAS products you license, and even within products there are implementation choices — for example, the web services mid-tier can be based on Java or .NET.

The SAS System supports both ODBC and JDBC access through a combination of drivers and product options. However, while direct access to SAS data can be useful the real power of SAS comes from exploiting its analytical capabilities. For this type of access SAS provides its Integration Technologies product.

SAS Integration Technologies (SAS IT) exposes the SAS system to client applications. It includes very robust Java support as well as support for COM, .NET, and Web Services. It also has features such as LDAP support and capabilities for push, messaging, authentication, etc. that won't be covered here (for complete details on SAS IT see the list of references below).

This primer focuses on RIA-SAS integration via web services. Keep in mind that there are other options, such as direct access to SAS via Java.

SAS IT includes two servers through which client applications can interface with the SAS system:

• the Workspace server - exploitation/management of persistent server-based SAS sessions
• the Stored Process server - execution of stored processes which can be exposed as a web service (has more functionality than the workspace server, e.g. support streaming results)

To use SAS web services for RIA access you'll want to use the SAS Stored Process Server.

Server configuration information is stored in and managed by a metadata repository, the SAS Metadata server. In a departmental or enterprise SAS installation (e.g., SAS hosted on a Solaris E-class server) the SAS Metadata server is the sole repository for metadata required by that SAS system installation. Among other things, this includes details on the web services you create — both WSDL-related info (e.g., the operations and operations parameters) and service management info (e.g., access rights). Among other benefits this centralization of metadata facilitates the creation of client-server applications.

SAS provides support for client-server protocols through its Integrated Object Model, or IOM. IOM is a core component of the SAS architecture, used by the SAS Metadata Server (part of Base SAS) as well as the Stored Process Server (part of SAS IT) and other SAS product servers (e.g., OLAP server). Through IOM your RIA can access the full capabilities of the SAS system; IOM "enables you to use industry-standard languages, programming tools, and communication protocols to develop client programs that access these services on IOM servers. The IOM Bridge communications protocol enables diverse clients to connect transparently to IOM servers on multiple platforms." (from Overview of SAS Integration Technologies).

As you can see from figure 1 below there is a wealth of options for clients accessing SAS through IOM servers. Note that this diagram shows the "SAS Intelligence Platform", the SAS System's overall distributed processing architecture;. SAS IT provides a subset of what is shown in the diagram (for example, it does not include the IOM OLAP server).

Fig1. SAS "Intelligence Platform" (distributed processing architecture)

For RIAs the most robust client access to SAS IOM servers is via Java through a feature of SAS IT called SAS Foundation Services. Foundation Services lets you use Java to access the full functionality of the SAS System, including creating and managing SAS sessions. If you want to use straight Java then this is your best option. Here are some references on interacting with SAS via Java:

• SAS 9.2 Integration Technologies Java Client Developer's Guide
• This pdf covers the mid-tier including server J2EE config (note: 12MB doc)
• And here is an entry point to the online (HTML) pages on this topic

While this primer focuses on accessing SAS stored processes via web services it's important to note that you can develop RIAs that directly use SAS stored processes. You can do this through SAS IT's Web Infrastructure Platform (previously Web Infrastructure Kit). The WIP provides support for a variety of web app needs (e.g., authentication). Particularly useful is its ability to execute a SAS stored process and stream back the results through its Stored Process Web Application (which is very similar to SAS's first foray into surfacing SAS functionality to the web, SAS/IntrNet). Through the Stored Process Web Application you execute a SAS stored process via the standard HTTP paradigm — invoke a URL and get back a response that you can display or process. Here are some references:

• Summary of WIP features
• Phil Mason's SGF 2011 paper "Using SAS Stored Processes with JavaScript and Flash to Build Web-Based Applications"
• Building a Web Application with SAS Stored Processes
• Web Application Administration Guide, Fourth Edition

SAS IT also includes SAS BI for web services, which provides standard web services support (e.g., discovery of services) and lets you execute SAS stored processes and stream back the results as XML (and, with new features of SAS 9.2, also add attachments for binary data). RIA access via web services will be the focus of the remainder of this primer.

Here are some references on SAS open architecture and protocols support (just a sample, much more on the SAS Site):

• SAS Integration Technologies factsheet
• SAS site pages for Integration Technologies
• Integration Technologies online doc manifest
• SAS IT Roadmap
• SAS 9.2 Intelligence Platform: Overview, Second Edition
• SAS site pages for Business Intelligence
• SUGI paper 030-29 on Java and SAS, "Developing and Deploying Java Applications Around SAS: What they didn't tell you in class". Though nearly five years old this is still a great resource on the topic
• PharmaSUG paper "Access to SAS Data Using the Integrated Object Model (IOM) in Version 9.1" -- from 2005 but still useful

RIA integration with SAS

As noted above, RIAs have multiple options for accessing SAS. At a conference last year SAS employee Guillaume Curat made a presentation on the integration of Flex and SAS which included the diagram shown below in figure 2.

Fig 2. From Guillaume Curat presentation 2009

RIA/SAS integration is most commonly done through web services. Use of a service-oriented archtiecture (SOA) makes SAS processes available to all major RIA products.

When you create a web service in SAS you associate it with one or more SAS stored processes — basically, centralized and usually parameterized SAS programs. So, the starting point in exposing SAS to an RIA is to create SAS stored processes with the SAS functionality you want to surface to your RIA. Once your stored processes are written you can publish them as web services through SAS BI web services. The latter is part of SAS IT and two versions are available, SAS BI web services for .NET or SAS BI web services for Java.

So, for RIA-SAS access via web services the integration path is:

1. within SAS you create SAS stored processes with the processing you want to surface to the RIA
2. within SAS you publish these stored processes as web services
3. in your RIA you create the code that interrogates the WSDL and makes the appropriate operations calls through the mid-tier server (Java or .NET)

The next few sections provide information on these 3 steps.

1. Creating SAS stored processes

SAS stored processes are essentially SAS programs written to SAS stored process conventions. They are generally parameterized, with parameters coded as SAS macro variables.

SAS stored processes can be directly accessed/executed from within the SAS system. They can also be published as web services, thus making them executable by non-SAS processes.

When you create a SAS stored process you register it to the SAS metadata server. During registration you provide information on access rights, execution server, input parameters, etc.

The registration of your SAS program as a stored process is most easily done through the SAS product Enterprise Guide 4.2, though you can also use the SAS Management Console. Several of the references below walk you through this process (a good starting point is SGF Paper 015-2010 Flex Your SAS Muscle).

SAS stored processes can create output in a variety of formats available in SAS (e.g., you could generate a graph as PDF, a report as RTF, etc.). However, for stored processes that you want to publish as web services your program must be written to generate XML. For other restrictions see Writing SAS Programs for Web Services.

Selected References: SAS Stored Processes

• SAS Site - Stored Processes developer info
• SGF Paper 330-2009: SAS Stored Processes: Going Beyond the Current Capabilities of the Stored Process Wizard
• SGF Paper 015-2010 Flex Your SAS Muscle
• Paper HW06-2009 SAS Enterprise Guide 4.2 and Stored Processes

2. Publishing SAS stored processes as web services

After your SAS program is registered as a SAS stored process it can be published as a web service. To do this you can use SAS BI Web services, which itself is part of SAS Integration Technologies.

As noted previously, SAS BI Web Services has a Java implementation, which requires a servlet container, and an implementation that uses the .NET framework. For more information on these options see the SAS BI Web Services web page "Deciding Between .NET and Java".

Fig 3. Accessing SAS via web service - from SAS BI Web Services Developer's Guide

The actual registration process for your web service is performed through the SAS Management Console and its Web Service Maker. Several of the references below walk you through this process (a good starting point is SGF Paper 015-2010 "Flex Your SAS Muscle").

Note that the web service to stored process is not a 1:1 relationship — that is, a web service can be associated with multiple stored processes, with each stored process becoming a web service operation.

Any parameters used by a stored process become web service operation parameters. As with all web services, these operations and their parameters will be included in the web service's WSDL that SAS will generate.

Selected References: Publishing SAS Stored Processes as Web Services

• SAS Site — Web Services developer info
• SGF Paper 004-2009 Tips and Techniques for Analytic Web Services
• SGF Paper 015-2010 Flex Your SAS Muscle

3. Consuming the web services

This section is especially brief since this primer assumes most readers are unfamiliar with SAS but not with Flex.

Flex access to web services is straightforward, facilitated by Flex Builder features that let you generate AS classes (including value objects to retain data types) through WSDL inspection.

From the Flex Builder 3 documentation: "You can use the Flex Builder Import Web Service feature to automatically generate connection code for invoking SOAP-based web service operations. The generated code includes client-side (ActionScript) web service proxy classes that return strongly typed objects. You can use the generated code to call web service operations directly and to pass strongly typed objects as operation parameters."

To have Flex Builder (Flex 3) inspect the WSDL and generate AS classes for selected WSDL operations use the menu option: Data > Import Web Services (WSDL). If you are using Flash Builder (Flex 4) use the menu option: Data > Connect to Web Service.

Once you have your proxy classes you can use the Flex WebService class to invoke the web service operations. There are many resources on this topic, but if you are new to using the WebService class I'd recommend the "Flex in a Week" training videos.

Optimization tip: When integrating Flex and SAS consider adding Adobe's server-based BlazeDS into the picture. When server and client exchange XML data you have a lot of overhead — XML is very verbose and performance on large result sets can be problematic. However, a Flex-BlazeDS connection can use Adobe's Action Message Format (AMF), a binary protocol that is much more efficient than XML over HTTP or SOAP. This can result in dramatic performance gains (and BlazeDS has other useful features such as strong data typing, push/messaging, etc).

Selected References: Flex consumption of Web Services

• Here I'll again reference Joe Flynn's excellent SGF Paper 015-2010 Flex Your SAS Muscle
• Adobe livedocs for Flex 3: Automatically generating web service proxies
• Devnet has some brief introductions on using web services, including an intro and another on using the Flash Builder "Import web service" feature.
• Devnet also has a short video on integrating Flex and Java you might find useful.
• "Flex in a Week" has some training videos, including "Retrieving and handling data with WebServices" and "Making a WebService request with parameters".
• Adobe TV also has some long presentations on use of Web Services, for example the MAX 2008 Duane Nickull and Chistopher Conraets 1 hour presentation "Adobe adoption of Web Services, SOA and REST"
• If you're interested in BlazeDS Adobe TV also has a nice intro into BlazeDS.

SAS and Flex

SAS is already using some Flash and Flex in its own browser-based applications, most notably its BI Dashboard. At this year's SAS Global Forum a paper presented by a SAS employee started out like this:


However, while I've had verbal confirmation that this is the direction SI is taking, as of late summer 2010 the SAS web site offers no official confirmation of this. It will be interesting to see what information (and SAS web-based products with Flex UIs) is released at the next SAS Global Forum.

Catch-22 for explorers of RIA-SAS integration

Unlike other software companies, SAS offers no evaluation copy of SAS*. This makes it difficult for the individual developer who wants to explore a RIA-SAS connection. Of course, if you are working for a company that is interested in SAS you can contact SAS sales and usually you can obtain a copy of SAS for evaluation. On the other hand, SAS is not cheap, and you may have trouble getting small to mid-size companies to consider licensing SAS.

Another complication with RIA-SAS integration is simply the breath and complexity of options available. This is compounded by the rapidly changing features of SAS — in this area SAS has evolved especially rapidly over the past few years. For example, the list of supported web servers changed between SAS 9.1 and SAS 9.2 (the latest version), dropping Apache.

* SAS does offer a reasonably priced "Learning Edition" but it does not include SAS IT and is not supported on Vista or Win 7

Conclusion

Hopefully this primer has given you a useful overview of your options, but if you're serious about a RIA-SAS project you should contact SAS Institute. I've worked on several projects where the folks at SI have been very generous with advice and even resources (of course, those projects were at very large pharmas with enormous buckets of $$$, so your mileage may vary).