During runtime, when an attribute's value is updated by rules, the update is communicated back to the business object by way of Listener classes. Listener classes are compiled at deployment time when Corticon Server detects a Ruleflow using Java Object Messaging. Once compiled, these Listener classes are also added to the .eds file, which is the compiled, executable version of the .erf. This process ensures that Corticon Serverknows how to properly update the objects it receives during an invocation. Because the update process uses compiled Listener classes instead of Java Reflection, the update process occurs very quickly in runtime.
Even though Java Object metadata was imported into Corticon Studio for purposes of mapping the Vocabulary, and those mappings were included in the Rulesheet and Ruleflow assets, the Listener classes, like the rest of the .erf, is not compiled until deployment time. As a result, the same Java business object classes must also always be available to Corticon Server during runtime.
Corticon Server assumes it will find these classes on your application server's classpath. If it cannot find them, Listener class compilation will fail, and your deployed Ruleflow will be unable to process transactions using Java business objects as payload data.
If a Ruleflow (.erf) is deployed to Corticon Serverwithout compiled Listeners, then it will accept only invocations with XML payloads, and reject invocations with Java object payloads. When invoked with Java object payloads, Corticon Server will return an exception, as shown in the following figure:
Figure 299. Server Error Message When Listeners Not Present
