Service Virtualization

Hi Team,

I have a requirement for SV in which I will receive a order request consisting of multiple articles and its information and I need to send a synchronous success response and then with some delays ,I need to send back each article information back as a individual Asynchronous response.

Please see example below:

<Articles>
<Article>
<ArticleID>8026E000000OvqNQAS</ArticleID>
<CommercialProductNumber>BIN20M011</CommercialProductNumber>
<CommercialProductDescription>KPN ÉÉN Internet tot 20 Mbps Premium (20Mb/1Mb)</CommercialProductDescription>
<ArticleSequenceNumber>7</ArticleSequenceNumber>
<ArticleDescription>Internet 20Mb/1Mb ADSL Premium</ArticleDescription>
</Article>
<Article>
<ArticleID>8026E000000OvqPQAS</ArticleID>
<CommercialProductNumber>BIN20M011</CommercialProductNumber>
<CommercialProductDescription>KPN ÉÉN Internet tot 20 Mbps Premium (20Mb/1Mb)</CommercialProductDescription>
<ArticleSequenceNumber>8</ArticleSequenceNumber>
<ArticleDescription>KPN ExperiaBox V10</ArticleDescription>
</Article>

</Articles>

Hence I need suggestion to achieve this as it requires first identifying how many articles are present in the request then send those many individual asynchronous responses back.

I am still not clear how will i build a logic that if 2 articles are coming in request then 2 webservice execution step will be called after responder with information about each article to be sent back.

Need some suggestions.

Thanks

Sarthak

Hi Sarthak,

Wondering if the XML XPath Filter would help you in this case - XML XPath Filter - DevTest Solutions - 10.1 - CA Technologies Documentation .

You could use 2 filters. On to get the count, to identify how many 'Article' you have in the XML (something like count(/Articles/Article) and another one to get the Article information (something like /Articles/Article[1]). You can then loop through that counter property and get each Article (/Articles/Article[i])  and execute the step to send this Article. 

Heloisa

Hi Heloisa,

Thanks for your suggestion.I will try this out .Also how can I send this info as Asynchronous response because I am not sure how will I dynamically add the WebService Execution  Steps in VSM based on number of articles .

Thanks

Sarthak

Maria's post pretty much summarizes the pattern.  You only need one WS XML step.  Think about it this way.

- After you Filter the XML, add a Filter to Xpath count the number of Articles in the XML and store this count in a filter for example fl_articleCount

- Add a Do Nothing step

- Add a Counting Dataset to the Do Nothing Step

- Set the counting dataset to count from 1 by 1 until the dataset index > {{fl_articleCount}}

- Give the dataset index a name such as ds_index

- Add a Filter to Xpath the Article occur that aligns to the current index (1, 2, 3, etc.)

use {{ }} notation inside your Xpath to reference the specific occur

For example /Articles/Article[{{ds_index}}]

- Add your WS XML step and set the body to send the Article Filtered in the Xpath

- Set the WS XML step to loop back to the counting dataset Do Nothing Step

- When the counting dataset ends, add a branch in the Counting Dataset to a step outside of the loop such as the LISTEN step

NOTE: If you need to slow the responses down, you might add a JSR-223 step that uses Thread.sleep(1000);  But, keep in mind that you are blocking threads in your service when you do something like this. This could potentially cause a performance problem if your service receives a lot of concurrent requests or a high number of Articles.  Let's say that you have 20 Article occurrences to send out.  If you add the thread sleep of 1 second, it will take the service 20 seconds to send the asynch responses. This means that nothing else can use the thread until you transaction completes. This would likely cause problems for a Functional VSE that is throttled to ~10 TPS.

Hi Joel,

Thanks for this suggestion.This clears my doubt of sending dynamically the asynchronous responses.

For the delay part,can't we use think time of 10 seconds in WS Step so that when the step loops backit will send the next asynchronous response after a delay of 10 seconds.

Thanks

Sarthak

Hi J_NeSmith and @Heloisa,

I am using the suggested approach but when for the below point:

Set the counting dataset to count from 1 by 1 until the dataset index > {{fl_articleCount}}....When I am trying to test the service locally then the counting set is not taking up the value of {{fl_articleCount}} as the limit of the loop.

Also if I need to send this article information when a second request comes to the virtual service ,then how can i achieve this.So its like: For first request ,send a response + 2 asynchronous response. and when the second same request comes,then send this article level asynchronous responses.

I was reading through some of the posts,may be I can put a assertion before responder and route it to article level steps.

Just need some inputs.

Thanks

Sarthak Gupta

I believe VSMs ignore Step think time because DevTest wants virtual services performing faster not slower. Thread sleep is not ignored.

Thread sleep causes your execution thread to suspend for a specified amount of time which can lead to performance issues. 

The issue I see is that the architecture you describe is going to constrain your virtual service's overall ability to handle any sort of concurrency.

A common way to think about a single transaction's (i.e., thread) wall time is to determine the amount of time it takes the service to get from the LISTEN step until the VSM loops back to the LISTEN step. In your use case, you have LISTEN, VSI Selection, Respond (ack), extract article occur, WS XML asynch, wait 10 secs, loop to extract next article, when done go to LISTEN. This means each thread processing an incoming request is consumed while all of these steps execute. The thread cannot process or be allocated to any other incoming request. And, both hardware and software limit the total number of available threads.

If you need to wait long periods between sending responses, my recommendation is to "offload" the Articles XML to the Shared or Persistent Model Map. Then, have a separate virtual service (that acts like a slave process with on incoming transactions) send the asynchronous messages. This second, or slave service, is not constrained by a threading model because all it does is wake up, process everything on the map, go to sleep, rinse and repeat. Never consuming more that 1 thread.

This pattern is more challenging to implement, but it is highly efficient and conserves resources. 

Hi Joel,

I understand your point of performance issues that will occur due to higher wait times.

Also your point of using shared model map .So it would be like this :

Ø  First request comes to virtual service A , send required asynchronous response and store article information in a shared model map (to be sent by virtual service B) .

Ø  Now when the next request comes to virtual service A,how will send back the article responses?

Thanks

Sarthak

Keep in mind that I do not know the architecture of your application nor the full list of requirements.

When you used the term 'send asynch responses' and 'WS Execution XML', I concluded you were using an HTTP 1.1 protocol. Currently, there is no support for the HTTP/2 spec which does allow unsolicited responses.

In my mind, asynchronous responses in an HTTP 1.1 protocol environment are analogous to 'fire-and-forget'. I took the position that there was no relationship between subsequent requests into Service A and the activities performed by Service B. In this regard, Service A and Service B do not know (nor care) what each other are doing.

Once Service A places data on the model map, it does not care whether Service B processes it or not. Service B has no clue what Service A is doing or did, "B" just knows that there is something on the model map that needs to be sent to an endpoint. The following is a very high level diagram of what I was describing.

If there is a more elaborate orchestration of transactions (such as transactions within transactions) between service A and B, additional customizations are necessary because the services are starting to manually manage the state of the application requests and responses.

I may be missing something.  Your second point seems to indicate that the first call returns a synchronous response, and a second call to the same service returns the articles. Am I misunderstanding what you need to do?

Hi Joel,

Thanks for your inputs.Here is overview of my flow:

> On first request to Virtual Service (say VS-A) which contains information about products and articles ,i should get a synchronous response and 2 asynchronous responses back(these asynchronous responses are static and needs to be sent in order to process the order but does not contain any specific info from the request )

> On second request (similar request as before) to Virtual service again (may be we need to send it to a different VS-say VSB), I need  to send back individual article asynchronous responses (as present in the Original request-A) as we discussed earlier.

Please let me know if I was able to put it correct...:)

