Ok so we redid everything in parallel. Too bad anyway I will continue
and my changes are in my clone.
I will update the booklet once I get it.
Stef
On Sun, Jan 21, 2018 at 6:05 PM, Cédrick Béler <cdric...@gmail.com> wrote:
>
> HI cedrick
>
>
> I tried to start a booklet with Stephane but it is too complicated right
> now. Stephane started a simpler version.
>
>
> For now saving and loading is not important. :)
>
>
> Yes
>
>
>
> I put below a summary of the reflexion/discussion I had with Max.
>
>
> Thanks.
> Now you should publish your code.
> I would have preferred to work from a working code. Because now it is
> like poking in the dark.
>
> Cedrick what did you get running?
>
>
> Actually, I got the workflow working and the tests as you. And then I was
> able to run some examples (as I tried to wrote in the booklet).
>
> I just din’t know yet how to publish on GitHub and friends… I discussed with
> Max about then… I’m learned a bit after how to use these tools especially
> for the booklet as we chatted….
> Then end of the semester…. No time…. Should be better soon.
>
> So sorry for that :)
>
> I join the last pdf I had…. Fuzzy (especially since I tried to include
> automatically classes comments) but there are details of installation and
> what I could make work:
>
>
> - rethink persistence (process definition and orchestration, realization)
>
> => persistance is essential and was central to Aare. Beside removing
> Omnibase references (and implication of WfManagedObject), some of the
> application features were very dependant on the persistence (like logging,
> tracing process evolution). All of these features are to be thing again
> considering as much as possible a loosely coupled solution. A general
> purpose storage solution like Voyage could be used. At first, in image
> storage will be used to focus on the running aspects of the library.
> - rethink interaction
> => Designing a general interaction sub-system is probably the more
> challenging tasks. Aare was web based. We want workflow to be UI agnostic.
> Moreover, we want to associate ,
> remove Magritte (replace UI or build an independant system based on
> Annoucement for instance)
>
>
>
> Yes I agree. Now I would like to be able to
> - define a super simple workflow: I picked sequence: start -> task1 -> task2
>
>
> Done in WfWorkflowLibrary (with convenience method). An example in 2.4
>
>
>
>
> - 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).
>
>
> […]
>
> DomBuilder is a small package for wrapping XML-Parser. I'll publish it so
> you can use it.
>
>
> Cedric did you got this package?
>
>
> No but I didn’t ask either. It’s possible to ask Max. But I think first, as
> you, we need to be able to run a process.
>
>
>
> The XML-Parser package has been significantly modified and
>
> is now named XMLParser (you can find it in the catalog). You should make the
> changes necessary to use the current incarnation of XMLParser (decide for
> yourself whether you still need DomBuilder or not).
>
>
> But this is not really important.
>
>
>
> Yep.
>
> Cheers,
>
> Cédrick
>
>
