Je vous conseille d’aller lire cet article à sa nouvelle adresse : ZTOAD – Requêteur Open SQL – version ECC
Voici la version ECC (a priori compatible 4.7) de mon requêteur open SQL, nommé ZTOAD, publié le 26 octobre 2009.
Peu de changement dans le code, si ce n’est une uniformisation des noms de variables, et un accroissement du taux de commentaires.
Télécharger ZTOAD (compatible 4.7+)
La présentation complète se trouve ici
Mar 8
Je vous conseille d’aller lire cet article à sa nouvelle adresse : Journal d’application
Lorsque l’on développe un programme spécifique et plus particulièrement une interface, intervient le besoin de gérer des messages d’erreur / alerte / succès et surtout de les sauvegarder pour les restituer ultérieurement.
SAP dispose d’un moyen standard pour gérer les logs applicatifs, y compris pour les programmes spécifiques. Composé d’un ensemble de transactions, programmes, fonctions et tables, cette approche permet d’économiser en coût de développement et de se rattacher à une architecture SAP standard, robuste et complète.
La transaction SLG1 (ou directement le programme SBAL_DISPLAY) permet d’afficher le journal d’application. Via des variantes de sélection, le journal pourra être filtré à convenance, répondant ainsi au besoin de reporting usuel de suivi d’interfaces. Le module fonction BAL_DSP_LOG_DISPLAY permet également d’afficher un log, évitant ainsi d’avoir à gérer un rapport d’exécution d’interface.
SLG1 - Affichage du journal d'application
La transaction SLG0 permet de définir ses propres objets / sous-objets.
Pour créer un log dans un programme spécifique, l’usage classique utilise 3 fonctions :
Les données sont sauvegardées dans les tables BALHDR et BALM
Il est possible d’associer des objets métiers pour chaque message, afin de contextualiser l’erreur.
La fonction APPL_LOG_DB permet d’extraire l’ensemble des données d’un log (pour export vers un autre système ou reporting avancé par exemple).
Enfin la transaction SLG2 (ou directement le programme SBAL_DELETE) permet de supprimer les logs expirés.
SAP fournit une multitude de modules fonctions pour exploiter le journal d’application. Ces fonctions sont toutes préfixée par BAL_*. Afin de faciliter leur utilisation, plusieurs programmes démo sont également livrés par SAP. Ces programmes sont préfixés par SBAL_DEMO_*
Pour plus d’information sur l’utilisation du journal d’application, la documentation est disponible en exécutant le programme SBAL_DOCUMENTATION
Pour exemple, un petit programme qui permet de sauvegarder une entrée dans le journal d’application puis de l’afficher.
* Data pour le log
DATA : s_log_hdr TYPE bal_s_log,
w_log_hnd TYPE balloghndl,
t_log_hnd TYPE bal_t_logh,
s_log_msg TYPE bal_s_msg.
* Ecriture En-tete du log
CLEAR s_log_hdr.
s_log_hdr-object = 'ZINTERFACE'.
s_log_hdr-subobject = 'COMMANDES'.
s_log_hdr-extnumber = 'INT CMD RETOUR PIECE'.
s_log_hdr-aldate_del = sy-datum + 30. "effacement apres 30j
s_log_hdr-aluser = sy-uname.
s_log_hdr-alprog = sy-repid.
s_log_hdr-altcode = sy-tcode.
s_log_hdr-del_before = 'X'.
CALL FUNCTION 'BAL_LOG_CREATE'
EXPORTING
i_s_log = s_log_hdr
IMPORTING
e_log_handle = w_log_hnd
EXCEPTIONS
log_header_inconsistent = 1
OTHERS = 2.
IF sy-subrc <> 0.
* error
ENDIF.
* Ecriture d'un message d'erreur
CLEAR s_log_msg.
s_log_msg-msgty = 'E'.
s_log_msg-msgid = 'V1'.
s_log_msg-msgno = '302'.
s_log_msg-msgv1 = '1000125423'. "param : doc number
CALL FUNCTION 'BAL_LOG_MSG_ADD'
EXPORTING
i_log_handle = w_log_hnd
i_s_msg = s_log_msg
EXCEPTIONS
log_not_found = 1
msg_inconsistent = 2
log_is_full = 3
OTHERS = 4.
IF sy-subrc <> 0.
* error
ENDIF.
* Sauvegarde du log
APPEND w_log_hnd TO t_log_hnd.
CALL FUNCTION 'BAL_DB_SAVE'
EXPORTING
i_client = sy-mandt
i_t_log_handle = t_log_hnd
EXCEPTIONS
log_not_found = 1
save_not_allowed = 2
numbering_error = 3
OTHERS = 4.
IF sy-subrc <> 0.
* error
ENDIF.
* Affichage du log
CALL FUNCTION 'BAL_DSP_LOG_DISPLAY'
EXPORTING
i_t_log_handle = t_log_hnd
EXCEPTIONS
profile_inconsistent = 1
internal_error = 2
no_data_available = 3
no_authority = 4
OTHERS = 5.
IF sy-subrc <> 0.
* error
ENDIF.
Je vous conseille d’aller lire cet article à sa nouvelle adresse : BW3 : Suppression des données d’un cube avec ses dimensions
L’accroissement de la taille des dimensions sur BW3 est un problème classique de l’équipe de maintenance. En effet, lors d’un cube chargé en “full” quotidiennement, le contenu du cube est généralement purgé au début du chargement.
Malheureusement cette étape de la process chain ne propose pas d’option pour supprimer également le contenu des dimensions. Ainsi leur taille croit jour après jour, finissant si l’on y prend pas garde par dépasser la volumétrie du cube lui même, entrainant ainsi une dégradation des performances de plus en plus prononcée, ainsi qu’un accroissement de la taille occupée par le cube sur le disque.
SAP a finit par se rendre compte de ce problème, et la version BI7 propose en option de supprimer le contenu des dimensions lors de la suppression du contenu d’un cube.
Pour les malheureux qui n’ont pas encore migré, il n’y a pas de solution standard, à part effectuer régulièrement une suppression manuelle du contenu des dimensions (prévoir un réveil a 3h du matin pour intervenir juste avant le chargement de la process chain…)
J’ai donc réalisé un petit ABAP spécifique afin de réaliser cette opération. Il vient remplacer le processus de suppression de contenu de cube dans les process chain. Il suffit de préciser en paramètre d’entrée le nom du cube pour que son contenu ainsi que ses dimensions soient supprimées.
Oct 26
Je vous conseille d’aller lire cet article à sa nouvelle adresse : ZTOAD – Requêteur Open SQL
Vous avez surement déjà été confronté à un bug dans un programme en production qui ne semble pas être reproductible en environnement de test.
Dans ces cas là, il n’est pas toujours évident de débugger directement le programme en production (problème de droits, sensibilité des données, risque de mauvaise exécution, documents créés avec votre user…). Quand le bug semble venir d’une requête SQL un peu compliquée (jointure sur 5 tables, subquery…), vous voila embarqué dans de fastidieuses recherches via SE16 avec 3 ou 4 modes ouverts pour essayer de comprendre le problème avec la requête (et encore… le problème ne vient peut-être même pas de cette requête la !)
Dans d’autres mondes, les développeurs n’ont pas ce genre de problèmes et peuvent composer en temps réel leur requêtes personnalisées directement sur la base de données. Sur SAP ce n’est pas possible. Vraiment ? Pas en standard en tout cas. Il suffit donc de créer un programme spécifique.
Dérivé de Z_TETARD lui même dérivé de YES4SQL, voici ZTOAD, mon requêteur SQL. Il permet de faire vos propres requêtes multi-tables, ou de copier coller celle du programme à débugger.
Les commentaires ABAP sont supprimés avant exécution, les alias de table sont compris, les requêtes sont mémorisées pour réutilisation (jusqu’à 99 requêtes).
ZTOAD historique des requêtes
Choisissez au lancement si vous voulez partir sur une page blanche ou reprendre une ancienne requête.
Sur cet écran vous pouvez choisir de supprimer une ancienne requête afin de garder un historique clair.
ZTOAD Saisie de requête
Saisissez / complétez votre requête, puis sauvegardez la (cela lance le traitement). Vous pouvez l’aérer et la commenter. * et ” sont acceptés pour les commentaires.
ZTOAD Visualisation résultat
Le résultat apparait dans un ALV grid, avec rappel en en-tête de votre requête.
A noter : le programme n’accepte que les requêtes de type SELECT afin d’être “acceptable” en production (sous réserve)
Télécharger ZTOAD (compatible 4.6c)
Télécharger ZTOAD (compatible 4.7+)
Je vous conseille d’aller lire cet article à sa nouvelle adresse : ZSPRO – Paramétrage spécifique
Lors de l’implémentation d’une solution SAP, il n’est pas rare de devoir écrire des programmes spécifiques. Les bonnes pratiques recommandant de ne jamais écrire de code “en dur”, il est fréquent de créer des tables Z… pour piloter ces programmes.
Au fil du temps, il y a de plus en plus de programmes spécifiques, et de plus en plus de tables pour les piloter. Lors du projet d’implémentation en lui même, cela pose rarement de problèmes, l’équipe ayant bien en tête l’ensemble des développements (enfin, sauf dans le cas d’un très gros projet ou d’un offshore).
Mais après le passage en maintenance, ou après avoir subit du turnover sur le projet, il devient difficile d’appréhender l’ensemble de ces spécifiques et il n’est pas rare de perdre des jours à rechercher comment modifier tel spécifique (voir d’en créer un nouveau !) alors que celui livré initialement pouvait gérer l’évolution grâce a sa table de pilotage…
Voila pourquoi il est intéressant d’avoir une transaction ZSPRO. Cette dernière permet de centraliser l’ensemble des tables spécifiques du système. La documentation de chacune apparait clairement, permettant au consultant fonctionnel d’avoir un aperçu de toutes les possibilités offertes par les spécifiques en place.
ZSPRO paramétrage spécifique SAP
L’organisation des dossiers et des tables est réalisée directement au sein de la transaction ZSPRO (en mode édition). Un outil de recherche est disponible, ainsi qu’un outil d’import de tables en masse.
Techniquement, cette transaction utilise plusieurs objets SAP standards (container, spliter, tree, html view)