Bij het gebruik van Invantive Cloud (OData) vanuit Azure Data Factory krijg ik een foutmelding:
Failed to create odata connection to RequetsUrl. The metadata document could not be read from the message content. XmlError: Data at the root level is invalid. Line 1, position 12312052. : (1, 12312052) Activity ID: ced4d2f9-11f8-4514-996e-df847209cfb7.
Bestaande pipelines die in het verleden wel hebben gewerkt krijg ik een foutmelding maar ook het maken van een nieuwe pipeline levert een connectie fout op bij het ophalen van de metadata van de OData.
Wat wel is dat de connectie die ik gebruik zowel naar EOL als de Azure SQL database kijkt. Dit heb jij toen geregeld voor mij tijdens de demo. Dit is voor het gebruik met ADF zowieso onnodige ballast aangezien ik huist van EOL naar die betreffende database ga schrijven en de connectie naar Azure SQL is gemaakt in ADF.
M.b.t. incorrecte metadata: normaliter is dat een datafout bij het ophalen, bijvoorbeeld een verlopen abonnement. Maar die zou ook te zien zijn in zowel Systeemberichten als Bridge Online Monitoring.
Wat nog zou kunnen is een bug in een recent toegevoegde optimalisatie. De programmatuur knipt grote datavolumes op in brokken van bijvoorbeeld 10 MB als die opgeslagen wordt in de caches. Op die manier is Invantive Cloud toch in staat om databestanden van 20 GB te verwerken zonder een enorm geheugenbeslag of OutOfMemory errors.
Aangezien iedereen hier last van zou moeten hebben, kan het zitten in een net iets grotere aantal objecten. Dat kan kloppen; er is ook een SQL Server datacontainer gedefinieerd.
Advies 1:
Haal de lijst van tabellen op door aanmelden op https://access-odata.com. Als die werkt, dan klopt de metadata.
De tweede oorzaak kan liggen in Azure. We weten dat in Azure af en toe serieuze crashes optreden bij complexe datasets. Zie bijvoorbeeld
Dit is tot dusver altijd te herkennen geweest aan het succesvol ophalen van de data bij Invantive Cloud en dan 1 tot enkele minuten later crashen van het laadproces.
Advies 2:
Vergelijk de exact tijdstippen van wanneer het verzoek volgens Bridge Online Monitoring beëindigd is en wanneer Azure begon met de verwerking. Als dat meer dan 30 seconden uit elkaar ligt, dan is het een Azure issue.
In beide gevallen is de workaround: haal de ongebruikte datacontainer weg.
Deze workaround is geen structurele oplossing. Daarom zouden we graag weten of het ophalen van de tabellenlijst op https://access-odata.com lukt.
Wat betreft de ongebruikte datacontainer snap ik denk ik niet helemaal wat je bedoelt.
Het lukt al niet (meer) om een connectie te maken vanuit ADF. Connectie wordt niet meer gevalideerd bij het testen. Dus kan ook geen metadata ophalen.
Voor het overige blijkt dat Azure Data Factory en Azure Dataflows blijkbaar momenteel regelmatig crashen bij het ophalen van de metadata als de metadata omvangrijk is. Invantive SQL biedt ruim 1.000 tabellen met honderdduizenden kolommen voor alleen al Exact Online. De omvang hiervan is circa 20 MB en dat lijkt een kritische grens te zijn in Azure Data Factory en Dataflows.
Het is mogelijk om delen van de tabellen achterwege te laten uit de metadata via de driver attributen:
use-rest-api: Whether to include tables from the REST API.
use-xml-api: Whether to include tables from the XML API.
De XML API’s zijn bij verre het meest omvangrijk door de structuur van de XSD.
Als geen XML API-tabellen gebruikt worden, dan is advies om de instelling use-xml-api=false toe te voegen aan de verbindingsspecificatie van de datacontainer. Deze is te vinden onder:
Toevoeging in de verbindingsspecificatie van de datacontrainer (alleen REST API) zorgt er voor dat 90% van de data goed wordt opgehaald. Loop alleen nog tegen issues aan met 2 tabellen.
FinancialTransaction.Transactions: lijkt er op dat deze stuk loopt op een timeout. Telkens na 4:46 geeft deze een error. Er worden 0 records weg geschreven in de destination tabel.
Incremental.TransactionLines: hier worden wel records weg geschreven maar na 14661 records geeft ADF een error.
Lijkt er op dat de grote tabellen nog wel een probleem op leveren.
Bij het laden van FinancialTransaction.Transactions stopt deze na ongeveer 4 min en 46 sec. er worden 0 records verwerkt richting destination en krijg ik de foutmelding:
Failure happened on ‘Source’ side. ‘Type=Microsoft.OData.Core.ODataException,Message=Invalid JSON. More than one value was found at the root of the JSON content. JSON content can only have one value at the root level, which is an array, an object or a primitive value.,Source=Microsoft.OData.Core,’
Gevoelsmatig zeg ik dat het voor ADF te lang duurt voordat er data uit de OData source wordt aangeboden.
Bij het laden van Incremental.TransactionLinesIncremental worden er wel records richting de destination geladen, echter met een foumelding waardoor deze na 14.661 records afbreekt.
Foutmelding:
Failure happened on ‘Source’ side. ‘Type=Microsoft.OData.Core.ODataException,Message=Invalid JSON. More than one value was found at the root of the JSON content. JSON content can only have one value at the root level, which is an array, an object or a primitive value.,Source=Microsoft.OData.Core,’
Dank voor de extra informatie. Het blijkt dat door een recente wijziging de antwoorden die terugkomen uit Invantive Bridge Online soms te veel tekst bevatten. Dit is zichtbaar in dit voorbeeld waarbij boekstukregels opgevraagd worden:
De bovenste regel is een correcte download die NIET uit de OData caches komt. Deze is ruim 26 MB.
De onderste regel komt wel uit de OData caches. Functioneel behelst die dezelfde data, maar na het einde volgen nog bytes totdat het een veelvoud van 10 MB is. Er worden teveel bytes meegestuurd. Vaak blijft het daardoor een geldig bericht, maar soms niet.
Voorheen werd het bestand na versleuteling in een geheel opgeslagen in de OData cache. Alleen doordat de bestanden elk gigabytes groot konden worden bij bijzonder grote tabellen is dit opgeknipt: de OData cache bestanden worden nu opgehakt in 10 MB blokken en bij het terugsturen uit cache weer achterelkaar gezet. Dit achterelkaar levert momenteel een onbetrouwbaar resultaat met soms tekst achter het einde van het bestand.
We hebben op dit moment tenminste drie gebruikers waar dit probleem speelt.
Nu het probleem reproduceerbaar is wordt het verder onderzocht. Het staat bij ons bovenaan de prioriteitenlijst. Zodra er meer nieuws is wordt dit topic bijgewerkt.
