Article ID: 555057 - View products that this article applies to.
Creating a Stored Procedure to Get the Data You Need
The first step in creating your web service is to create a stored procedure that will fetch the data that you need based on the parameters the user has typed into the form. If your database provides XML functionality, it is often a good idea to leverage this functionality. In this example, I am using the FOR XML EXPLICIT to render XML that will function as the final HTML that the client will render. If your database platform does not support this feature, this manipulation can either be done on the server using the classes in System.Xml or on the client using MSXML.
This stored procedure, using SQL Server 2000, will output something like this:
As you can see, this XML can be used directly on the client, as it is valid HTML.
Creating the Web Service
The next step is to create the web service that you intend to consume. If you are using SQL Server 2000, most of the work is already done for you. If not, then you may need to work with the data that your database returned in order to form it into XML that you can pass back to the client. First, you should create a new web service in your project. Then, the following C# code will return the XML that you need on the client in order to render this SELECT object:
Now you have created a web service, which you should be able to test using the browser interface that the .NET framework provides for you.
Creating the Client Side Script
Now that we have a web service to call, we can implement the client side script. First of all, in the HTML code, you can create a div into which we will insert the SELECT element that we are creating:
When I am creating a client side script to make a web service call, I like to provide the user with feedback so they will understand why their browser is not responding for a moment or two, and that some action is being taken. However, Internet Explorer does not re-render the page it is displaying until such time as the function returns, so we are going to have to break our call up, creating a function that displays the user input first, and then scheduling a call to actually process the web service call:
The actual processing occurs on callback, which we delay by 1 millisecond. Here, we are going to create an XML Document and an XML HTTP object. We are going to use XML HTTP to post to the web service, and store the results in this document. When we create these objects, we are going to iterate through an array of program IDs. For a number of reasons, Microsoft has decided to stop using version independent program IDs. We want to make sure that we are using the most current version, so we are going to start at the latest - 4.0. We will then iterate backwards until we reach version 1.0. This ensures that most clients will work with this script, as MSXML has been included with the operating system since Windows 95 OSR 2.5. If your clients are using Windows 2000, they will have version 2.5 of MSXML by default. If they are using Windows XP, then they will have MSXML 3.0 installed. Once we have instantiated this object, we can fetch the value for the parameter from the current form, build our SOAP envelope (which is simply an XML string - if you want to review the specific format for your web service, the ASMX browser interface will provide this for you when you browse to a method), set our request headers (which can also be reviewed in the browser interface) and submit the request. We set up our call to call yet another function when the HTTP request is complete, as this call will happen asynchronously.
What you should notice here is the simplicity of making a web service request. All that you need to do is review the calling convention, and build up an HTTP request (which is nothing but plain text) that conforms to this convention. By setting the headers and building some XML to send the SOAP request, you have done all that you need to do.
Now that we have sent our request, we simply need to wait for the request to return as completed, and implement our handler to get the results and output the results. We check the ready state to ensure that it is completed. If so, then we can find our object, and insert our text. Here, we can take advantage of the fact that we formatted our XML return set as valid HTML, and we can simply find the SELECT tag (which is the root of what we requested) and set the innerHTML of our div to that return. In our implementation here, we have SQL Server doing all of the work to get the results and format them properly, so the rest of our code needs only to forward along these results until it finally reaches the browser. You should note also that we do search for a specific node. Because we are working with raw XML, our results are going to be embedded inside of an XML SOAP envelope, and we want to dig into this to get at only the results that we expect to find.
Using this technique, you can solve a number of issues. For example, you might want to dynamically list the products you sell based on the state that a customer is located in. You may want to create a DHTML tree control, but you don't want to load all of the nodes at one time because the tree is too big, so you can use a web service call to get only the children of one branch at a time, speeding your rendering. Using web services on the server allows you to implement such dynamic behavior in a way that the .NET Framework explicitly supports, and should make the development task much simpler.
Article ID: 555057 - Last Review: February 13, 2004 - Revision: 1.0
COMMUNITY SOLUTIONS CONTENT DISCLAIMER
MICROSOFT CORPORATION AND/OR ITS RESPECTIVE SUPPLIERS MAKE NO REPRESENTATIONS ABOUT THE SUITABILITY, RELIABILITY, OR ACCURACY OF THE INFORMATION AND RELATED GRAPHICS CONTAINED HEREIN. ALL SUCH INFORMATION AND RELATED GRAPHICS ARE PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. MICROSOFT AND/OR ITS RESPECTIVE SUPPLIERS HEREBY DISCLAIM ALL WARRANTIES AND CONDITIONS WITH REGARD TO THIS INFORMATION AND RELATED GRAPHICS, INCLUDING ALL IMPLIED WARRANTIES AND CONDITIONS OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, WORKMANLIKE EFFORT, TITLE AND NON-INFRINGEMENT. YOU SPECIFICALLY AGREE THAT IN NO EVENT SHALL MICROSOFT AND/OR ITS SUPPLIERS BE LIABLE FOR ANY DIRECT, INDIRECT, PUNITIVE, INCIDENTAL, SPECIAL, CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER INCLUDING, WITHOUT LIMITATION, DAMAGES FOR LOSS OF USE, DATA OR PROFITS, ARISING OUT OF OR IN ANY WAY CONNECTED WITH THE USE OF OR INABILITY TO USE THE INFORMATION AND RELATED GRAPHICS CONTAINED HEREIN, WHETHER BASED ON CONTRACT, TORT, NEGLIGENCE, STRICT LIABILITY OR OTHERWISE, EVEN IF MICROSOFT OR ANY OF ITS SUPPLIERS HAS BEEN ADVISED OF THE POSSIBILITY OF DAMAGES.