Au mois de juin 2014, SAP a annoncé que son produit Personas devenait gratuit (inclus dans le coût des licences de base de SAP). Beaucoup d’entre nous se sont alors demandés s’il était opportun d’utiliser ce “nouveau” produit ou bien si GuiXT restait une alternative intéressante. Voici un comparatif passant en revue les différents aspects de chaque concurrent afin d’aider chacun à faire son choix.

Technologie

Les deux produits fonctionnent à la manière d’une surcouche graphique qui vient modifier le rendu des écrans standards SAP. Tous les deux se placent entre l’utilisateur et le serveur SAP.

Il existe deux principales différences :

• le moteur de transformation de GuiXT est installé en local sur chaque poste utilisateur tandis que celui de Personas est installé sur un serveur (généralement le serveur SAP).
  Pour ce dernier, il faudra faire attention aux problématiques de charge serveur. Des scripts complexes présentant de gros traitements pourraient grever la performance globale de SAP ou bien s’avérer un véritable goulot d’étranglement générateur de lenteur à l’affichage s’il est mal dimensionné.
• GuiXT fonctionne avec SAPGUI pour Windows, c’est à dire le SAPGUI “classique” installé par la majorité des clients SAP tandis que Personas ne fonctionne qu’avec SAPGUI pour HTML. Ce fonctionnement de Personas nécessite donc une migration de l’ensemble des postes utilisateurs et un changement d’habitudes afin de pouvoir l’utiliser.

A noter que GuiXT peut également être installé sur un serveur :

• Soit via l’achat du produit “GuiXT Server”
• Soit via l’utilisation de SAPGUI pour HTML sur un serveur ITS.

Dans le premier cas, un serveur GuiXT fera tampon entre SAP et le poste utilisateur, dans le second GuiXT sera installé directement sur le serveur ITS et le fonctionnement sera alors très similaire à celui de Personas.

Ces deux cas restent peu utilisés aussi nous ne parlerons plus que de GuiXT avec SAPGUI pour Windows.

Fonctionnalités

Les deux produits permettent de modifier/supprimer/déplacer des élements d’écran (champ, onglet, cadre…). Ils permettent également d’ajouter des champs et d’automatiser des actions ; gratuitement pour Personas et via une licence InputAssistant pour GuiXT. Cette licence est généralement jugée peu chère au regard du coût des licences SAP (licence à vie, environ 50€ par utilisateur).

Au niveau des spécificités, GuiXT permet d’ajouter une colonne dans un tableau, voir même d’ajouter un tableau sur un écran, ce que ne permet pas Personas.

En revanche Personas permet de dessiner des écrans de type “web”, avec une totale liberté de style. GuiXT reste limité au style imposé par le SAPGUI pour windows, et même si les composantes Viewer et Controls permettent quelques fantaisies, cela reste anecdotique.

Personas permet donc par exemple de supprimer la barre de titre et de modifier la barre de contrôles standards (bouton retour / OK code…) alors que cette zone est inaccessible pour GuiXT.

Il permet également d’afficher des images en arrière plan et d’appliquer un style à un ensemble d’éléments.

Cette grande liberté permet d’obtenir des écrans vraiment différents de SAP, ce qui impliquerait logiquement d’inclure des designers et des ergonomes dans le processus de création d’écrans. Ceci n’est généralement pas nécessaire lors la création d’écrans SAP / GuiXT vu la rigidité du SAPGUI pour Windows.

L’autre spécificité de Personas est la possibilité de fusionner le contenu d’onglets directement via son éditeur graphique. GuiXT permet également d’afficher le contenu de plusieurs onglets sur un même écran mais il faut alors plusieurs scripts et un peu de code.

Installation

Tester le produit

Si GuiXT peut être testé très facilement (2 clics suffisent pour l’activer), ce n’est pas possible pour Personas. En effet, impossible de bidouiller une installation dans son coin, il faut forcément une installation sur serveur et modifier du paramétrage système. Il faudra donc passer par une demande à un administrateur SAP, ce qui peut s’avérer plus ou moins compliqué…

Déploiement

Il faut installer sur chaque poste utilisateur les fichiers du moteur GuiXT alors qu’il n’y a rien à installer pour Personas. Cette contrainte est généralement bien intégrée par l’IT qui dispose d’outils de gestion de son parc informatique, ou qui peut ajouter ces fichiers dans sa procédure d’installation du SAPGUI. Il reste néanmoins quelques clients pour qui cela s’avère encore un problème.

