Part 1 - Introduction to Forms Publisher

---

Overview

• TS FormsPublisher (FP) is a ECM development template tool that automates the process of creating content using data capture forms and presentation templates. It is not a production tool because the capture data and presentation templates don't get deploy to production server; ii) FP component is on development workarea and generates the content page there. FP plays no part in executing any code (e.g. JavaScript) contain in the generated page (if any).
• Can generate any type of content file e.g. web, graphic and media articles
• The generated output file type format can be any format (defaulted to a text files), such as HTML, XML, JSP, WML, ASP and other file format types.
• In ContentCenter Pro, user can use various commands from the menu to create and manage forms and templates: File->New Form Entry; Actions->Generate Page / Regenerate Page
• Advantage: No Web Developer expertise or skills required to create web content. So FP is used by power users. ii) Does not require real time content composition, i.e. content generated on the fly (e.g. DHTML, ASP page)
  

Term

• Forms: Use to enter data into form entries, which store unformatted information. It can have many types of data entry fields. Some fields are madatory. HTML markup is supported with inline editor.
• Form Containers: It is a container that group like fields together into a framed box. A container can also have multiple sections called replicants. Replicants allow more than one item of the same type, e.g 2 paragraph fields for the same story field. Use replicant controls to add,delete and move fields around the form as needed.
• Data Capture Templates (DCTs) - Also known as Data capture forms, it is datacapture.cfg configuration XML file that defines the data capture form for each specifc data type. The goal is to i) defines the data type itself (such as what information the data type will contain and parameters that define what type of TeamSite FormsPublisher data is legal in any input field); and ii) to present form for data entry and capture info, which will be stored in a XML DCR file. A datacapture.cfg file also specifies the look and feel of the data capture form displayed in ContentCenter. Each data type has a datacapture.cfg file, located in templatedata/category_1/data_type_1 folder and use an external DTD lcoated at IWHOME\local\config\datacapture6.0.dtd
• Data Content Records (DCRs) - is a XML file containing content records that has been entered and save by a content contributor through the data capture form use to capture data. The DCR can be setup to name a content contributor automatically. The DCR file is stored in each data type located at templatedata/category_1/data_type_1/data folder There are 2 formats for DCRs, i.e. iwov (TS ver 5 and earlier) and xml (TS 6 and later)
• Presentation Template (PTs) - It is a file that defines how captured data will be formatted and appear when it is displayed as the output result. A presentation template is populated with a data record that was captured earlier (through a data capture template) or from queries to databases. It can be an XML file but can also be created in other format. PTs are stored in templatedata/category_1/data_type_1/presentation folder

Data Store Hierarchy

FormsPunlisher uses the following branch hierarchy in TS below:

Note: All template files are stored in a workarea under a directory named, templatedata

Configurating FormsPublisher
The FormPublisher in TS server needs to be firstly configured for each new workarea and template, prior to implementation as the folder structure is not created after installing TS.

1. Define template data types
2. Create a templatedata (default name but can be changed by setting the name with the data_root value in [teamsite_templating] section of iw.cfg) directory branch in a workarea (if one does not exist). Templatedata directory tree must not be deployed outside TS because it is used only as a workarea during development.
3. Create a unique one to many category name directory 1..n under the templatedata folder.
4. Create a data type directory under each category directory because there can be many data types for each category.
5. Create one data and presentation folder under each data type folder. The data type directory will contain all the DCRs created for that tempate and presentation folder will contain all PTs for that type.
6. Add a new entry in *template.cfg file for each category.
7. Create a new datacapture.cfg file for each data type (templatedata/category_x/datatype_x/ folder)
8. Create a new presentation template file in each presentation folder (templatedata/category_x/datatype_x/presentation/ folder)

* Configuration Files
Template.cfg is global XML file that resides outside TS file system in iw-home/local/config and specifies the following below. For more information about its format, read "Configuring Template.cfg".

• Defines the type of data record being produced (iwov or xml).
  
• Defines the data categories and types that are available for use with FormsPublisher.
  
• Specify the presentation templates that can generate HTML files on which TeamSite
  branches or directories.


• Specify the presentation templates that can be used with a specific data type.


• Define the specific users or roles with permissions who are allowed to create or edit data records for a specific
  data type, thus making it possible to restrict access to certain template.


• Define the location of the presentation template used for previewing generated HTML
  files.


• Whether auto-DCR naming has been set for this data type and category.
  Whether renaming is allowed.


• How the form looks, including buttons that display, whether there is a navigation tree, and what style sheet is used
  

