Skip to content
CA Test Data Manager - 4.4
Documentation powered by DocOps

Integration with CA Service Virtualization

Last update November 8, 2017

This article explains the concepts, benefits, use cases, and best practices about integrating the CA Test Data Manager (CA TDM) Portal with CA Service Virtualization (SV integration). This article also includes an end-to-end example that helps you understand the complete SV integration workflow using the CA TDM Portal.

This article covers the following information:

Tutorial Video

Watch the following video for a visual walk-through of a use case of using RR pairs to generate data for data-driven virtual services in CA Service Virtualization:

How This Integration Benefits Users

Often, organizations face issues when unavailable, unfinished, or constrained components create situations where testers and developers wait for components to become available upstream. Many organizations, therefore, use service virtualization to provide parallel, on-demand access to the components that distributed teams need. However, creating realistic virtualized services requires realistic data. You cannot expose live service data to non-production environments, because it increases the risk of data breach. Similarly, manual creation of request-response pairs (sample data) for a virtual service is a time-consuming and error-prone process. This approach often leads to scenarios where the virtual service data is not exhaustive enough for the rigorous testing. Also, it becomes difficult to incorporate new specifications because of the manual effort involved, leading to the risk of data becoming obsolete.

Integrating CA Service Virtualization with the CA TDM Portal helps you address such issues. This integration helps you update running virtual services with realistic, representative virtual data, which lets you cover a wide variety of the possible testing scenarios. You push the generated Request-Response (RR) pairs into a running virtual service, augmenting your virtual service with the synthetic data that is similar to the production data. Some of the benefits that this integration provides are as follows:

  • Maintains referential integrity of data by creating it (data) directly from an API specification (for example, WSDL). This approach helps create stable environments that are free from cross-system dependencies and constrains.
  • Provides on-demand environments without risking non-compliance, because no live data is exposed.
  • Removes the need to create or maintain manual data for virtual services.
  • Provides uninterrupted access to the up-to-date environments to the distributed teams. This continuity enables them to deliver fully tested applications.
  • Avoids project delays by simulating unavailable or incomplete components.

Use Cases

Using this integration, you can manage the following use cases:

Data Synchronized Across Inter-Dependent Systems and Services

This integration helps you generate and push virtual data with correct referential integrity across inter-dependent services, databases, and components. If your virtual data is referentially intact, your tests do not fail because of data inconsistency.

Consider a scenario where you are testing a customer web portal that is used for ordering items from an online store. The web portal is part of a composite system. When a test order is submitted, the transaction goes through the following steps:

  • An order database is searched for the order.
  • An inventory service is accessed to update the stock.
  • A credit card payment processing service is accessed to charge the credit payment.

The order database is complete and is available for use. However, the inventory service and credit card payment service are constrained. They are unavailable to the teams testing the customer web portal and must be virtualized. To do so, create virtual data so that it is synchronized across the test databases and virtual services. That is, when a test order is submitted, the inventory service and credit processing service must return an inventory item and a credit card. This information must correspond to the order found in the order database. For this scenario, you must push synchronized RR pairs into the inventory service and credit card payment processing service. If the data is not synchronized, tests fail due to data inconsistency. The SV integration lets you manage this scenario as follows:

The CA TDM Portal provides the virtual data that is required to cover every test case. When a test is executed, relevant data in the order database is reserved and RR pairs are generated for the dependent services. Therefore, the correct RR pair is pushed into the virtual inventory service. Simultaneously, the correct data is reserved in the order database and the correct RR pair is pushed into the credit card processing system. The constraints that arise from cross-system data dependencies are therefore removed and teams can cover the complete testing scenario without any manual intervention.

Increase Test Coverage

From a test coverage perspective, you want sufficient coverage in your virtual service. You do not need to guess what possible combinations are available to improve the test coverage. You can push the most important permutations of RR pairs into the virtual service. By linking with CA Agile Requirements Designer, you can determine the different permutations that are available to generate data. Using that generated data of all the important permutations and through the CA TDM and SV integration, you can push the data into a virtual service and can get a better test coverage.

Up-to-Date Virtual Services

