(Migrated) Zato as a mock server?

(This message has been automatically imported from the retired mailing list)

Hello,

I’m trying to see if zato would work as a mock server for a hand built ESB,
the main thing I’m trying to do is to record and replay the requests being
done to the external services, but I have some requirements:

The requests should be able to be grouped and identified somehow, for
instance, a special header would identify the user making the request and
the expected response (for instance, user A making the request and
expecting failure because of max calls reached, or user B expecting success)

Any user should be able to edit the response parameters for any stored
stub, so if for instance the service is down for maintenance and you want
to test a call that’s not recorded yet, you can modify an existing one.

Thanks for your help!

as a programmable proxy, I mean, we have a python ESB built from scratch,
we are not using zato anywhere (yet)

so yes, what I want is to catch the responses from the external systems and
replaying them to whoever asks them as many times as needed without calling
the external system all the time.

On Fri, May 29, 2015 at 3:29 PM Dariusz Suchojad dsuch@zato.io wrote:

On 29/05/15 15:12, David De Sousa wrote:

I’m trying to see if zato would work as a mock server for a hand built
ESB,
the main thing I’m trying to do is to record and replay the requests
being
done to the external services, but I have some requirements:

The requests should be able to be grouped and identified somehow, for
instance, a special header would identify the user making the request and
the expected response (for instance, user A making the request and
expecting failure because of max calls reached, or user B expecting
success)

Hi David,

just to confirm, are you thinking of replaying requests from Zato to
external systems or from clients to Zato?

In the scheme below …

Clients -> Zato services -> External systems

… what you are interested in is catching responses from external
systems first time they are produced and replaying them later on, is
that correct?

I’m asking because I’m not sure what sort of job Zato services will be
doing in your case. Are you planning on using Zato as an integration
platform or mostly thinking of using it is as a sort of a programmable
proxy?


Dariusz Suchojad

https://zato.io
ESB, SOA, REST, APIs and Cloud Integrations in Python

since this “proxy” will be used for testing purposes only, it would store
everything, and it could have a special header to instruct the proxy to
make the real call even if there’s something already recorded

On Fri, May 29, 2015 at 3:38 PM Dariusz Suchojad dsuch@zato.io wrote:

On 29/05/15 15:32, David De Sousa wrote:

so yes, what I want is to catch the responses from the external systems
and
replaying them to whoever asks them as many times as needed without
calling
the external system all the time.

Ok, what will be the difference, in terms of payload and headers,
between actual initial requests and ones made by developers during tests
or development (say)?

Will there be any flag to learn from indicating that this is a real
request and this one should be returned from cache?


Dariusz Suchojad

https://zato.io
ESB, SOA, REST, APIs and Cloud Integrations in Python

On 29/05/15 15:12, David De Sousa wrote:

I’m trying to see if zato would work as a mock server for a hand built ESB,
the main thing I’m trying to do is to record and replay the requests being
done to the external services, but I have some requirements:

The requests should be able to be grouped and identified somehow, for
instance, a special header would identify the user making the request and
the expected response (for instance, user A making the request and
expecting failure because of max calls reached, or user B expecting success)

Hi David,

just to confirm, are you thinking of replaying requests from Zato to
external systems or from clients to Zato?

In the scheme below …

Clients -> Zato services -> External systems

… what you are interested in is catching responses from external
systems first time they are produced and replaying them later on, is
that correct?

I’m asking because I’m not sure what sort of job Zato services will be
doing in your case. Are you planning on using Zato as an integration
platform or mostly thinking of using it is as a sort of a programmable
proxy?

On 29/05/15 15:32, David De Sousa wrote:

so yes, what I want is to catch the responses from the external systems and
replaying them to whoever asks them as many times as needed without calling
the external system all the time.

Ok, what will be the difference, in terms of payload and headers,
between actual initial requests and ones made by developers during tests
or development (say)?

Will there be any flag to learn from indicating that this is a real
request and this one should be returned from cache?

On 29/05/15 15:39, David De Sousa wrote:

since this “proxy” will be used for testing purposes only, it would store
everything, and it could have a special header to instruct the proxy to
make the real call even if there’s something already recorded

Ok, so it sounds easily doable, it just boils down to a couple of
if/else blocks.

  1. Upon receiving a request, check if it contains a force_ext_call
    header. If it does, invoke the external resource.

  2. If it doesn’t, build an sha256 sum of self.request.raw_request +
    self.wsgi_environ headers.

  3. Make the result a key into a dictionary of responses stored in Redis
    (self.kvdb)

  4. Check if the key exists or attempt to read a value for that key - if
    there is a response, it means we can return it. If there isn’t, call the
    external system, cache response and proceed as though it was already
    there previously.
    https://zato.io/docs/progguide/html.html
    You’d need to give some thought to how to design the Redis database
    seeing as you will have multiple users each with their own requirements.

You’d also need some sort of GUI so that users were able to update their
already collected responses.

I believe everything you need is under these links: tutorial, a few
REST-related niceties + info on how to produce HTML using Django templates.

https://zato.io/docs/tutorial/01.html

https://zato.io/docs/progguide/rest/services.html
https://zato.io/docs/progguide/rest/channels.html
https://zato.io/docs/progguide/rest/outconns.html
https://zato.io/docs/progguide/rest/json-adapter.html

https://zato.io/docs/progguide/html.html

The tutorial will cover a real lot of what you need. The main part of
this application will be the Redis cache so this is what I’d focus on in
particular when thinking things out initially.