I'm working on a module that will contain a variety of scripting functions. Because I don't want every function defined in one class, I've created 3 (for now), and am having issues "combining" them.
In the sdk-examples scripting-function example, there is only one class of functions, which can be easily returned in the getRPCHandler method.
In my case, I'm having 3 separate module classes.
My issue is that ultimately, getRPCHandler is only returning one object. What is the best way to "combine" these 3 module classes together, into one object to be returned? Or is an entirely different approach required at this point?
Are you actually using RPC from Vision clients or the Designer?
While the example conflates and RPC handler with a class for scripting functions, that is a very simplistic combination, and only meaningful if you do not ever need to push messages back to specific Vision/Designer clients.
What RPC functionality do you really need? Do your scripting classes really need to be instantiated? (Can you not use static functions and just pass the class itself to register?)
This was asked/answered here as well.
Basically, you get one RPC handler, but that doesn't have to be the same object as your script modules, so multiplex it out however you want.
Also for your consideration: for years now we (IA) no longer add new scripting functions to Designer / Vision Client scope and relay them over RPC. We only add new scripting functions to Gateway scope.
I do not need to target specific clients. The designer, I'm just sticking as closely to the scripting function example as possible. Any coding choice I make is basically a result of that. I'm open to any suggestions.
Do this. Three (or however many) classes of static functions. Private constructor (not used). Register those directly.
Omit getRPCHandler if you don't need it.
1 Like
I've had this in place already, is this what you mean?
By omitting getRPCHandler, I assume you mean simply deleting the implementation of it. Which then I get this error, when attempting to run one of the module functions in the Designer script console:
Let's step back. What are your script modules actually doing? Do they actually need any RPC, at all?
The public SDK example leads you down that path, but you don't need to use it if you can run your logic locally/self contained.
They are just running SQL queries against our gateway DB's. I also plan on having the functions check the module's LicenseState to determine how they execute. I don't know if they need RPC, could you tell me a bit more about that? What kind of situations require an RPC?
Well, one alternative would be to have your designer/client scoped classes rely on the existing facilities in the platform for sending SQL queries from the client. Probably not worth it, though; this is a pretty classic case for RPC.
Basically - the designer and client don't have all of the same facilities as the gateway - one of the obvious things is that the designer is not actually connecting to your database(s). Instead, the designer just has to talk to the gateway, and the gateway talks to the database. This is more efficient on your database, eliminates the security risk of having every designer/client get DB credentials, etc. So the RPC mechanism built into the platform for use from clients/designers is all about "expose a limited subset of the functionality a module on the gateway has to clients/designers".
1 Like
Okay, so it seems like in this case, I do actually need the RPC then. So back to the original problem, what's the best way to "compile" all script modules together to return, in the getRPCHandler method?
