rule-engine-open configures business rules in a browser, and the open edition is a deliberately narrow subset

Rules that a product manager can change without a deploy

RuleEngine is a rule engine whose pitch, stated in the repository description, is that implementing business logic no longer depends on code development and that complex business logic can be built with zero code, through web based visual configuration.

That is a well known product category, and the reason it exists is organisational rather than technical. A pricing rule, a risk threshold or a routing decision is the kind of requirement that changes often, is understood by the business, and is owned by nobody in the engineering team. If changing it requires a code change and a deployment, the change either waits for a sprint or it goes around the process. If it can be changed in a browser, it does not.

The mechanics follow from that. The documentation says rules are configured at the ruleengine.cn site, and once a rule is configured, an interface can be called to execute the rules inside the engine. The repository is the open edition of that system, and the project description is explicit about what is included: only the ordinary rules, parameters, variables and functions of the current project are open sourced.

The audience is therefore a Java development team that has decided the business wants to own its rules, and is willing to run a rule server as a service. The technology list in the documentation is what makes that concrete: SpringBoot 2.2.11, RabbitMQ, Redis with Redisson, MySQL 5.7.9, Mybatis-plus, Maven 3.3 and Swagger.

That stack is not incidental. A rule engine that is edited while the system runs needs somewhere to keep rules, somewhere to queue work, and somewhere to cache evaluated results, and the answer here is a relational store, a message broker and a cache, each of which is one more thing to operate.

The README restricts use in ways the Apache 2.0 label does not

The licence situation in this repository needs stating plainly, because it is unusual and because the two authoritative looking sources disagree.

The licence field in the repository records Apache-2.0, and there is a LICENSE file in the root. But the README says something considerably stricter. It states that only the ordinary rules, parameters, variables and functions of the current project are open sourced, and that no organisation or individual may copy, modify, distribute, reverse engineer or use commercially the commercial version of the software, described as the experience environment, in any form. It goes on to say that violators face a statutory fine of 200,000 renminbi and possible legal action, and that reporting infringement earns a cash reward of 40 percent of the actual fine.

Read charitably, the clause is aimed at the hosted commercial offering rather than at the open source code in this repository, and the Apache 2.0 grant on the repository is what covers the open part. Read literally, the wording about the commercial version is broad enough to be worth a lawyer rather than a readme.

This is not a technical property of the project, and it is not something this review can resolve. It is a commercial term in a repository that otherwise presents itself as Apache 2.0 licensed, and any organisation planning to build on it should get it clarified in writing before deployment.

The same point applies to the sibling products. The README links a drag and drop data platform on Gitee, a drag and drop rule platform at ruleplatform.com with flow rules, judgement rules, scoring rules and intelligent decisions, and a project site at ruleengine.cn, plus a graduation certification contact address. This is an open source component of a commercial product, not a standalone community project, and that is a fair description rather than a criticism.

Executing a rule is an HTTP POST with a rule code and parameters

The integration contract is simple and worth understanding before anything else, because it determines whether the engine fits your architecture.

A rule is executed by posting to a general rule execute endpoint. The request body carries a code, which identifies the rule, a workspace code, the access key identifier and secret, and a param object holding the inputs the rule reads. In the documented example the rule code is a test rule for phone numbers and the parameter is a phone number.

So the calling model is that your application holds a rule code, sends the parameters the rule expects, and receives the outcome. The rules themselves live in the engine, configured through the web interface, which means a change to a rule is a change in the engine's configuration and not a change in your application.

The access key pair is what identifies the caller, and the workspace code scopes it. That is a two dimensional authorisation model, and the README does not describe how the keys are provisioned or rotated, so anyone integrating this needs to find that out before running it with production traffic.

The param object is a free form map, which is what makes the engine usable with heterogeneous rules. It also means the coupling between your code and the configured rules is by string codes rather than by types, so a rule that is edited to expect a different parameter name fails at run time rather than at build time. That is a real operational property of a configuration driven engine and it is the thing to test for.

Batch execution also exists, since the client interface shown later declares a batchExecute method alongside execute and isExists, which are the three operations the Java client exposes.

The Java client is a Maven dependency and a Spring Boot starter

Calling the engine from a Java project is documented as a Maven dependency, so the client is a normal library rather than something you write yourself:

    <dependency>
        <groupId>cn.ruleengine</groupId>
        <artifactId>rule-engine-client</artifactId>
        <version>2.0</version>
    </dependency>

The coordinates are under a cn.ruleengine group, and the version documented in the README is 2.0.

A Spring Boot application then configures the client in application.yml, under a rule.engine prefix. The base url points at the rule server, the workspace code and the access key pair are supplied, and there is an optional feignConfig section holding the HTTP client tuning: connect and read timeouts in milliseconds, and a retryer with a period, a maximum period and a maximum attempt count of three.

The retryer block is the part worth reading twice. A rule engine call that is retried on failure is a rule that may be evaluated more than once, which is fine for a pure decision and not fine for a rule with a side effect. The client makes retries easy, and easy retries on a non idempotent operation is a trap.

The test code in the documentation shows the shape of the integration. The test class is annotated with the rule engine enablement annotation, runs as a Spring Boot test, and injects the client. The rule parameters are declared as a small data class annotated with a model code that matches the rule code, and each field carries an input parameter annotation giving its name, with a comment noting that the code defaults to the property name if left out.

