Best Practices voor de Universal Adapter

Inleiding

BI Applications is een Business Intelligence oplossing die organisaties in staat stelt om in korte tijd inzicht te verkrijgen in de stand van zaken door middel van geprefabriceerde ‘analytics’.
BI Applications is vooral ontwikkeld om data te verzamelen vanuit ERP / CRM systemen zoals Oracle EBS, PeopleSoft, Siebel en JD Edwards, en ook SAP.

Daarnaast bestaat er een mogelijkheid om dezelfde prefab ‘analytics’ te gebruiken met gegevens die komen uit een niet herkende bron, bijvoorbeeld een applicatie van een andere leverancier, of een zelfgemaakte applicatie. Daarvoor bestaat de zogenaamde Universal Adapter die toestaat dat gegevens, vanuit allerlei soorten applicaties, binnen het raamwerk van BI Applications getoond worden.

Dit document behandelt deze Best Practices, en zal bij voorbeelden specifieker ingaan op de analytische modules Financials en Human Resources. Overigens is de aanname gedaan dat u al voorkennis heeft van BI Applications, en dat bepaalde terminologie (SDE, SIL, DAC, etc.) niet meer toegelicht moet worden. Daarmee is dit een redelijk technisch inhoudelijk document.

Referentiedocumentatie

  1. Oracle® Business Intelligence Applications Implementing Human Resources Analytics with Universal Adaptors [ID 1269240.1]. Dit is een ‘paper’ op de Oracle Support site.
  2. Oracle® Business Intelligence Applications Installation Guide for Informatica PowerCenter Users Release 7.9.6.4. Part Number E35271-01.
  3. Oracle® Business Intelligence Applications Configuration Guide for Informatica PowerCenter Users Release 7.9.6.4. Part Number E35272-01.
  4. Oracle® Business Intelligence Applications Naming Conventions and Domain Values Guide Release 7.9.6.4.Part Number E35829-01. Dit document wordt ook wel ‘Data Model Reference Guide’ genoemd.

Het uitgangspunt voor dit document is BI Applications versie 7.9.6 (t/m .4) geweest. Echter, dit concept van de Universal Adapter is niet gebonden tot deze versie.

Concept Universal Adapter

 

bia-ua-figuur1
Figuur 1: Architectuur van BI Applications met aandacht voor de Universal Adapter.

Zoals u kunt zien in bovenstaande figuur heeft de Universal Adapter van BI Applications alleen betrekking op de ETL component van BI Applications, dat is aangegeven in de oranje cirkel. Dit heeft betrekking op de “Other” bronsystemen.  Alles dat daarna gebeurt, is algemene functionaliteit van BI Applications. Dit betekent dan ook dat u een beperkt deel van BI Applications moet gaan invullen.

Het juist invullen van de ETL component via de Universal Adapter om daarna correcte resultaten in BI Applications te zien, is goed te doen, maar moet ook niet te lichtvaardig worden ingeschat. Het achterliggende idee van de ETL component is gebaseerd op gebruik van een universele data interface, die met behulp van CSV bestanden werkt. U moet dus zelf programmatuur maken die de gegevensextractie en transformatie (E en T uit ETL) uitvoeren op uw bronsysteem, waarna de Universal Adapter de laadstap (L uit ETL) uitvoert.
Zoals bij elke adapter binnen BI Applications is de SDE logica voor de Universal Adapter specifiek en de SIL logica generiek.

Essentieel voor het gebruik van de Universal Adapter is juiste vulling van de CSV bestanden. Daarvoor is inhoudelijke kennis nodig van de BI applicatie (wat is nodig aan gegevens en wat is de betekenis?) en van de bron (welke items uit de bron zijn nodig voor voeding van BI Applications?). Om deze vragen te beantwoorden is een Data Lineage sheet een handig hulpmiddel. Meer details kunt u vinden in de paragrafen data mapping en data extractie).

Aanpak BI Applications met Universal Adapter

Bij het toepassen van de Universal Adapter moet u zelf zorgen voor de gegevensextractie en transformatie. Afhankelijk van de analytische modules die u wilt gaan gebruiken, kan er veel tot heel veel werk op u afkomen.

Daarom is het verstandig om voor een incrementele aanpak te kiezen. Dit betekent concreet het volgende:

  • Kies eerst welke modules u wilt gaan gebruiken.
  • Kies per module welke ‘subject areas’ voor u van belang zijn.

