Arrays are a real pain with COM. Reading arrays is possible and if you're dealing with straight class types should just work, but updating arrays is nearly impossible.

I'd recommend you call your .NET wrapper with wwDotnetBridge which wraps arrays/collection and provides a COM friendly wrapper that lets you keep the array/collections in .NET and access them via a proxy. This allows for reading and writing of arrays using common object syntax and never transfers the Array into FoxPro - you basically pull each of the items out of the array individually which bypassed the sucky COM array marshalling and allows access to all common array operations you would expect.

Using ComArray to access .NET Arrays/Collections

wwDotnetBridge is open source on Github or part of West Wind Client Tools or Web Connection.


If the service is a SOAP service rather than WS-* service (ie. no special WS* protocols ontop of SOAP 1.x) you can also look at the West Wind WSDL Generator which auto-creates a FoxPro and .NET Proxy for you so you don't have to manually create a wrapper class in .NET. Even if you don't use this tool (it's basically an automation tool), using the older WSDL tooling for SOAP 1.x services is usually much easier to integrate with from FoxPro. I reserve using WCF for working with services that require WS*.


+++ Rick ---


>Hi all:
>
>We have a group of legacy webservices in VFP9-SP2 on W2K3 server with SoapToolkit that we need to migrate to W2K12, but using the same VFP9 code.
>
>Because 2K12 does not support SoapToolkit, I'm making WCF envelopes for those VFP9 webservices using ComSvcConfig utility.
>
>The problem i'm facing is that I don't know which parameter type is needed to receive arrays.
>
>I'm going in more deep to explain.
>
>The legacy in-house framework allow external calls to internal webservices using a middleware, which is composed of a Java component and a MessageQueue.
>
>Clients use this middleware to send XML data, then the middleware processes this XML data using XML input/output templates so the data is formatted specifically for each webservice to acomodate the parameters, which allows that the webservices can be updated and evolved without changes in the client side.
>
>
>Example of the legacy webservice:
>
>The client data send something like this through middleware:
>
>

><DATA
>   <value1>Client-data-1</value1>
>   <value2>Client-data-2</value2>
></DATA
>

>
>and after template processing by the middleware, it can be transformed in something like this:
>
>

><soapenv:Envelope
>      xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
>      xmlns:cff="http://tempuri.org/07B8B002-BCCC-4E34-9F51-15721C0B1E3C">
>   <soapenv:Header/>
>   <soapenv:Body>
>      <cff:calc_price>
>         <lpoRs_Data>
>            <VALUE>
>               <RecordSet REG="1">
>                  <value>Client-data-1</value>
>               </RecordSet>
>               <RecordSet REG="2">
>                  <value>Client-data-2</value>
>               </RecordSet>
>            </VALUE>
>         </lpoRs_Data>
>      <cff:/calc_price>
>   </soapenv:Body>
></soapenv:Envelope>
>

>
>Finally, the middleware send this SOAP message to 2K3 server, whose WSDL have some SoapToolkit-specific extensions configured to call serializer/deserializer components which create RecordSet components that ends calling the COM+ component that receives those RecordSets.
>
>
>Migrating the webservice with WCF envelope
>
>Ok, SoapToolkit can't be used, so we changed parameter types of VFP/PRG components "as string" (because WCF does not support ADODB-RecordSets), like this:
>
>

>* ws_module.prg
>DEFINE CLASS CALC AS CUSTOM OLEPUBLIC
>   PROCEDURE calc_price
>      LPARAMETERS value1 as string, value2 as string && Params.previously were RecordSets
>      (business rules and calculation)
>      RETURN lcResponse
>   ENDPROC
>ENDDEFINE
>

>
>and then made WCF envelopes using ComSvcConfig tool, which creates a WCF proxy for each component with WSDL contracts that reflects that "string" parameters.
>
>So far so good.
>
>The problem is that using the same SOAP input, the service throw an error like this:
>
>Error in deserializing body of request message for operation 'calc_price'. End element 'lpoRs_Data' from namespace 'http://tempuri.org/07B8B002-BCCC-4E34-9F51-15721C0B1E3C' expected. Found element 'VALUE' from namespace ''.
>
>
>So it seems like, because the expected WSDL parameter is "string", then the serialized value (which is, I suposse, an array) causes this error.
>
>
>The questions then, are:
>
>1) What type of parameters are needed on the VFP side to receive those (array?) values, knowing that VFP does not allow specifying "as array"? (look at intellisense options to see them)
>
>2) In the case that nothing can be done on the VFP side: Is there some configuration that can be done with the WCF envelope to specify different parameters than specified on the VFP components?
>
>3) If yes: HOW?
>
>
>Sorry for this LOOONG post, but I prefer to give enough data to comment.
>
>Thanks!
>
>Fernando D. Bozzo