Inspiration
RuleMigration began with a problem I know well from my work as a Java developer: legacy business-rule systems are difficult to modernize because the code is only part of the truth. The real behavior is distributed across Java classes, database-backed rules, execution phases, mutable state, and years of accumulated assumptions.
What it does
This is a business rules engine. Each work-order entering the system represent work done that needs to be homologated before it's send to the accountant departament to be process for pay. The engine uses a number of rules that can modify the the "activities" to be paid by removing, adding, replacing, or modifying them. Rules are grouped by priority (agenda-groups). Within each group, rules do not follow a particular order. The agenda-groups run sequentially and in order. At the end of the process, a mutated work-order is ready for human analyst to inspect them. They have the final decission on what will be paid.
How we built it
Before using Codex, I had to make the legacy fragment runnable and safe to share. I removed unrelated production structures, replaced all data with synthetic data, prepared a local Oracle environment, and selected a smaller set of rules. Codex did considerably more than accelerate boilerplate. It:
- analyzed the reduced legacy implementation;
- created characterization tests;
- produced an incremental migration plan;
- implemented the migration in 19 reviewed steps. ChatGPT acted as a technical reviewer and migration-planning partner throughout the project. It helped to interpret Codex’s findings, challenge scope growth, identify missing runtime and operational concerns, and distinguish what the tests actually proved from what still required manual verification.
Challenges we ran into
During step 11, Codex started to have problem, many failed tests, many compiling issues. He requested authorization to enter Maven .m2 repository to analyze some of the dependencies. He used that information to refactor many classes. At that point I increased effort to high and asked Codex to revise this step again. He found a few problems with the previous implementation and fixed them. From that point on, I kept Codex at high effort level. Another challenge was explaining to Codex some of the domain reasons why rules should behave the way they do, what constituted legitimate defects, which were actually domain decissions that should persist in the new rules service.
Accomplishments that we're proud of
The first, and most important, is that the migrated engine works, preserving the required behavior. Later, Codex, guided by me, introduced a few improvements with respect to the legacy project allowed by the move from traditional DRL with conventional KIE sessions to the Rule Unit model.
What we learned
By the end of the project we learned that the migration was possible, even desirable in a future because of the characteristics of the Rule Unit model that fits better with the nature of the original rules engine. However, the strongest result that both codex and I arrived independently is that this migration posses significant risks and should not be the first step of the engine's modernization. A first step should be migrate Java, Spring Boot, and Drools to newer versions, but keep the traditional DRL and KIE session implementation. Once that step is stable, then we can consider a second step with Rule Units.
What's next for RuleBridge
What this prototype does not prove
- It is not connected to a shared or production-like Oracle environment.
- The administrative refresh and work-order execution endpoints are not authenticated or authorized.
- It does not provide final OCP manifests, secret injection, health groups, monitoring, alerting, or an operational rollback runbook.
- It has not undergone production-scale performance or repeated-refresh memory qualification.
Log in or sign up for Devpost to join the conversation.