Avec S/4HANA et les CDS (Core Data Services) views, SAP a beaucoup modifié la manière dont les données peuvent être utilisées à partir de son nouvel ERP et cela peut notamment influencer les usages des utilisateurs BW.

Chess

En effet, on constate désormais de nombreuses fonctionnalités permettant l’extraction de données dans les CDS views, et cela pourrait avoir de gros impacts sur la manière dont les chargements de données vont s’effectuer dans les entrepôts de données comme BW/4HANA.

Se pose donc la question de savoir si CDS view d’extraction ont le potentiel de remplacer les extracteurs standards de S/4HANA ?

Qu’est ce qu’une CDS view et comment ça marche ?

Avec l’arrivée de S/4HANA les CDS views ont été introduites et permettent, via l’utilisation d’un langage spécifique (ni SQL ni ABAP) de développer un modèle de données pouvant servir à la consommation de données dans du reporting ou bien, dans notre cas, à créer des extracteurs de données.

Voici un exemple de CDS view full permettant d’extraire des données de postes de commandes de vente (Left Join entre VBAK & VBAP) :

@AbapCatalog.sqlViewName: 'ZT_SD_CDES_FULL'
@AbapCatalog.compiler.compareFilter: true
@AbapCatalog.preserveKey: true
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: 'ZTEST_SD_CDES_FULL'
@Analytics.dataExtraction.enabled: true
@Analytics.dataCategory: #FACT

define view ZTEST_SD_CDES_DELTA as select from vbap as P
left outer join vbak as K on P.vbeln = K.vbeln
{
    key P.vbeln as SalesDoc,
    key P.posnr as SalesDocItem,
    P.matnr as Material,
    P.kwmeng as Quantity,
    P.vrkme as Unit
}

Quelques explications sur les annotations majeures :

  • @AbapCatalog.sqlViewName : le nom de la vue
  • @Analytics.dataExtraction.enabled: true : permet d’indiquer que la vue sert à l’extraction de données et sera donc utilisable via le framework ODP
  • @Analytics.dataCategory: #FACT : indique que l’on traite des données transactionnelles avec des dimensions et des ratios

Comment paramétrer une CDS view pour l’extraction des données en Delta ?

Très rapidement vous aurez besoin d’extraire vos données en delta, les volumes de données étant généralement trop importants pour des extractions full quotidiennes.

Paramétrage de la CDS View

Pour cet exemple nous souhaitons ramener des données de la table VBAP (postes de document de vente) dans BW/4HANA.

Cependant la table VBAP ne possède pas de date de modification qui nous permettrait de gérer les chargements en Delta.

Par contre la table VBAK (entête de document de vente) contient la zone “UPD_TMSTMP” qui capte la modification de la commande ou de l’un de ses postes.

Nous allons donc utiliser ce timestamp pour déterminer les postes de commandes modifiés ou dont la commande de vente à été modifiée afin de faire remonter ces changements dans BW.

Modification des annotations pour la gestion du delta

Afin de gérer l’extraction en delta, nous allons créer une CDS view ‘ZT_SD_CDES_DELTA’ :

@AbapCatalog.sqlViewName: 'ZT_SD_CDES_DELTA'

Puis, pour gérer le delta, nous allons ajouter la ligne suivante pour que la date/timestamp ‘LastChangedAt’ soit utilisée pour définir la date/timestamp de modification utilisé dans le mécanisme de chargement en Delta :

@Analytics.dataExtraction.delta.byElement.name: 'LastChangedAt'

Ainsi on pourra renommer le champ “UPD_TMSTMP” en “LastChangedAt” pour que cette date soit récupérée.

Enfin, nous allons paramétrer la CDS view afin qu’elle puisse gérer les suppressions de données et que l’on puisse ainsi effectuer les suppressions des postes dans les objets de BW/4HANA.

Pour cela nous allons rajouter l’annotation suivante :

@Analytics.dataExtraction.delta.byElement.detectDeletedRecords: true

Point d’attention : l’annotation “detectDeletedRecords” est très coûteuse en performance donc il faut éviter de traiter de trop gros volumes de données.

Une fois ces modifications effectuées vous obtiendrez une CDS View complète comme ci-dessous et permettant l’extraction en delta via le framework ODP :

