Quelquepart

Blog d'un développeur ABAP

Vous êtes ici : Accueil>Général

Général

Déménagement

Rédigé par Sébastien Hermann dans Général -

On garde les mêmes et on recommence !

Ouverture du nouveau site identique à l'ancien... mais en nouveau :)

Mots clés : aucun

PSA Maintenance - impossible d'accéder en modification

Rédigé par Sébastien Hermann dans Général -

Il arrive que malgré tous vos efforts, BW ne vous laisse pas modifier une entrée de PSA lors d’un chargement en erreur. Tout est pourtant bon au niveau des autorisations… Mais qu’en est-il du statut de chargement ?

- Il est rouge ! Me rétorquerez-vous probablement énervé par cette question, semble-t-il, idiote.

Sauf que le feu tricolore n’est qu’un résumé simpliste des différents statuts possibles d’un chargement. Pour BW il existe 25 statuts différents, et certains d’entre eux ne permettent pas de modification de la table PSA. Ce statut est stocké dans le champ AUFRUFER de la table RSMONICDP.

Voici la liste des statuts en question :

60Insert/update in database for transaction data
61Insert/update in database for texts
62Insert/update in database for master data
63Insert/update in database for hierarchies
70End of Processing

Si jamais vous êtes dans une situation semblable et que bidouiller la couleur du feu n'y change rien, vous avez juste à modifier le contenu de RSMONICDP (en y mettant le statut 66 par exemple). Comme par magie, la maintenance de PSA redevient possible. N'oubliez pas de remettre les statuts d'origine après modification de la PSA.

Une solution moins brutale consiste a supprimer des cibles toutes les demandes qui sont dans un des statuts bloquants. La PSA redeviendra modifiable, et ensuite vous pourrez "pousser" les données vers les cibles non mises à jour.

Activation de DSO un peu longue ? Quelques conseils...

Rédigé par Sébastien Hermann dans Général -

Un DSO (ou ODS pour BW3.x) qui s'active en 5 minutes, un autre avec la même volumétrie qui met plus de 2 heures... Ca ne vous est jamais arrivé ?

Voici quelques pistes pour essayer de résoudre ce problème.

  • En premier lieu, même si ca peut sembler une évidence, s'assurer que les statistiques de l'ODS sont bien à jour (transaction DB20).
  • Si cet ODS n'est pas utilisé pour le reporting, s'assurer que le flag "Reporting Bex" est décoché (ou l'option "SID Generation" n'est pas sur "during activation" en BI7). Dans le cas contraire, BW profite de l'activation des données pour générer/vérifier les SID de toutes les masterdata utilisées, ce qui peut prendre beaucoup de temps !
  • L'activation peut être longue si les tables de batch sont trop grosses car elles sont utilisées lors de l'activation. Pour s'en assurer il suffit de compter le nombre d'entrées sur la table TBTCO via SE16. Si plus de 100 000 entrées sont trouvées, il est conseillé de nettoyer ces tables via le programme RSBTCDEL2 (tcode SM65). Les admins sont sensés être au courant de cette procédure.
  • En dernier lieu, il est aussi possible de faire quelques ajustements de paramétrage des ODS, via la transaction RSODSO_SETTINGS. Ces ajustements peuvent être globaux pour le serveur ou restreint au seul ODS concerné. Cette transaction n'est accessible que sur SAP BI7.x. En version BW3.x, une version primitive existe toutefois : RSCUSTA2, mais elle ne permet que des réglages globaux.
    A noter : Il est aussi possible de modifier le nombre de processus en parallele pour l'activation directement depuis la variante dans la process chain (bouton "parallel processing")

Si les problèmes persistent, alors une analyse plus poussée sera nécessaire. La note OSS 1392715 pourra alors s'avérer utile. Bon courage dans votre chasse aux performances !

Migration BW3 - BI7 : vous reprendrez bien un peu de hash ?

Rédigé par Sébastien Hermann dans Général -

Ce matin, j’étais tranquillement en train de m’occuper de ma migration, quand tout à coup l’un de mes chargements dump. Je suis interloqué car le dump apparait lorsque je lance l’infopackage, sur le mode actif. Pas en background comme cela arrive habituellement.

