Hi Matt,
On 7/25/07, Matt Zukowski <[EMAIL PROTECTED]> wrote:
>
> John, I'm asking these questions not because I want to poke holes in
> OpenWFE, but because I want to better understand how you structured
> the system and why you chose to do it the way you did. Obviously
> you've given this a lot more thought than I have, so whenever
> something seems awkward to me, I assume it's my fault and not yours.
OK, thanks, but I also think that the documentation I wrote / I'm
writing can induce people in error, so thanks for your patience.
> Now, as for the REST API, I'm trying to organize it around our use
> case -- from the point of view of the other programmers here that will
> be using this workflow server. The server's perceived behaviour should
> allow the programmer to 1) instantiate a workflow with some piece of
> data, 2) find out where that piece of data is within the workflow, 3)
> provide additional information to participants within the workflow
> whenever needed.
Usually, 2 and 3 are provided by the "engine sends workitem to
participant" step.
For 2, if workitem pops up for participant Bob, then the process
instance is a step Bob. (Note that in concurrence cases, a workitem
will pop up 'simultaneously' in two or more participant inbox).
For 3, a classical scenario assumes that the participant is external
to the engine, thus all the necessary info for accomplishing the task
has to be stuffed in the workitem.
The engine is really an asyncrhonous beast, its participant expression
is meant to dispatch the workitem to a participant and then wait until
the reply comes.
> That's it. Nothing more, nothing less. The
> programmers shouldn't have to understand what an expression is, what
> participants are, what the engine is, etc. All these things can and
> should be abstracted away.
>
> For example, we might have a workflow defining an approval process for
> requesting a new project. The process involves 1) submitting some
> information (the project's proposed name, client, budget, etc.), 2)
> sending out approval requests to managers, and then 3) notifying the
> person who requested the project of the result. A programmer making
> use of this would place a call to the workflow server with two pieces
> of information: the name of the workflow definition to use (e.g.
> "new_project_request"), and the data payload (a hash with the project
> name, etc.). In return the programmer gets some identifier that lets
> them refer back to this later on.
OK, this is covered by
fei = engine.launch(launch_item)
> At this point the workflow server
> takes over, and the only thing the programmer might want to do is
> check whether the workflow is done or if its being held up somewhere,
OK, status information.
> or to provide additional information to a participant waiting within
> the workflow.
Participant has a workitem, maybe he wants some more information about
the process instance to which his workitem belongs to.
> So, I think that to facilitate the above process, the server should
> expose only the following behaviours:
>
> 1) Launch a workflow based on some data payload, returning a reference
> identifier.
engine resource.
> 2) Return the state of the workflow, based on the given reference
> identifier.
workflow instance / process instance resource.
> 3) Talk to a participant within the workflow (for example to update
> the data payload)
participant resource.
Makes sense.
> Framing this behaviour in a REST interface, I think that the one you
> posted above is great in terms of reflecting the underlying structure
> of OpenWFE, and maybe even in terms of the conceptual structure of a
> general workflow system, but it would be a bit confusing to a
> programmer who just wants to throw some data into a workflow and cares
> only about its status and result.
>
> So maybe the interface for the workflow instance should be something
> like:
>
> == Resource: WorkflowInstance
>
> C: launch a new workflow instance (returns workflow instance id)
> R: get status of workflow instance (returns OpenWFE's ProcessStatus
> object, serialized)
> U: no operation
> D: cancels workflow instance
>
> This is great for behaviours (1) and (2), but leaves us with the
> problem of how to deal with (3). Can you explain a bit what you mean
> by the "participant /slash/ workitem_id" resource? What is a
> workitem_id in OpenWFE terms? My impression was that the only way to
> reference to a workitem sitting in a participant is by knowing the
> participant name and FlowExpressionId (i.e.
> engine.get_participant(name)[fei]).
Let's imagine you have a participant "Alpha", it's a store participant.
To get the first workitem in participant Alpha
GET http://server/participants/Alpha/0
To get the count of workitems in participant Alpha (and generic info
about the participant)
GET http://server/participants/Alpha
To save a workitem (#2 here) (modified, but not to forward)
POST http://server/participants/Alpha/1
To forward a modified workitem
POST http://server/participants/Alpha/1/forward
(well, it's less RESTful, maybe simply PUT /Alpha/1)
That's my "participant / index" idea. The index concept has flaws,
instead of using an index, the "workflow instance id" + "expression
id" would be better as other workitems could pop up for the
participant meanwhile.
> I agree that we need a resource that corresponds to a workitem sitting
> within a participant, but I can't quite get my head around
> conceptualizing it. Whatever it is, external application will need
> some way of addressing it directly. Lets say my workflow looks
> something like:
>
> 1) send approval request by email ---> 2) wait for response ---> 3)
> send response to original sender
>
> Once the workflow gets to (2), I need the external application to
> somehow know how to address (2), and right now -- as far as I can see
> -- the only way to do this is via a combination of the participant
> name and fei.
Your questions are welcome.
Best regards,
--
John Mettraux -///- http://jmettraux.openwfe.org
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"OpenWFEru dev" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/openwferu-dev?hl=en
-~----------~----~----~----~------~----~------~--~---
