Slim datumfilteren in SAP Datasphere voor snelle BW‑queries

Wanneer je in SAP Datasphere werkt met SAP BW‑bronnen, merk je al snel dat datumfilters niet altijd efficiënt worden doorgegeven. Daardoor verwerkt BW eerst volledige datacubes, waarna Datasphere alsnog lokaal filtert. Dat kost onnodige rekentijd en vertraagt analyses aanzienlijk. Daarom laat ik je in dit artikel zien hoe je met SQL‑variabelen in een Datasphere Query Script wél een effectief pushdown‑filter op jaar realiseert. Vervolgens zie je direct in de Data Integration Monitor hoe de filterconditie netjes wordt doorgestuurd. Dit levert in sommige scenario's tot wel 95% performancewinst op.

Waarom datumfilters vaak niet worden doorgegeven

Veel SAP BW‑objecten slaan datums op als tekstvelden. Daardoor herkent Datasphere een standaard WHERE‑filter niet altijd als een pushdown‑conditie. Het gevolg: BW leest volledige datasets in zodra je query draait. Daarom zie je in de Remote Query‑details vaak dat de WHERE‑clausule ontbreekt. Dat maakt de verwerking duurder én trager.

Hoe Datasphere omgaat met remote filters

Bij een remote tabel of view bepaalt Datasphere of een filter kan worden doorgestuurd. Dit hangt onder andere af van:

• Het datatype van de kolom
• De compatibiliteit tussen SQL‑expressies in Datasphere en de onderliggende BW‑bron
• Het gebruik van variabelen of functies die door BW worden ondersteund

Wanneer de filterexpressie niet "pushdown‑compatible" is, wordt het filter pas na ontvangst van de volledige dataset toegepast.

De oplossing: jaartallen via variabelen doorgeven

Door jaartallen eerst in SQL‑variabelen te zetten en vervolgens via BIND_AS_VALUE() te gebruiken, wordt de filterconditie wel herkend en netjes meegestuurd. Daardoor draait BW direct een gefilterde query. Dat scheelt aanzienlijk in verwerkingstijd.

Hieronder zie je een aangepaste en geanonimiseerde versie van het toepasbare SQL‑patroon:

-- Variables
DECLARE P_LASTYEAR NVARCHAR(4);
DECLARE V_LASTYEAR NVARCHAR(4);
DECLARE P_THISYEAR NVARCHAR(4);
DECLARE V_THISYEAR NVARCHAR(4);
-- Previus year
V_LASTYEAR = TO_NVARCHAR(YEAR(ADD_YEARS(CURRENT_DATE, -1)));
P_LASTYEAR := TO_NVARCHAR(V_LASTYEAR);
-- Current year
V_THISYEAR = TO_NVARCHAR(YEAR(CURRENT_DATE));
P_THISYEAR := TO_NVARCHAR(V_THISYEAR);
RETURN
SELECT DISTINCT
    S."CALWEEK",
    S."CALYEAR",
    S."SALESORG",
    S."CUSTOMER" AS "Customer",
    TO_DOUBLE(S."INVOICED_QTY") AS "Invoiced qty"
FROM "MY_REMOTE_TURNOVER_VIEW" AS S
WHERE S."CALYEAR" IN (
    BIND_AS_VALUE(:P_LASTYEAR),
    BIND_AS_VALUE(:P_THISYEAR)
);

Waarom dit werkt

De functie BIND_AS_VALUE() zorgt ervoor dat Datasphere de variabele interpreteert als een statische waarde vóórdat de query naar BW gaat. Hierdoor verschijnt de jaartal-filtering zichtbaar in de Remote Query-details-precies zoals je wilt.

HPvH: Example Datasphere SQL Script Table Function

Hoe je de SQL-query in Datasphere opzet

Om dit patroon te gebruiken, maak je in de Data Builder een nieuwe SQL-view op basis van je BW-bron. Vervolgens stel je expliciet de taal in op SQLScript (Table Function).

Volg hiervoor deze stappen (inclusief controle met het schild‑icoon-Validate SQL):

