Pageflow and Form Guide

CHAPTER 3

Working with Activities

This chapter introduces the activities you can use in a pageflow process. It includes these topics:

• About pageflow activities

• Mode activity

• Form activity

• HTML activity

• XML activity

• Pageflow activity

• JSP activity

• Servlet activity

• Initial Query activity

• Get Page activity

• Get Record activity

• Record Insert activity

• Record Update activity

• Record Delete activity

• Apply Change Log activity

• Rule activity

• CheckPoint activity

• Exception activity

• Java activity

• XSL activity

• Web Service activity

• Composer Service activity

• Finish activity

• Workflow Return activity

About pageflow activities

Categories

There are several categories of pageflow activities:

NOTE:   The Database tab in the Pageflow Modeler also includes the Data Set. The Data Set is not an activity in the conventional sense. At design time, you can make changes to the definition of the Data Set, just as you would make changes to any pageflow activity. But at runtime the Data Set does not behave like an activity: it does not perform any processing or affect the flow of control as the other activities do.

    For more information on the Data Set, see Working with the Data Set.

The pageflow activities have properties you can set in the Pageflow Modeler. Some of these properties are common to all activities, whereas others are available only on some of the activities.

Most pageflow activities have a primary property. The primary property associates an object with the activity. For presentation activities, this is the item to display. For system properties, this is the object you want to execute.

Mode activity

Description

The Mode activity is the starting point for a particular mode within a pageflow. The Mode activity initiates a series of activities that are performed when the process is in that mode. Each mode activity maps directly to a portlet mode, as defined by the Portlet specification (Java Portlet 1.0).

The Mode activity is a required activity. Each pageflow must have at least one Mode activity of type View. When you create a new pageflow process, the Pageflow Modeler automatically adds a Mode activity that has the View type.

A pageflow can have multiple Mode activities. For example, a pageflow might have Mode activities that specify what happens when the flow is in View, Edit, or Help mode:

Properties

The properties of the Mode activity are:

Usage

What happens when a pageflow is initiated   All pageflows start in View mode. Since the Portlet specification requires that all portlets implement this mode, View mode is required in pageflows.

What happens when the user switches modes   The user can switch modes at runtime—mode switching is a runtime-only function. The pageflow runner detects mode switches by examining request information provided by the Portlet container. If a mode switch is detected, the flow is restarted using the named mode. If the mode specified cannot be found, an exception is thrown and the flow remains in its previous state. The default mode is not used during mode switching.

Form activity

Description

The Form activity is a presentation activity that specifies an XHTML file to display at runtime. The XHTML file defines a form for user interaction. The form uses XForms technologies to define the user interface. By providing access to the full range of XForms capabilities, the Form activity gives you an extremely powerful tool for building presentation into a pageflow process. The form displayed by a Form activity can include a variety of user controls, such as buttons, input fields, and labels. The form can also give the user a way to interact with a database or Web Service.

The exteNd Director Form Designer provides a graphical environment for developing XForms 1.0-compliant Web forms. The Form Designer lets you create and modify XHTML forms that can be displayed with the Form activity.

    For details on working with the Form Designer, see Form Designer.

Properties

The properties of the Form activity are:

HTML activity

Description

The HTML activity is a presentation activity that specifies HTML content to display at runtime.

If the HTML content you want to display contains an HTML form, the action for the form must specify the wsrp_rewrite token, an industry-standard token defined by the WSRP specification:

  action="wsrp_rewrite?wsrp-urlType=blockingAction/wsrp_rewrite"

NOTE:   This version of exteNd Director does not provide full support for the WSRP protocol. But, support for many WSRP features has been implemented. For example, the wsrp_rewrite token is required in the action for a form.

XHTML content that you display in a Form activity can specify this abbreviated syntax in the action for a form:

  <xforms:submission 
     action="?verb=help"
     id="help"
     method="post"/>

NOTE:   This syntax is not supported in HTML content.

Example 1   Here's a sample HTML page that could be displayed with an HTML activity. The HTML source for this activity has a Next button that passes a value of next for the parameter named verb:

  <form name="form1" method="post" action="wsrp_rewrite?wsrp-urlType=blockingAction/wsrp_rewrite">
   <p>Enter your name
      <input type="name" name="name">
      <br><br>
      <input type="submit" name="verb" value="next">
      <input type="submit" name="verb" value="help">
  </form>

Example 2   This example shows tags that take advantage of the classes defined in the theme CSS file. By mapping your tags to classes in the CSS file, you can ensure that these tags will alter their appearance according to the display characteristics of the currently selected theme:

  <form name="form1" method="post" action="wsrp_rewrite?wsrp-urlType=blockingAction/wsrp_rewrite">
  <br/>
  	 <span class="portlet-form-field-label">
  	 	 Zip
  	 </span>
  	 <input class="portlet-form-field" type="name" name="zip" value="02630" size="20"> 
  	 <br/><br/>
  	 <input type="submit" name="verb" value="Continue">
  </form>

Properties

The properties of the HTML activity are:

XML activity

Description

The XML activity is a presentation activity that specifies XML content. Pageflows can return content of type text/xml. This allows you to use portal styling to control the presentation, which is particularly useful when you want to perform transcoding for wireless applications.

A pageflow can have multiple renderable activities. When you return XML content, you must use XSL to determine which template to use for the returned XML.

To style the content for a pageflow, you need to add the proper style to the portlet fragment deployment descriptor associated with the pageflow.

Properties

The properties of the XML activity are:

Pageflow activity

Description

The Pageflow activity includes a separate pageflow within the current flow.

The Pageflow activity performs a runtime include. The Pageflow Modeler does not perform any design-time checking to ensure that the flow specified by the Pageflow activity will actually work properly within the containing flow.

When you include a pageflow within another pageflow, the Mode activity within the included flow must have a type that matches the Mode type of the containing flow. Also the included flow must have a Finish activity. The Finish activity tells the engine when to return to the containing flow. If the included flow does not contain a Finish activity, control will never be returned to the containing flow.

When a pageflow is included within another pageflow, the Mode and Finish activities within the included flow perform any scoped path functions required and then execute a forward operation.

Properties

The properties of the Pageflow activity are:

Usage

At runtime, the Pageflow activity doesn't perform any processing itself. Instead, it just instructs the pageflow engine to insert the included pageflow within the main pageflow before the process is started.

These are the basic steps the engine performs when it includes a pageflow within another pageflow:

1. Gets the pageflow to include using a scoped path.

2. Creates a new link between the main pageflow activity and the first Mode activity in the included flow.

3. Moves all outbound links from the main pageflow to the included flow's Finish activity.

4. Replaces the <modeactivity> nodes from the included flow's document with <activity> nodes.

5. Imports all activities from the included flow into the main flow.

6. Imports all links from the included flow into the main flow.

7. Creates a new process using the dynamically generated pageflow document.

This process is repeated for each included flow.

Example

Suppose you have a main pageflow that looks like this:

The Pageflow activity points to this flow:

At runtime, the main pageflow document is manipulated to create a flow that might look like this if it were drawn in the Pageflow Modeler:

JSP activity

Description

The JSP activity is a presentation activity that calls a JSP page.

The JSP page called by a JSP activity must handle the creation of its own URL for processing. To get the correct URL for a JSP activity, you need to add these lines to your JSP page:

  RenderResponse renderResponse = 
    (RenderResponse)request.getAttribute( "javax.portlet.response" );
  String MYURL = renderResponse.createActionURL().toString(); 

The string javax.portlet.response is defined by the Portlet specification. Since exteNd Director provides complete support for the Portlet specification, this string is available to all JSP pages (and servlets) that run within exteNd Director.

Usage

The form you create in your JSP page should look like this:

  <form name='myform' method='post' action='MYURL'>

You can use the JSP Wizard to create JSP page files. If you plan to call a JSP page from a JSP activity, you need to store the JSP page directly within the current WAR file. The JSP activity is not able to access JSP pages stored within a JAR inside the WAR file.

To execute a flow that contains a JSP activity, you need to modify the portlet descriptor generated by the Pageflow Modeler. You must add charset=ISO-8859-1 to the list of supported mime types:

  <supports>
    <mime-type>text/html; charset=ISO-8859-1</mime-type>
    <portlet-mode>view</portlet-mode>
  </supports>

Properties

The properties of the JSP activity are:

Example

