I've got a few ideas, and a few comments on the proposal.
Reading over your workflow support, it looks not that far from what I had
done for per-request workflow support. You've also got it extended to
multiple pages. Nice. The suggestion below, of allowing people to share
workflows, is an interesting one. Given this, here's a few of my
suggestions.
First of all, I'd like to see some consistent address space available across
an entire workflow. I'd like to be able to request a form field value from
a FormBean on the 2nd page of the workflow, even though I'm on the 7th page.
I'd like to be able to transfer control for a workflow to another user, in a
secure fashion. Given this, here's my proposal.
In your multi-wizard schema, add a <struts:page id="page1"> (or whatever) to
indicate a single page within the workflow. This would, in turn, contain
the <struts:forward> and <struts:navigate> tags. The idea is that this
provides a namespace for looking up FormBean values. From some other page
in the workflow, you should be able to look up values from the FormBean
associated with a given page that is identified by name.
You should also be able to set up role-based security for a workflow by the
workflow name and the page name. I could, for instance, set the third page
of an application open for my boss' signature. I would have some GUI that
would add my boss to the role associated with the third page of the
workflow. In such a case, the state (the collection of FormBeans for the
workflow) must be persisted in some manner. I'm not sure if it would be
easier/better to make this declarative--declare in the XML config file that
the state is persistent--or if the act of assigning a workflow to another
user would implicitly cause the state to be persisted.
At that point, the other user would have to be able to go to the named page
of the workflow. If the user has been assigned the workflow from more than
one user, then the user will be allowed to choose which workflow should be
used. Thus, runtime workflows are identified by workflow name, page name,
and user name (the user name that assigned the workflow...probably set to
null of the user initiated the workflow).
Now, I think we would have a secure way to transfer workflows from one user
to another. Your configuration file format only needs to change slightly.
Workflow data can be interrogated during the workflow. I think it could
work. It would require lots of JSP tags to facilitate things like selecting
a workflow when more than one is assigned.
What do you think?
-dan
-----Original Message-----
From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED].
org]On Behalf Of Craig R. McClanahan
Sent: Saturday, August 11, 2001 4:37 PM
To: [EMAIL PROTECTED]
Subject: RE: Workflow Support Proposal
On Sat, 11 Aug 2001, Michael Rimov wrote:
> Craig:
>
> I read through your proposal. [Which I liked very much] Forgive me if
I'm
> just missing it, but can the workflow support multiple users at any given
> particular time? What I mean is this:
>
In other words, multiple users that participate in the *same* workflow
instance? Yah, I didn't really address that one. I was focused on the
individual user interaction - but the multiple-user case is very important
as well.
> App Flow:
>
> -User A Performs Step 1
> -User A Performs Step 2
> -Application Mails User B URL to Step 3 (For example, a content approval
> message)
> -User B Clicks on URL to Step 3
> User B Performs Step 3
>
> etc...
>
> Now obviously, the mailing mechanism would have to be my own logic, but
> would the workflow cover the whole process with different users performing
> different steps or would you have to have a separate workflow for each
user?
>
In terms of the initial workflow proposal, it could be two individual
workflows that are coordinated (and, at the detail level, this seems
necessary anyway -- content approval, for example, could be a multi-step
process in and of itself).
There's also an interesting aspect of this - it is somewhat more
asynchronous, because you don't really want person A to be locked out of
doing anything else until person B is finished.
> If so, do you see any way that something like this could be integrated
into
> the workflow engine?
>
I think this is a very useful concept to consider adding. It might take a
level of abstraction above the current "Workflow" component to represent
it. There would also need to be a more formalized way to retrieve the
current state of a particular flow instance that is in progress (for the
web application single user case, you'd just store the Context object in
the session).
Now to figure out how to integrate it ...
> Thanks in advance,
> -Mike
>
>
Craig
