In-Depth
Wheels in Motion: LANSA Helps Bicycle Manufacturer Get Up to Speed
What do you do when your CEO comes to you on a Friday afternoon at 4:55 p.m. and says you absolutely, positively, must have the company doing e-business by noon on Monday? After you get over the panic attack, calm down and read this article.
Obviously, we are exaggerating the situation just a little bit, but when the President of Trek Corp., a manufacturer of bicycle parts and accessories, came to Tim Tarnowski, System/Development Manager at Trek, and asked how long it would take to build a functional e-business Web site, Tarnowski turned to LANSA for the Web to help him deliver on his promise. Trek was able to build a fully functional Web site, the Dealer Extranet (Dexter), in about 90 days. Dexter runs entirely on AS/400 and connects dealers to Trek’s catalog of parts and allows them to make orders 24 hours a day.
Trek speaks very highly of LANSA for the Web and how it helped them build Dexter quickly and with a minimum learning curve. It’s not that we don’t believe Trek. It’s just that we preferred to find out for ourselves. We wanted to answer the question, "Does LANSA for the Web (LFTW) really allow you to build e-business Web sites quickly and with a minimal learning curve?"
The answer? Yes – but, as is usually the case – with a number of caveats.
How We Tested
We have an AS/400e Model 170-2290 with 256MB of memory and a 8GB hard drive. Throughout our testing we paid special attention to performance – mostly response time – during 5250 development sessions, and found that although the LFTW development environment performed alright on our system, we expect that a more powerful system would be needed for serious development. We did not do any performance testing of the generated applications and therefore cannot comment on LFTW run-time performance.
For our testing, we wanted to build a system that would allow anyone to enter data about freelance articles written for MIDRANGE Systems into a database. We would then use the database to generate billing reports for each issue. Our test database consisted of four tables: ISSUES, ARTICLES, AUTHORS and ACCOUNTS.
We worked with these tables in two different scenarios. The first involved accessing the tables from within LANSA as external tables, not managed by LANSA. This scenario was meant to model a situation where you have an existing database for which you want to enable Web access through LANSA. The second scenario involved creating the tables from scratch in LANSA. This second scenario was meant to model a situation where you would build an application from the ground up, including the database design.
These two scenarios highlight one important thing to note about LFTW: It is built on top of LANSA, an AS/400 4GL application development tool, and hence all LFTW applications are actually LANSA applications with a Web face. What this means is that to deploy an LFTW application, you must learn to use LANSA first. That is where most of the learning curve comes in.
It’s Moving Time
We’re not going to waste more than a few words about the installation of LFTW. We were provided with a CD and clear instructions for installing the product. Post installation configuration is minimal – most of it involving the configuration of the IBM Web server that ships with OS/400. Once the product was installed and configured, we were able to access the demonstration application via our Web browser. Everything worked fine, so we fired up LANSA and went to work.
The version of LANSA we tested runs as an AS/400 green screen application. There is another version that runs under the Windows OS, but all LANSA applications are portable across LANSA-capable platforms. It is possible to use the Windows version of LANSA to develop your application and then move the code to an AS/400 for production. Some people prefer this method since the Windows version is supposed to have a richer editing environment.
By default, when you run LANSA without any parameters you are put into a menu that allows you to run applications and perform general system-related tasks. From this menu, you can work with fields, files and processes – the three things that you need to create to build a LANSA application.
Although you can work from these menus, it is preferable to run LANSA with the DEVELOPER parameter set to Y or A. We did all of our development using the advanced (DEVELOPER=A) developer menus.
Before we continue, some explanation of the LANSA environment is appropriate.
When you install LANSA, two partitions are installed by default, the system partition (SYS) and the demonstration partition (DEM). A LANSA partition allows the logical separation of LANSA objects. Because LANSA uses a "corporate data dictionary" approach to application development, it is recommended that you use one partition for all of your development and another for production. It is not a good idea to use partitions as a way to separate applications, as this defeats the purpose of the data dictionary. We created a partition called EDT in which to do all of our development.
Within a partition you can define fields, files and processes. Fields are individual data items, files are collections of fields and processes are where you define RDML – LANSA’s 4GL language – functions. When you run a process, a menu is displayed where you can choose which function to run.
In our first scenario, we needed to import the definitions of the tables into LANSA. This can be done manually, one at a time, or with LANSA’s bulk import facility. We tried both and found that although the bulk import facility does work for a small number of tables, defining the tables manually gives you greater control if there are problems. Enter the first of our caveats.
When we had originally defined our tables using DDS, we used ill-advised naming conventions, including the use of non-alphanumeric characters, such as the number sign (#) and underscore (_). Although there is no rule preventing these characters from being used in the field names of AS/400 files, LANSA was not so forgiving. Although LANSA allowed their use during the bulk import, they caused problems later. Defining the tables manually, we were aware of the errors right away and could work to fix them. These problems make us think that using files that already exist requires a bit of caution and could increase the overall development time for LFTW applications.
To fix our problems in a production environment, we would have created new files that had almost identical DDS definitions (excepting the field names) and exported the data from the original files into the new files. After this data transformation was complete, the bulk import would have been easy and error-free.
Once the bulk import is complete, you have definitions for all of the fields that were in the files and all of the files. In LANSA’s data dictionary-centric environment the same field can be used in more than one file. In fact, the power of the data dictionary is that fields are reused.
Trust us about this one. We made the mistake of naming the field that held the author identification number, AUTHNO in the AUTHOR file, but we called it AUTHOR in the ARTICLES file. When we did the bulk import, we ended up with two fields that essentially referred to the same thing. Later on, we will see why this can make your life more difficult than it has to be.
In the second scenario, we didn’t have any of the problems we had in the first, concerning the definitions of the fields that make up our files. In this case, we fully defined each field using the "Work with Fields" screen, and, when we were done with the fields, we used the "Work with Files" screen to map these fields to their proper files.
This manual process, although somewhat tedious, was accomplished without problems. When we were done, we had a database that was identical to the one that was created during the bulk import process. The only difference between the bulk import and the creation of the database from scratch is that there are certain things you can’t do with files that are not managed by LANSA. These files have the "Maintained by" attribute set to OTHER.
At this point, our two scenarios converge and there is no difference in the development of our application from this point on.
The Data Dictionary
As we started to fill in the details of our already defined fields, we came upon the true power of the data dictionary. In other application development tools we have used, such as Visual Basic, there is nothing to prevent you from changing the label of a field from one screen to the next. In LANSA, the data dictionary enforces uniformity. Some might say this is a bad thing, but we think it’s great.
We use the AUTHNO field in two places. In the AUTHORS file it is used as the primary key that identifies the author. In the ARTICLES file, we use AUTHNO as the foreign key that identifies the author of the article. In either case, we want the label that is used for display on a screen to be the same, we chose to use "Auth. #." After we defined this label for the field, any function that uses that field uses that label. This behavior makes applications easier for end users to understand and cuts down on training since you don’t have to explain why it’s referred to as "Auth. #" in one place and "Author ID" in another.
The data dictionary also comes into play for prompting functions. A prompting function is called any time the prompt key (usually F4) is pressed on a data entry screen while the cursor is in a field that has a defined prompting function. This way you can define one function and all data entry screens that use that field will use the same function. No duplicate code is necessary!
You can define many different things for each field, including input and output attributes and default values. You can even define a reference field that the current field will use to inherit things like help text and rules.
We defined rules for many of the fields, most notably lookup rules for the identification fields so that it would be illegal to enter an improper identification for things like the AUTHNO when you were entering information about articles. You can also define triggers that will perform functions when certain events, like a delete or a change, occur.
When it comes to the definitions of files, one powerful feature of LANSA is the ability to define Access Routes, which are predefined paths between files. For example, our ARTICLES file was defined with the primary key being made up of ISSNO and ARTNO, in that order. We also defined a logical file named ARTBYISS that indexed the ARTICLES file by just ISSNO. We then defined an Access Route from ISSUES to ARTBYISS that allowed us to easily retrieve all of the articles that belonged to each issue.
For cases when you want to automatically look up or total a field whenever you retrieve another field, there is the Predetermined Join Field (PJF). We used PJFs to retrieve the author’s last name from the AUTHORS file every time the AUTHNO field was accessed. That way, whenever you chose an AUTHNO from a prompt window or entered an AUTHNO into a screen, the last name could automatically be displayed. We also used this same method to total the PAYMNT field in ARTICLES and display that total with the data from ISSUES.
Once all of your fields and files have been defined and edited to your satisfaction, you are ready to build your first function.
Forms Follow Functions
LANSA functions are built using RDML, a platform-neutral 4GL. One of the most powerful features of LANSA and LFTW is RDML. It is a relatively easy to learn 4GL – from the generated functions we could immediately understand what the RDML code was doing – that handles a lot of the things that third-generation languages, like RPG and COBOL, do not. Report and data entry screen development are many times simpler than they are in RPG or COBOL, and the best news is that once you write an RDML program, that program can be compiled into any number of 3GL languages. For instance, on the AS/400 LANSA translates RDML into RPG, which is then compiled. On the Windows platform, RDML is translated into C. In any case, it doesn’t matter what the generated language is, you only have to modify the RDML code.
If we had to build all of our data entry and report screens from scratch, our opinion of LANSA (and our demeanor) would be much more negative. Lucky for us (and LANSA), we didn’t have to build our data entry screens from the ground up. LANSA uses templates to enable you to rapidly generate the RDML code for many different types of functions, including data entry screens and reports. Once generated, you can modify the RDML code if you wish or leave it as-is. We found the choice of templates provided by LANSA fairly robust, but serious users will want to modify and/or expand on the base set of templates.
We wanted to fully test the features of LFTW, so we built a number of functions for data entry and reporting. The primary purpose of our system was to allow the entry of articles written by freelance writers and to generate billing reports for each issue. First, we built prompting functions for AUTHORS, ISSUES and ACCOUNTS. We didn’t want the prompting functions to appear on the main menu, so we used the function control option for our process in the "Work with processes" screen. This allows you to control which functions appear on the main menu, as well as other menu-related actions.
We built our prompting functions using one of the templates, but found that all of the data we wanted to include in the pop-up window would not fit in the default layout. We chose to reduce the number of fields displayed on the pop-up window, but it would have been easy to edit the RDML code and make the window bigger, or attack the root of our problem and remove the extra white space from the end of long text fields.
Once all of our prompting functions were finished we created functions for basic data entry for the AUTHORS, ISSUES and ACCOUNTS files. These were simple to create, and we had no trouble creating them from one of the templates.
In order to more fully test the capabilities of LANSA, we decided to create a function that was a little more complicated. Typically, when we process each issue we have to enter the articles into the database, including information about the title, author and amount paid. We enter all of the articles for each issue at one time, so it made sense to use a master/detail data entry screen with ISSUES as the master and ARTICLES as the detail.
We tried to use the standard pop-up header/detail template, but to no avail. Our TITLE field was too long to fit on the pop-up screen and caused the RDML code to fail when compiled. We don’t mention this as a condemnation of LANSA, but as a warning. Some templates will work as-is; others will require you to modify the template to your specific requirements. This is clearly stated in the help text for this template and can be fixed by modifying either the generated RDML code for a specific instance of the template, or the template itself.
We found another template that implemented a non-pop-up header/detail data entry screen, and this one gave us the desired effect. In fact, it was just what we were looking for which proves our point about templates – some will be perfect for your needs; others, not so much.
Finally, we created a function based on a report template to implement our issue detail report. We think that reporting is going to be the place where you will have to do the most customization. The templates provide a good framework for a particular type of report, but to get the report looking the way you want will require a major amount of tweaking. That said, we think that LANSA provides a decent environment for changing screens and reports. We messed around with it a bit and our experience tells us that with a little bit of work, any desired report could be generated.
Once all of our screens and reports had been created and debugged, we tested them out in green screen mode. Everything operated as expected; so, we moved on to evaluate LFTW.
It’s Not Easy Being Green
The version of LANSA we tested generates AS/400 5250 green screen applications, which as most of you know, are not looked on as being state of the art anymore. Everybody wants to give access to AS/400 data via the Web, whether it be a product catalog or an order-entry system, the application flavor of the day is Web-enabled and browser-based.
This is where the "for the Web" part of LANSA for the Web comes in. Simply stated, LFTW allows an existing LANSA application to be accessed over the Internet via a Web browser. The architecture of LANSA makes this a pretty easy task. LANSA is already set up to translate RDML code into different languages, like RPG or C. All LANSA (the company) needed to do was write code that translates RDML into HTML. It’s actually a little more complicated than this – there is a server component (CGI) of LFTW that the HTML talks to – but, basically, generating a Web application isn’t fundamentally different from generating a green screen application.
In fact, from a user perspective, generating a functional Web application is a one-step process. If you are making an existing LANSA application Web-capable, you just need to go into the "Work with processes" screen, choose option 28, and change the "Enabled for the Web" choice to "Y." If you did this when you created the process, you already have a Web-enabled application. If you did it after you created functions, you’ll have to recompile the process and functions.
Once you have a properly Web-enabled process, you can access the application with a Web browser. We entered the proper URL for our application and, presto, our application was displayed in the browser with a frame on the left showing a list of available functions.
We tested the applications and found everything worked fine. We did find a few quirks of the generated Web application.
The first thing we found was that you can’t use the back button on your browser. You must use the links that LANSA provides, or you will get an error message. A link for each appropriate action is provided by default. This isn’t a big deal, but without training it might cause some confusion for the users of the application.
To get around this effect you can use WEBEVENTS functions that allow the use of the browser back button. The drawback of using WEBEVENTS functions is that, because they use features specific to a particular interface (in this case, the Web), you can’t access WEBEVENTS functions from the green screen. If you want an application that can be accessed from both green screen and Web, don’t use WEBEVENTS functions. If you only want a Web application, go wild.
The next quirk we found was the behavior of the enter key. In some cases, the enter key behaved, as we would expect it to, (i.e., it committed the data and took us to the "next" page). In other cases, it took us all the way back to the Web site’s home page, or sometimes, the main menu.
With the LANSA HTML Editor, which runs under MS Windows, you can customize the appearance of your HTML pages to suit your needs. We played around with the editor and found that changing your Web pages is fairly straightforward, but tedious. You can use a third-party HTML editor, but you won’t be able to edit the pages graphically because of the LANSA directives that are embedded in the code. If we could urge one improvement in LFTW, it would be to have a graphical HTML editor so that you could see how your changes will affect the look of the page.
One step in this direction is the beta E-Business Framework Wizard that we tested. The wizard allows you to change the look of your entire LFTW application in one fell swoop, without a ton of manual changes. We used the wizard to give a more pleasant look to our application than the default LANSA look. Unfortunately, the wizard is not perfect at this point, and the HTML it generates does not display properly – there seems to be a problem with the rather large LANSA logo peppered all over the place. LANSA might be better served by using small placeholder images that will allow the pages to display properly, and forego the free advertising.
In any case, the wizard does give you a lot of choices, and it is easy to use. It certainly beats manually redesigning all of the pages!
The Bottom Line
You know the saying, "I’ve got good news, and I’ve got bad news?" Well, first, the good news. We found LFTW to be an easy-to-use and powerful development tool that can help any IS department get an AS/400 database connected to the Web, and in a reasonable amount of time. We thought the strongest part of LFTW was LANSA itself. We were able to learn to use the tool quickly, and we think it is a powerful way to develop any application, not just Web applications. Its data dictionary-centric development paradigm speeds the development process and allows you to enforce rules and standards. If you have built your core business logic in a modular form, you will be able to integrate it with the LANSA screens and not have to do a lot of hand reprogramming.
The bad news is that we think the Web portion of LFTW needs work. Certainly, the amount of work to get a functioning Web application is not the problem. Once the green screen application was finished, making it Web-enabled was, basically, instantaneous. Unfortunately, the HTML produced will take a lot of extra work to be ready for prime time. The E-Business Framework Wizard beta we tested helps, but a lot of work will still need to be done. If you send your HTML people to LFTW training (you do have HTML people, don’t you?), you should be OK.
Chris Amaru is a contributing author for Enterprise Systems.