RPC Encoding and Web Services [InfoPath 2003 SDK Documentation]

  • Article

Applies to:

Microsoft Office InfoPath 2003

Microsoft Office InfoPath 2003 Service Pack 1

Web services can expose one of two styles for binding to their Web methods in the Web Service Description Language (WSDL) contract that describes them: Document or RPC. Additionally, each of these two styles of binding can be specified as either literal or encoded. The most common implementations for each type are: document/literal and RPC/encoded. However, the Microsoft Office InfoPath user interface only supports connecting to Web services that were created using the document/literal style.

Most Web service development tools provide a switch for specifying what kind of Web service you want to create. If you are developing a Web service that you will be connecting to from Microsoft InfoPath, you should specify document/literal as your Web service's style and encoding.

If you don't have control over the Web service you want to work with, however, and you need to connect to a Web service created using the RPC/encoded style, you can use either of the following workarounds.

  • Use the SOAP Toolkit to connect to an RPC/encoded Web service.
  • Use a .NET proxy service to connect to an RPC/encoded Web service.

Using the SOAP Toolkit to Connect to a Web Service

If you cannot modify your RPC/encoded Web service, you can use the SOAP Toolkit object model from script to connect to your Web service and invoke the operation you want to use. You can download the Microsoft SOAP Toolkit 3.0 and the SOAP Toolkit 3.0 Redistributable for installation on clients of your Microsoft InfoPath form template from Microsoft Developer Network (MSDN).

