Using web services with the AF

[cirrusio]

Hello all,

I have run into a problem with an AF build on a real-time system.  This application uses web services to send command to and retrieve data from the server (the AF application).  The main application communicates with the web server through a functional global variable that contains the message queue reference to the controller. The system runs fine and is relatively robust in development mode but when I go to build and run the exe, the exe builds but bombs on run (when debugging the exe, the launching VI has a broken run arrow).  I am beginning to think that the breaking point is the communication between the web service and the main application instance.  Unfortunately, I can not get the logs from the debug session right now, but it seems that the exe is trying to load the message VIs from two different locations when the web service is starting.  It's unclear to me why this is but seems to have something to do with the build process (web service VIs seem to load from an altogether different space than the main portion of the exe).  I have attached the build log (doesn't seem particularly illuminating to me) and will get a copy of the message logs when I get a chance, but any insight would be appreciated.

One thought that I had was to actually sepearate the web service from the main application instance (i.e. publish the web service rather than letting the application kick it off) and then using TCP to communicate messages between the two (maybe Network Endpoint Actor?).  Might this be a better way to do this?

Thanks, cirrus

[AristosQueue (NI)]

As with all other "the AF and appbuilder" bugs, I'll start by saying my usual mantra:

The AF is just VIs. There's nothing special about AF from LV's point of view. So double check all the things that can go wrong with building applications of your VIs without AF before trying to identify something special involving the AF. 

I am not an AppBuilder expert, so I cannot help debug your issue (though I'm hopeful that others on this mailing list can), but almost every time a question like this has appeared, the problem has been in the non-AF part of the app, and the other times, the users were trying to do something special with the AF itself. I wish I had more to offer, but maybe this helps you focus on other places first.

[cirrusio]

No, I agree. The honus is not on AF itself.  My question is more geared towards those who have experience with this type of application.  This problem has been a persistent one for me (several frustrating months now with no good solution from AE) so I am looking for anyone at this point who has had experience with this type of AF application.  The real question that can be answered here is what is the best approach to communicating between the AF and a web service in an exe on a real time machine.  I believe the source of my headaches (as I said above) may reside with how the web service is bundled in the exe and would like to decouple the two.  To that end, maybe one of the already developed solutions is sufficient (LNA, NEA?), but it is not clear to me.... What I want to know if how have others done this type of communication in their own work.

[MattP]

As AQ mentions above, this likely is not related to AF.

I have seen a similar issue in building a large embedded application that exposes communications via a web service and talks to the main application via queues.  I was able to fix it relatively simply, though the rationale is a bit annoying.

First, I assume you're working with a relatively recent version of LabVIEW (2014+), since we changed the way web services work several versions ago.

To determine if you're seeing the same issue that I saw:

Create a new build specification that does not include the web service.  In this build spec, enable the 'Modify project library file after removing unused members option'

If the resulting rtexe runs without issue, but disabling that option causes the rtexe to break, you have the same issue I had.

You might still have the issue if the above test does not match my results, but it makes for a good sanity check.

Unfortunately, if you have web services included in the build, you can't enable that option in the build spec.

Solution (short version): have two build specifications, one with the web service, one without.  Replace the exe built with the web services with the one built without the web services.

Solution (long version):

Have two build specs.  One without the web services, and with the 'Modify project library file after removing unused members option' enabled.

Build this.

Another build spec, with web services included.  Also, you will need to set any libraries/vis/typedefs that are common dependencies of both the web service(s) and the rtexe to have their destination set in the Source File Settings section of the build spec to be the rtexe.

Build this.  Delete the rtexe from this build output, replace it with the rtexe from the first build.

Deploy this build spec to the target.  It should work.

[MattP]

The reason we need to set the source file destination in the second build is because the web services apparently get built first, including any dependencies into the web service itself.  If you also have those same source files included in the rtexe, you get load conflicts when it tries to pull in two versions of the same source files.  Forcing the destination to be the rtexe removes those files from the web services, and places them where we expect to find them.

You can also create a 'Build project' VI that automates the process of building both build specs and replacing the relevant rtexe to avoid the manual pain of this approach.

[cirrusio]

MattP wrote:

As AQ mentions above, this likely is not related to AF.

OK...so I understand what you are saying, but to say it is not related to the AF is not exactly correct (and that was what I was saying above).  Since the AF is so highly coupled to it's messages, this is something you are likely to see with an AF project utilizing web services.  And this is actually what you seem to be saying in the next comment - web services get built first and therefore something is going on with how references are handled in common VIs (or at least this is my take on it) which results in the exe breaking.  This is not unique to the AF but it is something you will likely see in any AF project that uses web services to send messages to the actors themselves (which will create a mutual dependency on the message for the actor and the web service). Your response, which hopefully is useful, points to a big issue with the utilization of the AF in a very real scenario.  Hence the reason this is posted here and not in the forums - if what you are saying is correct, then the highest probability of someone having seen this issue resides with the AF community given all of the queue communications.

But, back to your comment - building the project without web services was actually going to be my next step.  My question (once again) is, given all the steps that you have provided above, would it be better to completely decouple the web service side from the controller side of the application, build them into two separate application instances and just have them communicate via tcp?  I am kind of feeling like this might have been the best approach (deploying web services on an RT target is a nightmare anyway and could really do without this part).

[MattP]

Not related to AF in the sense that it's not AF's fault.  Basically, if you have shared dependencies between the web service and the executable, you'll need to tell the project where you want those shared dependencies to go.

The application I ran into the above issue with did not use Actors (nor, indeed, classes) at all.

So...correlation, certainly.  Causation, no.

I personally like web services on RT targets - even with the grief associated with finding that solution, they still have been a net time savings for me, particularly in decoupling the RT system from the PC side.  Your mileage may vary, but I don't suggest dumping them entirely.  You may well find that alternatives have their own pitfalls.

Also, pro tip: you can lump all of the shared dependencies into a virtual folder in your project, and set the source destination properties for all items in the folder at once in the build spec.  No need to do so individually.

[cirrusio · Accepted solution]

OK, so this was a confounding problem that was not caused by the web service. As it turns out, there was one actor that had a problem with its core and it was rippling through the entire system.  What I don't get is why no errors are showing up in the run time environment...does anyone have any thought concerning this?

[AristosQueue (NI)]

What was the error in the Core?

[cirrusio]

The error had to do with a frame in a timed loop.  Not sure why, but removing the built in sequence and replacing it with a flat sequence solved the problem.