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

Loading...
Searching...
No Matches
C# / .NET JSON-RPC Client Binding

# Examples

# IDL-to-.NET Mapping

## Modules and .NET Namespaces

The classes implementing Xerus™ JSON-RPC communication are contained in two separate .NET namespaces: The namespace `Com.Raritan.XerusKvm.Idl` contains .NET classes for all IDL interfaces, and .NET equivalents for named IDL data types like structures or enumerations. The `Com.Raritan.XerusKvm.JsonRpc` namespace contains utility classes for performing the JSON-RPC.

## Interfaces and Methods

IDL interfaces are mapped to .NET classes. Each method defined in IDL maps to three overloaded methods in the corresponding .NET class:

public class CreateAccountResult {
public int _ret_;
}
// Version 1: synchronous method call
public CreateAccountResult createAccount(string username, string password) {
[...]
}
// Version 2: asynchronous method call
public AsyncRequest createAccount(string username, string password,
AsyncRpcResponse<CreateAccountResult>.SuccessHandler rsp,
AsyncRpcResponse.FailureHandler fail) {
[...]
}
// Version 3: asynchronous method call with custom options
public AsyncRequest createAccount(string username, string password,
AsyncRpcResponse<CreateAccountResult>.SuccessHandler rsp,
AsyncRpcResponse.FailureHandler fail,
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 .NET 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 the JSON-RPC call is finished successfully, the passed `rsp` method callback is called. If there was an error, the `fail` method callback is called.
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 .NET classes with public members for each structure element. Those classes feature a default constructor and implement the `ICloneable` interface.

## Enumerations, Vectors and Maps

IDL enumerations are mapped to plain .NET enums. Vectors are mapped to System.Collections.Generic.IEnumerable, and maps are mapped to System.Collections.Generic.IDictionary.

## 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.JsonRpc.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.JsonRpc.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.JsonRpc.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 `fail` method callback.

# Interface Versions

The .NET bindings contain classes 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 .NET 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(agent, "/net");
net.getSettings(result => {
[...]
},
ex => {
[...]
},
new RpcCtrl(RpcCtrl.BulkType.FORBID));
net
Network Configuration.
Definition Diagnostics.idl:9

# Com.Raritan.JsonRpc.Agent Method and Property 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 set the Username/Password or the Token property before the first request.

## Username

This property sets or returns the username for HTTP basic authentication.

## Password

This property sets or returns the password for HTTP basic authentication.

## Token

When this property is set, it enables and disables HTTP authentication using a session token. A session token can be obtained by calling the newSession method of the session.SessionManager class.

Setting Token with a string variable which contains the token will enable token-based authentication.

When setting Token to null, token-based authentication is disabled.