TS has a utility program call iwxml_validate.ipl wich can validate XMl files. Syntax: iwxml_validate.ipl filename.xml. This utility program needs access to the DTD for the file being tested. Easier approach is to copy the required DTD from iw-hoe/local/config to the same direcotry as the file is being tested. Note that this tool can only be used while logged on to TS server.

FP Development Process

• Creating a new data record
• Generating an output file
  

Resources
For further details, read: TeamSite FormsPublisher Developers Guide v6.7.1 SP1 or the PDF version

Part 5 - Implementing The Workflow Modeler

---

Pre-requistie: Read introduction to Workflow Model

Workflow Modeler GUI

• Toolbars: Provide acess to commonly used features. All features are available through the menu system.


• Tree: Provides a method to quickly select any object (model, task, link, etc) by name. The selected object is highlighted in the digram.


• Properties: Display the property settigns for the currently selecteds object, and enables modification of property values if it is a read/write property


• Project pane: A visual representation of the workflow model. Using the toolbar, user can select new types of objects, drop it on the project pane and select the object to set their properties.
  

Note

• All object names must be unique


• Link names are used as transition button labels


• Some object names are used as labels on UI form e.g. user, group and metadata task. ii) links with user, group, review or metadata predecessor

Review Task & Links

• Must have one sccess and one failure link


• May have additional default links, which will appear as additional transition options


• Success and failure link can have any name


• Use available groups and/or available user to define sets of possible reviwers for this task


• Then use Available Reviews to define the actual selection list of reviwers, which is use to generate a selection list on the job instantiation form


• Number of reviewers must be define in design time


• Use the Label and Description field to configure the form appearance of this select list
  
  

Group Task

• Have Shared By property instead of an owner property. So enter a set of users and groups to send this task to.


• One of them will take ownership and perform the task

Metadata Task

• Use to display the metadata input form but appearance will depend on its configuration setting.


• User then enters a metadata for the files in the workflow.


• Set immedate property to true to allow it to open the metadata form as soon as task becomes active
  

Lock Task

• Attempts to lock all job files associated with a workflow However it can't lock files that are already locked outside the workflow


• Has two transition, i.e. Success (taken when all locks are acquired) and failure (taken when any of the locks can't be acquired) which is required


• Can transfer between task owners for files locked within its own tasks


• Use external task calling unlock.ipl to unlock files

External Task

• Non interactive task that runs as an external application or script on TS server.


• Runs as SYSTEM user on windows OS or runs with userid of the task owner on UNIX server.


• Use the external task to execute unlock.ipl script to unlock files. Unlock.ipl does not acquire any arguments.


• Properties: i) Command - Full path of the executable or script to run ii)Retry - Successive attempts to re-run program again upon failure to start after a specific time whose value can be specified in iw.cfg


• When workflow calls external task program, it passes data as command line arguments, including job and task ID, area vpath and list of job files.

Dummy Task

• A time delay task that transitions to other tasks after some amount of delay time or a specific time


• Use it in a time delay if a lock task fails, before it tries to lock the file again.


• Must have one timeout transition where the timeout transition's time delay can be absolute or relative.


• Any task can use one or more timeout links in addition to any other links.

Update Task

• Used to copy files to another area but only files associated with the job are updated.


• Equivalent to Get Latest if source is a staging area or a Copy To if source is another workarea or an edition


• Area vpath is the destination area


• Properties: i) Delete - propagate deletion of fiels to destiniation area; ii) Overwrite - Overwrite conflicting versions in destination area; iii) Source Area VPath - area from which files are copied

E-mail Task

• Use to send notification to users via email
• Generates a message notifying a user that a task has been assigned to them with information about that job

Special properties:

• Email command: $IW_HOME/iw-perl/bin/iwperl/
• Email body: author_iwmailbody.tpl
• Email body text: author_textbody.tpl
• Email header: author_iwmailheader.tpl

To configure and use email task you must:

• Identify compay'es SMPT server and domain name
• Configure iw.cfg file under [iwsend-mail] section
• Set up an email_map.cfg file in iwhome/local/config/wft/solutions folder

Variables

• Variables allow the job creator to enter workflow or task property values when the job is created


• It can be used as property values for any object types


• There are 7 variable types:

1. Configurable variable: Value entered by the job creator via the form when the job is started. Configurable variables can be local to an object or global to the entire worflow model.

• Use local variables when you want to enable the job creator to select a specific task owner, area vpath or other single property of one task.


• If a value will be used in more than one task, use global property


• To define local configurable variable: Select a task object proeprty->description. Then select "configurable" from variable type drop down list. Enter a label value (will be displayed on the instantiation form). Entering and ID is optional as system will automatically generate a unique ID Recommend leave this default value for local variable. Description field is use for displaying a tooltip help icon. Click OK button