Gebruik voor het maken van deze keuze bij voorkeur een gevulde BI Applications omgeving, ook al is deze omgeving gevuld met demo-data van bijvoorbeeld Oracle (“Vision”).

  • Werk de vulling van de bestanden per ‘subject area’ uit.
  • Bepaal welke tabellen voor het ‘subject area’ van belang zijn. Het beste is om daarvoor in de OBIEE repository te kijken en dan een matrix op te bouwen van feiten en dimensies per ‘subject area’.
bia-ua-figuur2
Figuur 2 – Gedeeltelijk overzicht van feiten en dimensies per ‘subject area’
  • Maak een ‘data lineage’ in bijvoorbeeld een spreadsheet; 1 inleiding met alle benodigde CSV bestanden, en 1 per bestand.
bia-ua-figuur3
Figuur 3 – Gedeeltelijk overzicht van de ‘data lineage’ inleiding
bia-ua-figuur4
Figuur 4 – Gedeeltelijk overzicht van de ‘data lineage’ tabelinhoud en herkomst

Belangrijk bij de invulling van de sheets per CSV bestand (of BAW tabel) is om een sectie te maken voor:

    • de benodigde BAW gegevens en betekenis binnen BI Apps,
    • de herkomst van de data uit het bronsysteem, inclusief benodigde transformaties.
  • Bouw vervolgens de bestanden op voor de vulling van de dimensies.
  • Bouw daarna de bestanden op voor de vulling van de feiten. De volgorde van eerst dimensies en dan de feiten is van belang, omdat in de bestanden voor de feiten sleutelvelden bestaan die verwijzen naar de dimensies.
  • Test of alle gegevens volledig en correct geladen worden, en de dashboards de juiste gegevens en tellingen tonen. Het testen gebeurt in meerdere stappen. Voor meer details zie de paragraaf over testen. U zult wellicht merken dat er vaak meerdere cycli nodig zijn om alle data correct te laden. Ga uit van ongeveer 5 cycli per ‘subject area’. Hierbij bestaat 1 cyclus uit het compleet laden van alle tabellen 1 ‘subject area’.
  • Regel het proces in voor (dagelijkse) extractie, transport van bestanden en upload in BI Applications (zie vaste stroom).
  • Bepaal of er nog maatwerk nodig is, en voer deze door conform de daarvoor geldende stappen (zie ‘customizations’).

Overigens is er voor de module HR Analytics al heel veel voorwerk gedaan door Oracle zelf. Via de Oracle Support website kunt u papers downloaden die bovenstaande stappenplan ondersteunen (zie referentiedocument 1). Helaas is deze documentatie (nog) niet voor alle modules aanwezig.

Installatie en Configuratie

Voor elke BI Applications implementatie is het noodzakelijk om een installatie en configuratie uit te voeren, zo ook voor een BI Applications implementatie met de Universal Adapter.

Bij de installatie moet u de diverse softwarecomponenten voor BI Applications installeren (OBIEE, database, Informatica Powercenter en DAC), waarna u met behulp van de ‘BI Applications installer’ de benodigde ‘metadata repositories’ kunt aanmaken (voor OBIEE, Informatica Powercenter en DAC).

Na de installatie maakt u de tabellen van het BAW aan vanuit DAC, en voert een paar technische configuratiestappen uit om verbindingen met bron en BAW mogelijk te maken vanuit OBIEE, Informatica Powercenter en DAC.

Net zoals bij een BI Applications configuratie voor bijvoorbeeld Financials bovenop EBS, zijn er ook drie configuratiestappen voor de analytische modules bovenop de Universal Adapter:

  1. Brononafhankelijke configuratie
  2. Module specifieke configuratie
  3. Bronsysteem specifieke configuratie

Alle details over de configuratiestappen kunt u vinden in referentiedocument 2.

‘Out of the box’ is er per BI Applications module (HR, Financials, Procurement and Spend) een ‘execution plan’ in DAC die alle stappen van de Universal Adapter bevat. Afhankelijk van de modules die u wilt gebruiken, kunt u dan 1 of meerdere ‘execution plans’ opstarten. De ‘subject areas’ die behoren bij deze ‘execution plans’ staan in de ‘container’ “Universal”.

Alleen voordat u dat kunt doen, is het nodig om gevulde CSV bestanden te hebben. Hoe u deze het beste kunt aanmaken, leest u in de twee volgende paragrafen.

Data mapping van bron naar BI Applications

