Itgenclr083 melding bij start Exact Online replicatie proces

Bij het repliceren van Exact Online krijg ik een foutmelding direct bij het starten omstreeks 03:00 (UTC):

itgenclr083: The database '...' could not be opened

en daarna:

The remote server returned an error: (504) Gateway Timeout.
System.Net.WebException
ValidationException
   at System.Net.HttpWebRequest.GetResponse()
   at Invantive.Data.Providers.OData.ODataProvider.DoRequest
...

Hoe kan ik desondanks de replicatie succesvol laten verlopen?

Exact Online is gedurende de nacht regelmatig down. Dit kan varieren van enkele minuten tot uren. Gedurende deze downtijd, inclusief enkele minuten aanloop er naar toe, kan de software foutmeldingen terugkrijgen van Exact Online.

Helaas heeft Exact Online geen heldere (zwart/witte) switch tussen AAN en UIT. Ik zou het eerder vergelijken met de stervende zwaan in eender welke uitvoering. Denk aan:

  • net errorscherm in HTML terwijl JSON verwacht wordt;
  • een JSON-encapsulated error ergens in de datastream waar een getal of tekst had moeten staan;
  • een HTTP status die begint met een 5 zoals 503 of 504.

Invantive SQL zal automatisch via een aantal pogingen proberen de verbinding weer te herstellen. Die pogingen staan standaard enigszins zinvol ingesteld met connectorattribuutinstellingen. Zoek naar ‘download-’ in de documentatie.

Dat automatisch herstellen werkt redelijk. Het is erg lastig om de “stervende zwaan” te simuleren, dus we zoeken post-mortem naar oorzaken van storingen en proberen het mechanisme te verfijnen zonder aan data-integriteit in te leveren; een insert zal zelden tot nooit opnieuw geprobeerd worden zonder programmatische aanpak want dat zou kunnen leiden tot duplicaten en verlaagde integriteit van de administratie.

Invantive Data Replicator leest alleen data vanuit Exact Online. Mocht de verbinding onverhoopt wegvallen, dan kun je altijd overwegen de laadactie enkele uren later nogmaals te draaien. Aangezien de houdbaarheidsdatum per tabelpartitie vastgehouden wordt, zal dit amper leiden tot extra API calls: alle reeds bijgewerkte tabelpartities worden overgeslagen als zijnde “voldoende vers”.