This section aims to provide Rule Engine tasks and rules examples.

  • Example 1. Task - Install Bundle on All Connected OSGi Devices

  • Example 2. Rule – Persistent Install Bundle on All OSGi Devices

  • Example 3. Groovy Action – Add Remote Application Management Functionality on the Device and Install a Service Application

  • Example 4. Rule – Duplicating System Log Entries Into a File

  • Example 5. Rule – Monitoring the Alert Board

  • Example 6. Rule – Clone Proper Configuration


Rules can be imported directly to the RM User Interface. Download the Rule examples presented below here (Examples 2,4,5,6 as ZIP).

Example 1. Task – Install Bundle on All Connected OSGi Devices


Task Scope: DeviceScope with device type = "mprm.osgi.device", device group id = "ROOT/"Task Action:target.installBundle('mprm://contentId=mprm.osgidm.osop', false, true, null);


Refer to "OSGIDevice" from the API for the methods available of OSGi Device objects bound as "target" in the context of DeviceScope Tasks with device type "mprm.osgi.device".



Once launched, the Task will be executed on all OSGi Devices that are currently online and available to execute the action. On all offline devices, the Task will remain in device exec state- RUNNING_NOT_READY_TO_EXECUTE (refer to the "Execution Results" section from the Task Executions user guide).

Example 2. Rule – Persistent Install Bundle on All OSGi Devices

To install bundle on all OSGi Devices, you need 1) to launch the installation on all connected devices at once and 2) to launch it on the offline devices automatically once they connect to the backend. This could be achieved via Rule that combines manual and event-based triggers. The manual trigger will launch a Task (the same as the one defined in the previous example) that will finish on all currently connected devices, while the event-based trigger will launch a separate Task for each device connecting from now on to the backend. To not trigger bundle installation twice on the same device, we will use Rule Execution Option: once per device = true. In addition to find out when the Rule is completed on all available devices in the desired scope, we will also add the Rule Execution Option: disable-automatically = true (refer to the "Rule Execution Options" section from Rule-Based Automation).

The Rule in exported JSON format would look as follows:

{
  "name": "Install Bundle",
  "scope": {
    "deviceType": "mprm.osgi.device",
    "deviceGroupId": "ROOT",
    "deviceFilter": "",
    "isMemberCheckScript": "",
    "targetsListScript": "",
    "scopeType": "rule.device.scope"
  },
  "trigger": {
    "triggerElements": [
      {
        "triggerEvent": {
          "triggerMode": "rule.manual.trigger"
        },
        "triggerCondition": "",
        "sync": false
      },
      {
        "triggerEvent": {
          "triggerMode": "rule.funct.event.trigger",
          "eventType": "DeviceOnline"
        },
        "triggerCondition": "",
        "sync": true
      }
    ],
    "generalCondition": ""
  },
  "options": {
    "concurrency": -1,
    "timeConstraint": null,
    "overlapping": "NO_OVERLAPPING_CANCEL_OLD",
    "oncePerDevice": true,
    "autoDisable": true
  },
  "action": "target.installBundle('mprm://contentId=mprm.osgidm.osop', false, true, null);\n"
}


Example 3. Groovy Action – Add Remote Application Management Functionality on the Device and Install a Service Application

This example illustrates how to install a bundle providing new remote management functionality (apps management) on the OSGi Device(s) and to start using it directly – by installing the first service application. The critical moment here is that installing of service application should start after the asynchronous bundle installation is finished. We will use Closures to handle this use case.

Task Action:

Closure installServiceApp = {target.installServiceApplication('<my-app-id>', false)};
String appMgmtBundles = 'mprm://contentId=mprm.service.cu_interface' +
    ', mprm://contentId=mprm.service.osgi_bundle_component_plugin' +
    ', mprm://contentId=mprm.service.application_net_adapter' +
    ', mprm://contentId=mprm.service.application_management_agent' +
    ', mprm://contentId=mprm.osgidm.control_unit_agent';
 
target.installBundle(appMgmtBundles, false, true, null, installServiceApp);

Applications Management functionality is leveraged by a number of bundles, all provided as a url-list within a single installBundle method (just the installBundle method supports it). The code defined by the Closure installServiceApp will be run after the asynchronous execution of the installBundle method is finished.

The Groovy code could be run as Task and/or Rule analogically to examples 1 and 2.

Example 4. Rule – Duplicating System Log Entries Into a File

This example illustrates a Rule that writes into a file all newly added logs which contain some marker: "Logging in OSGi device" in this case.

{
  "name": "Log Event Demo",
  "scope": {
    "singleHostPerRole": false,
    "beHostRoles": [],
    "scopeType": "rule.system.scope"
  },
  "trigger": {
    "triggerElements": [
      {
        "triggerEvent": {
          "triggerMode": "rule.funct.event.trigger",
          "eventType": "mprm.log.event"
        },
        "triggerCondition": "event.message == \"Loging in OSGi device.\"",
        "sync": false
      }
    ],
    "generalCondition": ""
  },
  "options": {
    "concurrency": -1,
    "timeConstraint": null,
    "overlapping": "NO_OVERLAPPING_CANCEL_OLD",
    "oncePerDevice": false,
    "autoDisable": false
  },
  "action": "File file = new File(\"rule-filtered-logs.txt\")\r\nfile << event.message + ': ' + event.deviceId + '\\n'"
}


