What Are SAS BI Web Services?

A Web service is an interface that enables communication between distributed applications. Web services enable cross-platform integration by enabling applications that are written in various programming languages to communicate by using a standard Web-based protocol. This functionality makes it possible for businesses to bridge the gaps between different applications and systems.

The following figure shows how Web services work.

In general, SAS BI Web Services expose SAS Stored Processes for execution by using Web service protocols. Remote clients are then able to specify input parameters, drive execution of SAS code, and obtain results from that execution. Also, Web services make it possible to write clients that perform this act in a myriad of languages and on a variety of operating systems by using HTTP to exchange messages. Web services can enable a service-oriented, enterprise application approach, or they can support the development of mobile or Web clients, all of which leverage reusable SAS Stored Processes.

There are two core types of SAS BI Web Services: XMLA and structured Web services. Structured Web services can further be divided based on how you access the services and the format of the messages that you send and receive.

SAS BI Web Services expose a single XMLA Web service endpoint with two operations: Discover and Execute. Clients call Discover in order to obtain information from the system, including the list of SAS Stored Processes that are available for execution by the XMLA engine, the inputs and outputs of those stored processes, and other metadata about the stored processes. Clients can then use the Execute operation to specify input, execute a stored process, and obtain the results of that execution. The XMLA Web service is more limited than structured Web services because it provides only a general interface for invoking stored processes. For example, XMLA includes a Web Service Description Language (WSDL) file, but because XMLA can be used to execute any number of stored processes, this WSDL does not actually describe the stored process inputs and outputs. Instead, the WSDL describes the information that the Discover calls will return to the client. This makes XMLA Web services unsuited for use with client Web service libraries where automatic proxy generation and easy service execution are desired. Also, XMLA only supports XML and the SOAP protocol for all operations and does not support many features of SAS Stored Processes.

In SAS 9.3, all stored processes are available individually for execution using Web services without any action required from the user. SAS BI Web Services automatically exposes a WSDL file for each and every stored process that is available in the system. These WSDL files use XML to include detailed information about the inputs and outputs of each stored process using XML schema descriptions. Also, the WSDL file includes the URLs of endpoints to use to invoke these stored processes by using SOAP over HTTP. You can use these WSDL files to automatically generate code in your client framework of choice that can be used to invoke the Web services. SAS BI Web Services exposes these services using a simple mapping from the metadata folder path of the stored process.

You can group multiple stored processes together in a single, named Web service using the Deploy As Web Service wizard in SAS Management Console. In 9.2, these were called generated Web services because the wizard generated a grouping (and because server artifacts were actually generated as well). You can group stored processes for Web service execution to simplify management or to enable generated client code to invoke more than one stored process. The grouping generates a single WSDL file that describes all stored processes together in one document and all stored processes in a generated Web service grouping are invoked at the same, unique endpoint based on the name of the generated service. Stored processes that are a member of a generated Web service are still individually available for execution.

All structured Web services can be invoked by using SOAP over HTTP. SOAP strictly defines message structure, including the envelope containing headers and body. SAS BI Web Services define the content (and namespace) of the payload within the body. In addition, SAS 9.3 BI Web Services support Javascript Simple Object Notation (JSON) and plain XML as message formats for all structured Web services. The format of input XML messages for a structured Web service can be deduced from its WSDL file. The addition of new output resource URL suffixes in conjunction with the new SAS folder path mapping means that SAS BI Web Services now support Representational State (REST) style Web service invocation.

SAS BI Web Services for Java are administered by using JBoss, Oracle WebLogic, or IBM WebSphere. If you install SAS BI Web Services for Java, then you also need to have a Java Virtual Machine for an application server. For more information about administering and configuring Web services, see the SAS Intelligence Platform: Web Application Administration Guide.