• To define global configurable variable: Select workflow object property->global variable. Then select "configurable" from variable type drop down list. Enter a unique ID value. Enter a label value. Click Add button. When finish click OK button.

2. System variable: Dynamic value which is automatic created and set by the workflow system, when a workflow starts. Can use it as default or property values. All system variable name are uppercase and begin with "$IW_"

3. Script variable: Variable use to generate a more complex value using JavaScript. Enclose system variable in quotes (e.g. "$IW_USER"). Don't use return to return a value; the script variables value will be the result of the final evaluation i nthe script.

4. Datasource variable: Vaue calculated by an external Java class.

5. Extended attribute variable: Used to set extended attribute data on files.

6. Macro variable: Values used to set extended attribute during workflow.

7. Task variable: Used to pass data along from one task to another task as a job executes.

Resources
For further details, read Workflow Modeler User Guide

Part 4 - Introduction to Workflow Modeler

---

What is a Workflow Modeler?
A Interwoven workfllow modeling tool that allows user to:

• Create workflow model and validate it
• Create tasks
• Draw transitions between tasks
• Deploy workflow model to TS server

System Requirements

• Windows 2000/XP/2003

Using the Workflow Modeler

The steps required to begin using the Workflow Modeler are as follows:

1. Implement a methodology to design a workflow model (analyse requirement, risk, etc..)
2. Identify the workflow elements discovered during step 1. The elements are: i)workareas ii)files iii)jobs iv) tasks v) transitions vi) variables
3. Design a workflow diagram based on step 2.
4. Implement the design from step 3 using Workflow Modeler
5. Test and debug the workflow
6. Deploy to TS server

Workflow Model Features

• Configurable variables
• Data sources to pull data
• Support of system variables
• Scripting variables
• Conditional execution of tasks [Conditional Link]
• Global and local scope of variables

Server side enhancements including:

• Customizable Instantiation Screen using DCT framework
• Customize workflows for different branches
• Web view of the workflow from Content Center
• Current status of the workflow
• Debug support

Part 2.1.1 - Configurable Workflow Settings

---

All three configurable workflows share the following functionality:

Email Notification


Metadata Capture


Deployment

The configurable_author_assignment and configurable_author_submit workflows also add the functionality to have submitted files reviewed by a configurable reviewer. The reviewer section of these workflow configuration (.cfg) files is where the email notification system obtains instructions to determine the email address of the reviewer.

Note: The configurable_author_assignment workflow also adds the functionality to attach files to a workflow task.

The general procedure for configuring these options is the same for each of the configurable workflows:

Open the workflow_name.cfg file that corresponds with the configurable workflow you want to implement.




By default, these files are located in iw‑home/local/config/wft/solutions.




Edit the entries that correspond with the functionality you want to enable.


Save and close the file.


Ensure the workflow is activated as described in Enabling Workflows.

The following sections describe each of these options in detail.

Part 2.2 - Configuring availiable_templates.cfg

---

The available_templates.cfg file is an XML configuration file that lists all of the workflow templates that are available for use on the TeamSite server. For each workflow, this file indicates the name of workflow, the location of the workflow template file, and the conditions under which the workflow is available.

By default, the available_templates.cfg file is located in:

C:\Program Files\Interwoven\TeamSite\local\config\wft (Windows)
/Interwoven/TeamSite/local/config/wft (UNIX)




Note: If available_templates.cfg is edited and contains non-ASCII text, it must be saved in UTF-8 encoding.

The available_templates element is the container element for the file. This element contains the following attribute:

require_workarea — specify whether (true) or not (false) workflow templates selection screen will include a branch/workarea chooser if workarea context is not present. Most of the out of the box workflow template examples require this to be enabled (require_workarea="true") to work properly. Default value is false.

Within the available_templates element is the template_file element:

<available_templates require_workarea="true">

  <template_file name="Author Submit Workflow"

    path="solutions/configurable_author_submit.wft">

    ...

  </template_file>

</available_templates>

The template_file element has the following attributes:

name — specify the title of the workflow, for example:
name="Author Submit Workflow"

active — indicate whether (yes) or not (no) the workflow template is enabled. Default value is yes.
path — specify the path where the template file resides. Template files must reside in one of the following locations:


iw‑home/local/config/wft/default
iw‑home/local/config/wft/examples
iw‑home/local/config/wft/solutions




The value you specify is relative to the iw‑home/local/config/wft directory, so if the template file resided in the following absolute path:






iw‑home/local/config/wft/default/author_submit.wft






then you would specify the value:
path="default/author_submit.wft"

Specifying Template Access

