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

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’.

Maak een ‘data lineage’ in bijvoorbeeld een spreadsheet; 1 inleiding met alle benodigde CSV bestanden, en 1 per bestand

Logische naam domein Technische naam domein
Financial Statement Item ‘FIN_STMT_ITEM’
Gender ‘SEX_M_F’
Group Account ‘GROUP_ACCT’
Highest Degree of Education ‘HIGHEST_DEGREE’
Job ‘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:

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.

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.

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.