Workflow Guide

CHAPTER 3

Working with Activities

This chapter describes the activities you can use in the Workflow Modeler. It includes these topics:

• About workflow activities

• Pageflow activity

• User activity

• Web Service activity

• Rule activity

• Java activity

• Synchronize Merge activity

• Start activity

• Composer Service activity

• Finish activity

    For information about using the Workflow Modeler, see Workflow Modeler.

About workflow activities

There are two types of workflow activities:

About activity properties   The workflow activities have properties you can set in the Workflow Modeler. Some of these properties are common to all activities, and others are available only on some of the activities.

Some 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.

About scoped paths   Scoped paths are pointers to application data that you can select visually in the Workflow Modeler. You can use scoped paths to select the activity's primary property. In addition, most activities allow you to copy scoped paths before or after the execution of an activity.

    For more information, see the chapter on working with scoped paths in Developing exteNd Director Applications.

Pageflow activity

Description

The Pageflow activity represents a task or step in your business process that uses a portlet created using the Pageflow Modeler. Including a pageflow in a workflow allows you to take advantage of the Pageflow Modeler's integrated client technology.

Properties

The properties for the Pageflow activity are

Specifying the addressee   The addressee property determines where the workitem will be routed by the workflow engine. Each link can accept a single value for its Addressee property. Typically this value is a role, and the role defines a list of users with permission to perform work at the activity. You can also specify that the addressee value be dynamically derived at runtime from a workitem property.

To specify an addressee:

1. Open the Property Inspector for the activity and choose the Addressees tab.

2. Click Edit Addressee:

   

3. In the Value field specify a scoped path for a user or role. See the examples at the bottom of the Addressee form.

   • Click User if you are specifying a user known to your directory realm. For example:

     String/JSmith
   

   NOTE:   If you are accessing an LDAP realm, specify the distinguished name. For example:

     cn=user,ou=users.
   

   • Click Role if you are specifying a security role descriptor. For example:

     String/workflowUser
   

   The name of the security role you specify must be the name of a security role descriptor file, without the file extension. For the example shown above to work, you would need to define the role workflowUser in a file called workflowUser.xml.

       For information about creating and using roles, see the chapter on using security roles in the User Management Guide.

Usage

At runtime, the Workflow engine delegates processing to the specified pageflow until the Workflow-Return activity in the pageflow is executed.

This activity ensures that the workflow engine does the following:

• Executes a forward operation to the next workflow activity in the containing workflow.

• Closes the portlet window, if the close window property on the Workflow-Return activity is selected.

This process is repeated for each included pageflow.

    For more information with examples, see Pageflow in a workflow.

User activity

Description

The User activity represents a task or step in your business process that requires user interaction. Use this activity is for:

• A custom portlet, JSP page, or servlet not created or associated with a pageflow

• A non-Web client such as a word processing program or spreadsheet

Properties

The properties for the User activity are:

Usage

Binding activities to client types   The default client for workflow applications is the Portal subsystem. The Workflow subsystem provides a mechanism for specifying different client types for workflow activities. For example, you might want the UI for a particular workitem to be a spreadsheet application, a Java client, or some other application.

With a User activity you are required to specify clients in a descriptor called activity-policy.xml.

Creating an Activity policy descriptor    You need to create a descriptor that follows the schema is defined in activitypolicy.xsd, located in library/WorkflowService/schema in your installation directory. Place the descriptor in the data/workflow-activity-policy directory in your exteNd Director project's resource JAR.

NOTE:   The name of the file must be activity-policy.xml

Here is the activity policy defined for three portlets used in the installed Content Life Cycle workflow application.

  <?xml version="1.0" ?> 
  - <activitypolicy xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="activitypolicy.xsd"> 
  - <activity name="AssignContent"> 
  <client type="portal" uri="/portal/portlet/WorkflowAssignPortlet">Portal</client> 
  </activity> 
  - <activity name="CreateContent"> 
  <client type="portal" uri="/portal/portlet/WorkflowCreatePortlet">Portal</client> 
  </activity> 
  - <activity name="AuthorizeContent"> 
  <client type="portal" uri="/portal/portlet/WorkflowAuthorizePortlet">Portal</client> 
  </activity> 
  </activitypolicy>







 
Element



 
Description







 
name



 
The name of the activity. This must match the Name property in the Workflow Modeler. 

 
For example, the Name property in the Workflow Modeler for the first activity would be AssignContent







 
client 



 
The client type and URI for the application portlet or JSP page. The default client type is portal, which means the activity will use exteNd Director portal services to render the client.

 

NOTE:    You can also specify default as the client type and provide an implementation. You can also add a client tag under <activitypolicy> as a global default using the string default.

Adding client types   To provide a different client type you must modify the activity policy file and add the new client type and associated URLs. The XSL of the WorkflowQueue core portlet (WorkflowQueueDefault.xsl) looks for portal as the client type and uses the associated URL as the link for the activity. To reference a different client type, modify the XSL for the queue portlet and the activity-policy client type accordingly.

NOTE:   The WorkflowQueue portlet only supports direct URL references as an URI pointer.

Accessing policy information   EbiWorkitemDelegate provides access to activity policy information. Here are some of the methods:

Coding the User activity    You need to access the workitem and define your presentation logic in the implementation class. For code examples, refer to the sources for the User activities in the Content Life Cycle application.

    For more information see Content life Cycle application sources.

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 the context of a pageflow, see the chapter on working with RPC-Style Web Services in the Pageflow and Form Guide.

Properties

The properties of the Web Service activity are:

Rule activity

Description

The Rule activity represents the Rule subsystem functionality needed to execute a rule within a workflow. Rules allow you to build complex logic into your workflow by using installed conditions and actions.

Properties

The properties for the Rule activity are:

Java activity

Description

The Java activity represents an unattended task or step in your process. This can be any kind of logic or processing that you want to happen automatically without user intervention. You specify a Java class you want to execute, which you create using the Java Activity Wizard. The class that you define extends EbiJavaActivity.

    For information about creating and coding the Java class, see Java Activity Wizard.

Properties

The properties for the Java activity are:

Synchronize Merge activity

Description

The Synchronize Merge activity is used to synchronize a split in a workflow process. This activity is necessary only in cases when workitems are forwarded on more than one path of the split.

Here is how the workflow engine synchronizes multiple branches:

1. When encountering a split the engine forwards the workitem to the next activity in each branch where the link evaluates to true.

2. The work is processed by each branch activity and forwarded according to the flow logic, until each one reaches the Synchronize Merge activity.

3. The workflow engine waits until work is completed on all branches and forwards the workitem to the next activity.

Properties

The properties for the Synchronize Merge activity are:

Usage

    For more information and examples, see Process design concepts.

Start activity

Description

The Start activity represents the Workflow subsystem functions necessary to create a new workitem, and optionally to assign an initial document to the workitem. The start activity is created when a new workflow process is created and cannot be deleted from the process. There is only one Start activity per process.

Properties

The properties for the Start 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 and 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.

    For details on using the Composer Pageflow Wizard, see the chapter on the Composer Pageflow Wizard in the Pageflow and Form Guide.

Properties

The properties of the Composer Service activity are:

Finish activity

Description

The Finish activity represents the Workflow subsystem functions necessary to bring a workflow process to a normal end. There must be one (and only one) Finish activity in a workflow process.

Properties

The properties for the Finish activity are:

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