Pharo-users

By thread

pharo-users@lists.pharo.org

January 2018

82 participants
456 messages

Re: [Pharo-users] Aare questions

by HernÃ¡n Morales Durand

Hi CÃ©drick, 2018-01-21 8:04 GMT-03:00 CÃ©drick BÃ©ler <cdrick65(a)gmail.com>: > Hi Hernan, > > I decided to give a try to Aare or Workflow in Pharo 6, following > instructions in https://github.com/Netstyle/Workflow . > > > Cool :) > > I started but had to stop until the semester is finish. Next month should be > ok to continue on that. > > > However, the > installation script raised a Warning about missing WADynamicVariable > class. Should I install Seaside? > > > > Happy to see people having interest in such tools :) > > No. > > I discussed with Max Leske. > > To solve this Â« pb Â», just create WADynamicVariable as a subclass of > DynamicVariable already in Pharo. There are also missing part for the > export/import in XML (should be easy to fix and Max propose to give the code > - DOMBuilder and co.) Thanks. I cloned the Ducasse fork which already solved the issue. > I tried to start a booklet with Stephane but it is too complicated right > now. Stephane started a simpler version. > > I put below a summary of the reflexion/discussion I had with Max. > > > Cheers, > > CÃ©drick > > > > > ========= INTRO > > What's missing compared to the full (proprietary) solution are user > interfaces that were web based (Seaside \+ Magritte). Also, persistence was > achived through Omnibase. References were removed but they are stil some > disfunctionning. Moreover, the completion of activities were mainly manual > and achieved through web interface (web forms). They are, for now, no real > way to introduce different kind of activities like those being > message-based, event-based, service-based. > > To evolve, one has to remove all dependancies to Omnibase and > Magritte/Seaside. > > There are also important design decisions to ensure WfWorkflow being a > powerful and extensible workflow management system for Pharo. To me there > are 2 main tasks: > - 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) > It could be me that I am used to execute and wait processes jobs for hours or days in HPC: typical workflows of NGS trimming, QC, genome indexing, sequence alignment, etc. But integration of a monitoring system (like Ganglia) and interaction with a work load manager (like PBS, Condor, Slurm, etc.) would be also giant tasks. > ========= RANDOM QUESTIONS AND ANSWER (in black me - below max) > > 1) > > The static definition of workflow is done through WfWorkflow, WfOutgoingEdge > and WfSteps (+ WfConditions). The easy part :) > > The runtime aspect are achieved via WfActivation, WfWorkList, > WfWorkflowHistory et WfWorkflowManager. More difficult to understand and > make evolve. > > WfWorkflowHistory represents the different versions of a workflow, so it > belongs to the static part. 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) > > > > 2) > > To me activations are really central entities (and I need to be sure of its > correct role). They are said to the realization of an activity/step. > > Can we consider the static definition of a workflow as Â« Plan Â» and the > runtime as the concrete realization (like a job in a scheduler) ? > > Yes, I would say so. > > > > I see that: > > > FUTURE: Static BP dÃ©finitions with steps (plans) > > PRESENT: activation (realization) > > PAST: History (experience feedback) > > Yes, that's certainly one way to look at it. Although I'd say that the > static definition is independent from time once it exists and that "future" > would be the set of steps of the current definition that have not yet been > activated (just a little nit picking :) ). > > > > 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:). > > > 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). > > > 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. > The model does *allow* (in principle) to modify an existing workflow but I > doubt that was the intention. However, I don't see why modifying an existing > workflow has to be bad thing, as long as you can guarantee that only edges > and steps are modified that have not yet been activated. That could open up > some interesting possibilities. > Cancellation of an activation could be very interesting. It would basically > allow reversal of complex effects. Very nice idea! I'm not so sure though > whether suspending makes much sense. Maybe when a step has the potential to > take a long time for some operation. But then you may run into transaction > problems. The nice thing about an activation at the moment is that it's > atomic (in theory). But again, done right that could open up interesting > possibilities. > > > > If a running process is modified, do we track its evolutions in > WfWorkflowManager ? > > The modification of a workflow is indeed announced to WfWorkflowManager, > yes. Workflow versions are stored in WfWorkflowHistory. For modifying a > *running* workflow you will probably want to create a specific workflow > manager for that, that does validation etc. > > > > The goal of history(s) are to log the realization of the process. But is it > one of its aim to Â« replay Â» the process execution ? > > No. WfWorkflowHistory only stores the static definitions. However, the > history of activations could be used to replay an execution (nice idea!). > > i.o.w., Is it more than log/report ? > > I think the activation history was designed as a log, the workflow history > as a log and also as a way to undo changes. As you suggest, however, they > could certainly be used for more things. > > > I agree with the separation (WfWFManager for the run time evolution of the > process definition => adaptation and WfActivationHistory for the trace of > interactive/automatic step realizations information). > > > #beginHistory implementation example was very helpful. I knew I missed > something Just, as I see a MailManager (with role is obvious), is it > something that has to be generalizable ? Like InteroperableManager ? > MessageManager ? To get user interactions > > That would be very nice, yes. You're completely free to do what you like. It > would be cool though if we could evolve the project as opposed to you > creating a fork to your own liking. If you're game we can set up a workflow > on github where you open pull requests against our repository. > > > > 6) Iâd like to remove fully the reference and need of Omnibase and > Magritte/seaside forms. > > Yes please! > > > I think Omnibase is ok, even storing in image for instance. > > Whatâs more problematic to me is for user interactions (and even automatic > interaction through program for instance). There are achieved in your > example with seaside. It is ok but what if Iâd like to do it more generally > ? Would we use Annoucement for example ? > > I think that is completely open to implementation. In my eyes, Workflow > should remain a separate library that does not enforce any kind of specific > presentation or persistence. What's critical for that is of course the right > kind of interface. > Announcements would certainly be an interesting way to decouple Workflow > from other parts of the system. > > > Iâd like to have an incomingMessageBox for each user and eventually > transform these message in concrete action (user i/o) ? Or dispatch in > JobQueues (each user being a distant worker thread). Again, the distinction > between Scheduler and BPEngin is fuzzy to me. > > > Does it make sense to you ? > > Yes, it does :) What I've asked myself (out of curiosity) is whether you > want to have > - a dedicated instance for executing workflows > - a distributed workflow with autonomous synchronisation (parts of a > workflow could run on every uses instance, others would need to be executed > through agreement) > - a partially distributed workflow with one or more managing nodes that > control the core steps (e.g. you could designate parts of a workflow as > independant) > > > PS: some random comments on your proposals > > Parts of Workflow were never cleanly separated from the proprietary > application, so there are indeed a couple of things that are missing (mostly > #subclassResponsibility stuff etc.) > > > > - initializeDefaults is not present for steps but thats ok. > > > - in #createIncoming: (doesnât exist), I donât get â¦.. => makePersistent > asPersistentReference. You store persistentReference of steps. Is it like > the step object itself ? I would store the step objects (as no persistance > right now). > > An activity step is a specific subclass of a step. Such a step includes > additional information such as documents, duration and user roles. I'm not > sure why "makePersistent asPersistentReference" is sent there, as WfStep > already inherits from WfManagedObject and would, therefore, already be > managed by OmniBase. But I don't know OmniBase, maybe some things need to be > announced specifically. > > > - I donât understand the offsetSeconds in your BLActivationHistoryItem > > That's really just some business rule to modify the timestamp of the history > item. > > > ============= Others responses from Max > > WfWorkflow - Load and Run > All instances that inherit from WfManagedObject were managed by OmniBase, > yes. > DomBuilder is a small package for wrapping XML-Parser. I'll publish it so > you can use it. 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). > > > Those IDXXX classes belong to another package a didn't publish (but will). > This package also includes an OmniBase specific class. > Magritte has changed significantly over the years but the core should be > pretty much the same. Just load the newest Magritte and try working with > that. >> ok but avoidable ? >> try loading Magritte ? Long â¦ > > #beginInHistory should be implemented with #subclassResponsibility on > WfActivation. > Your explicit implementation could then look something like this: > beginInHistory > self history add: (MyActivationHistoryItem new > message: 'started'; > user: (WACurrentSession value > ifNotNilDo: [ :session | session user ]); > type: #started; > yourself). > MyMailManager noteNewActivation: self > > Basically, what the history contains is up to the workflow implementation. I > think it would makes sense though to have an abstract > WfActivationHistoryItem. > WfActivation>>history should be implemented like this: > history > ^self propertyAt: #history ifAbsentPut: [ OrderedCollection new ]. > > Although I think that it would be good to have a dedicated > WfActivationHistory class. WfWorkflowHistory is associated with changes to > the workflow, not activations. Both history classes should probably inherit > from an abstract class WFAbstractHistory. > > > Seaside interaction > > Here are a couple of action implementations in Seaside components that > should give you an idea of how to interact with the workflow: > MyActivationComponent>>complete > self activation hasCompleted > ifTrue: [ ^ self ]. > self history add: (BLActivationHistoryItem new > message: 'completed'; > user: self session user; > type: #completed; > offsetSeconds: -1; > yourself). > self activation complete. > > MyActivationForm>>accept: aString > self activation authorized: true. > self history add: (BLActivationHistoryItem new > comment: aString; > message: 'accepted'; > user: self session user; > type: #accepted; > offsetSeconds: -2; > yourself). > self completeIfSatisfied. > > MyActivityList>>addActivity > self call: (MyActivityEditor new > workflow: self workflow; > yourself). > self refresh. > > MyActivityEditor>>buildActivity > ^(self workflow newActivityStep > initializeDefaults; > yourself) > asPersistentReference. > > MyTransitionEditor>>createIncoming > | step | > step := (self workflow newActivityStep > initializeDefaults; > yourself) makePersistent asPersistentReference. > self addIncoming: step. > MyCurrentWorkflowComponent value showActivity: step. > > MyTransitionEditor>>addIncoming: anActivity > ^self add: anActivity to: self activity. > > MyTransitionEditor>>add: aSourceActivity to: aDestinationActivity > ^aSourceActivity addOutgoingEdgeFor: aDestinationActivity. > > MyTransitionEditor>>editCondtions: anEdge > | component | > anEdge condition isTrueCondition > ifTrue: [ anEdge condition: WfAllCondition new ]. > component := (MyConditionEditor activity: self activity) > container: anEdge; > addDecoration: (MyToolbarDecoration new > title: 'Edit Transition Conditions to: ' , anEdge to name; > toolbar: [ :html | > html > icon: 'icon_close.gif' > text: 'Close' > action: [ component answer ]. > html helpIconOn: component ]; > yourself); > yourself. > self call: component. > > MyConditionEditor>>addRule: aDescription > | new | > new := MyCondition newPersistent > field: aDescription; > asPersistentReference. > new := self call: (self > buildEditorFor: new > titled: 'Add Rule for ' , aDescription asLabel). > new isNil ifFalse: [ > self condition add: new; markDirty. > self changedForm ]. > > >> WfWorflowManager class is empty defining empty stubs/protocols. Its aim >> seems to be about âlogging/notingâ changes. Is is itâs only role ? > Correct. You would use WfWorkflowManager to update the workflow in OmniBase > (e.g. mark dirty, add new activation etc.). #generateID would generate an ID > from OmniBase and #activationClass would answer your specific activation > class, if you choose to override WfActivation. > Cool, thank you both for including your very valuable comments! I did my first experiment and have a script to start: | wf task1 task2 startStep frame | wf := WfWorkflowLibrary default workflowNamed: 'Test1'. task1 := wf newStepNamed: 'Step 1'. task2 := wf newStepNamed: 'Step 2'. startStep := wf start. startStep addOutgoingEdgeFor: task1. task1 addOutgoingEdgeFor: task2. frame := wf executeInNewFrame. frame workList running first complete. frame workList runningSteps. frame workList running first complete. frame workList runningSteps. wf To see how it matches with scientific workflows I will need more experiments. Cheers, HernÃ¡n