With this integration, you can easily maintain your virtual services and provide an up-to-date testing environment to test new scenarios. For example, whenever API specifications change, you can update the virtual service to support the new test scenarios. You can push new parameters into existing virtual services and can leverage the previous effort. This approach also lets you maximize the value of existing virtual data. Testers can then use the up-to-date environment that contains the latest version.

Virtual Services on Demand

With this integration, you can create realistic virtual services without spending manual efforts on generating RR pairs (sample data). You can create realistic sample data for new virtual services directly from API specifications (for example, WSDL/RR pair). You can also support more testing scenarios by pushing new RR pairs into existing virtual services. Distributed teams can then run efficient test and development cycles in parallel, in secure environment that is free from system constraints and dependencies.

Understand the CA TDM Portal and SV Projects

Integrating the CA TDM Portal with CA Service Virtualization involves interaction with different projects. Different projects that are used when you integrate the CA TDM Portal with CA Service Virtualization are as follows:

CA Test Data Manager (CA TDM) Portal Project

You create a CA TDM Portal project (Portal project) by using the CA TDM Portal. All the integration-related operations that you perform in the CA TDM Portal occur in context of a Portal project and its version. 

The CA TDM Portal project must also contain at least one version. For simple applications, you can work with a single version. However, if you have a complex application, create multiple Portal project versions to address different scenarios. The version name is usually the name of the current release of your database/application; for example, 7.A. You can also create one generic version within each Portal project. The generic version stores all generic test cases, which normal test cases can then inherit. For example, in a travel system, you can create a standard trip. The standard trip is then available when you edit the data. For more information about how to create Portal projects and work with them, see Create and Edit Projects.

CA Service Virtualization Project

A CA Service Virtualization project (SV project) contains static virtual services, which you can run in a virtual service environment (VSE). After you run the static virtual service, you can update it by using RR pairs (XML or JSON) that the CA TDM Portal has created. For more information about SV projects, see CA Service Virtualization documentation.

How the CA TDM Portal and CA Service Virtualization Interact

The following diagram illustrates the high-level flow of information between the CA TDM Portal and CA Service Virtualization:

SV_Integration_Flow

The following points explain the information flow that is shown in the illustration:

  • Step 1: Register a file object to the CA TDM Portal. 
    For SV integration, the file object must be of type WSDL, XML RR pair, JSON RR pair, or REST RR pair.
  • Step 2: Create and register derived objects in the target database based on the registered file object.
  • Step 3: Import the sample RR pair data into the derived objects.
  • Step 4: Define data generation rules.
    This step adds data generation rules to the derived objects, which help during the process of data generation.
  • Step 5: Publish the data into derived objects.
    This step adds more data to the derived objects.
  • Step 6: Export the generated data (as RR pair files) into a virtual service in CA Service Virtualization.

Best Practices

