use more than 28 input terminals with webServices

[carri]

Hi everyone,

I have a VI with more than 28 inputs, and I want to create a WebService to access it, but I only have 28 inputs to wire with the VI, How can I do that?

[Francois Normandin]

Hi everyone,

I have a VI with more than 28 inputs, and I want to create a WebService to access it, but I only have 28 inputs to wire with the VI, How can I do that?

Maybe I don't understand the question correctly... but you can bundle some data into a cluster to use less inputs to your VI.

This is not the most convenient connector pane I've seen. (just an opinion)

<a href="http://content.screencast.com/users/normandinf/folders/Jing/media/d74f18d1-74c3-4f69-972a-1c032c12dadd/2010-11-25_0927.png"><img'>http://content.screencast.com/users/normandinf/folders/Jing/media/d74f18d1-74c3-4f69-972a-1c032c12dadd/2010-11-25_0927.png"><img class="embeddedObject" src="http://content.screencast.com/users/normandinf/folders/Jing/media/d74f18d1-74c3-4f69-972a-1c032c12dadd/2010-11-25_0927.png" width="39" height="38" border="0" /></a>

[carri]

That solution is valid if I were to use the VI like a subVI, but in WebService it isnt a valid solution. The build of the service shows an error due to an unsupported data type (the cluster).

[Francois Normandin]

That solution is valid if I were to use the VI like a subVI, but in WebService it isnt a valid solution. The build of the service shows an error due to an unsupported data type (the cluster).

I've never used WebServices, so your answer will be educative for me even if it's not doable:

Can you flatten to string, pass it to your web service, and unflatten the bundled data inside?

[mje]

Never used WebServices either, but can you not encode several pieces of data into a single input? Encode it on the client and interpret it in your VI. Ugly I know, but I don't think you can get around the hard limit of available connector types.

[carri]

both solutions are possible, althought are very ugly. The second solution is better, because you send the variables in the URL header, and sending a string with special characters such . or , is easier than sending XML code, i think.

I was looking for another solution more pretty and more scalable. A VI with more than 28 inputs is now a very big VI, and adding all this extra functions makes it more messy.

PS: Sorry for my english, its very bad

[John Lokanis]

That would be one heck of a URL string for all 28 inputs. Here is a more elegant solution. In LV2010, you can create web service VIs that will persist beyond the first call in memory (when setting up the VIs as source files, there is an Auxiliary VI setting). Using this technique, you could create several VIs and split the 28 inputs amongst them. These web service VIs would be called first and would store the input values. Then the last one or a later one could be used to 'execute' the function.

[carri]

it songs very good, but i'm using the version 8.6, and i have to use it. I will try to test this solution, it maybe worth. Thanks!!