25959 - ASP.NET Web Service

Sample 25959: ASP.NET Web Service

Overview

This sample demonstrates how you can build an XML Web service using the Microsoft .NET Framework and SAS Integration Technologies. The .NET Framework makes it very easy to develop a new Web service and write clients to access the Web service. SAS Integration Technologies opens up the power of SAS analytics so it can be accessed through the Web service. This sample presents the necessary code and methodology to make a sample XML Web service run. It also presents the steps necessary to develop an ASP.NET client that accesses the Web service.

An XML Web service enables you to reuse code in a variety of applications. The functionality of the service is typically exposed to Web clients via the Simple Object Access Protocol (SOAP). Information about the functionality that is provided by the service is described in a Web Service Description Language (WSDL) document. The WSDL document enables new users to quickly start using the XML Web service.

When your Web service supports these open standards for XML Web services, you broaden integration options and enable many different applications and programming languages to call your Web service. Any client that supports making method calls using SOAP can call methods on your Web service. So a Java client, ASP.NET client, desktop Windows application, or even Microsoft Word can call the methods in your Web service.

This sample demonstrates how to

write an ASP.NET XML Web service that uses SAS Integration Technologies
call a SAS stored process through a Web service and get back results
create the required COM interop assemblies for the Integration Technologies components
access your ASP.NET XML Web service from an ASP.NET application.

Some of the technologies this sample uses are

ASP.NET Web services
ASP.NET Web Forms
ADO.NET to access SAS data
SAS XML LIBNAME Engine
SAS Integration Technologies.

Explain the Sample Code

The following sections describe the components of this sample:

Web Service: sasws.asmx
- Web Methods
- Private Methods
Stored Process: ProcMeans.sas
ASP.NET Client: default.aspx
- HTML Code
- C# Code

For more information about these topics, see the list of references at the end of this page.

Web Service: sasws.asmx

Now that your Web service is up and running, let's take a look at the source code that makes it run. One thing to note is that all the source code for the Web service is in sasws.asmx. When you use Visual Studio .NET to create a Web service, it specifies and creates a CodeBehind file, which enables Visual Studio to provide a precompiled assembly in the bin directory. You can do the same for your Web service so that the first user of the Web service does not have to encounter delays due to JIT compilation. We chose to include our code in sasws.asmx to simplify deployment. Also, you can add a global.asax or a Web.config file to provide more customization to the application.

Web Methods

This section describes the publicly accessible Web methods that are defined in Service1 (GetDataFromSAS method and RunStoredProcedure method). Methods in a .NET Web service with the <WebMethod()> attribute can be called by a client using SOAP. This sample exposes only two Web methods to clients, but it has several private internal methods that are called by the Web methods.

GetDataFromSAS Method

The GetDataFromSAS Web method is provided to enable a simple test of the Web service. Because it takes no input parameters, this method can be easily used through the browser to verify that the SAS server is running.

First, a SAS workspace is created by calling the GetSAS() method.

This workspace is then used to submit SAS code to the server to run PROC MEANS on the SASHELP.CLASS table and to store the output in the WORK.MEANOUT table.

The WORK.MEANOUT table is then retrieved from SAS by calling the GetData() method. This method returns an ADO.NET DataSet that the Web method then returns to the client. The SAS workspace is then released by calling the DoneWithSAS() method.

<WebMethod()> Public Function GetDataFromSAS() As DataSet
    Dim obSAS As SAS.Workspace = GetSAS()

    ' Create some data
    obSAS.LanguageService.Submit( _
                  "proc means data = sashelp.class;output out=meanout;run;")

    GetDataFromSAS = GetData(obSAS, "work.meanout")

    DoneWithSAS(obSAS)
End Function

RunStoredProcedure Method

Given the name of a stored process and some data, the RunStoredProcedure Web method will send that data to the SAS server and invoke the stored process. It will also retrieve result data back from SAS. Let's take a look at how RunStoredProcedure works.