Jan. 21, 2018

Re: [Pharo-users] looking for another iterator :)

by Stephane Ducasse

I thought about something like that... SequenceableCollection >> atMax: numberOfItems do: aBlock "Execute the iteration with at the maximum numberOfItems. If the receiver contains less than numberOfItems iterate them all." 1 to: (numberOfItems min: self size) do: [:index | aBlock value: (self at: index)] This is an abstraction that we need to treat some samples. Stef On Sun, Jan 21, 2018 at 5:47 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Hi Ben and Clement > > I have a collection (a dictionary in my case) and I want to get > maximum 5 bindings out of it and iterate on them. > I want keysAndValuesDo: or do: but only up to 5 elements. > > aDict atMax: 5 do: [:each | ] > > So I learned from:to:do: > > aCollection atMax: 5 do: [:each | ] > > Does it make sense? > > Stef > > On Sun, Jan 21, 2018 at 1:16 PM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: >> I don't think we do. Do you need it on SequenceableCollection or >> HashedCollection too ? >> >> Recently I was trying to iterate over the first N elements of a collection >> and since there was no #first:do: I used #from:to:do:. I guess you could use >> that too: >> >> aCollection from: 1 to: (aCollection size min: 1000) do: aBlock >> >> Which guarantees you iterate at max over 1000 elements. But that API is >> SequenceableCollection specific. >> >> On Sun, Jan 21, 2018 at 11:44 AM, Ben Coman <btc(a)openinworld.com> wrote: >>> >>> On 21 January 2018 at 18:36, Stephane Ducasse <stepharo.self(a)gmail.com> >>> wrote: >>> > Hi >>> > >>> > I would like to iterate at max on a certain amount of elements in a >>> > collection. >>> > And I was wondering if we have such iterator. >>> >>> I'm not clear what functionality your asking for. Could you present >>> it as code & result if you assumed the iterator you want was >>> available? >>> >>> cheers -ben >>> >> >> >> >> -- >> ClÃ©ment BÃ©ra >> Pharo consortium engineer >> https://clementbera.wordpress.com/ >> BÃ¢timent B 40, avenue Halley 59650 Villeneuve d'Ascq

