(This message has been automatically imported from the retired mailing list)
I know next to nothing about workflow engines, but it looks like an
interesting concept. It seems like Zato’s BST component is similar to
the core functionality of tools like jBPM. If that is so, then what are
the advantages of one over the other?
On 19/11/15 22:11, Sam Geeraerts wrote:
I know next to nothing about workflow engines, but it looks like an
interesting concept. It seems like Zato’s BST component is similar to
the core functionality of tools like jBPM. If that is so, then what are
the advantages of one over the other?
Hi Sam,
I haven’t used jBPM in some 6-7 years so I cannot really comment on that
one in particular but I can tell you more about BST and upcoming Zato
features similar to BST.
As Zato the core platform solidifies, we’ll be adding more and more
higher level capabilities that are needed in integration efforts because
some projects will be a set of endpoints whereas some will need more in
the way of controlling the processes.
BST and BPM, as seen in Zato, will be two sides of the same coin really.
BST is at its core a state machine so you use it to look at your
processes from the perspective of certain states in the process that
were reached or not.
The client who sponsored its initial development have a group of
applications that are very heavy on forms that users have to fill out
with a Zato-based backend that:
Uses BST to understand where to send users next if they log off and
log in again, i.e. to which screen. This is accomplished precisely by
keeping track of states in BST and telling frontend what to show
depending if certain forms were already seen and filled or not. External
applications participate in the process and their input updates state in
BST because a person may log off in one application, log in to another,
do what is necessary there and log back to continue in the same screen
they left off at. There are also branches, forks and other indirect
paths leading to various types of outcome.
Zato and BST are also used to drive frontend further so that on
frontend (which is in Angular so it doesn’t even have its own DB)
nothing is hard-coded, process-related interactions with users result
from responses from the ESB and BST.
The use of BST helped catch a few issues with frontend calling the ESB
in an incorrect order, e.g. not in sync with what the BST requires or
using invalid input data which BST was not aware of.
Please also note that very soon BST will also grow two new features:
Timeouts raised when a given state is not reach in N
seconds/minutes/hours/days etc. (sends info to a service(s) of choice)
Notifications sent to services upon a transition from a state to state
So that is BST - thinking in terms of states reached or not plus paths
leading out of and into each.
A related feature that Zato will have in the next release is controlling
interactions between systems in natural languages - this is what typical
BPMs usually have and use an XML syntax for or a GUI designer which
still requires one to use XML for anything not trivial.
I’m attaching a few screenshots here to give you an overview of how it
will look like, more or less. It’s not ready nor even fully designed yet
but this will offer an understanding of what is coming up.
A tentative English grammar for it is here:
It will be very easy to add new languages as above.
In contrast to BST, these new means will let you build logic using high
level if’s and else’s, async signals notifying services plus enabling
you to use a pipeline of variables shared by all services participating
in a given process or a process instance.
That all on top of what the core messaging layer will receive, such as
connection plugins or web debugger.
BPM is just a method to put some work on business logic directly on
business analytics. Pros - no misunderstanding between BA and developers,
Cons - when BA codes by moving squares, it’s still coding.
I can’t imagine business analytics using BST, that’s not their tool. But it
can be nice facility for python developers for sure.
On Thu, Nov 19, 2015 at 11:52 PM, Dariusz Suchojad dsuch@zato.io wrote:
On 19/11/15 22:11, Sam Geeraerts wrote:
I know next to nothing about workflow engines, but it looks like an
interesting concept. It seems like Zato’s BST component is similar to
the core functionality of tools like jBPM. If that is so, then what are
the advantages of one over the other?Hi Sam,
I haven’t used jBPM in some 6-7 years so I cannot really comment on that
one in particular but I can tell you more about BST and upcoming Zato
features similar to BST.As Zato the core platform solidifies, we’ll be adding more and more
higher level capabilities that are needed in integration efforts because
some projects will be a set of endpoints whereas some will need more in
the way of controlling the processes.BST and BPM, as seen in Zato, will be two sides of the same coin really.
BST is at its core a state machine so you use it to look at your
processes from the perspective of certain states in the process that
were reached or not.The client who sponsored its initial development have a group of
applications that are very heavy on forms that users have to fill out
with a Zato-based backend that:
Uses BST to understand where to send users next if they log off and
log in again, i.e. to which screen. This is accomplished precisely by
keeping track of states in BST and telling frontend what to show
depending if certain forms were already seen and filled or not. External
applications participate in the process and their input updates state in
BST because a person may log off in one application, log in to another,
do what is necessary there and log back to continue in the same screen
they left off at. There are also branches, forks and other indirect
paths leading to various types of outcome.Zato and BST are also used to drive frontend further so that on
frontend (which is in Angular so it doesn’t even have its own DB)
nothing is hard-coded, process-related interactions with users result
from responses from the ESB and BST.The use of BST helped catch a few issues with frontend calling the ESB
in an incorrect order, e.g. not in sync with what the BST requires or
using invalid input data which BST was not aware of.Please also note that very soon BST will also grow two new features:
Timeouts raised when a given state is not reach in N
seconds/minutes/hours/days etc. (sends info to a service(s) of choice)Notifications sent to services upon a transition from a state to state
So that is BST - thinking in terms of states reached or not plus paths
leading out of and into each.A related feature that Zato will have in the next release is controlling
interactions between systems in natural languages - this is what typical
BPMs usually have and use an XML syntax for or a GUI designer which
still requires one to use XML for anything not trivial.I’m attaching a few screenshots here to give you an overview of how it
will look like, more or less. It’s not ready nor even fully designed yet
but this will offer an understanding of what is coming up.https://zato.io/support/zato-discuss/proc1.png
https://zato.io/support/zato-discuss/proc2.png
https://zato.io/support/zato-discuss/proc3.pngA tentative English grammar for it is here:
https://github.com/zatosource/zato/blob/dsuch-f-gh372-add-processes/code/=
zato-process/src/zato/process/vocab.pyIt will be very easy to add new languages as above.
In contrast to BST, these new means will let you build logic using high
level if’s and else’s, async signals notifying services plus enabling
you to use a pipeline of variables shared by all services participating
in a given process or a process instance.That all on top of what the core messaging layer will receive, such as
connection plugins or web debugger.
I always hate the have you looked at this 
But I am going to 
Spiffworkflow is a workflow /bpmn tool and much of its functionality
mirrors what is in BST. It can execute
https://github.com/knipknap/SpiffWorkflow
I had looked at trying to integrate it into ZATO some time back but other
projects got in the way.
It would be interesting to look at the specific core services that has been
created to support BST and see if they map to what is required for
spiffworkflow so if we want to be able to execute workflows based on BPMN
xml definitions as an alternate workflow spec.
Cheers
Tim