Review the following best practices that you can use while working with the SV integration:

  • Performing Multiple Operations: (For WSDL) You can use one file object to create and register derived objects only for one operation at a time. To use the same file object for multiple operations, register that file object separately for each operation and create and register derived objects. For example, your WSDL file has two operations (getAddress and getProduct). You want to derive objects for each operation. In this case, register your WSDL file separately for each operation—first for the getAddress operation and then for the getProduct operation.
    Another use case about using the same file object for performing multiple operations is as follows:
    If the "create and register derived objects" task fails for one operation in a file object, you can reuse the same registered file object for another operation. If the task succeeds for one operation, drop the derived objects if you want to use another operation for the same file object. For example, your WSDL file has two operations (getAddress and getProduct). In this case, you register the WSDL file and perform the "create and register derived objects" task for the getAddress operation. If the task fails for getAddress, you can perform the same task for the second operation, getProduct. However, if the task succeeds for getAddress and you want to use the same file object for getProduct, drop the derived objects that are created for getAddress and proceed with getProduct.
  • Using the Same Connection Profile and Schema Name: When you perform the import and export tasks, we recommend that you do not change the connection profile and schema names that you used at the time of creating and registering derived objects. Though the CA TDM Portal lets you change the connection profile and schema names, we recommend that you do not change them.
  • Identifying Derived Objects: If you use the same database as a target connection profile to derive objects for the different file objects, it becomes difficult to identify which derived objects belong to which file object. In this case, you can uniquely identify derived objects based on the schema name. The schema name format is <objectName>_<objectId>, where <objectId> is an integer.
  • Adding Unique Values to Primary Keys: Every derived object includes a column that is named Shred_ID, which must include a unique value. The CA TDM Portal recognizes this ID as an identity of a derived object. Instead of manually adding a unique value to this primary key column, use the Make All Parents Default option in the CA TDM Portal to automatically add this value during data generation. For more information, see the step about relational editing in Create Data Generation Rules.
  • Establishing Parent-Child Relationships: After you create and register derived objects, you can automate the task of ensuring that the foreign key column in the child table refers the primary key column in the parent table. To do so, use the Make All Children References option in the CA TDM Portal. This option helps you automatically generate data generation rules for the foreign key column in the child table, which otherwise is a manual and error-prone effort. This reference, therefore, enables you to establish a relationship between the parent and the corresponding child tables. This approach also maintains the referential integrity of the data at the time of publishing. For more information, see the step about relational editing in Create Data Generation Rules.
  • Incorporating Schema Changes: Consider a scenario where you use one file object to create and register derived objects in context of a specific project. After you do that, you update the same file object because of the additional information that you received. Now, to accommodate the additional schema changes, you want to use the updated file to create and register derived objects. In such scenarios, you do not need to use a different project and perform the "create and register derived objects" task from the start. You can simply use a new version in the same project to create and register derived objects. This approach ensures that the CA TDM Portal identifies and implements only the changes in the schema, not the complete information. For more information, see Upgrade Inherited File Objects.
  • Using Table Relationships: After you derive objects in the CA TDM Portal, you can view the table relationships between different derived objects. These relationships help you understand how derived objects are related to each other. You can use this information to select appropriate derived objects for which you can write necessary data generation rules. For more information about table relationships, see View Table Relationships.
  • Creating Virtual Services: In CA Service Virtualization, you can create a virtual service using multiple methods. For example, using recording, RR pair, and JDBC. However, the CA TDM Portal is not dependent on the method that you used to create the virtual service. After you run the virtual service, the CA TDM Portal can update it with generated RR pairs regardless of the method that you used to create the service.
  • Using Correct RR Pair Naming Convention: Ensure that the RR pair files that you use for uploading the data into a virtual service follow the correct naming convention. Example RR pair file names that follow the correct naming convention are TDMFile_1655-Req.xml and TDMFile_1655-Rsp.xml.

Differences in Handling XML, JSON, and REST RR Pairs

The SV integration requires an RR pair to update a virtual service. The SV integration supports the following types of RR pairs:

  • XML request-XML response (XML RR pair) 
  • JSON request-JSON response (JSON RR pair)
  • REST request-REST response (REST RR Pair)

XML Request-XML Response (XML RR Pair)

XML RR pair supports SOAP, non-SOAP, and REST formats. The RR pair files are in .xml format. For SOAP/non-SOAP, the XML RR pair input includes an XML request body and a corresponding XML response body. The SV integration supports this XML RR pair use case, because it adheres to the RR pair format. However, for REST format in the case of XML RR Pair, different REST methods are available—PUT, POST, GET, and DELETE. RR pair input for PUT and POST requires a request body and a corresponding response bod. Whereas, GET and DELETE do not require any request body. The SV integration supports only PUT and POST methods for the XML RR pair use case. 

JSON Request-JSON Response (JSON RR Pair)

JSON RR pair supports REST format. The RR pair files are in .json format. The SV integration supports the PUT and POST methods for JSON RR pairs.

REST Request-REST Response (REST RR Pair)

REST RR pair supports REST format. The RR pair files are in .txt format. The SV integration supports the PUT, POST, GET, and DELETE methods for REST RR pairs. The text files (which include the data for REST RR pair) must include the data in a specific format. For more information about the format, see REST RR Pair Format.

Note: For GET and DELETE, the request text file includes only the URL; the response text file includes the URL and body.

The following illustration further explains the information:

  REST_RRPAIR_Formats

Example: Get Supplier Information Based on a ZIP Code