In het stappenplan voor implementatie staat al genoemd dat het nodig is om een ‘data lineage’ op te bouwen, bijvoorbeeld met behulp van een spreadsheet. In deze paragraaf gaan we verder in op de details van deze ‘data lineage’.

Als u de ‘data lineage’ sheet voor HR Analytics (referentiedocument 1) bekijkt, dan ziet u een tabblad met alle benodigde bestanden en bijbehorende ETL logica. Voor elke regel in het inleidende tabblad ziet u een detail tabblad per bestand (of BAW staging tabel).

bia-ua-figuur4
Figuur 4 – Gedeeltelijk overzicht van de ‘data lineage’ tabel inhoud en herkomst

 

Voor alle duidelijkheid is nogmaals figuur 4 opgenomen. Belangrijk bij de invulling van de sheets per CSV bestand (of BAW tabel) is om één sectie te maken voor de benodigde BAW gegevens, en één sectie voor de herkomst van de data uit het bronsysteem.

Bij elke BAW tabel zult u de volgende details moeten opnemen:

  • Kolomnummer. Geeft de volgorde aan van een kolom / veld in het CSV bestand.
  • Kolomnaam.  Naam van de kolom in het BAW.
  • Omschrijving. Betekenis van de kolom binnen BI Applications.
  • Data Type. Soort veld (numeriek, alfanumeriek, datum).
  • Lengte van het veld. Voor numerieke velden eventueel ‘precision’ (totaal aantal cijfers inclusief decimalen) en ‘scale’ (aantal decimalen).
  • Verplicht / Optioneel.
  • Toegestane waarden. Voor bepaalde kolommen zijn in de Data Model Reference Guide [4] lijsten met toegestane waarden opgenomen. Het is wel handig om deze waarden te weten.

Bij de herkomst van de brongegevens zult u de volgende details moeten opnemen (per kolom):

  • Brontabel en bronkolom(men). Overigens kan er ook sprake zijn van een bronbestand met velden.
  • Mogelijke waarden in de bron, en vertalingen richting BAW waarden.
  • Benodigde transformaties voor overige kolommen.
  • Opmerkingen. In normaal Nederlands beschrijven wat de betekenis is van bepaalde transformaties.

En eenmalig per CSV bestand:

  • Algeheel filter voor brondata.
  • ‘Join conditions’. indien u meerdere tabellen met elkaar moet combineren, is het ook verstandig om de ‘join conditions’ op te nemen. Deze worden eenmalig per tabel genoemd.

Indien u meerdere bronnen onderkent, dan is het verstandig om voor alle bronnen dezelfde ’data lineage’ sheet te gebruiken, maar dan per bron een aparte sectie met de herkomst van data op te nemen.

Vulling van kritieke velden

In BI Applications zijn er diverse kolommen (velden) die op een bepaalde manier gevuld moeten worden. Deze velden zijn hieronder opgesomd:

  • DATASOURCE_NUM_ID. Nummer om een bronsysteem aan te duiden. Vormt samen met INTEGRATION_ID een technische sleutel (‘unique key’).
  • INTEGRATION_ID. Veld / velden die in de bron de sleutel vormt /vormen. Indien meerdere velden de sleutel vormen, dan worden deze door middel van een ~ van elkaar gescheiden. Vormt samen met DATASOURCE_NUM_ID een technische sleutel (‘unique key’).
  • xxx_ID velden bij de CSV bestanden voor de feiten. Dit zijn de verwijzingen van de feitdata naar de dimensiedata (INTEGRATION_ID in de dimensie). Deze kolommen moeten dus identiek gevuld worden aan de INTEGRATION_ID van elke dimensie.
  • X_CUSTOM. Normaal gesproken een markeringsveld in BI Applications om maatwerk te scheiden van de standaard. Normaal gesproken wordt dit veld niet gebruikt , maar in de context van de Universal Adapter is het handig om de code van het bronsysteem hierin op te nemen. Dit is vooral handig voor het testen van de data via queries op het BAW. Hiermee kunt u ook verschillende bronnen met dezelfde DATASOURCE_NUM_ID van elkaar onderscheiden.
  • TENANT_ID. Wordt nog niet echt gebruikt, en is vooral bedoeld voor SaaS oplossingen. Aangezien BI Applications dit (nog) niet toestaat, is een standaardvulling met “DEFAULT” het beste.
  • SRC_EFFECTIVE_FROM_DT / SRC_EFFECTIVE_TO_DT. Kolommen die tijdgeldigheid in de bron aangeven. Indien de bron geen historie opbouwt, dan is het verstandig om deze velden als volgt te vullen:
    • SRC_EFFECTIVE_FROM_DT01-01-1899
    • SRC_EFFECTIVE_TO_DT31-12-2020 of 31-12-2030
  • DELETE_FLG. Kolom die aangeeft of een rij is verwijderd in de bron, nadat deze is geladen in het BAW. Indien de bron niet in staat is om dit te markeren, dan vult u deze vlag altijd met een “N”.
  • CREATED_BY_ID / CHANGED_BY_ID. Gebruikerscode die een bepaald gegeven (rij) in de bron heeft aangemaakt of gewijzigd. Dit betekent dat alle gebruikers bekend moeten zijn in de tabel ‘W_USERS_D’. En voor deze laatstgenoemde tabel is het niet mogelijk om de kolommen anders te vullen dan met een 0. Indien u voor analytische doeleinden niet wilt bijhouden welke gebruiker welke gegevens heeft gemuteerd, dan kunt u deze kolommen vullen met standaardwaarde 0.

