WebFacing applications can be invoked programmatically from other Web applications. This provides a way to integrate WebFacing generated user interfaces with existing Web applications.
WebFacing applications are launched from URLs. Typically, a URL is represented as a link that a user clicks to start the application. During WebFacing conversion, URLs are written to an index.jsp file and after the application is deployed, these are the links users click to start the application. However, WebFacing URLs can also be constructed dynamically by other programs such as controller servlets. These URLs could be sent back to users as links to click on a Web page. But, more importantly, they can be used in the forward() and sendRedirect() methods in other Web applications. Using dynamically determined WebFacing URLs with forward() and sendRedirect() methods means that a program like a controller servlet can perform actions such as determining the host to use, the WebFacing program to launch, what CL command to use for the WebFacing program, or other actions. After these actions are completed, the servlet can provide the appropriate WebFacing application, with its parameters already set, directly to a user.
With control of how WebFacing is invoked, it is also possible to use alternative methods of authentication. All user authentication can now be performed in a custom servlet before WebFacing is called. The authentication mechanism used must be able to provide the WebFacing application with i5/OS® user credentials so that it can access i5/OS resources.
Here is a simple example for a determining the CL command to use to launch a program:
newURL = "WFInvocation.do?clcmd=call " + orderProgram;newURL could then be used as the forward or redirect URL for your forward() or sendRedirect() methods.
http://<hostname>:<port>/<application>/WFInvocation.do?clcmd=call%20ordentr
The example shows the full URL beginning with http://<hostname>:<port>/<application>/ . The value for newURL is the string after this. That is, the string: WFInvocation.do?clcmd=call%20ordentr . In an example like this, the first part of the URL: http://<hostname>:<port>/<application>/ , represents the host, port, and context root for the application. If your controller servlet is in the same context root, it is not always required for the servlet to determine the entire URL. If necessary, though, you could code the servlet to construct a string for the fully qualified URL.
You can specify the CL command prefixes that will be allowed for programmatic invocation using the clcmd parameter. Programmatic invocations that use the clcmd parameter and specify a value that does not start with a prefix that you allow will be blocked from running. The default is to not allow any programmatic invocations that override the CL command to be run.
For migration of projects from WebFacing plugin version 5.1.2.2 and earlier to V6, a special value of *ALL will be included to allow all CL commands to be run.
<context-param> <param-name>WFCLCMDAllowed0</param-name> <param-value>*ALL</param-value> </context-param>
If the clcmd parameter is not used or if the clcmd values that are used are known, you should remove the *ALL value and provide values as indicated below.
To specify which command prefixes are allowed, edit the source of the web.xml file for your WebFacing application. Add parameter names consisting of WFCLCMDAllowed, followed by additional text to make each parameter distinct. Then add a parameter value for each to specify the command that is being allowed. The following example allows all commands that start with CALL MYCMD and 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>
Provide additional context parameters with values as required.
This will allow clcmd values such as CALL MYCMDisOK or CALL MYCMD PARAM(ONE), but disallow values such as CALL MY or CALL OTHERCMD. Similarly for GO MYMENU, allowed commands must start with the specified string. Case is ignored for the comparison.
http://<hostname>:<port>/<application>/WFInvocation.do?clcmd=call%20ordentr&host=SYSTEM1&userid=WEBFACING&password=WEBFACING
Note: in this example the strings <hostname> and <port> refer to the hostname and port for the application server where the WebFacing application is deployed. <application> is the context root for the deployed application. The example shows the following values being passed by the URL: CL command is call ordentr. Host where the 5250 application is located is SYSTEM. The user ID is WEBFACING. The password is WEBFACING. Multiple parameters are separated by &.
javax.servlet.RequestDispatcher's forward() method | javax.servlet.http.HttpServletResponse's sendRedirect() method |
---|---|
A Server-side call. This method calls the other resource, retrieves its output, and returns it to the client. | Sends the HTTP 302 status code to the browser. The browser will automatically re-connect to the URL of the resource. In this case, the browser knows that the output came from the other resource. |