Quelquepart

Blog d'un développeur ABAP

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

Général

Correspondance Request number / Request ID

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

Dans toutes les tables relatives aux chargements (listées dans un billet à venir), vous trouverez un ID unique sur 29 caractères de la forme REQU_xxxx. Mais en affichage dans BW, il est souvent fait référence à un numéro court (nombre incrémenté de 1 pour chaque nouveau chargement).

Lors d’une erreur à l’activation, BW indique généralement l’ID de requête erroné.

Passer facilement de l’un à l’autre est enfantin… une fois que l’on connait la signification de ces 2 objets : Le request ID est en fait le SID du Request number (parfois appelé lui même request ID, suivant les écrans...) Il suffit donc d’aller lire la table /BI0/SREQUID pour obtenir l’un à partir de l’autre.

Déménagement

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

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 - aucun commentaire

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 - aucun commentaire

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 - aucun commentaire

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