HELP: Mijn delta’s zijn in de verkeerde volgorde verwerkt!

Ton van Velzen | Sinds de introductie van SAP NetWeaver BI 7.0 is het mogelijk om gebruik te maken van Write-Optimized DataStore Objects. Tegenwoordig wordt de Write-Optimized DSO veelal gebruikt als eerste ‘staging’ laag waarmee deze feitelijk de functie van de Persistent Staging Area (PSA) overneemt. Het gevaar bestaat echter dat delta requests* in een verkeerde volgorde worden geladen in de Write-Optimized DSO’s om vervolgens in de verkeerde volgorde te worden geladen in de target InfoProviders, met alle gevolgen van dien! De betrouwbaarheid van de data in het Data Warehouse staat op het spel! In dit blog draag ik een oplossing aan om deze problematiek geautomatiseerd te onderkennen en om de ‘fout’ adequaat te kunnen herstellen.

* In SAP BI-land is delta een geïntegreerde methode om alleen nieuwe of gewijzigde records te verwerken. Zonder deze methodiek zou iedere keer alle data volledig moeten worden geladen om up-to-date rapportages te kunnen presenteren. Voorwaarde van het gebruik van deze methodiek is dat de delta’s in de juiste volgorde worden verwerkt.

Achtergrond

Delta’s worden veelal (met behulp van Process Chains) volgens een vast laadschema opgehaald uit het bronsysteem en verder verwerkt in het SAP BI Data Warehouse:

  1. Laad delta uit bronsysteem in PSA
  2. Verwerk PSA delta naar Write-Optimized DSO
  3. Verwerk data verder naar InfoProviders

Iedere laadactie krijgt een uniek volgnummer. De verwerking van vier delta’s naar een Write-Optimized DSO zou er dus als volgt uit kunnen zien:

PSA WO DSO
1 2
3 4
5 6
7 8

De eerste delta wordt geladen in de PSA door middel van laadactie (request) 1. Vervolgens wordt de delta geladen in de WO DSO door request 2. Een nieuw PSA request 3 wordt verder verwerkt in de WO DSO door request 4, etc. In het WO DSO request wordt opgeslagen welk PSA request is opgepakt, zie ‘Selecties’:

Met deze informatie kan de request tabel worden uitgebreid:

PSA WO DSO
1 2 (selectie is PSA request 1)
3 4 (selectie is PSA request 3)
5 6 (selectie is PSA request 5)
7 8 (selectie is PSA request 7)

Foutieve load

Het kan voorkomen dat bijvoorbeeld PSA request 3 foutief wordt verwerkt in de WO DSO terwijl er geen actie wordt ondernomen op deze fout. Vervolgens wordt zowel PSA request 5 als PSA request 7 foutloos verwerkt in de WO DSO. Daarna wordt de foutief verwerkte PSA request verwijderd uit de WO DSO, de data wordt in de PSA gecorrigeerd en opnieuw geladen in de WO DSO. Normaliter zou je de nieuw verwerkte PSA requests 5 en 7 in de WO DSO eerst moeten verwijderen om te voorkomen dat de PSA requests in de verkeerde volgorde worden verwerkt in de WO DSO. Het kan echter voorkomen dat dit niet gebeurt. De request tabel zou er in dat geval als volgt uitzien:

WO DSO
2 (selectie is PSA request 1)
6 (selectie is PSA request 5)
8 (selectie is PSA request 7)
9 (selectie is PSA request 3)

PSA request 3 is nu in de verkeerde volgorde verwerkt in de WO DSO ten opzichte van PSA requests 5 en 7. Dit betekent hoogstwaarschijnlijk ook dat de delta verkeerd is verwerkt naar de target InfoProviders, resulterend in foutieve data in de rapportages.

In de instellingen van de WO DSO wordt de mogelijkheid geboden om te controleren op deltaconsistentie (standaard staat deze optie uit):

Deze optie suggereert dat (door het aanvinken) de in het blog besproken problematiek zich niet kan voordoen. Dat klopt helaas niet.

De optie voorkomt dat requests die zijn verwerkt in de target InfoProviders kunnen worden verwijderd uit de WO DSO. De optie voorkomt helaas niet dat requests in de verkeerde volgorde worden geladen in de WO DSO zelf en dus ook in de verkeerde volgorde worden verwerkt in de target InfoProviders.

