Making your e-business work  


    Reference Model
    Public Documents
    Wf-XML 2.0

About WfMC


Information and

Free downloads

Membership Information

Press Room

Excellence Awards

Marvin L Manheim Award

Workflow Handbook

   2006 NEW!

Associated sites:

Got a question?
Join our Discussion Forums
 Discussion Forum for Workgroups (WfMC-specific)

Workflow and BPM Research

BPM Community Forum

Rainer Weber CT0022 1.1 Interfaces WorkList and WorkItem

To me, the Interfaces WorkList and WorkItem still have a very rough status (as in the first

SWAP proposal), they are not very elaborated

and are not part of the "main stream" (i.e., start a process, monitor it and get notified when it is

completed). I would favour leaving these

things out of the spec's first version. At least there should be different conformance profiles

such that you can conform to the SWAP spec,

but only the "main stream", not the worklist stuff. To me, the worklist/workitem handling and

process starting are two completely separate issues. Proposal: Leave it out; or elaborate it

and mark it as optional.

Rainer Weber CT0023 1.2 Interface EntryPoint

This seems to be a very specific thing. Is this really needed?? If so, can this not be modeled in

a way that for a process with several

entry points we have several "virtual processes" (one for each entry point). Each virtual

process could obtain a different resource ID,

e.g. the resource ID could be composed of the process ID and the entry point ID.

Proposal: Leave it out.

Rainer Weber CT0024 1.3 Interface ActivityObserver

I do not really see the purpose of that interface. Is it just to monitor the process, to find out

which activities are pending? If this is so, ProcessInstances.PropFind already gives you that

information, viz. the activities. For a hierarchic process each activity could tell whether it is a

(sub)process, and thus the method PropFind suffices (a slight extension of PropFind was

needed then.) If it is not just to monitor the process, it is to modify the activity. If the activity

is a (sub)process, we already have mechanisms to modify a process: The methods PropPatch

and Terminate of the interface ProcessInstance. If the activity is not a (sub)process, why

should we modify that activity? This is then done by executing the corresponding work item,

and should not be controlled from outside. So I do not see why this interface should make

sense. Proposal: Leave it out.

Rainer Weber CT0039 What are the results of all these methods? None are given.

Proposal: Clarify.

Olaf Kruger CT0101 We read in the description on CreateProcessInstance: "When invoked via this interface, a

work item will also be added to the user's worklist, which can be controlled through the

WorkItem interface." I am sure I am missing something... but when I ask a worklist to create a

new workitem (to be the placeholder for the created process instance), how to I specify the

user to whose worklist I am referring? Wouldn't I need details as which worklist I am adding

the new workitem / process instance? Secondly, once the process instance is created, and the

workitem has been added to the worklist, should I not get some workitem resource id back for

later reference when using the workitem interface?

Richard Heim RW0022 First, I definitely agree about WorkList, WorkItem, EntryPoint, and Activity Observer. I

don't use any of these. They do map to Jflow though.... (except EntryPoint)

Issue 29
Batch Creation of Process Instance

Keith Swenson CT0015 Request which contains a batch of process instances to be created: We add a new method

'createProcessInstances' which contains information for the creation of more than one process

instances. The information for each process instance is same as the createProcessInstance

method. We add a new parameter 'batchKey' which is assigned to each request of the method.

We can use the batchKey for asking the server about the batch request. The resultpage of the

method is a list of the requestKey and URI of the instances.

Rainer Weber CT0021 As for his comments 15: I do not agree with 15.2 (create a batch of process instances). Cannot

we handle this by just transfering a request

which includes several XML bodies? Or do we get syntactic problems? And with 15.3 (flow

control without a center server), I do not see who controls the process. Either there is a center

server which call A, B, C in a row; or after A, A's server calls B (B need not be a subprocess of

A for that purpose), and after B, B's server calls C, similarly. Maybe I just do not see the point

Friday, June 09, 2000 Page 3 of 8
First Previous Next Last
Published Docs
Reference Model
XPDL support

Wf-XML 2.0

Information Services
Info Services
Workflow Handbook

How to join
Country Chapters
List of members


Workflow Handbook 2006

CDROM Companion to the Workflow Handbook 2005


horizontal rule

home | membership | standards | info | events | members only

All brand names and product names mentioned in this website are trademarks or service marks of their respective companies. Any omission or misuse should not be regarded as intent to infringe on the property of others. The WfMC recognizes and respects all marks used by companies, manufacturers and developers as a means to distinguish their products. The “WfMC” logo and “Workflow Management Coalition” are service marks of the Workflow Management Coalition.

horizontal rule