Setting up the schema used for stubbing a physical database

Before you can create database stubs, you must specify in IBM® Rational® Integration Tester which database schema is to be used for the simulation database.

About this task

If you are using Rational Integration Tester 8.5.0 or later and you want to simulate an IBM DB2®, Oracle, Microsoft SQL Server, or MySQL database, you have the option to use the integrated simulation database or a vendor-specific database.

The integrated simulation database is an Apache Derby database that is included with Rational Integration Tester. Although the Apache Derby database is based on the Java™, JDBC, and SQL standards, it cannot simulate the idiosyncrasies of all other databases, so in the following situations it may be appropriate to use a database schema that matches the database being simulated:

An application may be using SQL syntax that is not understood by the integrated simulation database. This will be evident if the console of the application displays messages about unexpected JDBC exceptions during the recording (learning) phase. If you are using the Rational Integration Tester JDBC proxy, these SQL errors are also logged in the activity log of IBM Rational Test Control Panel, which is viewable if you have Rational Test Control Panel administrator privileges.
A database might support a data type that the integrated simulation database does not support. This will be evident if you try to edit a database table of a database stub that includes a data type not supported by the Apache Derby database. Rational Integration Tester will display SQL syntax error messages when saving the database table.

Note: If you elect to use the integrated simulation database, the instances of the databases that Apache Derby uses are stored in the workspace of Rational Integration Tester or IBM Rational Integration Tester Agent, whichever is applicable. The specific location in the workspace is unimportant because the locations where the instances are stored are transient.

Depending on the option you select, the database schema or the integrated simulation database will be used while Rational Integration Tester is "learning" the stubs, and also used when a stub is started, that is, the database schema or the integrated database will be used to store the contents of a database stub.

Note: If you want to run more than one database stub simultaneously and you want to use a database schema, you will need a database stub schema for each database stub. For example, if you want to run five database stubs simultaneously, you will need five database stub schemas. However, each schema must match the corresponding database. For example, if you want to stub an Oracle database, you will need an Oracle schema. Alternatively, if you want to stub a Microsoft SQL Server database, you will need a Microsoft SQL Server schema, and so on.

The following table lists the live/simulation database combinations supported by different versions of Rational Integration Tester.

Live and simulation database combination support	Rational Integration Tester version
DB2/DB2	5.4.0 or later
DB2/Integrated simulation database (excluding support for JDBC virtualization on IBM WebSphere® Application Server)	8.5.0 or later
DB2/Integrated simulation database (including support for JDBC virtualization on WebSphere Application Server)	8.5.1 or later
Microsoft SQL Server/Microsoft SQL Server	5.4.0 or later
Microsoft SQL Server/Integrated simulation database (excluding support for JDBC virtualization on WebSphere Application Server)	8.5.0 or later
Microsoft SQL Server/Integrated simulation database (including support for JDBC virtualization on WebSphere Application Server)	8.5.1 or later
MySQL/MySQL	5.4.0 or later
MySQL/Integrated simulation database (excluding support for JDBC virtualization on WebSphere Application Server)	8.5.0 or later
MySQL/Integrated simulation database (including support for JDBC virtualization on WebSphere Application Server)	8.5.1 or later
Oracle/Oracle	5.4.0 or later
Oracle/Integrated simulation database (excluding support for JDBC virtualization on WebSphere Application Server)	8.5.0 or later
Oracle/Integrated simulation database (including support for JDBC virtualization on WebSphere Application Server)	8.5.1 or later

Procedure

In the Physical View of the Architecture School perspective of Rational Integration Tester, double-click the physical database that you want to stub.
The Database (Properties) window is displayed.
Click the Stub Settings tab.
The Stub Settings tab is displayed.
Note: If you are using Rational Integration Tester 8.5.0 or later, by default, the Use integrated database check box is selected.
Decide whether you want to use the integrated simulation database or a vendor-specific database:
- If you want to proceed with using the integrated simulation database, click OK to close the window.
- Alternatively, if you want to use a vendor specific database, clear the Use integrated database check box and complete the remaining steps in this procedure.
In the Database URL field, enter the URL of the server that will host the database stub schema.
In the User Name field, enter the name of the relevant database user.
In the Password field, enter the database user’s password.
In the Database Schema field, enter the name of the database stub schema.
Note: Rational Integration Tester manages the content of the simulation database, including dropping and creating content when database stubs are executed. To avoid collisions between this management of the simulation database and the content of the live database, the database settings for the live and simulation databases must be distinct. The combination of database URL and schema must provide sufficient separation between the live database and the simulation database; for example, you could use different schemas within the same database or you could use completely different database instances.

Note: The user name, password, and schema name should be provided by a database administrator (DBA). The database user must also have sufficient privileges to be able to create and delete tables in the simulation database.
Optional: When working with database virtualization, if you observe that the data in the simulation database is not reset automatically, use the Clear simulation database option to manually clear the data.

Modify the default value of the Max Row Count field. The default value of the field is 10,000. You can decrease this default value if you want to limit the maximum number of rows copied when learning from a live database or when copying rows into a database stub.
Modify the default value of the Max Stored Procedure Calls field. (This field is available only in Rational Integration Tester 8.0.1 or later). The default value of the field is 10,000. If the system under test is very active, you can decrease the value of this field, thus limiting the quantity of data captured by Rational Integration Tester while learning.
Modify the default value of the Max Result Set Row Count field. (This field is available only in Rational Integration Tester 8.0.1 or later.) The default value of the field is 10,000. You can decrease this default value if you want to limit the maximum number of rows copied when learning a result set returned from a stored procedure and thus limit the amount of information that Rational Integration Tester will learn while creating a new database stub. You might want to use this field if you cannot or do not want to modify the behaviour of the system under test.
Click the Unique option button (default) if you want to record only unique invocations of a stored procedure based on the input parameters. Alternatively, click the All option button if you want to record all invocations of a stored procedure. (These option buttons are available only in Rational Integration Tester 8.0.1 or later.)

Click Test Stub Connection to verify the Rational Integration Tester connection to the database stub.
Click OK.

Results

You are now ready to create database stubs.

Feedback