You can configure access to each template listed in the available_templates.cfg file by using any combination of the following categories:

Command
Role
Group
User
Branch

The categories can be combined using boolean terms such as AND, OR, and NOT to include and exclude those that meet the inclusion or exclusion criteria you configure. Template access is configured within the allowed element, which is a subelement of template_file:

Within the template_file element is the allowed element, where you can configure user access by matching workflow commands with user roles:

<template_file ...>

  <allowed>

    ...

  </allowed>

</template_file>

Command Access

Workflow commands are specified by the command element. The command element specifies the user-activity that starts the corresponding workflow. For example, the following configuration:

<command name="submit"/>

specifies that the associated workflow is started when performing a Submit and that it cannot be invoked by other means.

The valid command values that you can associate with a workflow are:

submit (submitting files)
assign (assign button or menu item)
new_job (new job)
new_TFO_job (new job, in TeamSite FrontOffice)
tt_data (saving FormsPublisher data records)
tt_deletedcr (deleting FormsPublisher data records in ContentCenter Standard only)
all (all possible values from this list)




Note: The tt_data command is valid in ContentCenter Standard and can be configured in ContentCenter Professional; see the User Interface Customization Guide. The tt_deletedcr command is only valid when users are using the ContentCenter Standard interface; in ContentCenter Professional, this command is not valid and data records are treated like any other assets.

Role Access

Access based on TeamSite roles is specified by the role element’s name attribute. For example, the following configuration:

<role name="author"/>

specifies that if the user is logged in as an Author.

Group Access

Access based on user groups is specified by the group element:

<group name="marketing"/>

User Access

Access based on individual user name is specified by the user element:

<user name="jdoe"/>

Branch Access
Access based on TeamSite branch is specified by the branch element: 

<branch="/default/products"/>

Combining Access Categories

Pairings of individual or multiple access elements can be included or excluded using the and, or, and not elements within the allowed element. You can use boolean logic to create combinations of categories that can either have access to a specific template, or be excluded from it.
In the following example: 

<template_file name="Author Submit" path="default/author_submit.wft">

  <allowed>

    <and>

      <command name="submit"/>

      <or>

        <role name="author"/>

        <role name="editor"/>

        <group name="marketing"/>

        <and>

          <role name="admin"/>

          <not>

            <user name="jdoe"/>

          </not>

        </and>

      </or>

    </and>

  </allowed>

</template_file>

the following individuals have access to the Author Submit workflow:

Those who are authorized to perform submit commands.
Those who have the author or editor role.
Those who are members of the marketing group.
Those who have the admin role, with the exception of the user jdoe.

If no access category is specified, it is assumed that category has full access to the workflow template.

Regular Expression Support

You can use regular expressions when specifying branch element constraints within available_templates.cfg to search for a specified pattern and specify what to do when matching patterns are found. Using regular expressions allows a greater level of flexibility when adding items.

For example, if you want only the users in the three administration_1 branches (a1, a2, and a3) to access a workflow template, you can set the following constraint:

<allowed>

  <or>

    <branch name="/default/main/administrator_1/a1"/>

    <branch name="/default/main/administrator_1/a2"/>

    <branch name="/default/main/administrator_1/a3"/>

  </or>

  ...

</allowed>

If a new branch called a4 is added to /default/main/administrator_1 you could manually update the available_templates.cfg file to allow access for users in the new branch by adding the branch element to the existing ones:

<branch name="/default/main/administrator_1/a4"/>

Or you could modify the available templates.cfg file to use the following regular expression and, thus, automate the constraints placed on the a4 branch:

<allowed>

  <and>

    <branch name="/deault/main/administrator_1/.*"/>

  </and>

  ...

</allowed>

This regular expression allows users from any branch under /deault/main/administrator_1 to have access to the template.

Path Separators

When using regular expressions, the path-separators (“\”, “\\”, “/”) are all translated to “/” in both the pattern and the string to match against before attempting the match.
In the following example:

<branch name="foo"/>

any branch path that includes the string foo will be matched. Here the following examples match:

/default/main/food/...

/default/main/barfoo/...

In the next example:

<branch name="^/default/main/foo"/>

any branch path that begins with the value-string will be matched. Here the following example matches:

/default/main/food/...

while this one does not:

/default/main/barfoo/...

The following examples are all treated as identical on both Windows and UNIX.

<branch name="^/default/main/foo" include="yes"/>

<branch name="^\default\main\foo" include="yes"/>

<branch name="^\\default\\main\\foo" include="yes"/>

<branch name="^/default\main\\foo" include="yes"/>

Part 2.1 - Enabling & Configuring Workflow

---

The optional (non-default) workflows can be activated by completing the following procedure:

Verify that you have satisfied the following two requirements:


Install and license TeamSite (which now includes FormsPublisher)—Workflow email notifications use the presentation template compiler installed with FormsPublisher.
The permissions on the iw-home/tmp and the iw-home/tmp/cci directories must be readable and writable to all TeamSite users (the email notifications are temporarily placed in these directories while being created).


And consider the following compatibility issues:


Install MetaTagger 3.6 or later (optional)—MetaTagger 3.5 and earlier are not supported. If you are integrating with MetaTagger, TeamSite must be installed before MetaTagger or the MetaTagger GUI will not work.
Install OpenDeploy 5.5.1 or later (optional)—You must have a base server on the TeamSite server.




Open the iw‑home/local/config/wft/available_templates.cfg file (see available_templates.cfg).


Add an entry for each new workflow.
For example, to add the Author Submit Workflow workflow, add the following entry:




<template_file name='Author Submit Workflow'
path='solutions/configurable_author_submit.wft'>
<allowed>
<and>
<command name="submit"/>
<role name="author"/>
</and>
</allowed>
</template_file>






For your convenience, a file containing entries for each new workflow is provided. It is called available_templates.cfg.fragment and is located in the iw‑home/local/config/wft/solutions directory. You can copy any or all of the workflow entries from this file into your available_templates.cfg file.




If you are replacing another workflow, you can deactivate it by any of these methods:


Delete the entry
Comment out the entry using <!-- -->
Add the attribute active=“no”




Save and close the available_templates.cfg file.


For each configurable workflow that you added to your available_templates.cfg file, edit the corresponding .cfg file to activate the desired functionality.
The .cfg file contains question and answer pairings for each configurable option. For example, in the Email Notification section:

# Should a email notification be sent if a deploy task fails? email_no_deploy=no

Change the default from no to yes on any feature you want to activate. For a detailed description of the configurable features available in each workflow, refer to Configurable Workflow Settings.



If you are using the Email Notification functionality:


Ensure that your iw.cfg file contains entries for maildomain and mailserver in the [iwsend_mail] section.
If it does not, add the appropriate entries. For example:
[iwsend_mail]
maildomain=yourcompany.com
mailserver=mail.yourcompany.com

Edit the solutions/email_map.cfg file to specify the mapping from user names to email addresses if adding @yourcompany.com to the username is not adequate.


If you are using Metadata Capture functionality:


Ensure that the metadata_capture_ui properties in the workflow-specific .cfg files have the desired setting for either MetaTagger or TeamSite Metadata
Ensure that iw‑home/local/config/ contains datacapture.cfg and metadata‑rules.cfg files, and that these files contain the desired settings.
Ensure the mt‑home/conf/metatagger.cfg file contains the desired entries. See MetaTagger Administration Guide “Configuring MetaTagger to Work with TeamSite” for integration instructions.
Ensure that the category tag values in the metatagger.cfg file match corresponding item name values in the datacapture.cfg file.
Optionally, test your metadata capture configuration from a custom menu item before you try it from a workflow.


If you are using Deployment functionality:


Copy the deployment configuration file (solutions/wft_opendeploy.xml) to the od‑home/conf directory.
Edit solutions/wft_opendeploy.cfg file to specify the mapping from branch names to the corresponding destination nodes and paths.
See Integrating with OpenDeploy for detailed information about these entries.

10. Ensure that yo have add appropriate TS groups and users in LDAP or AD. Then in TS, add all the groups and users. Then add the appropriate user to a group. Then assign roles to each added users.

Default Workflow Templates

---

Default Template Descriptions

---

The following workflow templates are installed in iw‑home/local/config/wft/default:

Template Name	Description
author_assignment.wft	Lets an Editor, Administrator, or Master assign a job to an Author. The assigner selects an author and enters a task description. The assigner also selects a branch and workarea if the job is initiated from the To Do List view. An approval sequence is also included for the author assignment.
author_submit.wft	Submits content to the STAGING area. This is the default workflow invoked when a user logged in as an author clicks Submit. Includes review/approval task by the owner of the workarea.
author_submit_dcr.wft	Submits a data record to the staging area when an Author clicks Save and Exit in the FormsPublisher window. This automates the submission process, eliminating the need for the Author to initiate the submission manually after creating or editing a data record.
default_assign.wft	Designed for use with the assign action. It enables a user to assign one or more assets to another user, and then review changes prior to submitting changes to STAGING.
default_submit.wft	In addition to submitting the files, provides support for pre-submit activities including approval, file type recognition, and user-specific destinations.
default_TFO_submit.wft	Submits content to the staging area. This workflow can be configured for use by Front-Office users when they submit files from the TeamSite Briefcase or from a Microsoft Office application, such as Word.

Example Workflow Templates

---

The templates in iw‑home/local/config/wft/examples are included as reference examples that are applicable to some installations. The functionality provided by these examples is included in a more generalized form in the work_order.wft template. The templates in the examples directory are provided as shorter, more modular examples of how you can develop custom workflow templates.

To make the example files available to end-users, you must edit available_templates.cfg as described in available_templates.cfg.

The following example templates reside in iw‑home/local/config/wft/examples:

Template Name	Description
cgi_task_test.wft	Example workflow template that demonstrates the functionality of a cgitask. Uses iw-home/httpd/iw-bin/sample_cgi_task.ipl.
concurrent_approval.wft	Same as serial_approval.wft, except the reviewers review content in parallel.
external_task_test.wft	Example workflow template that demonstrates the functionality of a cgitask. Uses iw-home/local/config/wft/examples/sample_external_task.ipl
serial_approval.wft	Lets Editors, Administrators, and Masters assign a task to a content contributor and specify one or more users as the approvers.

You should examine each .wft file for details about its construction and the features of the job it defines. After examining each file, you can choose to use it as is, or modify it for your specific installation using the information from Workflow Template File Structure.

Part 2 - Setting up a Workflow

---

Objective: Develope the knowledge and skills of configuring workflow after installing TeamSite.


Overview

There are two types of source files that are used with TS workflow, i.e. file with the extension *.wft and *.ipm. Either one of these two source files are used in v.6.7.1 (but v6.5 only uses the *.wft) to run the workflow:

• wft extension - Also referred to as a WFT (pronounced “wooft”) or Workflow Template file, this file contains a combination of Perl and XML.The Workflow Template file defines the framework, and the fields of information
  needed to generate a static Workflow object description. Some WFT by default are already enabled in TS server. The WFT was used in the early version of TS v6.5.0. However it still can be used in the later version of TS 6.7.1 which is backward compatible.


• ipm extension - A workflow model file that contains XML. A Workflow Modeler tool is a commonly used for creating/editing a ipm files. This workflow model file can only be used in the later release of TS v6.7.1

Workflow Templates
TS has 6 default "wooft" files that are shipped "out of the box" (See Default Workflow Templates for more details) and there are also 4 example workflows (See Example Workflow Template for more details), Only 2 default workflow templates (default_TFO_submit.wft & author_submit_dcr.wft) are enabled by default in TS server while the rest are NOT yet all enabled.

There are 4 solution workflow templates already installed and enabled on TS server by default and its located at iw-home/local/config/wft/solutions/ folder.

So to enable an existing workflow template not yet enabled or whenever a new worflow template file is created, follow these instructions, which initiailly requires configuring the available_template.cfg XML file.

In summary, the workflows that are active by default (that is, they have an entry in the available_templates.cfg file) are marked with an asterisk (*):
iw‑home/local/config/wft/default/

• author_assignment.wft
• author_submit.wft
• author_submit_dcr.wft*
• default_assign.wft
• default_submit.wft
• default_TFO_submit.wft*

iw‑home/local/config/wft/examples/

• author_assignment_with_nested_job.wft
• cgi_task_test.wft
• concurrent_approval.wft
• external_task_test.wft
• url_external_task_test.wft
• serial_approval.wft

iw‑home/local/config/wft/solutions/

• author_submit_with_deploy.wft
• author_submit_with_email.wft
• author_submit_with_metadata.wft
• configurable_author_assignment.wft*
• configurable_author_submit.wft*
• configurable_default_submit.wft*
  

Workflow models
TS has 6 example workflow models located at iwhome\install\AdminStore\workflowModeler folder (assuming iwhome is the TS installation folder path, usually at c:\interwoven\teamsite) but are NOT enabled by default.

To enable it or whenever a new customised workflow model is created/added, available_models.xml file (see section below) must be always be initially configured. Once finish editing the avaiable_model.xml in TS sererver, it needs to be published into staging.

* Note: Ensure that all files located in /iwadmin/main/workflowModels/WORKAREA/iw-wa/Internal folder has been published to staging when using a workflow model for the first time after TS installation.

Workflow user
There are two TS user types when using the workflow:

• Workflow User - Start and interact with workflow jobs. By default all users in TS are in this role


• WorkflowAdmin - Create or revise existing models. Modify model configuration, user access and behaviour. By default only Sysadmin user is in this role.
  
  

Managing Workflow Models

Workflow models are stored in TS server in the iwadmin/workflowmodels/workarea branch, which contains:

• Config folder - Configuration XML files for each workflow model that control how jobs are instanitiated.


• Instance folder - Copies of all instantiated worfklow job specifications.


• Internal folder - Contains XML files, especially the available_models.xml file which controls model activiation and access


• Models folder - All workflow model files (.ipm extensions).

Model behaviour and activation can be controoled from each brach or globally from administration tab when logging into TS as an administrator.

Managing availiable_models.xml

To manage this xml file , logged into TS as either a Master or a WorflowAdmin user. The available_models.xml file is use to determine which workflow will execute based on:

• Command (events that can trigger workflows)


• Role (of the current user)


• Group (groups the current user belongs to)


• Branch (currently active branch)


• User name (user name of current user)


• *Event types (workflow event types settings that determine what event(s) will trigger the execution of a workflow)
  

*The standard workflow event types are as folows below. Note that if more than one workflow model is assigned to a givent event they will be presented with a selector to choose which workflow to execute.

• all: Any worfklow events causes this workflow to run.


• assign: User selected Actions->Assign


• new_job: User selected Actions->New Job


• submit: User selcted the Submit button in ContentCenter


• tt_data: User saved a TS templating DCR in CententCenter Standard


• t_deletedcr: User delted a DCR in ContentCenter Standard


• new_TFO_job:b New job selected in TS Front Office

Availiable Elements

• availiable_model element- Top level element contains 1 or more model elements


• require_workarea element- True (default is false): Means workflow should be used from a workarea context and can't start a job without selecting a workarea.


• model element - Each model element relates to one workflow model files. model contains allowed sub-element that determines how the model can be activated.

Model Elements

• path attribute - "prod" or "debug"


• name attribute - Name of the model, without ipm extensions


• active attribute - To enable/disable the model (default is "yes")


• One allowed sub-element per model element - Controls access to the workflow model

Allowed sub-element

• command attribute - action of user ("assign", "new job", "submit", "tt_data", "tt_deletedcr", "new_TFO_job")


• role attribute - role of user ("reviwer", "editor", "author")


• group attribute - membership of user


• branch attribute - current context


• user attribute - name of account user


• and: apply list of rules


• or: 1 rule of list must match


• not: exclusion rule
  

Using branch

Branch name attribute is a vpath regular expression used for any branch or workarea, except not staging, editions or content sub directories

Always use forward slashes

".*" - Any branch

"^/branch name/" - All branches in branch name.



Workflow Log Files

• iwjoberrrs.log - Shows compelete instantiated workflow and error messages.


• iwtrace.log - Shows job and task started and stop information and error messages. Located from Logs section in administration tab or c:\interwoven\teamsite\local\logs\
  

Part 1 - Introduction to Workflow

---

Objective

• Define workflow terms
• Define task types
• Understand types of workflow
  
  

Workflow terms

• A workflow consist of a set of steps/procedures that are interconnected in predeccessor-successor relationship. It is represented by a flowchart. In Teamsite workflows implements business workflow and also a *package of files and instructions.
• A bussiness workflow is a real world process used by an organistaion to produce a result.
• **Job: A new workflow instance started by an execuation of a workflow model. This job is identified by a numeric job ID. A job is a collection of tasks and links but all the variables have been filled in. Job has one or more files attached to it. Many jobs can be started from one workflow model.
• Job specifications are XML files that describe a specific job instance. You can create these files either by invoking the instantiation of a workflow template or a workflow modeler only through a TeamSite v6.7.1 GUI.
  However previous version of TS v6.5 uses the workflow template to create the job specification