Access to a live environment in your organization is restricted. You want to test your application service with various combinations of data to ensure that the service works as expected. To address such scenarios, you can use CA Service Virtualization to virtualize the actual service and push RR pairs into this virtual service. You, therefore, enhance the virtual service by adding more RR pairs to it, allowing you to rigorously test your application. This approach lets you route your application to the virtual service so that you can test the application without getting blocked because of the restricted access.

In this example, you test a scenario where you virtualize a service to get details about the supplier based on a ZIP code. You have only the ZIP code information. You want to use that ZIP code in a request body to find available suppliers catering to that area in the corresponding response body. To virtualize this service, you must have multiple XML RR pairs that you want to host in that virtual service. For these XML RR pairs, the request XML file must include the ZIP code information and the corresponding response XML file must include the related supplier information. You generate multiple similar XML files, adhering to the same schema defined in the associated WSDL file. All the XML RR pairs are then hosted in the virtual service.

The complete workflow is as follows:

  1. Create a Connection Profile.
  2. Create a Portal Project.
  3. Register a File Object (WSDL).
  4. Create and Register Derived Objects.
  5. Create a Data Generator.
  6. Import the Sample RR Pairs into Derived Objects.
  7. Verify Records in the Database After Import.
  8. Add Data Generation Rules.
  9. Publish More Data into Derived Objects.
  10. Verify Extra Records in the Database After Publishing.
  11. Create a Virtual Service in CA Service Virtualization.
  12. Configure the Virtual Service Connection in the CA TDM Portal.
  13. Export the Generated Data (RR Pairs) into the Virtual Service.
  14. Verify the RR Pairs Added to the Virtual Service.
Note: You can follow the same process for the other file object types (XML RR pair, JSON RR pair, and REST RR pair) that are applicable for SV integration. As of now, you cannot verify JSON RR pairs and REST RR pairs that are added to the virtual service using a client. However, if you have received a successful message for the export operation, it implies that the virtual service has been updated with the generated RR pairs.

Create a Connection Profile

Create a connection profile to ensure that you store the details about a connection to a target database system (Microsoft SQL Server).

Follow these steps:

  1. Access the CA TDM Portal.
  2. Click Configuration in the left pane.
    All available configurable options are expanded.
  3. Click the Connection Profiles option.
    The Connection Profiles page opens.
  4. Click the New Profile button.
    The Add New Connection Profile page opens.
  5. Enter information in the following fields for this example:
    • Profile Name
      Specify the profile name as Supplier_Connection_Profile.
    • Description
      Specify the connection description as This is a Supplier connection profile.
    • DBMS
      Specify the database type as SQL Server.
    • Server
      Specify the server where the Microsoft SQL Server database is available as abc01-ip05.
    • Database
      Specify the name of the database as SupplierDB.
    • Port
      Specify the port number as 1433.
    • User Name
      Specify the user name as sa.
    • Password
      Specify the password as Xyz123.
  6. Click Test to verify the connection.
  7. Click Save to save the connection profile.
    You have successfully created a connection profile.

Create a Portal Project

Create a Portal project to ensure all the operations are performed in context of that project.

Follow these steps:

  1. Access the CA TDM Portal.
  2. Select the Project Manager icon (gear icon) in the top blue bar.
    The Manage Projects dialog opens.
  3. Click New Project.
    The New Project dialog opens.
  4. Enter information in the following fields for this example:
    • Name
      Specify the name of the CA TDM Portal project as Supplier.
    • Description
      Specify the description of the project as This is a Supplier project.
    • Version
      Specify the project version as 1.0.
    • Version Description
      Specify the project version description as This is version 1.0 of the project Supplier.
    • All new versions inherit tables from previous version
      Enable this option to ensure that a new version can inherit tables from a previous version.
  5. Click Save to save the information.
    You have successfully created a Portal project Supplier with its version as 1.0.

Register a File Object (WSDL)

For this example, the file object that you register is WSDL (medicare.wsdl).

Follow these steps:

  1. Access the CA TDM Portal.
  2. Select the Supplier project and its version 1.0 from the Project drop-down list in the top blue bar.
  3. Click Modeling in the left pane.
    The Modeling option expands and displays two options—Objects and Variables.
  4. Click Objects.
    The Objects page opens.
  5. Click Register New Object(s).
  6. Select WSDL as the object type from the Object Type drop-down list.
  7. Enter the object name in the Name field. For this example, the value is specified as Medicare_Supplier.
  8. Drag and drop the medicare.wsdl file to the specified area under File(s) to Upload.
    The medicare.wsdl file is uploaded to the CA TDM Portal.
  9. Click Save to register the WSDL file object.
    The Medicare_Supplier object is added to the list of registered objects.

