Migration de données SAP LSMW Partie2

Bonjour !

Voici la deuxième partie sur LSMW.

Si vous n'avez pas lu la partie 1, ou si vous souhaitez vous rafraîchir la mémoire, vous pouvez la consulter ici : Partie 1

Nous en étions à la fin de la construction de notre programme de migration, tout était normalement configuré pour pouvoir utiliser le programme de migration dans le but de créer de nouveaux équipements.

Je passe l'étape Maintain Fixed Values, Translations, User-Defined Routines car elle n'est pas nécessaire dans notre cas, je reviendrais dessus dans un autre tutoriel lorsque je l'aurais testé (Vous pouvez trouver des informations dans l'aide SAP : help.sap : user-defined routines si vous souhaitez creuser).

Reprenons : vous avez déjà fait lors de la partie 1 l'essentiel du travail, à savoir :

• Définir le type d’objet à utiliser pour la reprise de données. 
• Définir les noms des structures sources.
• Définir les zones qui composent les structures sources.
• Définir les relations entre la/les structures sources et la/les structures cibles.
• Définir les relations entres les zones des structures sources et les zones cibles, avec règles de conversion si besoin.

Passons maintenant aux étapes restantes : 

• Spécifier le chemin du fichier source et définir les fichiers intermédiaires de lecture et de conversion du/des fichiers sources.
• Lire les données.
• Convertir ces données.
• Lancer l’intégration des données avec le mode correspondant à l’objet choisi pour la reprise de données (Batch Input, Direct Input, génération d’iDoc, etc.).

II - Exécution du programme de reprise LSMW

       1. Spécification du chemin du fichier source

Lors de cette étape, vous pourrez choisir le répertoire ou sera placé votre fichier (ou vos fichiers), afin qu'il puisse être lu par SAP.

Pour ce programme de reprise, le fichier source resemble à ça :

En première ligne on trouve le nom des colonnes, puis sur les lignes suivantes, les valeurs obligatoires pour la création de l'équipement. Le séparateur doit être le même partout. Il faut faire attention à prendre un séparateur qui ne risque pas de se retrouver dans une des valeurs de lignes. Si par exemple la désignation de l'équipement peut contenir un point-virgule, il faut donc éviter de le choisir comme séparateur.

Le nom du fichier source sera à placer dans une des deux zones Legacy Data. Je teste actuellement en local, sur mon PC donc, je vais placer le fichier source sur la première ligne "On the PC (Frontend)". Double cliquer sur la zone ou choisir Nouveau.

 Vous pouvez effectuer quelques réglages, tels que le choix du délimiteur (aucun séparateur, virgule, point-virgule, ...), la structure du fichier (le fichier comprend le nom des champs au début du fichier, ...) etc pour que votre fichier soit correctement interprété. Vous pouvez commencer par sélectionner le chemin qui mène au fichier en cliquant sur le matchcode de la première zone de saisie "File".

Il faut sélectionner le radio bouton "Semi-Colon" dans la section "Delimiter", et cocher dans la section "File Structure" le matchcode "Fields Names at Start of File".

Après validation, vous pouvez voir les modifications prises en compte pour le fichier source.

Les zones Imported Data et Converted Data sont des noms automatiquement générés, avec des extensions .lsmw.read et .lsmw.conv. Je pense qu'il s'agit de fichiers temporaires SAP, qui permettent de gérer les données du fichier source dans SAP. Ils serviront pour les étapes de lecture et de conversion des données.

En résumé on a lecture du fichier source, qui aliment le fichier .lsmw.read, qui alimente ensuite le fichier .lsmw.conv, qui sert lui-même à la suite du traitement.

Après avoir terminé l'attribution du fichier et ses réglages, sauvegarder et revenir au menu principal.

L'étape qui suit, Assign Files, se fait normalement automatiquement, il n'y a alors rien à toucher. Sinon il faut attribuer le fichier source à la structure source correspondante.

Le nom du fichier source est associé à la structure source correspondante :