This method takes two parameters: a string containing the name of the stored process to run and the ADO.NET DataSet containing the data to be used by the stored process. The method returns an ADO.NET DataSet.
```
<WebMethod()> _ 
Public Function RunStoredProcedure(ByVal storedProcedureName As String, _
                                   ByVal inputDataset As DataSet) As DataSet
```
A SAS workspace is created by calling the GetSAS() method.
```
    Dim obSAS As SAS.Workspace = GetSAS()
```

The SendData method is called, which uploads inputDataset to the SAS server.

    ' Send the data to SAS; create the WEBSVC libname
    SendData(obSAS, inputDataset)

The obSASEvents object is set equal to the LanguageService interface of our workspace. This makes it possible to receive events from LanguageService, because obSASEvents was declared with the WithEvents keyword. It is helpful to listen for events in a Web service when runnning a stored process. If there is an error during the stored process execution, the Web service can handle it gracefully or throw an exception.

The Async property of obSASEvents is set to True so that the stored process executes asynchronously. The obSASEvents object is now receiving events to monitor the progress of stored process execution, instead of waiting for the method to return. The Repository property is also set so that SAS knows where to find the stored processes. If you are using a repository other than c:\SASRepository, you will need to modify the code to point to your repository.
```
    ' Run the requested stored procedure
    obSASEvents = obSAS.LanguageService
    obSASEvents.Async = True
    obSASEvents.StoredProcessService.Repository = "file:c:\SASRepository"
```

Now the stored process is executed. The stored process takes a parameter string so that you can pass in variables to the SAS job. In this sample, two variables are passed, inData and outData, which indicate the source and result data sets that are used in the stored process.

    ' Parameters to a StoredProcess are name=value space-separated pairs
    Dim params As String
    ' "inData=WEBSVC.A outData=WORK.OUT"
    params = "inData=WEBSVC." & inputDataset.Tables(0).TableName 
    params = params & " outData=WORK.OUT"
    obSASEvents.StoredProcessService.Execute(storedProcedureName, params)

The stored process is now running, but control has returned to the Web method immediately because obSASEvents.Async is True. The current thread will wait for m_EventComplete to be set before it proceeds. m_EventComplete will be set when the obSASEvents_SubmitComplete event fires. The timeout is 20 seconds, so if the execution takes longer than 20 seconds, a SystemException is thrown. You can increase this wait time if you write your own stored process and it takes longer to execute. Errors during the execution cause a SystemException to be thrown. m_ErrorCount, which is incremented when obSASEvents_StepError fires, keeps track of the number of step errors that were encountered while running the stored process.
```
    ' We are using events to detect errors in the submitted SAS code.  So, we 
    ' will wait here until the SAS code has finished running, and see if we 
	' did get any errors.
    m_EventComplete.WaitOne(20000, True)
    If (m_ErrorCount > 0) Then
        ' Web service exceptions can be caught be the caller
        m_ErrorCount = 0
        Throw New SystemException("The submit has failed:" _
                                  &storedProcedureName)
    End If
```
If you encounter problems during your stored process execution, you can uncomment the following code and view the SAS log in the Visual Studio .NET debugger.
```
    ' This is here for debugging...
    'Dim s As String
    's = obSAS.LanguageService.FlushLog(100000)
```
If the Web method makes it to this point without throwing an exception, then there should be a new SAS data set called WORK.OUT that can be accessed by the workspace. This data is returned to the Web service by calling the GetData() method. This method retrieves the data set from SAS stored in WORK.OUT and then puts the data into an ADO.NET DataSet. This is the DataSet that the Web method returns to the client.
```
    ' This method copies the named SAS data set into a .NET DataSet
    RunStoredProcedure = GetData(obSAS, "work.out")
```
The execution of the Web method is complete when the SAS workspace is released by calling the DoneWithSAS() method.
```
    DoneWithSAS(obSAS)
End Function
```

Private Methods

This section describes the private methods that are used by Service1 (GetSAS, DoneWithSAS, SendData, GetData, obSASEvents_StepError, obSASEvents_SubmitComplete). These methods are inaccessible to clients of the Web service.

