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: FTLEndpointValue: ep-TPIntegrationASServices_receive
Target service name:Name: TargetServiceValue: NotifyBillingAccountCreation
Target XSD name:Name: TargetXSDValue: 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-meta.properties will contain something like:
Hope this helps..
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/jsonConnection: keep-aliveFTLEndpoint=ep-TPIntegrationASServices_receiveTargetService=NotifyBillingAccountCreationTargetXSD=CustomerAccount.xsd
<BLANK LINE HERE>
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."
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