Available as of Camel 2.13
The optaplanner: component solves the planning problem contained in a message with OptaPlanner.
For example: feed it an unsolved Vehicle Routing problem and it solves it.
The component supports consumer as BestSolutionChangedEvent listener and producer for processing Solution and ProblemFactChange
Maven users will need to add the following dependency to their
pom.xml for this component:
The solverConfig is the classpath-local URI of the solverConfig, for example
You can append query options to the URI in the following format,
URI Options (since v 2.16)
The endpoint keeps a map of Solver instances. solverId specifies a the map key to use.
Specifies the size the of thread pool to use for processing async Solution messages.
Specify whether to use another thread for submitting Solution instances rather than blocking the current thread.
Message Headers (since v 2.16)
|CamelOptaPlannerSolverId||null||String||Shared||Specifies the solverId to use|
|CamelOptaPlannerIsAsync||PUT||String||Producer||Specify whether to use another thread for submitting Solution instances rather than blocking the current thread.|
Camel takes the planning problem for the IN body, solves it and returns it on the OUT body.
(since v 2.16) The IN body object supports the following use cases:
- If the body is instance of Solution, then it will be solved using the solver identified by solverId and either synchronously or asynchronously.
- If the body is instance of ProblemFactChange, then it will trigger addProblemFactChange. If the processing is asynchronously, then it will wait till isEveryProblemFactChangeProcessed before returning result.
- If the body is none of the above types, then the producer will return the best result from the solver identified by solverId
The solving will take as long as specified in the
Solve an planning problem that's on the ActiveMQ queue with OptaPlanner:
Expose OptaPlanner as a REST service: