Bonjour à tous,
Cet article se propose de présenter la marche à suivre pour créer une aide à la recherche personnalisée dans le contexte FPM.
Une aide à la recherche personnalisée consiste en un écran Web Dynpro spécifique qui sera affiché en lieu et place de la classique popup standard.
Cela offre donc la possibilité de configurer complètement l’interface de recherche, l’idée étant d’améliorer l’expérience utilisateur et/ou de se rapprocher au mieux de la modélisation du client.
L’exemple proposé dans cet article consiste à remplacer l’aide à la recherche par une arborescence. On présente une hiérarchie au client, dans laquelle il pourra sélectionner la valeur recherchée. Plus concrètement, il s’agit de la hiérarchie des articles, dans le cadre d’une commande de vente (SD).
En outre, on ajoutera une zone permettant d’accéder au matchcode standard, pour que l’utilisateur puisse conserver la fonctionnalité bien pratique de liste de valeurs personnelles.
Première étape : le composant Web Dynpro.
Il faut créer un composant Web Dynpro implémentant l’interface IWD_VALUE_HELP. Cette interface apporte :
- les évènements d’ouverture et de fermeture de l’aide à la recherche ;
- la méthode SET_VALUE_HELP_LISTENER que nous décrirons plus tard.
Le contexte de l’INTERFACECONTROLLER contient un noeud, nommé VH_DATA_SELECTED, ayant un unique attribut, ici MABNR, de type MATNR.
Le COMPONENTCONTROLLER hérite de ce contexte et on lui ajoute un noeud permettant de gérer la hiérarchie.
Puis trois vues et une fenêtre. La fenêtre contenant la vue principale, cette dernière contenant elle-même les deux autres vues.
Seule la méthode WDDOONOPEN de la fenêtre est utilisée. Elle permet de modifier le titre de la fenêtre, par :
window_descr->window->set_window_title( cl_wd_utilities=>get_otr_text_by_alias( `Z_SD_FPM/SEARCH_MATNR` ) ).
La vue principale ne contient rien d’autre que les deux sous-vues.
Chacune de ces sous-vues permet de gérer son propre traitement, sur lequel je ne vais pas m’attarder. L’objet de cet article n’est pas de décrire comment créer une hiérarchie dans un Web Dynpro.
L’important ici, c’est la transmission de la valeur que l’utilisateur aura choisie à la zone de l’écran associé à notre aide à la recherche.
Ainsi, les deux vues possèdent une méthode (dont l’appel est géré par la logique intrinsèque de ces vues) qui exécute les instructions suivantes :
" Affecte l'article sélectionné au context appelant le Matchcode
wd_comp_controller->set_material_selected( iv_material = lv_material ).
wd_comp_controller->fire_vh_data_selected_evt( ).
wd_comp_controller->gv_vh_listener->close_window( ).
C’est assez limpide : on transmet la valeur sélectionnée, on déclenche l’évènement de sélection, et on ferme la fenêtre.
La méthode SET_MATERIAL_SELECTED est une méthode du COMPONENTCONTROLLER dont le code est le suivant :
wd_this->gv_vh_listener->f4_context_element->get_node( )->get_node_info( )->get_controller( )->get_context( )->add_context_attribute_change(
element = wd_this->gv_vh_listener->f4_context_element
attribute_name = wd_this->gv_vh_listener->f4_attribute_info-name
new_value = iv_material ).
wd_this->gv_vh_listener->f4_context_element->set_attribute(
name = wd_this->gv_vh_listener->f4_attribute_info-name
value = iv_material ).
On y voit des références à GV_VH_LISTENER.
Cet objet est enregistré par la méthode SET_VALUE_HELP_LISTENER dont nous parlions plus haut. Cette méthode reçoit en paramètre le LISTENER qui permet le lien entre l’écran appelant et notre aide à la recherche.
Et c’est tout !
Pour résumer : un composant Web Dynpro implémentant l’interface IWD_VALUE_HELP et une méthode permettant de transmettre la valeur choisie puis de fermer l’aide à la recherche.
Au passage, j’attire l’attention sur la nécessité de bien initialiser les données. En effet, le composant Web Dynpro conserve son état entre deux appels à cette aide à la recherche. Notamment, les méthodes WDDOINIT ne sont pas rappelées. Ceci peut engendrer des comportements étranges, selon la complexité de l’interface mise en place.
Deuxième étape : intégrer le Web Dynpro dans FPM.
C’est bien beau d’avoir un Web Dynpro pour remplacer le matchcode standard, mais encore faut-il que notre moteur FPM sache qu’il doit l’utiliser !
Pour cela, rien de plus simple. Il faut utiliser la méthode GET_DEFINITION de la feeder class du GUIBB concerné. Cette méthode retourne une table interne ET_FIELD_DESCRIPTION qui contient diverses informations concernant l’ensemble des champs disponibles pour le GUIBB.
Et parmi ces informations, deux nous intéressent en particulier :
- DDIC_SHLP_NAME ;
- WD_VALUE_HELP.
Comme leur nom l’indique, la première contiendra le nom de l’aide à la recherche classique, la seconde le nom du composant Web Dynpro.
Il suffit alors de vider la première et d’alimenter la seconde, et le moteur FPM se chargera d’appeler notre Web Dynpro.
Cette fois, c’est vraiment terminé !