Nota bene, wanneer de optie is aangevinkt, kan de eventueel noodzakelijke herstelactie “Overladen van de ‘foutieve requests’ naar een kopie van de WO DSO en terug laden van de requests naar het origineel” (zie einde blog) niet worden uitgevoerd. Requests die zijn geladen in de kopie WO DSO kunnen nu niet worden verwijderd uit het origineel, terwijl dit wel een voorwaarde is om de juiste volgorde te kunnen herstellen.

Onderscheppen requests die in de verkeerde volgorde zijn verwerkt in de WO DSO

In SAP BI wordt (zoals gebruikelijk) de benodigde informatie opgeslagen in tabellen. In dit onderdeel van de blog leg ik stapsgewijs uit op welke manier de benodigde informatie is te vinden en hoe uw SAP BI systeem op de bewuste fout kan worden gecontroleerd.

1. Identificeer de Write-Optimized DSO’s 

Transactie: SE16
Tabel: RSDODSO
Selectie: OBJVERS = A
ODSOTYPE = W
Resultaat: Lijst met de WO DSO’s, veld ODSOBJECT
WO_DSO1
WO_DSO2
WO_DSOn

2. Identificeer de DTP’s die delta’s laden naar de WO DSO’s:

Transactie: SE16
Tabel: RSBKDTP
Selectie: OBJVERS = A
UPDMODE = D
TGT = WO_DSO1, .. , WO_DSOn
TGTTP = ODSO
Resultaat: Resultaat: Lijst met de delta DTP’s, veld DTP
DTP1
DTP2
DTPn

3. Identificeer de correct verwerkte requests in de WO DSO’s:

Transactie: SE16
Tabel: RSBKREQUEST
Selectie: USTATE <> 4 (verwijderde requests behoeven niet te worden meegenomen in de analyse)
DTP = DTP1, .. , DTPn
Resultaat: Lijst met request id’s per DTP, velden DTP en REQUID
DTP1, REQUID1, .. , REQUIDn
DTP2, REQUID1, .. , REQUIDn
DTPn, REQUID1, .. , REQUIDn

4. Vind de PSA requests die zijn opgepakt door de DTP requests

Helaas zijn de PSA requests die zijn opgepakt door de DTP requests niet opgeslagen in een transparante tabel in SAP BW. De betreffende PSA requests zijn alleen op te halen door middel van het uitvoeren van ABAP Object Oriented programmacode. Door het uitvoeren van de methode CREATE_FROM_DB in de klasse CL_RSBK_REQUEST kan/kunnen de betreffende PSA request(s) worden opgehaald:

DATA:  itab TYPE STANDARD TABLE OF rsbk_s_range,
wa TYPE rsbk_s_range.
DATA: l_r_request TYPE REF TO cl_rsbk_request.
DATA: n_requid TYPE int4. “Dit is het DTP request

 l_r_request = cl_rsbk_request=>create_from_db( n_requid ).
itab = l_r_request->get_th_range( ).

In de interne tabel “itab” worden de opgehaalde PSA requests opgeslagen per DTP request.

Resultaat: Lijst met PSA request’s per DTP request, velden REQUID(DTP) en REQUID(PSA)
REQUID(DTP)1, REQUID(PSA)1, .. , REQUID(PSA)n
REQUID(DTP)2, REQUID(PSA)1, .. , REQUID(PSA)n
REQUID(DTP)n, REQUID(PSA)1, .. , REQUID(PSA)n

 

5. Controleer of requests in de verkeerde volgorde zijn verwerkt in de WO DSO

Per DTP kan nu een soortgelijke tabel worden opgebouwd als eerder vertoond:

DTP REQUID(DTP) REQUID(PSA)
DTP_1 3 1
DTP_1 3 2
DTP_1 6 5
DTP_1 8 7
DTP_1 9 4
DTP_n n n

6. Automatisering

Bovenstaande controle zou idealiter periodiek geautomatiseerd uitgevoerd dienen te worden met als resultaat een e-mail met de output van de controle. Om deze oplossing te realiseren heb ik gebruik gemaakt van zowel SAP BW (7.30) als van SAP Business Objects (4.1).

