- execute it and script it resolution.

See 2.5.

My way of running them and where I stopped and is a bit stuck.

To me we need now to design an interaction model (based on Annoucement ?)

Running a workflow.

Once a workflow is defined, to be executed, he calls the method #executeIn- newFrame. This method instanciate and populate the worklist (WfWorklist) that keep track of the state of the running workflow.

      workflow := WfWorkflowLibrary simpleBranch.
      frame := workflow executeInNewFrame.

To see running activitions (activities that are started but not completed yet):

      frame worklist running.

Once a activation is over, it has to be completed by sending the message #completed. For now, there are only manual completions but we could imag- ine in the future automatic or semi-atomatic completion based on extrenal interaction or if delegated to a program for instance.

      anActivation := frame worklist any.
      anActivation complete. "complete mannully one activation"
      "or"
      frame complete: anActivation.

The workflow is running until there are no possible (accessible) activation left. This state is called implicit termination and can be checked with:

      frame isCompleted.

Here is the code of the WfFrame��>completeAll

      WfFrame>>>completeAll
        [self workList allRunning isEmpty] whileFalse:

          [self completeActivation: self workList allRunning first].

I would like to understand the difference between frame and activation.

The frame is the container of the workflow resolution, the �� manager �� A workflow runs in a frame (subworkflows in subframes)��

Activations are when a step (one activity defined in a workflow) is activated (we are starting for real to do the activity).

WfWorkflowManager managers workflow definitions
(static) and activations (dynamic).
WfFrame is also a part of the dynamic side, connecting activations to a
workflow.
Workflows are hierarchical, i.e. a step can have a sub workflow (see
WfWorkflowLibrary>>simpleSubflow)

Yes for now I do not want to understand this part.

You have too to get the workflow running I think.

3)

Going back to activations, here is my current understanding.

Once a step is activated (all condition on Edges leading to are true - to
evaluate outgoing conditions of a step, the step execution has to be
complete first) , we get an activation instance (I��m not 100% sure how
completion of an activity and outgoing conditions are managed).

As far as I understand, a step can always be activated (e.g. manually).
However, activating a step propagates the values of conditions on the edges
to the next steps and their activations ("dead" or "alive"). Hence, an
activation responds to #isAlive with true if at leat one incoming token was
true ("alive") (see WfStep>>continueInFrame:fromStep:alive: and
WfActivation>>isAlive). The conditions are evaluated once #complete is sent
to the activation.
Activation instances are created by two ways (slightly different for the
start step), but generally they are created when a step receives tokens from
the outgoing edges of an upstream activation (see
WfStep>>continueInFrame:fromStep:alive:).

Activations are central.

On the exemple of BLActivationHistoryItem that you gave, I��m not sure if
it��s an activation of a history item stored in the history (subclasss of
WfHistory?).

My idea was that it should represent a record for an activation (there might
be multiple records for a single activation). So "HistoryItem" would be the
general description of a record, of which "ActivationHistoryItem" is a
special case for activations (I hope that makes sense).

4)
Moreover I don��t see clearly the difference with a scheduler and a BP engine
(they are at least really complementary). Do you see any ressemblance
between Activation and ScheduledJob ?

I actually would like to have a (simple) scheduler with the BP engine :)

Well, it's certainly a matter of point of view. I would argue that an
activation is something close to a "job". A "scheduled job" would be a more
specific case of a "job", a job that is in a queue. An activation has no
notion of scheduling but simply represents the idea of what happens when
traversal between two nodes occurs. A scheduler would be one way of managing
activations (WfWorklist seems pretty close to a scheduler, holding running
and completed activations).

Too subtle for me.

For now, the are no real workflow engine. More a state machine providing access to activable steps (and running one�� hence remaining ones).

I/We will need a scheduler (even simple ones).

Max explains below:

To me the scheduler right now is not really existing besides having a list
of simultaneous/parralelized steps to realize (activated or not). Activated
means currently being done.

You're right, I think. The application that Workflow was designed for
required manual interaction, hence there was no need for other methods of
scheduling (e.g. by time or event).

This activation role is about logging and interacting with responsible
users. But it is more than that. It��s the actual job being done.

Yes.

5)

Concerning run time modification of a process. Is it true that we can modify
a currently executed workflow (steps that are not yet activated ?) ? I think
that is possible (an cool). When activated, it shouldn��t. Would you think it
would be interesting to allow activations to be suspended/resume (frozen),
cancelled ?

The history of workflows consists of copies. The steps of a workflow
reference the workflow they belong to. Therefore, while it is possible to
modify a workflow, modifications do not impact running workflows, as the
steps of that workflow continue to reference the previous version. The model
suggests that it is ok to create a new version of a workflow but not to
modify existing workflows.

For now I would like to get a workflow running without modifying it

Sure. But again an interesting decision to have first.

To me, what more interesting is to be able :

- to cancel a task (an activation actually),

- change dynamically the remaining workflow (to adapt)��

- eventually suspend/resume (nice to time track but I also thin it��s not hard to have)

I know the second point seems too early but again this is important to consider now.

Designs decisions of Aare leaves some room to build more (and constrain its use).

[��]