Récupérer des données en provenance de SAP vers une base SQL Server peut parfois s’avérer compliqué suivant la version de SAP utilisée. Nous allons voir ici une façon de faire qui utilise un logiciel tiers « Xtract de l’éditeur Theobald Software ». Xtract va ainsi servir d’intermédiaire entre SAP et SQL Server.

1. Extraire via Xtract

A l’aide d’Xtract, il est possible de récupérer différents types de données SAP tels que :

Nous verrons ici des Xtract des deux types suivants : « Tables » et les « Delta Q ».

1.1 Extraction d’une table

L’extraction d’une table se fait très simplement en indiquant la table puis en spécifiant les colonnes à extraire ainsi que les potentiels filtre à appliquer. Il est aussi possible, via les paramètres, de spécifier une clef primaire ainsi que la taille des paquets (nombre de ligne) à extraire pour une extraction donnée :

Le choix du paramétrage de la destination se fait là aussi simplement :

Différentes options étant proposées pour la préparation et l’utilisation de la donnée, il est possible de récupérer la donnée de la façon souhaitée :

Il ne reste maintenant plus qu’à lancer l’extraction pour que la donnée soit à disposition dans notre table SQL.

1.2 Extraction à partir d’une datasource

L’extraction depuis une datasource peut quant à elle se faire soit de la même manière que les tables (on extrait l’ensemble de la donnée à chaque fois), soit en mode delta. Cette seconde possibilité peut permettre, par exemple, de résoudre des problèmes de durée d’extraction ou d’éviter des problèmes de surcharge machine lorsque la volumétrie devient trop importante.

Afin de n’extraire que les données modifiées, il est nécessaire de mettre en place deux Xtracts dans deux tables SQL différentes (XXX_DELTA et XXX_FULL par exemple) et un process Stambia qui va consolider les données. Le premier Xtract sera à configurer en mode Full et le second en mode Delta.

Dans un premier temps, on crée les deux Xtract qui ont la même base, seul le « Udpdate Mode » change , « D – Delta Update » pour l’un et « F – Full » pour l’autre :

Pour les deux Xtracts, au niveau des paramètres il est nécessaire :

Dans les « Extraction Settings », d’activer l’option « Add Serialization Info to Output » ce qui va ajouter les deux colonnes « DataPackageID » et « RowCounter » dans la table SQL de destination. Ces colonnes nous permettrons par la suite de déterminer quelle est la dernière valeur modifiée :

Dans les « General Settings », de sélectionner les champs composants la clef primaire :

Enfin, lors de la configuration de la destination, on configure les tables en « Truncate Or Create » :

Une fois cela fait, on édite l’Xtract Delta et on clique sur « Activate » afin d’ajouter un abonné sur le datasource et ainsi permettre la récupération des données modifiées uniquement :

Un message nous indique que l’abonné a bien été créé.

Une fois l’abonné créé, on va initialiser ce dernier. Pour cela, on choit le mode « S – Delta Init (without data) » et on lance l’extraction à l’aide de « Run » :

On repasse ensuite l’Xtract dans le mode « D – Delta Update » et on passe sur second Xtract de type Full que l’on va lancer à son tour afin d’initialiser notre table SQL XXX_FULL.

Une fois l’extraction Full terminée, notre initialisation est finie. A l’avenir, il ne sera nécessaire de lancer que l’Xtract en mode Delta et ce à la fréquence souhaitée.

A la fin de chaque extraction Delta une fois que la table XXX_DELTA est alimentée, il est nécessaire de consolider la table XXX_FULL à partir des nouvelles données via un mapping Stambia. Etant donné qu’il est possible qu’une donnée ait été modifiée plusieurs fois, il s’avère nécessaire de déterminer qu’elle est la dernière modification.

La requête ci-dessous permet cette détermination. La valeur 10000000 est arbitraire, il faut juste qu’elle soit supérieure au nombre total de ligne de notre table XXX_FULL et que cela reste toujours le cas :

CREATE VIEW dbo.XXX_DELTA_DATA
SELECT [DataPackageID]
      ,[RowCounter]
      ,[KEY1]
      ,[KEY2]
      ,[COL1]
      ,[COL2]
      ,[COL3]
FROM [dbo].[XXX_DELTA] SRC
INNER JOIN (
      SELECT [KEY1]
            ,[KEY2]
            ,MAX(DataPackageID * 10000000 + RowCounter) AS IDENT
      FROM [dbo].[XXX_DELTA]
      GROUP BY [KEY1]
              ,[KEY2]
) SEL
ON SEL.[KEY1] = SRC.[KEY1]
AND SEL.[KEY2] = SRC.[KEY2]
AND IDENT = (SRC.DataPackageID * 10000000 + SRC.RowCounter)

Le mapping Stambia permettant la mise à jour de la table XXX_FULL est un simple mapping entre la source XXX_DELTA_DATA et la table de destination XXX_FULL avec comme clef, la clef primaire :

1.3 Lancement d’un Xtract via Stambia

Le lancement d’un Xtract dans Stambia peut se faire à l’aide d’un simple « Operating System Command » :

Ainsi, à l’aide d’un process Stambia générique et d’une table de paramétrage listant les Xtracts et leurs planifications, il est possible de mettre en place une solution d’ordonnancement des extractions et ce qu’elle que soit le type de donnée SAP (table, delta Q …).

Attention, dans le cas d’un Xtract Delta Q en mode Delta, il faudra aussi lancer un mapping Stambia consolidant la donnée.

2 Autres méthodes d’extraction depuis SAP

2.1 Activer le CDC

Une autre possibilité est d’activer le CDC (Change Data Capture) au niveau de la base de donnée SAP et de mettre en place un process, Stambia par exemple, permettant la consolidation des données afin d’avoir à disposition la donnée à jour sans avoir à requêter les tables SAP.

En cas de problème sur une partie du processus de mise à jour de la table (que ce soit côté CDC, processus de consolidation …), il risque d’être nécessaire de refaire une initialisation des données, chose impossible sans requêter la table SAP.

2.2 Utiliser le driver Stambia

Depuis quelques temps, Stambia permet d’interagir directement avec la base de donnée de SAP Hana à l’aide du SAP Hana JDBC driver :