xml.rpc
| Syntax |
xml.rpc (rpcServer, rpcPort, procedureName, adrParamList, flDebug, ticksToTimeOut, flShowMessages, rpcPath, flAsynch, adrCallback, extraInfo, adrErrorCallback, protocol, soapAction)
|
| Params |
Parameters are the same as betty.rpc.client, with two additions (both are optional). protocol is a string, either "xml-rpc" or "soap" (case-sensitive), indicating which protocol to use. Defaults to "xml-rpc". soapAction is a string, it provides the value for the SOAPAction header, to allow routing of the message on the server. Defaults to the empty string.
|
| Action |
Sends a remote procedure call to the indicated server with the indicated parameters using the indicated protocol, and passes the response back to the caller.
|
| Returns |
The value returned by the handler on the server machine.
|
| Examples |
local (params = {12}); xml.rpc ("localhost", 81, "examples.getStateName", @params) » "Idaho"
local (params = {12}); xml.rpc ("localhost", 81, "getStateName", @params, protocol:"soap", soapAction:"/examples")
|
| Notes |
It has the same parameter list as betty.rpc.client, by design, you can simply replace calls to betty.rpc.client with calls to xml.rpc. There are two new optional parameters, protocol and soapAction. If protocol is "soap" we call soap.rpc.client, which has other optional params, but I'm not sure it's necessary to expose them through this interface. soap.rpc.client isn't going away. There's a little strangeness when it comes to procedure names. SOAP procedure names can't have dots or any other special characters because on the wire they are XML elements. So we strip off everything to the left of the last dot in the procedure name. Also it should be said somewhere that, while we still have support for agent-based asynchronous xml-rpc, it's probably a better idea to use thread.callScript to do an asynch call. The asynch implementation was done before we had thread.callScript.
|
| See Also |
betty.rpc.client
|
