Enabling gRPC Generic Event in Server Template

[KarthikAbiram]

A generic user event was added to the template few years back (#29), so that users can have the option of getting a single event for all gRPC methods, like below:

This was quite handy for keeping the generated code and user code separate as well as allowing users to implement their own handlers/dispatchers.

Could someone please let me know how I can get this feature with the latest template?

AB#2963372

[jasonmreding]

I don't have a lot of background context on this, but I'm not sure this feature was really ever fully implemented/tested. Either that or subsequent changes to the LV code broke it. From looking at the code, it appears that only one event type is active in the server code at a time. So you can either receive a single generic event notification for all RPCs or an event that is specific to each RPC but not both. By default, the server template is generated such that it enables the RPC specific user events. This can be seen by looking at the generated Bind RPC ... .vi for the server. It should look something like below (I've deleted some data in the string constants and labels that are service specific).

This generated VI calls Create and Register Server Event.vim which is part of the grpc library installed to vilib and is also on the palette. This VI is in turn called by the generated Register gPRC Methods.vi. If you want to instead use a generic event, you will need to modify Register gRPC Methods.vi and replace the call to Create and Register Server Event.vim with Create and Register Generic Method Server Event.vi (also on the grpc functions palette). However, the user event for this VI has a different signature than the one that is generated for the server class. That means you will have to modify the server class to include this event type instead or do something else to "plumb" the data along so that it is accessible from Start Sync.vi or Start Async.vi. I guess you could inject another event loop that does nothing but convert from Method Name and Method gRPCid in one event type to the Command and Data used by the other event type. However, I'm not really sure what that buys you.

All of these comments are made from code inspection. I haven't actually tested any of this. I suspect you can probably get this to work by applying what I described above. However, my take from looking at the code is that this was never a fully fleshed out feature. This, Start Sync.vi, and Start Async.vi all seem like variations of the same theme at least in terms of handlers/dispatchers and parallelism. Long term, I think the generator should generate more of this dispatcher code for you and do a better job of separating generated code from user logic so the server can be updated based on latest proto file changes without overwriting user code.