Call service with optional fallback server
See original GitHub issueWhen chaining service calls, whereby the input of a service is taken from the response of a previous service, any failed call could result in a failing scenario.
Examples:
- the service is not implemented yet but there is mock data available
- the service is unavailable (server is down, too much load)
- the service data infrequently changes (refdata, codes, etc.)
- the service is working but is either very slow intermittently timesout
- the service is not critical for the whole senario
In some cases it would be very helpful if we could make requests with an option to fallback to another server (typically a mock server) if an error occurs
// very quick example
karate-config.js:
var fallbackEnabled = true // default is false
var fallbackServerUrlBase = 'http://localhost:3000'
var fallbackIfStatus = [ 5** ] // all server errors
var fallbackIfStatus = [ 500, 501, 502, 503, 504 ] // specific server errors
Test.senario:
When method post with fallback // uses config fallbackIfStatus
When method post with fallback for [500] // override config fallbackIfStatus
When method post with fallback for fallbackIfStatus // fallbackIfStatus var
Reporting:
The step could be marked as a failure but allowed to continue and highlighted that it was a fallback response.
or marked as passed but highlighted that it was a fallback response.
I would be more than willing to implement this feature if it is desired and when the configurations and call specifics are finalized-
I understand that I could can accomplish the results with JavaScript. Just curious what you think about such a feature built in
Issue Analytics
- State:
- Created 6 years ago
- Comments:13 (7 by maintainers)
Top GitHub Comments
Yes that’s it - Karate does clear the responseStatus !
Well, looks like you are doing some pretty advanced stuff with Karate. Let me know if something can be added to Karate to make things easier.
The solution here to me sounds like you should return the responseStatus from the target feature, actually it would be present by default in the JSON returned from the
call
. If you just grab and save it somewhere, won’t you be able to use it instead of doingkarate.get()
? Something like this:closing due to inactivity - this is anyway a planned roadmap item - e.g. service virtualization.
you can achieve this in a custom way as of today by following the same approach as the karate-mock-servlet. the over-ridable method callback hands you the URL