Problemen met ophalen en inladen data tabel: "FixedHourComponents@nms"

Vragen
, ,
1

Ik ondervind problemen bij het ophalen en inladen van de Nmbrs-datatabel FixedHourComponents@nms in Power BI.

Wanneer ik deze tabel selecteer om toe te voegen aan de gegevensstroom, blijft de voorevaluatie oneindig laden zonder dat er data wordt weergegeven. Als ik vervolgens op ‘Gegevens transformeren’ klik, probeert Power BI de tabel tien minuten in te laden, waarna de melding “Evaluatie is geannuleerd” verschijnt.

image
image1378×1041 26.8 KB

Bij het opslaan en sluiten van de query’s blijft Power BI soms lang hangen op “Query’s valideren”, terwijl de validatie andere keren wel succesvol wordt afgerond. Zodra de tabel eenmaal is toegevoegd aan de gegevensstroom, treedt er echter steeds een foutmelding op bij een geplande of automatische datarefresh.

image
image2778×302 35.6 KB

Wanneer ik de tabel verwijder uit de gegevensstroom, verloopt de datarefresh wél probleemloos.

Wat kan ik doen om te achterhalen of op te lossen waarom juist de tabel FixedHourComponents@nms niet succesvol kan worden ingeladen?

2

Aanvullen informatie

Is het mogelijk om een (geanonimiseerde) schermafdruk van de details van het verzoek in Invantive Bridge Online Monitoring toe te voegen zoals beschreven in Meer inzicht met nieuwe Bridge Online Monitoring?

De details vindt u door te klikken op het downloadverzoek welke het onderwerp van dit onderwerp representeert.

Het downloadverzoek heeft meestal een SQL-statement waarin de tabelnaam zichtbaar is.

Gelieve tenminste de volgende gegevens zichtbaar te laten van beide kolommen:

  • de titelbalk met de request ID,
  • de statuscode, netwerkgrootte, pad en tijdstippen in de linkerkolom,
  • de foutcode en foutmelding helemaal onderaan in de linkerkolom,
  • de gehele rechterkolom inclusief het SQL statement, tabelnaam en parameterwaardes.

Bijvoorbeeld:

image
image1474×640 49.6 KB

Controleer juiste server en gebruiker

Controleer zorgvuldig dat u zich aanmeldt op de Bridge Online-website die ook gebruikt wordt vanuit Power BI en met dezelfde gebruikersnaam. U ziet alleen de verzoeken van de Invantive Cloud-gebruiker waarmee u zich aanmeldt op de website.

Er zijn vier servers in gebruik:

  • bridge-online.cloud
  • app-online.cloud
  • bridge-online.invantive.com
  • app-online.invantive.com

De gebruikte server ziet u in uw script of broncode van rapportage.

Controleer juiste aanvraag en details

Zorg ervoor dat u het verzoek eerst selecteert om de details weer te geven. Er hoort maar één verzoek zichtbaar zijn in de schermafbeelding.

Controleer ook zorgvuldig of het verzoek een pad heeft met odata4 of apps. Verzoeken met andere paden zijn over het algemeen niet relevant voor dit doel.

Foutmelding en tips per e-mail

Daarnaast zal de Invantive Cloud-gebruiker die de foutmelding heeft op zijn e-mailadres veelal een e-mail ontvangen met een foutmelding en tips als er sprake is van een foutmelding in Power BI, Power Query, Azure Data Factory, Qlik of Tableau.

Advies is om de spam van de betrokken gebruiker te controleren op dergelijke e-mails verzonden vanaf support@invantive.com.

3

Goedemorgen,

Excuses voor mijn verlate antwoord.

Ik had de FixedHoursComponents tabel losgekoppeld van de gegevensstroom, doordat het verversen van de data hierdoor continue op foutmeldingen liep. Het is mij in de tussentijd niet meer gelukt om deze te koppelen, doordat hij vast blijft hangen op “Query’s valideren”.

image
image500×602 30 KB

Daarnaast lopen we ook tegen het probleem dat die nu foutmeldingen geeft bij het verversen van de data zonder de FixedHoursComponents-tabel. Hij lijkt hierbij steeds vast te lopen op de VariableHoursComponents, terwijl de gegevensverversingen eerst succesvol verliepen. Hierbij is het ook zo dat de geplande vernieuwingen continue op een foutmelding liepen, waarbij de handmatig gestarte vernieuwingen wel succesvol gingen. Nu is het echter zo dat beide op een foutmelding lopen.