Vulling van bestand voor W_CODE_D

De tabel W_CODE_D is binnen BI Applications vooral bedoeld voor vertalingen. En dan bedoelen we:

  • letterlijk vertalingen. Nederlandse bronwaarden voorzien van Engelstalige code en omschrijving
  • datavertalingen: Data mappings om bronwaarden om te zetten in relevante rapportagewaarden binnen BI Applications.

Normaal gesproken wordt deze tabel van inhoud voorzien vanuit de Oracle bronnen (EBS, Siebel, PeopleSoft, JDEdwards). Voor de Universal Adapter zult u zelf de vulling moeten aanleveren met behulp van 1 CSV bestand per onderwerp of categorie.

Bij de uitvoering van de ETL stappen zijn er dus ook vele ETL mappings die elk hun eigen bestand oppakken, en de tabel vullen voor een bepaalde categorie. De juiste codering voor de categorie kunt u het beste afleiden uit de waarde van de parameter “$$CATEGORY” bij elke ‘W_CODE_D task’ in DAC.

Voorbeelden van waarden die nodig zijn (voor Financials en/of HR) zijn:

Financial Statement Item

Gender

Group Account

Highest Degree of Education

Job

‘FIN_STMT_ITEM’

‘SEX_M_F’

‘GROUP_ACCT’

‘HIGHEST_DEGREE’

‘JOB’

 

Bijzondere bestanden

Sommige bestanden zijn vereist voor een correcte vulling van het BAW en daarmee werking van BI Applications. In deze bestanden staat dan een hardgecodeerde waarde voor een ROW_WID, iets dat normaal tijdens de SIL ETL stappen wordt toegekend.

Nu is het onmogelijk om in dit document alle uitzonderingen te benoemen, maar de belangrijkste zijn hier opgesomd:

bia-ua-tabel1

 

In het stappenplan voor implementatie staat al genoemd dat het nodig is om na het invullen van de ‘data lineage’ sheet, te starten met het aanmaken van gevulde CSV bestanden. Deze sheet gebruikt u vervolgens om de extractie-queries te maken en de bestanden te vullen.

Op zich voert u hier de E en T stappen uit het ETL traject uit. Daarbij zijn er wat bijzonderheden te melden over de structuur van de CSV bestanden, en niet zozeer over de queries die u moet maken om deze bestanden te vullen; deze queries zijn immers bronsysteem afhankelijk.

Kopregels

Elk bestand bestaat uit 5 kopregels. Een voorbeeld kunt u zien in de Informatica Powercenter folder “<INFA-HOME>/server/infa_shared/SrcFiles”.

In de voorbeelden zijn de 5 kopregels op de officiële manier opgebouwd. Echter, u kunt er ook voor kiezen om willekeurig 5 regels tekst in het bestand te zetten. De enige voorwaarde is dat er 5 kopregels zijn voordat de regels met data starten.

Voor testdoeleinden (bijvoorbeeld openen van de CSV bestanden in Excel of een CSV editor) is het wel handig om de 5e kopregel waarin de kolomnamen staan, aan te maken.

bia-ua-figuur5
Figuur 5 – Voorbeeld kopregels CSV bestand.

