Déboguer une application Progress OpenEdge : outils et méthodes

Par /

Sur du code Progress ancien — souvent écrit en v9 ou même en v6, parfois sans une seule ligne de log applicatif — le débogage est fréquemment le point faible des équipes qui reprennent une application existante. Voici les outils et la méthode que j’utilise en mission de TMA ou d’audit.

Le débogueur intégré

OpenEdge fournit un débogueur graphique (accessible depuis OpenEdge Architect / PDSOE, ou en ligne de commande avec l’option -debugalert). Il permet de poser des points d’arrêt, d’inspecter les variables et temp-tables, et d’avancer pas à pas dans une procédure. C’est l’outil de référence pour un problème reproductible sur un poste de développement.

En revanche, sur un AppServer de production, poser un point d’arrêt n’est pas toujours possible ou souhaitable : c’est là que les logs prennent le relais.

Les logs applicatifs et système

Le fichier .lg généré par la base de données et les agents AppServer est la première source à consulter en cas de comportement anormal en production : erreurs de connexion, verrous, arrêts inattendus.

LOG-MANAGER permet d’écrire des entrées de log applicatives configurables par niveau (ERROR, WARNING, INFO) sans repasser par un MESSAGE ... VIEW-AS ALERT-BOX, qui bloque l’exécution et n’a pas sa place en production :

LOG-MANAGER:WRITE-MESSAGE(
    "Traitement facture " + STRING(piFactureID) + " démarré",
    "MonModule").

Sur du code legacy qui n’a jamais été instrumenté, l’ajout progressif de LOG-MANAGER:WRITE-MESSAGE aux points clés (entrée/sortie de procédure, avant/après un COMMIT, dans les blocs CATCH) change radicalement la capacité à diagnostiquer un incident sans avoir à le reproduire.

Gérer proprement les erreurs : NO-ERROR et ERROR-STATUS

Un piège classique sur du code ancien : des instructions NO-ERROR posées un peu partout pour faire taire les erreurs, sans jamais consulter ERROR-STATUS ensuite. Résultat : l’erreur est silencieuse, mais le programme continue dans un état incohérent.

FIND FIRST Client WHERE Client.ClientID = piClientID NO-LOCK NO-ERROR.
IF ERROR-STATUS:ERROR THEN DO:
    LOG-MANAGER:WRITE-MESSAGE(
        "Erreur recherche client " + STRING(piClientID) + " : " +
        ERROR-STATUS:GET-MESSAGE(1), "MonModule").
    RETURN ERROR "Client introuvable".
END.

La règle simple à appliquer en revue de code : un NO-ERROR sans vérification de ERROR-STATUS juste après est presque toujours un bug en devenir.

Isoler le problème avant de corriger

Sur une application complexe, la tentation est de corriger au premier endroit où l’erreur apparaît. La méthode qui fait gagner du temps :

  1. Reproduire avec le jeu de données le plus petit possible — un seul enregistrement plutôt qu’un traitement de masse.
  2. Remonter à la source réelle, pas au symptôme : une erreur affichée dans un écran de saisie vient parfois d’un batch exécuté la veille qui a laissé une donnée incohérente.
  3. Vérifier les triggers et les règles métier implicites avant de modifier une procédure : sur du Progress ancien, la logique est parfois répartie entre triggers de table, procédures partagées et code écran, sans documentation.
  4. Ne corriger qu’un point à la fois, et revalider immédiatement — les corrections en cascade sans test intermédiaire sont la première cause de régression sur ce type de code.

Debug côté client vs côté AppServer

Un même symptôme peut avoir une cause différente selon qu’on est en session locale (4GL classique) ou en architecture AppServer. Pensez à activer le logging côté AppServer (-clientlog, paramètres de log dans le fichier .pf) en plus du poste client : une erreur qui semble « disparaître » est souvent une exception avalée côté serveur, jamais remontée à l’écran.

En résumé

Le débogage sur Progress/OpenEdge ne diffère pas fondamentalement d’un autre langage : la difficulté principale, sur du code de plusieurs années voire décennies, est l’absence de logs et une gestion d’erreurs incomplète. Instrumenter progressivement le code avec LOG-MANAGER, systématiser la vérification d’ERROR-STATUS, et isoler avant de corriger permettent de reprendre la main sur une application, même mal documentée.

Une application Progress / OpenEdge difficile à maintenir ou à déboguer ? Contactez-moi pour un audit, ou consultez ma page TMA / maintenance applicative.

Retour en haut