• Instantiation: Means that the workflow model is being filled in with values to gnerate a true job specification. If any variables are user supplied, then instantiator display a form to gather information from user.
• Workflow modeler (new feature in v6.7.1) is a TS authoring tool for defining a workflow model that will implement a recurring and approving business process for content management. Think of a workflow model like an automated flowchart use to i)manage content developement life cycle ii)automate development tasks iii)customise procedures. It saves the workflow model as a XML file with *.ipm extension.
• Workflow template: (old feature in v6.5 but still supported in v6.7.1) Workflow templates are XML files with a .wft extension (known as wofty files) that describes the job specifications for a particular workflow. These files are created dynamically with embedded Perl script to dynamically generate the output job specification. Then it is transfer to the TeamSite server where they can be instantiated by users, as needed, to become specific jobs. The configuration file available_templates.cfg lists all the workflow templates available to users to be instantiated.
• The server-side workflow subsystem resides on the TeamSite server and contains all the executable files that provide workflow functionality.
• Task: A single step in a workflow process which can be perform by a perseon or program & the task status is either inactive or active and identified by a task ID. More than one task can be active at a time. Active means user has not yet completed the task's work.
• Activation: User or program for that task has not yet completed the task's work
• Transition: Occurs when one task is finished, which cases the current task to become inactive and activate the current task's successor (according to the workflow model) which may be one or more other task.
• Transition options: There are two or more possible ways to transition, usually depending on the outcome of the task.
• Links is a connection between two or more tasks and present the oder in which tasks are performed. Links can activate more than one tasks at a time. Links can also re-activate task that have already completed (i.e. activate an inactive task), creating loops.When a task is completed, the next task starts automatically. Links create predecessor/successor relationship between tasks. When a predecessor task is completed, it activates its successors. Links can have multiple predecessor/successor.
• Start and end event - Workflow model has one or more start and end event. All successors of start evetns become active as soon as workflow job is started. WHen any end event activates, the workflow is terminated. Start event has no predecessor. End event has no successor.
• Serial task activation - A workflow model in which no more than 1 task is active at one time.
• Parallel task activation - A workflow model in which more than 1 task active at a time.
• Parell Transitions - If a user task has 2 or more successor, the user selects one of them to be the next task
  
  

*The package is routed from one user to the next:

• Each user reads instructions to see what they need to do to the files
• Afer doing their work, the user addes comments to hte package what they did and pass the package to the next person in sequence.

**When a workflow job is started, the following occurs

1. Workflow job is instantiated
2. Workflow job becomes active
3. Task in workflow becomes active if they are successors of a start event.
   

Workflow users

• Business users define the workflow requirements
• Developers implement workflows
• Content Managers/Contributor initiate and maintain the jobs and automate and perform the tasks.
  

Task Types
Most workflows are automated by the program. Those tasks that can't be performed automatically must be assigned to a user to manually perform a interactive task (e.g. review/approve or reject, content creation, etc). So there are two types of task:

1. Automated task: Perform operations on the worflows flikes like copy, lock, submit, etc..

2. User-interactive tasks comes in 3 types:

• User task - Standardise TeamSite (TS) workflow task types designed to give user the tools needed to work on the workflow inside their "to-do" windows. Example include: create/edit files, fill in forms/metadata, review and approve/reject, compare and merge.
• Group task - Assign to a list of people and will show up in all their "to-do" windows, until one of the user takes ownership (i.e. starts the work), which assigns the task to that person. After that the group task becomes a standard user task. Example include lock/unlock, email notification, copy/move files, submit, deploy, execute program.
• Custom user task - Known as CGI task because the task is created by system adminstartors from common gateway interface task, which can provide customise task.
  
  
  

Workflow types
TS has two "out of the box" common workflows, but any number of other workflows can be created during TS installation. Workflow is dependent on busines needs and operations.

1. Assign workflow: Where a person asign work to another team member. Some examples include:

• A team member (Assigner) assign a set of files and instructions to another person
• Assignee completes the work
• The Assigner who assigned the work then reviews it, and either approves/rejects the work
• After approval, the files are automatically submitted.
• Email is sent to the Assigner and Assignee.

2. Submit worfklow - Runs a job to submit a workflow using the default_submit workflow template.

Workflow Events

Workflow events are the initiation of starting a job when a user selects the following event:

• Action->new job
• Submit
• Assign
• Create/delete a DCR

Resources
For further details, read: Workflow Developers Guid v6.7.1 SP1

What is TeamSite?

---

TeamSite is a content management software (CMS) for enterprise business that was developed by a vendor called Interwoven, that started off from in the USA head office in 1993 and now a company global organisation in many countries providing content management solutions to business clients.

At the heart of any CMS is the ability to control, manage, store, find, share, change, track, test, move and back up a large number of the organisation's asset (a file that contains important data), such as web pages, document files, database, program source codes, scripts.

That's what Teamsite CMS does with ability to cover the content development life cycle. The basic development cycle includes:

• Assign: a new task involving content creation and assigning that task to a person.


• Edit: Content is edited and tested by a content contributor.
  
• Review: Content is reviewed by a reviewer with possible rejection and recycle the process.
  
• Deploy: Content that is approved by the reviewer is then transferred to production site.
  
  

The diagram above can equivalently look more like the diagram below.

Note:

TS integrates with OpenDeploy and MetaTagger. OpenDeploy is a software that allows contents, documents, files to in TS be deploy and published to the production server. MetaTagger is a software that automates the process of tagging enterprise business content with descriptive metadata to help transform a loosely content to a organise library catalog.

TeamSite can be used for a wide range of applications:

• Public web sites
  
• Intranet and internal portals
  
• Extranet portals


• Colloborative document and digital asset management


• Workflow management