How it works

The Web Service Proxy Generator lets you access most SOAP 1.x Web services. It works by using the .NET WSDL client generator tool create a .NET Web Service client Proxy which is then accessed from Visual FoxPro using wwDotnetBridge.

Here's an overview on how it works:

The process works like this:

1. Run the Proxy Generator Wizard
   You start by running the proxy generator Wizard and specifying a WSDL file to import a service from.

2. Generate produces .NET assembly
   The .NET WSDL generation creates a .NET assembly that maps the WSDL service. The generated assembly contains the actual SOAP service interface (ie. the service methods that are exposed) as well as all the dependent objects that are required in order to pass and retrieve data from the service.

3. Generate produces FoxPro PRG Class
   The Proxy Generator also creates a FoxPro class that maps the .NET service class. The PRG has the same methods as the .NET Service proxy and makes it easy to call the service. The FoxPro proxy also pre-configures an instance of wwDotnetBridge which you can then use for accessing more advanced .NET structures like Arrays, Value Types, Enums in order to pass them to and from .NET.

4. Your application uses the FoxPro Proxy
   Your application then creates an instance of the FoxPro proxy class. You can call the service methods on this proxy directly (ie. loProxy.MyServiceMethod(parm1,parm2) and you can access the raw .NET service loProxy.oService and wwDotnetBridge loProxy.oBridge to perform more low level tasks.

The idea is that you can use the rich support of the .NET WSDL client generator tool (WSDL.exe) to generate the .NET proxy and then call it from Visual FoxPro. The Proxy Generator facilitates this process by creating a FoxPro proxy client class that maps each of the methods in the .NET proxy generated. The FoxPro proxy code generated uses wwDotnetBridge to provide the FoxPro to .NET interoperability in order to avoid COM registration of components and allow easier access to complex types supported by .NET and that are exposed in common Web Service scenarios.

The process of calling a service is very simple:

LOCAL loProxy as WebStoreServiceProxy 
loProxy = CREATEOBJECT("WebStoreServiceProxy")

*** Call a Service method
loItem = loProxy.DownloadInventoryItem("WWHELP40")

*** Create a new item -  use full .NET typename (look up in Reflector)
loItem = loProxy.oBridge.CreateInstance("WebStoreService.wws_itemsRow")
loItem.Sku="NEWITEM"
loItem.Descript = "New Item Added from Client"

lcResult = loProxy.UploadInventoryItem(loItem) 

*** Retrieve an array of items
loItems = loProxy.DownloadInventoryItems("")

*** Result is a ComArray object - wrapper around a .NET array
? loItems.Count

*** .NET Arrays are 0 based so count from 0
FOR lnX = 0 to loItems.Count -1
    loItem = loItems.Item(lnX)
    ? loItem.Sku + " - " + loItem.Descript
ENDFOR

*** Update an item
loItem = loItems.Item(0)
loItem.Descript = loItem.Descript + " Updated"

*** Upload changed array back to the service
loProxy.UploadInventoryItems(loItems)

More Complex Object Interactions - You'll need wwDotnetBridge

The previous examples are very easy because the Web Service is set up in such a way that all the service methods can directly provide for all the features used - basic objects and arrays and simple values.

If you need to create objects, and arrays to pass to a service however, very frequently you need to drop a little lower level using wwDotnetBridge to create this data to pass.

If you want to better understand wwDotnetBridge and how to interact with the .NET objects from your Web service I recommend you take a look at the wwDotnetBridge and Com Interop White Paper that goes into much more detail.