Sometimes a scenario may want to simulate one of a number of test cases, each of which has its own values. These values can be expressed using a TABLE element, and can be referenced in the scenario using a SELECT element.
Below are descriptions of defining data sets and selecting values in tables, followed by two examples: using test data and multiple tables.
Defining data sets
The data contained in a table is called a data set. Data sets can either be specified inline (inside the scenario), or in an external CSV file (loaded using simulator commands).
Defining a data set inline
When defining a data set inline, you declare the table columns and data values like this:
(TABLES) {
tableName {
{ "column1"; "column2"; ... "columnN"; }
{ "value"; "value"; ... "value"; }
{ "value"; "value"; ... "value"; }
}
}
The first row declares the column names, and the remaining rows define the data values.
Defining a data set externally
When loading a data set from an external CSV file, you declare the table columns like this:
(TABLES) {
tableName {
{ "column1"; "column2"; ... "columnN"; }
}
}
Loading data set files
In order to load external (cvs) data set files, you need to use the load-data-set command.
Selecting values
You select a table value like this:
fieldName (SELECT "tableName[columnName]");
The Simulator randomly selects an initial row using SELECT "tableName[columnName]". So when it generates a message, it chooses a row and columnName value from the defined tableName.
The SELECT narrows the set of matching table rows. If a message includes a SELECT from column 1 of a table for a given message field, and the field’s value matches in exactly two table rows, then the set of matching rows narrows to just those two rows. Any further SELECTs in the scenario definition must match values from the remaining set of possible rows (and may narrow the set further).
|
The same name cannot be used for both a TABLE and an ALIAS.
Table names have the same restrictions as ALIAS names (for example, they cannot contain square brackets or commas)
|
Example: test data
Below is an example of table containing test data. It specifies that whenever the value of the callingPartyNumber field is “`021111111`”, the value of the destinationNumber field must be “`021222222`”.
...
(TABLES) {
testData {
{ "caller"; "dest";} // header row
{ "21111111"; "021222222"; } // first value row
{ "021333333"; "021444444"; } // next value row
}
}
...
initialDP {
callingPartyNumber (SELECT "testData[caller]");
destinationNumber (SELECT "testData[dest]");
}
...
Example: multiple tables
The following example shows multiple tables. Tables destinationNumber and terminatingParty are independently referenced as there is no concept or syntax for joining data sets.
This example specifies that whenever the value of the destinationNumber field in the initialDP message is “`9990`”, the same field in the laterMessage message must be “`6588777123`” (since both values must come from the same row in the terminatingParty table).
MyScenario {
(TABLES) {
originatingParty {
{ "msisdn"; "shortcode"; "imsi"; }
{ "641234567; "1001"; "802222224344"; }
{ "641234444; "1005"; "802222445644"; }
}
terminatingParty {
{ "msisdn'; "shortcode"; "imsi"; }
{ "6588777123"; "9990"; "802234872"; }
{ "6388443782"; "9991"; "983052034"; }
}
}
...
initialDP {
callingPartyNumber (SELECT "originatingParty[msisdn]");
destinationNumber (SELECT "terminatingParty[shortcode]");
}
...
laterMessage {
destinationNumber (SELECT "terminatingParty[msisdn]");
}
...
}