Example 5. Rule – Monitoring the Alert Board

This example illustrates a Rule that automatically adds error-log when an Alert having message "UserAdmin is unavailable!" is raised in RM.

{
  "name": "Alert Event Demo",
  "scope": {
    "singleHostPerRole": false,
    "beHostRoles": [],
    "scopeType": "rule.system.scope"
  },
  "trigger": {
    "triggerElements": [
      {
        "triggerEvent": {
          "triggerMode": "rule.funct.event.trigger",
          "eventType": "mprm.alert.event"
        },
        "triggerCondition": "event.type == Alert.RAISED && event.alert.message == \"UserAdmin is unavailable!\"",
        "sync": false
      }
    ],
    "generalCondition": ""
  },
  "options": {
    "concurrency": -1,
    "timeConstraint": null,
    "overlapping": "NO_OVERLAPPING_CANCEL_OLD",
    "oncePerDevice": false,
    "autoDisable": false
  },
  "action": "logService.error(event.alert.message)"
}

Example 6. Rule – Clone Proper Configuration

This example illustrates how configuration(s) from a properly running OSGi Device could be exported and applied to all other devices. The following Rule is triggered on each device connect. The script reads the configuration from a 'etalon' device – with id "215166345214" - and sets it on the 'target' device for which the Rule is triggered.

{
  "name": "Clone proper configuration",
  "scope": {
    "deviceType": "mprm.osgi.device",
    "deviceGroupId": "ROOT/",
    "deviceFilter": "",
    "isMemberCheckScript": "",
    "targetsListScript": "",
    "scopeType": "rule.device.scope"
  },
  "trigger": {
    "triggerElements": [
      {
        "triggerEvent": {
          "triggerMode": "rule.funct.event.trigger",
          "eventType": "DeviceOnline"
        },
        "triggerCondition": "target.getId() != \"122\"",
        "sync": false
      }
    ],
    "generalCondition": ""
  },
  "options": {
    "concurrency": -1,
    "timeConstraint": null,
    "overlapping": "NO_OVERLAPPING_CANCEL_OLD",
    "oncePerDevice": false,
    "autoDisable": false
  },
  "action": "String etalonDeviceID = \"122\"; // we will always get the proper configuration from this device\r\nfinal
 
 
  CONFIGURATION_PID = \"mbs.http.pid\"; // just for instance, pretending we are interested in this exact configuration\r\n\r\npublic
  Dictionary getConfigurationProperties(OSGiDevice device, String configurationID);\r\n  
  Configuration configuration = device.getConfiguration(configurationID)
{\r\n return configuration.configurationProperties;\r\n}\r\n\r\npublic
  void changeDeviceConfiguration(OSGiDevice device, String configurationID, Dictionary properties)
{\r\n Configuration configuration = device.getConfiguration(configurationID);\r\n  
  configuration.changeConfiguration(properties); //can use also replaceConfiguration method\r\n}\r\n\r\n\r\n
 
  // starting the work:\r\n
  // 1. get the etalon device which should have the proper configuration\r\nOSGiDevice
  etalonDevice = dm.getOSGiDevice(etalonDeviceID);\r\n
  // 2. get its (etalon) configuration\r\nDictionary
  configProperties = getConfigurationProperties(etalonDevice, CONFIGURATION_PID);\r\n  
  // 3. apply the etalon configuration to the currently processing device - \"target\"\r\n
  changeDeviceConfiguration(target, CONFIGURATION_PID, configProperties);\r\n\r\n
}


Since the Rule Action is not conveniently readable in JSON format unless imported in UI, here is a better formatted one. Rule Action:

String etalonDeviceID = "122"; // we will always get the proper configuration from this device
final CONFIGURATION_PID = "mbs.http.pid"; // just for instance, pretending we are interested in this exact configuration
 
public Dictionary getConfigurationProperties(OSGiDevice device, String configurationID) {
  Configuration configuration = device.getConfiguration(configurationID);
  return configuration.configurationProperties;
}
 
public void changeDeviceConfiguration(OSGiDevice device, String configurationID, Dictionary properties) {
  Configuration configuration = device.getConfiguration(configurationID);
  configuration.changeConfiguration(properties); //can use also replaceConfiguration method
}
 
// starting the work:
// 1. get the etalon device which should have the proper configuration
OSGiDevice etalonDevice = dm.getOSGiDevice(etalonDeviceID);
// 2. get its (etalon) configuration
Dictionary configProperties = getConfigurationProperties(etalonDevice, CONFIGURATION_PID);
// 3. apply the etalon configuration to the currently processing device - "target"
changeDeviceConfiguration(target, CONFIGURATION_PID, configProperties);