The next step is to create and register derived objects based on the registered WSDL file object.

Create and Register Derived Objects

When you create and register derived objects, you add a schema to the relational database based on the registered WSDL file.

Follow these steps:

  1. Access the CA TDM Portal.
  2. Select the Supplier project and its version 1.0 from the Project drop-down list in the top blue bar.
  3. Click Modeling in the left pane.
    The Modeling option expands and displays two options: Objects and Variables.
  4. Click Objects.
    The Objects page opens.
  5. Click the Medicare_Supplier object.
  6. Click the WSDL operation GetSupplierByZipCode in the table that lists the available WSDL operations for the registered medicare.wsdl file.
  7. Select the connection profile as Supplier_Connection_Profile from the Connection Profile drop-down list.
  8. Click the Create and Register button.
    A message displaying the job ID appears. When the job completes, all the derived objects are displayed in the Derived Tables section.
  9. Review the derived objects.
    You have successfully created and registered derived objects based on the registered WSDL file.

Create a Data Generator

Create a data generator for your Supplier project.

Follow these steps:

  1. Access the CA TDM Portal.
  2. Select the Supplier project and its version 1.0 from the Project drop-down list in the top blue bar.
  3. Click Generators in the left pane.
  4. Click the New Generator button.
  5. Enter information in the following fields for this example:
    • Name
      Specify the data generator name as Supplier_Generator.
    • Description
      Specify the data generator description as This data generator is for the Supplier project.
  6. Click Save to save the information.
    The data generator Supplier_Generator is created and added to the data generators list.

Import the Sample RR Pairs into Derived Objects

Import the sample data (XML RR pairs) into the Supplier_Generator data generator and into the target database schema (MedicareSupplier_10363).

Follow these steps:

  1. Access the CA TDM Portal.
  2. Select the Supplier project and its version 1.0 from the Project drop-down list in the top blue bar.
  3. Click Modeling in the left pane.
    The Modeling option expands and displays two options: Objects and Variables.
  4. Click Objects.
    The Objects page opens.
  5. Click the Medicare_Supplier object.
  6. Click the Import Data icon (up arrow).
    The Import Data dialog opens.
  7. Enter information in the following fields for this example:
    • R/R Pair Link ID
      Specify the RR pair link ID as r1.
    • Advanced Settings
      Specify the connection profile as Supplier_Connection_Profile and the schema name as MedicareSupplier_10363.
    • Request-File to Upload
      Drag and drop the XML request file medicare_request.xml for the medicare.wsdl file (which defines the schema).
    • Response-File to Upload
      Drag and drop the XML response file medicare_response.xml for the medicare.wsdl file (which defines the schema).
    • Import To Generator
      Select this option to import the sample data to a data generator. When you select this option, the following drop-down list appears:
      • Data Generator Connection
        Specify the data generator as Supplier_Generator.
  8. Click the Import button.
    A message displaying the job ID appears. When the job completes, the sample data is imported into derived objects in the target database schema and into the data generator.

Verify Records in the Database After Import

Access the Microsoft SQL Server database (SupplierDB) to verify that the sample data is added to the derived objects in the database. The following screen shot shows the sample RR pair data added to one of the derived objects after the import process:

This screen shot shows the records in the database after the import process.

Review that the derived object (MedicareSupplier_10363.Response_SupplierData) includes only one record, with the ZIP code as 60532.

Add Data Generation Rules

You add data generation rules to derived objects. These rules help you add more data to your derived objects during the data publishing. For more information about how to add data generation rules, see Create Data Generation Rules.

