The EcoVida.workflow module, obtainable from the ATG Developer Network, includes all the configuration files necessary to define a new workflow type. The following is the list of these files:


You can use the registration workflow configuration files as a template for creating your own workflow types. Most of the properties configured by these files are the same for all workflow types. The properties you may need to modify are discussed below.


The file adds the workflow process manager for the registration workflow type to the fileCombiners property:


The file adds the SQL JMS topics and queues used by the registration workflow type to the requiredTopicNames and requiredQueueNames properties:


The XML files in /atg/dynamo/messaging/ are the Patch Bay configuration files necessary for hooking up the WorkflowProcessManager and WorkflowMessageSource components as message sources and sinks. The standard Patch Bay configuration file, dynamoMessagingSystem.xml, is used on all process servers. The other Patch Bay configuration file is used on global process servers only, and is XML-combined with the standard configuration file on startup. For the registration workflow type, this file is named dmsRegistrationWorkflowGlobal.xml.


The admin-accounts.xml file specifies security privilege information for the ACC task that is used for editing workflows.

/atg/registry/ creates a component of class atg.service.registry.SimpleRegistry that sets the root path for storing registry files for the workflow type:


The WorkflowAgents component is the registry (used by the ACC) of all workflow agents. You add the agent components of your custom workflow types to the workflowAgentPaths property of this component. (By default, this list is empty.) The file includes this line:


The Registration.wdl file stores information used by the ACC. It is created automatically by the ACC.


The /atg/workflow/registration/ components include the WorkflowManager itself and the associated helper components.

The WorkflowConfiguration component has a number of properties that other components make reference to. The file includes:


WorkflowMessageSource is a message source that fires all workflow-related JMS messages for registration workflows.

The WorkflowSubjectAccess component provides access to the workflow’s task information data. The component is configured to point to the workflow subject type and the repository it is stored in:


The WorkflowView component implements the atg.workflow.WorkflowView interface described in the Workflow Classes section; it provides session-scoped access to workflow features. This component is optional, as it is also possible to create workflow views programmatically using the WorkflowManager API, but it provides a convenient way to access workflow information from the point of view of the current user.

The WorkflowTaskQuery and WorkflowSubjectLookup servlet beans, and the request-scoped WorkflowTaskFormHandler, are optional as well; they can be used to construct custom workflow UIs. The registration approval gear uses the WorkflowTaskQueryDroplet to display active tasks accessible to the current user. It then uses the WorkflowTaskFormHandler to operate on these tasks: claim and release tasks, and fire outcomes. All of this is done in JSPs, with no need for the direct use of the workflow API, or custom code. See the Workflow Servlet Beans and Workflow Task Form Handler sections for more information about these components.


The /atg/workflow/registration/process/ components include the WorkflowProcessManager and the associated helper components.

The WorkflowAgent component is configured to point to the registry component for the workflow type:


The process manager XML configuration file, workflowProcessManager.xml, defines all of the standard workflow events and actions, plus the custom actions specific to registration workflows. It also contains configuration information for customizing the registration workflow editor in the ACC.


The /atg/workflow/registration/process/configuration/ components configure the emailNotifyTaskActors and deleteRegistration standard workflow actions, plus the custom actions createAccounts, createOrganization, createCommunityFromTemplate, addUserToCommunity, and setHomeCommunity. Note that you can find the source code for these custom actions, along with other Java source files, in the src/ subdirectory of the Ecovida.workflow module.


The registration repository item types are part of the user profile repository, and are therefore defined in the file /atg/userprofiling/userProfile.xml. (Other workflow types may use other repositories.) This file is XML-combined with the other user profile configuration files, and defines all the necessary workflow-related item types. In addition, it defines two new properties for the company-registration-request item type: workflowInstances (pointing to a set of individual workflow instances), and workflowTaskInfos (pointing to a set of WorkflowTaskInfo items). A third property, id, is also required for workflows, but is not defined in this file because the company-registration-request item type already has an id property. All these properties must be defined for a subject type in order for the workflow and process engines to function correctly.

In addition to the process-related item descriptors, the workflow repository schema also defines several additional item types that are required for all workflow types. One of these is the workflowTaskInfo item descriptor, whose purpose is to store workflow task-related information on a per-subject basis. The intent is for generalized workflow subjects to have a workflowTaskInfos property pointing to a set of workflowTaskInfo items. The other item types are as follows:


For information about the properties of these item types, see the /atg/userprofiling/userProfile.xml file in the Ecovida.workflow module.

The names for these item types are specified by the WorkflowProcessManager component. If you want to use different names in your repository, you must change the corresponding properties of that component.

As mentioned above, each workflow type must have its own set of database tables. The script for creating the tables for the registration workflow is <ATG2007.3dir>/EcoVida/sql/db_components/<database-vendor>/registration_workflow_ddl.sql.


The file creates a component of class atg.ecovida.commerce.b2b.profile.CompanyRegistrationFormHandler. This class contains the code that initiates the workflow and performs dynamic routing of the channel review task by region. This code is executed after the registration request item has been created, in the form handler’s postCreateItem method. It demonstrates how the workflow API can be used both to start the workflow and to affect its tasks.

loading table of contents...