De oorzaak van de foutmelding itgenodr017 is inmiddels bekend.
Breaking change geen rijen / 403
Sinds december 2020 zijn door Exact een aantal breaking changes doorgevoerd zonder vooraankondiging. De software van Invantive is hierop aangepast, maar dit is helaas soms ook erg hectisch gegaan om downtime te beperken.
Een van de breaking changes was het veranderen van het gedrag van de REST API als een gebruiker geen rechten heeft in Exact Online op de gegevens. Dat kan zijn omdat de module niet gelicentieerd is (bijvoorbeeld uitlezen lijst van abonnementen in een Exact Online Salaris-omgeving) of omdat de hoofdgebruiker deze rechten niet ter beschikking heeft gesteld (toegang grootboek is een veelvoorkomende beperking).
De volgende beperking is in mei 2021 doorgevoerd:
You may have noticed that API errors were returning an empty list for users without rights or who were unauthorized. We are happy to announce that we are fixing that, and that they’ll be implemented on 1 July.
From 1 July, the correct status code will appear for authentication, rights, or license issues. Only if no records are found will you see an empty list. Here’s an overview of the fixed response codes:
- Not authenticated – 401
- No rights – 403
- Feature not available in license – 403
- No records found – empty list
This change also conforms to the HTTP standard status code, both conforming to standards and tightening security.
Een verdere toelichting is te vinden op Forbidden - User division is not within division scope (Itgeneor228 / itgenoda060).
Bestaande programmatuur op de REST API’s ging er van uit dat oorspronkelijke gedrag van 0 rijen teruggeven behouden blijft. Nog sterker, de XML API’s gaven en geven wel een 403 foutmelding. Dit is instelbaar via ignore-http-403-errors, die tegenwoordig standaard op true staat voor de REST API’s, zodat de 403 foutmeldingen onderdrukt worden. Vooral onervaren Power BI gebruikers hadden veel moeite met begrijpen van de foutmeldingen in de XML API-gebaseerde tabellen.
De formele route om dit 403-probleem op te lossen was om vooraf telkens om per administratie en per tabel op XML en REST te vragen aan de Exact Online API of de gebruiker rechten heeft via een API. Deze API bleek nog niet opgewassen tegen serieus productiegebruik. In mei is toen de keuze gemaakt om de 403-foutmeldingen te laten voor wat ze zijn. Niet deftig, maar het realistisch best haalbare zonder gebruikers te frustreren.
Test, test, test en de itgenodr017 foutmelding
Het inschakelen van de per 1 juli aangekondigde wijzigingen verloopt volgens een niet-bekende planning. Het limiteren van het aantal errors (zoals 403) zou 5 juli wereldwijd geactiveerd zijn en 12 juli verbeterd. In het kader van een analyse is onderzocht hoe de limieten overschreden kunnen worden zodat de Invantive SQL-engine een zo optimaal mogelijk gedrag kan vertonen.
Het overschrijden bleek niet te lukken; mogelijkerwijs zijn de limieten niet doorgevoerd of werken ze anders dan gepland.
Echter, doordat de SQL-engine aangepast was om dergelijk relatief low-level fouten af te vangen en door te geven is door Invantive een bug geintroduceerd in het cachemechanisme. Deze bug treedt alleen op voor gegevens op specifieke administraties en tabellen waar de gebruiker geen rechten op heeft. Feitelijk wordt een Exact Online HTTP 403-foutmelding gecached inclusief de daarbijhorende JSON. Het omzetten bij een tweede aanroep van dezelfde administratie en tabel door een gebruiker zonder rechten zal proberen de JSON als een HTTP 200-melding (“OK”) te behandelen en leidt tot de geschetste foutcode itgenodr017.
De analyse was bewerkelijk omdat relevante achtergrondinformatie verdween gedurende de foutafhandeling. Dit is inmiddels verbeterd zodat een analyse sneller tot resultaten leidt.
De storing duurde relatief lang omdat de testcases een Exact Online test-omgeving gebruiken waar de gebruiker relatief veel rechten heeft, zodat alle API’s getest kunnen worden op correct gedrag. De API-testcases focussen beduidend minder op incorrect gedrag.
In de volgende release zal nogmaals geprobeerd worden deze wijziging te verwerken, maar dan zonder de gevolgschade.