Roger,

I've been playing with RESTful services and collections, which has actually
given me a different perspective on the problem of workflow.

Assume for the moment that you have one or more real collections of
documents, possibly (probably) with some form of wrappers that include
tokenized workflow properties as elements (call if status for now).

Create virtual collections (say by creating RESTful interfaces backed by
XQueries or XProc pipelines) that then segment out elements by workflow
status. Include as the presentations on these interfaces some form of
syndication feed. Give the appropriate people access to the feed appropriate
to their state in the workflow, ordered by most recent, then set up a status
board "reader" that displays these feeds. They can see, edit or sign off on
a given document if they have the right permissions, and once they do, the
workflow status switches to something which moves the virtual records into
the feed. This keeps you from sending the document anywhere and creating
multiple (possibly conflicting) copies.

Taking a RESTful approach doesn't solve all problems, and you do end up
having to build an infrastructure on the back end to better support virtual
collections, but I find that it does seem to be a better alternative than
developing a complex formal workflow.


Kurt Cagle
Managing Editor
http://xmlToday.org


On Sat, Apr 11, 2009 at 2:06 PM, Costello, Roger L. <costello@m...>wrote:

>
> Hi Folks,
>
> Consider an insurance claim for an auto accident. It contains information
> about a claim, including:
>
>   - date of the accident
>   - damage to the car
>   - police report
>
> The claim is routed - as defined by some workflow process - to appropriate
> people and applications for processing. Which people and applications
> receive the claim depend on certain values of the claim.
>
> For example, if the estimated amount to be paid on the claim is less than a
> certain amount, a settlement offer is made to the client. If the estimated
> amount is greater, then an assessor is assigned to investigate the claim,
> and which office is assigned depends on the location of the client. Thus,
> these are two of the values used to manage the claim:
>
>    - "estimated claim value" is used to determine
>      whether the claim should be routed to the "offer
>      settlement" task or the "send assessor" task
>
>    - "client location" is used to determine what
>      resources (i.e. which field office) should be
>      used by the "send assessor" task
>
> "estimated claim value" and "client location" are values used for workflow
> management. A workflow management system can use these values to route the
> claim and assign resources to tasks.
>
> How do you deal with workflow management data vice content data? More
> generally, how do you design XML documents that enable workflow management?
>
> I can think of two approaches:
>
> 1. Header/Payload Approach (i.e. the SOAP approach)
>
> Store the workflow management values in a header section and the content in
> the body section. This approach requires the workflow management system to
> have the smarts to fetch the workflow data from the header section. The
> tasks must have the smarts to fetch the contents from the body section. For
> example:
>
> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
>    <soap:Header>
>        <workflow-data xmlns="http://www.auto-insurance.com">
>            <estimated-claim-value>$200</estimated-claim-value>
>            <client-location>Denver, Colorado</client-location>
>        </workflow-data>
>    </soap:Header>
>    <soap:Body>
>        <claim  xmlns="http://www.auto-insurance.com">
>            <ID>49303203-AAD</ID>
>            <type>auto</type>
>            <date-of-accident>April 9, 2009</date-of-accident>
>            <date-of-filing>April 11, 2009</date-of-filing>
>            <description>
>              Car failed to stop at stop sign and broadsided
>              the car.
>            </description>
>            ...
>        </claim>
>    </soap:Body>
> </soap:Envelope>
>
> 2. Separate Workflow and Content Documents
>
> The workflow data is placed in one document and the content data is placed
> in a separate document. The two documents are connected via links. The
> workflow management system deals just with the workflow document. The tasks
> deal just with the content document. For example:
>
> -----------------------------------------------
> Workflow Document (workflow-49303203-AAD.xml)
> -----------------------------------------------
>
>    <Workflow-Data href="claim-49303203-AAD.xml">
>        <estimated-claim-value>$200</estimated-claim-value>
>        <client-location>Denver, CO</client-location>
>    </Workflow-Data>
>
> -----------------------------------------------
> Claim Document (claim-49303203-AAD.xml)
> -----------------------------------------------
>
>    <claim xmlns="http://www.auto-insurance.com"
>           href="workflow-49303203-AAD.xml">
>        <ID>49303203-AAD</ID>
>        <type>auto</type>
>        <date-of-accident>April 9, 2009</date-of-accident>
>        <date-of-filing>April 11, 2009</date-of-filing>
>        <description>
>          Car failed to stop at stop sign and broadsided
>          the car.
>        </description>
>        ...
>    </claim>
>
>
> QUESTIONS
>
> 1. Are there other approaches than the two listed above?
>
> 2. What approach do you recommend?
>
> /Roger
>
>
>
>
>
> _______________________________________________________________________
>
> XML-DEV is a publicly archived, unmoderated list hosted by OASIS
> to support XML implementation and development. To minimize
> spam in the archives, you must subscribe before posting.
>
> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
> Or unsubscribe: xml-dev-unsubscribe@l...
> subscribe: xml-dev-subscribe@l...
> List archive: http://lists.xml.org/archives/xml-dev/
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
>
>