Thanks

Sarthak

The requirements seem complex enough that we will likely not be able to provide a specific solution in this forum. Some things to think about are:

It sounds as though you need to figure out whether you can use a Stateful service or take advantage of one of the model maps.

In your post you indicate that the first request sends a synch response then 2 static asynch responses. This can still be done using a "slave" service B as depicted earlier. The Responder step in Service A is responsible for sending the first response (synch). The two static responses can be put on the model map and sent by Service B. Technically, responses can be stored as Response 2 of 3 and 3 of 3 in the VSI. Just keep in mind that in an HTTP service, those responses are ignored by the Responder step. The VSM will need some script logic that iterates the lisa_vse_response object and places these responses on the model map. You may also need to perform testExec.parseInState( respStringHere ) so property substitution occurs prior placing data on the map.

To support the second incoming request (whether to Service A or some other service), you have to identify a technique for pairing the first transaction with the second request. Again, maybe a Stateful service can do this or maybe you need a model map. The solution is not clear at this point.  Perhaps, Service A writes a key/value pair to the map. And, the second incoming request uses a value on the request as the "key" to look up the article values written by Service A. The value side of the key/value pair can be iterated to produce asynch responses which represent each article.

Model maps support a concept of namespaces. Perhaps, one namespace supports the key/value pairs that Service B sends via WS Exec XML, and a different namespace holds key/value pairs used for locating the second incoming request.

One might start by creating a detailed sequence diagram of the different flows the service(s) needs to support.

Then develop an understanding of which keys are available on the request side and which are available on the response side. This is an important step in understanding how the service is going to match a subsequent request with a previous request or response. 

Once one understands the flow and mapping, the next step is to determine how the information can be communicated from one request to the next in a stateless environment. This is where the Stateful model or the Model Maps may be able to help.

After choosing an implementation approach, consider the scripting necessary to store the information so it can be retrieved. And, consider if the Asynch responses are best handled by a secondary service.