This topic explains how you can use the Data Repositories view and the related editor to review and modify the repository structure as well as update the included records.
Sections include:
The Data Repositories view is designed to help you review and extend the available servers, repositories, data sets and record types. From this view, you can add servers and repositories (as described in earlier topics) as well as define data sets and record types.
The data on each repository server can be logically grouped into any number of subsets, which are called data sets. All data sets draw from the library of record types defined for the given repository. To add a data set:
At least one record type must be defined for each data set. To add a record type:
You can define any number of record types that will be describe the structure of records on this repository. To add a record type:
To start navigating through the repository records, do one of the following:
Color | Meaning |
---|---|
Yellow | A complex column that you can drill-down into. |
White | Stores a primitive value that you can edit here. |
Purple | Determines the row number, which is used by SOAtest in determining how to iterate over data source row. Not applicable for Virtualize. |
Symbol | Meaning |
---|---|
[R] | Record list |
[L] | Literal / primitive list |
From the Data Editor, you can edit record values, rows, and columns.
You can edit the record values in any column with a white or light-purple background. Cut/copy/paste is supported. Changes are saved in real time; you do not need to explicitly save your changes.
Note that if a field contains large data, you can double-click that field to open the value in a editor dialog. Alternatively, you can right-click that field and choose Edit to open that same editor dialog.
Data source caching settings control whether repository data changes are immediately reflected in deployed virtual assets.
If the data source’s Enable caching option is disabled (the default), updates to the repository data will be immediately reflected in any deployed virtual assets which use that data.
If you enable caching, virtual assets will need to be redeployed in order for the repository data changes to take effect at runtime. Enabling caching for load testing is recommended for performance optimization.
If you want to set a value to nil or exclude (so it will not appear in the message when an element is populated from this data source), use the available right-click options (Set field to null, Set field to exclude). Or, you can enter special string values: [null]
will be treated as a value that has been set to null, and [exclude]
will be treated as a value that has been set to exclude
.
When adding rows, you can either create a new row or add a reference to an existing row. If you add a reference to an existing row, you essentially link this new row to the original row; if the original row is updated, those changes will be propagated across all referencing rows.
To create a new row:
To create a reference to an existing row:
New rows are always added at the bottom of the table.
Columns can have the following types:
You can add "regular" columns, as well as "key columns": special columns that are used for Virtualize responder correlations. Key columns must be of primitive type.
Note that the specially-marked (in light purple) row column determines how SOAtest iterates through the data source rows. This column is required if you will be using this repository data in SOAtest.
To create a new regular column:
To create a new key column:
A record identity is the subset of a record type’s fields which uniquely identifies that record type. For example, a bank customer record type might have 15 different fields, but its identity might use only social security number and account number.
Identities enable you to correlate imported traffic data with existing data repository records. This matching helps determine when existing records can be reused and when new ones need to be created. Maximizing reuse simplifies data updating and management. If a record is reused across 1000 ancestors you can update it once and the changes will be automatically propagated to all related records. Otherwise, you would need update all 1000 records individually.
Each set of identity field values must be unique. For example, the following is valid:
Identity Column 1 | Identity Column 2 | Identity Column 3 |
---|---|---|
1 | 2 | 3 |
1 | 2 | 4 |
1 | 3 | 4 |
1 | 3 | 5 |
The following is not valid:
Identity Column 1 | Identity Column 2 | Identity Column 3 |
---|---|---|
1 | 2 | 3 |
1 | 2 | 4 |
1 | 3 | 4 |
1 | 2 | 4 |
To mark an identity:
The selected field(s) will then be marked in green. If you later decide to change the identity, remove it (right-click> Remove Identity), then add a new identity.
Note that fields themselves will not be removed; only the identity status will be impacted. Identity fields cannot be deleted.