Service Virtualization

We have created Virtual Services(VS) for a REST services based application .Most of the calls use HTTP POST method The Real Service and Virtual Services are consumed by a Mobile application.

Recently the Mobile application enabled new Browser for their app which uses CORS (Cross Origin Resource Sharing) . This is causing a preflight transaction to be sent out first  to the Virtual Service with HTTP OPTIONS method .  This causes the Virtual services to fail as CORS is not enalbled on Devtest . Only if this handled , the application can send the POST call to the virtual Service . I raised a ticket with CA support and got to know that Devtest does not support CORS functionality at the moment .As a workaround , please let me know if there is a way to handle incoming requests with OPTIONS as well as POST verbs for the same virtual Service . Any other suggestions are welcome.

As a test, try the following and let us know if you are successful:

In the VSM, ensure that your REST protocol DPH allows a URI rule of OPTIONS /<theuri>/<string> where <theuri>/<string> matches your needed URI. 

You will need one OPTIONS for each URI that needs to be "pre-flighted". This varies for example GET requests may not need to make the OPTIONS call.

In the VSI for each OPTIONS REST DPH rule, add a transaction to support the OPTIONS call

OPTIONS /<theuri>/<string>

Since there are no arguments, you might get away with setting the match style to Operation.

I cannot say which response headers are required in your installation, but, in the response META data, add the necessary headers that the Live System echos with the options that are available. 

For example,

Allow=OPTIONS,POST,GET

Access-Control-Allow-Origin=*

 Accept, Accept-Language, Content-Type, Last-Event-Id, etc.

Also, you may need to remove headers that are not considered safe by your implementation.

Give this a try and report back on what you find out.  This will be helpful to others dealing with CORS issues.

Hi Joel,

Thanks for your help. I followed the above steps in my virtual Services . However, I am still facing the same issue. 

Got the META data headers from my application team, added those to my VSI for the OPTIONS call . I tested the OPTIONS call using SOAPUi and works fine. 

But when the services are invoked from the application, it does not pass through the Pre-flight transaction and hence the POST calls are not invoked . 

Any thoughts ? 

Can you tell if the application is actually making the pre-flight calls?

I gather by your statement that you don't see the OPTIONS service call hit the VSE. Can you isolate in the application that the pre-flight call is being made but is rejecting for some reason?

Hi Joel, yes, the application is making the PreFlight calls as I could see the OPTIONS call hitting the virtual Service . The issue I am having is after the OPTIONS call , there is no POST call hitting the VS. I am not sure if the response of the OPTIONS call was sent out from VS to the application , so that the POST call could be triggered.

We will need to plug in a network sniffer such as Wireshark or tcpdump to see the flow between the endpoints. If the OPTIONS response meta data header does not contain the proper response information, the client might not consider the pre-flight call as successful. The CORS processing on the client side app might not recognize all of the response info and prevent the call.  Not sure...

Update 30 Mar:

Wireshark capture shows the pre-flight OPTIONS call enter and VS response. Not seeing subsequent GET / POST calls. Reviewing the OPTIONS response Meta Data to ensure that all settings match expectations of SUT.