Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
64 changes: 48 additions & 16 deletions markdownpages/profit/en/bi-models.md
Original file line number Diff line number Diff line change
Expand Up @@ -6,21 +6,53 @@ tags: BI, OData, bi-modellen
---

## Introduction
The BI models in AFAS Profit can be accessed via OData connectors.
OData connectors are interfaces that allow applications to exchange data in a standardized and secure manner using the OData protocol (Open Data Protocol).
The BI models in AFAS Profit can be accessed via OData connectors. OData connectors are interfaces that allow applications to exchange data in a standardized and secure manner using the OData protocol (Open Data Protocol).

## BI Models vs. GET Connectors
The BI models in AFAS Profit operate differently from GET connectors.
With GET connectors, data is generated and returned at the time of the request.
This can lead to longer wait times and performance issues with more complex GET connectors (where a lot of data from different tables needs to be combined).
In BI models, the data is pre-calculated and stored in a separate model, significantly improving performance when retrieving large amounts of data.
This makes BI models very suitable for reports and analyses involving large datasets.

## Server-Side Pagination
When you retrieve large amounts of data via an OData connector and do not include skip and top parameters in your query, server-side pagination will be applied.
This means the server returns the data in smaller chunks (pages) instead of all at once.
The server sends a response back, which includes a link to the next page of data. When there is no more data, no link is provided.

## Client-side pagination
You can also specify how many records you want to retrieve and from which record you want to start using the 'skip' and 'top' parameters.
You do not need to provide sorting because a fixed order is already maintained on the server side.
The BI models in AFAS Profit operate differently from GET connectors. With GET connectors, data is generated and returned at the time of the request. This can lead to longer wait times and performance issues with more complex GET connectors (where a lot of data from different tables needs to be combined). In BI models, the data is pre-calculated and stored in a separate model, significantly improving performance when retrieving large amounts of data. This makes BI models very suitable for reports and analyses involving large datasets.

## Versions of the BI models and redirects
The endpoints of the BI models remain consistent and unchanged. However, when you call the standard endpoint, a redirect is performed. It is important that your client follows this redirect to access the correct resource.

### Example
``` curl
https://12345.rest.afas.online/ProfitRestServices/bi/Verkoopomzet
```
This call will be redirected to the most recent version of this model, for example:
``` curl
https://12345.rest.afas.online/ProfitRestServices/bi/Verkoopomzet/v2/
```

## Pagination

### Client-side
You can specify how many records you want to fetch and from which record you want to start using the 'skip' and 'top' parameters. You don't need to provide sorting because the server already maintains a fixed order.

### Server-side
When you retrieve large amounts of data via an OData connector and do not include skip and top parameters in your query, server-side pagination will be applied. This means the server returns the data in smaller chunks (pages) instead of everything at once. The server sends a response that includes a link to the next page of data. When there is no more data, no link is provided.

## Creating BI models

When you create a BI model, this can be based on an **Existing BI model** or on a **Source table**.
If you choose *Existing BI model*, you get a copy which you can then adjust.
If you choose *Source table*, you select a source table from the list, for example **Financial mutations**.

The BI model editor opens; a **fact table** is automatically created in the model. You can now add fields from the source table to this fact table. This results in a single large table.

It is often more efficient not to include all fields in one fact table, but to build the model as a so-called **star schema**. You place values that occur frequently in a separate table (*dimension table*) and reference that dimension table from the fact table.

```
An example of this is the field DebtorName in Financial mutations. Suppose there are 150 mutations for one debtor. This debtor's name is: EenHeleLangeNaam B.V.

If you use only one fact table, that name will be stored 150 times in the table. If you create a dimension table with debtor names, each debtor name will only appear once. In the fact table you then store not the full name but a reference to the debtor name table, for example 115. The number of characters then goes from 21 to 3. This is much more efficient when transferring information.
```

### Adding a dimension table
You can add fields that can be expanded into the fact table, or you can include them as a new dimension. To do this, right-click the field and choose *New dimension* from the menu. A new dimension table is then created automatically. A reference to this dimension table is added in the fact table.
In Profit there are two options for adding a new dimension:
1. New dimension
2. New dimension (all values)

To explain the difference we use the example of DebtorName in Financial mutations again.
With option 1 only the debtor names that actually occur in the Financial mutations source table are added.
With option 2 all debtor names that are available in the environment are added, including names that do not occur in the source table.
65 changes: 50 additions & 15 deletions markdownpages/profit/nl/bi-modellen.md
Original file line number Diff line number Diff line change
Expand Up @@ -5,22 +5,57 @@ date: 2025-11-20
tags: BI, OData, bi-modellen
---


## Introductie
De BI-modellen in AFAS Profit kunnen worden uitgevraagd via OData-connectoren.
OData-connectoren zijn koppelstukken waarmee applicaties standaard en veilig gegevens kunnen uitwisselen via het OData-protocol (Open Data Protocol).
De BI-modellen in AFAS Profit kunnen worden uitgevraagd via OData-connectoren. OData-connectoren zijn koppelstukken waarmee applicaties standaard en veilig gegevens kunnen uitwisselen via het OData-protocol (Open Data Protocol).

## BI-modellen vs. GET connectoren
De BI-modellen in AFAS Profit werken anders dan de GET connectoren. Bij GET connectoren wordt de data op het moment van de aanvraag gegenereerd en teruggegeven.
Dit kan bij complexere GET connectoren (waarbij veel gegevens uit verschillende tabellen moet worden samengevoegd) leiden tot langere wachttijden en prestatieproblemen.
Bij de BI-modellen wordt de data vooraf berekend en opgeslagen in een apart model, waardoor de prestaties bij het opvragen van grote hoeveelheden data aanzienlijk verbeteren.
Hierdoor zijn BI-modellen zeer geschikt voor rapportages en analyses waarbij grote datasets betrokken zijn.