Log du dump :

Category : ABAP Server Resource Shortage
Runtime Errors : TSV_TNEW_PAGE_ALLOC_FAILED

What happened?
You attempted to extend an internal table, but the required space was not available.

Information on where terminated
Termination occurred in the ABAP program "SAPLRSSM_LOAD" - in "RSSM_RSSELDONE_READ". 
The main program was "RSAWBN_START ". 
In the source code you have the termination point in line 245 of the (Include) program "LRSSM_LOADU08".

Allant voir plus loin dans le log je me rend compte que le dump survient sur un select avec des conditions dynamiques.

Me voici donc partit pour débugger le tout. J’arrive rapidement à trouver la valeur des paramètres et après un petit tour dans SE16, je suis catastrophé. 6.8 millions d’entrées correspondent à cette sélection. Voici donc pourquoi le chargement dump. Ca fait un peu beaucoup de lignes à mettre dans une table interne...

En revanche j’ai du mal à m’expliquer pourquoi SAP fait ce chargement. La table RSSELDONE contient les paramètres de chargement de toutes les requests. Quel intérêt d’aller charger en mémoire tout l’historique des paramètres de sélection sur ma source ???

Après arrachage de poignées de cheveux et traitage de noms d’oiseaux des développeurs de Waldorf, j’ai fini par comprendre. SAP a ajouté un hash code dans cette table. Il n’était pas présent sur la version 3.x et se trouve dans la 7.x. Dès qu’on fait un chargement en BI7.x, le hash code correspondant est généré et stocké dans RSSELDONE. Mais quid des entrées 3.x lors d’une migration ? Et bien SAP a décidé que le PREMIER CHARGEMENT serait le parfait moment pour générer LA TOTALITE des hash code de chargement de la source correspondante !

Bon c’est bien, je sais maintenant pourquoi ca dump, mais ça ne m’aide pas à corriger. J'ai fini par trouver un programme standard qui permet de générer les hash code : RSSM_HASH_ENTRIES_CREATE. Malheureusement il a probablement été écrit par un stagiaire... son temps d'exécution est très très très (trop) long. Aussi, pour les besoins du projet, j'ai du faire une version light qui appelle directement la fonction standard de génération de hash, sans appeler des tonnes de fonctions inutiles autour...

2h plus tard, j’ai pu relancer mon infopackage qui a chargé sans problème mes données. Affaire classée !

Au cas où cette mésaventure vous arrive, voici le programme dont je me suis servi.

Télécharger le programme correctif

Afficher un ALV objet sans créer d'écran (screen painter)

Rédigé par Sébastien Hermann dans Général -

Lassé de créer un écran ne contenant qu'un custom control, avec PBO et PAI rachitiques uniquement pour afficher votre grid ALV objet ? La classe cl_gui_container contient nativement des attributs qui permettent de s'en passer ! Encore faut-il le savoir, ce qui est maintenant votre cas ;-)
En effet, au lieu de créer tout d'abord un objet container puis d'indiquer cet objet en parent de l'objet alv, utilisez directement cl_gui_container=>screen0 comme parent pour votre ALV !

PROGRAM test.
DATA : o_alv      TYPE REF TO cl_gui_alv_grid,
       t_sflight  TYPE TABLE OF sflight.

* Definition d'un écran de sélection vide
SELECTION-SCREEN : BEGIN OF SCREEN 1001,
                   END OF SCREEN 1001.

* Remplissage de la table de données pour l'ALV
SELECT * FROM sflight INTO TABLE t_sflight.

* Creation de l'objet alv directement rattaché au premier screen
CREATE OBJECT o_alv
  EXPORTING
    i_parent = cl_gui_container=>screen0.

* Passage des données a l'ALV
CALL METHOD o_alv->set_table_for_first_display
  EXPORTING
    i_structure_name = 'SFLIGHT'
  CHANGING
    it_outtab        = t_sflight.

* Affichage de l'écran, l'ALV apparait !
CALL SELECTION-SCREEN 1001.

Cette astuce améliore au passage la portabilité de votre code (pas de screen/status/title à gérer).