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. Une URL se présente généralement sous la forme d'un lien sur lequel l'utilisateur clique pour démarrer l'application. Pendant la conversion WebFacing, les URL sont écrites dans un fichier index.jsp, puis, une fois l'application déployée, elles deviennent des liens sur lesquels l'utilisateur clique pour démarrer l'application. Cependant, les URL WebFacing peuvent aussi être construites de manière dynamique par d'autres programmes comme les servlets contrôleurs. Ces URL peuvent être renvoyées aux utilisateurs en tant que liens d'une page Web. Avant tout, elles peuvent être utilisées dans les méthodes forward() et sendRedirect() d'autres applications Web. L'utilisation d'URL WebFacing déterminées de manière dynamique à l'aide de méthodes forward() et sendRedirect() implique qu'un programme comme un servlet contrôleur puisse effectuer des actions telles que le choix de l'hôte à utiliser, le programme WebFacing à lancer, la commande CL à utiliser pour le programme WebFacing, etc. Une fois ces actions terminées, le servlet peut fournir directement à l'utilisateur l'application WebFacing appropriée ainsi que ses paramètres prédéfinis.
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 i5/OS pour lui permettre d'accéder aux ressources i5/OS.
Voici une façon simple de déterminer la commande CL à utiliser pour lancer un programme :
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().
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.
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 le plug-in WebFacing version 5.1.2.2 (et toute version antérieure à 6), une valeur *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.
http://<nom_hôte>:<port>/<application>/WFInvocation.do?clcmd=call%20ordentr&host=SYSTEM1&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é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. |