1. Ga naar Data Builder en kies Nieuw → SQL View.
2. Sleep je BW-bron (bijvoorbeeld een remote turnover-view) vanuit de Source Browser naar de editor, of verwijs er later in je code naar.
3. Open in het rechterpaneel de eigenschappen van de SQL-view en zet Language op SQLScript (Table Function).
4. Plak vervolgens je SQLScript-code (met DECLARE-blokken, variabelen en RETURN SELECT ...).
5. Klik op het schild‑icoon-Validate SQL om je SQL syntactisch te toetsen en voer daarna Preview Data uit om zowel de syntaxis als de outputstructuur te controleren.
6. Sla de view op en deploy deze.

Vanaf dit moment wordt je SQLScript als HANA-table function uitgevoerd. In combinatie met BIND_AS_VALUE() zorgt dat ervoor dat je filters op jaar en datum ook echt als pushdown naar BW worden verstuurd.

Waarom SQLScript essentieel is bij BW-datasets

Wanneer je met SAP BW-bronnen werkt, merk je dat een standaard SQL View vaak onvoldoende is voor efficiënte filtering. Dit komt doordat je in een reguliere SQL View geen variabelen kunt declareren en geen gebruik kunt maken van RETURN-statements of table-function-logica. Daarom is SQLScript (Table Function) noodzakelijk. Hiermee krijgt de HANA-engine de ruimte om variabelen vooraf te evalueren en deze als bind-values door te sturen naar BW. Bovendien kan de optimizer de volledige querystructuur analyseren en zo bepalen of pushdown mogelijk is. Hierdoor wordt filtering op jaartal of YEARMONTH op de bron uitgevoerd in plaats van in Datasphere.

Hoe de Data Integration Monitor werkt

De Data Integration Monitor is een essentieel hulpmiddel om te controleren of je query optimaal draait. Je vindt er onder Remote Queries zowel de logische SQL als het statement dat daadwerkelijk naar BW gestuurd wordt. De belangrijkste elementen zijn:

• Executed Remote SQL: de exacte query zoals BW die ontvangt. Hier moet je WHERE-filter zichtbaar zijn.
• Runtime Remote vs Runtime Local: hoge remote runtime is normaal; hoge local runtime duidt op ontbrekende pushdown.
• Rows Transferred: een laag getal betekent dat filtering bij de bron plaatsvond. Hoge aantallen wijzen op lokale filtering.
• More Details: toont de volledige SQL, inclusief bind-values zoals je jaartal of YEARMONTH.

Door deze informatie te analyseren, kun je direct vaststellen of je oplossing echt performant is.

Veelgemaakte fouten (en hoe je ze voorkomt)

Tijdens het bouwen van SQLScript-views voor BW-bronnen kom je vaak dezelfde valkuilen tegen. De belangrijkste zijn:

• Geen SQLScript als taal selecteren: zonder table-functionmodus worden variabelen niet verwerkt en vindt geen pushdown plaats.
• Complexe expressies in WHERE: functies die BW niet begrijpt (bijvoorbeeld bepaalde stringbewerkingen) verhinderen pushdown.
• Geen gebruik van BIND_AS_VALUE(): variabelen worden dan niet als vaste waarde doorgegeven en de WHERE-clausule ontbreekt.
• Filteren op tekst zonder juiste representatie: wanneer BW-datumvelden tekst zijn, moet je filterwaarden exact hetzelfde formaat hebben.

Door deze valkuilen te vermijden, vergroot je de kans dat je filters daadwerkelijk naar BW worden doorgestuurd.

Resultaat: tot 95% performancewinst

Zodra Datasphere alleen de relevante jaren ophaalt, hoeft BW niet langer volledige datacubes te verwerken. Daarom merk je direct:

• Kortere wachttijden
• Minder belasting op de BW-omgeving
• Snellere dashboards en rapporten die hierop bouwen

Dagelijkse persistency voor extra snelheid

Door deze gefilterde dataset dagelijks als persisted view te laten draaien, werk je altijd met een lichte, snelle basis. Vanuit deze persistente laag bouw je eenvoudig meerdere use-case views zonder opnieuw zware remote queries uit te voeren.

Filteren op YEARMONTH in plaats van alleen YEAR

