The RM Generic Device Manager API allows developers to access and manage devices and their components as control units from applications remote to the RM backend or from custom backend bundles.

Overview

The RM Generic Device Manager API allows developers to access and manage devices and their components as control units from applications remote to the RM backend or from custom backend bundles.

The common principles and concepts of RM device management are described in Conceptual Guide.

The main component responsible for RM device management is the Generic Device Manager. On the one side the Generic Device Manager communicates with frontend applications requesting to access device information and on the other side - with Control Unit Providers providing management functionality over specific device types by means of device root and component control units. See the "Control Units and Device Representation" document for detailed description of RM's device management model.

In addition, the Device Manager provides means for manipulating the structure of the device management tree.

RM offers a special API for device management - the Device Manager API, represented by the com.prosyst.mprm.admin.devices and com.prosyst.mprm.admin.devices.event packages. The Device Manager API provides bundles residing in a RAS or in the CC or remote applications running a RAC with access to the devices and the resources available on them. The API's main interface is DeviceManager, which represents the Generic Device Manager functionality.

Getting the Device Manager

There are two ways to get a DeviceManager instance:

  • If you are developing a custom bundle for the RM backend, get the Device Manager as an OSGi service from the framework.

Getting the Device Manager as an OSGi service on a RAS framework or on the CC framework:

import com.prosyst.mprm.admin.devices.DeviceManager;
import org.osgi.framework.BundleContext;
import org.osgi.framework.ServiceReference;
 
. . .
private BundleContext bc;
private ServiceReference ref;
private DeviceManager deviceManager;
 
   . . .
   ref = bc.getServiceReference(DeviceManager.class.getName());
   if(ref != null) {
   deviceManager = (DeviceManager) bc.getService(ref);
   . . .//Do some work with the obtained Device Manager  
  }


  • If you are developing a remote-to-backend application, get the Device Manager via a Remote Access Client.

    import java.util.Hashtable;
    import com.prosyst.mprm.admin.devices.DeviceManager;
    import com.prosyst.mprm.rac.RemoteAccessClient;
     
               . . .
      private static RemoteAccessClient rac;            
      private static Hashtable credentials;
      private static String userName = "system";
      private static String URI = "socket://localhost:11449";
      private static DeviceManager deviceManager;          
             . . .
        //Obtaining a connected RAC instance
        credentials = new Hashtable();
        credentials.put(RemoteAccessClient.USER_PASSWORD, "system");
        rac = RemoteAccessClient.connect(URI, userName, credentials, null);            
        // Getting the DeviceManager    
        deviceManager = (DeviceManager) rac.getService(DeviceManager.class.getName());
            . . .    
        //Do some work with the obtained Device Manager  

    In this case, you need the lib/rac/system-rac.jar and lib/rac/gdm-rac.jar JAR files present in your classpath. See the Remote Access to RM guide for more information about using a remote access client.

For development purposes, you can also use the lib/api/gdm-api.jar JAR file, which contains the APIs of the RM Generic Device Management package.

Management Models

Having obtained a reference to the Device Manager, you have two options for accessing and commanding device root and component control units:

  • By using the system-scoped model – Control units are accessed from within the scope of the entire RM system. Component control units may belong to different device roots and can have different versions of their types in the system. Component control units can be considered unique only in the scope of the concrete device root control unit. The system-scoped model implies calling directly methods of the Device Manager.

    For more information on the system-wide usage model, refer to the System-Wide Device Management document.

  • By using the device-scoped model – Component control units are accessed and managed only within the scope of a specific device root control unit where their uniqueness is guaranteed.

    The device-scoped model implies getting an org.mbs.services.cup.radmin.RemoteCUAdmin reference or an org.mbs.services.cup.ControlUnitProxy reference for an individual device and using its methods for device component management.

    For more information on the device-scoped usage model, refer to the Component Management on a Single Device document.