CurationEngine
Fullstack and platform engineering work on a Drools and Business Central-based curation engine around the Lufthansa Cargo smartBooking / Cargo Booking API.
Fullstack Software Engineer at Lufthansa Industry Solutions, Jan 2024 - 2025
- Drools
- rule execution
- KIE
- runtime containers
- CI/CD
- rule deployments
Work overview
A quick read on where the work sat, what made it hard, what I owned, and what changed.
Context
CurationEngine sat around the smartBooking / Cargo Booking API as a rule-driven decision service. Instead of hardcoding every cargo-booking condition inside the Java API, rule assets were authored and managed through Business Central, packaged as Maven/KJAR artifacts, deployed to KIE Server, and executed by Drools.
What was hard
Cargo-booking rules change more often than core API contracts. The platform needed a governed way to author, test, version, deploy, observe, and roll back booking logic without destabilizing the Booking API.
My part
I worked across implementation, integration, and platform ownership: backend service interaction, Business Central and KIE Server configuration, Maven artifact handling, CI/CD workflows, containerized runtime deployment, runtime properties, secrets, health checks, logs, and release troubleshooting.
What changed
The platform helped turn volatile cargo-booking logic into managed rule artifacts with controlled promotion across environments and a clearer operational path when deployments or runtime integrations failed.
Constraints that mattered
- Rule changes could affect booking eligibility, warnings, rejected options, or fallback behavior.
- Business Central, KIE Server, Maven repositories, containers, credentials, and API integration had to be aligned per environment.
- Troubleshooting needed enough logging and correlation to understand whether a failure came from an artifact, container, runtime property, API call, or environment difference.
- Rule behavior had to be explainable across business tooling, API integration, runtime config, and operations.
Approach
Make rules deployable software
The rules were treated like versioned deployable artifacts, not loose configuration. Builds, artifact publishing, promotion, and rollback were part of the platform work.
Stabilize the runtime boundary
KIE Server connectivity, runtime containers, service credentials, Maven resolution, and environment-specific properties needed to be repeatable across non-production and production setups.
Debug the whole chain
Failures could happen in rule packaging, container startup, Business Central/KIE communication, artifact resolution, or the Booking API integration, so observability had to cover more than application logs.
Key decisions
A few engineering choices that shaped the implementation and delivery path.
Externalize volatile booking logic
Cargo booking policies can change faster than the core API should be released.
Business-rule changes could be packaged, deployed, promoted, and rolled back separately from API code changes.
Use Maven/KJAR artifacts as the release unit
Rule assets still need traceable versions, reproducible builds, and clear promotion between environments.
The runtime could execute a known rule-container version instead of an ambiguous set of manual changes.
Treat runtime diagnostics as platform work
A wrong rule result is hard to investigate without artifact version, container status, request context, logs, and deployment history.
Troubleshooting became more concrete across KIE Server startup, artifact resolution, API integration, and environment drift.
What I did
Built
- CI/CD workflows for rule artifacts and platform services around Drools/KIE deployments.
- Environment-specific setup for Business Central, KIE Server, runtime containers, Maven artifacts, and service configuration.
- Container deployment support with runtime properties, secrets, health checks, and release diagnostics.
Improved
- Promotion and rollback paths for cargo-booking rule changes.
- Observability through logs, health checks, runtime status, and deployment troubleshooting.
- Separation between fast-changing business rules and the core Booking API release cycle.
Owned
- End-to-end engineering support from rule authoring and backend integration to packaging and runtime execution.
- Troubleshooting of rule-runtime deployments, Maven artifact resolution, KIE Server connectivity, and configuration differences.
- Clear explanation of runtime boundaries, artifact versions, environment differences, and support paths.
Rule-driven cargo booking decision service
A sanitized architecture view of how authored rules became executable booking decisions.
Business Central
Rule authoring, governance, test scenarios, project versioning, and deployment management.
Maven / KJAR
Packaged rule artifacts with metadata and KIE configuration for repeatable releases.
KIE Server / Drools
Runtime containers executing rules against booking, shipment, route, product, and customer facts.
smartBooking API
Java/REST integration sending booking context and receiving curated booking decisions.
Delivery & Operations
CI/CD, environment config, containers, secrets, logs, metrics, release support, and rollback.
Learnings
- Rule engines create value only when the delivery lifecycle is as disciplined as normal application releases.
- For decision services, the artifact version is part of the business answer; without it, debugging becomes guesswork.
- The most useful engineering work often sits at the boundary between business tooling, backend APIs, runtime configuration, and operations.