Starting in SAS 9.3, all stored processes are available individually
for execution using SAS BI Web Services without any action required
on your part. You no longer have to run the Deploy as
Web Service wizard in SAS Management Console. For every
stored process, you can obtain a description of the structure of input
and output web service messages that can be used to invoke the stored
process. The document that describes this structure is called a Web
Services Description Language (WSDL) file. SAS BI Web Services automatically
exposes a WSDL file for each and every stored process in your 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 the SOAP protocol over HTTP. Typically,
you use these WSDL files to automatically generate code in your client
framework that can be used to invoke the web services. Structured
web services are all SAS BI Web Services that can expose a WSDL file
that describes their inputs and outputs. Structured web services are
all non-XMLA SAS BI Web Services.
Having all the type
information in the WSDL is better suited to most client applications,
and also makes things simpler for you. Making the WSDL more specific
to the actual parameters instead of having a generic interface enables
you to simplify the request XML. Making the WSDL more specific also
makes it easier to consume the web service with standard web service
client applications such as BizTalk, InfoPath, Word, SharePoint, Excel,
AJAX, Oracle WebLogic, and WebSphere, or in general any framework
that can generate proxies from WSDL and schema.
In addition to being
able to access stored processes directly from a web service endpoint,
you can also group multiple stored processes together into a single
web service. These web services are called generated web services.
You might choose to use the grouping mechanism because it might reduce
the amount of generated client code in your application. Many web
service client frameworks produce a proxy object for each web service,
and grouping stored processes into a single web service could reduce
the number of generated proxy objects to one.
All structured web services
support SOAP over HTTP and RESTful invocation using JSON and plain
XML. Depending on the message format - SOAP, JSON, or plain XML -
different features of structured web services are available for you
to use. SOAP is a recognized enterprise format with many existing
standards that describe how to interact with web services of this
type. SAS BI Web Services support WS-Security for securing messages
and the WS-I Attachments Profile for attaching binary content to request
and response messages when using the SOAP transport. SOAP endpoints
also expose a WSDL file that describes the inputs and outputs of the
request and response messages, respectively. This enables you to use
client frameworks to generate proxies that invoke these web services
and reduces the amount of code that you have to write to integrate
with SAS Stored Processes.
Starting in SAS 9.3,
SAS BI Web Services also expose all structured web services as RESTful
resources that can be invoked by using either JSON or plain XML inputs
and outputs. JSON is a popular message format typically used by AJAX
web applications because JSON is a native data representation in JavaScript.
However, JSON can be used from any client. Plain XML is an ideal message
format for situations where SOAP libraries are not available or the
complexity and features of SOAP are not desired. When using plain
XML to communicate with SAS BI Web Services, use the same XML format
as you would use with SOAP, but SOAP headers, SOAP elements, and namespaces
can all be omitted.