image
image1442×462 11.3 KB

image
image1463×378 9.33 KB

Onderstaande screenshot komt uit de Monitoring - Bridge Online:

image
image3171×460 42 KB

Hierin staat onder uitzonderingen het volgende: “de gegevensdownload werd geannuleerd na ruim 3 uur, waarschijnlijk door de gebruiker”. Deze download is echter niet door ons geannuleerd, deze is gestart door de geplande vernieuwing, maar in het proces fout gelopen.

4

Advies is om van de drie rode regels de request ID toe te voegen. Die kunt u zien in de titel van de details, zichtbaar als u ergens in de regel klikt (zie ook afbeeldingg bij Problemen met ophalen en inladen data tabel: "FixedHourComponents@nms" - 2 van forums).

Voor delegatie vindt u de stappen beschreven in:

5

Dank voor uw antwoord.

Als ik nu kijk in de monitoring zijn deze drie regels niet meer te zien; er zijn enkel nog monitoringsregels te zien van vandaag. Hierdoor is het voor ons niet mogelijk om de IDs op te zoeken en toe te sturen.

Het is ons wel gelukt om de delegatie toe te voegen, als het goed is heeft u hierover een mail ontvangen.

6

Invantive Cloud

Invantive Cloud draait sinds enkele weken op release 25.0.

De volgende query is uitgevoerd op Invantive Cloud:

select * 
from   FixedHourComponents@nms

Net zoals:

select * 
from   VariableHourComponents@nms

geeft deze een foutmelding:

itgensql035
Unknown identifier ‘PTE.PERIODS_PER_YEAR’.
Consider one of the following: year.

Deze foutmelding komt uit een view die in de *HourComponents@nms-views zit: Nmbrs.Views.CompanyLast7YearPeriods. Deze gebruikt weer PeriodTypes, die door een recente aanpassing niet meer klopt.

Vanaf release 25.0.55 zal dit probleem binnen Invantive Cloud opgelost zijn.

Invantive Bridge Online

Invantive Bridge Online draait nog op release 24.0.

De volgende query is uitgevoerd op Invantive Bridge Online via het Invantive Query Tool over het OData4-protocol:

select *
from   [VariableHourComponents@nms]

Performance Algemeen

Deze queries veroorzaken circa 500x het aantal medewerkers API-calls. Dit is niet duidelijk uit de naamgeving; ze geven de indruk dat het enkel de mogelijke componenten zijn.

Bij bijvoorbeeld 100 medewerkers hebben ze 50.000 API-calls nodig (circa 3 uur verwerkingstijd momenteel zonder parallellisme).

Advies is om een filter mee te geven zoals een filterstap / where-clause op periodetype en/of periode. Dit versnelt in het algemeen de uitvoering bijna lineair. Indien de huidige periode nodig is, gebruik dan EmployeeHourComponentsFixedCurrentByEmployee en EmployeeHourComponentsVariableCurrentByEmployee. Historische periodes kunnen in een datawarehouse opgeslagen worden voor snellere toegang.

Indien deze gegevens vaak nodig zijn, dan is advies om contact op te nemen met Nmbrs Support en de suggestie aan te dragen voor een snellere API.

Hernoemen

Om verwarring te voorkomen omtrent snelheidsverwachtingen worden de tabellen vanaf release 25.0.55 als volgt hernoemd:

  • FixedHourComponents → EmployeeFixedHourComponents
  • VariableHourComponents → EmployeeVariableHourComponents

Parallellisme

Vanaf release 25.0.55 zullen parallelle opties op Nmbrs ingeschakeld worden. Echter, het aantal API-calls zal enorm hoog blijven. Het valt niet te garanderen dat honderdduizenden API-calls voor 1 SQL-statement door het gedeelde Invantive Cloud-platform verwerkt zal worden cq. of dat mogelijk blijft.

7

Er lijkt een groter probleem te zijn met gebruik van deze tabel onder versie 25.0 (dus niet op Invantive App Online en Invantive Bridge Online). De onderliggende SQL van de view onder 25.0.55 is:

select /*+ join_parallelization(ehd, true) */
       ehd.* prefix with 'EHD_'
,      emp.* prefix with 'EMP_'
from   Nmbrs.Views.EmployeesActive emp
join   Nmbrs.Employees.EmployeeHourComponentsFixedCurrentByEmployee(emp.id) ehd

waarbij join_parallelization irrelevant is voor het probleem. Eerste uitvoering levert geen rijen binnen 10 minuten, waarna de UniversalSQL-editor afbreekt.

