In my project I have some requirements I want to use Drools to fit. There are some rules that do not change often and serve as the foundation. Then there should be a second DSLR which changes more often and in which the already defined rules should be expanded, overriden and/or aggregated.
Is it possible to use drools for such requirements. I red the Drools documentation but I am not sure that this is possible.
I suspect you have made your plans by now, but for reference, here's something of an answer.
What you describe is a typical Drools application, so at a high level, 'yes' Drools can be used that way.
You can set up some initial DRL technical rules, which are very much for developers to maintain. The next step is how to support the business users. Drools provides:
DSL/DSRL - Developers write DSL templates, which map a natural language style of phrase to DRL. Business users write DSRL in that natural language syntax. In reality I tend to find that this is easy to read, but not so easy to write correctly. However, if you have Guvnor, the guided rules make use of the DSL to enable business users to build up rules easily. They can just pick and choose from drop-down lists to build rules using the DSL.
Spreadsheets - Here the developers create a spreadsheet with a number of hidden fields that map the cells to rules. Each row in the table becomes a rule. A business user just needs to fill in fields.
Web decision tables - In Guvnor, these are similar to spreadsheets in look, a developer can easily create a table which maps LHS constraints to actions, which could be modifying existing facts, or creating new ones. Again, business users can maintain these by adding rows to the tables and changing values in the cells. These are probably the least 'technical' from a business user's perspective, so I prefer them where possible.
If you use Guvnor, then the business users have a web site they go to where they can update rules and save them. Depending on how you want to work, the runtime rules engine can automatically pick up those changes, or you can implement a more strict release procedure for rules changes.
Related
I have been asked to start exploring a Activiti tool for some client demo.
The demo will also have JBoss Drools with which Activiti will be integrated.
I am new to both of these tools and business process world, so excuse me if the question is dumb.
The question is why do you need Drools? Isn't Activiti enough for the job?
Both of them have conditional elements so why do you need Activiti on top of drools?
This question doesn't quite fit the purpose of StackOverflow, so don't be surprised if you get a few flags. But I'll try to give a short answer.
Activity is a workflow engine, Drools is a business rules engine. They serve two different purposes.
Workflow engines are useful when you have a flow of actions of different actors that need to be controlled programmatically.
Rules engines are useful when you have business rules for executing some task automatically that you want to describe in a declarative way.
Both purposes are orthogonal to each other, meaning that the problem you have to solve may require none, just one, or both of them.
Imagine a workflow where a customer reports an incident, some experts have to work on it, and finally a bill gets produced, but no heavy algorithms are behind those tasks. That might be supported by a workflow engine without a rules engine.
Imagine a complex price model for a product, like cars having all sorts of special features that may be ordered. (Hifi speakers cost 400 €, except if the executive version of the car is ordered, where they only cost 200 € if ordered in combination with smartphone adapter...) Here a rules engine may be useful, although nobody talked about a workflow, so no workflow engine is needed.
Imagine the first example (incident workflow) together with a complex billing scheme. Here both tools may be used.
I wonder why these two types of tools are in some places described as perfectly fitting together. (Maybe this kind of claim motivated your question.) They serve two different purposes, and whether you need them both depends on the problem you have to solve.
Introduction
Drools Guvnor has it's own versioning system, that in production use allows the users of an application to modify the rules and decision tables in order to adapt to change in their business. Yet, the same assets continue to live on the development version control system, where new features to the app are developed.
This post is for looking insight/ideas/experience on rule development and deployment when working with Drools rules and Guvnor.
Below are some key concepts I've been puzzling about.
Deployment to Guvnor
First of all, what is the best way to deploy the drl files and decision tables to production environment? Just simply put them on a zip package and then unzip to Web-Dav folder? What I have navigated around Drools, I haven't found a way to import more than one file at a time. The fact model can be added as a jar archive, though. Guvnor seems to have a REST API of some sort, but using that would require custom deployment scripts.
Change management
Secondly, once the application is in production, the users will likely want to change the values in decision tables in order to set the discount percentages to higher for premium clients etc. This is all fine and dandy, until comes the time to start development of version 2.0 of the app.
Now what we have at this point is
drl files and decision tables in version controlling system
drl files and decision tables in production environment with user modifications, versioned by Guvnor
Now we are in the point of getting the rules and decision tables back from the Guvnor. And again is the Web-Dav folder the best for this, what other options there are?
Merge tools today can even handle Excel file diffs, but sounds like a merge hell to me on a big scale projects.
Keeping the fact model backwards compatible
Yet another topic is fact model integrity. For the assumed version 2.0, developers always want to make refactoring and tear the whole fact model upside down. Still, it must remain backwards compatible with the previous versions as there may be user modified rules that depend on that. Any tips on this? Just keep the fact model simple and clean? Plan ahead / suggest what the users could want to change?
Summary
I'm certain I'm not the first, and surely not the last, to consider options on deployment and change management with Drools and Guvnor. So, what I'd like to hear is comment, discussion, tips etc. on some best (and also the worst in order to avoid them) practices to handle these situations.
Thanks.
The best way to do things depends very much on your specific application and the environment you work in. However the following are pointers from my own experience. Note that I'll add just a few points for now. I'll probably come back to this answer when things come to me.
After the initial go-live, keep releases incremental and small
For your first release you have the opportunity to try things out. Take advantage of this opportunity, and do as much refactoring as possible, because...
Your application has gone live and your business users are maintaining rules in decision tables. You have made great gains in what folks in the industry like to call "business agility". Unfortunately, this tends to be at the expense of application development agility. All of your guided editor rules and decision table rules are tied to your fact model, so any changes existing properties of that fact model will break your decision tables. Unlike in most IDEs these days, you can't just right-click on a fact's getX() method, rename it, and expect all code which relies on that property to be updated.
Decision tables and guided rules are hard to refactor. If a fact has been renamed, then in many (all?) versions of Guvnor, that rule/table will no longer open. You need to get at the underlying XML file via WebDav and do some text searching and replacing. That may be very difficult, considering that to do this, you need to download the file from production to a test environment, make changes, test them, deploy them to a test environment. When you're happy with your changes you need to push them back up to the 'production' Guvnor. Unfortunately, while you were doing that, the users have updated a number of decision tables and you need to either start again, or re-apply the past couple of days' changes. In an ideal world, your business users will agree to make no rule changes for a period of time. But the only way to make that feasible is to keep the changes small so that you can make them in a couple of hours or a day depending on how generous they feel.
To mitigate this:
Keep facts used within Guvnor separate from your application domain classes. Your application developers can then refactor the internal application model to their hearts content, but such changes will not affect the business model. Maintain mappings between the two and ensure there are tests covering those mappings.
Avoid changes such as renaming facts or their properties. Make sure that facts you create and their properties have names which suit the domain and agree these with the business. On the other hand, adding a new property is relatively painless. It is well worth prompting the users to give you an eye on their future plans.
Keep facts as simple as possible. Don't go more complex than name-value pairs unless you really need to. For one thing, your business users will find it much easier to maintain rules. Your priority with anything managed within Guvnor should always be about making it easy for business users to maintain.
Keep external dependencies out of your facts. A developer may think it's a good idea to annotate a fact as a JPA #Entity, for easy persistence. Unfortunately, that adds dependencies which need to be added to Guvnor's classpath, requiring a restart.
Tips & tricks
My personal technique for making cross-environment changes is to connect Eclipse to two Guvnor WebDav directories, and checkout the rules into local directories, where each local directory maps to an environment. I then use the Eclipse diff tooling.
When building a Guvnor-managed knowledge base, I create a separate Maven project containing only the facts, and with no dependencies on anything else. It makes it a lot easier to keep them clean this way. Also, when I really do need to add a dependency (i.e. I use JodaTime where possible), then the build can have a step to generate a shaded JAR containing all the dependencies. That way you only ever deploy one JAR to Guvnor, which is guaranteed to contain the correct versions of your dependencies.
I'm sure there will be more that I think of. I'll try to remember to come back to this...
I am relatively new to the concept of rules engines and was trying to work with Drools.
Has anyone already worked this tool before and is it similar to Cognos?
My understanding was that Cognos is a reporting tool and Drools will promote more increased control over the business logic implemented.
Am I on the right track? Any link which would help me differentiate between the 2 would also be helpful.
Thank you.
Cognos is a business intelligence reporting tool. It is meant to query over data sources including data warehouses and data marts, to help provide insight into your data and help you make decisions, view trends, etc. Here is IBM's Cognos product page. Here is a definition of Cognos from Wikipedia which I find helpful.
Drools is a Rete algorithm based Java rules engine that allows you to define business rules within your application and then have your application validate against those rules. Here is its definition from Wikipedia. And here is the Drools community page.
We actually use Drools in some of our applications for client side verification of business rules. And our business is planning on using Cognos (and another tool called QlikView) to do business intelligence reporting over our data warehouses and data marts.
As for how you use Drools, I'd look at the community page. In the version we used (2.0-Beta-10, which was way before Drools was acquired by JBoss) you generally define your rules in XML based files with a .drl extension from what I remember. We use an older version of Drools so it may have changed since then. We also extended Drools in our case so we could write our rules in Java code for run time debugging versus using XML files (since our Business analysts weren't writing the rules anyway).
Hope this helps!
You can use Drools & jBPM5 if your application will define Business Processes and Business Rules. The business rules will allow you to define business logic in a declarative way and the rule engine will allow you to do inferences over the information that you have in your domain. Visiting the community sites and looking for examples will probably help you out to understand how the project look like now and how you can use it.
Cheers
What goals can be accomplished using a Rules Engine?
A Rules Engine is typically a component in software that is used to validate business rules at runtime.
They're often used in order to be able to easily change business rules without having to recompile/redeploy software. Rules can easily be stored in a corporate database, and sometimes even edited by less technical users who understand the business rules much more effectively.
For example, a mortgage company may need to change its criteria for approving a mortgage every week. By using a rules engine, you can easily create very complex criteria that can be modified without having to "program" the logic into the software. Say, this week, the base credit score shifts, you just adjust that rule in the chain of rules. Then, tomorrow, when the minimum income percentage for requiring PMI given a 90% equity rate shifts, you can just put that "rule" in place.
To add to #Reed Copsey's answer. Most rule engines keep their rules in external files that can be modified by business analysts or end users. Drools is one such solution.
In most cases the Rules being processed are at the business layer, it is possible to look at a firewall as a rule engine of sorts, another common type of rule engine is based on high level domain specific languages for transaction processing and decision making.
There are a number of companies that produce appliances, and web transactions as a service to. These give the analysts tools to form complex decision trees and expert systems without having to do the grunt work of the developer, thanks to the magic of EGL most of the translation is done by modeling tools that can stub and generate code and valid end points to meet the "business" needs automagically.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I have a pretty decent list of the advantages of using a Rules Engine, as well as some reasons to use them, what I need is a list of the reasons why you should NOT use a Rules Engine
The best I have so far is this:
Rules engines are not really intended to handle workflow or process
executions nor are workflow engines or process management tools
designed to do rules.
Any other big reasons why you should not use them?
I will give 2 examples from personal experience where using a Rules Engine was a bad idea, maybe that will help:-
On a past project, I noticed that the rules files (the project used Drools) contained a lot of java code, including loops, functions etc. They were essentially java files masquerading as rules file. When I asked the architect on his reasoning for the design I was told that the "Rules were never intended to be maintained by business users".
Lesson: They are called "Business Rules" for a reason, do not use rules when you cannot design a system that can be easily maintained/understood by Business users.
Another case; The project used rules because requirements were poorly defined/understood and changed often. The development team's solution was to use rules extensively to avoid frequent code deploys.
Lesson: Requirements tend to change a lot during initial release changes and do not warrant usage of rules. Use rules when your business changes often (not requirements). Eg:- A software that does your taxes will change every year as taxation laws change and usage of rules is an excellent idea. Release 1.0 of an web app will change often as users identify new requirements but will stabilize over time. Do not use rules as an alternative to code deploy.
I get very nervous when I see people using very large rule sets (e.g., on the order of thousands of rules in a single rule set). This often happens when the rules engine is a singleton sitting in the center of the enterprise in the hope that keeping rules DRY will make them accessible to many apps that require them. I would defy anyone to tell me that a Rete rules engine with that many rules is well-understood. I'm not aware of any tools that can check to ensure that conflicts don't exist.
I think partitioning rules sets to keep them small is a better option. Aspects can be a way to share a common rule set among many objects.
I prefer a simpler, more data driven approach wherever possible.
The one poit I've noticed to be "the double edged sword" is:
placing the logic in hands of non technical staff
I've seen this work great, when you have one or two multidisciplinary geniuses on the non technical side, but I've also seen the lack of technicity leading to bloat, more bugs, and in general 4x the development/maintenance cost.
Thus you need to consider your user-base seriously.
I'm a big fan of Business Rules Engines, since it can help you make your life much easier as a programmer. One of the first experiences I've had while working on a Data Warehouse project was to find Stored Procedures containing complicated CASE structures stretching over entire pages. It was a nightmare to debug, since it was very difficult to understand the logic applied in such long CASE structures, and to determine if you have an overlapping between a rule at page 1 of the code and another from page 5. Overall, we had more than 300 such rules embedded in the code.
When we've received a new development requirement, for something called Accounting Destination, which was involving treating more than 3000 rules, i knew something had to change. Back then I've been working on a prototype which later on become the parent of what now is a Custom Business Rule engine, capable of handling all SQL standard operators. Initially we've been using Excel as an authoring tool and , later on, we've created an ASP.net application which will allow the Business Users to define their own business rules, without the need of writing code. Now the system works fine, with very few bugs, and contains over 7000 rules for calculating this Accounting Destination. I don't think such scenario would have been possible by just hard-coding. And the users are pretty happy that they can define their own rules without IT becoming their bottleneck.
Still, there are limits to such approach:
You need to have capable business users which have an excellent understanding of the company business.
There is a significant workload on searching the entire system (in
our case a Data Warehouse), in order to determine all hard-coded
conditions which make sense to translate into rules to be handled by
a Business Rule Engine. We've also had to take good care that these
initial templates to be fully understandable by Business Users.
You need to have an application used for rules authoring, in which
algorithms for detection of overlapping business rules is implemented. Otherwise you'll end up with a big mess, where no one understands anymore the results they get.
When you have a bug in a generic component like a Custom Business Rule Engine, it can be very difficult to debug and involve extensive tests to make sure that things that worked before also work now.
More details on this topic can be found on a post I've written: http://dwhbp.com/post/2011/10/30/Implementing-a-Business-Rule-Engine.aspx
Overall, the biggest advantage of using a Business Rule Engines is that it allows the users to take back control over the Business Rule definitions and authoring, without the need of going to the IT department each time they need to modify something. It also the reduces the workload over IT development teams, which can now focus on building stuff with more added value.
Cheers,
Nicolae
GREAT article on when not to use a rules Engine...(as well as when to use one)....
http://www.jessrules.com/guidelines.shtml
Another option is if you have a linear set of rules that only apply once in any order to get an outcome is to create a groovy interface and have developers write and deploy these new rules. The advantage is that it is wickedly fast because normally you would pass the hibernate session OR jdbc session as well as any parameters so you have access to all your apps data but in an efficient manner. With a fact list, there can be alot of looping/matching that really can slow the system down.....It's another way to avoid a rules engine and be able to be deployed dynamically(yes, our groovy rules were deployed in a database and we had no recursion....it either met the rule or it didn't). It is just another option.....oh and one more benefit is not learning rules syntax for incoming developers. They have to learn some groovy but that is very close to java so the learning curve is much better.
It really depends on your context. Rules engine have their place and the above is just another option if you have rules on a project that you may want to deploy dynamically for very simplified situations that don't require a rules engine.
BASICALLY do NOT use a rules engine if you have a simple ruleset and can have a groovy interface instead.....just as dynamically deployable and new developers joining your team can learn it faster than the drools language.(but that's my opinion)
In my experience, rules engines work best when the following are true:
Well-defined doctrine for your problem domain
High quality (preferably automated) data to help drive most of your inputs
Access to subject matter experts
Software developers with experience creating expert systems
If any of these four traits are missing, you still might find a rules engine works for you, but every time I've tried it with even 1 missing, I've run into trouble.
That's certainly a good start. The other thing with rules engines is that some things are well-understood, deterministic, and straight-forward. Payroll withholding is (or use to be) like that. You could express it as rules that would be resolved by a rules engine, but you could express the same rules as a fairly simple table of values.
So, workflow engines are good when you're expressing a longer-term process that will have persistent data. Rules engines can do a similar thing, but you have to do a lot of added complexity.
Rules engines are good when you have complicated knowledge bases and need search. Rules engines can resolve complicated issues, and can be adapted quickly to changing situations, but impose a lot of complexity on the base implementation.
Many decision algorithms are simple enough to express as a simple table-driven program without the complexity implied by a real rules engine.
I would strongly recommend business rules engines like Drools as open source or Commercial Rules Engine such as LiveRules.
When you have a lot of business policies which are volatile in nature, it is very hard to maintain that part of the core technology code.
The rules engine provides a great flexibility of the framework and easy to change and deploy.
Rules engines are not to be used everywhere but need to used when you have lot of policies where changes are inevitable on a regular basis.
I don't really understand some points such as :
a) business people needs to understand business very well, or;
b) disagreement on business people don't need to know the rule.
For me, as a people just touching BRE， the benefit of BRE is so called to let system adapt to business change, hence it's focused on adaptive of change.
Does it matter if the rule set up at time x is different from the rule set up at time y because of:
a) business people don't understand business, or;
b) business people don't understand rules?