SAP BW

Stappen 1 tot en met 3 zijn opgelost door gebruik te maken van een Generic DataSource, extractiemethode functiemodule. Het resultaat van de Generic DataSource is een lijst met request id’s per DTP, beschikbaar in een PSA:
Stappen 4 en 5 zijn opgelost in de Transformation naar de target DSO. Het resultaat van de Transformation wordt opgeslagen in de target DSO. Dit is een lijst met de PSA requests per DTP die in de verkeerde volgorde zijn verwerkt in de WO DSO:

De benodigde informatie is nu beschikbaar in het SAP BW Data Warehouse. Om de benodigde informatie te kunnen rapporteren is een BEx query gecreëerd. De BEx query geldt vervolgens als input van een Business Objects Web Intelligence document. Uiteindelijk kan het Web Intelligence document periodiek worden verzonden naar belanghebbenden. Dit is te realiseren met behulp van de Business Objects Schedule functionaliteit. Onderstaand rapport krijgen belanghebbenden in hun e-mail-inbox:

Herstelactie

De herstelactie is in principe simpel. De PSA requests die in de verkeerde volgorde zijn verwerkt in de target InfoProviders zullen moeten worden verwijderd uit de target InfoProviders. Voor onderstaand voorbeeld betekent dit dat verder verwerkt REQUID(DTP) 6, 8, 9 en n verwijderd moeten worden uit de WO DSO en de target InfoProviders.

DTP REQUID(DTP) REQUID(PSA)<
DTP_1 3 1
DTP_1 3 2
DTP_1 6 5
DTP_1 8 7
DTP_1 9 4
DTP_n n n

Er van uitgaande dat REQUID(PSA) 4, 5, 7 en n nog beschikbaar zijn in de PSA, kunnen de PSA requests met een nieuwe delta worden geladen in de WO DSO en kunnen ze verder worden verwerkt in de target InfoProviders. Over het algemeen is het dus raadzaam om delta PSA requests een aantal dagen te bewaren in de PSA om herstelacties te kunnen faciliteren. Indien de requests niet meer beschikbaar zijn in de PSA, resten er twee opties:

  •  Een nieuwe delta-initialisatie: afhankelijk van de initialisatiemethode en het datavolume kan dit een zeer tijdrovende exercitie zijn.
  •  Overladen van de “foutieve requests” naar een kopie van de WO DSO en terug laden van de requests naar het origineel:

Stap 1: Laad de requests uit het origineel naar de kopie, zorg ervoor dat  aangevinkt is. Resultaat kopie WO DSO:

DTP REQUID(DTP) REQUID(PSA)
DTP_1 10 1
DTP_1 10 2
DTP_1 11 5
DTP_1 12 7
DTP_1 13 4
DTP_n n n

Stap 2: Verwijder requests 6, 8 en n uit de originele WO DSO. Resultaat:

DTP REQUID(DTP) REQUID(PSA)
DTP_1 3 1
DTP_1 3 2
DTP_1 9 4

Stap 3: Verwijder requests 10 en 13 uit de kopie WO DSO en laad de overgebleven requests terug naar de originele WO DSO. Resultaat originele WO DSO:

DTP REQUID(DTP) REQUID(PSA)
DTP_1 3 1
DTP_1 3 2
DTP_1 9 4
DTP_1 14 5
DTP_1 15 7
DTP_n n n

De delta’s staan weer in de juiste volgorde in de WO DSO en kunnen verwerkt worden in de target InfoProviders.

Tot slot

Met deze blog hoop ik u een handreiking te geven om de preventieve controle op uw data-correctheid naar een hoger niveau te tillen of u tenminste bewust te maken dat bovenstaande problematiek zich überhaupt kan voordoen. Aarzel niet om contact op te nemen met Ton van Velzen indien u vragen heeft of hulp wenst bij de implementatie.

Ton van Velzen is managing analytics consultant bij Magnus. Binnen het Magnus Analytics team houden we ons bezig met het realiseren en implementeren van SAP Analytics oplossingen. Daarbij leggen we de focus op SAP Business Planning & Consolidation, Mobile BI, Design Studio, Predictive Analyses, HANA en Datawarehousing architecturen.

Links: