OptaPlanner's input and output data (the planning problem and the best solution) are plain old JavaBeans (POJO's), so integration with other Java technologies is straightforward. For example:
To read a planning problem from the database (and store the best solution in it), annotate the domain POJO's with JPA annotations.
To read a planning problem from an XML file (and store the best solution in it), annotate the domain POJO's with XStream or JAXB annotations.
To expose the Solver as a REST Service that reads the planning problem and responds with the best solution, annotate the domain POJO's with XStream or JAXB annotations and hook the
Solverin Camel or RESTEasy.
Enrich the domain POJO's (solution, entities and problem facts) with JPA annotations to store them in a database.
Note
Do not confuse JPA's @Entity annotation with OptaPlanner's
@PlanningEntity annotation. They can appear both on the same class.
Enrich the domain POJO's (solution, entities and problem facts) with XStream annotations to serialize them to/from XML.
Camel is an enterprise integration framework which includes support for OptaPlanner (starting from Camel 2.13). It can expose OptaPlanner as a REST service, a SOAP service, a JMS service, ...
Read the documentation for the camel-optaplanner component. That component works in Karaf too.
OptaPlanner's jars include OSGi metadata to function properly in an OSGi environment too.
Note
OptaPlanner does not require OSGi. It works perfectly fine in a normal Java environment too.
OptaPlanner does not work out-of-the-box on Android yet, because it is not a complete JVM. For more information and workarounds, see this issue.
A good OptaPlanner implementation beats any good human planner for non-trivial datasets. Many human planners fail to accept this, often because they feel threatened by an automated system.
But despite that, OptaPlanner can benefit from a human planner as supervisor:
The human planner defines and validates the score function of OptaPlanner.
Some examples expose a
*Parametrizationobject, which defines the weight for each score constraint. The human planner can then tweak those weights at runtime.When the business changes, the score function often needs to change too. The human planner can notify the developers to add, change or remove score constraints.
The human planner is always in control of OptaPlanner.
As shown in the course scheduling example, the human planner can lock 1 or more planning variables to a specific planning value and make those immovable. Because they are immovable, OptaPlanner does not change them: it optimizes the planning around the enforcements made by the human. If the human planner locks all planning variables, he/she sidelines OptaPlanner completely.
In a prototype implementation, the human planner might use this occasionally. But as the implementation matures, it must become obsolete. But do keep the feature alive: as a reassurance for the humans. Or in case that one day the business changes dramatically before the score constraints can be adjusted.
Therefore, it's often a good idea to involve the human planner in your project.