Creating data model-driven stubs

Data models provide an alternative way to store data for a stub. This method creates stubs from recorded events, and such stubs can reuse the data across multiple operations.

About this task

Basic (hardcoded) and parameterized (data-driven) stubs are examples of simple stub-types because the data that is provided when the stub is run is either hardcoded in the stub itself or is taken from a simple data source. In each case, the same data is used each time when the stub is started.

However, the testing of complex systems might require persistent storage of data so that a stub can save information across multiple operations. By doing so, you can virtualize services that create data, for example, a customer, and then use that data in a GetCustomer service without having to know a design time the data will be used. It is this capability that distinguishes simple stubs from those that are coordinated to provide a virtualized application.

In cases where you require multiple operations within a stub, or multiple stubs to share data to provide a virtualized application, consider using a data model to hold such data. Data models can be shared across stubs. In addition, data models can hold data about multiple entities and their relationships, such as customers and orders.

Therefore, a data model is a simple view of entities and their relationships that can be used by stubs to persist information. Data models exist as assets within a project. A stubs properties define which data model it is using. Stubs can read and modify data held in a data model. You can use the Stub Editor to specify whether an operation is trying to create, update, or delete data based on the received message, and thus reduce the time and effort you need to create rich stubs.

In Rational® Integration Tester, you can create a data model by using the Ecore Editor . Alternatively, you can create a data model while creating a data model-driven stub from recorded events. This second method analyzes the message in recorded events and creates a data model and entities within that data model based on the messages. Operations that are created will be connected to the data model automatically.

To create a data model-driven stub from recorded events:

Procedure

  1. In Rational® Integration Tester Recording Studio perspective, in the Events View window, select multiple recorded events.
  2. On the Events View toolbar, click the arrow icon () next to the Save Stub from selected events icon () and on the context menu, click Save Data Model Stub.

    Alternatively, right-click the messages and click Save Data Model Stub on the shortcut menu.

    Note: The first and second screens of the Recorded Events wizard are the Resource Type and Data Storage screens. The screens are displayed only if you click the Save icon () or press CTRL+S. Clicking the Save Stub from selected events icon () bypasses the Resource Type and Data Storage screens.
  3. On the Operation Assignment screen, you can modify the operation and the events associated with the stub.
    Note: If you are creating a stub for multiple operations, Rational® Integration Tester attempts to verify that all selected recorded events are associated with the correct operations.

    Click Next.

  4. On the Transaction Assignment screen, you can group the events into transactions.
    The groups that you choose are important because they determine the number of merged messages and, thus, the number of remaining screens in the Recorded Events wizard. For example, one recorded event could have a single transaction, which means that there is only one mapping. Or, two recorded events might be grouped into two groups, which means that there are two transactions and, thus, only one mapping. Or, two recorded events could be put into a single group, which means that there are two mappings.

    For information about this screen, see Creating basic stubs.

    Click Next.

    The Entity Mapping screen is displayed.
  5. On the Entity Mapping screen, map the fields in the selected recorded events to the data source to use for data model-driven stubbing.

    A separate Entity Mapping screen is displayed for each event you selected in step 1. The following table describes how to use the Entity Mapping screen.

    To... Do this...
    Specify that a field in a recorded event will be an entity in the data model
    1. Select the field.
    2. Click Entity. The Map to entity dialog box is displayed.
    3. Click OK. For the selected field, New is displayed under Status.
    Specify that a field in a recorded event will be an attribute of a particular entity in the data model
    1. Select the field.
    2. Click Attribute. The Map to Attribute dialog box is displayed.
    3. Click OK. For the selected field, New is displayed under Status.
    Specify that a field in a recorded event is not included in the data model
    1. Select the field.
    2. Click Ignore.
    Search for a specific data item in a recorded event
    1. Click Search.
    2. In the Find field (displayed at the bottom half of the screen), enter the search query.
    3. Press Enter.
    Increase or decrease the number of example values displayed for each field In the Samples field, enter or select the number of examples to display (default value: 2).
    Specify that a field is a "key" field so that it can be used to match data between different messages Under the Key column, select the check box of the field.
    Expand or collapse a node
    1. Click the node.
    2. Click Expand or Collapse.

    Click Next.

  6. In the Header Transformation window, all HTTP headers that were identified in the recorded traffic are displayed. Only those headers that are useful in distinguishing one operation from another are enabled. The remaining headers are disabled to make the message or messages more generic. Change any of these assignments if necessary, and click Next.
  7. On the Summary screen, review the configuration of the stub and save the stub and the data model.

    Click Finish.

Results

After you click Finish on the Summary screen, the following actions happen:

  • The Rational® Integration Tester Test Factory perspective is displayed, and the newly created stub is displayed under the relevant logical resource on the component tree. If you created a stub for multiple operations, the stub is displayed under each applicable operation.
  • If you selected the Open resource after finish check box on the Summary screen, the stub is also opened in the Stub Editor. You can edit any of the details; see Modifying message-based stubs.
  • If you open the Data Models window in the Architecture School perspective, the newly created data model is listed on the upper left of the window. To display the data models details in the window, select the model.