Three Workflow Approaches with WebLogic Portal

This is a blast from the past originally published at when they were still interested in portal development.  I came across it because I needed a reference to Nested Page Flows and couldn’t find one until I ran across a link to my own article. Deja dude. Anyway, here it is. One day I will clean up the mark up, but for now it is still useful for reference and so long as the link above works you can still see the clean version…

While the disclaimers usually start later, this article merits one up front: These are not the only solutions to creating workflows in WLP. For example, we’re not even going to touch on JSF, or consider the possibility of special considerations in a federated portal architecture. So don’t let yourself be limited by the scope of this article or author’s experiences, and prejudices. What we will examine is some solutions that are known to work and should give you enough of the basics to implement any set of workflow requirements on WLP.

Simple Page Flows

Page flows provide a very straight forward approach to creating a workflow. Using the built-in wizard will quickly generate your page flow controller with the default begin action. This default action is a simple action, which doesn’t do much for flow as all it does is forward to the generated index.jsp.

This is quickly enhanced by right-clicking on the begin action under the Actions folder in the page flow perspective and selecting Convert to a Method.

Now you can begin adding workflow logic to your page flow. This approach is good for a simple process where the user will enter data in multiple forms and each submit does some level of processing on new data entered. You can even provide branching logic, forwarding to an action based on inputs. In either case, a single form bean in the page flow controller serves well to maintain the values, placing “frozen” values into hidden fields to maintain them from page to page and action to action.

Below is a series of action stubs that follow a simple workflow to create a web site user account:

What makes this simple is that each JSP uses the same form bean, with the action set to the next action. In a more robust implementation each action would also have an error page to forward to, which could easily be the JSP that submitted the information (such as processUserNameAndEmail does) with error messages. This example could be expanded with some simple branching; such as if the user already exists in the database the page flow action could forward to a password reminder page instead of simply going back to the index page.

Nested Page Flows

Nested page flows take planning a coordination between the originating and nested controllers.This makes them very useful when the work flow is predetermined and not expected to change much or often. In other words, the nested page flow approach is best suited to Waterfall projects where most (if not all) requirements are known prior to development.

Nested page flows allow passing control off to another controller while maintaining the state of the originating controller. This can be useful for branching logic or if you are creating multiple workflows that have the same set of steps as part of the flow. You can develop a page flow control that does the common steps, then call it from the controllers that deal with the parts of the workflow that vary. For instance, in our earlier simple page flow we could add a survey in the work flow before the subscription page to determine what types of subscriptions to offer. This survey workflow could also be presented to existing users at log in if their responses were out of date or when there was a new survey. In both the account creation scenario and the login scenario, the survey comes in at the middle of the process, so we want to be able to reuse the survey code without losing the state of either the enrollment or login workflow, so we call the survey flow as a nested flow.

If you know you are going to be calling a page flow as a nested flow at the beginning you can get the necessary annotations and action methods generated by checking the “Make this a nested page flow” option at the start of the page flow creation wizard. The two key ingredients to making a pageflow nested is in the controller annotation at the class declaration:

As noted, this takes a good deal of planning up front. For a more Agile approach, let’s look at a new approach.

Event Flows

As far as the author knows, this is the first description of using events for this particular purpose. This is probably because the author doesn’t have as much time to read articles as write them, because it is a fairly intuitive leap to go from inter-portlet communication (a common use of portal events), to passing control back and forth between specialized controllers as well as loading hidden pages used only for special purposes in a workflow.

Events are a handy way of decoupling your controllers and actions. They allow you to move from one controller to another and back again with the only explicit relationship being to the event rather than the action. If you come up with a better way of handling an event or your workflow rules change, you can simply change how the event is handled rather changing all parts of the workflow.

Let’s say we are looking at a login workflow. When the user logs in, the first step would always be to check their credentials. From that point, there are many tasks we may want the user to do. It may be time for them to change their password, or there may be a message we want to show them based on some demographic information. None of these activities are mutually exclusive and could occur in any combination. We could use simple page flows or nested page flows to achieve this, but that would require tight coupling between the actions and/or controllers. Instead, we can fire an event based on an evaluation and send the user off to take a survey (for example). When they have completed the survey we may want them to see a bulletin or not. So rather than having the logic in the survey action as to where to send them to next, we can send them back to the initial action which will then evaluate whether they should just go to the landing page or somewhere else (such as our bulletin) first. The bulletin could either send them back to the same action after the user acknowledges receipt or forward them on to the landing page itself.

Accomplishing is fairly straight forward. For each page where you want to handle an event, create a .portlet file. While the portlet configuration must have some class defined where it would presumably start, once you add event handling to the configuration you have ultimate control over how to respond to that event. Let’s look at a simple example of how this works.

