Rules Engines are often sold under the premise of making it possible for business people to modify some very dynamic parts of the application directly, without any involvement or programming done by the developers.
In my opinion, putting into production any code that is not covered by automated tests represents a grave risk. I know that many rules engines are actually a rules management environments, including versioning, promotion between environments etc.but what support they offer to BA for writing tests? I have seen some documents where it seems frameworks like JUnit are integrated into the engine and this is certainly not the type or programming that non-programmer would do.
BA can easily change the rule with business engine, but how easy is for him to write a test that can cover it without the help of a programmer? How is the problem of rules test coverage resolved in practice?
"making it possible for business people to modify some very dynamic parts of the application directly, without any involvement or programming done by the developers."
We have been using a commercial rules engine for over 6 years now. We build template applications that are customized as per the customer's (like banks etc) requirements. The customization's are in the form of decisioning rules which are written in business vocabulary. Below are some of the observations that I've made over 6 years
I've never seen any rules customized on the fly in production by any customer. They all go through proper testing in the UAT environment before they are pushed to production. The whole app is not re-deployed, only the business rules are pushed.
Rules are written by the BA's but most of the time they still need to go through the developers for performance tuning purposes because of the execution model that these rules engine use.
I doesn't know about many open source rules engines but for the one we use, we wrote custom eclipse plugins so that that BA's can generate the test cases in the form JUnits
I think most of the rules engines will provide some sort of a API that tells which rules were fired in the form of audit report for a given request. But the challenge for us was to find the test data that can fire a particular rule. We call it as rule relevant data.
Related
I am needing to get a financials heavy software system under test automation. It has been in development and production for a couple years. I've been an advocate for developers building testing test automation into their coding practices for over 18 years, but this is a unique challenge. Beyond establishing test automation standards and training for the technologies we are using, I need to figure out the most effective strategy for prioritizing and implementing automated tests into the existing system that will improve confidence/stability/reliability, while continuing with rapid development of future features. There are many teams working on this solution.
My primary decision point is whether I should start the focus on internals of the financial transactions, processes, rules - with unit and integration tests under the hood - or start with use cases that tell full stories. There are two things that are competing for priority, making sure requirements have been implemented correctly vs. making sure what has already been implemented does NOT get broken by new code merges. I realize that these are not mutually exclusive, but time is of the essence and I need to move yesterday on implementing the highest value tests.
I would love to discuss with others experienced with test automation in systems that are heavy on financial transactions that are CRITICAL.
Since you will never catch up with the tests you should focus on new features and fixes. Whenever the code will be changed, try to identify which parts of the existing code will be touched and see if you can improve the test coverage for this parts before writing any new code. Do not aim for perfection, just try to get some tests running that would catch any serious regressions. Then try to TDD the new feature/fix.
Also check out "Working Effectively with Legacy Code" by Michael Feathers.
Is there a rules engine that can handle constantly changing rules? The scope of the rules is well defined, but users have the ability to change parameters of rules within that scope whenever they choose to. I don't expect to have more than a couple thousand rules, but they will likely experience numerous changes each time a user joins the system. Should I scrap the Rules Engine idea altogether here or does something exist that meets these demands? I wasn't able to find anything online except an IEEE paper.
Any business rule engine is nominally designed to handle this use case. However, you will find that they all have different takes on what is important and the technology stacks will be different. The above answers for InRule and CodeEffects seem good for environments where .Net is required.
Based on statements in your question, it seems that you are going to have a lot of churn in the rules. I think it is important for you to consider then who will be making these changes and what the governance of the changes will be. These considerations may be more important to you than the technology platform (.net / java / hosted) or the initial implementation effort, actually. Most rule projects should be considered with the on-going maintenance in mind more than the initial development.
In our project we have to implement business logic regarding mapping of certain objects to some actions. We will have a series of conditions for specific types of objects to be verified before a certain action finally gets resolved. In other words for 7 types of objects we can have a series of actions ( from out of almost 45 actions).
We were thinking of using Drools to write down the aforementioned rules. Does anyone have some positive / negative experience with using Drools as far as its efficiency is concerned? There is also the jBPM framework that can be used (if I am not mistaken Drools are used there) – anyone is familiar with that framework? Perhaps you have some other ideas of how to solve the problem?
With regards efficiency, you should have no issues at all with Drools. That sounds like a pretty tiny set of facts and rules to me. The Rete engine on which it is based is almost certainly faster at making decisions than any pile of if-then-else statements you code up yourself. And a particular benefit that I noticed is that response times are extremely predictable.
Obviously all fact models and rules differe, but as an example, the application I'm currently building has hundreds of facts in working memory at any time, and more than 1000 rules. It's able to make decisions about incoming requests in about 20 milliseconds.
The full jBPM framework doesn't sound necessary for what you describe. However, it is good at what it does. For instance there is a process modelling GUI if you're looking to design workflows, and Guvnor can be usable for non-technical rules authors if the technical team puts in some up-front effort on writing DSLs and building decision tables.
For completeness, the main competitors are probably FICO Blaze Adviser or IBM ILog JRules. Generally when it comes to benchmarks those tend to be slightly ahead of Drools, but they are expensive. Admittedly, if you decide to pay for JBoss/RedHat service contracts then it's not much different, but if you're happy to take community support on Drools, then it's free!
My only concern about Drools is that there is no decent GUI for it that a non-IT business people could really use. Lots of products claim that they do provide such UI but it always turns out to be not really true. So, you have to accept the fact that your development team will end up creating and testing all those rules based on decision tables or some other formats.
Other than that, Drools is a great BRE used by governments, banks and large companies.
Drools is very efficient and fast. But as with any technology & framework it will need an investment to integrate into your project and it is not a magic bullet. You need to consider:
How many rules will you have? I would not recommend any rule engine if there is less than 20 rules. It might not justify the effort you will spend for the compexity of adding a rule engine just for 7 objects and 45 actions...
Will you need DSL (Domain Specific Language) capabilities? Ie. will non-technical people write rules? IMHO this is not very usable in Drools in comparison to eg. Oracle OPA. But again I have not seen a non-technical person safely tinkering with a rule system yet. Apart from changing values in a decision table.
How often will your rules change? If you need a centralised system to manage, version, package, test your rules then Drools Guvnor is a very capable product.
jBPM is not a rule engine, it's a workflow engine. Drools is a rule engine. So Drools is what you're looking for.
Drools and jBPM are companion projects: they integrate really nicely if you need workflows with rules.
Drools is good well JBPM is bit complex as compared to other BPMN engines. I would suggest go for Activiti because it is bit easier and integration of anything say Spring, LDAP etc.; with Activiti is easier. Also you can integrate Drools with Activiti.. so go for Activiti as aworkflow engine and Drools for a rules engine.
I'm currently working on a large BPM project at work which uses the Global 360 BPM tool-set called Process 360. Just to give some background; this product works like a lot of other BPM solutions in that you design multiple "process maps" which define the flow of a particular business process you're trying to model, and each process map consists of multiple task nodes connected together which perform particular functions (calling web-services etc).
Currently we're experiencing some pretty serious issues during QA phases of our releases because there isn't any way provided by the tool-set to automate testing of the process map routes. So when a large and complex process is developed and handed over to our test team there are often a large number of issues which crop up. While obviously you'd expect some issues to come out of QA, I can't help the feeling that a lot of the bugs etc could have been spotted during development if we had some sort of automated testing framework which we could use to build up a set of unit tests which proved the various routes in the process map(s).
At the moment the only real development testing that occurs is more akin to functional testing performed by the developers which is documented as a set of manual steps per test-case. The problem with this approach is that it's very time consuming for the developers to run manually, and because of this, is also relatively prone to error. Also; because we're usually on a pretty tight schedule, the tests are often not executed often enough to spot issues early.
As I mentioned earlier; there isn't a way provided by the current tool-set to perform this sort of automated testing. Which actually got me thinking why? Being very new to the whole BPM scene my assumption was that this was just a feature lacking in the product, but I also wonder whether "unit testing" just isn't done in the BPM world traditionally? Perhaps it just isn't suited well to this sort of work?
I'd be interested to know if anyone else has ever encountered these sorts of issues, and also what - if anything - can be done to improve things.
I have seen something about that, though not Global 360 related : using bpelunit for testing processes
I develop a workflow tool and there is an increased demand for opening the test tools used for testing the engine to end-users.
I've done "unit" testing with K2.net 2003, another commercial BPM. I'd really call this integration testing, because it requires a test server and it's relatively slow. However, it is automated.
There's a good discussion of this in the book Professional K2 blackpearl (it applies to K2.net 2003 as well).
In order to apply it to your platform, the tool set has to have an API that permits starting process instances, obtaining work items, completing work items, etc. You write tests using any supported language (I used C#) and a testing framework (I used NUnit). If the API supports synchronous calls, this is easier to do. For each test:
Start the process under test
Progress the work item to a decision point
Set process instance data appropriately
Complete the work item
Assert that the work item is now at the expected activity
Delete or complete the process instance
Base test classes or helper methods can make this easier. You could even write a DSL for testing maps.
Essentially you want full "test coverage" of the process/map - test every decision point and insure that the correct branch is taken.
There are two aspects of BPM that are related yet not identical.
There's BPM that tool and technology vendors advocate for which is all about features.
There's also BPM that Enterprise Architects advocate for which is all about establishing Centers of Excellence.
The former is where a company buys some software.
The latter is where a company makes systemic and inherent changes to the behavior of their IT workers.
The former is supposed to be in the service of the latter but that isn't necessarily so. Acquiring the former is necessary but not sufficient for achieving the latter.
I don't know just how well that Global 360 supports what is known as Test Driven Development but JBoss jBPM does provide some tool support for easily writing JUnit tests.
However, the tool can't and won't force developers to write them or to embrace TDD principles.
When is a Business Rules Engine used?
What is the difference between Business Rules Engines and scripting/configuration/customization
A business rules engine, or a business rules management system, should be used when you are trying to implement a decision in your code. But not just any decision. A decision that:
Involves lots of rules
Has rules that change often
Has rules that are complex or interact in complex ways (think lots of nested IFs otherwise)
Has rules that only someone with domain knowledge can understand/verify
Is one that the business people REALLY want to be able to change without your help
Involves using predictive analytics / scores as part of the decision making
These are the kinds of decisions that pay off the use of a business rules management system. Don't start with the rules, start with the DECISIONS.
Business rules are verbose (so business people find them easier to read), declarative not procedural and atomic (so they can be stored, managed and reused like data in a database).
More on why to use business rules here in this piece on why I believe in business rules.
Business rules engines are typically used to provide customizable "IF some-condidtion THEN do-something" sorts of logic to applications. These types of business rules can trigger certain workflows to execute or bubble up event knowledge to higher level rules, causing them to be evaluated.
Using a rule engine also allows for easier separation of concerns by removing the business logic from your code. Rules engines today typically also offer a front-end where users can add new rules without having to modify scripts inside the application.
Rules engines implement algorithms such as Rete (speaking from Drools experience) that make the task of evaluating the rules quicker. The rule engine also provides forward chaining, backward chaining, hybrid chaining, etc. of rules. However, these could be implemented in a scripting language as well. You can achieve some of the same sorts of things with both approaches, but I believe that it depends on the complexity and number of rules as to which avenue you should choose.
Take a look at this link from the Jess project: http://www.jessrules.com/guidelines.shtml
It provides a step-by-step walk through of questions to ask yourself in order to determine if a rules engine meets your needs, or is overkill.
Rules engines can do forward and backward chaining as well as inferencing. Check out Fair Isaac Blaze, Drools or iLog for implementations.