Appel par programmation d'applications WebFacing depuis d'autres applications Web

Vous pouvez appeler par programmation les applications WebFacing depuis d'autres applications Web. Vous pouvez ainsi intégrer des interfaces utilisateur générées par WebFacing à l'aide d'applications Web existantes.

Les applications WebFacing sont lancées depuis des URL. Dans une application WebFacing, chaque URL de commande CL définie se présente généralement sous la forme d'un bouton sur lequel l'utilisateur clique pour démarrer l'application. Pendant la conversion WebFacing, les URL sont écrites dans un fichier d'appel .jsp. Une fois l'application déployée, elles deviennent des boutons sur lesquels l'utilisateur clique pour démarrer l'application.

Le contrôle de l'appel de WebFacing permet d'avoir recours à des méthodes d'authentification alternatives. L'authentification de l'utilisateur peut être effectuée dans un servlet personnalisé avant que WebFacing ne soit appelé. Le mécanisme d'authentification utilisé doit pouvoir fournir à l'application WebFacing les données d'identification utilisateur IBM i pour lui permettre d'accéder aux ressources IBM i.

Voici une façon simple de déterminer la commande CL à utiliser pour lancer un programme :

URL construite par un servlet contrôleur :
WFInvocation.do?clcmd=call%20ordentr
Dans cet exemple, ordentr est le nom du programme à lancer. La valeur ordentr peut être définie par un servlet et attribuée à une variable telle que orderProgram. Votre servlet peut construire la chaîne URL en utilisant la valeur déterminée par orderProgram et l'affecter à une variable newURL à l'aide d'une ligne telle que la suivante :
newURL = "WFInvocation.do?clcmd=call " + orderProgram;
newURL peut alors être utilisée comme URL de réacheminement ou de redirection de vos méthodes forward() et sendRedirect().
Dans cet exemple, l'URL complète utilisée par le navigateur, si c'est une URL de redirection, est du type :
http://<nom_hôte>:<port>/<application>/WFInvocation.do?clcmd=call%20ordentr

L'exemple montre l'URL complète commençant par http://<nom_hôte>:<port>/<application>/. La chaîne qui suit correspond à la valeur de la variable newURL, à savoir la chaîne : WFInvocation.do?clcmd=call%20ordentr. Dans un exemple de ce type, la première partie de l'URL, http://<nom_hôte>:<port>/<application>/, correspond à l'hôte, au port et à la racine de contexte de l'application. Si votre servlet contrôleur se trouve dans la même racine de contexte, il n'est pas toujours nécessaire que le servlet définisse l'URL complète. Si cela s'avère toutefois nécessaire, vous pouvez coder le servlet afin de construire une chaîne indiquant l'adresse complète de l'URL.

Remarque : Les caractères %20 de l'URL représentent un espace codé lors de l'envoi au navigateur. Les espaces ne peuvent généralement pas être utilisés de manière explicite dans les URL. Dans l'exemple où la chaîne de l'URL est en cours de construction, puis attribuée à la variable newURL, l'espace est présent dans la chaîne juste après clcmd=call. Cet espace représente la commande CL call ordentr. Il n'est pas nécessaire d'ajouter directement %20 dans la chaîne de l'URL en construction. Le serveur ajoute ce codage si nécessaire.

Paramètres d'URL pouvant être déterminés de manière dynamique

clcmd
Commande CL servant à démarrer le programme.
hôte
Nom de l'hôte sur lequel l'application 5250 d'origine est située.
port
Numéro de port du serveur WebFacing sur IBM i.
userid
ID utilisateur utilisé lors de la connexion à l'application. Remarque : Si une méthode forward() est utilisée sur votre servlet contrôleur, les paramètres de l'URL sont envoyés uniquement au niveau du serveur d'applications (niveau intermédiaire). Si vous utilisez la méthode sendRedirect() à la place, les paramètres de l'URL sont exposés au navigateur. La méthode sendRedirect() est donc moins sécurisée car des informations comme l'ID utilisateur ou le mot de passe peuvent être révélées dans la zone d'emplacement d'un navigateur, ou si un utilisateur affiche les propriétés de la page en cours d'utilisation.
password
Mot de passe utilisé lors de la connexion à l'application. Remarque : Si une méthode forward() est utilisée sur votre servlet contrôleur, les paramètres de l'URL sont envoyés uniquement au niveau du serveur d'applications (niveau intermédiaire). Si vous utilisez la méthode sendRedirect() à la place, les paramètres de l'URL sont exposés au navigateur. La méthode sendRedirect() est donc moins sécurisée car des informations comme l'ID utilisateur ou le mot de passe peuvent être révélées dans la zone d'emplacement d'un navigateur, ou si un utilisateur affiche les propriétés de la page en cours d'utilisation.
inv
Nom d'appel de la commande CL WebFacing utilisée pour lancer l'application. Si les valeurs telles que l'hôte, l'ID utilisateur et le mot de passe sont définies pour une commande CL, ces valeurs prévalent sur les valeurs générales spécifiées pour un projet. Pour visualiser le nom d'appel d'une commande CL, ouvrez la perspective WebFacing dans le plan de travail, cliquez sur l'onglet Projets WebFacing, développez le projet WebFacing, développez le dossier Commandes CL et cliquez sur le libellé de la commande. La valeur du nom d'appel peut être visualisée dans la sous-fenêtre Propriétés. Si la sous-fenêtre Propriétés n'est pas affichée dans la perspective WebFacing, cliquez sur Fenêtre > Afficher la vue > Propriétés pour l'ouvrir. Pour modifier le nom d'appel, cliquez avec le bouton droit de la souris sur la commande CL dans la vue Projets WebFacing et sélectionnez Propriétés.