Sauvegarder et revenir à l'écran des différentes étapes pour commencer la lecture du fichier source.

       2. Lecture des données

L'étape Read Data signifie le lancement de la reprise de données. Un fichier source vous a été transmis, et vous avez normalement tous les éléments en votre possession pour commencer la reprise de données.

Cliquer sur cette étape vous emmènera sur l'écran suivant :

Pour lire toutes les données du fichier, contentez-vous de cliquer sur exécuter. Les zones pour "Transaction Number" servent apparemment à limiter les données leurs dans l'optique de tests : cela correspondrait aux numéros de lignes (par exemple de 2 à 10). Les deux cases à cocher correspondent à des réglages sur les valeurs et les dates.

Lorsque l'on exécute la phase Read Data, lors de la première lecture sur votre programme de migration, une fenêtre de sécurité apparaît pour confirmer l'accès au fichier à lire. Vous pouvez choisir plusieurs options, limitant plus ou moins les autorisations d'accès. Libre à vous de choisir ce qui convient le mieux, suivant les indications du client.

Après avoir validé, le fichier est lu par SAP, qui génère le fichier en .lsmw.read. Un report s'affiche en fin de lecture pour vous informer du taux de succès de la lecture.

Ce report liste les informations utiles, telles que :

• les fichiers sources listés, leur lecture et leur écriture ou non dans le fichier généré par SAP (.lsmw.read)
• le nombre de lignes (transactions) lues
• le nombre d'enregistrements (fichiers) lus
• le nombre de transactions écrites
• le nombre d'enregistrement (fichiers) écrits

Une fois cette étape terminée, cliquer sur précédent, pour revenir à l'écran des étapes de migration.

Vous pouvez si vous le désirez, afficher les informations lues, pour avoir un aperçu de la façon dont elles ont été interprétées par SAP. Cela sert notamment lors des premiers tests, pour d'éventuels ajustements. Pour cela il faut alors sélectionner l'étape Display Read Data.  Vous pouvez tout de même continuer si certaines lignes ne sont pas écrites, elles ne seront tout simplement pas prises en compte lors du traitement suivant.

Une popup apparaît avec différentes informations. On retrouve le nom du fichier .lsmw.read. Il est possible de choisir les lignes qui nous intéressent. Valider.

Un report apparaît alors, sous forme de tableau. Il comporte le numéro de ligne, le fichier source et ce que contient la ligne. La lecture qu'on peut en faire peut manquer de clarté, car toutes les infos sont agglomérées. Pour disposer d'un affichage plus clair, vous pouvez cliquer sur la ligne qui vous intéresse.

L'affichage est alors plus clair, puisqu'il reprend la structure du fichier source avec le détail des champs et leur valeur.

Aucune manipulation n'est possible ici, cela ne sert qu'à l'affichage. Si vous constatez des erreurs dans la lecture des données, vous pouvez corriger le fichier source, et relancer le programme de reprise à l'étape Read Data.

Sinon vous pouvez passer à l'étape suivante : conversion des données.

       3. Conversion des données

L'étape de conversion des données est maintenant possible, après l'étape de lecture.

Le fonctionnement est simple car il est le même que l'étape précédente, vous pouvez donc l'éxecuter de la même manière. Un report s'affiche en fin de traitement, avec la même forme : lignes lues, lignes écrites, etc.

Si tout s'est bien passé, vous pouvez afficher les infos converties, sinon vous pouvez analyser les erreurs de conversion, et corriger le fichier source, ou la façon dont la zone de la structure source est alimentée en conséquence. Il suffira alors de reprendre à l'étape Read Data. Vous pouvez tout de même continuer si certaines lignes ne sont pas écrites, elles ne seront tout simplement pas prises en compte lors du traitement suivant.

L'affichage des informations converties se fait de la même manière que les informations dans l'étape Display Data. On retrouve la même popup, mais qui exploite le fichier généré .lsmw.conv.

