Custom view uit Startup SQL niet zichtbaar in Bridge Online OData4 (Easyflex)

Vragen (alle)
,
1

In een database van Easyflex heb ik in Startup SQL:

SQL:

create or replace view LjTestW1
as
select * from DataService.Flexwerker.Loonjournaal@efx(jaar => 2026, week => 1)

Hiermee probeer ik het loonjournaal vanuit Easyflex van een periode op te halen via een OData-feed in Excel. In de Universal SQL editor werkt deze query, helaas verschijnt deze niet in de OData-feed. Ook niet nadat cache is geleegd. Heeft iemand toevallig tips?

2

De custom views uit de Startup SQL worden gecached in zowel het EDM-datamodel als het proces (als verbinding niet langdurig onderbroken is geweest). Vooral Invantive Bridge Online en Invantive App Online cachen bijzonder agressief, terwijl de Invantive Cloud-site zelf dat veel beperkter doet en meer controle over de sessies biedt via de knop “Verbinding verbreken” in de UniversalSQL-editor.

Het legen van de cache verwijdert het EDM-datamodel, en verwijdert als goed is ook de custom view definitie uit de sessie.

Vergelijkbare problemen zijn onder andere:

Soms lijkt cache reset te helpen en uiteindelijk wordt view altijd zichtbaar.

Feitelijk lijkt sprake van een bug; het in productie nemen van een view voor Bridge Online en App Online mag niet zo complex en bewerkelijk zijn.

Tot op heden is het niet gelukt om dit probleem reproduceerbaar te krijgen, waardoor een oplossing is uitgebleven.

Inmiddels is de Big Data JSON-driver beschikbaar gekomen binnen Invantive UniversalSQL. Deze faciliteert, zoals Parquet, het snel queryen van datasets van terabytes aan logbestanden.

We zullen hiermee een analyse maken over een langere historie van de betrokken gebruiker in een poging om de oorzaak te achterhalen. Mocht die gevonden worden, dan zal een bugfix gemaakt worden voor release 26.0 en de aanstaande release 27.0.

3

Op welke server(s) heeft u de cache geleegd?

Het legen dient plaats te vinden op de server genoemd in de URL waarmee de data opgehaald wordt.

4

Een view uit de startup SQL ontbrak in de OData4-feed, omdat Invantive Bridge Online een eerder opgeslagen datamodel bleef gebruiken. Het legen van de cache in Invantive Cloud raakt dat datamodel niet.

Samengesteld met hulp van AI.

Inhoud Trace

De trace beslaat 22 tot en met 24 september 2026. Alle tijden zijn in UTC.

Tijdstip (UTC) Gebeurtenis
23-09 12:04 De database wordt aangemaakt in Invantive Cloud, zonder startup SQL.
23-09 12:05 Het eerste OData4-verzoek vanuit Power BI. Bridge Online bouwt het datamodel met 197 tabellen en slaat het op schijf op. Het opgeslagen model blijft zeven dagen geldig.
23-09 14:26 De startup SQL krijgt een view op het loonjournaal.
23-09 14:31 tot 14:47 Vijf sessies vanuit Power BI. In elke sessie voert Bridge Online de startup SQL zonder fout uit. Het datamodel komt echter uit de schijfcache: 197 Easyflex-tabellen, zonder de view.
24-09 08:39 Nog een sessie, hetzelfde beeld.
24-09 08:46 De cache wordt geleegd in Invantive Cloud.
24-09 09:00 en 09:03 Twee sessies, hetzelfde beeld.
24-09 09:06 De startup SQL krijgt een view op DataService.Flexwerker.Journaalposten. Bridge Online meldt terecht een fout: die tabel vraagt waarden voor de parameters jaar en week (itgenboe074).
24-09 09:09 De startup SQL krijgt de view uit de vraag. Zes seconden later wordt de cache opnieuw geleegd in Invantive Cloud.
24-09 09:10 en 09:24 Twee sessies. De startup SQL maakt de view zonder fout aan. Het datamodel komt weer uit de schijfcache, met 197 tabellen.

Na de eerste wijziging van de Startup SQL werkten dus tien sessies met het oude datamodel.

Oorzaak

Bij het begin van elke sessie voert Invantive Bridge Online de Startup SQL uit. De view bestaat daarna in die sessie. Daarom werkt een query op de view in de SQL-editor van Invantive Cloud wel.

De lijst met tabellen van de OData4-feed komt uit een aparte cache: het datamodel achter $metadata. Invantive Bridge Online bewaart dat datamodel per gebruiker en per database versleuteld op schijf. De uneieke sleutel van die cache bevat alleen de database en niet de Startup SQL. Na een wijziging van de Startup SQL bleef het oude datamodel daarom in gebruik, tot die na zeven dagen zou verlopen.

Het ontwerp hield hier gedeeltelijk rekening mee. Een datamodel met views uit de startup SQL slaat Bridge Online bewust niet op, omdat zulke views kunnen veranderen. Een datamodel dat is opgeslagen vóórdat er een view was, werd bij het lezen echter niet gecontroleerd. Die situatie deed zich hier voor: het model van 23 september 12:05 is ouder dan de eerste custom view.

Legen van de cache hielp niet

Invantive Cloud en Bridge Online hebben elk een eigen menukeuze “Cache resetten”. Elke keuze leegt alleen de caches van het eigen product, en de twee producten draaien op verschillende servers. De trace toont twee keer een reset op Invantive Cloud. Die reset wist de caches van Invantive Cloud, maar niet die van Bridge Online. Een reset in Bridge Online zelf komt in de trace niet voor.

Bericht 2 noemt dat het legen van de cache het datamodel verwijdert. Dat klopt voor “Cache resetten” in Bridge Online, niet voor dezelfde keuze in Invantive Cloud.

Verbeteringen

De volgende verbeteringen zijn uitgevoerd:

  • Bridge Online bewaart bij het datamodel een vingerafdruk van de databasedefinitie. Die bestaat uit de verschillende Startup SQL’s en uit de datacontainers: alias, connector en de keuze voor gepartitioneerde tabellen. Wachtwoorden en tokens horen er niet bij, omdat die vernieuwen zonder dat de tabellen veranderen.
  • Als de vingerafdruk afwijkt, bouwt Invantive Bridge Online het datamodel opnieuw op.
  • Dezelfde vingerafdruk is onderdeel van de sleutel van de responscache. Startup SQL kan ook andere partities selecteren. Na een wijziging levert de responscache daarom geen antwoord meer dat onder de oude definitie is berekend.
  • Een lopende sessie houdt de definitie waarmee de sessie is geopend. Een sessie eindigt uiterlijk tien minuten na het laatste verzoek. Zo blijven de antwoorden binnen één sessie onderling gelijk.
  • Een database die alleen uit de responscache levert in de calamiteitenmodus, houdt het opgeslagen datamodel en de opgeslagen antwoorden. Die instelling is juist bedoeld om uitsluitend uit de cache te leveren.
  • Invantive MCP Server voor AI (zoals Claude) gebruikt hetzelfde datamodel en krijgt dezelfde correctie.

Beschikbaarheid

De verbeteringen zijn beschikbaar vanaf release 26.0.332 en in de volgende release 27.0.