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 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.
importjava.util.Hashtable;importcom.prosyst.mprm.admin.devices.DeviceManager;importcom.prosyst.mprm.rac.RemoteAccessClient;. . .privatestaticRemoteAccessClient rac;privatestaticHashtable credentials;privatestaticString userName ="system";privatestaticString URI ="socket://localhost:11449";privatestaticDeviceManager deviceManager;. . .//Obtaining a connected RAC instancecredentials =newHashtable();credentials.put(RemoteAccessClient.USER_PASSWORD,"system");rac = RemoteAccessClient.connect(URI, userName, credentials,null);// Getting the DeviceManagerdeviceManager = (DeviceManager) rac.getService(DeviceManager.class.getName());. . .//Do some work with the obtained Device ManagerIn 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.RemoteCUAdminreference or anorg.mbs.services.cup.ControlUnitProxyreference 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.