Jan. 21, 2018

Re: [Pharo-users] looking for another iterator :)

by Stephane Ducasse

Hi Ben and Clement I have a collection (a dictionary in my case) and I want to get maximum 5 bindings out of it and iterate on them. I want keysAndValuesDo: or do: but only up to 5 elements. aDict atMax: 5 do: [:each | ] So I learned from:to:do: aCollection atMax: 5 do: [:each | ] Does it make sense? Stef On Sun, Jan 21, 2018 at 1:16 PM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > I don't think we do. Do you need it on SequenceableCollection or > HashedCollection too ? > > Recently I was trying to iterate over the first N elements of a collection > and since there was no #first:do: I used #from:to:do:. I guess you could use > that too: > > aCollection from: 1 to: (aCollection size min: 1000) do: aBlock > > Which guarantees you iterate at max over 1000 elements. But that API is > SequenceableCollection specific. > > On Sun, Jan 21, 2018 at 11:44 AM, Ben Coman <btc(a)openinworld.com> wrote: >> >> On 21 January 2018 at 18:36, Stephane Ducasse <stepharo.self(a)gmail.com> >> wrote: >> > Hi >> > >> > I would like to iterate at max on a certain amount of elements in a >> > collection. >> > And I was wondering if we have such iterator. >> >> I'm not clear what functionality your asking for. Could you present >> it as code & result if you assumed the iterator you want was >> available? >> >> cheers -ben >> > > > > -- > ClÃ©ment BÃ©ra > Pharo consortium engineer > https://clementbera.wordpress.com/ > BÃ¢timent B 40, avenue Halley 59650 Villeneuve d'Ascq

Jan. 21, 2018

Re: [Pharo-users] Aare questions

by CÃ©drick BÃ©ler

> > > Cedrick > > My goal is one step at a time. > I do not want grand plan. Just something working in one image. Yes sure. But at this is an important requirement for me, I prefer to talk about it first :) > Stef > > On Sun, Jan 21, 2018 at 12:19 PM, CÃ©drick BÃ©ler <cdrick65(a)gmail.com> wrote: >> Besides all suggested ideas on the previous mail, whatâs very important to me is being able to run processes between several images considering 1 image = 1 actor. >> >> At first, we can consider both actor being on the same image (what Stephane wants first) but my requirement number 1 is having 1 actor by image and therefore having the possibility to trigger DistantSubWorkflow. >> >> Cheers, >> >> CÃ©drick >

Jan. 21, 2018

Re: [Pharo-users] [Moose-dev] Re: feenk log

by Tudor Girba

Hi, There is a difference in performance. The Announcement is slower (about 2-3x slower). However, for 1M events the difference is measured in a 200-400ms, which is very small. The benefit of using Announcement is that we can reuse the tooling around Announcement, such as blogging and debugging. Still, the way it is used in Bloc is different from the typical usage in that Bloc registers to all Events (which are Announcements) and then dispatches through them to specific Element method (like BlEventListener>>clickEvent:). Still the cool thing is that you also can still register from the outside to a specific event using a normal when:do:. We will write a piece of doc about it. Cheers, Tudor > On Jan 21, 2018, at 4:46 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > this looks really cool. > For the event I remember the discussion with glenn about the difference and I forgot. > > Stef > >> On 21 Jan 2018, at 15:54, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> >> Hi, >> >> Here is an update of the work on Bloc and GT. As always, please do let us know what you think. >> >> Bloc: >> - Eventing saw a deep overhaul. They are now dispatched using the Announcements engine. The previous mechanism is still in place in order to help people compare the impact. In the process, we also cleaned the propagation of events, and we made them debuggable through inspector extensions: >> https://twitter.com/feenkcom/status/955086133519618048 >> https://twitter.com/feenkcom/status/946482609680539649 >> - Embedding Bloc elements in Morphic is even easier now: >> https://twitter.com/feenkcom/status/946676667002556416 >> - We continued the work towards an interactive creation of a graphical scene: >> https://twitter.com/feenkcom/status/948492946541858816 >> - Theme experiment >> >> GT: >> - The documentation of Mondrian is available when you download the code and can be viewed using GT Documenter: >> https://twitter.com/feenkcom/status/939394586115563520 >> - The Mondrian extensions of BlElement are now extracted in a more general package that enables Bloc elements to be used in graph scenes. >> >> Have fun, >> The feenk team >> >> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "Obvious things are difficult to teach." >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)list.inf.unibe.ch >> https://www.list.inf.unibe.ch/listinfo/moose-dev > > -------------------------------------------- > StÃ©phane Ducasse > http://stephane.ducasse.free.fr > http://www.synectique.eu / http://www.pharo.org > 03 59 35 87 52 > Assistant: Julie Jonas > FAX 03 59 57 78 50 > TEL 03 59 35 86 16 > S. Ducasse - Inria > 40, avenue Halley, > Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza > Villeneuve d'Ascq 59650 > France > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev -- www.tudorgirba.com www.feenk.com "Beauty is where we see it."

Jan. 21, 2018

feenk log

by Tudor Girba

Hi, Here is an update of the work on Bloc and GT. As always, please do let us know what you think. Bloc: - Eventing saw a deep overhaul. They are now dispatched using the Announcements engine. The previous mechanism is still in place in order to help people compare the impact. In the process, we also cleaned the propagation of events, and we made them debuggable through inspector extensions: https://twitter.com/feenkcom/status/955086133519618048 https://twitter.com/feenkcom/status/946482609680539649 - Embedding Bloc elements in Morphic is even easier now: https://twitter.com/feenkcom/status/946676667002556416 - We continued the work towards an interactive creation of a graphical scene: https://twitter.com/feenkcom/status/948492946541858816 - Theme experiment GT: - The documentation of Mondrian is available when you download the code and can be viewed using GT Documenter: https://twitter.com/feenkcom/status/939394586115563520 - The Mondrian extensions of BlElement are now extracted in a more general package that enables Bloc elements to be used in graph scenes. Have fun, The feenk team -- www.tudorgirba.com www.feenk.com "Obvious things are difficult to teach."

Jan. 21, 2018

Re: [Pharo-users] Aare questions

by Stephane Ducasse