The client is then obtained from the engine, the rule is executed with the parameter object, and the output is printed. The output type is a generic Output, so the shape of the result depends on what the configured rule returns, which the documentation does not specify.

Feign by default, and a RestTemplate escape hatch

The default HTTP mechanism is Feign, and the documentation is clear that you can substitute your own. The configuration class is a Spring component that imports RestTemplate and defines the interface the client uses:

@Component
@Import({RestTemplate.class})
public class RuleEngineClientConfig {

    @Resource
    private RestTemplate restTemplate;

    @Bean
    public GeneralRuleInterface generalRuleInterface() {
        return new GeneralRuleInterface() {

            @Override
            public ExecuteResult execute(ExecuteParam executeParam) {
                return restTemplate.postForObject("http://ruleserver.cn/ruleEngine/generalRule/execute", executeParam, ExecuteResult.class);
            }

            @Override
            public IsExistsResult isExists(IsExistsParam existsParam) {

The interface has three methods, execute, isExists and batchExecute, and the two methods other than execute are shown in the documentation as unimplemented stubs. That is a small but important detail: the client interface is wider than the reference implementation, so any operation you plan to use beyond a single execute call needs checking before you rely on it.

The reason to override the transport rather than use the default is worth spelling out. The default Feign client is configured for the engine's own conventions, and the RestTemplate path lets you keep your existing HTTP client configuration, your own timeouts, your own tracing, and your own authentication interceptors. In an organisation that already has a standard HTTP setup, that consistency is usually worth more than the convenience of the default.

Either way the engine is a remote service reached over HTTP. That is the architectural fact, and it is what separates this from a rule library you would link into your process, such as one evaluated in memory inside the same JVM.

A server built from three modules, not a library you can embed

The repository layout confirms the shape of the system. There are three modules, rule-engine-open-compute, rule-engine-open-core and rule-engine-open-web, plus a root pom.xml. A compute module, a core module and a web module is a service, not a library, and the naming of the web module matches the configuration surface where rules are edited through a browser.

The documentation site is at ruleengine.cn with the detailed documentation at ruleengine.cn/doc, and the front end source lives in a separate repository on Gitee rather than in this one. The split is worth noticing, because it means the open edition of the engine and the open edition of the interface are two different codebases maintained in two different forges, which is a factor to weigh if you intend to modify the configuration UI.

The supporting services are the ones named in the stack list, and each has a clear job. MySQL holds the configuration, since rules, parameters, variables and functions are data. Redis with Redisson provides the cache and the distributed locking that a rule engine needs when several callers evaluate the same rules concurrently. RabbitMQ carries the work between the request path and the evaluation, which is what lets a rule run asynchronously when a rule is slow. Swagger exposes the API.

That is three stateful dependencies plus the engine itself. For a team that already runs Spring Boot with MySQL, Redis and RabbitMQ, that is a familiar bill. For a team that does not, adopting this engine means adopting its infrastructure requirements, and that is a larger decision than the rule model itself.

The related products extend the same idea. The drag and drop data platform on Gitee covers data flows, data sources, data alignment, query templates and monitoring, and the rule platform at ruleplatform.com adds scoring rules, rule reuse, simulation runs, version management and execution monitoring. The direction is a platform rather than a component, and the open repository is one part of it.

The roadmap is scorecards and decision trees, and there are no releases

The project states its next steps plainly. Optimising the code and improving the configuration experience is in progress, while a scorecard and a decision tree are both marked as to be developed. It also says the author is busy with work and the features are not yet complete, and welcomes partners who are interested.

The roadmap is revealing about the product's direction. A rule engine that evaluates a condition and returns a value is a different thing from a scorecard, which aggregates weighted criteria into a grade, and from a decision tree, which models a branching decision. Those two additions are the move from a decision point system towards a decision management system, which is where the commercial rule platform is positioned with its flow rules, scoring rules and intelligent decisions.

The maintenance picture for the open repository is modest. The project has no GitHub releases, so there is no tagged version to pin, and the last push was on 2026-10-11. The repository is not archived. The client library that applications depend on is published separately under the cn.ruleengine group at version 2.0, which is the artefact most integrators actually pin, and that is a separate release stream from this repository's own activity.

Bugs are reported on Gitee and on GitHub, and there is a bug reward mentioned for defects or vulnerabilities found while using the project.

So the practical reading is that the open edition is a working subset with an active but unversioned repository, that the parts you depend on for integration are the separately published client and the HTTP contract, and that the feature direction of the project is set by the commercial platform beside it.

Editorial conclusion

Use rule-engine-open if you want business rules that non developers can change in a browser, you already run Spring Boot with MySQL, Redis and RabbitMQ, and you are willing to run the engine as a separate service that your applications call over HTTP. Do not adopt it expecting an embeddable library, because the modules in this repository are a server, and read the licence terms before using it commercially, since the README states restrictions on the commercial version that go beyond the Apache 2.0 label in the repository metadata. Before deploying, call the execute endpoint with your own rule code, and confirm the access key handling and the workspace separation with whoever owns your credentials.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. Project website
4. README
5. rule-engine/rule-engine-open on GitHub