something else to consider. the business man will use tools like open
office.
open office has support for Macros. openoffice basic(the preferred),
python, Beanshell, and Javascript.
Open office binaries are already in ofbiz.
why not extend the openoffice basic for business rules.
flesh out the ofbiz program manager for Drools Planner, Drools Flow, fusion.
BJ Freeman sent the following on 7/28/2010 9:21 PM:
I agree ECA is basic Database
SCAS is based on a operation/service like create party.
what I guess I was not clear on is that in compiler implementation you
have source code that is then turn into the actual code that will be used.
Tn this case, an organization create business plan, which is quite
detailed.
then that is run though the "compiler" to create businesses flow in
project manger(which gives a visual), services and SCAS to implement.
when a rule is implements it needs to take into consideration the
resources it has available to implement it. Man power, Facilities,
Assets, etc.
having another language that a Business person has to learn it not what
I consider business friendly.
if we talk about Drool first talk about what it takes to integrate into
ofbiz. An analysis of the inner workings of Drool and how it meshes with
ofbiz model.
Brett Palmer sent the following on 7/28/2010 9:00 PM:
I'm working on a non-ofbiz project right now where they are considering
replacing the commercial rules engine solution with something like
drools.
Drools looks like a solid rules engine. They have their own domain
specific
language (DSL) which makes the rules easy to develop and follow. The also
handled nested rules very effectively.
I like ECA and SECA as well but I have used them more like database
triggers
and not a method for implementing complicated rules and workflow, but I
could be wrong on this subject.
Drools appears to be licensed appropriately for ofbiz. I would be in
favor
of drools rules engine integration implementation.
Brett
On Wed, Jul 28, 2010 at 9:47 PM, BJ Freeman<[email protected]> wrote:
ofbiz has, though not implemented well, a rules engine as well as a
workeffort and event(ECA, SECA, controller events) Model. the Project
management also lends itself to rules.
I would suggest we work out a model rules engine that works around
the way
ofbiz works. That was the short comings of the other rules engines
was the
integration into the ofbiz model.
Maybe doing a review of rule engines in ofbiz now and why they did
not get
implemented would be a good exercise.
My efforts have been how to have a ui that a business person would
understand, and generate ECA and SECA to accomplish Thier logic. The top
level of this would be when they generate a business plan, it sets up
the
rules on how the business flow is done. This actually is base on
compiler
theory and some program that create web code for a particular type of
web.
I estimated to be about 1.5 man year.
Sam Hamilton sent the following on 7/28/2010 8:12 PM:
Hi Guys,
I have been thinking about problems we are soon going to start
facing in
marketing our OFBiz website and some of them can be solved using a
rules
engine, this then spilled over into other departments once I had read
through the Drools website and saw how powerful it could be once
implemented
inside OFBiz.
I was thinking Drools http://jboss.org/drools/ as its ASL2 so we can
have
in trunk http://jboss.org/drools/downloads.html and also because of the
GUI which could be plugged into OFBiz where ever we need rules - a
few cool
examples are here
http://downloads.jboss.com/drools/docs/5.0.1.26597.FINAL/drools-introduction/html/ch02.html#d0e166and
for the developers or data mining people using Birt etc they can use
Eclipse.
The uses I can think of right now are:
1. Sending emails to customers - similar to auto responders or
triggered
emails .
2. Stock reordering - allowing different stock to be treated
differently
depending on for example how fast its selling or out of which
warehouse the
most is shipped.
3. Inserting marketing material into parcels - picking different
customer
segments and targeting them differently.
4. Shipping carrier upgrades / changes depending on either
destination or
price - like zappos do when they secretly upgrade customers to over
night
delivery.
5. Refunds to customers if something goes wrong (could automate some of
the process) and then if its outside the rules it move to a human for
review.
The real aim is that I want to move the process of rule changing out of
the programers hands and put them into technical business people so
that we
can make fast changes to the business all done by the business users.
What does everyone else think?
Cheers
Sam
