Developing Processes

Introduction

The purpose of this document is to give an overview as well as detailed knowledge on important parts of Comflow Process Framework. Working with the process framework requires general knowledge of the Comflow Platform.

Why processes?

While workspace workflows are single, interactive, user functions, processes are functions typically spanning multiple users in an asynchronous manner. Processes are designed in Comflow Studio.

Interaction with, and monitoring of, the running processes are done via the browser runtime GUI.

The flow of a process (instance) is decided by events in user functions, timer events and other types of events. Processes are, when put in a running state, ready to be triggered by a user, timer or application event. Such a trigger event will create a new instance of the process.

It is important to understand the distinction of a process definition, a process modeled (or designed), in the Developer Studio, and the numerous process instances that are created from that definition. A process instance exchanges information between users (assigned to roles) and, possibly, external systems in a synchronous or asynchronous way.

The information routing can be fully content based. When an end user (assigned to a specific role) interacts with a running process he or she, typically, does so using My Work List in the runtime GUI.

A brief description of what a process can look like

The figure below provides an example of a simple item registration process modeled in Comflow.

The process is started by a user acting in the role as ItemResponsible. An event will start a process instance.

Two tasks, “Add Purchase Info” and “Add Quality Info”, will be sent to two different roles.

The tasks will show up in a work list of the users assigned to the PurchaseResp- and QualityResp roles. If no role/user assignment have been done the tasks will end up in the common Claim tab in work list.

When the work items have been sent, the process will enter a “wait for event” state, waiting for the "add purchase info"-completed and "add quality info"-completed events to occur. When those events has occurred the process instance will send an “Approve” work item to the ItemResponsible role, wait for the "Approved"-event to occur and then end.

Note that this is a very simplified process example. Typically, a process like this handles a lot of other things like non-event handling, content based routing, external application information exchange etc.

A process model, and its running counterpart, that fully explores the possibilities of Business Process Management provide a number of benefits for any organization:

• Bridges the Business/IT gap: The people that really know the business processes are the ones that define the process model and the blueprint is handed over to the IT department. This effectively bridges the gap between business and IT.
• Keeps track of work: The electronic process instance owns and drives the process, handling non events and making sure that nothing "falls between chairs".
• Minimizes manual work: Automates as far as possible
• Flexibility: In today’s world it is very important for a company to be able to react and change rapidly to new market demands. Electronic business processes that are modeled and running in Comflow are easier to change to fit the new needs, compared to changing "hard-coded" and hidden processes inside different applications.
• Review existing processes: The modeling of the business processes will result in scrutinizing the existing processes and getting a visualized image and easy understanding of the new ones.
• Visualize: Business logic is to a great extent visualized in the model and no longer hidden in a “black box” layer.

Creating a simple process

This chapter shows how to create a very simple process in the process framework. Even though the process is simple, it contains most of the features that are needed in larger real-world processes, so by following this chapter you will get a quick introduction to the basics of the Comflow Process Framework.

Create Process

The figure below shows how to create a new process model and inserting some process activities in Comflow.

Start Event

This chapter shows how to add a start event for the process. When an event happens in the system that matches the definition of the start event of a process, an instance of that process is created. A typical event is that a user pushes a specific button in a specific function.

The figure below the continuation of the start event configuration.

When the configuration wizard is finished, the result looks as below. All the values can, as an alternative to the wizard, also be changed directly in the property inspector.

Work Item Configuration

After having configured the start event, the first work item also have to be configured for the framework to know who to send to, title, and other information.

Work Reference

A work item can (but does not need to) have a work reference to the function where the task is supposed to be solved. The work reference is added to a work item and contains reference information to workspace workflow, portlet etc, so that the user is presented the correct view for his or her work.

As with the event configuration wizard, the work item configuration wizard add information that also can be changed and presented in the property inspector, as shown below.

Wait for Event

The last process artifact that has to be configured before running the process is the waiting point where the process should pause after having sent the work item. The waiting point is configured in a similar way as the work item, and can in fact copy a lot of the information from the previous work item if suitable. Many times (but not always) the event that the process waits on comes from an action in the same view as the work item work reference points to, and it is in these cases the copy method is a good choice ('configure as previous' as shown below).

