> Am 27.09.2019 um 10:10 schrieb Tim Mackinnon <tim@testit.works>:
>
> If this does become of interest to anyone, I had a quick look at the workflow
> landscape in Pharo and found it rather unfathomable - Netsyle seems very
> comprehensive but complicated and lacking syntactic sugar to make it easy to
> just pick up and run with. It’s reified up the hilt, so simple stuff seems to
> need lots of code, which the examples emphasise.
>
> NewWave has a great readme.md, so quickly got some initial concepts but it’s
> very work in progress and key base classes have no documentation so it’s not
> easy to understand what does what for more detailed things (Sebastijan did
> respond quickly to some questions, so hope to see it continue to improve). It
> looked promising but it seems to want to “own the flow” and run everything,
> so my Teapot endpoints couldn’t easily get the next workflow from the engine
> - the engine wanted to push things to me (I messed with a semaphore to try
> and sync things, but decided it’s ethos was just different - I think the
> netstyle engine would let me pull, but didn’t get that far with it).
>
> There was a gemstone workflow engine - it’s not ported, it looked interesting
> but used a Windows bpml tool and again wasn’t sure if it wanted to own the
> world, and porting it would be more than I wanted to do.
>
> After an hour, I went with my own domain model and some condition blocks to
> just get something going. Teapot and NeoJsonWriter really let you prototype
> quickly! Had something in 15 mins to let me mull over the problem.
>
That‘s where most „workflow engines“ start _and_ end ;)
Workflow engines are simple if the flow is simple. Most people come up with a
simple sequence of tasks. To do it properly with all the fork and join
possibilities is not that easy.
I think the Netstyle engine is kind of ok but never got past the point where
seaside dependencies and Omnibase dependencies were properly refactored to be
independent of its roots.
NewWave is the new trial. We are talking with the guys to help build a decent
machine. At ESUG we talked more than an hour about approaches. The last thing
we acknowledged was to create a mailing list for it to make the discussion more
public. Stef wanted it to happen on this list but I think a dedicated one would
be better. So we are trying to find a place for the list.
Marcus, I think we got stuck in the process finding a proper mailing list
provider, right?
Norbert
> Tim
>
> Sent from my iPhone
>
>> On 26 Sep 2019, at 09:12, Tim Mackinnon <tim@testit.works> wrote:
>>
>> Hi everyone, in my day job I encountered an interesting domain problem that
>> a previous java team has made a bit of a hash of ...
>>
>> I thought it might be interesting to model it in Pharo to help explain it
>> better to a new team and I was interested in community thoughts as we have
>> some of the best thinkers on tap.
>>
>> The scenario is that a user is presented with several input fields to apply
>> for a loan , one of them is Amount and another the type of loan (cash,
>> invoice, machinery etc).
>>
>> Depending on these answers, they are next presented with different questions
>> - if the amount > 100k there are some high value questions, if the loan type
>> is machinery there are some more additional questions on the type of machine
>> etc. This progresses to a third form and potentially a 4th and 5th.
>>
>> So it’s effectively a decision tree, that rules out different loan types.
>>
>> The UI is a React web form, and I’ve suggested to the team to do some
>> experiments with a dynamic UI that interprets a Json payload that describes
>> the questions, so it’s really about how to model the questions and then
>> render them out in this Json format.
>>
>> I was wondering if this was a typical workflow problem (and whether the
>> netstyle engine was appropriate or wasn’t there some other ones announced
>> recently too?)
>>
>> I’ve never used a workflow engine - But it sounds a bit like the problem
>> above? Or not?
>>
>> Alternatively, I was thinking I could model groups of questions into a
>> Decision, and then have a DecisionJourney of Decisions. Each decision could
>> have some match and dependency criteria - e.g. some sort of matcher block eg
>> [:d | d amount > 100 & d type = #machinery] and then some method to add
>> questions to a DecisionForm on a match which would then render the Json
>> payload.
>>
>> But I wondered if workflow engines just do this, and they might handle extra
>> stuff for free.
>>
>> Anyone have any thoughts or directions to explore?
>>
>> Tim
>>
>> Sent from my iPhone
>>
>
>