Notez que cette contrainte s'applique uniquement au moteur d'exécution de GuiXT. Les scripts sont séparés et peuvent être stockés sur le serveur SAP. Il n'y a donc pas besoin de déposer un fichier sur le PC des utilisateurs à chaque nouveau script.

Développement

Personas est fourni avec son éditeur graphique qui permet d’utiliser quasiment toutes les fonctions de l’outil sans avoir à “coder”. Le langage de script pour les calculs et les fonctions avancées est le javascript.

Synactive propose “Designer”, un éditeur graphique pour GuiXT. Il faudra toutefois s'acquitter d’une licence dédiée pour cet outil. Il est aussi possible d'utiliser gratuitement un éditeur texte spécialement concu pour GuiXT (coloration syntaxique, intégration avec l'écran SAP en cours, aide contextuelle...), ou bien tout éditeur de textes de son choix.

Personas comme GuiXT propose tous les deux un “recorder” pour enregistrer les scripts d’automatisation d’action. GuiXT propose en plus un log d'exécution activable à la demande pour contrôler l'exécution des scripts d'automatisation ainsi qu'un debugger permettant de faire du pas à pas et de voir le contenu des variables.
Il n'y a pas d'outils de debug pour Personas, il faut se contenter des logs d'erreur du navigateur internet.

Transport

GuiXT utilise le schéma de transport classique de SAP : Création d'ordre de transport de type Workbench, libération, etc...
C'est un schéma connu et sécurisé.

Personas semble nécessiter de passer par un admin pour packager un transport. (manque d’information sur ce point)

Maintenance

Tant que l’on reste dans les limites des outils d’édition graphique (la partie “dessin d’écran”), la maintenance est similaire sur GuiXT et Personas. Tout change lorsqu’on s’introduit dans l’automatisation d’actions, ou l’enrichissement d’écrans via recherche d’informations sur d’autres écrans SAP. En effet, l’inconvénient de GuiXT d’utiliser un langage propriétaire devient alors un énorme avantage. Les scripts GuiXT sont simples, lisibles, aérés. Ils sont compréhensibles même par un novice. Les commandes d’actions sont en anglais et décrivent l’action. De plus, l’ajout de commentaires permet de simplifier la relecture. les scripts Personas, en revanche, sont complètement illisibles. Par conséquent, chaque script devra être assorti d'une documentation décrivant précisément l’effet de chaque ligne de script.

Pérénité

GuiXT est édité par Synactive depuis 1998, en partenariat avec SAP qui l'intègre dans son installation du SAPGUI pour Windows. La note OSS 1825312 décrit la stratégie de maintenance de GuiXT par SAP. A ce jour, SAP maintient sa position de confiance et d'intégration de GuiXT.

Personas est édité directement par SAP depuis 2012, et vient de passer "gratuit" après seulement 2 ans de commercialisation. Si certains y voient la volonté de SAP d'écouter ses clients qui réclamaient sa gratuité, d'autres y voient le signe d'un échec commercial : peu de clients ayant acheté des licences Personas, le produit est donc packagé avec ECC pour le revaloriser.
Quid de son existence dans 2 ans s'il n'y a pas plus d'engouement pour le produit ?

GuiXT est utilisé par 947 clients (données 1er janvier 2014). Cette base est en constante augmentation depuis 15 ans.

Tableau comparatif

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).

Request ID affiché dans la gestion d’infoprovider

Request Number affiché dans le monitor

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.

Correspondance entre ID et Number via SE16

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 :

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.

Pour accéder rapidement à une liste de valeur pour une aide à la recherche, il est possible d'utiliser une syntaxe particulière directement dans le champ.
Par exemple sur l'écran d'accueil de SU01, dans le champs User, saisir =...seb puis entrée affichera la liste de tous les utilisateurs dont le prénom commence par "seb".

La syntaxe est la suivante :

• Commencer par =
• Ajouter autant de points que la position du champ de recherche a remplir dans le match code
• Saisir le texte recherché
• Appuyer sur entrée

Dans l'exemple "=...seb", les 3 points indiquent d'utiliser le 3e champ, donc le prénom

Le matchcode du champ User de SU01

Cette astuce fonctionne avec la plupart des champs standards SAP. Il est également possible de faire une recherche sur plusieurs champs en les enchainant. =...seb.dir pour rechercher tous les "seb*" du département "dir*"

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 :

• BAL_LOG_CREATE qui permet d'initialiser le nouveau log.
• BAL_LOG_MSG_ADD qui permet d'insérer les messages, 1 par 1
• BAL_DB_SAVE qui permet de sauvegarder le log en base de données

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.