Labels

The last thing we should do before running the process is changing some of the default labels in the process to make it more streamlined for the end user, as well as people who look at the process definition itself. The labels are the work item title, as presented in 'My Work list' and labels on the waiting point (only visible in the process model).

Runtime Preparation

To be able to run our process, we need to do some setup with the navigator, add a user to the Tester role, and also activate our process.

Running the Process

This chapter show how to start an instance of our process, how to pick the created work item, and make the process continue to exit.

Adding Roles

A refinement of the process model is to create a role of your own, instead of using the pre-defined Tester role.

Presentation Information

Presentation Key & Title are intended to be a help for the user when browsing the work list. They can consist of any information that identifies the data entity in question (such as an order, an item etc) of a process.

Adding States

A final refinement that we can do with our process is adding some states. States are presented in work lists and in process administration, as a summary of where the process is right now.

Work Lists

Work lists are the human interface for participating in a Processes. Processes creates task, and users works with, and complete tasks from different work lists. The work list in combination with executing processes enables a process driven way of interacting with a system. Manually added tasks can be added to the Work list.

Introduction

All personal work in Comflow is collected under My Work. The personal generic work list - My Work List - is central among the functions collected under My Work, especially if you are part of one or several executable processes. You can also reach My Work List via the icon at the top right corner in the menu.

When a user that is part of a process interacts with a running process, i.e. receives or submits information from/to a process, the tasks under My Work are used.

Features

• Overview
• Planning
• Notification of new work
• Sorting & Filtering
• To Do List

Concepts and definitions

Process

A set of one or more linked procedures or activities which collectively realise a business objective or policy goal, normally within the context of an organisational structure defining functional roles and relationships

Activity

An Activity defines what needs to be done

Task

A task is a general description of work that needs to be done by one single user. An Activity can consist of one or more Tasks. A Taks may or may not have a work reference.

Work item

The term work item is used for tasks with work reference. To simplify usage, the term Work Item is used for both Task and Work Item in the application

Work Reference

A reference to a function (a point workspace workflow) and its specific data where the completion of a task is supposed to take place.

Ad hoc Work Item

Ad hoc work items contain manually entered work that is by a process that only contains one Work item with the function it was initiated from as Work Reference. Technically it has no Process Instance behind the scene. It is only a certain way to create a single Work item.

Roles

A Role is a group of participants exhibiting a specific set of attributes, qualifications and/or skills. A Role defines the same authorization and responsibility for a Work Item.

Work item

A Work item defines what shall be done, by whom and possibly when. It also holds related attributes like Work subject, Work description, When it was created, Work priority, Project, Activity.

A Work item shall always be assigned to one single user, which then is authorized and responsible for performing the work that is related to it. If a work item is not assigned to a specific user, it can be claimed by others that are part of the same Role.

For a Task, there is no directly related system function and data to it, so the user has to do the navigation for that manually. For a Work item, the user is automatically guided to the right function and data via the Work List record.

My Work List

Overview

My Work List is the function to do all Process-related work for a user. It contains all active (Open) work items, all Closed, all work items that can be claimed, all work items that are redirected from other, the Processes that the user has administrative responsibility for and Settings for the Work List.

Quick Settings

The quick settings segment consists of the filter and the search order settings of the Settings view. If you don't use them often you can hide the quick settings and set the filter and the search order from the Settings view instead via the Settings… button.

The quick settings are persistent and applies to all the tabs in the work list (Open, Closed, Claim, Redirected).

When Project ID / Process is cleared, they will automatically get a '*' or a '%' to make the filter search all occurrences. You can also use '%' and '?' wildcards as in the generic temporary list filter.

Changes in quick settings take effect when you click the Find button (Enter).

Filter
Filter what data to be displayed. Enter the desired filter and click Find to display the results. The filter settings are saved. When you log in again the selected filter remains. The filter can be used on Project ID and Process.

You can also filter the results by entering a search word in the different columns.

