Rick.Brown

An Approach for virtualizing optional repeating blocks

Blog Post created by Rick.Brown Employee on Mar 25, 2018

Introduction

There are cases in many situations where API request messages have a number of repeating blocks of data. CA Service Virtualization (DevTest) will generate virtual services to match the data scenarios that are seen during the generation process. If, on replay, a different number or different combination of repeating nodes & elements are seen, DevTest will drop through to a “no match found” response, and the client application will receive this as a 404 error, with the text “Please consider expanding your virtual service”.

 

An example of the problem:

Let’s consider a shopping cart. During the generation process, perhaps 1 item is listed in the cart, in which case DevTest will see one block of data for the shopping cart contents. On replay, there might be 2 items in the cart, and there’s a good chance that DevTest won’t understand what to do with 2 items:

 

Example:

<Cart>

            <item product_code=123>

                        <name>Mobile Phone</name>

                        <description>Samsung Galaxy 9</description>

                        <quantity>1</quantity>

            </item>

</Cart>

DevTest will see the arguments like this:

Cart_item_name = Mobile Phone

Cart_item_description = Samsung Galaxy 9

Cart_item_quantity = 1

To add “product_code” to the list, the attribute needs to be moved to an argument, and this would be done by the inclusion of an additional Data Protocol Handler (DPH).

 

On replay:

<Cart>

            <item product_code=123>

                        <name>Mobile Phone</name>

                        <description>Samsung Galaxy 9</description>

                        <quantity>1</quantity>

            </item>

            <item product_code=124>

                        <name>SIM</name>

                        <description>PAYG</description>

                        <quantity>1</quantity>

            </item>

</Cart>

DevTest will now see the arguments like this:

Cart_item_name_1 = Mobile Phone

Cart_item_description_1 = Samsung Galaxy 9

Cart_item_quantity_1 = 1

Cart_item_name_2 = SIM

Cart_item_description_2 = PAYG

Cart_item_quantity_2 = 1

 

The DevTest pattern matching will only know about Cart_item_name, Cart_item_description and Cart_item_quantity (and product_code if the extra DPH was included), so it can’t know how to deal with the elements matching “*_1” and “*_2”.

 

Historically, we would have suggested that the service image gets updated with a specific match against 2 items being in the shopping cart, and this specific scenario would then match correctly.

 

Of course, there can be any number of items in the shopping cart, so there would need to be the same number of matching virtual service instances.

 

If any data needs to change outside these blocks, every virtual service instance needs to be updated with the change, and this is now starting to become unwieldy.

 

I have seen situations where specific blocks require different processing, such as the data block containing “SIM” responding with extra fields like an IMEI number, or some responses adding a future shipping date, or different product codes including different response elements, and suddenly the number of virtual service responses explode with specific matches, making them impossible to search, and discouraging their use.

 

If we’ve added the DPH to cope with “product_code” above, we have an even worse problem, in that we now need to support specific combinations of items, and suddenly we need to use exponential mathematics to determine how many responses we need in our virtual service. It’s not uncommon to have 30 different “product_code” entries possible, each combination of response blocks needing a different response instance, and now we have billions of responses. DevTest can’t be architected to support this without the inclusion of alternative methods of processing the request.

 

There are two current out-of-the-box solutions for this, but I’m going to explain a third method.

  1. Incorporate CA TDM into the virtual service generation process. This is the preferred mechanism, as it offloads all processing to TDM, which was specifically built to support this kind of scenario, putting each repeating block into a different database table and providing the tester with a self-service web page to generate their test data (and virtual service data) on demand, so the required services are deployed and provided at the right time. The argument against the use of this mechanism is simply a commercial one, as it requires a separate product.
  2. Investigate Data-Driven Virtual Services. This is a mechanism within the DevTest Portal to attempt support of this kind of virtual service. It replaces optional segments of the virtual service with @name@ blocks, the data for these blocks coming from an attached Excel spreadsheet. Arguments against this mechanism are that it can only support protocols enabled in Portal, it can only support DPHs enabled in Portal, and some DevTest intelligence is impossible because the service image no longer includes valid response data.
  3. Read on for my third method of supporting this scenario. It uses DevTest Workstation, adding additional virtual services for the repeating blocks, adding request and response scriptable DPHs, adding an extra loop inside the service model and modifying parts of both the request and the response on-the-fly. It is not as user-friendly as the first solution, and it’s not as Portal-friendly as the second solution, and it will need you to understand how to do scripting, but it’s all self-contained and only takes a few hours to completely configure, and provides better responses in most scenarios.

 

Attached as a document so screenshots are immediately embedded.

Outcomes