In veel BW-modellen wordt naast jaar (CALYEAR) ook een tekstveld met jaar-maand (CALMONTH, formaat YYYYMM) gebruikt. Hetzelfde principe met variabelen en BIND_AS_VALUE() werkt hier ook uitstekend. Daarmee kun je bijvoorbeeld de laatste 12 maanden of een specifieke maandreeks ophalen.

Voorbeeld 1-Laatste 12 maanden op basis van YEARMONTH

Onderstaand patroon berekent een FROM-en TO-waarde op YYYYMM-niveau en filtert vervolgens op CALMONTH:

-- Variables YEARMONTH
DECLARE P_FROM_YM NVARCHAR(6);
DECLARE V_FROM_YM NVARCHAR(6);
DECLARE P_TO_YM   NVARCHAR(6);
DECLARE V_TO_YM   NVARCHAR(6);
-- Last 12 months
V_FROM_YM = TO_NVARCHAR(ADD_MONTHS(CURRENT_DATE, -12), 'YYYYMM');
P_FROM_YM := V_FROM_YM;
V_TO_YM = TO_NVARCHAR(CURRENT_DATE, 'YYYYMM');
P_TO_YM := V_TO_YM;
RETURN
SELECT
    S."CALMONTH",
    S."CALYEAR",
    S."SALESORG",
    TO_DOUBLE(S."INVOICED_QTY") AS "Invoiced qty"
FROM "MY_REMOTE_TURNOVER_VIEW" AS S
WHERE S."CALMONTH" BETWEEN 
    BIND_AS_VALUE(:P_FROM_YM) AND BIND_AS_VALUE(:P_TO_YM);

Hiermee stuur je een strak begrensd YEARMONTH-bereik door naar BW, waardoor de remote query veel minder data hoeft te lezen.

Voorbeeld 2-Alleen huidige en vorige maand

Wil je rapportages die vooral op recente maanden focussen, dan kun je in plaats van een volledig bereik ook expliciet de huidige en vorige maand opvragen:

-- Variabelen voor huidige en vorige maand
DECLARE P_PREV_YM NVARCHAR(6);
DECLARE V_PREV_YM NVARCHAR(6);
DECLARE P_CURR_YM NVARCHAR(6);
DECLARE V_CURR_YM NVARCHAR(6);
-- Vorige maand
V_PREV_YM = TO_NVARCHAR(ADD_MONTHS(CURRENT_DATE, -1), 'YYYYMM');
P_PREV_YM := V_PREV_YM;
-- Huidige maand
V_CURR_YM = TO_NVARCHAR(CURRENT_DATE, 'YYYYMM');
P_CURR_YM := V_CURR_YM;
RETURN
SELECT
    S."CALMONTH",
    S."CALYEAR",
    S."SALESORG",
    TO_DOUBLE(S."INVOICED_QTY") AS "Invoiced qty"
FROM "MY_REMOTE_TURNOVER_VIEW" AS S
WHERE S."CALMONTH" IN (
    BIND_AS_VALUE(:P_PREV_YM),
    BIND_AS_VALUE(:P_CURR_YM)
);

Ook hier geldt: doordat de maandwaarden eerst in variabelen staan en vervolgens via BIND_AS_VALUE() worden gebruikt, zie je in de Remote Queries-details exact welke YEARMONTH-waarden naar BW zijn gestuurd. Dit voorkomt onnodige dataverwerking, versnelt analyses en verlaagt de belasting van je landschap. Vooral in omgevingen met tekst‑datumvelden in BW levert dit een aanzienlijke performancewinst op. Combineer dit met persisted views en je bouwt een schaalbare, snelle en onderhoudsvriendelijke datastructuur in Datasphere.

Bronnenlijst

• SAP Datasphere-"Monitoring Remote Queries" op SAP Help Portal. help.sap.com
• SAP Help Portal-"SQLScript Reference" voor Datasphere, waaronder de sectie over het instellen van de Language op SQLScript (Table Function). help.sap.com
• SAP Community Blog-"SAP Datasphere Remote Table dynamic filter pushdown" waarin het gebruik van variabelen in SQLScript voor filterpushdown wordt beschreven. community.sap.com