@AbapCatalog.sqlViewName: 'ZT_SD_CDES_DELTA'
@AbapCatalog.compiler.compareFilter: true
@AbapCatalog.preserveKey: true
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: 'ZTEST_SD_CDES_DELTA'
@Analytics.dataExtraction.enabled: true
@Analytics.dataCategory: #FACT
@Analytics.dataExtraction.delta.byElement.name: 'LastChangedAt'
@Analytics.dataExtraction.delta.byElement.detectDeletedRecords: true
 
define view ZTEST_SD_CDES_DELTA as select from vbap as P
left outer join vbak as K on P.vbeln = K.vbeln
{
    key P.vbeln as SalesDoc,
    key P.posnr as SalesDocItem,
    P.matnr as Material,
    P.kwmeng as Quantity,
    P.vrkme as Unit,
    @Semantics.systemDateTime.lastChangedAt: true
    K.upd_tmstmp as LastChangedAt
}

Le premier DTP lancé côté BW/4HANA s’occupera de l’init, les suivants des delta successifs.

Avantages et inconvénients

SAP n’a toujours pas livré d’extracteurs en CDS pour remplacer les extracteurs historiques. Pour connaitre l’état des datasources utilisées dans S/4HANA, vous pouvez vous reporter à la note suivante : https://launchpad.support.sap.com/#/notes/2500202

Pour remplacer les extracteurs standards de S/4HANA par des CDS views d’extraction nous constatons donc qu’il faut des dates/timestamp de modifications sur de nombreuses tables afin de pouvoir gérer le Delta.

Cela peut engendrer une analyse longue de l’ensemble des extracteurs standards car ces derniers sont le résultat de consolidations de nombreuses tables sources.

Cela va donc nécessiter un investissement considérable en terme de temps d’analyse des données pour trouver les dates pertinentes à la mise en place du Delta.

Pour résumer nous avons fait un comparatif des deux solutions avec les avantages et les inconvénients :

Extracteurs standardCDS view d’extraction
AvantagesToutes les jointures et les différents liens entre les tables/structures sont déjà paramétrés.

L’activation de ces extracteurs est simple et rapide
Les modifications à apporter dans la CDS view pour modifier les zones à importer se font rapidement
InconvénientsLes inits impliquent dans le cas des 2LIS une étape supplémentaire de restructuration (alimentation des setup tables)

Les modifications à apporter peuvent être complexes et chronophages car elles nécessitent la restructuration pour les 2LIS
Il faut une analyse des tables sources pour trouver les dates/timestamp nécessaire à la mise en place des chargements en Delta

Cette méthode s’adresse à des développeurs qui doivent maîtriser un nouveau langage proche d’un mélange entre le SQL et l’ABAPLa modélisation influence très grandement les performances

L’approche CDC

Depuis les versions cloud 1905 et on-premise 1909 une nouvelle méthode d’extraction Delta est apparue grâce au Change Data Capture (CDC).

Cette méthode permet aux développeurs de capter les modifications sur les données données dans les tables de l’ERP en ne récupérant seulement les clés relatives à ces dernières.

Cette méthode est très proche de celle utilisée actuellement pour le SLT.

Ainsi, lorsqu’une modification est effectuée, la clé est de nouveau remontée (avec l’ensemble des champs concernés par la modification) dans l’extracteur et la mise à jour peut se faire dans BW. Vous pouvez donc vous affranchir d’un champ pertinent pour le delta qui certaines fois… n’existe pas !

N’ayant pas eu l’occasion de tester cette méthode nous sommes donc très optimistes sur les capacités d’extractions qui vont nous être proposées dans les prochains mois !

Conclusion

Les CDS views d’extraction proposent des fonctionnalités très intéressantes pour l’extraction de données et les évolutions continues sur ces objets annoncent de belles choses.

Cependant il n’existe pas encore de CDS views standards permettant de remplacer les extracteurs standards et de gérer l’ensemble des liens qui y sont fait actuellement.

Pour utiliser les CDS view d’extraction il faudra donc plus de temps d’analyse et de développement au début de la phase d’extraction des données afin de bien reproduire les extracteurs standards et de les rendre maintenables par la suite.

Laisser un commentaire