Environments and Application Models

Each application that an organization uses requires specific data. The tables and their relationships are modeled using an application model version. The application model version specifies a modelling connection, a schema, and a start table as a starting point for the collection of data. An application model version only deals with objects in the specified schema.

Use of relationships defined by data relation rules allows an application model version to accurately model the data associated with an application. Selection begins with the start table and, depending on the data relation rules, continues with referenced tables. XDM then traverses the data relation rules defined on those referenced tables, and so on. Data relation rules in one application model version can reference tables from another version altogether. This allows a row level processor task to gather data from multiple schemas and databases.

The application model version also specifies a number of other rules.

As with the environment and the application model, an application model version can also specify one or more modification sets. In addition, the application model version also allows the specification of custom parameters.

An installed application is an application model version used in an environment. The installed application overrides the connection and schema specified in the application model version on which it is based. There must be an equivalent start table in the connection and schema specified by the installed application. All other properties are inherited from the parent application model version.

As with the application model version, an installed application can also specify additional modification sets.

In order to collect all the data required for a particular application, XDM must know how the required tables are related. This is achieved through the use of data relation rules. Table relationships are defined by specifying base table and referenced table as well as the columns which participate in the relationship. Details can be found in the data relation rule reference documentation.

Data relation rules are independent of any database foreign key relationships. The direction of reference is not necessarily from parent to child. A parent table can reference a child table and vice versa. References in both directions are also valid. XDM can, however, generate data relation rules from database foreign keys.

Using the warehouse example once more, consider an inventory application that reports on current stocks, which items are in short supply, and whether orders for re-supply are currently outstanding. The application would need access to tables containing the quantities of items in stock and their minimum required amounts, current items on order with the expected delivery dates, and whether there are unfulfilled customer orders. When the application is modified it must be adequately tested and for this a suitable environment and application model would be specified.

Such an application would use the table with the items in stock as a start table. Assuming each item has a unique ID, data relation rules could be defined with the items in stock as the base table and the other tables as referenced tables. Each of the referenced tables might also be the base table for other relationships as required by the application. The resulting data relation rules would be added to an application model version corresponding to the application to be tested.

You can restrict the amount of data retrieved through data relation rules. To this end a data relation rules can optionally specify a condition script, a lookup script, and a traversal value. For details on their specification and usage see the data relation rule reference documentation.

The activation script is used to check whether an application model is included in the selection. It is evaluated in tailoring for each application model. An application model is then taken into account in the task execution if the activation script returns true.

More information about the activation script can be found here

The guide Dynamic Environments shows a simple example of how the Activation Script is configured.

XDM begins its selection with a start table, which is set in the application model. In the task, the start table of the application model is then set, which is set in the environment is set as the Start Model.

The Start Model Selection Type defines how the start model is set. If the start model is always contained in the set of selected models, the selection type can be left at Static and the start model can be set to permanently.

Otherwise, the model must be set dynamically using the start model script. In this case, the Start Model Selection Type is set to Dynamic The Start Model Script returns the application model that should be used as start model. If the application models are selected dynamically, it must of course be guaranteed that the application model containing the start table is included in the set of selected models. Otherwise, XDM cannot select any data.

More information about the start model script can be found here

If you use a start model script, the data relation rules within and between the application models must also be configured accordingly. Data relation rules in XDM are directed. In order to be able to reach a table from all possible start tables, two data relation rules may have to be created for a relationship, one for each direction.

In the first instance we will consider an application which deals with the inventory. Tests for such an application would require a variety of different warehouse items, using different units of measure. To obtain an accurate overview, the application would require to access the following tables:

Consider the situation where certain customers wish to send orders using imperial rather than metric units of measure. The inventory application needs to be adapted to cope with these cases. To provide the extra information, the table CUSTOMER is given an extra column called USE_METRIC which has the values Y or N. When the value is N, the customer’s orders are in imperial measure (e.g. pounds or ounces). The ITEMS table would also require a new column IMPERIAL_UNITS to indicate what the imperial unit of measure is.

The test data for the development of the new inventory application is to be sourced from The TEST1 schema on TDB1 and placed on another connection called DDB1 with schema DEV1. To provide the data to ensure that the application still provides correct inventory information, one would define two further data relation rules on the application model version to be used. The base application model would be the same.

The enhanced application would need to access some additional tables:

This example will consider a situation where different data is required from the same source tables. In the first instance a procurement application must create and update orders for items which fall below the minimum quantity. Such an application might also have responsibility for planning where orders are sourced. To this end the ITEM_SUPPLIER table can be used to examine the supply chain.

Suppliers of items for the warehouse will have their own suppliers for parts or raw materials. This leads to a supply chain which goes all the way back to the source of the raw materials. It is important to know whether a supplier sources materials from a region where factors such as natural disaster might affect the availability of materials. In this case the application must ensure that warehouse items are sourced from those suppliers who are most likely to be able to deliver goods reliably.

These requirements must access different data. In the first case, the application only requires data from suppliers who are direct suppliers of the warehouse. This requires data from the following tables:

Important here is that rows from the ITEM_SUPPLIER should be those where the column DIRECT_SUPPLIER has a value of 'Y'.

The second case, that of procurement planning, requires data that includes the full supply chain. The tables which would be required are:

There are a number of ways to satisfy the differing requirements. One possibility is to devise a single application model version with a variety of different data relation rules. The main aspects to note are the use of the data relation rule’s traversal property, the use of a lookup script, the use of condition scripts, and the use of a custom parameter.

As before, the source database and schema are PDB1 and PROD1 respectively, and the target database and schema are TDB1 and TEST1 .

In many organizations it is common for data to be stored in logical groups which can span multiple schemas and even databases. XDM can deal with test data requests which involve tables from various groups by defining data relation rules across database boundaries.

Adequately testing how well applications cope with such an arrangement typically requires system integration testing on a regular basis. With large volumes of data, this can be a drain on resources, so it would be helpful to be able to extract a representative sample of test data from all databases, whilst simultaneously maintaining all necessary relationships between tables.

For the purpose of this example we will assume that our warehouse uses the following database arrangement:

Database PROD1 (External Entity Data):

Database PROD2 (Stock and Procurement):

Database PROD3 (Customer Orders):