Here is an example of a JSP page that you might call from a JSP activity:

  <%@ page language="java"
          session="true"
          isThreadSafe="true"
          contentType="text/html; charset=ISO-8859-1" %>
  
  <% 
  //************************************************************ 
  // User needs to make sure to import "javax.portlet.*;"
  %>
  <%@ page import="javax.portlet.*" %>
  
  <%
  // For the JSP Activity to work, the user must build the correct
  // URL for their HTML Form to submit to.  
  
  // The HttpRequest object is available to all JSPs by default.
  // The user can get the RenderResponse object from the HttpRequest
  // at the well-known location of JAVAX.PORTLET.RESPONSE on the
  // HttpRequest object.  The user can then build the URL from that 
  // RenderResponse by calling renderResponse.createActionUrl().  
  // Whatever the value of that URL is should be placed in the Form.
  
  // Get the RenderResponse
  RenderResponse renderResponse = (RenderResponse)request.getAttribute( "javax.portlet.response" );
  String MYURL = "";
  try {
      // Build the correct URL for the HTML Form
      MYURL = renderResponse.createActionURL().toString();
  }
  catch( Exception e ) {
      e.printStackTrace();
  }
  %>
  
  <% // Make sure the URL the user built is the "action" attribute 
     // of the HTML Form %>
  <form method="post" action="<%= MYURL %>">
  <% //*********************************************************** 
  %>
      <hr>
      <br><br>
      <p>Enter a value to POST back to Tom: <input name="testValue"/>
  
      <br>
  	 <input type="text" name="tomText"/>
      <input type="submit" name="Submit" value="Submit">
      <br><br>
      <hr>
  </form>
  

Servlet activity

Description

The Servlet activity is a presentation activity that calls a servlet.

At runtime, the Servlet activity calls the doGet() method on the servlet. The doGet() method must return HTML that can be displayed to the user.

The servlet called by a Servlet activity must handle the creation of its own URL for processing. To get the correct URL for a Servlet activity, you need to add these lines to your servlet code:

  RenderResponse renderResponse = 
   (RenderResponse)request.getAttribute( "javax.portlet.response" );
  String MYURL = renderResponse.createActionURL().toString(); 

The string javax.portlet.response is defined by the Portlet specification. Since exteNd Director provides complete support for the Portlet specification, this string is available to all servlets (and JSP pages) that run within exteNd Director.

Usage

The form you create in your servlet should look this:

  <form name='myform' method='post' action='MYURL'>

You can use the Servlet Wizard to create new servlet Java class files. When you do this, the Servlet Wizard automatically adds the required entries to the web.xml file for the new servlet.

If you plan to call a servlet from a Servlet activity, you need to store the servlet class directly within the current WAR file. The Servlet activity is not able to access servlets stored within a JAR inside the WAR file.

Properties

The properties of the Servlet activity are:

Example