Filtrage des commandes d'appel par programmation

Vous pouvez préciser les préfixes de commande CL qui seront autorisés pour les appels par programmation via le paramètre clcmd. Les appels par programmation utilisant le paramètre clcmd et précisant une valeur qui ne commence pas par un préfixe autorisé par vous ne pourront pas s'exécuter. Par défaut, le système empêche l'exécution de tout appel par programmation qui se substitue à la commande CL à exécuter.

Pour la migration des projets depuis WebFacing version 6, une valeur spéciale *ALL sera incluse, pour permettre l'exécution de toutes les commandes CL.

<context-param>
	<param-name>WFCLCMDAllowed0</param-name>
	<param-value>*ALL</param-value>
</context-param>

Si le paramètre clcmd n'est pas utilisé ou si les valeurs clcmd utilisées sont connues, vous devez retirer la valeur *ALL et entrer des valeurs selon les indications ci-dessous.

Pour préciser les préfixes de commande autorisés, modifiez la source du fichier web.xml de votre application WebFacing. Ajoutez des noms de paramètre comprenant WFCLCMDAllowed, suivi d'un texte permettant de distinguer un paramètre d'un autre. Ajoutez ensuite une valeur à chaque paramètre afin de préciser la commande qui sera autorisée. L'exemple ci-dessous autorise toutes les commandes commençant par CALL MYCMD et GO MYMENU.

<context-param>
	<param-name>WFCLCMDAllowed0</param-name>
	<param-value>GO MYMENU</param-value>
	<param-name>WFCLCMDAllowed1</param-name>
	<param-value>CALL MYCMD</param-value>
</context-param>

Si nécessaire, affectez des valeurs aux autres paramètres du contexte.

Les valeurs de clcmd du type CALL MYCMDisOK ou CALL MYCMD PARAM(ONE) seront autorisé, contrairement à des valeurs comme CALL MY ou CALL OTHERCMD. Comme pour GO MYMENU, les commandes autorisées doivent commencer par la chaîne précisée. La comparaison ne prend pas en compte la différence majuscules/minuscules.

Remarque : Seuls les appels par programmation utilisant le paramètre clcmd sont concernés, contrairement aux appels WebFacing utilisant le paramètre inv.

Exemples d'URL

WFInvocation.do?clcmd=call%20ordentr
L'hôte et le port sont utilisés dans le fichier descripteur de déploiement web.xml. Invitez l'utilisateur à se connecter.
WFInvocation.do?inv=INV1
L'hôte, l'ID utilisateur, le mot de passe et la commande CL sont extraits du fichier descripteur de déploiement web.xml. Le nom d'appel de la commande CL est INV1. Invite uniquement lorsque l'ID utilisateur ou le mot de passe sont manquants ou que l'invite est spécifiée. Impression du message d'erreur si l'ID utilisateur ou le mot de passe sont incorrects.
WFInvocation.do?inv=INV1&host=SYSTEM1&userid=WEBFACING&password=WEBFACING
Le nom d'appel de la commande CL est INV1. L'hôte, l'ID utilisateur et le mot de passe sont transmis par l'URL. Les paramètres multiples sont séparés par &.
WFInvocation.do?clcmd=call%20ordentr&host=SYSTEM1&userid=WEBFACING&password=WEBFACING
La commande CL call ordentr est transmise par l'URL. L'hôte, l'ID utilisateur et le mot de passe sont transmis par l'URL. Les paramètres multiples sont séparés par &.
Exemple entièrement qualifié

http://<nom_hôte>:port/<application>/WFInvocation.do?clcmd=call%20ordentr&host=SYSTEM1&port=4004&userid=WEBFACING&password=WEBFACING

Remarque : Dans cet exemple, les chaînes <nom_hôte> et <port> correspondent au nom de l'hôte et au port du serveur d'applications sur lequel l'application WebFacing est déployée. <application> est la racine de contexte pour l'application déployée. L'exemple montre les valeurs suivantes transmises par l'URL : la commande CL est call ordentr. L'hôte sur lequel l'application 5250 est installée est SYSTEM. L'ID utilisateur est WEBFACING. Le mot de passe est WEBFACING. Les paramètres multiples sont séparés par &.

Méthodes de servlet permettant d'appeler une application WebFacing par programmation

Il existe deux méthodes de servlet permettant d'appeler une application WebFacing par programmation, à savoir :
  • forward() -- La méthode forward() se trouve dans la classe javax.servlet.RequestDispatcher.
  • sendRedirect() -- La méthode sendRedirect() se trouve dans la classe javax.servlet.http.HttpServletResponse.
Les différences principales entre ces deux méthodes sont listées ci-dessous :
méthode forward() javax.servlet.RequestDispatcher méthode sendRedirect() javax.servlet.http.HttpServletResponse
Appel Server-side. Cette méthode appelle l'autre ressource, extrait ses résultats et les renvoie au client. Envoie le code d'état HTTP 302 au navigateur. Le navigateur se reconnecte automatiquement à l'URL de la ressource. Dans ce cas, le navigateur sait que les résultats proviennent d'une autre ressource.