NB: Regel 5 met de kopregel wordt in deze figuur als twee regels getoond, omdat deze te lang is om als 1 regel op het scherm te laten zien.

Scheidingsteken

Alle velden in het bestand worden van elkaar gescheiden door middel van een komma.

Nu kan het natuurlijk voorkomen dat in bepaalde tekstvelden een komma is gebruikt. Om te voorkomen dat de ETL logica dit ziet als een nieuw veld, kunt u aanhalingstekens (“)  gebruiken aan het begin en einde van elk veld.

Voorbeeld: …,1582,“Dit is een tekstveld, dat dient als voorbeeld”,01-03-2013,…
U ziet hier nu de inhoud van 3 velden: Getal 1582, een tekst en datum 01-03-2013.

Full en Incremental extracts

Bij het verwerken van de gegevens in de CSV bestanden is het zo dat alle data die wordt aangeleverd altijd volledig wordt verwerkt. In feite bepaalt u zelf de inhoud van de aangeleverde rijen: Een volledige set of alleen de wijzigingen ten opzichte van de vorige keer.

Daarbij wordt u natuurlijk beperkt in uw keuzes door de mogelijkheden die het bronsysteem heeft om wijzigingen te onderkennen. Sommige systemen bieden niet de mogelijkheid om alle mutaties sinds de vorige keer te herkennen. In dat geval rest u niets anders dan een volledige data extractie.

Testen data

Nadat u de bestanden hebt aangemaakt en gevuld met de gegevens uit uw bronsysteem, zult u deze vulling moeten controleren. Het testen van BI Applications in combinatie met de Universal Adapter bestaat uit verschillende stappen, namelijk:

Het testen van de CSV bestanden op correcte vulling tijdens de E en T stappen. Dit noemen we in het algemeen datatest 1.

  1. Het is een technische test om te zien dat alle rijen die zijn geselecteerd correct en volledig in het CSV bestand zijn gekomen.
  2. In deze test wordt meestal gebruik gemaakt van Excel of een CSV editor om de volgende zaken te bekijken:
    1. Aantal data rijen (dus alles exclusief de 5 kopregels) in het CSV bestand vergelijken met het aantal rijen in de extractiequery.
    2. Inhoud van kolommen controleren met verwachting.

Laden van de CSV bestanden in het BAW en controleren op correct vulling van het BAW.
Dit noemen we datatest 2. Ook dit is een technische test. In deze test worden de volgende zaken bekeken:

  1. Aantal data rijen (dus alles exclusief de 5 kopregels) in het CSV bestand vergelijken met het aantal rijen in de BAW staging tabel.
  2. Inhoud van kolommen controleren met verwachting in de BAW staging tabel.
  3. Tellen van het aantal rijen in de BAW eindtabel. Dit is het aantal rijen in de staging tabel + 1 voor de ‘Unspecified’ rij.
  4. Inhoud van de kolommen controleren, waarbij ook gekeken moet worden naar “vertalingen”.

Correctheid van data bepalen met behulp van standaard BI Applications dashboards en enkele zelfgemaakte analyses. Dit noemen we de aansluitingstest. Dit is een inhoudelijke test om te zien of alle data en tellingen kloppen.

Voor het uitvoeren van deze test is functionele kennis over het te testen domein nodig.

Ketentest uitvoeren, waarbij de complete keten van data extractie, transport van bestanden, upload in BI Applications inclusief ‘scheduling’ van deze onderdelen wordt getest.

Voor het uitvoeren van deze testen zijn zeker 5 cycli nodig:

  • 2 cycli voor het uitvoeren van datatest 1 en 2 (niet alles gaat in 1 keer goed).
  • 2 cycli voor de aansluitingstest (niet alles gaat in 1 keer goed).
  • 1 cyclus voor de ketentest.

Inregelen proces ‘vaste stroom’

Voor het (dagelijks) verwerken van gegevens uit uw bronsysteem in BI Applications is het nodig om een proces in te richten. Onderstaande tabel geeft een aantal processtappen weer, waarvan alle stappen behalve 5 door uzelf geregeld moeten worden.

bia-ua-tabel2

Optioneel ‘customizations’ doorvoeren

Tot slot kunt u besluiten om bepaalde wijzigingen in de BI Applications standaard aan te brengen, de zogenaamde ‘customizations’ of het zogenaamde maatwerk.

Dit traject zal niet veel anders verlopen dan bij een implementatie bovenop een ERP bronsysteem.

Reacties zijn gesloten.