An important update to the Ofsys infrastructure will occur this weekend - April 28, 2013.
START: Sunday, April 28, 2013 at 07:00 (Moscow time)
END: Sunday, April 28, 2013 at 14:00 (Moscow time)
During this window, an expected downtime period of 120 minutes will occur. Contingency plans include a possible extension of this window up to 7 hours of downtime.
During this procedure, all Ofsys services will be offline.
We recommend that you avoid planning work during this period and suggest that you also avoid launching campaigns that would result in a high traffic volume towards Ofsys services.
IMPORTANT ADDITIONAL NOTES :
The stop will be complete, including API calls.
No servers will be able to receive any API call, so they will not be "replayed" later from our side.
We plan a short time of "no service", we expect something between 15 to 30 mn unofficially but officially we announce more as there might be non-expected consequences due to the complexity of the task. Basically, we are finalizing the complete migration of all our DBs towards a high-end infrastructure equipment and are rearranging/upgrading our production network.
So during the stop, transactional items will not be treated and we hope our clients have put in place resuming processes on their side in case of server breakdowns / internet fail-outs / execution failures, etc...
As an advice, a "fast and rather reliable" method to put in place by our clients would be to simply store their calls into a DB and to have them executed in sequence by an automated task. This will allow the calling process to continue it's job in case of failure or delays (when its work doesn't depend on the response). Other more sophisticated alternatives exist : Entreprise Bus which role is to take each specific calls individually and follow-up with it until success even if it takes hours. It's more complex to put in place but also more reliable.
Again, maintenances that cause full interruptions are rare, they happen once or twice each year.
But failures are more difficult to consider when we consider all different sources of possible failures which neither us or our clients are responsible for : routing problems, internet communications, etc...)