You are here: Foswiki>Service Web>MockDevicesForTesting (15 Feb 2017, VitaliyRapp)Edit Attach

Introduction

Sometimes a situation requires a mock-up device, which may be configured at run-time to deliver a specific desired value. As instance in case of unit testing one can configure such mock-up prior the test, and then run expecting a defined behavior from the used device. Another use case of such mock up could be system test, where you can configure multiple devices to deliver a specific subscription update. One can even model a significant amount of devices to perform smaller performance tests of the system.

Such devices may be mocked using the Rda3TestDataServer. The service group provides some ready-to-use services related to such mock-up devices at the asl74x cluster. The usage of those services is described in this section.

Infrastructure

Directory Server for Testing

In order not to interfere with the production or integrational testing environment an additional instance of the Directory Server is launched. This new DS instance is accessible from the asl cluster. It is configured to work with the AccDbU database (development). Note that currently the U database does not contain information about the majority of the "normal" devices and hence they would not be available, using this DS. A client will also be able to communication only with mock-up devices. Since the Directory Service a part of the RDA infrastructure you will also need to provide it in case you what to communicate using directly the RDA library.

The Directory Server is accessible under following address:
vmla001.acc.gsi.de:5050

Rda3DataServer

Rda3DataServer is an implementation of the Rda3 server developed to perform different kind of (mainly communication) tests involving devices. The core idea behind is to provide an echo like service, where one can set a particular property of a device and then collect the same value using the get or subscription request. The Rda3DataServer itself stores different statistics like how many a times a particular notification request was set for a given device. Those statistics help to identify possible communication or other problems of the client.

The Rda3DataServer will accept any set request for any device and any property. If the device/property exists, that the value will be overridden, if not then the device/property will be created. Any get or subscribe request on device or properties which are not exist will end up in an error. Additionally it possible configure the Rda3DataServer to return an exception for a given device property.

At the moment the server is launched at vmla002 VM-host. The servers name is (how it is known by the DS):
Rda3TestDataServer.vmla02

Device Pool

In the common use scenario of RDA (or JAPC) the user does not need or provide the server on which a particular device is running explicitly. This information is available by the DirectoryServer who does the resolution between devicename and servername. However the information about, which device is running on which server is available only statically in the database and is not a subject of change at run time, at least not automatically by any of services. To use the RDA (or JAPC) in the usual way the information about devices should also be known in advance and needs be written into the DirectoryServer 's Database.

Currently we do have 9 devices registered in the Database (U) connected to the server. Names are: XXXDEV01 ... XXXDEV09

Usage (common use case)

The usage is demonstrated by a typical use case: setup a device, get the value, and subscribe for the value. Java interface as well as RDA CLI Interface is demonstrated.

Prequisites (setup right DirectoryServer)

RBAC CLI

For RBAC CLI tools you need to set the right environment variable in the session you use the CLI tools:
$ export CMW_DIRECTORY_CLIENT_SERVERLIST=vmla001.acc.gsi.de:5050

JAPC

For JAPC you will need to adjust the VM argument accordingly:
-Dcmw.directory.client.serverList=vmla001.acc.gsi.de:5050

Configure device (set value)

We use the device XXXDEV01 from the pool and the property TestProp. It is set using following value (fields), without the selector:
Name : current
Type : int32
Value: 10

Name : state
Type : string
Value: OK

RBAC CLI
$ ./Rda3SetClient XXXDEV01/TestProp -v OK,10 -f state,current -t string,int32
JAPC
ParameterFactory pfac = ParameterFactory.newInstance();
Parameter p = pfac.newParameter("XXXDEV01/TestProp");

Selector nullSelector = SelectorFactory.newSelector(null);

Map<String, SimpleParameterValue> valuemap = new HashMap<String, SimpleParameterValue>();
valuemap.put("current", SimpleParameterValueFactory.newValue((int)10));
valuemap.put("state", SimpleParameterValueFactory.newValue("OK"));

p.setValue(nullSelector, MapParameterValueFactory.newValue(valuemap));

Get and Subscribe for the value

RBAC CLI

Get:
$ ./Rda3GetClient XXXDEV01/TestProp

Subscribe (in this case end after 10 update):
$ ./Rda3SubscribeClient XXXDEV01/Status -n 10
JAPC

Common code:

ParameterFactory pfac = ParameterFactory.newInstance();
Parameter p = pfac.newParameter("XXXDEV01/TestProp");

Selector nullSelector = SelectorFactory.newSelector(null);

...

Get:
...
AcquiredParameterValue value = p.getValue(nullSelector);
System.out.println(value);

Subscribe:
...
try {
 
 SubscriptionHandle handle = 
 par.createSubscription(nullSelector, new ParameterValueListener() {
 
    @Override
    public void valueReceived(String parameterName, AcquiredParameterValue value) {
         System.out.println(value);
    }
    @Override
    public void exceptionOccured(String parameterName, String description, ParameterException exception) {
         System.out.println("Exception occured for parameter " + parameterName);
         exception.printStackTrace();
    }
 });

 handle.startMonitoring();
 // Wait and to other stuff in the meanwhile
 handle.stopMonitoring(); 

} catch (ParameterException e) {
   // Do some exception handling here
}

Additional configuration

Some additional configuration is described in the attachment. Note that it requires the usage of the RDA library directly, or the RDA CLI tools.

Limitations

The time between the notifications of the subscription is a fixed option at the TestServer level (1000 ms in the current deployment) and may be set only during the TestServer launch. Hower it is possible to launch additional Rda3TestServers with different notification time intervalls.
Topic revision: r1 - 15 Feb 2017, VitaliyRapp
This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Foswiki? Send feedback