January 16, 2021
Hot Topics:

Three Workflow Approaches with WebLogic Portal

  • By Scott Nelson
  • Send Email »
  • More Articles »

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, and then call it from the controllers that deal with the parts of the workflow that vary. For instance, in the earlier simple page flow, you could add a survey in the work flow before the subscription page to determine what types of subscriptions to offer. This survey workflow also could 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 you want to be able to reuse the survey code without losing the state of either the enrollment or login workflow, so you 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 are in the controller annotation at the class declaration:

@Jpf.Controller(nested = true)
public class NestedPageFlowAController
   extends PageFlowController{

And, the necessity to have an action with a forward that includes a return action:

@Jpf.Action(forwards = { @Jpf.Forward(name = "done",
   returnAction = "portlets_nestedPageFlowADone")})
protected Forward done() {return new Forward("done");}

The return action must be an action method that exists in the controller that called the nested controller. Calling the nested controller is simply a matter of having an action with a forward that resolves to the nested controller (or a method within the controller), like this:

@Jpf.Action(forwards = { @Jpf.Forward(name = "success",
   path = "subscribeNewsletter.jsp")})
      Forward portlets_nestedPageFlowADone(userDataFormBean form)
   {return new Forward("success");}

As noted, this takes a good deal of planning up front. For a more Agile approach, 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.

Say you 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 you may want the user to do. It may be time for them to change their password, or there may be a message you want to show them based on some demographic information. None of these activities are mutually exclusive and could occur in any combination. You 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, you 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, you may want them to see a bulletin. So, rather than having the logic in the survey action as to where to send them to next, you can send them back to the initial action which then will evaluate whether they should just go to the landing page or somewhere else (such as your 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 straightforward. For each page where you want to handle an event, create a .portlet file. Even though 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. Look at a simple example of how this works.

Yor logic can go in any action, but for simplicity you will put it in the begin action:

public Forward begin(userFromBean form)
   PortletBackingContext pbc =
   int status = getStatus(form.getUserId());

      case 0:
         pbc.fireCustomEvent("callDisplayBulletin", form);
      case 1:
         pbc.fireCustomEvent("callChangePassword", form);
      case 2:
         pbc.fireCustomEvent("callPresentSurvey", form);
   return new Forward("default");

Because this action method always evaluates the users' status, you can continue to send them back here and determine where to go next. If value of the status doesn't have a case, you simply send them to the forward destination.

Page 2 of 3

This article was originally published on August 4, 2008

Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Thanks for your registration, follow us on our social networks to keep up-to-date