Semaine 1-2

• Installer une instance HANA Database (qui est une machine virtuelle) pour accéder aux données et aux schémas, et la configurer.
• Tutorial pour HANA Architecture et Hana Data Models
• Créer un simple projet de XS (lié au javascript) et commencer à pratiquer avec du javascript dans HANA Studio basé sur Eclipse
• Lecture d’un document sur Data Lineage rédigé par Eric Simon.

Semaine 3

• Tutorials
• Pratiquer avec les Hana Data Models comme Attribute View, Analytical View et Calcualtion View. J’ai mis un peu de temps pour comprendre le schema de STAR (lié au notion OLAP Cube)
• Faire la pratique de codes de javascript
• Discuter avec Eric Simon sur l’ensemble de stage (l’architecture de Proof of Concept (POC), le résultat attendu etc.)
• Lire des documents et des codes sur Data Lineage. Ces documents expliquent les notions nécessaires pour concevoir l’architecure de POC.
  L’utilisation de “Graph” est essentiel pour le Data Lineage et la traçabilité. Les codes appartiennent aux définitions de graph en langage SQL.
  Par exemple, “CREATE TABLE NODES …”, “CREATE TABLE EDGES …” etc.
• Transformer des codes SQL existant en langage de HANA, i.e. Core Data Service Artifacts (.hdbdd, .hdbsequence, etc.)
• Dossier d’initialisation pour l’INSA de Lyon

Semaine 4

• Suite: Transformer des codes SQL existant en design objects dans HANA:
• Des définitions de tables et des séquences (par exemple ADD_EDGES(…) etc.)
• Des procéures (par exemple ADD_TABLE_NODE(…), ADD_LINEAGE(…) etc..)
• Faire des tests pour vérifier que les procédures fonctionnent bien. Les test ont été construit en XS Unit.
• Lire des documents et des codes sur Graph Engine Calculation Scenario

Semaine 5

• Pratiquer avec Graph Engine. Dans Graph Engine, on crée d’abord un scénario de calcul (on décide à partir de quel nœuds le parcours de graphe commence, filtrage sur les liens et les nœuds, “outgoing edges” ou “incoming edges” etc.) et en executant le scénario, on récupère le résultat du parcours. Le parcours de graphs en largeur (Breadth First Search):
• Implémentation d’une requête de type Impact analysis du coté Developpeur
• Création d’une procédure qui crée un calcul de scénario
• Création d’une procédure qui calcule le résultat du parcours du graphe. Le résultat est composé de 3 tables (NODES, EDGES et DETAILS). Donc le résultat est aussi un graphe mais plus compact.
• Réflechir sur l’implémentation d’une requête de type Impact analysis du coté Client.

Semaine 6

• Optimisation de l’implémentation de code d’une requête de type Impact analysis du coté Developpeur. Le valider avec des tests
• Réflechir sur l’implémentation d’une requête de type Impact analysis du coté Client. Je pense que j’ai trouvé une solution donc la semaine prochaine je vais l’implementer et le tester (discter avec mes tuteurs avant).
• Commencer à implémenter une requête de type Impact analysis du coté Client.
  Préparation des tests avec JS UNIT

Semaine 7

• Implémentation de code d’une requête de type Impact analysis du coté Client.
  Le valider avec des tests
• Voir le possibilité de visualisation. En ce moment, il y a 2 possibilités: Outil de Visualisation de Graph Engine et Galilei.
  • SAP Graphe Engine nécessite des tables de nœuds et d’arcs statiques (c’est-à-dire les tables doivent déjà exister dans la base de données)
  • SAP Galilei ne pose aucune restriction. Donc on peut lui fournir soit des tables statiques ou soit celles dynamiques (les tables (nœuds etc.) renvoyées/calculées par une procédure par exemple)
• L’utilisation de SAP Galilei pour le coté de visualisation afin d’afficher le graphe de sortie [presque fini]
  • On fournit à Galieli les données JSON que la procédure d’Impact Analysis renvoie