Business Process Mangement and Rules [message #753] |
Mon, 09 April 2007 17:32 ![Go to next message Go to next message](/theme/default/images/down.png) |
stephenboey
Messages: 54 Registered: January 2007
|
Member |
|
|
Just some suggestions.
Based on a Role:
Based on a Business Rule:
1. Add features that allow a screen/view to be preconfigured by developer/administrator from a form. Preferably, these properties are stored in database.
example: field visibility, field enabled/disabled.
Currently this is only achievable through scripting in the classes. This can be very tedious if too many rules.
Would be good if business rules can be factored out and stored in database as well. Similar to BPM workflows.
|
|
|
|
|
Re: Business Process Management and Rules [message #757 is a reply to message #756] |
Tue, 10 April 2007 04:35 ![Go to previous message Go to previous message](/theme/default/images/up.png) ![Go to next message Go to next message](/theme/default/images/down.png) |
AJM
Messages: 2361 Registered: April 2006 Location: Surrey, UK
|
Senior Member |
|
|
No, you do not need different versions of the same task. You have one task, which has a single screen with a defined set of fields. If you want to have different accessibility to these fields for different Roles the old fashioned way would be to create a different task with a different screen. This would also mean that you would have to change menu/navigation buttons in order to activate the relevant task with the relevant accessibility, and this would require a great deal of effort.
The Radicore approach is much easier. There is a single Task with a single screen that is accessible to one or more Roles. By default all the users of those Roles see exactly the same screen. By using either of those two functions I mentioned previously it is possible to change the accessibility of certain fields in that screen for specified Roles. There is still a single task with a single screen, but the contents of the MNU_ROLE_TASKFIELD table is checked at runtime to see if the default accessibility of any fields in that screen need to be changed.
As for a rules engine based on the screen sample you supplied, I have no plans to implement such a thing. The Radicore framework has been designed for developers, not untrained users, so business rules are implemented by putting the correct PHP code in the correct method of the correct class. Any alternative would simply impose a great overhead for no benefit. It would also make debugging a lot harder.
The theory that it is possible to write a general-purpose rules engine that can deal with any rules in any circumstances is just that - a theory. I have seen it attempted and I have seen the failures.
The only time I have personally built a successful rules engine was for a payroll system in the 1990s in which I made it possible for all the calculations to be defined in screens and maintained on the database. This was a closed system in that all the possible inputs were known, all the possible outputs were known, and all the possible actions (add, subtract, multiply, divide) were also known.
Tony Marston
http://www.tonymarston.net
http://www.radicore.org
|
|
|
|
Re: Business Process Management and Rules [message #759 is a reply to message #758] |
Tue, 10 April 2007 05:55 ![Go to previous message Go to previous message](/theme/default/images/up.png) ![Go to next message Go to next message](/theme/default/images/down.png) |
AJM
Messages: 2361 Registered: April 2006 Location: Surrey, UK
|
Senior Member |
|
|
Such rules cannot easily be handled by the framework for the simple reason that the framework knows only about Tasks and Roles, and nothing about the state of any records within your application database.
If you have such complex rules, what is the difference between having to define them using PHP code and defining them in a rules engine? They still have to be defined, and doing it in code avoids the overhead of going through an intermediate rules engine.
If you look inside file dict_column.class.inc you will see where I turn access to different fields either ON or OFF depending on the datatype of the current column. This is just a single task with a single screen, yet the screen can change at will to suit the circumstances. I am afraid that trying to write a rules engine to do the same thing would require an enormous amount of effort, but for what benefit?
Also, the task of maintaining a rules engine which people would expect to be able to handle ANY condition in ANY set of circumstances would be just too great.
If you think that such a rules engine is possible then why not try writing it yourself?
Tony Marston
http://www.tonymarston.net
http://www.radicore.org
|
|
|
|
|