Here is my scenario I am using drools for storing the rules mainly decision tables not I have a scenario where I want to create version of my knowledge. and depending on certain param want to use the knowledge.
today is my base engine when I am deciding the rules and everything. tomorrow if it changes than it should affect only the new user and old user should be able to use the older rules and if it changes again than we have three sets of user and three sets of rules.
I could see that I can maintain different Excel file and load them all and keep adding them once I get some changes in the rule.
In the same file I could have a date or some flag by that I could decide which rule has to be used.
but none of this seems to be looks like a standard drools solution to me. any thoughts or suggestions
If I'm not mistaken Drools Guvnor offers an option to publish different versions of your rule set. In a similar fashion as companies can publish different versions of Web Services.
Please comment back on this as I'm also interested whether I'm correct or not and it'll work in such a manner :)
Related
I am a newbie with the rules engine, so bear with me if this question is very basic. All the tutorials for rules engines have been saying that you can move your business logic outside your code and get it updated by BAs/ end users instead of putting it inside Java code.
I have the following questions
But why can't we write our code to read values from property files and do the same thing?
Also, the rules files seem to have a syntax which is not simply one-liners, compared to .properties files.
Does putting these rules in Rule engine make the code/app work without requiring an app server restart?
3a. If it does NOT, then how can we achieve it?
Had been doing some reading the last few days and I think (it is IMHO), the capacity for allowing business rules to be updated using simple spreadsheets, gives Rules Engines the edge over property files. I can make property files as highly configurable as possible using multiple properties and instructions for modifying rules as comments under each property.
But in a scenario where the business user is able to directly configure the application to apply values based on a "decision table" in a spreadsheet, then that solution will be more desirable.
If any other (budding) developer looking for justification on the for the need of Rule Engines is convinced with this answer, please leave a thumbs up!
If there's a change in logic, you'll change the properties file and deploy the whole project again. Whereas, if you maintain it using BRMS, you can change & test individually on the BRMS only without needing to deploy the whole project again. Once the testing is done and you finally want to deploy the new rule in place, then also, no need to deploy the whole project in production. If you've exposed your rule as API using KIE Server, redeploying just the KIE server would do.
One can write decision tables in such a way that all the logic is contained in the top rows. Then the developer can lock & hide those top rows and then give it to BA. Now BA doesn't see any logic but knows how to maintain the file. Also, not all logics should be written as decision tables.
As I mentioned above, one can deploy each and every rule as a separate rest API and hence is deployable independent of the rest.
In the end, I'd say the main reason we use Redhat BRMS is, as they mention in their documentation,:
Agility: No need to involve developers for a change request. BA's themselves can change the logic.
Visibility: What you see (in the excel) is what you get.
Consistency: Rules are evaluated the same way every time.
Rules engines are not always the answer. However, they provide, in theory, the advantage that the engine can perform complex processing on a simple rule expression and return a result. Other advantages are visibility to the rules and less code.
Answers to your questions.
You can. In simple cases,using property files makes sense.
Rules need to sufficiently complex to cover the business issues they validate. A good rules engine uses a syntax that is readable, even if it is complicated.
In theory, the rules server could run independently of the app server. In large companies, that is normal. The rules server could allow updates without a restart, or it could be restarted (rippled, if there are multiple instances,) without affecting the app server.
Rules engine comes into picture when business users of company want to set certain rules and drive application based on execution results / outcome decisions of rules set. One of examples of such company could be a Law firm or Insurance company where lawyers set rules to drive the quotes calculation for a insurance & rules are subjected to change over period of time. Property file is developer area where business user may not be proficient to make changes. Having separate rules engine tracks the rules and make a business user and a developer work together automating the business seamlessly which could be difficult with properties file.
Rule files syntax is way to convert business rules (verbal) to coding instructions which are executable. Thats where the syntax comes into picture. That way rules engine provide data abstraction to business entities and their relationships.
Integration with rules engine may be done with some broker or a web service or whatever, based on that, server app need rules client jars to make call against. So its matter of deployment and how server picks up changes / hot deploys if rules client jar is updated.
Rules engines are just algorithms for organizing many rules. See the Rete Algorithm.
Basically, it all comes down to complexity. If you have a few simple rules, of course you can use a .properties file. But imagine if some of your rules are 'chained' - one rule affects some other property, which triggers some other rule, which changes another property... you'd have to scan every rule, every change. For thousands of rules, it would take forever. Hence a 'rules engine'.
There are many articles on why you should or shouldn't use a rule engine. Here is one good example.
https://martinfowler.com/bliki/RulesEngine.html
Our framework is Grails. Say domain.com contains an application and currently used by some client. If we want to allow another client with the same functionality but providing a separation for the data of two clients, so that they can't mix both, how to do this? And whenever we want to add n clients to this application, what is the best method to be followed, so that with less / no configuration we can share the common war file for these clients by separating the db.
How the real time web development handle these type of situations?
And, one more point is how to provide client1.domain.com works for client1 and client2.domain.com works for client2. How to make the war file (in Java / Grails) to work like this? Otherwise we have to programmatically control the clients with in the project for every feature to be allowed or unnecessarily maintain separate war file for each client, which will be a waste of resources.
You're describing multitenancy - create one table for N 'tenants' instead of N identical (or nearly) tables, but partition it with a tenant_id column, and use that to filter results in SQL WHERE clauses.
For example the generated code for findByUsername would be something like select * from person where username='foo' and tenant_id=3' - the same code as a regular call but with the tenant_id column to restrict within that tenant's data.
Note that previously simple things like unique constraints are now harder because you would want to restrict uniqueness within a tenant, but allow a value to be reused across tenants. In this case changing the unique constraint to be on the combo of username and tenant_id works and does the heavy lifting in the database.
For a while there were several related plugins, but they relied on tweaking internal APIs and some features broke in newer Hibernate versions. But I believe that http://grails.org/plugin/multi-tenant-single-db is active; it was updated over a year ago, but it is being used. Contact the authors if it looks like it'll be what you need to be sure it's active. Note that this can only work with Hibernate 3.x.
Hibernate 4 added support for multitenancy, but I haven't heard much about its use in Grails (which is expected, since it's not that common a requirement). It's not well documented, but this bug report highlights some of the potential pitfalls and should still be a working example (the test app is still on GitHub): https://jira.grails.org/browse/GPHIB-6.
I'd like to ensure that this is working and continues to work, so please let me know via email if you have issues later. It's a great feature and having it in Hibernate core makes things a lot easier for us. But we need to make it easy to use and well-documented, and that will happen a lot faster when it's being used in a real project.
I'm trying to implement Drools in our project, but I really don't know which method to adopt. First of all, our project is about creating marketing campaigns for mobile network operators. So, we've got a Web UI where we let the user define his own rules for the campaign.. Now.. here's my problem. Should i try to translate everything in the UI in a custom drl with a custom agenda-name (because there can be many custum campaigns with different flows), or should I create an object with different properties which should reflect the chosen options in the web-ui and then use it in my rules to create the behaviour?
If I should go with the first option, how can I store it? Should I store the drl in Guvnor(but the models my change from time to time.. not the attributes used in the rules, other attributes.. and I can't import several jars from an url to have access to the models, can I?) or in DB, and the dynamically add the rules at run-time?
Both of the options will work. My first intuition would be to create an object model that reflects the choices in your UI. You can then add this object to the knowledgebase and trigger your rules based on it.
If you do go with the first option you can store the rules in Guvnor or you could also store the rules in a database and import the rules from a stream at runtime. I'm currently working on a large enterprise project that incorporates drools changes via guvnor and the models change quite regularly. We have not had any issues uploading new models into guvnor.
I'm using Hibernate EntityManager and Hibernate Annotations for ORM in a very early stage project. The project needs to launch soon, but the specs are changing constantly and I am concerned that the system will be launched and live data will be collected, and then the specs will change again and I will be in a situation where I need to change the database schema.
How can I set things up in order to minimize the impact of this? Are there any open source projects that deal with this kind of migration? Can Hibernate do this automatically (without wiping the database)?
Your advice is much appreciated.
It's more a functional or organizational problem than a technical one. No tool will automatically guess how to migrate data from one schema to another one. You'd better learn how to write stored procedure in order to migrate your data.
You'll probably need to disable constraints, create temporary table and columns, copy lots of data, and then delete the temporary tables and columns and re-enable constraints to have migrate your data.
Once in maintenance mode, every new feature that modifies the schema should also come with the script allowing to migrate from the current schema and data in production to the new one.
No system can possibly create datamigration scripts automatically from just the original and the final schema. There just isn't enough information.
Consider for example a new column. Should it just contain the default value? Or a value calculated from other fields/tables.
There is a good book about refactoring databases: http://www.amazon.com/Refactoring-Databases-Evolutionary-Addison-Wesley-Signature/dp/0321774515/ref=sr_1_1?ie=UTF8&qid=1300140045&sr=8-1
But there is little to no tool support for this kind of stuff.
I think the best thing you can do in advance:
Don't let anybody access the database but your application
If something else absolutely must access the db directly, give it a separate set of view specially for that purpose. This allows you to change your table structure by keeping at least the structure of what other systems see.
Have tons of tests. I just posted an article wich (with the upcoming 2nd and 3rd part) might help a little with this: http://blog.schauderhaft.de/2011/03/13/testing-databases-with-junit-and-hibernate-part-1-one-to-rule-them/
Hibernate can update the database entity model with data in the database. So do that and write migration code in java which sets or removes data relationships.
This works, and we have done it multiple times. But of course, try to follow a flexible development process; make what you know for sure first, then reevaluate the requirements - scrum etc.
In your case, I would recommend a NoSQL database. I don't have much experience with such kind of databases so I can't recommend any current implementation so you may want to check this too.
The purpose of this quetion is to evaluate the reasonability of using Drools for complex display value lookup processing within a web application. I have been tasked to retrieve coverage information (from an insurance policy) stored in a vendor database and display the information within a custom web app. There are 100s of coverages and the display values that are to be displayed for each coverage can be based on a combination of 4 or 5 different columns per type of coverage. I think there may be as many as 40 different types of coverages.
So with that being said, would drools or a decision tree mechanism provide a good way of handling this? I should point out that it is very likely that we'll need to add / modify the coverage information often and one thing that draws me to this mechanism is that the BAs could help keep the rules up-to-date. I am worried however that the speed may be adversely impacted by this option. Currently I have a working protototype using databases in combination with reflection and XML in the the database to make sure the mapping is done successfully.
I am open to other options if you can think of them as well.
Thanks,
Jeremy
Based solely on the fact that you want to offer BAs the possibility to dynamically update the coverage rules, it seems that Drools would offer you a big head start.
Regarding performance, it seems very unlikely to me that the performance would be an issue, as you're talking about a small number of facts and rules really. Biggest performance penalty is usually the parsing of the rules, which can be done on start-up and cached/shared afterward.