## Server side pagination
Wanneer je grote hoeveelheden data ophaald via een OData-connector en je geeft geen skip en top parameters mee in je query, dan zal er server side pagination worden toegepast.
Dit betekent dat de server de data in kleinere brokken (pagina's) teruggeeft in plaats van alles in ��n keer.
De server stuurt een response terug en in deze response zit een link naar de volgende pagina met data. Wanneer er geen data meer is, wordt er geen link meer meegegeven.

## Client side pagination
Je kunt ook zelf aangeven hoeveel records je wilt ophalen en vanaf welk record je wilt beginnen met de 'skip' en 'top' parameters.
Je hoeft hierbij geen sortering mee te geven omdat aan de server kant al een vast volgorde wordt aangehouden.
De BI-modellen in AFAS Profit werken anders dan de GET connectoren. Bij GET connectoren wordt de data op het moment van de aanvraag gegenereerd en teruggegeven. Dit kan bij complexere GET connectoren (waarbij veel gegevens uit verschillende tabellen moet worden samengevoegd) leiden tot langere wachttijden en prestatieproblemen. Bij de BI-modellen wordt de data vooraf berekend en opgeslagen in een apart model, waardoor de prestaties bij het opvragen van grote hoeveelheden data aanzienlijk verbeteren. Hierdoor zijn BI-modellen zeer geschikt voor rapportages en analyses waarbij grote datasets betrokken zijn.

## Versies van de BI-modellen en redirects
De endpoints van de BI-modellen blijven consistent en onveranderd. Wanneer je echter het standaard endpoint aanroept, wordt er een redirect uitgevoerd. Het is belangrijk dat je client deze redirect volgt om toegang te krijgen tot de juiste resource.

### Voorbeeld
``` curl
https://12345.rest.afas.online/ProfitRestServices/bi/Verkoopomzet
```
Deze aanroep wordt geredirect naar de meest recente versie van dit model zoals bijv:
``` curl
https://12345.rest.afas.online/ProfitRestServices/bi/Verkoopomzet/v2/
```

## Pagination

### Client side
Je kunt zelf aangeven hoeveel records je wilt ophalen en vanaf welk record je wilt beginnen met de 'skip' en 'top' parameters. Je hoeft hierbij geen sortering mee te geven omdat aan de server kant al een vaste volgorde wordt aangehouden.

### Server side
Wanneer je grote hoeveelheden data ophaald via een OData-connector en je geeft geen skip en top parameters mee in je query, dan zal er server side pagination worden toegepast. Dit betekent dat de server de data in kleinere brokken (pagina's) teruggeeft in plaats van alles in ��n keer. De server stuurt een response terug en in deze response zit een link naar de volgende pagina met data. Wanneer er geen data meer is, wordt er geen link meer meegegeven.


## BI-modellen creëren
Wanneer je een BI-model maakt, kan dit op basis van een **Bestaand BI-model** of op basis van een **Brontabel**.
Als je kiest voor een *Bestaand BI-model*, krijg je een kopie die je vervolgens kunt aanpassen.
Als je kiest voor *Brontabel*, selecteer je een brontabel uit de lijst, bijvoorbeeld **Financiële mutaties**.

De BI-modeleditor opent zich; er wordt automatisch een **feitentabel** aangemaakt in het model. Je kunt nu velden vanuit de brontabel toevoegen aan deze feitentabel. Zo ontstaat één grote tabel.

Het is vaak efficiënter om niet alle velden in één feitentabel op te nemen, maar het model op te bouwen in een zogenoemd **ster-model**. Je plaatst waarden die vaak terugkomen in een aparte tabel (*dimensietabel*) en verwijst vanuit de feitentabel naar die dimensietabel.

```
Een voorbeeld hiervan is het veld Debiteurnaam in Financiële mutaties. Stel dat er voor één debiteur 150 mutaties zijn. Deze debiteur heet: EenHeleLangeNaam B.V.

Als je slechts één feitentabel gebruikt, wordt die naam dus 150 keer in de tabel opgenomen. Kies je er daarentegen voor om een dimensietabel met debiteurnamen te maken, dan komt elke debiteurnaam maar één keer voor. In de feitentabel sla je dan geen volledige naam op, maar een verwijzing naar de debiteurnamentabel, bijvoorbeeld 115. Het aantal karakters gaat dan van 21 naar 3. Dit is veel efficiënter bij de overdracht van informatie.
```

### Dimensietabel toevoegen
Je kunt velden die uitgeklapt kunnen worden aan de feitentabel toevoegen, maar je kunt ze ook als nieuwe dimensie opnemen. Dit doe je door met de rechtermuisknop op het veld te klikken en in het menu te kiezen voor Nieuwe dimensie. Er wordt dan automatisch een nieuwe dimensietabel gemaakt. In de feitentabel wordt een verwijzing naar deze dimensietabel opgenomen.
In Profit zijn er twee opties voor het toevoegen van een nieuwe dimensie:
1. Nieuwe dimensie
2. Nieuwe dimensie (alle waarden)

Om het verschil uit te leggen gebruiken we opnieuw het voorbeeld van Debiteurnaam in Financiële mutaties.
Bij optie 1 worden alleen de debiteurnamen toegevoegd die daadwerkelijk in de brontabel Financiële mutaties voorkomen.
Bij optie 2 worden alle debiteurnamen die in de omgeving beschikbaar zijn toegevoegd, dus ook namen die niet in de brontabel voorkomen.