Service Virtualization

I got a service to virtualise. Its a http request. So I thought of using req/rsp pair to create a virtual image. But I also have the below dynamic header details to be added alongwith the request. How to create the virtual image in this scenario? Where shall i give the request headers? How will be my request and response pair? Can someone hel[ me with this?

FTL Endpoint:
Name: FTLEndpoint
Value: ep-TPIntegrationASServices_receive

Target service name:
Name: TargetService
Value: NotifyBillingAccountCreation

Target XSD name:
Name: TargetXSD
Value: CustomerAccount.xsd

As you are using Request/Response pairs for recording, and you want to create different header values during the recording, you can do that using Sidecar files. A sidecar file contains key/value pairs that are added to the metadata of requests, responses, or both in a virtual service.  Please see documentation on this : Request/Response Pairs - DevTest Solutions - 10.1 - CA Technologies Documentation 

This file applies to all request or response files or it can be used for specific files.

for example :

someReq1-req.txt

someReq1-req-meta.properties

someReq1-rsp.txt

someReq1-req-meta.properties will contain something like: 

FTLEndpoint=ep-TPIntegrationASServices_receive
TargetService=NotifyBillingAccountCreation
TargetXSD=CustomerAccount.xsd

Hope this helps.. 

Thanks

Shiney. 

I did the same. I created an aditional file in my RR pair named "notifyBillingAccountCreation-rsp-meta.properties".but when I create an virtual image, it is taking my properties as a response. And hence after deployment of my service, when my client test this in SOAP ui, I get this as a response not as header value. Please see the attached screen shots for better clarity.

You indicated that you wanted these properties on the request Header.

However, the set up  you describe in the above post is using the sidecar file as a response header (-rsp-meta.properties). 

abrsh01 was suggesting that you add the headers in notifyBillingAccountCreation-req-meta.properties. 

Can you make this change, recreate the VSI and let us know if the results are different?

Hi , I have created the file "notifyBillingAccountCreation-req-meta.properties" and recreated the image. But I dont see these headers got added anywhere in the request. I have attached the new image with screen shots. Please look into this and let me know if I have to change anything.

OK, this is a RESTful service.  In this case, add the headers in the notifyBillingAccountCreation-req.txt file and remove the -req-meta.properties file.

POST /notifybillingaccountcreation<?query=query_String_Here_if_you_have_one> HTTP 1.1

Content-Type: application/json
Connection: keep-alive
FTLEndpoint=ep-TPIntegrationASServices_receive
TargetService=NotifyBillingAccountCreation
TargetXSD=CustomerAccount.xsd

<BLANK LINE HERE>

<JSON_REQUEST_PAYLOAD_GOES_HERE_IF_YOU_HAVE_ONE>

If you do not have a payload or query string, then omit these from the example but keep the blank line after the last incoming request header. Give this a try and let us know if that works for you.

I have a payload which is in xml format. I created the image as per your steps (see my attached screen shot). But when I try to hit the deployed service, I get the success response even when I didn't add any header values (tested using SOAP ui)  Is this the expected behaviour?What is the real purpose of adding those headers in req file of my RR pair.?

Yes, this is expected behavior.

The VSI does not use the values in the MetaData as part of the signature comparison and matching logic. If you want TargetXSD, TargetServer, and FTLEndpoint to be considered use the RDM DPH, see your prior screenshot, and move or copy those headers to the Argument List. Your screenshot indicates that these fields are moving to themselves.

Action = Move or Copy

Source Type = Meta Data

Source Name = FTLEndpoint, TargetService, TargetXSD

Target Type = Argument

Target Name = FTLEndpoint, TargetService, TargetXSD

After changing the RDM in the attachment, rebuild the service so these headers are part of the VSI's signature list, and give it another try with and without headers. You should see different results.

For clarification, just because TargetXsd is copied from MetaData to the Argument list does not mean that the service is going to apply XSD validation. XSD validation is not automatic.

I tried by moving the three meta data to arguments (see attached). When deploed and tested in SOAP ui I get success response even without headers. My doubt here is .. Will those 3 values be treated as header values? because this stub will be used by some parties and I should get like " if theses are the headers they pass, I should get success response"

What is the match style for the META transaction on this one? Is it signature or operation? 

It will be like, if my taget service is "A' it will hit one service if "B" it will hit another. And I got the solution by adding failure message in meta data.

Hi Johny, I have read the above conversation and this might help me for my upcoming projects. Could you please explain your point "got the solution by adding failure message in meta data."

Hi J_NeSmith,

I had the same query for putting Headers in REST API but there is no seperate option in VSI i can see . Please confirm will adding those headers key/Value pairs manually in metaData will work