The routing option is too limited to be useable today.
At my current client we need the option to route certrain ranges to the real back end services, or the option to do so via scripting (return route instead of return template).
We have specific ranges of easily identifiable Virtual Customers, those should return one of our templates while real customers should return the real service response.
Unfortunately the feature added in Version 1.8 is not what my customer needs. (or at least absolutely not userfriendly).
I'm very disappointed to see the conditional routing being a separate script.
In the case described above, I have all the scripts already in the Dispatch section, there I have existing code that knows when to route to the real back end and when not to. (based on the technical ID)
I just need to be able to route as if it were a normal template.
I'm not going to use this feature as it is implemented today since I would have to duplicate most of the code (and then maintain the duplication as well)...
Please fix this...
Hi JeroenVdb and LoundesM,
Thanks again for explaining the need and scenarios. We really appreciate it!
Good news is we have already added groovy scripting support for routing, which will be coming in the next version.
Regards,
Shadid Chowdhury
SmartBear Sweden.
Hi Shadid, LoundesM
That is exactly what my client needs.
Their need isn't based on wanting to limit the traffic.
We indeed want to be able to route depening on values in the incoming request. The example LoundesM provided is not very far from our case.
We use customernumbers, ipadresses, macadresses which are translated to a technical ID via groovy script.
The technical ID is then used to return a specific template. Based on the value of this technical ID we can determine if our customer is "real" or "virtual" (for example: if technicalID > 1 000 000 return real else return virtual)
Preferably we would control this via groovy script as this would allow us the most precise control.
There are a few reasons for our need:
- Multiple APIs controlled by both internal and external parties on sometimes unstable environments
- Multiple independent testers at various different test levels
- Test automation of the GUI application using our VirtServer
- Developers of either the GUI application or the service layer (composite API) want it configured depending on their current development phase.
So at any given time different teams want the same GUI application or composite API configured to different endpoints which isn't feasible.
This option would help with the acceptance of our VirtServer setup tremendously.
Hi guys,
Thanks for the feedback!
There is a feature that sounds very much like what you're asking for pretty high up in our backlog, so I hope it will be added to the product before long.
Kind regards,
Manne, Ready! API Developer
My interpretation of Jeroen's original request would be something like this (speak up if its wrong :smileywink:)
with routing enabled at present a request is either served by the virt or the routed service based upon the operation (get, put etc)
for any given operation what if we want to limit some traffic to use the virt and some to use the actual service
i.e. we have some external people doing some testing and we're providing a virt for them to use, however some of our internal team are also using the virt and we want to expose them to some of the actual service functionality as becomes available to test before letting the external party also use that
if there was an input field with a year value for example, we could say to the external party enter the year value in the range 2011 - 2013, in this case they would all be served the virt response as per the standard dispatch rules as if routing was disabled
for the same request our internal testers used a range of 2014 - 2017, in this case the routing would kick in and they would be served the actual response from the service as opposed to the virt response
regards
Mike
Hi JeroenVdb,
Right now routing can be configured on virt level or REST Action(method + resource)/ WSDL operation level.
As I understood you want more control on the action/operation level. So for each action/operation you can configure routing depending on values in incoming request. Is that correct assumption?
Regards,
Shadid Chowdhury
SmartBear Sweden.
There is pass through capability although I've not used that yet but the idea of selective pass through could be very useful