Now I got all the TestGraphs green by commenting the graphiz dependencies. On Sun, Jan 21, 2018 at 3:33 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > I got all the WfTestFlow green. > So now we can study the execution a bit better. > > On Sun, Jan 21, 2018 at 3:28 PM, Stephane Ducasse > <stepharo.self(a)gmail.com> wrote: >> HI cedrick >> >> >>> To solve this Â« pb Â», just create WADynamicVariable as a subclass of >>> DynamicVariable already in Pharo. >> >> Ok I will do it. What is important is to *share* knowledge and code. >> So I changed and publish the code in my branch to make >> CurrentWorkflowManager an dynamic variable. >> Before I just inherited from Object. >> Now we get a version that can be loaded. >> >> >> There are also missing part for the >>> export/import in XML (should be easy to fix and Max propose to give the code >>> - DOMBuilder and co.) >>> 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. :) >> >> >>> 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? >> >> Stef >> Some comments below >> >> >>> ========= INTRO >>> >>> What's missing compared to the full (proprietary) solution are user >>> interfaces that were web based (Seaside \+ Magritte). Also, persistence was >>> achived through Omnibase. References were removed but they are stil some >>> disfunctionning. Moreover, the completion of activities were mainly manual >>> and achieved through web interface (web forms). They are, for now, no real >>> way to introduce different kind of activities like those being >>> message-based, event-based, service-based. >>> >>> To evolve, one has to remove all dependancies to Omnibase and >>> Magritte/Seaside. >>> >>> There are also important design decisions to ensure WfWorkflow being a >>> powerful and extensible workflow management system for Pharo. To me there >>> are 2 main tasks: >>> - 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 >> - execute it and script it resolution. >> >> I would like to understand the difference between frame and activation. >> >>> ========= RANDOM QUESTIONS AND ANSWER (in black me - below max) >>> >>> 1) >>> >>> The static definition of workflow is done through WfWorkflow, WfOutgoingEdge >>> and WfSteps (+ WfConditions). The easy part :) >> >> Yes the easy part. >> I started to add a test to cover his >> >>> >>> The runtime aspect are achieved via WfActivation, WfWorkList, >>> WfWorkflowHistory et WfWorkflowManager. More difficult to understand and >>> make evolve. >>> >>> WfWorkflowHistory represents the different versions of a workflow, so it >>> belongs to the static part. >> >> I saw and documented the interaction between a workflow history and >> its workflows. >> >> >> 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. >> >>> >>> 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:). >>> >>> >>> 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. >> >> >>> 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 >> >> >>> The model does *allow* (in principle) to modify an existing workflow but I >>> doubt that was the intention. >> >> I think that it was because else why to bother. >> >> However, I don't see why modifying an existing >>> workflow has to be bad thing, as long as you can guarantee that only edges >>> and steps are modified that have not yet been activated. That could open up >>> some interesting possibilities. >>> Cancellation of an activation could be very interesting. It would basically >>> allow reversal of complex effects. Very nice idea! I'm not so sure though >>> whether suspending makes much sense. Maybe when a step has the potential to >>> take a long time for some operation. But then you may run into transaction >>> problems. The nice thing about an activation at the moment is that it's >>> atomic (in theory). But again, done right that could open up interesting >>> possibilities. >>> >>> >>> >>> If a running process is modified, do we track its evolutions in >>> WfWorkflowManager ? >>> >>> The modification of a workflow is indeed announced to WfWorkflowManager, >>> yes. Workflow versions are stored in WfWorkflowHistory. For modifying a >>> *running* workflow you will probably want to create a specific workflow >>> manager for that, that does validation etc. >>> >>> >>> >>> The goal of history(s) are to log the realization of the process. But is it >>> one of its aim to Â« replay Â» the process execution ? >>> >>> No. WfWorkflowHistory only stores the static definitions. However, the >>> history of activations could be used to replay an execution (nice idea!). >>> >>> i.o.w., Is it more than log/report ? >>> >>> I think the activation history was designed as a log, the workflow history >>> as a log and also as a way to undo changes. As you suggest, however, they >>> could certainly be used for more things. >>> >>> >>> I agree with the separation (WfWFManager for the run time evolution of the >>> process definition => adaptation and WfActivationHistory for the trace of >>> interactive/automatic step realizations information). >>> >>> >>> #beginHistory implementation example was very helpful. I knew I missed >>> something Just, as I see a MailManager (with role is obvious), is it >>> something that has to be generalizable ? Like InteroperableManager ? >>> MessageManager ? To get user interactions >>> >>> That would be very nice, yes. You're completely free to do what you like. It >>> would be cool though if we could evolve the project as opposed to you >>> creating a fork to your own liking. If you're game we can set up a workflow >>> on github where you open pull requests against our repository. >>> >>> >>> >>> 6) Iâd like to remove fully the reference and need of Omnibase and >>> Magritte/seaside forms. >>> >>> Yes please! >>> >>> >>> I think Omnibase is ok, even storing in image for instance. >>> >>> Whatâs more problematic to me is for user interactions (and even automatic >>> interaction through program for instance). There are achieved in your >>> example with seaside. It is ok but what if Iâd like to do it more generally >>> ? Would we use Annoucement for example ? >>> >>> I think that is completely open to implementation. In my eyes, Workflow >>> should remain a separate library that does not enforce any kind of specific >>> presentation or persistence. What's critical for that is of course the right >>> kind of interface. >>> Announcements would certainly be an interesting way to decouple Workflow >>> from other parts of the system. >>> >>> >>> Iâd like to have an incomingMessageBox for each user and eventually >>> transform these message in concrete action (user i/o) ? Or dispatch in >>> JobQueues (each user being a distant worker thread). Again, the distinction >>> between Scheduler and BPEngin is fuzzy to me. >>> >>> >>> Does it make sense to you ? >>> >>> Yes, it does :) What I've asked myself (out of curiosity) is whether you >>> want to have >>> - a dedicated instance for executing workflows >>> - a distributed workflow with autonomous synchronisation (parts of a >>> workflow could run on every uses instance, others would need to be executed >>> through agreement) >>> - a partially distributed workflow with one or more managing nodes that >>> control the core steps (e.g. you could designate parts of a workflow as >>> independant) >>> >>> >>> PS: some random comments on your proposals >>> >>> Parts of Workflow were never cleanly separated from the proprietary >>> application, so there are indeed a couple of things that are missing (mostly >>> #subclassResponsibility stuff etc.) >>> >>> >>> >>> - initializeDefaults is not present for steps but thats ok. >>> >>> >>> - in #createIncoming: (doesnât exist), I donât get â¦.. => makePersistent >>> asPersistentReference. You store persistentReference of steps. Is it like >>> the step object itself ? I would store the step objects (as no persistance >>> right now). >>> >>> An activity step is a specific subclass of a step. Such a step includes >>> additional information such as documents, duration and user roles. I'm not >>> sure why "makePersistent asPersistentReference" is sent there, as WfStep >>> already inherits from WfManagedObject and would, therefore, already be >>> managed by OmniBase. But I don't know OmniBase, maybe some things need to be >>> announced specifically. >>> >>> >>> - I donât understand the offsetSeconds in your BLActivationHistoryItem >>> >>> That's really just some business rule to modify the timestamp of the history >>> item. >>> >>> >>> ============= Others responses from Max >>> >>> WfWorkflow - Load and Run >>> All instances that inherit from WfManagedObject were managed by OmniBase, >>> yes. >>> DomBuilder is a small package for wrapping XML-Parser. I'll publish it so >>> you can use it. >> >> Cedric did you got this package? >> >> >> 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. >> >>> >>> >>> Those IDXXX classes belong to another package a didn't publish (but will). >>> This package also includes an OmniBase specific class. >>> Magritte has changed significantly over the years but the core should be >>> pretty much the same. Just load the newest Magritte and try working with >>> that. >>>> ok but avoidable ? >>>> try loading Magritte ? Long â¦ >>> >>> #beginInHistory should be implemented with #subclassResponsibility on >>> WfActivation. >>> Your explicit implementation could then look something like this: >>> beginInHistory >>> self history add: (MyActivationHistoryItem new >>> message: 'started'; >>> user: (WACurrentSession value >>> ifNotNilDo: [ :session | session user ]); >>> type: #started; >>> yourself). >>> MyMailManager noteNewActivation: self >>> >>> Basically, what the history contains is up to the workflow implementation. I >>> think it would makes sense though to have an abstract >>> WfActivationHistoryItem. >>> WfActivation>>history should be implemented like this: >>> history >>> ^self propertyAt: #history ifAbsentPut: [ OrderedCollection new ]. >>> >>> Although I think that it would be good to have a dedicated >>> WfActivationHistory class. WfWorkflowHistory is associated with changes to >>> the workflow, not activations. Both history classes should probably inherit >>> from an abstract class WFAbstractHistory. >>> >>> >>> Seaside interaction >>> >>> Here are a couple of action implementations in Seaside components that >>> should give you an idea of how to interact with the workflow: >>> MyActivationComponent>>complete >>> self activation hasCompleted >>> ifTrue: [ ^ self ]. >>> self history add: (BLActivationHistoryItem new >>> message: 'completed'; >>> user: self session user; >>> type: #completed; >>> offsetSeconds: -1; >>> yourself). >>> self activation complete. >>> >>> MyActivationForm>>accept: aString >>> self activation authorized: true. >>> self history add: (BLActivationHistoryItem new >>> comment: aString; >>> message: 'accepted'; >>> user: self session user; >>> type: #accepted; >>> offsetSeconds: -2; >>> yourself). >>> self completeIfSatisfied. >>> >>> MyActivityList>>addActivity >>> self call: (MyActivityEditor new >>> workflow: self workflow; >>> yourself). >>> self refresh. >>> >>> MyActivityEditor>>buildActivity >>> ^(self workflow newActivityStep >>> initializeDefaults; >>> yourself) >>> asPersistentReference. >>> >>> MyTransitionEditor>>createIncoming >>> | step | >>> step := (self workflow newActivityStep >>> initializeDefaults; >>> yourself) makePersistent asPersistentReference. >>> self addIncoming: step. >>> MyCurrentWorkflowComponent value showActivity: step. >>> >>> MyTransitionEditor>>addIncoming: anActivity >>> ^self add: anActivity to: self activity. >>> >>> MyTransitionEditor>>add: aSourceActivity to: aDestinationActivity >>> ^aSourceActivity addOutgoingEdgeFor: aDestinationActivity. >>> >>> MyTransitionEditor>>editCondtions: anEdge >>> | component | >>> anEdge condition isTrueCondition >>> ifTrue: [ anEdge condition: WfAllCondition new ]. >>> component := (MyConditionEditor activity: self activity) >>> container: anEdge; >>> addDecoration: (MyToolbarDecoration new >>> title: 'Edit Transition Conditions to: ' , anEdge to name; >>> toolbar: [ :html | >>> html >>> icon: 'icon_close.gif' >>> text: 'Close' >>> action: [ component answer ]. >>> html helpIconOn: component ]; >>> yourself); >>> yourself. >>> self call: component. >>> >>> MyConditionEditor>>addRule: aDescription >>> | new | >>> new := MyCondition newPersistent >>> field: aDescription; >>> asPersistentReference. >>> new := self call: (self >>> buildEditorFor: new >>> titled: 'Add Rule for ' , aDescription asLabel). >>> new isNil ifFalse: [ >>> self condition add: new; markDirty. >>> self changedForm ]. >>> >>> >>>> WfWorflowManager class is empty defining empty stubs/protocols. Its aim >>>> seems to be about âlogging/notingâ changes. Is is itâs only role ? >>> Correct. You would use WfWorkflowManager to update the workflow in OmniBase >>> (e.g. mark dirty, add new activation etc.). #generateID would generate an ID >>> from OmniBase and #activationClass would answer your specific activation >>> class, if you choose to override WfActivation. >>>