Search Order
Search order applies to all your work items in the system, in contrast to the generic sort function of the lists which only applies to the current page.

For example, if you have many work items and all cannot be listed on the current list page, only the records on the current page will be displayed when you press Find. If you use sort order, also non visible work items can get visible and be listed.

You have two search order options, the first is applied first. If this returns a lot of hits, you can apply a secondary sorting within the list. If you select search order on Work Status and the search returns 50 records, you can select a secondary sorting on for example priority.

Open Work Items

The work items displayed in the list are work items that are assigned to you.

Closed Work Items

The Closed tab displays all work items that were allocated to the current user but are now either completed or canceled.

Claimable Work Items

The Claim tab displays items that are allocated to a role, but not a specific user. A user will see all items that he or she can perform given his or her role. This means that you can see all work items that are allocated to the role you belong to.

To work on a claim item you first need to claim it. You do this by right clicking on the item and selecting Assign me.

Redirected Work Items

You can delegate/redirect work to another user than the work item is currently allocated to. This is useful for example when a user is absent for illness or on vacation. The work item will still remain in the original user's list, but it will also be visible on the Redirected tab of the users it was redirected to.

Any user who has the work item in the Redirected work list and wants to start working on it needs to select Assign me on that work item. The work item will then be removed from all other users.

The re-assign settings are located under System Administration > Process Administration > Redirection of Work Items.

Process Responsibility

If you are assigned responsibility for a process, you will see those processes in you work list on the process Responsibility tab. You can via right click on the Process go to the Process view of the process or se all work items for the process via the function Work List – All Users.

The Process Responsibility settings are located under System Administration > Process Administration > Process Responsibility.

Work List Actions

Left-click row actions

• Process Info (icon)

Opens the Process Info popup that presents a graphical view of the process and the state of the particular process instance that the work item (the row you clicked) is associated with. A blinking circle around a wait activity shows where the process is waiting for event(s) to be able to continue. A square around work items shows open work items (yours and others) for this process instance.

Right-click menu actions

• Open

Takes you to the referenced work area, i.e. the view that the work item refer. If the work item does not have a work reference (if it is just a simple task), then the same generic task view opens as when using Open Task action below.

• Open Work item

Opens a detail view for the task, without showing any work reference view even if the work item has a work reference.

• Re-assign

Takes you to a view where you can re-assign the work item to a new user that have the specified Role on the Task.

• Completed

Sets a work item in status completed (and state closed) if the Process allows that.

• Cancel

Sets a work item in status canceled (and state closed) if the Process allows that.

• Process Instance Details

Takes you to a read-only detail view for the process instance that the work item is associated with.

Buttons

The following buttons are available:

• Planning
• New Work Item
• Find - Applies quick settings (and saves) and temporary filter and sort.
• Cancel - Closes the work list.
• Settings… - Takes you to your personal work list settings view.

Read more about Work Item, Task and Work Reference concepts in the general Function Help for the Work List.

Action Restrictions

Work Items created by processes can have restrictions that give warnings that you are not allowed to edit, close or re-assign these work items from generic views. The term "generic views" means views as the predefined work list, the work list planning view etc, all views that are predefined in the platform, and not made for a specific application.

When a process has set these restrictions, it is because the process itself needs to have full control of closure of work items and other operation. It can for example be that the process need to update some extra status values in a legacy system in the same transaction as closing a work item and sending out one or several new work items.

If such work items were allowed to be closed in generic views, the process would not be notified, and the particular process instance associated with these work items might not be able to continue executing.

Example: Can only reach a certain view via a work item. If that work item is removed, that view cannot be reached anymore, and the process cannot continue. Another process might have alternative ways to reach a view (from navigator), in this case, the process may allow closing work items from generic views.

Work List – All Users

Overview

Work List – All Users is the function and generic view to do all Process-related work for all users as an administrator. It contains all task for all users and all Processes. The function can also be used from the Process Responsibility tab in My Work List with a filter on the specified Process.

Work Items for all users

All work items for all users and processes are listed and can be filtered.

Work List Actions

Left-click row actions

• Process Info (icon)

