(Migrated) AMQP RPC

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

Hello,

I have a simple zato setup and I can call 2 different API’s within zato, now one of my processes calls an api using AMQP, in an RPC style, so my process is the producer that makes the call, waits for the result from the api, then it moves along, when we have to process several items, we use a direct queue and a notification is sent when the batch process is done.

I guess I could achieve the same if I use an http service in zato, but I’m wondering if there is a way to create an AMQP consumer that listens to RPC calls?.

Thnak You.

On 10/08/14 00:29, Ivan Villareal wrote:

I have a simple zato setup and I can call 2 different API’s within zato, now one of my processes calls an api using AMQP, in an RPC style, so my process is the producer that makes the call, waits for the result from the api, then it moves along, when we have to process several items, we use a direct queue and a notification is sent when the batch process is done.

I guess I could achieve the same if I use an http service in zato,
but I’m wondering if there is a way to create an AMQP consumer that listens to RPC calls?.

Hi Ivan,

sorry it took me so long.

Yes, you are right - the same thing, conceptually, can be achieved using
an HTTP channel and HTTP is currently the only means through which your
services can be invoked synchronously.

It is possible for a service to listen for AMQP calls:

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

However, from the external producer’s point of view, it’s a fire and
forget mechanism. They just push messages to an exchange that points to
a queue that you listen on in your Zato AMQP channel and the producers
cannot be delivered a response from that channel. The channel doesn’t
allow for it - that’s how it looks like right now.

Your service would have to use an outgoing AMQP connection to deliver
responses to the external applications.

In other words, it would be the same result but split into distinct
phases and entities - one for accepting requests only and the other for
producing responses only.

Naturally, you’d need a way to correlate responses with requests. This
could be achieved, for instance, using a correlation ID (cid) embedded
in the payload.

So, in pseudo code:

External -> Zato through an AMQP channel:

req = {‘cid’:1234, ‘action’:Create Customer’, ‘cust_name’:‘First name’}

Zato -> External over an outgoing AMQP connection:

resp = {‘cid’:1234, ‘result’:‘OK’}

Now the responses can be correlated with requests and it’s the external
party’s responsibility to make sure they are actually unique, e.g. a
UUID4 will do nicely.

Other than that - if you absolutely need synchronous calls, please use
HTTP rather than AMQP.

On 10/08/14 00:29, Ivan Villareal wrote:

I have a simple zato setup and I can call 2 different API’s within zato, now one of my processes calls an api using AMQP, in an RPC style, so my process is the producer that makes the call, waits for the result from the api, then it moves along, when we have to process several items, we use a direct queue and a notification is sent when the batch process is done.

I guess I could achieve the same if I use an http service in zato,
but I’m wondering if there is a way to create an AMQP consumer that listens to RPC calls?.

Hi Ivan,

sorry it took me so long.

Yes, you are right - the same thing, conceptually, can be achieved using
an HTTP channel and HTTP is currently the only means through which your
services can be invoked synchronously.

It is possible for a service to listen for AMQP calls:

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

However, from the external producer’s point of view, it’s a fire and
forget mechanism. They just push messages to an exchange that points to
a queue that you listen on in your Zato AMQP channel and the producers
cannot be delivered a response from that channel. The channel doesn’t
allow for it - that’s how it looks like right now.

Your service would have to use an outgoing AMQP connection to deliver
responses to the external applications.

In other words, it would be the same result but split into distinct
phases and entities - one for accepting requests only and the other for
producing responses only.

Naturally, you’d need a way to correlate responses with requests. This
could be achieved, for instance, using a correlation ID (cid) embedded
in the payload.

So, in pseudo code:

External -> Zato through an AMQP channel:

req = {‘cid’:1234, ‘action’:Create Customer’, ‘cust_name’:‘First name’}

Zato -> External over an outgoing AMQP connection:

resp = {‘cid’:1234, ‘result’:‘OK’}

Now the responses can be correlated with requests and it’s the external
party’s responsibility to make sure they are actually unique, e.g. a
UUID4 will do nicely.

Other than that - if you absolutely need synchronous calls, please use
HTTP rather than AMQP.