Valider. Vous retrouvez alors un tableau, avec le même comportement que précédemment. Un affichage général de toutes les lignes converties, et quand on clique sur une des lignes, l'affichage détaillé de cette ligne. 

Les infos converties sont adaptées au format de la structure source, et permettent donc d'avoir un aperçu de la transformation qu'a pu subir telle ou telle donnée.

Cette étape est alors terminée.

       4. Création et lancement du Batch-Input

Après avoir lu le fichier source et l'avoir converti, les donnéees sont alors prêtes pour être traitées par le programme de reprise. Il s'agit ici de la dernière étape du traitement. Suivant le type d'objet choisi lors de l'étape 1 de création du programme de reprise, des étapes peuvent s'ajouter ou se soustraire du déroulement du programme. Dans le cas de cet exemple, l'objet utilisé passe par un traitement en Batch Input, qui simule la transaction IE01, création d'un équipement.

L'écran qui s'affiche pour l'exécution de la dernière étape comporte de nombreuses informations. Je vais essayer de les décrire section par section.

Le mode de traitement

Il existe 3 modes de traitement :

• Dossier BDC

Code indiquant qu'un groupe BDC ou un dossier doit être créé. Marquez cette zone si vous souhaitez créer un groupe BDC ou un dossier. C'est cette option qui est cochée par défaut avec l'objet utilisé en étape 1. La LSMW permettant la reprise de données en masse, la création d'un dossier BDC est un avantage. La reprise de données, qui peut prendre beaucoup de temps suivant les volumes, peut alors être reporté à un moment où la charge système est moins importante (la nuit etc.).

• Mode transaction d'appel souhaité

La transaction à laquelle se rapportent les données d'entrée devrait être exécutée à l'aide d'une transaction d'appel. Les résultats sont connus immédiatement. Vous pouvez les afficher sous forme de protocole.

• Direct Input

La transaction à laquelle les données d'entrée font référence doit être exécutée avec la procédure direct input. Les données sont immédiatement reprises. Marquez cette zone avec un x si vous souhaitez que la procédure direct input soit utilisée pour la reprise des données. Les contrôles nécessaires auxquels doivent être soumises les données à transférer doivent être exécutés et doivent vous garantir que les résultats du transfert des données sont corrects.

Le format de fichier.

Le fichier source peut être sous format texte ou format binaire.

Ici je n'ai rien touché, le format du fichier étant sous format texte.

L'accès au fichier : source.

Trois radio boutons sont disponibles :

• Serveur de présentation

Code indiquant que le fichier source est enregistré sur une machine frontale locale (p.ex., un PC ou une station de travail UNIX) et non sur un serveur d'applications (p.ex, base de données UNIX). C'est cette option qui est logiquement cochée pour notre exemple. Le fichier source étant placé sur mon bureau, le nom du fichier physique est renseigné. 

• Serveur d'application

Fichier Unix sur un serveur d'application. Code indiquant que le fichier est un fichier de serveur d'application et non un fichier du serveur de présentation local (PC, par exemple).

• Données test/INDX,PM

SAPINDX - la source est SAP DATABASE INDX(PM) clé ID% %. Le fichier se situe dans la base de données interne SAP INDX. Voir la commande ABAP: EXPORT TO DATABASE INDX(xx) ID xxxxxx

Vous devez exporter la INT_TAB EXPORT vers DATABASE INDX(PM).
Vous pouvez sélectionner l'ID de votre choix.

L'accès fichier : sauvegarde enreg. de données erronées.

Les mêmes options que la section précédente. Il semble que cela serve à l'enregistrement des données erronées, sûrement dans le but de comprendre les erreurs et de pouvoir savoir où corriger dans le fichier source.

Le mode de la transaction d'appel.

Lorsque le mode de traitement sélectionné est "Transaction d'appel", il est possible de sélectionner le mode d'exécution : A pour afficher toutes les boîtes de dialogue et voir ainsi toutes les étapes, E pour afficher uniquement les endroits où des erreurs de saisie sont détectés, N pour exécuter la transaction en arrière-plan. Cette option ici ne nous intéresse pas, n'étant pas dans le mode de traitement qui correspond.

