Als ETL tool voor onze Datawarehouse draait Microsoft Azure Data Factory (ADF), waarmee een Exact Online administratie binnenhalen via Invantive Bridge Online op https://bridge-online.cloud.
In ADF bestaat een Copy Data activity o.b.v. een OData connector naar Invantive Bridge Online. Over het algemeen functioneert dit prima, echter de performance van het binnenhalen van bepaalde data, b.v. de Cashflow.Receivables (ca. meerdere tienduizenden rijen), wisselt nogal.
Het ene moment is de job binnen 2 minuten afgerond, terwijl ik een volgende keer tegen timeout grenzen aanloop van 20 minuten. De onderstaande melding verschijnt dan in de output van de ADF job:
ErrorCode=ODataRequestTimeout,
Fail to get response from odata service in a expected time
Is bovenstaande iets wat jullie herkennen, en kunnen jullie aangeven waarmee dit te maken zou kunnen hebben?
Zeg dat er 100.000 Receivables zijn, dan zal dat pakweg 800 seconden duren als de data initieel geladen moet worden en Exact Online niet te zwaar belast is. Problemen in de daadwerkelijke belasting op Exact Online kun je meestal snel zien op de downdetector (meer tips over de Exact Online status op Hoe vraag ik de status van een Exact Online storing op?). Het is niet ongebruikelijk dat het soms twee keer zo lang duurt.
Zodra de gegevens eenmaal binnen zijn, zullen volgens de tijd ingesteld bij de database in Invantive Cloud dezelfde gegevens opnieuw opgeleverd worden en dat gaat met een snelheid tot 500 megabyte/seconde.
Gezien het aantal rijen adviseer ik om een aantal opties te bekijken:
kun je een sterk filterend filter meegeven, bijvoorbeeld AmountDC!=0. Zo uit mijn hoofd maakt dat bij specifiek deze API veel uit omdat ie ook de 0-bedragen blijft aanleveren. Geen idee waarom.
overstappen op de bulk API; die is meestal bij queries op 1 administratie tot 8x sneller.
overstappen op de Exact Online XML versie AROutstandingItems hiervan; die is significant sneller en bevat veel interessate informatie-elementen.
Je kunt zelf in Session I/O scherm in Invantive Cloud zien hoeveel requests het ODataverzoek afvuurt.
Met extra filters lijk ik inderdaad een betere throughput te krijgen. Voorlopig laat ik de Receivables even achterwege, aangezien de ReceivablesList voor nu voor ons afdoende is.
Kun je aangeven hoe lang data bij jullie in de cache blijft bestaan? Stel dat ik maandelijks een full extract van bepaalde tabellen wil doen, en dagelijks een incremental, dan is het natuurlijk niet fijn om bij iedere full weer de volle 800 sec. (zoals in dit voorbeeld) te moeten wachten.
Ik was ervan uitgegaan, dat jullie (bijna) alle EOL data binnenhalen in jullie ‘cache’, en dat wij dan de data van jullie webservices onttrekken. Halen jullie zelf ook de data van Exact binnen op het moment dat ik erom vraag en deze niet in de cache aanwezig is?
Dit kan dus in theorie net zo lang duren, als dat ik zelf de EOL API bevraag?
Kun je aangeven hoe dat dan zit met nog grotere tabellen, zoals b.v. de Transactions? Een full extract hiervan, zal dan nog langer duren verwacht ik. Of komt daar een product als de Replicator om de hoek kijken, als betere oplossing?
De werking van de cache Invantive Bridge Online staat in dit artikel beschreven.
Uitgangspunt van Invantive Bridge is pull: de data wordt opgehaald als ze gevraagd worden. Dit in tegenstelling tot Invantive Data Replicator die alleen pull is vanuit Invantive SQL maar push vanaf de database (SQL Server bijvoorbeeld). Pull werkt in de meeste scenario’s beter omdat je dan meer real-time bent.
Het ophalen duurt in principe net zolang als zelf de API bevragen, met dien verstande dat de caches en Invantive SQL optimalisaties bij bijvoorbeeld een join de looptijd kunnen verkorten. Je kunt aan pre-loading doen - net zoals bijvoorbeeld bij Microsoft IIS - door bijvoorbeeld 's nachts het OData4 request al eens af te vuren.
Als je wilt werken met incremental data, dan hangt de haalbaarheid daarvan af van de tabel/API. Niet elke Exact Online API kan incrementeel data teruggeven. Of op bepaalde velden een filter doorgestuurd wordt naar het achterliggende platform heet “server-side filtering” en is een eigenschap op het veld. Die kun je met F4 (Describe) zien als je de tabelnaam intikt in het Invantive Query Tool.
Deze werkwijze blijkt in praktijk ook goed te werken bij bijvoorbeeld TransactionLinesBulk. Hier komt binnenkort een incrementele versie van (de Sync API’s van Exact Online), maar tot een paar miljoen rijen kun je prima telkens volledig verwerken als maar 1 administratie is.
Het daadwerkelijke gebruik van OData en achterliggend platform kun je ook in Invantive Cloud terugvinden. Voor real-time informatie svp even bellen met support; die kunnen real-time via een monitorscherm alle draaiende queries zien qua voortgang.
De monitoring is beschikbaar gekomen op Invantive Cloud; zie releasebericht voor 30 november 2020. Ook details over het verblijven in cache zijn af te lezen.