rpcbroker

Index Home MAE > MAE Architecture > MAE Daemons > rpcbroker

RpcBroker Daemon

This daemon manages the registration, calling, and response of remote procedure calls (synchronous messaging) where one application calls a service identified by a unique identifier with parameters and then the servicing daemon sends a response back with data.

RpcBroker maintains a list of all registered services.  When an application make a service request, RpcBroker determines where to route the request.  And after the request is processed, RpcBroker routes the response back to the caller.

Use the trpc utility to send requests from the command line.

Daemon Parameters

None.

Programming API to RpcBroker

Although you can directly use the RemoteService class to write code to send and receive requests, it is best practice to have genmae create that code. You create a .mreg file that specifies what requests your program receives and what API calls other programs can make to send requests to your program; genmae will write the code for you.

For example, if your app uses the xyz channel, then you create xyz.mreg and then use genmae to create the logic to handle inbound requests using

genmae xyz.mreg -msg msgXyz.cpp

and then create the API interface using

genmae xyz.mreg -apih -apicpp

to create XyzAPI.h and XyzAPI.cpp.

Receiving a Request Example

There's plenty of detail in the genmae documentation, but here is an example of receiving a request:

#rpc "item.fetch" ItemApp::rpcFetch(string service, XMLData & params, string appname, string user= "", void * data= NULL);

where fpcFetch() is a static method in the ItemApp class. Any parameters sent through an API become properties of params, which rpcFetch() can extract. If you can encounter an error that prevents processing, call RemoteService::setError() to communicate that error back.

Sending a Request Example

For another program to call the above example's service called item.fetch, that program would use:

RemoteService::call("item.fetch", params);

Your program can create an API interface to make it easier for the calling program. Here's the code to go into xyz.mreg to define the API and then how to process the request:

#api XMLData ls(const string & maepath)

/** Given a MAE directory path, return a list of all files under it.

 * A filename with a trailing / is a directory.

 * @param maepath - the MAE directory path

 * @return Resulting data from the call.  Use RemoteService::getError(result) to get any error; if no error, then call worked.

 */

#param path=maepath

#rpc "vfs.ls" IoApp::rpcLs(string service, XMLData & params, string appname, string user= "", void * data= NULL)

which creates XyzAPI::ls() for the other program to use to call the cmd.ls request. Your program then needs to define the static method IoApp::rpcLs().

Database Tables

rpcbroker uses these database tables:

Messages Sent/Received

RpcReq

This message flows from the client to RpcBroker and then from RpcBroker to the service provider.

rpcbroker adds these properties to the XML parameter list sent to a service daemon.

RpcResp

This message flows from the service provider to RpcBroker.

The service app automatically adds these properties into its response.

RpcOK

This message flows from RpcBroker to the client app.

rpcbroker adds these properties to the XML reply list sent to the calling app.

RpcError

This message flows from RpcBroker to the client app.

No XML data is returned, just the error message.  rpcbroker produces two of the error messages:

RPC Timeout - the service providing app did not complete the request within the timeout period, so the request expired

RPC Service Termination (interrupted) - when RpcBroker terminates, it sends this message to all clients with outstanding requests