Journal des erreurs sert à avoir un listing des erreurs détectées et Sauveg.trans.erron. enregistre les lignes provoquant des erreurs.

Bizarrement, j'ai du cocher la deuxième option, qui doit donc être prise en compte pour le mode de traitement dossier BDC (ou peut-être qu'il s'agit d'un petit bug SAP).

Le dossier BDC

Enfin pour le mode dossier BDC, la possibilité de choisir le nom du dossier, l'ID de l'utilisateur qui génère le fichier. Bloquer jusqu'à permet de déterminer la date à laquelle le dossier Batch peut être exécuté. Le code de suppression indique si le dossier BDC doit être effacé de la liste après son traitement.

Exécution du dossier BDC.

Si tout va bien, lorsque vous exécutez l'étape de reprise des données, vous arrivez sur l'écran des protocoles du dossier BDC. Si tout est vert, alors votre dossier BDC est bien crée et il ne vous reste plus qu'à l'exécuter. Sinon vous pouvez analyser les messages d'erreur en rouge pour essayer de comprendre d'où viennent les éventuels problèmes.

Si tout s'est bien passé, vous pouvez lancer la transaction SM37, afin de gérer l'exécution de votre dossier BDC généré.

Il apparaît normalement dans la liste des dossiers à exécuter.

Sélectionner votre dossier et cliquer sur exécuter.

Une popup s'affiche alors, vous proposant plusieurs options. Là tout dépend de ce que vous souhaiter observer. Si vous avez confiance en votre programme de reprise, ou/et si vous avez des gros volumes à traiter, vous pouvez lancer en arrière-plan.

Une fois choisies vos options, vous pouvez lancer l'exécution du dossier.

Après fin du traitement, dont la durée varie selon la complexité et le volume de données à traiter, vous saurez si la transaction s'est bien déroulée.

En cas de succès, le nombre de transactions correspondantes réussies apparaît dans la colonne titrée d'une icône succès, sinon c'est l'éclair blanc sur fond rouge.

Un double clic sur l'élement qui vous intéresse vous emmène sur le détail du dossier, et vous donne les informations nécessaires à la compréhension de ses erreurs, ou de ses succès.

Dans l'onglet de droite, "Protocole", vous disposez des messages permettant de distinguer les différentes étapes du traitement.

III - Contrôle de la bonne création des données.

Votre programme de reprise s'est bien exécuté ? C'est le moment de vérifier la cohérence des informations, chose plus ou moins simple à réaliser suivant le programme de reprise exécuté. Ici il s'agit d'une simple création d'équipement, on peut donc aller sur la transaction IE03 pour contrôler si l'équipement a correctement été créé.

Lors du lancement de la transaction d'affichage d'équipement, le dernier équipement créé apparaît dans la zone de saisie.

Lorsqu'on l'affiche, on constate que les informations sont bonnes. Le programme de reprise fonctionne donc correctement !

On constate ici que les informations de l'équipement correspondent avec les informations du fichier source.

IV - Conclusion

La création d'un programme de reprise nécessite de la patience, de la précision.

LSMW est un outil à connaitre pour la reprise de données, car la création d'un fichier source reste simple.

La correspondance entre fichier source et structure cible est simple à mettre en place, si peu de règles de conversion entrent en jeu. 

Le mécanisme d’exécution de la reprise est séquentiel, ce qui permet à chaque étape de valider les données (lecture source, conversion, exécution).

En mode batch-input, comme dans cet exemple, il est possible d'analyser les erreurs afin de trouver la source du problème.

Cet outil permet la reprise de données de base, mais sert également à la modification de masse, ou autre utilisation, sachant qu'il est possible d'enregistrer une transaction afin de l'utiliser dans un LSMW.

LSMW est complètement transverse dans SAP (pas limité à un ou plusieurs modules)