Hi,
/"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." /I think you are talking about BpmFlow (https://github.com/brunobuzzi/BpmFlow) if not excuse me :)
A couple of month ago a created an issue for the port
(https://github.com/brunobuzzi/BpmFlow/issues/843) to annotate all information
related to a possible port.
The most challenging task is how to persist BpmProcess data within Pharo, use
an ORM (GLORP) or use GemStone ?
This task is the most complex.
But first there are some minor issue to tackle|: * Replace GS ReduceConflict classes with normal Pharo collections. *
GsQuery - Replace GsQuery with normal blocks - |||(or)| Find out if GsQuery was ported (or it could be ported) to Pharo
* Replace GS Selection Block with normal Pharo blocks. {:each |
each.address.state = 'OR'} Develop in Pharo and Deploy in GemStone
strategy can be a very good source of information to solve the above
issues. I use Jade client to directly develop on GemStone/S so a
research is needed on "|||Develop in Pharo and Deploy in GemStone|". Modeling tools: The goal is
to be able to import any XPDL file exported by any BPMN tool. For now we
use Bizagi but others tools that export to XPDL standard can be added.
This will require some effort but is possible (we do an extensive use of
Bizagi extended attributes but if the BPMN tool to be added support some
kind of mechanism to add custom attributes to tasks there will be no
problem). regards, bruno |
//