The following code example shows how to use the SOAP Toolkit to connect to a Web service using a URL to a fictitious WSDL (http://www.contoso.com/service.asmx?wsdl), and invoking the Web method MyWebMethod, whose input parameters are string values "parameter1" and "parameter2".

var objSoapClass
var strWSDLURL
var strWebServiceResponse
var objNewDOM
var dataFieldsChildren
var dataFieldsNode
var newDataFields

strWSDLURL= "http://www.contoso.com/service.asmx?wsdl"

// Instantiate new SoapClient30 object. 
objSoapClass=new ActiveXObject("MSOSOAP.SoapClient30");

// Initialize the SoapClient30 object using URL to the WSDL
// for the Web Service you want to work with.
soapClass.MSSoapInit(strWSDLURL);

// Pass parameters to Web Service and load XML from response.
strWebServiceResponse=soapClass.MyWebMethod("parameter1","parameter2");

// Instantiate new DOM document object.
objNewDOM=new ActiveXObject("Msxml2.DOMDocument.5.0");
objNewDOM.loadXML(webServiceResponse);

// Disable automatic synchronization the form's underlying XML document.
XDocument.View.DisableAutoUpdate();

// Remove all child nodes to prepare to write response nodes. 
dataFieldsChildren=XDocument.DOM.selectNodes("//dataFields");
dataFieldsNode=XDocument.DOM.selectSingleNode("//dataFields");

for(i=0;i<dataFieldsChildren.length;i++)
  dataFieldsNode.removeChild(dataFieldsChildren(i));
   
// Add new child nodes with response data.
newDataFields=newDOM.selectNodes("//dataFields");
for(i=0;i<newDataFields.length;i++)
  dataFieldsNode.appendChild(newDataFields(i));

//Enable automatic synchronization the form's underlying XML document.
XDocument.View.EnableAutoUpdate();

Script such as this can be used whenever a call to the Web service is needed. For example, if your form needs to refresh its data through the Web service when it is first opened, you would use script like this in the event handler for the OnLoad event of the form. If your form needs to query the Web service after a value is changed in another field, you can use script like this in the field's OnAfterChange event handler. If you need to query the Web service on demand, then you can use script like this in the OnClick event handler of a button control.

Note  Because this script instantiates and makes calls to ActiveX components that can read and write to the file system, it must be deployed as a fully trusted form. For information on how to create and deploy fully trusted forms, see Understanding Fully Trusted Forms.

Using a .NET Proxy Service to Connect to a Web Service

If you don't have control over the RPC/encoded Web service you want to work with, you can create a document/literal proxy Microsoft .NET Web service that provides wrapper functions for each of the Web methods you want to invoke from the RPC/encoded Web service. You can then work with the proxy document/literal Web service from InfoPath.

.NET Framework code is able to work with any type of Web service (both RPC/encoded and document/literal), and all .NET Web services use the document/literal style and encoding. Because the .NET Framework can communicate with any kind of Web service, you can create a .NET Web service with methods that make calls to the RPC/encoded Web service. The .NET Web service will act as a translator that enables InfoPath to make document/literal style calls to the .NET Web service which in turn can make RPC/encoded style calls to the original Web service.

The prerequisites for creating such a proxy Microsoft .NET Web service are a Microsoft Windows XP Professional, Microsoft Windows 2000 Server, or Microsoft Windows Server 2003 running Microsoft Internet Information Services (IIS) with ASP.NET installed on which to deploy the proxy Web service. When you create an InfoPath solution, you will point to the proxy Web service instead of the RPC/encoded Web service. The proxy Web service will then make calls to the RPC/encoded service.

Creating a Proxy Web Service Using Visual Studio .NET

The following procedure describes how to create a proxy Microsoft .NET Web service from Microsoft Visual Studio .NET.

  1. Create a new ASP.NET Web Service project.

  2. In the Solution Explorer, right-click the References folder of your new project, and then click Add Web Reference.

  3. In the Add Web Reference dialog box, type in the URL of the RPC/encoded Web service you want to work with, and then click Go.

  4. Click Add Reference.

  5. Open the .asmx file for your Web service and add one Web method to call each Web method from the referenced RPC/encoded Web service.

  6. To view a list of the methods in the reference RPC/encoded Web server, display the Class View window. For each Web method you will see three methods. For example, if the Web method is called doSearch, then you will see three methods called doSearch, BegindoSearch, and EnddoSearch. You only need to create a wrapper Web method for the doSearch method. Be sure to match the exact method signature and return type.

  7. Within each wrapper method, you need to write code to make a call to the referenced RPC/encoded Web service as shown in the following example.

    [WebMethod]
    public string[] doSearch(string keyword)
    {
        SearchService srch = new SearchService();
        return srch.doSearch(keyword);
    }

  8. If the RPC/encoded Web service requires authentication, you can hard code the credentials required to connect to the RPC/encoded Web service into the source code for the proxy .NET Web service, or you can use code like the following example.

    myProxy.Credentials = System.Net.CredentialCache.DefaultCredentials;

    For more information, search for the "HOW TO: Pass Current Credentials to an ASP.NET Web Service" Microsoft Knowledge Base article on http://support.microsoft.com/.

Creating a Proxy Web Service Without Visual Studio .NET

Alternatively, you can create a proxy Web service by using the tools that are provided with the .NET Framework Software Development Kit, which can be downloaded from MSDN.

Use the Web Services Description Language Tool (Wsdl.exe) to create the code file for your proxy Web service. This code file can be compiled by using the C# command-line compiler (csc.exe) or the Visual Basic .NET command-line compiler (vbc.exe), which are also included with the .NET Framework SDK. After the Web Services Description Language tool has generated the code file, rename the file extension to .asmx and open the file in any text editor. On the very first line of the document, add the following page directive:

<%@ WebService Language="C#" class="GoogleSearchServiceWrapper" %>

Go to the end of the code file and create a call to each Web method in the RPC/encoded Web service. The following code sample shows the code for a .NET Web service that connects to the Google Web service, which uses the RPC/encoded style of development. There is a placeholder for where the wsdl.exe generated code should go.

The following code sample shows the code for a .NET Web service that connects to the Google Web service, which uses the RPC/encoded style of development.

<%@ WebService Language="C#" class="GoogleSearchServiceWrapper" %>

using System;
using System.Web.Services;

// The auto-generated code from the wsdl.exe tool goes here.

[WebService]
public class GoogleSearchServiceWrapper : System.Web.Services.WebService 
{
    [WebMethod]
    public System.Byte[] doGetCachedPage(System.String key, System.String url)
    {
        GoogleSearchService srch = new GoogleSearchService();
        return srch.doGetCachedPage(key, url);
    }

    [WebMethod]
    public System.String doSpellingSuggestion(System.String key, System.String phrase)
    {
        GoogleSearchService srch = new GoogleSearchService();
        return srch.doSpellingSuggestion(key, phrase);
    }

    [WebMethod]
    public GoogleSearchResult doGoogleSearch(
                                System.String key,
                                System.String q,
                                System.Int32 start,
                                System.Int32 maxResults,
                                System.Boolean filter,
                                System.String restrict,
                                System.Boolean safeSearch,
                                System.String lr,
                                System.String ie,
                                System.String oe)
    {
        GoogleSearchService srch = new GoogleSearchService();
        return srch.doGoogleSearch(key, q, start, maxResults,
                                                     filter, restrict, safeSearch, lr, ie, oe);
    }
}

See Also | Understanding Fully Trusted Forms