Our logic can go in any action, but for simplicity we will put it in the begin action:Since this action method always evaluates the users’ status, we can continue to send them back here and determine where to go next. If value of the status doesn’t have a case, we simply send them to the forward destination.

Each of the events has a portlet event handler registered to listen for it. The handlers can be in as many different portlet definitions as we want, allowing for reusing the methods in the same controller on different pages or be able to have several different controllers interact with each other through the event framework. Keeping our example simple, we will have the methods in one controller in a single portlet:

The above example is for the sake or brevity. It is far more likely that these events would be handled by multiple portlets either due to presentation considerations (such as going from a page full of portlets to a page with a single portlet) or logical separation of functionality (such as a survey controller, bulletin controller, etc.).

In addition to custom events, page flow actions are events that can also be listened for, allowing for the possibility of completely changing the functionality of action by listening for it and adding additional or new behaviors. The combinations are endless and can often be changed with only a minor configuration update or a single line of code. This simplicity is key to agile methodologies and provides developers with a rapid way to add functionality on an as needed basis.
Workflows are a common requirement for portals. While the examples in this article revolved around a simple registration and login process, they were chosen for their commonality. Employment applications, freight logistics, legal document creation, supply requisitioning, and financial transactions are other common workflows that are often required within a portal. Those that are straight-forward with little or no deviation are easily implemented with a simple page flow. Nested page flows provide a solution to complex workflows that need to interact and provide an opportunity for the reuse of common sub-flows when a project has well defined requirements. For a more agile approach, listening for and calling events provides a flexible, loosely-coupled way to call portlet methods within and between controllers without having to know all of the specifics what future requirements may be.

© Scott S. Nelson

Cleaner Code with the PMD Eclipse Plug-in

Re-post from the original publication on December 4, 2008 at

Most developers like to write clean code. So why is so much code in the world messy? While there are many opinions about this, there are two contributing causes that very most everyone will agree on.

One of the reasons is that there is rarely enough time to write code as cleanly as we would like. Even when code starts clean, the continual refactoring from changing requirements, shifting dependencies and the inevitable bug fixes (often a result of the first two factors) leads to messy code just as surely as short deadlines and long hours make an organized person’s desk become littered with piles of unfiled papers and unfinished notes.

The other reason that is generally agreed on for code in the real world not being as clean as it starts out in our minds is because not everyone generally agrees with what clean code should look like. Some people are more certain that their version is cleaner than another, and there are people who hold different opinions with equal conviction. For example, which row the opening brace of a method belongs. An example where I’m fairly certain I am not the only person who has had endless email threads and inconclusive meetings about. The one, final answer will not be decided in our lifetime.

While the coding standards of an enterprise or project team may begin as a democratic process, they will not be useful as a benchmark until their definition evolves to a benevolent dictatorship (remember, we are discussing business, not government here). Once the standards are defined, a third reason for not meeting them comes into play, which is that there are usually more rules than most folks can memorize, or remember when the time pressure is on or when the rules of one project differ from those of another. For these causes of messy code, I have found PMD to be the best solution based on its flexibility and ease of use. The letters themselves do not really stand for anything. The creator(s) just thought they sounded good together. The PMD home page supplies “several “backronyms” to explain it.”

About PMD

The PMD home page describes the value of the project simply and concisely as something that scans Java source code for potential problems such as possible bugs, dead code, suboptimal code, overcomplicated expressions, and duplicate code.

PMD is more than just an Eclipse plug-in, in fact it is available as a plug-in for many IDEs. It can be run from a command line or as an ANT task. This makes it perfect for Agile projects as it can be integrated into the developer’s IDE and run as part of an automated build process. Even if you aren’t running automated scans at build time, making it part of your IDE will allow you to write cleaner code as a developer and to speed up code reviews as a reviewer.

Eclipse Plug-in Installation

While Google is a developers best friend (though I really miss DejaNews), for the more mature Eclipse plug-ins it pays to read the details of your Google search results. In the early days of Eclipse plug-ins, the use of the update manager was less prevalent. Most plug-ins at that time were made available as downloads. Many of the plug-in projects that have survived since those early days have since moved entirely to the Eclipse project’s preferred method of using the update manager. While this can be annoying to those of us who began using Eclipse in the early versions (especially when maintaining a portable tool kit), it is a much cleaner way for plug-in projects to publish their wares and make it easier for the user to get the correct version for their workspace. I mention this because while preparing for this article my Google search found the original download site at Even though it wasn’t the highest ranked, it did come in third and the habit to want a download rather than an update manager URL is hard to break. Just before downloading the zip file, I noticed that site was last updated in 2005. Had I installed that version I would have then spent part of my afternoon cleaning up the mess of my highly-personalized workbench.

