(Migrated) Ensuring that an aoutgoing job is being done

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

In the solutioon we consider using Zato for, Zato should perform certain outgoing jobs every night using SOAP protocol. This can, of course, be configured with the scheduler.

On of our concerns is: what if the scheduled job for some reason is not done correctly, for instance because the receiving service is not avaliable? Will we have to program all of the logic for ensuring the jobs are done ourselves, or does Zato provide a mechanism for this?

Regards,

Finn Gruwier Larsen

Forbrugerrådet Tænk er en uafhængig medlemsorganisation, der arbejder for et Danmark, hvor alle forbrugere kan træffe et trygt valg.
Få nyheder, informationer om test, tilbud og gode råd 1-2 gange om ugen. Tilmeld dig vores nyhedsbreve på taenk.dk/nyhedsbrev

On 12/18/2013 10:46 PM, Finn Gruwier Larsen wrote:

On of our concerns is: what if the scheduled job for some reason is not done correctly, for instance because the
receiving service is not avaliable? Will we have to program all of the logic for ensuring the
jobs are done ourselves, or does Zato provide a mechanism for this?

Hi Finn,

as of now it is best to use the invoke/retry pattern, this is part of
zato-labs but will be included in 1.2.

https://zato.io/blog/posts/invoke-retry-in-zato-11.html

This lets you wait until a service accessing a resource is available a
configured number of times, either in a blocking or manner or
asynchronously. You can even have both - first try blocks and if it
fails repeats are asynchronous.

In this scenario, your scheduler-invoked service would invoke another
one using invoke/retry and this other one would access the resource.

Do you think that will answer your need?

On 12/18/2013 10:46 PM, Finn Gruwier Larsen wrote:

On of our concerns is: what if the scheduled job for some reason is not done correctly, for instance because the
receiving service is not avaliable? Will we have to program all of the logic for ensuring the
jobs are done ourselves, or does Zato provide a mechanism for this?

Hi Finn,

as of now it is best to use the invoke/retry pattern, this is part of
zato-labs but will be included in 1.2.

https://zato.io/blog/posts/invoke-retry-in-zato-11.html

This lets you wait until a service accessing a resource is available a
configured number of times, either in a blocking or manner or
asynchronously. You can even have both - first try blocks and if it
fails repeats are asynchronous.

In this scenario, your scheduler-invoked service would invoke another
one using invoke/retry and this other one would access the resource.

Do you think that will answer your need?

Hi Dariusz,

It sounds like the invoke/retry pattern is exactly what we need.

When do you think the 1.2 version will be released? We plan to put the solution online 1. March 2014.

Finn Gruwier Larsen

On 12/19/2013 10:49 AM, Finn Gruwier Larsen wrote:

It sounds like the invoke/retry pattern is exactly what we need.

OK, great!

When do you think the 1.2 version will be released? We plan to put the solution online 1. March 2014.

This is the list of open tickets that are slated for delivery in 1.2

I can’t see getting it done in less than 50-70 man-days so this looks
like April-June most likely for the release of 1.2.

All the development happens in feature branches so you are safe to use
git master.

In fact, there’s a constant activity in git and in recent weeks in the
area of SimpleIO in particular. Even more will be done with SIO in
upcoming weeks - more data types, including Dict, List, ListOfDicts and
Nested types.

This will one to create quite advanced documents in addition to what is
possible now with automatic serialization to JSON/XML/SOAP.

So when you’re building a completely new solution that will be released
around 1.2 anyway you may want to have a look at it.