Legrand / Raritan Xerus™ JSON-RPC API for Remote Access Devices like KX4-101, KX3G2

Loading...
Searching...
No Matches
Java JSON-RPC Client Binding

# Examples

# IDL-to-Java Mapping

## Modules and Java Packages

The classes implementing Xerus™ JSON-RPC communication are contained in two separate Java package hierarchy: The namespace `com.raritan.xeruskvm.idl` contains Java interface declarations for all IDL interfaces, and Java equivalents for named IDL data types like structures or enumerations. The `com.raritan.xeruskvm.json_rpc` namespace contains proxy classes that implement those interfaces and relay any method calls to a remote device using JSON-RPC.

## Interfaces and Methods

IDL interfaces are mapped to Java interfaces and implemented by proxy classes. Each method defined in IDL maps to three overloaded methods in the corresponding Java interface:

public class CreateAccountResult {
public int _ret_;
}
// Version 1: synchronous method call
CreateAccountResult createAccount(String username, String password) throws Exception;
// Version 2: asynchronous method call
AsyncRequest createAccount(String username, String password,
AsyncRpcResponse<CreateAccountResult> rsp);
// Version 3: asynchronous method call with custom options
AsyncRequest createAccount(String username, String password,
AsyncRpcResponse<CreateAccountResult> rsp,
RpcCtrl rpcCtrl);

1. A synchronous variant which takes the same arguments as the IDL method declaration. This method will block the calling thread until the JSON-RPC communication is finished and the result is available. If the method has a return value or out-parameters those will be included in the result object returned by the method.
   This version of the method is the only one that may throw a Java exception in case of communication problems or an error response from the server.
2. An asynchronous variant. This version of the method returns immediately without performing any network communication. Instead, the request is processed by a background thread. When it is finished, a method of the passed `rsp` response object is called: `onSuccess` in case the JSON-RPC call was successful, or `onFailure` when there was an error.
3. An asynchronous variant with custom options. By default, the background thread can combine multiple method calls into a single HTTP request. If that's not desired it can be suppressed by setting an option in the passed `rpcCtrl` object.

## Structures

IDL structures are mapped to Java classes with public members for each structure element. Those classes feature a default constructor and implement the `Cloneable` interface.

## Enumerations, Vectors and Maps

IDL enumerations are mapped to plain Java enums. Vectors are mapped to java.util.List, and maps are mapped to java.util.Map.

## Exceptions

Exceptional error conditions may occur because of communication problems or because of system errors that occur on the server while processing a request. Those "unexpected" error conditions are not a part of the regular IDL signature, so they are handled by using one of the following exceptions:

- `com.raritan.xeruskvm.json_rpc.RpcRequestException`

  This exception is raised in case of a communication failure. Typical examples for this include an unreachable server, an authentication problem or a wrong resource ID.

- `com.raritan.xeruskvm.json_rpc.RpcErrorException`

  This exception is raised in case the server responded with a JSON-RPC error object instead of the expected method result. This can indicate either an internal problem in the server or a malformed request from the client.

- `com.raritan.xeruskvm.json_rpc.RpcFormatException`

  This exception is raised in case the JSON-RPC response from the server cannot be decoded. This may indicate an interface version mismatch between client and server.

For synchronous method invocations the exceptions are thrown and can be intercepted with a try/catch block. For asynchronous method invocations the exception object is passed to the `onFailure` method of the result object.

# Interface Versions

The Java bindings contain interfaces and proxies for all IDL interface versions that have been released up to the firmware release the bindings were generated for. Using those classes client programs can be written to be compatible with any firmware version up until the most recent release.

IDL interface names like `serial.SerialPort_3_0_1` contain three separate version numbers:

1. A major version. This number is incremented when the interface has changed in an incompatible way. A client program that is written to support `SerialPort_3_*` may or may not work with a device that implements a `SerialPort_4_*` interface.
2. The middle number is the sub-major version. This number is incremented in case a referenced interface is changed in an incompatible way. A client can safely ignore the middle version number as long as it uses only methods of the interface itself. However, it should verify the type and version of any objects returned from an interface with a different sub-major number before using them.
3. The last number, the minor version, is incremented on backward- compatible interface changes, e.g. when a new method was introduced. A client that was written to support the `SerialPort_3_0_1` interface is guaranteed to work with `SerialPort_3_0_2` or later without modification. Object references returned from an interface with compatible changes can be safely used without additional compatibility checks.

# Bulk Requests

The Bulk RPC interface allows combining multiple JSON-RPC method calls into a single bulk request that can be sent to the server and processed in a single HTTP request. When using the asynchronous API the Java client library automatically adds all submitted requests into a bulk request queue. A background thread combines pending requests into a bulk request and sends it to the device. As a result, submitted requests can be delayed by up to 250 Milliseconds while the bulk RPC thread waits for more requests to be queued.

To bypass the bulk request queue, add an `rpcCtrl` parameter to the asynchronous method call. The following call will be immediately sent to the device as a dedicated JSON-RPC request:

Net_8_0_0 net = new Net_8_0_0_Proxy(agent, "/net");
net.getSettings(new AsyncRpcResponse<Net_8_0_0.GetSettingsResult>() {
public void onSuccess(Net_8_0_0.GetSettingsResult result) {
...
}
public void onFailure(Exception e) {
...
}
}, new RpcCtrl(RpcCtrl.Bulk.FORBID));
net
Network Configuration.
Definition Diagnostics.idl:9

# `com.raritan.xeruskvm.json_rpc.Agent` Method Reference

## Constructor: Agent(url)

Creates a new agent.

Parameters:

- url Base URL of the device (e.g. "https://my-xerus.example.com")

It is necessary to call setUsername()/setPassword() or setToken() before the first request.

## setUsername(user)

This method sets the username for HTTP basic authentication.

Parameters:

- user User Name

## setPassword(password)

This method sets the password for HTTP basic authentication.

Parameters:

- password Password

## setToken(token)

This method enables and disables HTTP authentication using a session token. A session token can be obtained by calling the newSession method of the session.SessionManager interface.

Calling setToken(token) with a string variable which contains the token will enable token-based authentication.

When calling setToken(null), token-based authentication is disabled.

Parameters:

- token Session Token (null or string with session token)