soap webservice error and guid use

[NeilA]

I have imported a SOAP webservice that a colleague wrote and I had errors in three of the methods. Finally I managaed to create the missing services by hand building the missing sections using .NET functions that I hope will work. I cant try them out as now I have realised that there is a bit missing from the functionality of each method. The SOAP header contains a GUID which we have named UUID I have access to the UUID property in LabVIEW but its input is a refnum. I think that the input needs to be in GUID form as that is the way the WSDL describes it but I cant find a way to do this in LabVIEW. The way this function is to work is that the initialise methods sends a UUID which is subsequently used throughout further method calls until a complete message is called. I was expecting this to be a string that I could keep available in a shift register to validate each time. Do you think it would be easier for me to ask for this to be constructed as a string or can I build something to do this in LabVIEW?

[Andrew McL]

Hi NeilA,

Thank you for contacting National Instruments. I think it may be easier to change your .NET assembly to return this data as a String, rather than changing data from within LabVIEW.

Could you possibly code the .NET assembly to initialise the GUID and then pass this value out to LabVIEW.

Please let me know your thoughts.

[NeilA]

The .net assembly is to be used by several different RF test systems made in house or by suppliers so it makes it awkward at this stage to make changes to the .net assembly since the data type for the guid may have been implemented already by a supplier.

I have actually gotten round this now! I struggled to get any of the methods to work, I have 12 in total and needed to do alot of manipulation of data in to an XML string to be sent with in most of the methods. Because of this I have now opted to build the whole of each method as an XML string in soap format , add the HTTP post header and send the message using TCP connections. It is slighly long winded but since I do not need to make a UUID and can format all the input parameters from standard LabVIEW primitive types to string this seems to be currently the best option I have.

Of course I may have issues later down the line with scalability and implementing changes but I should be fine since the methods are in a stable state for now.

Let me know your thoughts,

Neil Andrew.