Follow these steps:

  1. Access the CA TDM Portal.
  2. Select the Supplier project and its version 1.0 from the Project drop-down list in the top blue bar.
  3. Click Generators in the left pane.
  4. Click the Supplier_Generator data generator that you created for the Supplier project.
  5. Click the Select Tables button to open the Registered Tables dialog.
    This dialog lists the registered tables (used and unused) based on the Supplier project. The Supplier project is associated with the Supplier_Generator data generator.
    1. View the table relationships to understand how tables are related to each other. For more information, see View Table Relationships.
  6. Click the Relational Edit button.
  7. Select the Make All Children References and Make All Parents default options, and click OK.
    The first option automatically adds a data generation expression to table cells. This option ensures that the foreign key column in the child table refers the primary key column in the parent table. Similarly, the second option automatically adds a data generation expression to table cells. This option ensures that all the primary keys in the parent tables are replaced with the valid next sequence. For more information, see the step about relational edit in Create Data Generation Rules.
  8. Review the information in the Relational Editor Results dialog, and click OK.
  9. Add data generation rules to the appropriate cells of all the required derived objects. 
    Example data generation rules added to the Response_SupplierData derived object are as follows:
    • SHRED_ID: @nextval(SHRED_ID_SEQ)@
    • SupplierNumber: @randlov(0,@seedlist(Car Parts)@)@
    • CompanyName: @randlov(0,@seedlist(Companies)@)@ LTD
    • Address1: @randlov(0,@seedlist(US Address Line 1)@,1)@
    • City: @randlov(0,@seedlist(US City State Zip County)@,1)@
    • Zip: ^Request_GetSupplierByZipCode.zip(1)^
    • ZipPlus4: @randlov(0,@seedlist(US City State Zip County)@,2)@
    • Telephone: @randrange(2300,9800)@
    • Description: (@randrange(110,999)@)@randrange(110,999)@-@randrange(1110,1999)@
    • Response_SupplierDatas_SHRED_ID: ^Response_SupplierDatas.SHRED_ID(1)^
    You have successfully added data generation rules to all the derived objects.

Publish More Data into Derived Objects

After you create data generation rules, publish the data so that you can add more data to the derived objects in the target database. For more information about how to publish the data, see Publish Data Using the CA TDM Portal.

Follow these steps:

  1. Access the CA TDM Portal.
  2. Select the Supplier project and its version 1.0 from the Project drop-down list in the top blue bar.
  3. Click Generators in the left pane.
  4. Click the data generator Supplier_Generator that you created.
  5. Click the Select Tables button to open the Registered Tables dialog.
  6. Click the rows corresponding to the used derived objects that you want to use for the data publishing. For example, used derived objects are Request_GetSupplierByZipCodeResponse_GetSupplierByZipCodeResponseResponse_SupplierDataLists, Response_SupplierData, and so on.
    All derived objects with appropriate rows are listed in the <Data Generator Name> page.
  7. Review the data generation rules (added to the derived objects in the preceding procedure).
  8. Click the Publish button.
  9. Enter information in the following fields for this example:
    1. Table Count
      Specify the table count value as 1 for all the listed derived objects.
    2. Publish To
      Specify the connection profile as Supplier_Connection_Profile.
    3. Schema
      Specify the target schema name as MedicareSupplier_10363 (for the selected connection profile).
    4. Repeat
      Specify the value as 10 to provide the number of rows to add to the derived objects.
    5. Email
      Specify the email ID where you want to send the publishing notifications as givore@xyz.com.
    6. Schedule  Publish
      Select Now in this section.
    7. Include in Publish
      Select the check box that is available before the table name to include the table in the publish. 
  10. Click the Publish button.
    A message displaying the publish job ID appears. When the job completes, the data is published into the derived objects in the target database schema. 

Verify Extra Records in the Database After Publishing

Access the Microsoft SQL Server database (SupplierDB) to verify that extra rows are added to the derived objects in the target database. 
The following screen shot shows that the same derived object (MedicareSupplier_10363.Response_SupplierData) now includes more records as a result of the publish process:

This screen shot shows the records in the database after the publishing is done.

Create a Virtual Service in CA Service Virtualization

Use the CA DevTest Portal to create a virtual service. You use the initial sample RR pair data to create the virtual service. You then add more RR pairs (as part of exporting from the CA TDM Portal) to this virtual service to represent the real-world scenario.