Opens the Process Info popup that presents a graphical view of the process and the state of the particular process instance that the work item (the row you clicked) is associated with. A blinking circle around a wait activity shows where the process is waiting for event(s) to be able to continue. A square around work items shows open work items (yours and others) for this process instance.

Right-click menu actions

• Open

Takes you to the referenced work area, i.e. the view that the work item refer. If the work item does not have a work reference (if it is just a simple task), then the same generic task view opens as when using Open Task action below.

• Open Work Item

Opens a detail view for the task, without showing any work reference view even if the work item has a work reference.

• Re-assign

Takes you to a view where you can re-assign the work item to a new user that have the specified Role on the Task.

• Completed

Sets a work item in status completed (and state closed) if the Process allows that.

• Cancel

Sets a work item in status canceled (and state closed) if the Process allows that.

• Remove (archive)

Sets a work item in state archived if the Process allows that. This hides it from all your views (also the 'Closed' tab). It can still be re-opened by a system administrator.

• Process Instance Details

Takes you to a read-only detail view for the process instance that the work item is associated with.

Buttons

The following buttons are available:

• Edit all – Goes to a function to edit all work items
• Find - Applies quick settings (and saves) and temporary filter and sort.
• Cancel - Closes the work list.

Process Design

The checklist below is a suggestion of a very simple process design method that is suitable when designing processes in Comflow Platform.

1. Give a short textual description of what the process should do
2. Identify the ‘Main Data Entity’ of the process.
   • What is the main data object that one instance of the process should work with? (e.g. Item Registration has ‘Item’ as its main data entity).
   • It is recommended not to have several main data entities since the process design gets more complicated, though it is technically possible.
3. What roles are involved in the process?
   • A role is an abstraction of an actor in a process with the skills, knowledge and authorization to perform certain tasks.
   • You don’t have to identify all of them here, some are discovered when the tasks (see below) are identified.
   • NOTE: If you can only find one role, you don’t have to build a process, it is probably enough with an application with one or more workspaces where this single role can solve its tasks. An exception though could be a task that normally takes very long time, and you want to generate “reminders” in the work list, to be able to continue interrupted work.
4. Identify the tasks (the work items) of the process and give them descriptive titles
   • Give each task a role that should perform the task.
5. Find the main flow logic of the process
   • Is there any branches, and what do they depend on (just give label on the transitions).
   • Which are the synchronization points?
   • Which tasks can be done in parallel?
   • NOTE: If you find that there is no well defined order for the tasks (everything in the process must be possible for the users to do at anytime regardless of the state of the process), then the solution is perhaps not a process, but an application (a collection of separate functions that can be used whenever you need them).
6. When the main structure of the process is defined, then the user interface of the separate tasks can be defined (as Comflow "Workspaces" and views)
7. Later: Refine the process with
   • Email notifications
   • “Back loops” (e.g. tasks for complementing information)
   • Exception branches, as for example timeouts
8. The data of the process is normally identified to some extent while defining the process (the data that affects the flow logic, for example) as well as when defining the workspaces (the data that is necessary to solve a certain task)

When the process definition got this far, it is recommended to do the full definition of the data model and create its repository. After that, all views in the different functions (if several) can be completed.

Process Development

This chapter consists of step-by-step descriptions for the different parts of process development.

Process Flow Logic

In the figure below the different artifacts of the flow logic are described. The artifacts that are involved in controlling a process flow are:

• Event Definitions
• Event Data Constraints
• Transition Data Constraints
• Data Constraint Rules
• Split & Join Types
• Wait Types

Start Events, Split/Join and Wait Types

Event Constraints

Transition Conditions

Other Event Types

Remove Previous Work Item

Flow Logic Override

Process Data

This chapter describes all the different data that is associated with a process (apart from the main data entity of the process, the application or function data managed in a workspace workflow).

There are three main types of data related to a process:

• Process Data: Simple Variable-Value (string) storage, per process model, i.e. common for all instances of the process. Can be used as “Business Parameters” (Note. The term Process Data is also used in fuzzy way to summarize all the data that is related to a process (instance)).
• Process Instance Data: Same as above, but specific for a process instance. Process Data and Instance Data is like Map Data for Workspaces, but persistent.
• Connector Data: References to, or copy of data that arrives to a process instance through a process connector
  • Example: Workspace Data: The data that arrives from the workspace through the workspace connector in a workspace event (Map Data, Data Instance etc).

The connector data is not necessarily part of the process instance. The process instance can keep references to the data of the connector (Example: A process instance only keeps a copy of the workspace Map Data in order to be able to retrieve the rest of the data through the keys in Map Data). It is up to each connector to keep a copy of as much data as necessary to be able to retrieve the rest.

Process Connectors – There is one connector per event type: Workspace, Timer, Date/Time, Assignment, Service etc.

A connector is also responsible for the Work Reference of the same type. At the moment there is only one type of work reference: workspace work reference.

Process Data in Service Events

Since service events are general "fall-back" events to be used when no other event type fits, they are basic, and have for example no automatic setting of connector data (as other event types).

A service event does not have any knowledge of workspace data (as for example map data), and they should not have either, since they are general events to be used in any environment. However, sometimes you need to use a service event, and at the same time you need to propagate data through the connector into the process. This is possible by using a call-back method that is set in the calling rule of the service event. See below for an example of such rule.

// This method is called from the process framework after the process instance has been started

public void postReceiveEvent(AsynchControl processInstance, String eventId) throws Exception {

// Save as MapData

long mapDataId = System.currentTimeMillis();

// Typically the keys that you want to be reconstructed when clicking on next work item (see TestDefault.cml)

String keyColumns = "Key,Number"; // Just guess from your detail portlet, assuming these are in mapData

// String keyColumns = null; // Alternative to the line above: This one save ALL mapData (can have negative impact on performance)

// Store MapData (service event does not explicitly store map data as workspace event does)

AsynchConnectWorkspace.saveMapData(mapDataId, eventId, processInstance.getProcessInstId(), mapData, dialogWorkspace, keyColumns);

processInstance.storeMapDataId(mapDataId, eventId);

}

The method is included in the service event example AsynchWorkflow project. Look in the "Hello" process (from 2.16.35). Use MyWorkListsTest.navtree and the TestDefault task "drive" the process through service events.

Role Assignment

There are four main assignment methods

• Manual Assignment: Choose a user from a list.
• Automatic Assignment in a Rule: Set role/user in a rule.
• Claim: Tasks sent to a role, and anyone who can act in the role can claim the tasks.
• The "Single Role" method: If only one user can act in a role, then the role can be assigned immediately when process instance is created.
• Entry Point Auto Assign: A role for a start event will automatically be assigned to the user that trigger the event.

In a Process, tasks (work items) are assigned to roles at design time:

For a Process Instance, each role is assigned to a user at runtime. A role can at any time be re-assigned (with the same method as earlier or with some other assignment method).

“Can act in” role-user relationship: A user can only be assigned to a role in a particular process instance if the user can act in the role in general.

Summary

Design Time (Process): Task (Work Item) < Role

Run Time (Process Instance) Role < User(s)

NOTE: A role keeps its assignment throughout the life of the process instance (or until the role is re-assigned) 

Process Rules

This chapter describes where in a process "rules" can be defined. The actual java interface for process "rules" is described in javadoc bundled with the process framework of the platform (inside the net.comactivity.AsynchWorkflow Eclipse plugin).

Language Support

The task title have language support in the work list even though it can be considered to be data and not meta-data. The language support is initialized on system start. If the title is used in a dynamic way, for example modified from rules, it is possible to disable the language support through the site settings below.

Meta-data language support is managed like in other parts of the platform, in columns, and in label constants.

A user defined process for example has a name property where a label constant can be referred.

Troubleshooting

“Normal” recommended log-level during process development is to have ‘sql’ and other categories on level 'ERROR' and asynchwf on level 'INFO'. This gives an opportunity to “read” the process execution in the console

How to "read" the process log above:

1. No process... just a warning, in this case it is a start event, so no problem.
2. ...Started - The process framework found a process that meets the event conditions, and starts an instance
3. event data constraint... - The framework tells which one of the start event definitions that met the start condition (and that the event also had data constraints which matched).
4. WriteKey... - Sets an "Application/Process(Instance)" mapping, which helps the system to later on find the correct process instance from table key values. This is necessary only when running from navigator. When running from work list, the framework fins the correct instance anyway since each task (work item) is connected directly to a process instance.
5. change state... - Process state is changed according to the process definition (visible in work list for example)
6. Process Exec... - A process rule is executed (Assign.java, under Entry Point)
7. transition condition... 1_1 is true - Says that all conditions were true and it will traverse this transition
8. Traverse... 1_1 towards... - Says that the transition is traversed
9. execute Work Item Activity - The Work Item (with the name in the transition statement above; 'Add Purchase Info') is created
10. ...som more transisions...
11. prepare Wait for Event - The process instance enters a 'Wait' node, where it holds until some other even "wakes it up"
12. ... some more transitions are traversed - these are parallell transitions to the one that reached the wait, and all of them are executed until they reach end of the process, or a wait node.

When all transitions have reached wait nodes, the execution that was started by the event has come to an end, and the whole process instance waits for new events before it starts executing again.

Process Administration

Process administration includes starting, stopping and monitoring processes. An administrator also

has the possibility to re-assign users to specific work items, study process statistics etc.

Process administration tasks enable an administrator to start/stop processes on both global and

instance level. It is also possible to study process statistics, view users working lists, re-assign user

work items etc.

Processes

The Processes task is typically used to start and stop processes on a global level and to study global

process statistics.

Process State

In the sitedef it is, on global level, possible to define weather the default process state of deployed processes should be running or paused. When deployed, the process definition is saved on disk on the runtime server. When the server starts up all processes default process states (running or paused) are registered in the runtime database i.e. the database holds the persistent information about the process state (not the process definition itself).

The list of processes as seen in Figure 48 is, therefore, a list of process states for all processes that has been deployed to the runtime server.

When a process is in a paused state no new process instances will be created.

A Remove Row right click will immediately remove the selected process from the list of processes. Note that this operation only removes the process state from the list i.e. the process definition does still exist on the runtime server disk. No new instances of the process will be created as long as the process in not in the list. The process will be back in the list if the Reload Cache button is pressed (or after server restart) and the Processes task thereafter is reopened. The former of course only applies if the actual process definition has not been deleted from the runtime server.

Choosing Process Details … for a specific process will take you to the view below:

The duration segment

The duration segment shows statistical information about the selected process. Note that SVG viewer must be installed on the computer running the runtime browser client to be able to see the bar chart. Please see installation documentation for further details. In Figure 54 we can see that a total of five process instances (x-axis), of the selected process, have been created. One process instance is completed and has had a duration (y axis) of three days (the green bar). Four process instances are still ongoing and they all have been running for one day (the

blue bars). Each bar is named from the PID of the process instance.

.

Hovering with the mouse over a bar will result in a pop up displaying the duration of the process

instance in the format of days with two decimals.

By right clicking in the duration segment it is possible to zoom in/out the bar chart.

Process Configuration segment

In the process configuration segment it is possible to view, add, change and delete process variables. Process variables are global process variables that can be used to store aggregated process instances information or control the behavior of created process instances etc. Process variables are created in runtime, typically automatically from design time defined rules. It is, however, also possible to create process variables in runtime manually.

Creating process variables in runtime in a manual way should be regarded as a very unusual operation only to be used if it, for some reason, not should be possible to create them from a rule.

Please see ComActivty BPP Developer user manual for more information about process variables.

Process Instance Detail

A row click will lead to the Process instance details of the selected process instance. When right clicking on a specific process instance an administrator can choose to:

• Delete the process instance
• Display the Gantt View
• View process instance details.

Choosing Delete will delete the selected process instance. Note that deletion of a process instance only will remove the generic process data such as the instance itself, work items, map data etc. Already committed business data will not be removed. A delete process instance operation should be performed with great caution!

Process instance details – Gantt View

For each process instance there is the possibility to study process instance activity time details in a Gantt view. All work items, in this context called activities, existing in a process definition will be visible as a bar in the Gantt view.

From Figure 64 below we can draw the conclusion that six (6) different activities exists in the

process definition from which the process instance is created from; Solve Issue, Do Assignment,

Verify Solution, Give More Info, No Issue and Registration Continue.

Other conclusions that we can draw from Figure 64 is that only two, of a total of six, activities has been started i.e. been sent to the work lists of the associated roles; Solve Issue and Do Assignment. The green color of the Solve Issue work item bar tells us that this activity has been completed i.e. it has been handled by a user. The blue color of the Do Assignment activity bar tells us that the activity is ongoing i.e. the activity has been sent to the associated role but has not yet been handled by any user. Hovering an activity bar will present detailed time information for an activity (please see Figure 65).

More process instance details – Assignment segment

Almost all processes exchange information with different users acting in specified roles. In the Assignment segment it is possible to assign a user to act in the role for a specific process instance. Should a user already be assigned it is possible to assign a new user. Re-assignment applies to already started process instances, as well as future created instances.

More process instance details – Control (Internal State) segment

A design time modeled process consist of a number of modeling objects in a sequential order (see Figure). At every point in time each running process instance will be in a specific state, at a specific modeling object. In the figure,the circle around the last “wait for event” object indicates that this specific process instance is in that place of the process.

Normally no alterations are done in the Control (Internal State) segment. Any changes should be done with great cautions!

The only time you do any changes in this segment is when you for some reason want to force the process instance to listen to a new event (or several events) i.e. redirect the process flow in some way. In such case you have to delete the event(s) that the process instance is currently waiting for and add a new event(s) that should occur for the process instance to continue. This of course requires knowledge of the modeled process because you have to know the ActivityId, ActivityLabel and possibly ReceivedTransitionIds.

When right clicking on a specific activity an administrator can choose to:

• Delete the activity
• Create a new activity

The PID

Every created process instance gets an auto generated process ID (PID) that uniquely identifies the instance. A process instance typically handles a case, such as an item registration, which is built upon an item that is represented in an external database and that has a unique key e.g. the item number (here called Key).

For technical reasons it is sometimes necessary to associate the PID with the unique item number key. This is if we want a process to listen to events that are not handled using users work lists (with System Administration [Reference Manual] work lists the handling differs slightly). The PID/Key association mapping definition is made in design time.

Processes - All enterprises

Using the Processes – All Enterprises task it is possible to associate a process to another enterprise than the default association. All users and all processes belong to a specific enterprise and almost all query operations take the enterprise value as input parameter. If an administrator opens the processes task, all processes that are part of the enterprise that the administrator belongs to will be listed. Using the Processes – All Enterprises task all processes, no matter which enterprise it is associated with, will be listed. Hence, it will be possible to change

process/enterprise association. The Processes – All Enterprises task is probably quite rarely used.

Work list - All

In the Work List – All task an administrator has the possibility to view, re-assign and in several

other ways, work with all current i.e. not handled work items and notifications. You reach the Work List by selecting Process Administration > Work List – All in the System Administration menu.

See System Administration [Reference Manual] for more details about Process Administration.

Installation Configuration

Process Framework installation settings.

See Master Site Definition v 2.16 [Reference Manual].xml for more information.

Function Summary

The table below summarizes all the functions included in the process framework. Detail information can be found in the different chapters in this document.

Framework Architecture

This chapter contains a high level overview of the parts of the Comflow Process Framework and how they are connected.

• 
  
  • Modules
• Worklists
  • My Worklist
  • Worklist - All
• Process Statistics
• Process Engine
• Process Administration
  • Processes
  • Process Instances
  • Role Adminstration

Work Item 1

Work Item 2

open function()

Process Engine

My Worklist

Work Item 1

Work Item 2

find Process Instance listening on this event

Action Event

View

Wait for next Event

Create next Work Item

Remove Previous

Work Item

Work Reference

* CLICK *

Navigator

Figure: Process Execution (one execution step)