Jan. 21, 2018

Re: [Pharo-users] Aare questions

by Stephane Ducasse

I got all the WfTestFlow green. So now we can study the execution a bit better. On Sun, Jan 21, 2018 at 3:28 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > HI cedrick > > >> To solve this Â« pb Â», just create WADynamicVariable as a subclass of >> DynamicVariable already in Pharo. > > Ok I will do it. What is important is to *share* knowledge and code. > So I changed and publish the code in my branch to make > CurrentWorkflowManager an dynamic variable. > Before I just inherited from Object. > Now we get a version that can be loaded. > > > There are also missing part for the >> export/import in XML (should be easy to fix and Max propose to give the code >> - DOMBuilder and co.) >> 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. :) > > >> 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? > > Stef > Some comments below > > >> ========= INTRO >> >> What's missing compared to the full (proprietary) solution are user >> interfaces that were web based (Seaside \+ Magritte). Also, persistence was >> achived through Omnibase. References were removed but they are stil some >> disfunctionning. Moreover, the completion of activities were mainly manual >> and achieved through web interface (web forms). They are, for now, no real >> way to introduce different kind of activities like those being >> message-based, event-based, service-based. >> >> To evolve, one has to remove all dependancies to Omnibase and >> Magritte/Seaside. >> >> There are also important design decisions to ensure WfWorkflow being a >> powerful and extensible workflow management system for Pharo. To me there >> are 2 main tasks: >> - 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 > - execute it and script it resolution. > > I would like to understand the difference between frame and activation. > >> ========= RANDOM QUESTIONS AND ANSWER (in black me - below max) >> >> 1) >> >> The static definition of workflow is done through WfWorkflow, WfOutgoingEdge >> and WfSteps (+ WfConditions). The easy part :) > > Yes the easy part. > I started to add a test to cover his > >> >> The runtime aspect are achieved via WfActivation, WfWorkList, >> WfWorkflowHistory et WfWorkflowManager. More difficult to understand and >> make evolve. >> >> WfWorkflowHistory represents the different versions of a workflow, so it >> belongs to the static part. > > I saw and documented the interaction between a workflow history and > its workflows. > > > 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. > >> >> 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:). >> >> >> 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. > > >> 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 > > >> The model does *allow* (in principle) to modify an existing workflow but I >> doubt that was the intention. > > I think that it was because else why to bother. > > However, I don't see why modifying an existing >> workflow has to be bad thing, as long as you can guarantee that only edges >> and steps are modified that have not yet been activated. That could open up >> some interesting possibilities. >> Cancellation of an activation could be very interesting. It would basically >> allow reversal of complex effects. Very nice idea! I'm not so sure though >> whether suspending makes much sense. Maybe when a step has the potential to >> take a long time for some operation. But then you may run into transaction >> problems. The nice thing about an activation at the moment is that it's >> atomic (in theory). But again, done right that could open up interesting >> possibilities. >> >> >> >> If a running process is modified, do we track its evolutions in >> WfWorkflowManager ? >> >> The modification of a workflow is indeed announced to WfWorkflowManager, >> yes. Workflow versions are stored in WfWorkflowHistory. For modifying a >> *running* workflow you will probably want to create a specific workflow >> manager for that, that does validation etc. >> >> >> >> The goal of history(s) are to log the realization of the process. But is it >> one of its aim to Â« replay Â» the process execution ? >> >> No. WfWorkflowHistory only stores the static definitions. However, the >> history of activations could be used to replay an execution (nice idea!). >> >> i.o.w., Is it more than log/report ? >> >> I think the activation history was designed as a log, the workflow history >> as a log and also as a way to undo changes. As you suggest, however, they >> could certainly be used for more things. >> >> >> I agree with the separation (WfWFManager for the run time evolution of the >> process definition => adaptation and WfActivationHistory for the trace of >> interactive/automatic step realizations information). >> >> >> #beginHistory implementation example was very helpful. I knew I missed >> something Just, as I see a MailManager (with role is obvious), is it >> something that has to be generalizable ? Like InteroperableManager ? >> MessageManager ? To get user interactions >> >> That would be very nice, yes. You're completely free to do what you like. It >> would be cool though if we could evolve the project as opposed to you >> creating a fork to your own liking. If you're game we can set up a workflow >> on github where you open pull requests against our repository. >> >> >> >> 6) Iâd like to remove fully the reference and need of Omnibase and >> Magritte/seaside forms. >> >> Yes please! >> >> >> I think Omnibase is ok, even storing in image for instance. >> >> Whatâs more problematic to me is for user interactions (and even automatic >> interaction through program for instance). There are achieved in your >> example with seaside. It is ok but what if Iâd like to do it more generally >> ? Would we use Annoucement for example ? >> >> I think that is completely open to implementation. In my eyes, Workflow >> should remain a separate library that does not enforce any kind of specific >> presentation or persistence. What's critical for that is of course the right >> kind of interface. >> Announcements would certainly be an interesting way to decouple Workflow >> from other parts of the system. >> >> >> Iâd like to have an incomingMessageBox for each user and eventually >> transform these message in concrete action (user i/o) ? Or dispatch in >> JobQueues (each user being a distant worker thread). Again, the distinction >> between Scheduler and BPEngin is fuzzy to me. >> >> >> Does it make sense to you ? >> >> Yes, it does :) What I've asked myself (out of curiosity) is whether you >> want to have >> - a dedicated instance for executing workflows >> - a distributed workflow with autonomous synchronisation (parts of a >> workflow could run on every uses instance, others would need to be executed >> through agreement) >> - a partially distributed workflow with one or more managing nodes that >> control the core steps (e.g. you could designate parts of a workflow as >> independant) >> >> >> PS: some random comments on your proposals >> >> Parts of Workflow were never cleanly separated from the proprietary >> application, so there are indeed a couple of things that are missing (mostly >> #subclassResponsibility stuff etc.) >> >> >> >> - initializeDefaults is not present for steps but thats ok. >> >> >> - in #createIncoming: (doesnât exist), I donât get â¦.. => makePersistent >> asPersistentReference. You store persistentReference of steps. Is it like >> the step object itself ? I would store the step objects (as no persistance >> right now). >> >> An activity step is a specific subclass of a step. Such a step includes >> additional information such as documents, duration and user roles. I'm not >> sure why "makePersistent asPersistentReference" is sent there, as WfStep >> already inherits from WfManagedObject and would, therefore, already be >> managed by OmniBase. But I don't know OmniBase, maybe some things need to be >> announced specifically. >> >> >> - I donât understand the offsetSeconds in your BLActivationHistoryItem >> >> That's really just some business rule to modify the timestamp of the history >> item. >> >> >> ============= Others responses from Max >> >> WfWorkflow - Load and Run >> All instances that inherit from WfManagedObject were managed by OmniBase, >> yes. >> DomBuilder is a small package for wrapping XML-Parser. I'll publish it so >> you can use it. > > Cedric did you got this package? > > > 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. > >> >> >> Those IDXXX classes belong to another package a didn't publish (but will). >> This package also includes an OmniBase specific class. >> Magritte has changed significantly over the years but the core should be >> pretty much the same. Just load the newest Magritte and try working with >> that. >>> ok but avoidable ? >>> try loading Magritte ? Long â¦ >> >> #beginInHistory should be implemented with #subclassResponsibility on >> WfActivation. >> Your explicit implementation could then look something like this: >> beginInHistory >> self history add: (MyActivationHistoryItem new >> message: 'started'; >> user: (WACurrentSession value >> ifNotNilDo: [ :session | session user ]); >> type: #started; >> yourself). >> MyMailManager noteNewActivation: self >> >> Basically, what the history contains is up to the workflow implementation. I >> think it would makes sense though to have an abstract >> WfActivationHistoryItem. >> WfActivation>>history should be implemented like this: >> history >> ^self propertyAt: #history ifAbsentPut: [ OrderedCollection new ]. >> >> Although I think that it would be good to have a dedicated >> WfActivationHistory class. WfWorkflowHistory is associated with changes to >> the workflow, not activations. Both history classes should probably inherit >> from an abstract class WFAbstractHistory. >> >> >> Seaside interaction >> >> Here are a couple of action implementations in Seaside components that >> should give you an idea of how to interact with the workflow: >> MyActivationComponent>>complete >> self activation hasCompleted >> ifTrue: [ ^ self ]. >> self history add: (BLActivationHistoryItem new >> message: 'completed'; >> user: self session user; >> type: #completed; >> offsetSeconds: -1; >> yourself). >> self activation complete. >> >> MyActivationForm>>accept: aString >> self activation authorized: true. >> self history add: (BLActivationHistoryItem new >> comment: aString; >> message: 'accepted'; >> user: self session user; >> type: #accepted; >> offsetSeconds: -2; >> yourself). >> self completeIfSatisfied. >> >> MyActivityList>>addActivity >> self call: (MyActivityEditor new >> workflow: self workflow; >> yourself). >> self refresh. >> >> MyActivityEditor>>buildActivity >> ^(self workflow newActivityStep >> initializeDefaults; >> yourself) >> asPersistentReference. >> >> MyTransitionEditor>>createIncoming >> | step | >> step := (self workflow newActivityStep >> initializeDefaults; >> yourself) makePersistent asPersistentReference. >> self addIncoming: step. >> MyCurrentWorkflowComponent value showActivity: step. >> >> MyTransitionEditor>>addIncoming: anActivity >> ^self add: anActivity to: self activity. >> >> MyTransitionEditor>>add: aSourceActivity to: aDestinationActivity >> ^aSourceActivity addOutgoingEdgeFor: aDestinationActivity. >> >> MyTransitionEditor>>editCondtions: anEdge >> | component | >> anEdge condition isTrueCondition >> ifTrue: [ anEdge condition: WfAllCondition new ]. >> component := (MyConditionEditor activity: self activity) >> container: anEdge; >> addDecoration: (MyToolbarDecoration new >> title: 'Edit Transition Conditions to: ' , anEdge to name; >> toolbar: [ :html | >> html >> icon: 'icon_close.gif' >> text: 'Close' >> action: [ component answer ]. >> html helpIconOn: component ]; >> yourself); >> yourself. >> self call: component. >> >> MyConditionEditor>>addRule: aDescription >> | new | >> new := MyCondition newPersistent >> field: aDescription; >> asPersistentReference. >> new := self call: (self >> buildEditorFor: new >> titled: 'Add Rule for ' , aDescription asLabel). >> new isNil ifFalse: [ >> self condition add: new; markDirty. >> self changedForm ]. >> >> >>> WfWorflowManager class is empty defining empty stubs/protocols. Its aim >>> seems to be about âlogging/notingâ changes. Is is itâs only role ? >> Correct. You would use WfWorkflowManager to update the workflow in OmniBase >> (e.g. mark dirty, add new activation etc.). #generateID would generate an ID >> from OmniBase and #activationClass would answer your specific activation >> class, if you choose to override WfActivation. >>

