From OpenTTCN DocZone

OpenTTCN DocZone   Home | Developer's corner | Knowledge base | Working documents | Documentation | Tutorials | Training | How do I | Frequently asked questions | Technical support

Article's permanent URL

Adapter and session properties

---

OpenTTCN supports two kinds of properties: adapter properties and session properties.

Adapter properties

Adapter properties facilitate configuration management and reporting. Adapter properties are used merely as a means to insert user-defined name-value pairs into conformance log. Setting an adapter property in the adapter code has no other effect except enabling its reporting in the conformance log.

Adapter property names are freeform and their semantics is not standardized.

Adapter property in the ANSI C SDK can be set through calling an interface function with the following signature (defined in isl/TTCN3.h, note the API documentation):

int otSetProperty(const char* name, const char* value);

For example, assume you have performed the following sequence of calls in your adapter initialization part:

otSetProperty("LLC version", "1.1.1");
otSetProperty("SAP bearer", "UH 2.5/E 2005");

Assuming you have registered this adapter to a session with the "TRI" role, your conformance log will contain the following line, typically closer to the beginning of the log:

Tester : {14:31:18.345} : // Time: 14:31:18.345. Date: 14/May/2008. MOT version: TC: 2.57.0.RC5.0; Adapter properties: TRI: LLC version=1.1.1;SAP bearer=UH 2.5/E 2005.

If there are multiple adapters attached to the same session, adapter properties will be reported for each of them individually in the same log line.

You can even develop a dedicated adapter acting exclusively as a property server. You can register such adapter to a session with some dummy unallocated role, for example with the "Property server" role. This means that such adapter will not be burdened with serving, say, TRI or TCI-CD requests. It will be used merely as a supply for adapter properties to be inserted into conformance log.

For example, if you have registered the example adapter with the above property set to a session using the following statement:

otRegisterAdapter("MySession", "Property server");

then your conformance log will contain a line that looks like this:

Tester : {14:46:35.321} : // Time: 14:46:35.321. Date: 14/May/2008. MOT version: TC: 2.57.0.RC5.0; Adapter properties: Property server: LLC version=1.1.1;SAP bearer=UH 2.5/E 2005.

Session properties

Session properties shall not be confused with adapter properties. Unlike adapter properties, session properties are not displayed in the conformance log, however they may affect test execution mode.

You can set a session property with the session command using the following syntax:

session set property SESSION PROP_NAME[=PROP_VALUE]

Here is an example of setting a session property:

session set property MySession TC_PRIORITY=HIGH

This assigns OS-specific priority level to all test component processes of OpenTTCN virtual machine that are started in the specified session.

You can delete a property from the session like this:

session set property MySession TC_PRIORITY

i.e. by calling the 'set property' command without specifying the property value.

You can retrieve the list of all session properties like this:

session status MySession

The Properties subsection will contain the full list of session properties defined in the MySession session.

The full list of supported session properties together with their meaning is presented in Table 1.

Table 1: Supported session properties

Property name	Allowed values	What it does	Availability	Since
STAT_CAPTURE	ON | OFF	Enables time-related statistics capturing to facilitate detection of performance bottlenecks, performance analysis, and test system instrumentation.	All platforms	2.55.0.RC7
TC_PRIORITY	HIGH | IDLE | NORMAL | REALTIME	Assigns OS-specific process priority level to all test component processes started by OpenTTCN virtual machine. This helps to better control system scheduling issues.	Windows	2.55.0.RC7.1
PRETEST_FUNCTION	[MODULE_ID.] FUNCTION_ID	Sets a callback function declared or defined in a TTCN-3 module that is invoked prior to executing the very first statement of a test case.	All platforms	2.55.0.RC7.3
POSTTEST_FUNCTION	[MODULE_ID.] FUNCTION_ID	Sets a callback function declared or defined in a TTCN-3 module that is invoked after executing the very last statement of a test case.	All platforms	2.55.0.RC7.3

STAT_CAPTURE

The STAT_CAPTURE property enables timestamp generation facility in test components and SUT adapters. This facility can also be referred to as "performance statistics capturing facility". Timestamps are generated in the following locations:

• beginning and end of a TTCN-3 statement;
• beginning and end of one of the following user-implemented callback functions: triSend(), triExternalFunction(), triCall(), triReply(), triRaise(), tciEncode(), and tciDecode(), including checkpoints when (a) call is initiated by the remote side, (b) callback is received by the recipient, (c) callback processing by the recipient is complete, and (d) call completion notification is received by the remote call initiator;
• beginning and end of a user call to TRI API function triEnqueueMsg();
• beginning and end of enqueue operation in the test component (beginning and end of a callback received by TE from an adapter due to TRI API call of triEnqueueMsg(), triEnqueueException(), triEnqueueCall(), triEnqueueReply().

To release a file sharing lock acquired by test component and adapter processes on raw statistics files generated in the default installation location (e.g. C:\Program Files\OpenTTCN\Tester3\logs) and to close pending file handles, the user may need to release resources using the "tester release" command and to stop participating adapters using the "session stop" command after statistics files are generated to gain full access to them.

File content is flushed in the end of a test run.

This timestamp generation facility is a part of a demonstration version and this feature is not an integral part of OpenTTCN Tester for TTCN-3 and it can be removed or disabled without notice from future versions.

TC_PRIORITY

The TC_PRIORITY property controls the priority of main and parallel test component processes. This feature is supported only in the Windows version of OpenTTCN Tester for TTCN-3. Setting TC_PRIORITY property in Linux does not have any effect and it does not generate any error message. Available priority values have the following correspondence to Windows priorities:

• IDLE = IDLE_PRIORITY_CLASS
• NORMAL = NORMAL_PRIORITY_CLASS
• HIGH = HIGH_PRIORITY_CLASS
• REALTIME = REALTIME_PRIORITY_CLASS

PRETEST_FUNCTION

The value of the PRETEST_FUNCTION property shall be a function name of a function with empty parameter list defined in one of the modules of the test session where the property is defined.

The function may have a "runs on" clause, in which case it shall be the same as the "runs on" clause of the relevant test case.

The function specified in the PRETEST_FUNCTION property will be executed before execution of a test case body starts. The function is executed as though it had been called from the corresponding test case.

Supplying unqualified function name as a property value is allowed if the function name is unambiguous.

POSTTEST_FUNCTION

See remarks for PRETEST_FUNCTION. The function specified in the POSTTEST_FUNCTION property will be executed before execution of a test case body finishes, also in case of a test case error.