Integrating XML Web Services Into Microsoft Office Solutions

Paul Cornell
Microsoft Corporation

September 6, 2001

By now, you have probably heard many people talking about XML Web services. XML Web services are units of application logic providing data and services to other applications (such as Microsoft® Office) over the Internet or your intranet. For instance, imagine a scenario in which you manage a warehouse that supplies windshield wipers to automotive manufacturers across the United States. Currently, imagine that customers place orders over the phone or through a generic order form on a Web page. Now, imagine adding all of the rich functionality of the Microsoft Office applications to your order-entry application. With this functionality, customers could place orders and receive order confirmations from within an Office application, such as a Microsoft Excel spreadsheet template, over the Internet. Additionally, customers could use the rich features of Excel to analyze and report on their orders in a way that makes sense to them.

However, programmatically exposing application logic over the Internet or your intranet is only one of the benefits to using XML Web services. A huge problem that Office developers face today is the issue of solution deployment and versioning. Today, you typically distribute Office solutions as macros or Component Object Model (COM) add-ins. These solutions are tightly bound to particular computers. To deploy COM add-ins, or upgrade these solutions, users must register and reinstall files, which can be distracting. Furthermore, if your users encounter any difficulties while deploying or upgrading these solutions, you may end up wasting hours providing technical support. With XML Web services, you programmatically expose your business services to the public through the Internet, or within your organization over an intranet, using code maintained on individual Web servers or Web server farms. Applications, such as Office, can then call these XML Web services on Web servers over Hypertext Transfer Protocol (HTTP) using Extensible Markup Language (XML) and the Simple Object Access Protocol (SOAP).

Although at first glance this may sound a bit complicated, tools such as the SOAP Toolkit 2.0, and the upcoming Microsoft Visual Studio® .NET and the Microsoft .NET Framework, actually shield you from many of the implementation details of XML Web services. This allows you to leverage your existing skills and solutions to expose your organization's business services over the Internet or your intranet.

In the following section, I will demonstrate how to call an XML Web service from Office. For a more detailed discussion of XML Web services, see Behind the Scenes: A Technical Explanation of XML Web Services at the end of this section. For more information on building your own XML Web services, see Behind the Scenes: Building an XML Web Service near the end of this column.

Calling XML Web Services from Office

Calling XML Web services from Office is similar to calling COM objects; you set references to XML Web services and then call the functions that the XML Web services expose.

Currently, to call an XML Web service:

• You need to know the HTTP address of the XML Web service. Depending on how the XML Web service provider implements the XML Web service, you may also need additional information from the provider (for more information, see the Creating a client solution that invokes the XML Web service section later in this column). If the XML Web service provider publishes the XML Web service using Universal Description, Discovery, and Integration (UDDI), you can search for the XML Web service using Web sites such as http://www.uddi.org. Otherwise, you need to contact the XML Web service provider directly for the HTTP address and additional information.
• You need to know the specific function name and input parameters that you want to call in the XML Web service. Again, you may be able to obtain this information using Web sites such as http://www.uddi.org, or you can contact the XML Web service provider directly.
• You must install the SOAP Toolkit 2.0 Service Pack 2 (SP2) or the SOAP Toolkit 2.0 SP2 Redistributable Files on the client computer that is calling the XML Web service (for more information, see the Installing the SOAP Toolkit 2.0 SP2 or the Installing and registering the SOAP Client DLLs sections later in this column). The SOAP Toolkit 2.0 SP2 is easier to install than the SOAP Toolkit 2.0 SP2 Redistributable Files, but the SOAP Toolkit 2.0 SP2 is slightly larger and exposes tools only developers will use.

Once you have obtained this information and installed SOAP, you are ready to write a solution that calls the XML Web service.

