Making your e-business work  

Home

Standards
    Conformance
    Reference Model
    Public Documents
    XPDL_2.0
    Wf-XML 2.0



About WfMC

Events

Information and
Publications


Free downloads

Membership Information

Press Room

Excellence Awards

Marvin L Manheim Award

Workflow Handbook
   2001
   2002
   2003

   2004
   2005
   2006 NEW!


Associated sites:
AIIM
WARIA

e-workflow.org

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

Workflow and BPM Research

BPM Community Forum
 


Issue 19
<ResultPage> tag

Resolution: The Message Header contains a parameter “ResponseRequired” that indicates whether or not a response

is required.

Keith Swenson CT0014.1 Asynchronous creation of process instances: Asynchronous creation of process instances on such

protocols as FTP and SMTP which do not necessarily use the result page. First, we add a new

parameter <resultpage> which indicates the need of a result page. The SWAP server does not

return a result page when the value of the parameter is no. When the result page is not returned, it

becomes a problem that a key URI of a process instance is generated in a server and sent to a client

in a result page according to the SWAP1.0draft interface. A client can hardly ask about a process

instance without the URI. We add a new parameter <requestKey> of the createprocessinstance

method which enable a client to assign a key for a new process instance to be created. A client is

responsible for assigning a unique requestKey. Two possible actions when the server receives a

requestKey which is not unique: return an exception or just create it anyway with a non-unique

request key. (item for discussion: which?) It is a value that can be used to search through the list

of process instances and find the process instance that resulted from a particular create request. For

this reason the request id must be included in the values returned with ListInstances. This may

serve as the purpose that ResourceID was invented for (but I am not sure). We add another new

parameter <originalKey>. The originalKey is inherited by subprocesses and following processes

(explained in section 2.3) while a requestKey is only assigned to a corresponding process

instance. We can ask directly any process definitions using the originalKey when a process

creates several subprocesses and following processes succeedingly, while we need to trace them

in sequence without originalKey. The flow engine is responsible for carrying the originalKey of a

process into its subprocesses and following processes. We add a new method <propfindinstance>

to the process definition interface which returns the information of the process instances which

match a particular <requestKey>, <originalKey>, or <batchKey> (see below). This functions in

other ways like the ListInstances method.

Issue 20
Application Level vs. Session Level Data

Resolution: Each Wf-XML message contains a message header (tag WfMessageHeader), message body (tag

WfMessageBody) and an optional section on transport mechanisms (tag WfTransport). The message

header (WfMessageHeader) is used for a variety of session specific information – such as whether the

message mode is a request or a response, user defined correlation information and exception information.

The message header must be provided in each message. The message body (tag WfMessageBody) is where

the operation specific information is placed. Transport protocol specific information is described in the

optional transport section (tag WfTransport).

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

Wf-XML 2.0
 

Information Services
Info Services
Awards
Books
Workflow Handbook

Membership
How to join
Application
Country Chapters
List of members
Officers
Fellows


NEW!

Workflow Handbook 2006
NOW SHIPPING!



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. http://www.wfmc.org.

horizontal rule