Follow these steps:

  1. Log in to the CA DevTest Portal.
  2. Click the Virtualize using RR pairs option under Create in the left pane.
  3. Select the virtual service environment server name from the VSE Server drop-down list.
  4. Enter the virtual service name (Supplier_Virtual_Image) in the Service Name field.
  5. Select the service group name (VSE) from the Service Group drop-down list.
  6. Select HTTP as a protocol from the Protocols drop-down list.
  7. In the Upload Custom Request/Response Files area, upload the sample XML request and response files by browsing to the location where the files are available or by dragging and dropping the files into the area.
  8. Click the Allow duplicate specific transactions option.
  9. Click Create and Deploy.
    A message displays stating that the virtual service with the name Supplier_Virtual_Image is created and is deployed in the provided VSE server. The message also provides the HTTP location where the virtual service is available.

Configure the Virtual Service Connection in the CA TDM Portal

To communicate with the required CA Service Virtualization environment, configure the CA TDM Portal with the appropriate virtual service-related information.

Follow these steps:

  1. Access the CA TDM Portal.
  2. Click Configuration in the left pane.
  3. Click the DevTest Portal option.
  4. Enter information in the following fields for this example:
    • Protocol
      Specify the protocol value to connect to the virtual service as HTTP.
    • Host Name
      Specify the name of the host where the virtual service environment is available as abc01-grica.
    • Port
      Specify the registry web service port number (not CA DevTest Portal port number) where the virtual service is running as 1505.
    • Username
      Specify the name of the user having access to the virtual service environment as abc.
    • Password
      Specify the password for the user as xyz123.
  5. Save the configuration details.
    The virtual service connection details are saved. 

Export the Generated Data (RR Pairs) into the Virtual Service

After you configure the CA TDM Portal to connect to the virtual service, you can export the generated data into the configured virtual service. The data is exported into the virtual service in the form of XML RR pairs.

Follow these steps:

  1. Access the CA TDM Portal.
  2. Select the Supplier project and its version 1.0 from the Project drop-down list in the top blue bar.
  3. Click Modeling in the left pane.
    The Modeling option expands and displays two options: Objects and Variables.
  4. Click Objects.
    The Objects page opens.
  5. Click the Medicare_Supplier object that you want to use for the data export operation.
  6. Click the Export Data icon (down arrow).
  7. Enter information in the following fields for this example:
    • Connection Profile
      Specify the connection profile name as Supplier_Connection_Profile.
    • Schema Name
      Specify the schema name for the selected connection profile as MedicareSupplier_10363.
    • Update Virtual Service
      Select this option and provide information in the following fields:
      • Virtual Service Environment
        Specify the name of the virtual service environment as VSE. This drop-down list is automatically populated based on the virtual service configuration information that you provide in the CA TDM Portal.
      • Virtual Service
        Specify the name of the virtual service as Supplier_Virtual_Image. This drop-down list is automatically populated based on the virtual service environment that you select in the preceding list.
  8. Click the Export button.
    An export job is created. A message with a job ID appears. When the job completes, all the exported XML RR Pair files are exported into the specified virtual service Supplier_Virtual_Image.

Verify the RR Pairs Added to the Virtual Service

After you perform the export operation, all the data available in the target schema is pushed into the virtual service in the form of XML RR pairs. You can verify this information by using any available client that can display a response based on a request for a virtual service.

In this example, CA DevTest Workstation is used to verify the RR pair data in the virtual service.

Follow these steps:

  1. Log in to the CA DevTest Workstation.
  2. Right-click Tests and select Create New Test Case.
  3. Right-click in the right pane and select Add Step, Web/Web Services, Web Service Execution (XML).
  4. Specify the location of the WSDL file (used for deriving objects) and the virtual service endpoint.
  5. Paste the request body and provide the ZIP code (for example, 65001).

    Note: The ZIP code 65001 was added to the derived objects as a result of the data generation process. This ZIP code was not originally present in the derived objects.

  6. Click the arrow icon to execute the request.
    The appropriate response body is returned.

The following screen shot shows the request for the ZIP code 65001:

This screen shot shows a request for a specific ZIP code.

The following screen shot shows the corresponding response received for the ZIP code 65001:

This screen shot shows an appropriate response for the corresponding request.

In this example, you have successfully exported XML RR pairs that adhere to the schema that is defined in the WSDL file.

Was this helpful?

Please log in to post comments.