explain web service auxiliary vi

[james brunner]

I'm trying to migrate a web application from LV2009 to LV2010 and I am trying to understand the purpose of the "Auxiliary VI" attribute (found in the Project > Web Service Build Specification > Source Files > Configure RESTful VI dialog).  I have the feeling that I might be able to use such "auxiliary VI's" as functional globals, for example, but I have not found too much documentation regarding their use.

Any help is much appreciated!

--

James

[BTreece]

I am pasting this directly from the LabVIEW 2010 Help:

"Auxiliary VIs run as part of a Web service application but do not exchange data with a Web client. However, auxiliary VIs can exchange data with Web method VIs without using network resources, which can increase overall application efficiency."

I hope you find this helpful.

Brandon Treece

Applications Engineer

National Instruments

[james brunner]

Wow - with that depth of documentation, it's hard to imagine that there's anything left to question

Really, I'm trying to ferret out the behavior and potential uses of these auxiliary VI's (without resorting to too much experimentation).  I was looking at the shipping web service examples - however they do not seem to demonstrate auxiliary VI use.  I am considering using them as sort of functional globals, but wonder how the top-level auxiliary VI sits in the hierarchy (reserved for run, reentrancy, etc. for examples).

--

James

[BTreece]

You could use auxiliary VIs as functional globals.  They are a part of the web service, but do not send data to the web client.  They can run independently but do not communicate to the actual web client.  I have attached some other information from the LabVIEW Help files.

Tutorial: Building and Accessing a LabVIEW Web Service Application (Windows, ETS, VxWorks)

LabVIEW Web Services (Windows, ETS, VxWorks)

Brandon Treece

Applications Engineer

National Instruments

[james brunner]

Brandon, I appreciate your help, and I have read through the help and the additional documents you linked in your post.  However, I still don't really understand the use case or reason for Auxiliary VIs in the web methods.

Let's take the shipped example "LV Queue Server" project.  This project builds and deploys the "netqueue" web service.  It does not use Auxiliary VIs, but it does use a non-web method VI (Queue Manager.vi) that gets launched via VI server and one of the web methods, start queue manager.vi.

Can you contrast the use of this dynamically-called VI (Queue Manager.vi) with the how the Auxiliary VIs are intended to be used?

Again, I appreciate your help.  I hope you understand that I have read through the documentation and have not found an answer that has enlightened me.  That's why I've resorted to asking the community for help and examples demonstrating Auxiliary VIs.

--

James

[BTreece]

In this case, the Queue Manager.vi is the axillary VI.  It is a VI that is constantly running in the background, but does not exchange data with the web service.  In this case, the web methods VIs communicate to the web service, and Queue Manager sends data to those VIs.

I hope that you find this helpful.

Brandon Treece

Applications Engineer

National Instruments 

[james brunner]

Brandon, thanks for the feedback.  Unfortunately your response was not as helpful as you'd hoped.  Can you help me by explaining the example further?

In my (LV 2010) "LV Queue Server > Net Queue RESTful Web Service Properties" project build specification, I see the following list of Source Files (Service VIs):

None of these is the "Queue Manager.vi" that you claimed in your previous post was "In this case, " ... "is the auxiliary VI".  As I (currently) understand the "Auxiliary VI" configuration setting for the VIs in the Service VIs list, they must first be added to the Service VIs list, then subsequenty marked "Auxiliary VI" in the "Configure RESTful VI" dialog box (open by selecting the appropriate VI in the Service VIs list and clicking the "Configure VI..." button).

Perhaps the example installed with my LV 2010 is different than the one you are working with?

Here is an expanded picture of the example project and the dialogs and specific setting to which I am referring:

[BTreece]

Hi James, 

Lets see if I can explain this better.  An auxiliary VI is a VI that is part of the web service and constantly runs when the web service is deployed, but is not a directly exposed web method.  Lets say that you had two VIs.  One VI that you had was an auxiliary VI that established a single element queue, and every iteration of the loop, the value was removed from the queue, incremented by one, and then placed back into the queue.  This effectively is a fancy way of counting the number of iterations that the loop has gone through.  The VI runs constantly while the service is deployed. 

Now say that you have a second VI.  This VI is not an auxiliary VI and is called by the web method.  This VI will dequeue the element off of the queue running on the first VI and display it.  The VI called by the web service is only run once, and looks at the auxiliary VI for its information which is the iteration count.  The auxiliary VI never communicates with the web method.

I hope that you find this more helpful than the information that I provided before.  

Brandon Treece

Applications Engineer

National Instruments

[james brunner]

Hi Brandon,

I'm beginning to get a better understanding.  I guess you figured out why I was confused, because in your previous post you explicitely stated, "In this case, the Queue Manager.vi is the axillary VI.", while it clearly is NOT marked as an auxilary VI in the example project.

For the example, there is an explicit web method, "start queue manager.vi", that starts the Queue Manager VI running.  As you explained, Auxiliary VIs are started automatically and live as long as the web service is deployed.  I presume that these VIs are run top-level (though this detail is missing from the documentation) under the web server's LV application instance, such that they share memory space with the VIs in the web methods.  From this point of view, it seems like the netqueue example could be updated to mark the Queue Manger as an Auxiliary VI, then the "start" web method would no longer be necessary.

I'd also like to see documentation about the implications of Auxiliary VIs in the web service deployment such as:

• is the order of starting auxilary VIs determinate (e.g., more than 1 aux VI in the web service)?
• what happens if the auxilary VIs cannot start (e.g., resource conflict, broken VI, etc.)?
• is there a prescribed methodology for stopping/starting auxiliary VIs?

Your propoal to create a fairly simple project to demonstrate this behavior is well taken, and I will probably cobble one together to see it for myself and experiment a bit.  I had hoped to get the understanding without taking this step, but perhaps should not be surprised at its necessity.

Thanks again and kind regards,

James

[BTreece]

Hi James, 

I am glad that this is starting to become more clear.  I apologize for the confusion earlier.  While the Queue Manager VI is not an auxiliary VI, it acts much like one, however in the example it is not constantly running in the background, but called when it is needed.  I agree that the documentation is not clear.  I will make the proper parties aware of this, but I cannot comment on what or when this will be available.  

Brandon Treece

Applications Engineer

National Instruments