The currently maintained site is at, where you will find the update manager URL of As a refresher from the Building the Perfect Portable Eclipse Workbench article, here are the steps to install PMD through the update manager:

Figure 1: Access the Update Manager from HelpSoftware UpdatesFind and Install

Figure 1: Access the Update Manager from HelpSoftware UpdatesFind and Install

Figure 2: Select Search for new features to install in the Update Manager Options

Figure 2: Select Search for new features to install in the Update Manager Options

Figure 3: Add the PMD URL to the Site List

Figure 3: Add the PMD URL to the Site List

From this point, the standard “Next, Next, Next” steps can be easily followed. Upon success, you will have a new perspective in your workbench:

Figure 4: The PMD Perspective

Figure 4: The PMD Perspective

If you happen to use the PHP version of Eclipse you will need to accept the restart Eclipse option or be annoyed by prompts telling you that your workspace is a mess.

Checking Your Code with PMD

While PMD can be customized to meet your coding standards, you can start using it immediately after installation with the default configuration. For those who don’t already have documented coding standards, these defaults can provide a good starting point.

PMD allows you to check code at any level available in the code view, i.e., at the project, package or class level. The code check is run by right clicking on the code level you wish to check and selecting Check Code with PMD from the PMD options:

Figure 5: PMD Options in Right-Click Menu

Figure 5: PMD Options in Right-Click Menu

The location and number of violations is then displayed in the PMD view.

Figure 6: Check Code with PMD Results
Figure 6: Check Code with PMD Results

You can drill down in the Violations Overview from the level you ran the check at all the way to individual line and violation description.

If you are introducing PMD mid-stream into a large project, the scan can take a long time. Once PMD has become part of your regular coding environment, getting in the habit of running a scan on each class you have created or updated prior to checking it into source control can save hours of bug hunting, not to mention reducing the possibility of embarrassing comments during code reviews.

After running a code check, the results can be exported by selecting Generate Reports from the PMD menu. A new folder will be added to your project named “reports” where the output will be available in several different formats.

Another cool feature is the ability to search for duplicate code with the Find Suspect Cut and Paste menu selection. The results of this search can help to pin down repeated code that should become part of a utility class.

Customizing PMD

If one reason for messy code is the differing opinions of what constitutes clean code then the expectation that the default rules will be perfect for every project is a bit ambitious. The PMD project takes this into account by making it very easy to customize which rules to enforce and what level of attention they should be given.

The basic view generally won’t need to be changed:

Figure 7: Basic PMD Option
Figure 7: Basic PMD Option

The predefined rules can be edited and removed easily in the preferences view. Changing descriptions to match the text of your coding standards can make the standards themselves easier to remember. As running the code check becomes more of a habit, most developers will tend to have fewer violations as correcting them reinforces remembering how to code to the standards.

Figure 8: Customize Rules with Configuration

Figure 8: Customize Rules with Configuration

One key option is the violation level. In the code check results view there are color coded toggles to set what level of violations to show (see Figure 6). When time for code review is limited, selecting the higher priority level (lower numbered) violations can help developers and reviewers focus on the most urgent violations.

When determining what level a violation should be it is a good idea to avoid the temptation to go too high as the top level violations will prevent compilation of code.

Figure 9: Error High Prevents Compilation

Figure 9: Error High Prevents Compilation

If you are adopting PMD mid project, setting too many violations at the highest level can bring project progress to a screeching halt or drive developers to remove the plug in, both results defeating the purposes of improving quality while saving time. However, if PMD is part of your environment from the first line written, high violation settings can lead to improved code quality throughout the project.

PMD also allows for creating your own rules, a task that is far beyond the scope of this article. Full documentation is available at Most teams will find that customizing the descriptions and priorities of the large selection of pre-defined rules will be more than adequate for their needs.

Once the rules have been customized to match your standards, they can be exported for sharing across the enterprise or team.

While the tool itself is simple to install, customize and use, creating practices and policies to get the most of its use may take a bit more work. My personal preference is to make sure all violations at all levels have been addressed prior to the completion of the QA phase. Even with the best-defined rule sets, there will be some exceptions to the rules, and the project allows for this by providing a “Mark as reviewed” option. Using this option adds an annotation at the end of the line of code that will allow the code check to skip that violation in future checks.


PMD is a great tool for improving code quality, developing good habits and speeding up code reviews. It is not a panacea that can completely replace manually reviewing code. Code is an art as well as a science and automated tools have a long way to go before a level of heuristics that can be 100% reliable will be reached.

About the Author

© Scott S. Nelson