As a simple example, imagine that you work for a manufacturer transitioning from U.S. customary measurements to metric measurements. Rather than write conversion functions yourself, you discover an XML Web service that can do the conversion for you. Here is how to create a simple macro that calls the miles-to-kilometers conversion function in the XML Web service. Imagine that we have a fictional HTTP address for the XML Web service of http://example.microsoft.com/WebServices/MetricConversions.wsdl. The function name in the XML Web service is MilesToKilometers, and the function accepts a Long value representing the number of miles that you want to convert to kilometers. For the sake of simplicity, I will use a number selected in a Microsoft Word document to get the number of miles that I want to convert, as follows:

Public Sub ConvertMilesToKilometers()

    ' Set a reference to the Microsoft SOAP Type Library
    ' (MSSOAP1.dll) first.
    Dim objSOAPClient As MSSOAPLib.SoapClient
    Dim lngKilometers As Long
    
    On Error GoTo ConvertMilesToKilometers_Err
    
    Set objSOAPClient = New MSSOAPLib.SoapClient
    
    ' Bind the SOAP client object to the XML Web service.
    objSOAPClient.mssoapinit _
        bstrWSDLFile:="http://example.microsoft.com/WebServices/MetricConversions.wsdl"
       
    If IsNumeric(Application.Selection) = True Then
        ' Call the MilesToKilometers function in the XML Web service
        ' by using the syntax objSOAPClient.methodname(parameters).
        lngKilometers = objSOAPClient.MilesToKilometers(Application.Selection)
        MsgBox Prompt:=Application.Selection & " miles is equal to " & _
            lngKilometers & " kilometers."
    Else
        MsgBox Prompt:="Selection must contain only numbers. Please try again."
    End If
            
ConvertMilesToKilometers_End:

    Exit Sub

ConvertMilesToKilometers_Err:

    With objSOAPClient
        MsgBox Prompt:="An error occured:" & vbCrLf & vbCrLf & _
            "Fault code: " & .faultcode & vbCrLf & _
            "Fault string: " & .faultstring & vbCrLf & _
            "Fault detail: " & .detail
    End With
    
    Resume ConvertMilesToKilometers_End
    
End Sub

For a complete explanation of this code sample, see Creating a client solution that invokes the XML Web Service at the end of this column.

In the rest of this column, I provide a technical explanation of XML Web services, followed by details on building your own XML Web services.

Behind the Scenes: A Technical Explanation of XML Web Services

Architecturally, an XML Web service solution is comprised of the following components:

• A client application that uses SOAP client dynamic-link libraries (DLLs) to interact with the XML Web service over the Internet.
• A Web server that hosts the XML Web service, implemented as a COM DLL, a Web Services Description Language (WSDL) file, and if the Web server is using the SOAP Toolkit, a Web Services Meta Language (WSML) file.

What Is SOAP?

The Simple Object Access Protocol (SOAP) is an XML-based messaging protocol for exchanging information between client applications and XML Web services. Currently, SOAP is most widely used in conjunction with the Hypertext Transport Protocol (HTTP) for its transport protocol; however, SOAP is an extensible protocol, so it can use other protocols if needed.

Therefore, for the following simple function, two numbers of type Double are added and the sum of these two numbers is returned as a Double:

Public Function AddDoubles(ByVal dblFistNumber As Double, _
        ByVal dblSecondNumber As Double) As Double
    
    AddDoubles = dblFirstNumber + dblSecondNumber

End Function

The following is an example SOAP request and response over HTTP:

Request (sent from the client application to the XML Web service using SOAP over HTTP)

POST/soaplisten/MyAddDoublesWebService.wsdl HTTP/1.1
Content-Type: text/xml; charset="UTF-8"
HOST: MyServer
SOAPAction: "http://tempuri.org/action/NumberCrunching.AddDoubles"
Content-Length: 410
<?xml version="1.0" encoding="UTF-8" standalone="no" ?>
<SOAP-ENV:Envelope 
        SOAP-ENV:encodingStyle="https://schemas.xmlsoap.org/soap/encoding/"
        xmlns:SOAP-ENV="https://schemas.xmlsoap.org/soap/envelope">
    <SOAP-ENV:Body>
        <SOAPSDK1:AddDoubles xmlns:SOAPSDK1="http://tempuri.org/message/">
            <dblFirstNumber>45</dblFirstNumber>
            <dblSecondNumber>32</dblSecondNumber>
        </SOAPSDK1:AddDoubles>
    </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