Draai je de query opnieuw, dan eindigt hij na 57 seconden met:

itgengpr227
The platform has a timeout of 57.000 ms, but all parallel execution slots have been locked for at least that time.

In de locks-tabel is te zien dat een lock van het type semaphore met categorie itgenncr009 niet vrijgegeven wordt:

select *
from   systemlocks@datadictionary
where  date_last_Acquisition is not null
and    date_last_release is null

Aantal acquisities is 32, maar 0 releases.

Ook lijkt het er op dat het gebruik van deze tabel een downsituatie circa 15-30 minuten later veroorzaakt, mogelijk doordat er in de achtergrond nieuwe API-calls afgevuurd blijven worden (zie Storing Invantive Cloud vanaf 20 oktober vanaf 21:40 CET).

8

Specifiek voor release 25.0 (alleen Invantive Cloud) is het onderliggende probleem opgelost. Als er meer dan 16 gelijktijdige HTTP-verzoeken gedaan werden, dan kon een deadlock optreden door een bug die geintroduceerd is in versie 25.0 ten opzichte van versie 24.0.

Deze bug is opgelost en de oplossing is inmiddels in productie genomen. De bug speelt op alle platformen op basis van SOAP, dus onder andere Nmbrs en Twinfield, die gebruik maken van parallellisatie om een grotere doorvoersnelheid te krijgen.

Het aantal API-calls van de genoemde tabellen blijft extreem hoog; de looptijd van 100 medewerkers is enkel gedaald door parallellisatie van 3 uur naar circa 10 minuten indien geen filtering wordt toegepast.

Zonder aanpassingen door Nmbrs aan de mogelijkheden van de API’s is er geen bekende oplossing voor de performance-issues.

Advies is om:

  • de downloads te voorzien van filters (die werken zowel op release 24.0 (App Online, Bridge Online) als op release 25.0 (Cloud)).
  • de downloads opnieuw te proberen nadat release 25.0 ook op App Online en Bridge Online in productie is genomen.
9

Hartelijk dank voor de antwoorden en het uitzoeken van het probleem.

Wij zullen rapportages gaan opzetten die zowel historische als huidige data van de tabellen FixedHourComponents en VariableHourComponents nodig hebben. Aan de hand van de antwoorden, heb ik nog een paar vragen:

  • Wanneer wordt release 25.0 verwacht op App Online en Bridge Online?
  • Klopt het dat na deze release de tabel (Employee)FixedHourComponents succesvol kan worden ingeladen in Power BI?
  • Klopt het dat na deze release de tabel (Employee)VariableHourComponents weer succesvol kan worden ververst (gezien die de laatste tijd consequent tegen een fout aan loopt)?
  • Op het wachten op release 25.0 na, zijn er dingen die wij zelf alvast kunnen doen om mogelijke problemen te voorkomen?
10

Release 25.0 op App en Bridge Online

Er is geen concrete datum bekend wanneer release 25.0 in productie genomen zal zijn. Het is de wens om dit zo snel mogelijk te doen, maar bij twee eerdere pogingen trad na enige tijd een vreemd probleem op dat wel enigszins gelijkend is met het hier gevonden probleem. Gezien het grote aantal gelijktijdige gebruikers op deze platformen die voor hun productietaken er van afhankelijk zijn proberen we met zo weinig impact het probleem te bestuderen en op te lossen.

De voortgang is te volgen via:

Op dit moment draait release 25.0.56 op App Online in proef. Dit platform heeft de kleinste groep gelijktijdige gebruikers, die bovendien veelal meer kennis hebben in omgang met issues.

Succesvol inladen

Het is niet bekend of na deze release de tabel (Employee)FixedHourComponents en/of (Employee)VariableHourComponents succesvol kan worden ingeladen in Power BI.

Het is wel zeker dat er onder release 25.0 een bug voor de juiste werking lag indien er meerdere downloads tegelijk of massief parallel uitgevoerde queries waren op bijvoorbeeld Nmbrs. Deze bug is weggenomen.

Voorbereidingen

Er zijn op dit moment geen dingen in beeld bij Invantive die jullie als gebruiker alvast kunnen doen om mogelijke problemen te voorkomen naast het gegeven advies van filters toevoegen.

11

Inmiddels lukt het om zowel de EmployeeVariableHours als FixedVariableHours op te halen en in te laden.

12

Dit topic is 3 dagen na het laatste antwoord automatisch gesloten. Nieuwe antwoorden zijn niet meer toegestaan.