Re: Some random gibberish

On Mon, 17 Mar 2003 09:22:07 -0500, bob mcwhirter wrote:

>> Here's a use case I would like to support using werkflow.
>> 
>> Create User
>> -----------
>> 
>> Steps
>> -----
>> 
>> 1. Gather - Get the user login, password and email address. 2. Validate
>> - Ensure that the login and password are compliant with our rules.
> 
> For this typs of interactive thing, where you want to keep displaying
> the form until folks have entered enough of the right data, I'm thinking
> will be another layer outside of what we know as 'werkflow' at the
> moment.
> 
> I like having werkflow be messaging-based, but that doesn't lend itself
> to interactivity with immediate feedback.  So, by having a 'portal'
> layer that builds/displays/accepts form input and then shoots off a
> message to the core, we can maintain the distinction.

Gather is obviously and outside operation =(in this sample done via a html
page). The HTTP form would contain the information required to initiate
the process. I was careful not to introduce a loop into this, it's just
work or fail (fail ending the case).

My reason for wanting to keep it in the work flow is simple. One place. I
don't need to care if the system is running struts, webwork, maverik or
cocoon (I envisage adapters to extract parameters and initiate events for
each of these environments).

The blocking should not be a part of the werkflow but rather an indication
from event initiator that it wants to wait (how we determine when it
returns is a point for discussion).

>> 3. Store - Store the users record with an unverified flag
> 
> I'd call this the 1st action of the core after receiving a message.
> 

I don't excpect to see errors like the database is dead, or you run out of
disk space etc, in the use case. We will need to allow a response to the
error condition though (email admin, hide under the bed etc).

I can see three possible places (excuse my ignorance if it's already
there), Engine, process and case.

>> 4. Send Confirm - Send a notification to the registered address with a
>> request for confirmation confirmation
> 
> 2nd action.
> 
>> 5. Receive Confirm - Update the unverified flag for the user
> 
> a <receive> to wait for response.
> 
>> 6a. Send Sys Alert - Notify System admin of new user registration
> 
> 3rd action.
> 
>> 6b. Index - Add the user to the list of active users
> 
> 4th action.
> 
>> 6c. Add the user to the announcements mailing list
> 
> 5th action.
> 
>> 7. End Process
> 
> 
>> 2.1 -- Failed Validation
>> 2.1.1 Notify - Notify user of validation errors. 2.1.2 End process
>> 
>> 5.1 -- Confirm not received in 48 hours
> 
> Yah, I've still got to work on timeouts.
> 
>> 5.1.1 Remove - Remove user record.
>> 5.1.2 Send alert - Notify sys admin of fail registration 5.1.3 End
>> process.
>> 
>> 5.2 -- Receive Confirm after 5.1.1
>> 5.2.1 Notify - Notify expiration of confirmation. 5.2.2 End process
> 
>> 1 is initiated via a an http request. It would be nice be be able to
>> call the werkflow engine in a blocking mode to handle the 1,2,2.1
>> interaction
> 
> We could, but I'd ask you think of another layer, possibly informed by
> the engine, but separate.  ie, maybe we have a <form> syntax to define
> your abstract forms, and it presses out a struts Action or something to
> handle the validation and message generation to the wf core.

See my notes above :)

>> 5.1 is a timed event. 5.2 is probably an error (ie the associated case
>> has been completed)
> 
> Right, designed but not implemented.
> 
>> 5 and 5.2 are initiated by email. James?
> 
> You can have a chunk that POPs email or acts like an SMTP server to
> receive email, process it into some other easy-to-act-upon message which
> then can flow through the MessagingManager to the core.
> 
>> enough for now. I'm thinking I want to start on a full working example
>> with web, email interaction etc. User management seems to fit the bill,
>> what do others think.
> 
> I think the first 'problem' to solve is the user-interactive parts. I am
> working on support for synchronous actions, but there's still a
> thread-pool involved, so it won't be a blocking call.  Maybe we can add
> some blocking semantics, but I'm still leaning towards a UI layer
> external to the core sending messages.

I don't think that the process itself should have a blocking note (I might
be calling this process from a bulk loader). I do think that the caller
though should be able to wait on a response.

-k.

-- 
If you don't test then your code is only a collection of bugs which 
apparently behave like a working program. 

Website: http://www.rocketred.com.au/blogs/kevin/