Welcome to WebFacing

The newest release of WDSc, Version 5.1, has the most up-to-date version of the IBM WebFacing Tool, refined on the basis of user feedback and customer requirements. The WebFacing Tool, and all of the other workstation components that make up WDSc, are packaged to work in the Eclipse environment--the open-source framework created for multi-application level development, with all of the latest Java and Web tools available for use in your Web application.

The new packaging of iSeries application development tools, WDSc, is intended to support iSeries programmers who want to work with both traditional applications as well as Web-based e-business applications. You can even use the WebFacing Tool in conjunction with other WDSc tools to enhance your WebFaced application--for example, to add graphics and dynamic JSP attributes. In particular, you can use the WebFacing Tool in combination with these WDSc tools:

• The Remote System Explorer (RSE), to change and re-create your RPG program to adapt it to the WebFacing environment
• The WebSphere Application Server (WAS) Test Environment, to run and test the WebFaced application locally
• The Integrated iSeries Debugger, to help you troubleshoot and debug your WebFaced application

An Advanced Edition of WDSc is also available, providing end-to-end support for the creation and maintenance of J2EE applications and Web Services, plus support for Enterprise JavaBeans (EJBs) and Java Messaging Services. Most importantly, the Advanced Edition also provides additional capabilities for the WebFacing Tool, including the ability to generate run-time elements that conform to the Struts Model-View-Controller (MVC) framework and the ability to add additional services to the WebFaced application, such as Print Services. Some of the user interface elements in the Advanced Edition can also be generated as JSP custom tags.

But back to the basics of the WebFacing Tool. As a programmer, your starting point is your legacy 5250 application, which you run as a DDS-based user interface on the green-screen. For example, you might have an application that organizes customers and inventory for a store. This application uses a customer identification number to keep track of customers' data. As a user of this application, you select a customer, fill out an order that includes parts and quantities, and submit the order using a function key (F6, for example). You might be familiar with this type of application, as it resembles many of the common applications that you see at large electronics or department stores to keep track of customer orders and inventory. Your goal is to turn this kind of application into a modern GUI, with graphics and links, that can be deployed to WAS so that you can run the application over the Internet and integrate it with other Web technologies.

The conversion process generates JSPs and XML files that replace the existing DDS code, including your UIM help panels. The XML files hold the definition for the record format data, controlling its layout or other characteristics, and the JSPs control the appearance of the Web-enabled version in your Internet browser, prompting for data and handling input errors. The conversion also generates an application index.html page, where you can easily launch the Web-enabled version of your application.

Your starting point in the WebFacing Tool is your WebFacing project. The project holds all the files necessary for building a well-structured Web application. It contains the source to be converted, and it follows the formal J2EE directory structure of a Web project, conforming to the J2EE Web application standard. You begin in the general workbench of WDSc. The workbench contains a perspective specially customized for the WebFacing Tool called the WebFacing perspective, and it is recommended that you switch to this perspective, as it is fitted with all of the views and editors needed to make your WebFacing tasks easy.

When you create your WebFacing project within the WebFacing perspective, you connect to the iSeries server that contains your source code, specify the library and source physical file that contains the code, and then select the DDS source members that you want to convert to be the Web pages in your WebFacing project. You also specify the CL command you use to invoke the application. This is the same command that you use in your 5250 application--for example, "call retailapp." You also give the command a label, such as "Retail Application." In the converted project, the label appears as a link on the index.html page that, when clicked, invokes the application. You also choose a Web style for the generated pages, with the option to customize that style later on using Web Site Designer.

After you create your WebFacing project, it displays in the WebFacing perspective as a hierarchical series of files you can expand and collapse as a tree-view. Your project will contain these elements:

• The display source file members to use for WebFacing conversion
• The panel group source members to convert
• The command that invokes the application
• The style to use for the converted screens

At this point, you can convert your source. All you need to do is right-click the project and select Convert. Because you have already specified which DDS source files to use during project creation, the project itself has all of the necessary information; therefore, conversion is a one-step process. A conversion log shows you keywords you have referenced in the source, display file conversion logs, and UIM Help conversion logs. The conversion generates a Web page called index.html. This represents the homepage for the application, and in the WebFacing perspective, this is the page you use to launch your application.

Now, you can launch the Web-enabled application. To run the application on the Internet, you would typically need to copy all of the Web project files to a WAS environment. Luckily, a WAS Test Environment is embedded in the product. This Test Environment makes it very easy for you to test your converted application because you do not need to deploy the entire application to a remote production environment (which is what you would do only after any post-conversion modification and thorough testing). To test the application locally, however, you only need to follow these steps:

1. Right-click the index.html page and select Run to launch the Test Environment and display the page in a browser.
2. Select the link on the Web page to invoke the application.
3. Step through the Web-enabled application using the HTML-based user interface.

Now, you can see the Web version of your RPG application. When you invoke a converted application from the browser, the WebFacing server (on the iSeries server) starts the server program. The server handles all operations to READ, WRITE, and EXFMT display files, so that, in many cases, your program can run without modifications and without even detecting that it is being accessed with WebFacing. After you have converted the initial DDS source, you can take your WebFacing application in many different directions, depending on how you want to customize the application's appearance and behavior.