Jan. 21, 2018

Re: [Pharo-users] Aare questions

by Stephane Ducasse

HI cedrick > To solve this Â« pb Â», just create WADynamicVariable as a subclass of > DynamicVariable already in Pharo. Ok I will do it. What is important is to *share* knowledge and code. So I changed and publish the code in my branch to make CurrentWorkflowManager an dynamic variable. Before I just inherited from Object. Now we get a version that can be loaded. There are also missing part for the > export/import in XML (should be easy to fix and Max propose to give the code > - DOMBuilder and co.) > 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. :) > 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? Stef Some comments below > ========= INTRO > > What's missing compared to the full (proprietary) solution are user > interfaces that were web based (Seaside \+ Magritte). Also, persistence was > achived through Omnibase. References were removed but they are stil some > disfunctionning. Moreover, the completion of activities were mainly manual > and achieved through web interface (web forms). They are, for now, no real > way to introduce different kind of activities like those being > message-based, event-based, service-based. > > To evolve, one has to remove all dependancies to Omnibase and > Magritte/Seaside. > > There are also important design decisions to ensure WfWorkflow being a > powerful and extensible workflow management system for Pharo. To me there > are 2 main tasks: > - 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 - execute it and script it resolution. I would like to understand the difference between frame and activation. > ========= RANDOM QUESTIONS AND ANSWER (in black me - below max) > > 1) > > The static definition of workflow is done through WfWorkflow, WfOutgoingEdge > and WfSteps (+ WfConditions). The easy part :) Yes the easy part. I started to add a test to cover his > > The runtime aspect are achieved via WfActivation, WfWorkList, > WfWorkflowHistory et WfWorkflowManager. More difficult to understand and > make evolve. > > WfWorkflowHistory represents the different versions of a workflow, so it > belongs to the static part. I saw and documented the interaction between a workflow history and its workflows. 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. > > 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:). > > > 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. > 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 > The model does *allow* (in principle) to modify an existing workflow but I > doubt that was the intention. I think that it was because else why to bother. However, I don't see why modifying an existing > workflow has to be bad thing, as long as you can guarantee that only edges > and steps are modified that have not yet been activated. That could open up > some interesting possibilities. > Cancellation of an activation could be very interesting. It would basically > allow reversal of complex effects. Very nice idea! I'm not so sure though > whether suspending makes much sense. Maybe when a step has the potential to > take a long time for some operation. But then you may run into transaction > problems. The nice thing about an activation at the moment is that it's > atomic (in theory). But again, done right that could open up interesting > possibilities. > > > > If a running process is modified, do we track its evolutions in > WfWorkflowManager ? > > The modification of a workflow is indeed announced to WfWorkflowManager, > yes. Workflow versions are stored in WfWorkflowHistory. For modifying a > *running* workflow you will probably want to create a specific workflow > manager for that, that does validation etc. > > > > The goal of history(s) are to log the realization of the process. But is it > one of its aim to Â« replay Â» the process execution ? > > No. WfWorkflowHistory only stores the static definitions. However, the > history of activations could be used to replay an execution (nice idea!). > > i.o.w., Is it more than log/report ? > > I think the activation history was designed as a log, the workflow history > as a log and also as a way to undo changes. As you suggest, however, they > could certainly be used for more things. > > > I agree with the separation (WfWFManager for the run time evolution of the > process definition => adaptation and WfActivationHistory for the trace of > interactive/automatic step realizations information). > > > #beginHistory implementation example was very helpful. I knew I missed > something Just, as I see a MailManager (with role is obvious), is it > something that has to be generalizable ? Like InteroperableManager ? > MessageManager ? To get user interactions > > That would be very nice, yes. You're completely free to do what you like. It > would be cool though if we could evolve the project as opposed to you > creating a fork to your own liking. If you're game we can set up a workflow > on github where you open pull requests against our repository. > > > > 6) Iâd like to remove fully the reference and need of Omnibase and > Magritte/seaside forms. > > Yes please! > > > I think Omnibase is ok, even storing in image for instance. > > Whatâs more problematic to me is for user interactions (and even automatic > interaction through program for instance). There are achieved in your > example with seaside. It is ok but what if Iâd like to do it more generally > ? Would we use Annoucement for example ? > > I think that is completely open to implementation. In my eyes, Workflow > should remain a separate library that does not enforce any kind of specific > presentation or persistence. What's critical for that is of course the right > kind of interface. > Announcements would certainly be an interesting way to decouple Workflow > from other parts of the system. > > > Iâd like to have an incomingMessageBox for each user and eventually > transform these message in concrete action (user i/o) ? Or dispatch in > JobQueues (each user being a distant worker thread). Again, the distinction > between Scheduler and BPEngin is fuzzy to me. > > > Does it make sense to you ? > > Yes, it does :) What I've asked myself (out of curiosity) is whether you > want to have > - a dedicated instance for executing workflows > - a distributed workflow with autonomous synchronisation (parts of a > workflow could run on every uses instance, others would need to be executed > through agreement) > - a partially distributed workflow with one or more managing nodes that > control the core steps (e.g. you could designate parts of a workflow as > independant) > > > PS: some random comments on your proposals > > Parts of Workflow were never cleanly separated from the proprietary > application, so there are indeed a couple of things that are missing (mostly > #subclassResponsibility stuff etc.) > > > > - initializeDefaults is not present for steps but thats ok. > > > - in #createIncoming: (doesnât exist), I donât get â¦.. => makePersistent > asPersistentReference. You store persistentReference of steps. Is it like > the step object itself ? I would store the step objects (as no persistance > right now). > > An activity step is a specific subclass of a step. Such a step includes > additional information such as documents, duration and user roles. I'm not > sure why "makePersistent asPersistentReference" is sent there, as WfStep > already inherits from WfManagedObject and would, therefore, already be > managed by OmniBase. But I don't know OmniBase, maybe some things need to be > announced specifically. > > > - I donât understand the offsetSeconds in your BLActivationHistoryItem > > That's really just some business rule to modify the timestamp of the history > item. > > > ============= Others responses from Max > > WfWorkflow - Load and Run > All instances that inherit from WfManagedObject were managed by OmniBase, > yes. > DomBuilder is a small package for wrapping XML-Parser. I'll publish it so > you can use it. Cedric did you got this package? 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. > > > Those IDXXX classes belong to another package a didn't publish (but will). > This package also includes an OmniBase specific class. > Magritte has changed significantly over the years but the core should be > pretty much the same. Just load the newest Magritte and try working with > that. >> ok but avoidable ? >> try loading Magritte ? Long â¦ > > #beginInHistory should be implemented with #subclassResponsibility on > WfActivation. > Your explicit implementation could then look something like this: > beginInHistory > self history add: (MyActivationHistoryItem new > message: 'started'; > user: (WACurrentSession value > ifNotNilDo: [ :session | session user ]); > type: #started; > yourself). > MyMailManager noteNewActivation: self > > Basically, what the history contains is up to the workflow implementation. I > think it would makes sense though to have an abstract > WfActivationHistoryItem. > WfActivation>>history should be implemented like this: > history > ^self propertyAt: #history ifAbsentPut: [ OrderedCollection new ]. > > Although I think that it would be good to have a dedicated > WfActivationHistory class. WfWorkflowHistory is associated with changes to > the workflow, not activations. Both history classes should probably inherit > from an abstract class WFAbstractHistory. > > > Seaside interaction > > Here are a couple of action implementations in Seaside components that > should give you an idea of how to interact with the workflow: > MyActivationComponent>>complete > self activation hasCompleted > ifTrue: [ ^ self ]. > self history add: (BLActivationHistoryItem new > message: 'completed'; > user: self session user; > type: #completed; > offsetSeconds: -1; > yourself). > self activation complete. > > MyActivationForm>>accept: aString > self activation authorized: true. > self history add: (BLActivationHistoryItem new > comment: aString; > message: 'accepted'; > user: self session user; > type: #accepted; > offsetSeconds: -2; > yourself). > self completeIfSatisfied. > > MyActivityList>>addActivity > self call: (MyActivityEditor new > workflow: self workflow; > yourself). > self refresh. > > MyActivityEditor>>buildActivity > ^(self workflow newActivityStep > initializeDefaults; > yourself) > asPersistentReference. > > MyTransitionEditor>>createIncoming > | step | > step := (self workflow newActivityStep > initializeDefaults; > yourself) makePersistent asPersistentReference. > self addIncoming: step. > MyCurrentWorkflowComponent value showActivity: step. > > MyTransitionEditor>>addIncoming: anActivity > ^self add: anActivity to: self activity. > > MyTransitionEditor>>add: aSourceActivity to: aDestinationActivity > ^aSourceActivity addOutgoingEdgeFor: aDestinationActivity. > > MyTransitionEditor>>editCondtions: anEdge > | component | > anEdge condition isTrueCondition > ifTrue: [ anEdge condition: WfAllCondition new ]. > component := (MyConditionEditor activity: self activity) > container: anEdge; > addDecoration: (MyToolbarDecoration new > title: 'Edit Transition Conditions to: ' , anEdge to name; > toolbar: [ :html | > html > icon: 'icon_close.gif' > text: 'Close' > action: [ component answer ]. > html helpIconOn: component ]; > yourself); > yourself. > self call: component. > > MyConditionEditor>>addRule: aDescription > | new | > new := MyCondition newPersistent > field: aDescription; > asPersistentReference. > new := self call: (self > buildEditorFor: new > titled: 'Add Rule for ' , aDescription asLabel). > new isNil ifFalse: [ > self condition add: new; markDirty. > self changedForm ]. > > >> WfWorflowManager class is empty defining empty stubs/protocols. Its aim >> seems to be about âlogging/notingâ changes. Is is itâs only role ? > Correct. You would use WfWorkflowManager to update the workflow in OmniBase > (e.g. mark dirty, add new activation etc.). #generateID would generate an ID > from OmniBase and #activationClass would answer your specific activation > class, if you choose to override WfActivation. >

Jan. 21, 2018

Re: [Pharo-users] Pharo 7 image cannot write changes message on startup

by Alistair Grant

On 21 January 2018 at 15:14, Sanjay Minni <sm(a)planage.com> wrote: > The message "... cannot write changes ... check that you have write > permissions ..." is still there but I I install packages I can see .changes > file increasing in size Right. This isn't a fix, it just opens the files after the initial attempt fails. Cheers, Alistair > regards > Sanjay > > > Alistair Grant wrote >> Hi Sanjay, >> >> On 21 January 2018 at 12:10, Sanjay Minni < > >> sm@ > >> > wrote: >>> Hullo >>> >>> Can someone help with fixing this issue, >>> I am unable to use Pharo 7 image on windows 10 till this is done >> >> I'm not regularly using Windows, but a workaround is to create a >> startup file with: >> >> SourceFiles close; ensureOpen >> >> in it. >> >> Cheers, >> Alistair > > > > > > ----- > --- > Regards, Sanjay > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >

Jan. 21, 2018

← Newer
1
...
13
14
15
16
17
18
19
...
46
Older →

Jump to page: