[id='executable-model-con_{context}']

= Executable rule models

Rule assets in {PRODUCT} are built from executable rule models by default with the standard `kie-maven-plugin` plugin. Executable rule models are embedded models that provide a Java-based representation of a rule set for execution at build time. The executable model is a more efficient alternative to the standard asset packaging in previous versions of {PRODUCT} and enables KIE containers and KIE bases to be created more quickly, especially when you have large lists of DRL (Drools Rule Language) files and other {PRODUCT} assets.

If you do not use the `kie-maven-plugin` plugin or if the required `drools-model-compiler` dependency is missing from your project, then rule assets are built without executable models. Therefore, to generate the executable model during build time, ensure that the `kie-maven-plugin` plugin and `drools-model-compiler` dependency are added in your project `pom.xml` file.

Executable rule models provide the following specific advantages for your projects:

* *Compile time:* Traditionally, a packaged {PRODUCT} project (KJAR) contains a list of DRL files and other {PRODUCT} artifacts that define the rule base together with some pre-generated classes implementing the constraints and the consequences. Those DRL files must be parsed and compiled when the KJAR is downloaded from the Maven repository and installed in a KIE container. This process can be slow, especially for large rule sets. With an executable model, you can package within the project KJAR the Java classes that implement the executable model of the project rule base and re-create the KIE container and its KIE bases out of it in a much faster way. In Maven projects, you use the `kie-maven-plugin` plugin to automatically generate the executable model sources from the DRL files during the compilation process.
* *Run time:* In an executable model, all constraints are defined as Java lambda expressions. The same lambda expressions are also used for constraints evaluation, so you no longer need to use `mvel` expressions for interpreted evaluation nor the just-in-time (JIT) process to transform the `mvel`-based constraints into bytecode. This creates a quicker and more efficient run time.
* *Development time:* An executable model enables you to develop and experiment with new features of the {RULE_ENGINE} without needing to encode elements directly in the DRL format or modify the DRL parser to support them.

[NOTE]
====
For query definitions in executable rule models, you can use up to 10 arguments only.

For variables within rule consequences in executable rule models, you can use up to 24 bound variables only (including the built-in `drools` variable). For example, the following rule consequence uses more than 24 bound variables and creates a compilation error:

[source]
----
...
then
  $input.setNo25Count(functions.sumOf(new Object[]{$no1Count_1, $no2Count_1, $no3Count_1, ..., $no25Count_1}).intValue());
  $input.getFirings().add("fired");
  update($input);
----
====
