Quelquepart

Blog d'un développeur ABAP

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

Général

Message type X à l'ouverture d'un infopackage

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

Si vous avez un message type X lors de l'ouverture d'un infopackage, il est probable que la gestion du delta soit en cause. Dans le log du dump vous pouvez trouver ces critères :
MESSAGE_TYPE_X, SAPLRSS1, LRSS1F11, RSM1_CHECK_FOR_DELTAUPD, RSAWBN_START.

Dès lors, impossible de rentrer dans l'infopackage pour corriger. La création d'un nouvel infopackage ne résoud rien car il dump immédiatement.

La solution est tout simple, il suffit de lancer le programme RSSM_OLTP_INIT_DELTA_UPDATE pour reparer le delta en cours (en cochant ALWAYS).
Si jamais cela ne fonctionne pas, il faut essayer de lancer directement la fonction : RSC1_QUEUE_DELETE_ALL.

Si cela resiste encore... supprimer les entrées d'inits résiduts dans les tables suivantes:

  • ROOSPRMSC
  • ROOSPRMSF

La référence de la demande de mise à jour à supprimer est indiqué dans le dump (L_T_RSSDLINIT_OLTPDEL-RNR ou L_REQ_TO_KILL suivant la version de BW).

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 !