Here is an example of a servlet you might call from a Servlet activity:

  package com.test;
  
  import javax.portlet.*;
  import javax.servlet.*;
  import javax.servlet.http.*;
  import java.io.*;
  import java.util.*;
  
  public class myServlet extends HttpServlet {
   
    static final String CONTENT_TYPE = "text/html";
  
    // Handle the HTTP GET request
    public void doGet( HttpServletRequest request,
     HttpServletResponse response )
     throws ServletException, IOException {
  
      response.setContentType( CONTENT_TYPE );
      PrintWriter out = response.getWriter();
  
  //*****************************************************************
      String url = "";
      try {
       // The Servlet Activity must have a certain URL as the value 
       // of its HTML Form "action" attribute. 
       // Like the HTML Activity, the user will be responsible for 
       // building this URL themselves. They must do this, or the 
       // flow will not move along to the next activity.
       
       // The way to get this URL is from the RenderResponse object.
       // The Portlet Spec tells us that the RenderResponse MUST BE      // AVAILABLE  on the HttpServletRequest
       // object as the JAVAX.PORTLET.RESPONSE attribute.
       // This object will be there for any servlet who wants it.
  
       RenderResponse renderResponse = 
        (RenderResponse)request.getAttribute
         ( "javax.portlet.response" );
      
      // Once we have the RenderResponse object, the user needs to     // create an ActionURL from it, 
      // and then turn that ActionURL into a String.
       // This is the URL the user should use as in the HTML form.
  
       url = renderResponse.createActionURL().toString();
     }
     catch( Exception e ) {
       e.printStackTrace();
     }
  
      // Now the user needs to put the String as the value of the 
      // "action" attribute in the HTML Form.  
      // This way the Engine understands that it 
      // should move the flow along after a submit if that's what 
      // the user wants.
  
       out.println( "<form name='myForm' method='post' action='" + url + "'>" );
          //*****************************************************************
  
      out.println( "<p>Servlet MyServlet has received an HTTP
       GET.</p>" );
      out.println( "<p>The servlet generated this page in response 
       to the request.</p>" );
      out.println( "<input type='text' name='tomText'/>");
      out.println( "<input type='submit' name='tomSubmit'
       value='blah'/>");
      out.println( "</form>" );
   }
  
  
    // Handle the HTTP POST request
    public void doPost( HttpServletRequest request,
      HttpServletResponse response )
      throws ServletException, IOException {
  
     response.setContentType( CONTENT_TYPE );
     PrintWriter out = response.getWriter();
  
     out.println( "<p>Servlet has received an HTTP POST.</p>" );
     out.println( "<p>The servlet generated this page in response to
      the request.</p>" );
     out.println( "" );
    }
  }

Initial Query activity

Description

The Initial Query activity obtains the keys of all records from the database that match the user's search criteria. This activity takes an XML document that contains the search terms as input. When the keys have been retrieved from the database, it stores the result set in a record cache.

Properties

The properties of the Initial Query activity are:

Get Page activity

Description

The Get Page activity retrieves the summary data for a single page of records. This activity uses the set of keys returned by the Initial Query activity to determine which records to include in the summary data.

Properties

The properties of the Get Page activity are:

Get Record activity

Description

The Get Record activity retrieves the detail fields for a single record.

Properties

The properties of the Get Record activity are:

Record Insert activity

Description

The Record Insert activity sends the data for the new record to the database by executing a SQL INSERT statement.

NOTE:   If you enable the change log, the SQL INSERT is not actually performed until the Apply Change Logs activity is executed.

Properties

The properties of the Record Insert activity are:

Record Update activity

Description

The Record Update activity sends the updated data for one record to the database by executing a SQL UPDATE statement. To support optimistic concurrency control, the UPDATE statement includes the original (cached) values in the WHERE clause.

NOTE:   If you enable the change log, the SQL UPDATE is not actually performed until the Apply Change Logs activity is executed.

Properties

The properties of the Record Update activity are:

Record Delete activity

Description

The Record Delete activity deletes the records selected by the user by executing a SQL DELETE statement. To support optimistic concurrency control, the DELETE statement includes the original (cached) values in the WHERE clause. The Record Delete activity sends a separate DELETE statement for each selected record, but the statements are all executed in a single transaction.

NOTE:   If you enable the change log, the SQL DELETE is not actually performed until the Apply Change Logs activity is executed.

Properties

The properties of the Record Delete activity are:

Apply Change Log activity

Description

The Apply Change Log activity applies all changes from the change log to the database.

When you run the Database Pageflow Wizard, you are given the option to store modifications in a change log, as shown below:

If you indicate that you want to use a change log (as shown above), the wizard includes an Apply Change Log activity in the generated flow:

Properties

The properties of the Apply Change Log activity are:

Rule activity

Description

The Rule activity is a system activity that executes a business rule at runtime.

Properties

The properties of the Rule activity are:

CheckPoint activity

Description

The CheckPoint activity is a directive activity that allows you to specify the processing required to refresh a page within a flow. The CheckPoint activity acts as a transaction marker, indicating the starting point for processing required to rerender the page.

The CheckPoint activity is typically associated with a presentation activity (HTML, Form, or Portlet) within a pageflow. When the user tries to reload the presentation activity, the engine tells the flow to go back to the CheckPoint activity that precedes the presentation activity and continue from that point forward.

Performance tip   To enhance performance, you may not always want to include a CheckPoint activity before a system activity that performs background processing required for a portlet to be rerendered. For example, in a pageflow that invokes a Web Service, you might want to remove the CheckPoint activity so that the Web Service is not executed whenever the user refreshes the page or takes an action on another portlet within the page. If you know that the data associated with a page will not change frequently, then the CheckPoint activity may not be required.

NOTE:   An alternative to removing the CheckPoint activity is to use the portlet cache to minimize the number of rerender operations associated with a pageflow.

    For more information on using the portlet cache to improve performance in a pageflow, see Pageflow performance and portlet caching.

Usage

For example, suppose you have a pageflow that contains a Web Service activity and a Form activity that display the results of the Web Service invocation. The Web Service gets a stock quote based on a ticker symbol. Once the Web Service completes its processing, the Form activity displays the result. Whenever the user reloads the page, the data must be refreshed. To accomplish this, you could create a flow that looks like this:

Note the inclusion of the ManualQuoteRefresh link in this flow. This highlights the difference between a rendering triggered by a request (represented by the ManualQuoteRefresh link) and one triggered by the browser or Portlet container. Also note that the links SelectAnotherQuote and ViewAvailableStocks target the GetStocksCheckPoint. A link directly to the QuoteSelection activity would not cause the GetStocksCheckPoint and GetAvailableStocks activities to run.

In the example shown above, the same page is displayed for each rerender event, but with different data. You might also use a CheckPoint activity in a flow where each rerender event causes a different page to be displayed. For example, in Help mode you might want a flow to display a different help page each time the user requests a reload:

In this example, the links out of the helpCheckPoint activity are evaluated for each refresh to determine which help page should be displayed.

A pageflow may have any number of CheckPoint activities, however, there can be only one CheckPoint activity active at any point in time. At runtime, the CheckPoint activity performs these tasks:

1. Clears any previous CheckPoint activity registered with the process.

2. Registers itself with the process as the CheckPoint activity of record.

3. Sets a flag to indicate that it has just been executed and needs to be kept active.

4. Forwards processing on to any activities that are linked to it.

The logic that deals with how the engine reacts to the inclusion of a CheckPoint activity is built into the presentation activities.

Properties

The properties of the CheckPoint activity are:

Exception activity

Description

The Exception activity is a directive activity that acts as the safety net for a pageflow. Its purpose is to allow you to model how exceptions are handled within the flow. Each Exception activity is the starting point for processing that handles one or more exceptions.

When you create a pageflow, you do not add explicit links that point to the Exception activities. Instead, the links to the Exception activities are generated dynamically at runtime depending on which exception occurred. When an Exception activity gets control at runtime, it simply forwards processing to any activities that are linked to it. Once an Exception Activity has been called, control is not returned to the flow.

Usage

For example, suppose you define a pageflow that contains a Web Service activity. At runtime, it is possible that the Web Service being invoked is not available. To deal with this, you might add an Exception activity to the flow that traps java.rmi.ConnectException. In this case, the engine would forward processing to this activity whenever this exception was encountered. The Exception activity might then forward processing to an HTML activity that displays a meaningful message to the user:

A pageflow may have any number of Exception activities defined for it. A given Exception activity is associated with one or more exception classes. When you place an Exception activity on a flow, you specify its exception string in the Exception property. You can specify a complete class name (for example, java.lang,NullPointerException) or a partial name (for example, java.lang) to designate a set of exceptions that this activity should handle.

When an exception is encountered, the pageflow engine tries to match the exception to an Exception activity within the flow. You can instruct the engine to accept exact matches only for a particular Exception activity by setting its Recursive property to false. However, if you set the Recursive property to true, it will look for inexact matches as well, taking into consideration the package hierarchy as well as the inheritance structure.

If a match is found, a dynamic link to the Exception activity is created and a number of scoped paths are created to provide exception information to the custom exception handlers. These are the scoped paths that are created:

If no match is found, or if the exception handler itself throws an exception, an EboProcessException is generated and the exception is handled by the pageflow engine.

Example

Suppose you added an Exception activity that has an exception string of java.lang and set the Recursive property to true. In this case, suppose the java.lang.NullPointerException were thrown. This exception would be resolved as follows:

1. The engine would compare java.lang.NullPointerException against the list of known exception handlers within the flow and not find a match.

2. The engine would then drop the last segment of the qualified name and try again. This time it would find a match with java.lang and dynamically link to the Exception activity for java.lang.

Suppose the java.security.GeneralSecurityException were thrown. Here's how this exception would be resolved:

1. The engine would compare java.security. GeneralSecurityException against the list of known exception handlers within the flow and not find a match.

2. The engine would then drop the last segment of the qualified name and try again, still not finding a match for java.security.

3. The engine would then drop the last segment of the qualified name and try again, still not finding a match for java.

4. At this point, the engine would try to resolve the exception by looking at the superclass for java.security.GeneralSecurityException, which is java.lang.exception. It would not find a match for java.lang.exception.

5. The engine would drop the last segment of the qualified name and try again. This time, it would find a match with java.lang and dynamically link to the Exception activity for java.lang.

The Exception activity provides you with a flexible architecture for handling exceptions with a flow. If you want a particular Exception activity to catch a wide range of exceptions, you can specify an exception string that has a partial class name and set the Recursive property to true. On the other hand, if you want to exercise more control over what happens when a particular exception is thrown, you can specify a complete class name for the exception string and set the Recursive property to false.

Properties

The properties of the Exception activity are:

Java activity

Description

The Java activity is a system activity that executes a Java class within the context of a pageflow. A Java activity allows you to write custom business logic that executes automatically without user intervention.

The Java Activity Wizard helps you create a Java class that can be executed within a pageflow.

    For information on using the Java Activity Wizard, see Java Activity Wizard.

Properties

The properties of the Java activity are:

XSL activity

Description

The XSL activity is a system activity that uses XSL to transform an XML document.

Each XSL activity includes a property that specifies the XSL to use for the transformation. The activity also specifies an Input Document and an Output Document. The Input Document specifies the XML to transform. The Output Document specifies the document where the resulting transformation should be placed.

Properties

The properties of the XSL activity are:

Web Service activity

Description

The Web Service activity is a system activity that executes a Web Service.

The Web Service activity only provides support for document-style WSDL files that contain a schema. However, you can create a pageflow that uses an RPC-style Web Service by using a Java activity.

    For background information on Web Services, see the chapter on Web Service basics in Utility Tools. For details on how to use an RPC-style Web Service in a pageflow, see Working with RPC-Style Web Services.

The quickest and easiest way to create a pageflow that executes a Web Service is to use the Web Service Pageflow Wizard.

    For details on using the Web Service Pageflow Wizard, see Web Service Pageflow Wizard.

Properties

The properties of the Web Service activity are:

Composer Service activity

Description

The Composer Service activity is a system activity that executes an exteNd Composer service. exteNd Composer services typically combine executable units of work called components and coordinate the flow of data between them. A typical service might include a series of components that receive an input XML document, perform sophisticated document mappings/transformations, collect information from back-end data sources, execute transactions on mainframes and AS/400s, process error conditions, send context-sensitive e-mail or JMS notifications, and/or return one or more XML response documents to the original requestor(s). By breaking up a service's tasks into discrete components, important benefits—in terms of testing, debugging, code maintenance, and code reuse—can be realized.

The quickest and easiest way to create a pageflow that executes an exteNd Composer service is to use the Composer Pageflow Wizard.

    For details on using the Composer Pageflow Wizard, see Composer Pageflow Wizard.

Properties

The properties of the Composer Service activity are:

Finish activity

Description

The Finish activity is a system activity that marks the end of a pageflow. The Finish activity is not required in a pageflow unless it is being used within a another pageflow.

The Finish activity behaves differently depending on how the pageflow is being used:

• In a standalone pageflow, the Finish activity does nothing. The Finish activity is optional within a standalone pageflow.

• When a pageflow is included within another pageflow, the Finish activity simply forwards processing to the next activity within the containing pageflow. In this case, Finish is required so that the pageflow engine knows when to return to the containing pageflow.

Properties

The properties of the Finish activity are:

Workflow Return activity

Description

The Workflow Return activity is a system activity that tells a pageflow to forward its workitem to a workflow.

To use a pageflow in a workflow you:

• Create a pageflow that lets a user update the persistent workitem that will be passed in from the workflow. Use the Flow scope in the Pageflow Modeler to store the workitem data.

• Add a Workflow Return activity at the point in the flow where you want to return to the workflow and forward to the next workflow activity,

• Add a Pageflow activity in the Workflow Modeler at the point where you want to include the pageflow, and point to the pageflow descriptor. Use the Flow scope in the Workflow Modeler to access the updated workitem.

    For more information, see the section on using a pageflow in a workflow in the Workflow Guide.

The properties of the Workflow Return activity are:

Usage

If you run a pageflow that contains a Workflow Return activity and there is no workflow queue to forward (or the workflow engine is not running), the pageflow engine displays a message in the browser window:

  The Workflow Return Activity cannot find a workflow to forward.

The user can click the Continue button to continue processing.

Copyright © 2004 Novell, Inc. All rights reserved. Copyright © 1997, 1998, 1999, 2000, 2001, 2002, 2003 SilverStream Software, LLC. All rights reserved.  more ...