GetSAS Method

The GetSAS method returns a SAS.Workspace object. For this sample, a local COM IOM workspace server is created. The code in GetSAS can be modified to connect to any SAS workspace server. See the comment block at the end of the method for some sample code that can be used to connect to a bridge protocol IOM server that is listening on port 5016.

First, an instance of the WorkspaceManager is created. Then CreateWorkspaceByServer is called, passing in the parameters to create a workspace that uses the local COM IOM server. Because this workspace is used to access data sources using ADO.NET, it must be created with VisibilityProcess. This makes it possible for the IOM Data Provider to access the workspace through the WorkspaceManager.

'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
' Make a connection to SAS
Private Function GetSAS() As SAS.Workspace
    Dim obWorkspaceManager As New SASWorkspaceManager.WorkspaceManager()   
    Dim xmlInfo As String

    GetSAS = obWorkspaceManager.Workspaces.CreateWorkspaceByServer("", _
                     SASWorkspaceManager.Visibility.VisibilityProcess, _
                     nothing, "", "", xmlInfo)

    '''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
    ' If you want to connect to an IOM server other than the local COM server, 
    ' uncomment and modify the code below to point to you IOM server.

    'Dim obServer As New SASWorkspaceManager.ServerDef()
    'obServer.MachineDNSName = "machine.company.com"
    'obServer.Protocol = SASWorkspaceManager.Protocols.ProtocolBridge
    'obServer.Port = 5016
    'GetSAS = obWorkspaceManager.Workspaces.CreateWorkspaceByServer("", _
    '                 SASWorkspaceManager.Visibility.VisibilityProcess, _
    '                 obServer, "username", "password", xmlInfo
End Function

DoneWithSAS Method

When a method finishes using the workspace, it releases the workspace by calling DoneWithSAS. An instance of WorkspaceManager is created. Then, RemoveWorkspaceByUUID is called to remove the workspace from the list of available workspaces for WorkspaceManager. The workspace is then closed.

'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
' When done with SAS, clean it up
Private Function DoneWithSAS(ByVal obSAS As SAS.Workspace)
    Dim obWorkspaceManager As New SASWorkspaceManager.WorkspaceManager()
    obWorkspaceManager.Workspaces.RemoveWorkspaceByUUID(obSAS.UniqueIdentifier)
    obSAS.Close()
End Function

SendData Method

The SendData method takes two parameters, a SAS.Workspace object and an ADO.NET DataSet that is uploaded to the SAS server.

Private Sub SendData(ByVal obSAS As SAS.Workspace, ByVal inputDS As DataSet)

ADO.NET provides the ability to write a DataSet to an XML string, and SAS has the ability to read in an XML file using the XML LIBNAME engine. Using these two features, this method will stream data from the Web service to the SAS server and then create a libref that points to the data.

The process involves the following steps:

A temporary fileref named WEBSVC is assigned. The XML file is uploaded to this location.

    Dim obFileref As SAS.Fileref
    Dim assignedName As String
	
    ' Filename websvc TEMP;
    obFileref = obSAS.FileService.AssignFileref("WEBSVC", "TEMP", "", "", _
                                                              assignedName)

A TextStream object is created that is used to stream the XML to SAS. The TextStream object is then opened with write access using obFileref, which was created in the previous step.
```
    Dim obTextStream As SAS.TextStream
    obTextStream = obFileref.OpenTextStream( _
                   SAS.StreamOpenMode.StreamOpenModeForWriting, 2000)
```
Next, the XML header tag is written to the stream. This is required because ADO.NET does not write out this header by default. The XML that is generated by inputDS.GetXML() is written to the text stream and the stream is closed.
```
    obTextStream.Separator = " "
    obTextStream.Write("<?xml version=""1.0"" standalone=""yes"" ?>")
    obTextStream.Write(inputDS.GetXml())
    obTextStream.Close()
```
The data that was in the ADO.NET DataSet inputDS is now available on the SAS server in an XML file. The SAS server uses the fileref WEBSVC to point to this new XML file. This technique works well for small amounts of data; however, larger amounts of data can take longer to process.

Now, the XML data needs to be made available to the workspace. A libref is assigned that points to the WEBSVC fileref using the XML LIBNAME engine. The data can now be accessed in SAS by pointing to WEBSVC.TABLENAME, where TABLENAME is the name of the table in inputDS.

    ' This would be a great place to use XMLMap to transform the schema 
    ' of the provided data set into something that SAS may prefer.   
    ' We'll just use the default mapping.
    '
    ' Note that the libname statement uses the fileref of the same name 
    ' since we didn't specify a file.
    '
    ' Using the IOM method is better than using the Submit since we can 
    ' easily get an error back if there is a problem.
    ' obSAS.LanguageService.Submit("libname WEBSVC XML;")
    
    obSAS.DataService.AssignLibref("WEBSVC", "XML", "", "")        

End Sub

GetData Method

The GetData method gets data from SAS using ADO.NET and the SAS IOM Data Provider. It takes two parameters: a SAS.Workspace object and a string containing the name of the SAS data set that is to be retrieved. An OleDbDataAdapter object is created using an SQL query string that will retrieve the entire contents of the SAS data set name that was passed in. The connection string tells ADO.NET to connect to the SAS IOM Data Provider using the SAS workspace that was passed to the method.

Private Function GetData(ByVal obSAS As SAS.Workspace, _
                         ByVal sasDataset As String) As DataSet
    Dim obAdapter As New OleDbDataAdapter("select * from " & sasDataset, _ 
                         "provider=sas.iomprovider.1; SAS Workspace ID=" _
                                                 & obSAS.UniqueIdentifier)

An ADO.NET DataSet object (obDS) is created and is filled with the data from the OleDbDataAdapter object. The return value of the method is then set to the new DataSet obDS.

    Dim obDS As New DataSet()

    ' Copy data from the adapter into the DataSet
    obAdapter.Fill(obDS, "sasdata")
    GetData = obDS
End Function

obSASEvents_StepError Method

The obSASEvents_StepError method is the event handler for the StepError event that is fired by the LanguageService object named obSASEvents. The m_ErrorCount object keeps a count of the number of errors encountered during the stored process execution. RunStoredProcedure uses this count to verify whether to proceed with retrieving data from SAS or to throw an exception.

Private Sub obSASEvents_StepError() Handles obSASEvents.StepError
    m_ErrorCount = m_ErrorCount + 1
End Sub

obSASEvents_SubmitComplete Method

The obSASEvents_SubmitComplete method is the event handler for the SubmitComplete event that is fired by the LanguageService object named obSASEvents. When this event is fired, the m_EventComplete.Set method is called to indicate to RunStoredProcedure that the stored process execution has completed. m_EventComplete is a System.Threading.ManualResetEvent object that makes a thread wait until some event calls ManualResetEvent.Set which assigns it the signaled state.

Private Sub obSASEvents_SubmitComplete(ByVal Sasrc As Integer) _
                              Handles obSASEvents.SubmitComplete
    m_EventComplete.Set()
End Sub

Stored Process: ProcMeans.sas

ProcMeans.sas is the stored process that is called in the ASP.NET client application. ProcMeans.sas takes two parameters: inData and outData (for more information, see the RunStoredProcedure Web method. These two parameters represent special macro variables whose values are replaced by those that are passed in the parameter string when the stored process is executed.

The ProcessBody statement tells SAS that all macro variables prior to this statement should be replaced by the values in the parameter string.

The inData parameter should point to a valid libref in SAS because it is used as the input data for PROC MEANS. The output is written to the location specified by outData. For this sample, when using the ASP.NET Client, inData should always be WEBSVC.SASDATA and outData should be WORK.OUT.

%LET inData=sashelp.class; * The name of the data set to read;
%LET outData=work.out;     * The name of the data set to create;

*ProcessBody;

proc means data=&inData;
	output out=&outData;
run;

ASP.NET Client: default.aspx

To demonstrate how to access the Web service, we provide an ASP.NET Web Forms page, default.aspx. The Web Forms programming model is a huge step forward in Web programming, providing reusable server controls that can generate HTML as well as fire events that can be handled by server-side script. The Web Forms page consists of two components: the HTML code that defines the contents of the Web form, and the C# server-side script that handles events fired on the Web form.

HTML Code

This section describes the HTML and ASP.NET tags that are used to define the ASP.NET Web Forms page.

The first important tag is the form tag. All Web Forms pages must have a form tag with the attribute runat="server". All of the components of the Web Forms page must be inside this form tag. Otherwise they will not be recognized by the Web form.

<form id="Form1" method="post" runat="server">
<!-- All ASP.NET tags must be enclosed in a form that runs at the server -->

The next ASP.NET tag, asp:datagrid, adds an ASP.NET DataGrid Web control to the Web form. A DataGrid generates nicely formatted HTML tables that display data in an ADO.NET DataSet. The ID of the DataGrid is sourceDataGrid. The ID is the name used to programatically access the DataGrid in a script block.

Additional tags also define the presentation of the datagrid. AlternatingItemStyle indicates that the background color of every other table row will be #DCDCDC. The HeaderStyle tag configures the appearance of the headers for the table so that the column labels are more prominent than the data in the table.

            <asp:datagrid id="sourceDataGrid" runat="server"
             ToolTip="Source DataSet that will be sent to the Web Service.">
                    <AlternatingItemStyle BackColor="#DCDCDC" />
                    <HeaderStyle Font-Bold="True"
                                 ForeColor="White"
                                 BackColor="#000084"/>
            </asp:datagrid>

Next, an asp:button tag is added to the Web form with an ID of Button1. Like all the other asp: tags, it also has the runat="server" attribute. In addition, an onclick attribute is added for the button so that when the button is clicked, it will fire the Button1_Click method.

            <asp:button id="Button1"
                        runat="server"
                        onclick="Button1_Click"
                        Text="Run Proc Means on Data"/>

Another DataGrid Web control is added to the Web form, which will be populated with data returned by the Web service. All the attributes of this datagrid are the same as sourceDataGrid, except for ID and ToolTip. This datagrid is accessible using the ID resultDataGrid in the script block, and the ToolTip displays a more appropriate description of the table.

            <asp:datagrid id="resultDataGrid" runat="server"
                          ToolTip="Result DataSet created by the Web Service">
                <AlternatingItemStyle BackColor="#DCDCDC"/>
                <HeaderStyle Font-Bold="True"
                             ForeColor="White"
                             BackColor="#000084"/>
            </asp:datagrid>

A label Web control is also added to the Web form. If an exception is thrown during execution of the Web service, the exception text is displayed in this label.

    <asp:label id="Label1" runat="server" Height="88px" Width="800px"/>

C# Code

This section describes the C# server-side script that handles events in the Web Forms page (Page_Load, Button1_Click). This code could have been written in VB.NET instead of C#, but to demonstrate some of the capabilities of .NET, we'll call our Web service written in VB.NET with C# code.

Page_Load Method

The Page_Load method is fired when the page begins to load or reload in the event of a post back. This initialization is only necessary for the first page load. This method calls some code to display the data that is sent to the stored process. If a post back occurs (which happens when Button1 is clicked), then sourceDataGrid does not need to be populated again.

First, a new ADO.NET DataSet, sourceDataSet, is created with the name sasdata. sourceDataSet is then populated with the data in the file newDataset.xml, which is located in the virtual directory.

Then sourceDataSet is bound to sourceDataGrid, creating the table to display the data.

<script runat="server" language="c#">

//Fired by the Page Load event.
private void Page_Load(object sender, System.EventArgs e)
{
    Label1.Text = "";
    	
    // On page load we will load the DataSet and display it in a DataGrid
    if (!IsPostBack)
    {
        System.Data.DataSet sourceDataSet = new System.Data.DataSet("sasdata");

        //This command reads in the XML file located in
        //   the current applications virtual directory.
        sourceDataSet.ReadXml(Server.MapPath("newDataset.xml"));

        //Now bind the DataSet to the DataGrid
        sourceDataGrid.DataSource = sourceDataSet;
        sourceDataGrid.DataBind();
    }
}

Button1_Click Method

The Button1_Click method is fired when Button1 is clicked on the Web Forms page. A new ADO.NET DataSet is created and again is populated with the data from the XML file as described above.

Next, an instance of the WebService class, Service1, is created. This class is defined in the assembly webServiceProxy.dll that was created during the ASP.NET client installation. The Web method RunStoredProcedure is then called, passing in the DataSet object and the name of our sample stored process, ProcMeans. If all goes well, a DataSet is returned by the Web method and is assigned to resultDataSet.

Finally resultDataGrid, which is on the Web Forms page, is bound to resultDataSet creating the table to display the data.

If any exceptions are thrown during the execution of Button1_Click, they are caught and the message is displayed as the text of Label1.

//Fired by the Button1 Click event
private void Button1_Click(object sender, System.EventArgs e)
{
    try
    {
        // We are reading in the DataSet again.  For simplicity the
        //   sourceDataSet object isn't stored in the Session object.
        //   Instead of reading the file in a second time, the dataset
        //   could have been stored in the Session object and then 
        //   retrieved during Page_Load.

        // DataSet object to pass into RunStoredProcedure()
        System.Data.DataSet sourceDataSet = new System.Data.DataSet("sasdata");
        sourceDataSet.ReadXml(Server.MapPath("newDataset.xml"));

        // DataSet object to contain the results of RunStoredProcedure()
        System.Data.DataSet resultDataSet;

        //Create a new instance of our Web service, Service1
        Service1 svc1 = new Service1();

        //Call RunStoredProcedure Web method passing in the DataSet
        resultDataSet = svc1.RunStoredProcedure("ProcMeans", sourceDataSet);

        //The results of the storedProcedure execution are now stored in
        //   resultDataSet. Bind the resultDataSet to the resultDataGrid
        //   so we can view the results.
        resultDataGrid.DataSource = resultDataSet;
        resultDataGrid.DataBind();
    }
    catch (Exception ex)
    {
        //Handle errors and display them
        Label1.Text = "Error:  " + ex.Message;
    }
}
</script>

software requirements for running this sample
procedures for downloading and installing the Microsoft .NET Framework SDK
procedures for downloading and installing the Web service
procedures for running the Web service
procedures for installing the ASP.NET client
procedures for running the ASP.NET client.

Software Requirements

To run this sample, you must have the following software installed on your computer:

Windows XP Professional or Windows 2000 (SP2).
Internet Information Services (IIS) 5.
Microsoft .NET Framework Software Development Kit

See Downloading and Installing the Microsoft .NET Framework SDK for information.
The SAS System for Windows, Release 8.2 with SAS Integration Technologies.
The latest SAS Integration Technologies client component for Windows. You can download this software from our Web site. Select SAS Integration Technologies Client (for Windows) from the list of components.

Note: These requirements are for the machine that is running IIS (the machine where the Web service and ASP.NET client are installed). To test the Web service, you need only a Web browser such as Internet Explorer or Netscape on the client machine.

For this sample, you should have a working knowledge of the SAS Integrated Object Model, the Microsoft .NET Framework SDK, VB.NET, and Internet Information Services.

Downloading and Installing the Microsoft .NET Framework SDK

This sample requires the Microsoft® .NET Framework Software Development Kit (SDK). The .NET Framework SDK includes the .NET Framework, as well as everything you need to write, build, test, and deploy .NET applications - documentation, samples, and command-line tools and compilers.

The .NET Framework SDK is a free download and can be installed on Windows XP, Windows 2000, and Windows NT. ASP.NET, which is the major component of the .NET framework that needs to be installed for this sample only runs on Windows XP and Windows 2000. Be sure that Internet Information Services 5 (IIS) is installed on your server before you install the .NET framework. If IIS isn't installed, then you will not be able to install ASP.NET.

To learn more about the .NET Framework or to download and install the SDK, visit the Microsoft .NET Development site.

Install the Web Service

To install this sample:

Download the sample package to your computer and use the WinZip utility to extract the files to a directory on your computer. The package contains the following folders and files:

WebService Folder
- sasws.asmx — the .NET Web service implementation
- ProcMeans.sas — the SAS stored process that the Web service invokes
- readme.txt — readme containing information about this sample
- license.txt — conditions on which we provide this sample
- bin\buildSasInteropAssembiles.bat — batch file to build the COM interop assemblies.
WebServiceClient Folder
- default.aspx — ASP.NET Web Form application that accesses the Web service
- newDataset.xml — XML representation of SASHELP.CLASS that can be read by ADO.NET
- bin\buildWebServiceProxy.bat — batch file that builds the Web service proxy assembly.
In IIS, configure a virtual directory named "WebService" that points to the WebService folder that you created when you unzipped the sample package. The virtual directory will need 'Read' and 'Run Scripts' permissions.

Need help creating a virtual directory? Read Microsoft Knowledge Base Article Q301392: HOW TO: Create a Virtual Folder (Subweb) in IIS 4.0 or IIS 5.0.
After you create this virtual directory, you should view its properties and verify that anonymous access authentication is enabled. After anonymous access authentication is enabled, your clients — in this case, our ASP.NET Web Forms client — will be able to call the Web service without having to authenticate.
Generate the COM interop assemblies. These will call into the COM objects from the .NET Common Language Runtime (CLR). You will need to generate the COM interop assemblies for SAS.tlb and SASWMan.dll.
- Start a command prompt (cmd.exe) and navigate to the bin folder of the virtual directory that you created.
- Run the following two commands to create the COM interop assemblies. You will need to modify the path to your shared files folder if you did not install SAS in the default location.
  
  tlbimp /sysarray "c:\Program Files\SAS Institute\Shared Files\Integration Technologies\SAS.tlb"
  
  tlbimp /sysarray "c:\Program Files\SAS Institute\Shared Files\Integration Technologies\SASWman.dll"
  
  Note: We have also provide a batch file in the WebService\bin directory that contains these commands and that can be executed to build the assemblies.
  
  Note: If the tlbimp.exe command cannot be found, you will need to find this executable on your machine. Two default locations where tlbimp.exe may be located are:
  - C:\Program Files\Microsoft.NET\FrameworkSDK\Bin
  - C:\Program Files\Microsoft Visual Studio .NET\FrameworkSDK\Bin.
  After you have found the folder that contains tlbimp.exe, you should add that folder to your Path environment variable. You will have to restart your command prompt for the changes to take effect.
After running the above commands, you should now have 2 COM interop assemblies in your bin directory:
- SAS.dll
- SASWorkspaceManager.dll.
Create the folder c:\SASRepository and place your SAS stored processes (for this sample, ProcMeans.sas) into this folder. This is the folder where SAS looks to find the stored process it is asked to execute. If you cannot create this folder, you will need to modify sasws.asmx to point to a different stored process repository.
Configure the access and launch permissions. This sample starts a local COM IOM Workspace server. By default, an ASP.NET application cannot launch or access this server so you need to configure the access and launch permissions for the SAS: IOM DCOM Servers application. For more detailed information about setting access and launch permissions, see Setting Launch Policies per Application
- From the Windows task bar, select Start Run.
- Type dcomcnfg and click OK. The Distributed COM Configuration Properties dialog box displays.
- Select the Applications tab, select SAS: IOM DCOM Servers from the list box, and click Properties to view the properties for this application.
  
  Note: On Windows XP DCOM applications are now configured under Component Services. Invoking dcomcnfg will bring up the Component Services Microsoft Management Console. In the tree view, expand Component Services until you see DCOM Config. Select and right-click the SAS: IOM DCOM Servers application to view the properties.
- Select the Security tab:
  
  Give access and launch permissions to the local user ASPNET. ASPNET is the account that all ASP.NET applications run under.
- Ensure that the ASPNET user has the appropriate file access permissions for the SAS installation directory and the temporary and work directories as defined in your sasv8.cfg file. You should also verify that the temporary and work directories are set to a specific directory. This can cause server execution errors because the ASPNET account does not have a user profile.

Run the Web Service

Test the Web service using your Web browser:

http://localhost/WebService/sasws.asmx

This URL opens the Service1 Web Service page, an automatically generated Web page that enables a user to test a Web service. You should now be able to invoke the GetDataFromSAS method interactively using the Web browser. Note that the other method, RunStoredProcedure, does not support the HTTP protocol because it requires an input ADO.NET DataSet. You can also view the WSDL that IIS generates from the source code by clicking on the Service Description link in the browser.

Install the ASP.NET Client

As an example of how to use the Web service, we provide an ASP.NET application. But before you can access the Web service from the ASP.NET application, you must build the Web service proxy file and compile the proxy. For more detailed information, read Create an ASP.NET Web Form Client in the MSDN Library .NET Framework Developer's Guide.

Configure another virtual directory named WebServiceClient that points to the WebServiceClient folder (created when you extracted the sample package). This virtual directory also needs 'Read' and 'Run scripts' permissions.
Verify that you have the .NET tools, wsdl.exe and vbc.exe, in your path.

If you cannot run these tools from a command prompt with a default .NET Framework SDK installation, then you need to find these files on your machine and verify that the path to these tools is included in your Path environment variable. Wsdl.exe is located in the same folder as tlbimp.exe. Vbc.exe, by default, is located at %SystemRoot%\Microsoft.NET\Framework\v1.0.3705.
Start a command prompt (cmd.exe), and change to your WebServiceClient\bin directory.
Run the following commands to generate the proxy file and then compile the proxy file to create an assembly. Modify the wsdl command to point to your web service you installed earlier, if you didn't call your virtual directory WebService.

wsdl /out:webServiceProxy.vb /language:VB http://localhost/WebService/sasws.asmx?WSDL

vbc /out:webServiceProxy.dll /t:library /r:System.XML.dll,System.Web.Services.dll,System.Data.dll,System.dll webServiceProxy.vb

Note: We also provide a batch file in the WebServiceClient\bin directory that contains these commands and that can be executed to build the Web service proxy assembly.
After running the above commands, you should now have 2 new files in your bin directory:
- webServiceProxy.vb (the source code generated by wsdl)
- webServiceProxy.dll (the .NET assembly created by compiling the proxy)

Run the ASP.NET Client

Test the ASP.NET client in a Web browser:

http://localhost/WebServiceClient

When the page loads, you should see a table containing data. When you click the button, the data is sent to the Web service and the ProcMeans stored process is run on the data. If the Web service works correctly, then you should see another table containing the results of the ProcMeans stored process.

Type:	Sample
Topic:	Third Party ==> Output ==> XML Third Party ==> Programming ==> .NET

Date Modified:	2008-02-07 07:46:03
Date Created:	2005-08-01 15:52:35

Product Family	Product	Host	SAS Release
Product Family	Product	Host	Starting	Ending
SAS System	SAS Integration Technologies	Windows Millennium Edition (Me)	8.2 TS2M0
		Microsoft Windows 95/98	8.2 TS2M0
		Microsoft Windows 2000 Advanced Server	8.2 TS2M0
		Microsoft Windows 2000 Datacenter Server	8.2 TS2M0
		Microsoft Windows NT Workstation	8.2 TS2M0
		Microsoft Windows Server 2003 Datacenter Edition	8.2 TS2M0
		Microsoft Windows XP Professional	8.2 TS2M0
		Microsoft Windows Server 2003 Enterprise Edition	8.2 TS2M0
		Microsoft Windows Server 2003 Standard Edition	8.2 TS2M0
		Microsoft Windows 2000 Server	8.2 TS2M0
		Microsoft Windows 2000 Professional	8.2 TS2M0

Knowledge Base