Enhancing Your Web App

The first thing you might want to use is a feature called Web Settings, in CODE Designer, to change the look of the user interface. CODE Designer makes it easy for you to select an element in the 5250 application and create Web-enabled versions of the same functions. It is included with the WDSc product, and it can store the Web Settings information as comment lines in the DDS source. When you convert the application again with the WebFacing Tool, the DDS source comment lines are picked up and applied to the new user interface.

For example, in the 5250 application, to select a customer from a list of customers, you would need to put a "1" beside the customer's name in the options column, and then you would press the Enter key. This will still be how the application behaves when you convert it to a Web interface, in that there is a box beside the customer's name into which you need to enter a "1." Using Web Settings, you can change this behavior so that the customer's name appears as a link, and by clicking the link, you invoke the customer's record. Internally, the WebFacing Tool generates code that enters a "1" for the option and mimics that the Enter key has been pressed, so your program logic does not have to change even though the user interface now maintains a Web behavior.

In essence, when you use CODE Designer's Web Settings, you enhance the user interface, but you do not change the underlying function of the application, and you can still run the application in its original 5250 format since the comments are only applied to the Web-enabled version of the application after re-conversion. You can also use CODE Designer to add your own JavaScript to modify the behavior of the Web interface.

Another enhancement you can make to your application is a modification to its style. This project-level feature applies changes to all the pages in your application. You can, for example, change the text color and font for all highlighted fields, create graphics, or insert images into the interface. You can also apply changes to windows, push buttons, and subfiles. You perform these actions simply through the WebFacing properties window for the application, modifying the elements as you would for any type of personal application, such as a word processing application, and the changes are applied globally to your WebFacing project.

Security is another factor that is easily maintained in your converted application, which is important if you want to deploy the application over a large-scale network. You can change the run-time behavior so that the user must provide sign-on information. To do this, you simply change an option so that the application no longer has pre-specified values, and then you use the tool to create a dialog box that asks for the user's authentication information (user ID and password).

Getting the Bugs Out

When you run your converted application, you might also want to know more about the events occurring in the WebFacing environment, especially if you have customized your application and need to check that all of the code is still working. You can perform actions such as tracing and debugging to further investigate any changes or problems you might be having. Using tracing, you can monitor the data that is flowing between the user interface and the program. When you debug your application, you can discover which values are returned from the workstation files, which indicators are on or off, and which path in your program is being executed. You could use a green-screen debugger to debug the program in the server job, but WDSc comes with a built-in debugger more suited to your workstation environment. With the WDSc Integrated iSeries debugger, you locate the job started by the WebFacing environment, start the debugger and point it to your program, set breakpoints in the program source, monitor variables in your program, step through your program statements, and step into called programs at the point of any errors so that you can pinpoint and diagnose problems easily.

Passing Parameters

The WebFacing Tool also handles the passing of both static and dynamic parameters to the program. It generates the parameter entry fields for you on the initial Web page, and you can use the WebFacing Add CL wizard to create the parameter definitions. Instead of invoking the WebFaced application from a link on a Web page, you can invoke it from any Web application. This requires a bit of your own programming. When you perform this task, you can use the Java programming tools included with WDSc to add this dynamic behavior. However, you do not need to worry if you have never performed any Java coding, because the tools in WDSc set up the entire Java environment. All you need to do is select the methods from a simple, well-documented wizard.

Ready for Export

Once you are completely finished and satisfied with your WebFacing application, you are ready to export it to WAS or WAS Express. For the more recent versions of WAS, you simply use the Export tool inside WDSc to export the files, and then you install and start the Web application using the WAS Administrative Console. The J2EE standard creates an Enterprise Archive (EAR) file. This zip file contains all information about your Web application. WDSc builds this file automatically for all Web and WebFacing projects. You only have to move it to the application server, point to it, and then install the application. There is no need to worry about the organization of the application, because everything is taken care of by WDSc--the structure and functions are all preserved. You can then use a browser to invoke the application on the remote application server. In the future, to apply small changes, you can also copy new files from your WebFacing project to the application server without having to re-deploy the entire application (i.e., the EAR file) from scratch. Both the WebFacing Tool and WAS are designed to be scalable and modifiable, in case you want to add more to your Web application in the future or even add new applications to your business.

WDSc and WebFacing--The Tools of Your Future

As Web technology and graphical user interfaces continue to dominate the marketplace, programmers need a means to help them along this path quickly and easily. With a little help from the WebFacing Tool, it is not hard to give your legacy applications a modern look and feel, based on all the latest Web and Java technology for use in your Web application. What's more, once you start using the product, you will realize that this article only scratches the surface of all that is available in the WebFacing Tool, as well as the entire WDSc toolset.

Emily Bruner, Information Developer for iSeries AD Solutions, IBM Software, develops online documentation for WebSphere Development Studio Client for iSeries (WDSc). She also performs information mapping, software testing, and Web site maintenance. A recent graduate of the University of Waterloo in English and philosophy, she pursues writing, music, and volunteering for animal shelters in her spare time.

Also Read

Legacy application modernization: A comprehensive approach to modernize your business

How Low Code Helps Businesses Modernize their IBM i Apps

Why Migrate When You Can Modernize?