LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Web Service streaming response, and/or console generation

Solved!
Go to solution

I have some LabVIEW (not NXG) Web Service methods that perform some fairly long-running operations, and I'd like to be able to provide feedback as the process is executing. I have configured these methods to be "streaming", but the actual output isn't rendered on the client until the operation is completed.

 

I know there is a "flush buffer" method, so I did attempt writing intermediate output messages and then flushing the buffer immediately. However, I want to wait to return the final status code until the end of the process, in case it fails. It appears to throw an error if you try to set the status code after flushing the buffer.

 

Are there any ways we can actually stream a series of messages to the client as a web service method is running? Or, short of that, is there a way to write to the browser console programmatically, so we could at least provide more realtime feedback of the process there?

0 Kudos
Message 1 of 6
(1,633 Views)

Another possibility might be to pursue an async request-reply pattern, so I created this separate post on that topic.

0 Kudos
Message 2 of 6
(1,622 Views)

I've posted an answer in your other topic on how an async request pattern could look like.

But reading the description of what you're looking for, it looks like SSE might be a better fit.

 

SSE is implemented pretty much as you've stated, by configuring the method to use streaming, and using the flush function to push intermediate data.

 

It should however adhere to some rules regarding how the response body is formatted to be recognized by most browsers as a valid SSE stream.

 

0 Kudos
Message 3 of 6
(1,607 Views)

Thanks for the response, Jorn_Deruyck!

 

I guess I must still be missing something, because it doesn't seem to work the way (I think) you describe.

 

I put together a quick test (attached in zip file) to try to stream output messages at 1Hz for 5 seconds, but Chrome doesn't see any data until the entire operation completes.

 

SSE_test.PNG

 

 

 

 

 

 

 

 

 

 

 

 

 

 

You can see I have it configured to Stream, and I am actually flushing the buffer after every message, but as shown in the Chrome inspector view, nothing shows up until a full 5 seconds have passed. 

 

Also: it throws a warning when I try to set the status code after performing a flush. As you can see in the screenshot, I attempted to set the code to 500, but according to Chrome, it actually received 200. (And, again, the flush doesn't appear to be working for me, anyway...although I swear I did see it work once before).

 

I have also tried disabling buffering in the web service properties, but that doesn't appear to have any effect.

 

Can anybody see what I am missing here?

Download All
0 Kudos
Message 4 of 6
(1,585 Views)
Solution
Accepted by TurboPhil

Hi TurboPhil

 

I believe you have to set the correct "Content-Type" header value to "text/event-stream" for this to be recognized as an EventStream

 

I recreated your project (still at LV2018) and tweaked the code a bit so that it should work.

This example should be correctly identified by Chrome as an EventStream:

(not sure why the individual events don't show in the list tho, I know this used to work)

Jorn_Deruyck_0-1610642461113.png

 

I doubt if you can push a different status code though since you already acknowledged the request with the 200 status code.

As I said, SSE is quite limited in its capabilities, the asynchronous operation pattern using a separate resource that represents the operation as a newly created resource fits better within the REST paradigm.

 

But SSE is still useful due to its simplicity!

 

Message 5 of 6
(1,581 Views)

Thanks! That was it.

I had actually started trying to do this myself, but I was using the "Set MIME Type" function, instead of the content headers, so it still wasn't working. Your example got me unstuck. Kudos!

 

I'll still need to think some more about how I can handle the dynamic status code, so I might need to pursue a more complex async request-reply, but even if I do that, I imagine I might want SSE involved during intermediate steps to provide status updates as processes are running...

0 Kudos
Message 6 of 6
(1,569 Views)