Raritan PX2/PX3 JSON-RPC API
C# / .NET JSON-RPC Client Binding

Examples

Getting device information:

using System;
using Com.Raritan.JsonRpc;
using Com.Raritan.Idl;
using Com.Raritan.Idl.pdumodel;
namespace Examples {
class Program {
static void Main(string[] args) {
// create a JSON RPC agent, using a PX2 device URL
using (Agent agent = new Agent("https://my-px.raritan.com")) {
// set username and password
agent.Username = "agent";
agent.Password = "password";
// disable TLS certificate check if default certificate is used
// agent.ServerCertificateValidationCallback = Agent.UnsecureTrustAllCertificatesCallback;
// query the firmware revision using JSON RPC
Pdu_4_0_0 pdu = new Pdu_4_0_0(agent, "/model/pdu/0");
Pdu_4_0_0.MetaData metadata = pdu.getMetaData()._ret_;
Console.WriteLine("Firmware version: " + metadata.fwRevision);
}
}
}
}

Power-cycling an outlet:

using System.Collections.Generic;
using System.Linq;
using Com.Raritan.Idl;
using Com.Raritan.Idl.pdumodel;
using Com.Raritan.JsonRpc;
[...]
using (Agent agent = new Agent("https://my-px.raritan.com")) {
agent.Username = "agent";
agent.Password = "password";
Pdu_4_0_0 pdu = new Pdu_4_0_0(agent, "/model/pdu/0");
IEnumerable<Outlet_2_0_0> outlets = pdu.getOutlets()._ret_;
outlets.FirstOrDefault().cyclePowerState();
}

IDL-to-.NET Mapping

Modules and .NET Namespaces

The classes implementing Raritan JSON-RPC communication are contained in two separate .NET namespaces: The namespace Com.Raritan.Idl contains .NET classes for all IDL interfaces, and .NET equivalents for named IDL data types like structures or enumerations. The Com.Raritan.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:

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 pdumodel.Pdu_3_1_0 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 Pdu_2_* may or may not work with a device that implements the Pdu_3_* 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 Pdu_3_1_0 interface is guaranteed to work with Pdu_3_1_1 or later without modification. Object references returned from an interface with compatible changes can be safely used without additional compatibility checks.

See the DumpPdu.cs program distributed with this documentation for an example how to write a client program that supports multiple interface versions.

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_4_0_0 net = new Net_4_0_0(agent, "/net");
net.getSettings(result => {
[...]
},
ex => {
[...]
},
new RpcCtrl(RpcCtrl.BulkType.FORBID));

Com.Raritan.JsonRpc.Agent Method and Property Reference

Constructor: Agent(url)

Creates a new agent.

Parameters:

It is necessary to set the Username/Password or the Token propertybefore the first request.

Username

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

Username

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.