the flor language
Flor is a language for defining workflows for the flor workflow engine.
A flor engine is an interpreter for the flor language. Usually an interpreter lives in an OS process and interprets a single program. With a flor engine, there are multiple program instances, called workflow executions, being interpreted in the same engine. Flor can host multiple executions of the same workflow definition or executions of various, different, workflow definitions. They could be various versions of the same workflow definition, or even executions whose definitions diverged in-flight from their original definition (rewriting the program in-flight).
Executions route work between taskers. Taskers are orthogonal to workflow definitions/executions. Multiple definitions/executions share the same set of taskers. For example the "accounting department" tasker or the "send notification email" tasker may appear in multiple workflow definitions (in the same business domain usually).
Executions spend most of their time waiting for taskers' answers, especially if those taskers are human.
This meandering post tries to show what flor, the language, looks like, and to explain the motivations behind that. This post doesn't look at tasker implementation, it is sufficient to know that they are scripts (Ruby or not) accepting task messages and replying with an updated task payload or rejecting the task.
the language itself
Here is a sample flor workflow definition:
sequence set item_id # the launch data is used create_mandate _ # to create a new mandate cursor ops 'assign container number' # operations team update_mandate status: f.status # ops decides on status break _ if f.status == 'numbered' # break out of cursor if 'numbered' rm 'rework mandate' # relationship manager update_mandate status: 'agreed' # refines mandate data continue _ # mandate goes back to operations... pfs 'activate mandate' # portfolio team update_mandate status: 'active' # activates the mandate email 'rm' 'awm mandate activated' # success, email sent to rel manager
A few observations:
- It is indented
- There are no end of indentation levels, a leftward indentation change ends one or more indentation blocks, a rightward indentation change starts a new indentation block, it's like Python
- Lines begin with a word followed by arguments
- Arguments are strings or key: value entries, or sometimes
- Comments start with a
#sign and end with the end of their line
- The head of line word sometimes is an imperative (set, break, update_mandate, email, ...), sometimes a noun (sequence, rm, ...)
- Like in Ruby, some lines end in a condition, for example:
break _ if f.status == 'numbered'
A few answers:
Each non-comment line is a "call" of the head-of-line word procedure
Some of those heads are common flor procedures (set, sequence, cursor, break, continue, ...)
Some of those heads are taskers (pieces of code registered in the flor engine and available to multiple flor definitions), here, for example, "rm", "ops" and "pfs" point to three distinct group in the organization using the flor engine, they are "human taskers"
Some of those heads are taskers pointing to non-human taskers, like "email" and "update_mandate", such taskers tend to perform their task immediately, while human taskers are usually delivering the task to a queue/list system where humans may pick them (and drop them back eventually)
Some of those heads could be functions (sorry, no function calls in the example above).
The suffix conditionals are in fact syntactic sugar:
break _ if f.status == 'numbered' # # gets rewritten to: # if f.status == 'numbered' # conditional break _ # then branch # nada... # else branch
Such rewrites occur when the flow reaches the break/if, not before.
_ (underscore) as a single argument is necessary to distinguish getting the value of a head from calling it.
define get-name "Hector" get-name # yields a pointer to the "get-name" function get-name _ # yields "Hector"
Yielding a pointer to a function has its uses, for example, when aliasing it:
define add x y \ + x y set plus add # alias plus to add plus 1 2 # yields 3 set plus # set plus add 2 3 # to the value of `(add 2 3)`, yields 5 plus 3 4 # yields 5, not 7
why such a language?
Like all programming languages, flor sits between the user and the interpreter. It has to be understood by the interpreter (fairly easy) and by the user (difficult) and his co-workers (even more difficult).
Please note that I describe flor as a "workflow engine", not a "business process management suite". I am not really targetting business users, I am targetting fellow developers. Funnily, for most developpers, a workflow is in the realm of "my workflow", the set of ways in which they weave their work, all alone. Granted sometimes, there are team workflows, but there are much more blog posts about "my development workflow" out there than about team workflows.
Still, why not use BPMN? I prefer a text programming language to a visual programming language. I could go christian and say "In the beginning was the word", not the diagram. I also do not think that a diagram is not a program, there is no "no code", a workflow definition, text or diagram, is a piece of code. Most diagrams out there are backed by textual notations, we're back to word, text.
The basic blocks in a programming language come most of the time straight out of the English language: GOTO, if, car, cdr, RETF, whatever... We strive to have programs reading like English. If I target developers, I have not to forget that they'll be sharing those programs, those workflow definitions, with business users. It'd better be readable.
As already written, the flor language essentially routes work among taskers. Concise definitions should be readable. Throwing the work over the wall to a tasker should hide/abstract most of the complexity, then flor allows for functions, a classical way to abstract details away, flor then routes work among taskers and functions. The way a tasker is called is similar to the way a function is called: tasker name or function name, followed by arguments.
define phase1 concurrence alice 'call A-N customers' bob 'call M-Z customers' define phase2 sequence alice 'get customer confirmation' bob 'do something else' sequence phase1 _ # function call phase2 _ # function call charly 'final phase' # tasker invocation #verb_or_noun arguments* # verb_or_noun arguments*
I am not against diagrams, I think they are great to provide the coup d'oeil that business users want. My language should lend itself to (semi-)automatic generation of diagrams. If "technical details" are hidden behind abstractions, meaningful diagram generation should be possible.
It still takes discipline to write readable flow definitions or to write graspable BPMN diagrams.
a Lisp bastard
Flor is a Lisp bastard, one of those that lost the parentheses. A word on its own is replaced by the value it stands for. A word is followed by arguments and we have a function call or a tasker invocation, or simply a procedure call.
The 10th Greenspun rule needn't apply, I am deliberately bringing a Lisp to the table. Granted, "bug-ridden", "slow" and "half-complete" may still hold.
If Lisp is the mother, who's the father? Ruby for sure.
# Lispish # map [ 1, 2, 3 ] # def elt # + elt 3 # "map" accepts a function # Rubyish # collect [ 1, 2, 3 ] # + elt 3 # while "collect" is a macro rewriting to a "map" # both yield [ 4, 5, 6 ]
Surely, using flor to add 3 to a sequence of integers is a waste. Here is maybe a better example:
define notify_warranty_void users # set emails # users # collect # elt.email # collect the email for each user into "emails" notify emails "warranty void" # call to function "notify" # # OR # notify (users | collect \ elt.email) "warranty void" # as a one-liner
There is a list of the flor procedures, sorry, it doesn't contain "car" or "cdr" for the time being.
Why a Lisp bastard for defining workflows? I could answer that it's because I got taught about programming with the Wizard Book, but it's rather my wish for a language close to its symbolic expressions. I want this
(verb_or_noun arguments*) structure.
It can be said that I have an obessession for workflow engines, maybe it's more of a quest for a workflow language.
Lots of business processes are weaving among participants and services. Some of them are described (as-is BPMN diagrams), lots of them are bizlore.
Some business processes are backed by state machines, but most of the time, those are lifecycle business processes, they concern 1 entity, there might be a higher level business process driving the lifecycle of multiple entities.
Some business processes can be executed advantageously by a workflow engine. Having a workflow definition mapping one-to-one to a workflow execution is great. The definition can be versioned, executions of one or more versions of the same definition may coexist.
A portfolio of concise business processes / workflow definitions is very important. It takes discipline.
I am trying to provide a fun language to build with.