Response (sent from the XML Web service to the client application using SOAP over HTTP):

HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Date: July 6, 2001 21:34:23 GMT
Content-Type: text/xml; charset="UTF-8"
Content-Length: 445
<?xml version="1.0" encoding="UTF-8" standalone="no" ?>
<SOAP-ENV:Envelope 
        SOAP-ENV:encodingStyle="https://schemas.xmlsoap.org/soap/encoding/"
        xmlns:SOAP-ENV="https://schemas.xmlsoap.org/soap/envelope">
    <SOAP-ENV:Body>
        <SOAPSDK1:AddDoublesResponse xmlns:SOAPSDK1="http://tempuri.org/message/">
            <Result>77</Result>
            <dblFirstNumber>45</dblFirstNumber>
            <dblSecondNumber>32</dblSecondNumber>
        </SOAPSDK1:AddDoublesResponse>
    </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

Here's how the SOAP request and response messages are constructed:

• All of the information before the line <?xml version="1.0" encoding="UTF-8" standalone="no" ?> are properties specific to HTTP. In the request message, the HTTP properties include the request message's destination and action, the HTTP version, the content type, and the length. In the response message, properties include the HTTP version and response code, the Web server type, the date, the content type, and the length.
• Both the SOAP request and response messages include an Envelope element and a Body element. The format of a SOAP message is defined in the https://schemas.xmlsoap.org/soap/envelope namespace using the SOAP-ENV namespace prefix. The optional encodingStyle attribute references a set of encoding rules that defines how data types are mapped to XML in a SOAP message.
• The AddDoubles element in the request message and the AddDoublesResponse element in the response message describe the data being passed to and from the XML Web service. We use the default namespace http://tempuri.org/message/ to qualify the element names in the request and response messages. You can modify the namespace to make your element names unique.
• In the request message, the dblFirstNumber and dblSecondNumber elements describe the data being passed to the XML Web service. In the response message, the Result element describes the data being passed from the XML Web service. The response message also echoes the original dblFirstNumber and dblSecondNumber elements so that we can verify them.

The nice thing about the SOAP Toolkit is that it automatically generates SOAP messages to transport XML Web service requests and responses over HTTP for you.

What Is WSDL?

The Web Services Description Language (WSDL) is an XML format for describing XML Web services. A WSDL file is a contract that says if a client computer submits a properly formatted SOAP request to a Web server, that Web server is obligated to provide the corresponding XML Web service.

Therefore, for the AddDoubles function described in the previous section, the following is an example WSDL file:

<?xml version="1.0" encoding="UTF-8" ?> 
<definitions  
        name ="MyAddDoublesWebService"   
        targetNamespace = "http://tempuri.org/wsdl/"
        xmlns:wsdlns="http://tempuri.org/wsdl/" 
        xmlns:typens="http://tempuri.org/type" 
        xmlns:soap="https://schemas.xmlsoap.org/wsdl/soap/" 
        xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
        xmlns:stk="https://schemas.microsoft.com/soap-toolkit/wsdl-extension"
        xmlns="https://schemas.xmlsoap.org/wsdl/"> 
    <types>
        <schema 
            targetNamespace="http://tempuri.org/type"
            xmlns="http://www.w3.org/2001/XMLSchema"
            xmlns:SOAP-ENC="https://schemas.xmlsoap.org/soap/encoding/"
            xmlns:wsdl="https://schemas.xmlsoap.org/wsdl/"
            elementFormDefault="qualified">
        </schema>
    </types>
    <message name="NumberCrunching.AddDoubles">
        <part name="dblFirstNumber" type="xsd:double"/>
        <part name="dblSecondNumber" type="xsd:double"/>
    </message>
    <message name="NumberCrunching.AddDoublesResponse">
        <part name="Result" type="xsd:double"/>
        <part name="dblFirstNumber" type="xsd:double"/>
        <part name="dblSecondNumber" type="xsd:double"/>
    </message>
    <portType name="NumberCrunchingSoapPort">
        <operation 
                name="AddDoubles" 
                parameterOrder="dblFirstNumber dblSecondNumber">
            <input message="wsdlns:NumberCrunching.AddDoubles" />
            <output message="wsdlns:NumberCrunching.AddDoublesResponse" />
        </operation>
    </portType>
    <binding 
            name="NumberCrunchingSoapBinding"
            type="wsdlns: NumberCrunchingSoapPort" >
        <stk:binding preferredEncoding="UTF-8"/>
        <soap:binding style="rpc"
            transport="https://schemas.xmlsoap.org/soap/http" />
        <operation name="AddDoubles" >
            <soap:operation
            soapAction="http://tempuri.org/action/NumberCrunching.AddDoubles" />
            <input>
                <soap:body use="encoded"
                    namespace="http://tempuri.org/message/"
              encodingStyle="https://schemas.xmlsoap.org/soap/encoding/" />
            </input>
            <output>
                <soap:body use="encoded"
                    namespace="http://tempuri.org/message/"
               encodingStyle="https://schemas.xmlsoap.org/soap/encoding/" />
            </output>
        </operation>
    </binding>
    <service name="MyAddDoublesWebService" >
        <port name="NumberCrunchingSoapPort" 
            binding="wsdlns: NumberCrunchingSoapBinding" >
            <soap:address location=
                "http://MyServer/soaplisten/MyAddDoublesWebService.wsdl" />
        </port>
    </service>
</definitions>

Here's how the WSDL file is constructed:

• A WSDL file contains a root element named definitions. The definitions element provides the name of the XML Web service, along with the namespaces used in the WSDL file.
• The first child element, types, describes the XML Schema Definition (XSD) of any complex types used in the WSDL file. Because this WSDL file only uses simple XML Schema types, the types element contains an empty schema element, and is provided here only for completeness.
• Next, the two message elements describe the message names, NumberCrunching.AddDoubles and NumberCrunching.AddDoublesResponse, that will store the data passed to and from the XML Web service. Each message element contains one part element for each piece of data passed to and from the XML Web service: dblFirstNumber, dblSecondNumber, and Result. Each message part is an XML Schema type of double.
• The portType element describes the mapping between the messages described in the message elements and the operations that use them. For the AddDoubles operation, the input is the NumberCrunching.AddDoubles message, and the output is the NumberCrunching.AddDoublesResponse message.
• Next, the binding element defines a network transport protocol binding between the operations defined in the portType element and how they are implemented in the protocol. In this case, we are using the SOAP protocol.
• Finally, the service element ties the SOAP binding to the physical implementation of the service. This is where the URL of the WSDL file is described.

For more information on WSDL, you can also see the article Web Services Description Language (WSDL) Explained.

One benefit of the SOAP Toolkit is that the WSDL/WSML Generator (part of the SOAP Toolkit) can automatically generate WSDL files for you.

If you are using the SOAP Toolkit, the WSDL/WSML Generator will also automatically generate WSML files for you. WSML files are used by the SOAP Toolkit to map the operations in the WSDL file to the functions in the COM DLL. Here is an example WSML file for the AddDoubles function:

<?xml version="1.0" encoding="UTF-8" ?> 
<servicemapping name="MyAddDoublesWebService">
    <service name="MyAddDoublesWebService">
        <using PROGID="MyAddDoublesWebService.NumberCrunching" 
            cachable="0" ID="NumberCrunchingObject" />
        <port name="NumberCrunchingSoapPort">
            <operation name="AddDoubles">
                <execute uses="NumberCrunchingObject" 
                    method="AddDoubles" dispID="1610809344">
                     <parameter callIndex="1" name="dblFirstNumber"
                         elementName="dblFirstNumber" />
                    <parameter callIndex="2" name="dblSecondNumber" 
                         elementName="dblSecondNumber" />
                    <parameter callIndex="-1" name="retval" elementName="Result" />
                </execute>
            </operation>
        </port>
    </service>
</servicemapping>

Here's how the WSML file is constructed:

• The root servicemapping element identifies the service element that a WSDL-to-COM DLL mapping is describing. This must match a service element in the corresponding WSDL file.
• The service element contains a using element that identifies the COM DLL.
• The port element specifies the portType element in the WSDL file. For each operation element, in a portType element in the WSDL file, there is one operation element in the WSML file.
• In the operation element there is an execute child element that specifies the object that executes the operation. The uses attribute describes the object name, the method attribute specifies the method name, and the dispID attribute specifies the dispatch ID of the method.
• In the execute element there are parameter child elements that describe the method parameters. A callIndex attribute value identifies the parameter as a return parameter.

In most cases, similar to WSDL files, you will never need to directly edit WSML files.

Behind the Scenes: Building an XML Web Service

Here are the steps to building an XML Web service using the SOAP Toolkit 2.0 SP2, which is currently available to Office developers:

1. Build a COM DLL by using a COM-compliant development application, such as Microsoft Visual Basic® 6.0 Professional or Enterprise Edition.
2. Register the COM DLL on a Web server running Internet Information Services (IIS). Valid Web servers are Microsoft Windows NT® 4.0 SP 6 or later, or Microsoft Windows® 2000 Server or later. If you built the COM DLL on the same computer as the Web server, the COM DLL will already be registered when you click Make DLL on the File menu in Microsoft Visual Studio®.
3. Download and install the SOAP Toolkit 2.0 SP2 on the Web server.
4. On the Web server, use the SOAP Toolkit 2.0 SP2 WSDL/WSML Generator to write the COM DLL functions as WSDL and WSML files.
5. Place the WSDL and WSML files in a publicly available virtual directory on the Web server.
6. Install and register the SOAP Toolkit 2.0 SP2 client DLLs on the client computer.
7. Create a client solution that invokes the XML Web service on the Web server by using the SOAP Toolkit 2.0 SP2 client DLLs.

Building and registering the COM DLL

The first step in creating an XML Web service is to create a COM DLL using a COM-compliant development application such as Visual Basic, just as you would with any other COM DLL.

When you create COM DLLs in Visual Basic 6.0 that run on IIS Web servers, make sure to select the Retained in Memory and Unattended Execution check boxes on the General tab, in the Project Properties dialog box (Project menu) before you compile the COM DLLs.

Installing the SOAP Toolkit 2.0 SP2

The next step in creating an XML Web service is to install the SOAP Toolkit 2.0 SP2 on the Web server. Before installing the SOAP Toolkit 2.0 SP2, you must have the Visual Basic 6.0 runtime files, Microsoft Internet Explorer 5.0 or later, and the Microsoft XML parser (MSXML) 3.0 SP1 or later installed. The SOAP server objects will run on Microsoft Windows NT 4.0 SP6 or Microsoft Windows 2000 Server. The SOAP Toolkit 2.0 SP2 download Web page contains more information about these and other installation prerequisites. When you meet all of the prerequisites, you can access the SOAP Toolkit 2.0 SP2.

After you download and install the SoapToolkit20.exe file, you will notice the following four entries in the Microsoft SOAP Toolkit menu, located on your Start menu:

• Read Me, which contains installation and troubleshooting information.
• Trace Utility, which monitors and reports SOAP transactions.
• User Guide, which contains documentation.
• WSDL Generator, which creates WSDL and WSML files from COM DLLs. The WSDL/WSML Generator requires that you install Visual Studio or Visual Basic 6.0 first.

Using the WSDL/WSML Generator

Next, you must create an XML representation of your COM DLL, in the form of a WSDL file and a WSML file. The WSDL/WSML Generator in the SOAP Toolkit 2.0 SP2 can do this for you automatically. The WSDL/WSML Generator works only on Windows NT and Windows 2000 computers with IIS installed. The WSDL/WSML Generator will ask for the following information:

• The name of your XML Web service (this will become your WSDL and WSML file names).
• The local path to your COM DLL.
• The functions you would like to expose.
• A URL to which you'll bind the SOAP listener. Before you run the WSDL/WSML Generator, you should create a virtual directory in IIS to which you'll bind the SOAP listener.
• The type of SOAP listener. For most XML Web services, you should leave the default option, ISAPI, selected.
• The XSD Schema namespace (you should leave the default choice of 2001 selected).
• The WSDL file character set (UTF-8 or UTF-16).
• The location where you would like to store the WSDL and WSML files (preferably in the newly created virtual directory).

The only Visual Basic data types (and their XSD equivalents) that can be passed to and from XML Web services at this time are: Boolean (xsd:boolean), Byte (xsd:unsignedbyte), Date (xsd:dateTime), Double (xsd:double), Integer (xsd:short), Long (xsd:int), Single (xsd:float), String (xsd:string), and Variant (xsd:anyType). Arrays and multidimensional arrays based on these types are also supported. Optional parameters are not supported. The WSDL/WSML Generator maps these Visual Basic data types to their corresponding XSD data types. If the WSDL/WSML Generator encounters a data type that I have not listed, the data type will be listed as "????????" in the WSDL file. Using a text editor such as Notepad, you would need to change any "????????" references in the WSDL file to one of the valid XSD equivalents listed previously using the WSDL file as part of a solution.

**Note   **Office object types (for example, Application objects, Document objects, Range objects, and so on) cannot be passed to and from XML Web services. Only the XSD objects listed previously can be passed to and from XML Web services.

Hosting the WSDL and WSML files on a Web server

If you specify an ISAPI SOAP listener for your XML Web service in the WSDL/WSML Generator, the soapisap.dll file on the Web server will automatically handle the loading of the WSDL and WSML files, and the SOAP messages to and from the client application. Once you place the WSDL and WSML files in the IIS virtual directory you specified in the WSDL/WSML Generator, you are ready to receive XML Web service requests.

Installing and registering the SOAP Client DLLs

The SOAP client DLLs will run on Microsoft Windows 98, Microsoft Windows Millennium Edition, Microsoft Windows NT 4.0 SP6, and Microsoft Windows 2000 SP1.

Download the SOAP Toolkit 2.0 SP2. The redistributable files are comprised of two Microsoft Installer merge files, soap_core.msm and isapi_files.msm. These merge files can be added to a Microsoft Installer (.msi) file using an application such as the Visual Studio Installer. This .msi file can then be run on the client computer, where it installs and registers the SOAP client DLLs automatically.

Creating a client solution that invokes the XML Web service

To develop a client solution that calls an XML Web service, you must first set a reference to the Microsoft SOAP Type Library (MSSOAP1.DLL) from the client.

Once you have set a reference to MSSOAP1.DLL, you can call the AddDoubles XML Web service as follows:

Private Const FIRST_NUMBER As Double = 45
Private Const SECOND_NUMBER As Double = 32

' Calling subroutine.
Public Sub CallAddTwoNumbers()

    MsgBox Prompt:="The sum of " & FIRST_NUMBER & " and " & _
        SECOND_NUMBER & " is " & AddTwoNumbers _
        (dblFirstNumber:=FIRST_NUMBER, _
        dblSecondNumber:=SECOND_NUMBER) & "."
        
End Sub

' Called function.
Public Function AddTwoNumbers(ByVal dblFirstNumber As Double, _
        ByVal dblSecondNumber As Double) As Double
    
    ' You must first set a reference to the Microsoft
    ' SOAP Type Library (MSSOAP1.DLL).
    Dim objSOAPClient As MSSOAPLib.SoapClient
    
    On Error GoTo AddTwoNumbers_Err
    
    Set objSOAPClient = New MSSOAPLib.SoapClient
    
    ' Bind the objSOAPClient object to the XML Web service.
    objSOAPClient.mssoapinit _
        bstrWSDLFile:="http://MyServer/soaplisten/MyAddDoublesWebService.wsdl", _
        bstrServiceName:="MyAddDoublesWebService", _
        bstrPort:="NumberCrunchingSoapPort"
        
    ' Call functions in the XML Web service
    ' by using the syntax objSOAPClient.methodname(parameters).
    AddTwoNumbers = objSOAPClient.AddDoubles(dblFirstNumber, dblSecondNumber)
    
AddTwoNumbers_End:

    Exit Function

AddTwoNumbers_Err:
    
    With objSOAPClient
        MsgBox Prompt:=Err.Description & ":" & vbCrLf & _
            "Fault code: " & .faultcode & vbCrLf & _
            "Fault string: " & .faultstring & vbCrLf & _
            "Fault detail: " & .detail
    End With
    
    Resume AddTwoNumbers_End
   
End Function

In the preceding code example, the CallAddTwoNumbers subroutine calls the AddTwoNumbers function, which passes the numbers 45 and 32 to the XML Web service. To bind the SoapClient object to the correct XML Web service, the SoapClient object's mssoapinit method is used, which takes the following parameters:

• bstrWSDLFile: This required parameter is the URL of the target WSDL file.
• bstrServiceName: This optional parameter is the name of the appropriate service element in the WSDL file. By default, the first service element in the WSDL file is used.
• bstrPort: This optional parameter is the name of the appropriate port element in the WSDL file. By default, the first port element in the WSDL file is used.
• bstrWSMLFile: This optional parameter (not shown in the preceding example) is the URL of the target WSML file. I omitted this parameter from the example because I am not using any custom data type mappers (I am only using the built-in XML Schema data types in this solution).
• Once the mssoapinit method is successfully called, you can call any of the functions in the XML Web service by using the familiar object.method(parameters) syntax. Unfortunately, you cannot use Microsoft IntelliSense® to provide you with automatic syntax completion. You will need to provide the method and parameter names manually, and syntax checking will not occur until run time.

Note   The Web Services Proxy Wizard can be used to enable IntelliSense in the Visual Basic Editor. The Web Services Proxy Wizard requires Microsoft Visual C++® 6.0, but you do not need any experience with C++ to use the Wizard. If you do choose to use the Web Services Proxy Wizard, your Visual Basic implementation code will look slightly different. The technical article that accompanies the Web Services Proxy Wizard download describes the minor changes that you will need to make to your Visual Basic code.

• If there is an error in your code, the faultcode, faultstring, and detail properties of the SoapClient object provides robust error reporting (similar to the Microsoft Visual Basic for Applications Err.Description property). For example, in the WSDL file, I changed the value of the location attribute in the soap:address element to use port 8080, instead of the standard port 80, so that I could enable tracing with the SOAP Toolkit's Trace Utility in conjunction with IIS. When I forgot to change the value back to use port 80, the detail property gave me enough information to find my mistake.

Where to Go for More Info

• For more information on WSDL, see the article Web Services Description Language (WSDL) Explained.
• Download the SOAP Toolkit 2.0 SP2.
• Download the SOAP Toolkit 2.0 SP2 Redistributable files.
• Web Services Proxy Wizard
• The MSDN Web Services Developer Center contains additional information on XML Web services.

Paul Cornell works for the MSDN Online Office Developer Center and the Office developer documentation team. He spends his free time playing card games with his wife and reading to his daughter.