Code generators and client execution code

Rule Designer provides code generators in client projects to execute a specified ruleset. If the provided generators do not match your needs when your RuleApp is deployed on both test and production platforms, you can customize a generator or write the execution code in your own client project.

After you have defined and developed business rules, the next step is to create a client application. The client application must call Rule Execution Server and locate the ruleset that you deployed. To call a deployed ruleset, you must use the public API to start a rule session from your client application. A Client project for RuleApps is a predefined project for Eclipse that contains execution code to call rulesets contained in a RuleApp on Rule Execution Server. These clients can be Java™ applets running in a web browser or Java technology-based programs. You choose the code generator that best matches your needs. Alternatively, you can write the execution code in your own client project using the appropriate rule session factory.

Code generation templates

Code generators are provided for simple Java models (POJO) and for web services. The following table lists the code generation templates that you can use to integrate the calling code into your application.

Table 1. Code generation templates
Code generator	Target users	Purpose
POJO generator	For Java EE experts or performance-sensitive users.	Highly customizable. See Customizing execution code generators.
Web service generator (compatible with JDK 6)	For non-developers who want to author rules and make them available as executable web services.	To generate a web decision service or a monitored transparent decision service. This generator is particularly suited to Service-Oriented Architecture (SOA) or Business Process Management (BPM) projects that use an XML-centric data model. The Rule Execution Server console can make rulesets that process XML or Java types automatically available as web services. Such implementation relies on SOAP with Attachments API for Java (SAAJ) so that the code can run on any SAAJ-compliant platform.
Web service JAX-WS 2.1.1 generator	For forward-looking, standards-based users	JAX-WS 2.1.1 RI is provided in the distribution and can be deployed to Tomcat 7.0. Java types are serialized and deserialized through the standard JAXB APIs.
Service Component Architecture (SCA) generator		To generate an SCA archive based on a RuleApp project and export it to Rational® Application Developer. See Generating an SCA archive for Rational Application Developer.

The following diagram illustrates the code generation options.

Shows the options for code generation when integrating the rule engine into an application

Deciding how to choose a code generator

The following figure shows the decision pathway: choose a code generator for your client project or write the execution code yourself.

Flow chart to choose the cod generator for client projects

Before you choose the appropriate factory and rule session, make the choice between Java SE and Java EE. On Java EE, consider whether the call is local or remote, and whether you require transactions.

If you want to use Java SE, then create a Java Project for Rules and use the IlrJ2SESessionFactory class to write the execution code to call the rule session.
On Java EE, you must choose the type of rule session.
- For a remote call, always use the class IlrEJB3SessionFactory and the setRemote(true) method. This factory method enables calls via RMI-IIOP with EJBs. Use a web-service code generator if you want to use EJBs, and customize the execution code for your needs. Use message-driven rule beans (MDB) and the Java Message Service (JMS) if you need asynchronous execution in Java EE containers.
- For a local call, your choice is based on the need for transactions. If you need transactions, use the class IlrEJB3SessionFactory and the setRemote(false)method. If you do not need transactions and your application requires only a simple Java object model, use the IlrPOJOSessionFactory class. This factory creates POJO rule sessions and avoids the cost of the EJB layer. In the Client Project for RuleApps wizard, use a POJO code generator to generate the client code.

Checking execution

You can use a number of features to check the results of your execution. Decision Validation Services provides a way for you to test your results against an expected result in a controlled and measurable way. For more information, see Testing with Decision Validation Services.

However, even without Decision Validation Services, Rule Execution Server provides some basic reporting to help you make some rapid conclusions about the success of your execution.

Execution trace: You can request a report of the execution from the calling client. This report is called a trace. Execution traces provide some details on the number of rules executed and the time that the ruleset took to execute. For more information, see Setting up ruleset execution traces.
Statistics: In the Rule Execution Server console, you can generate statistics for an executed ruleset. For more information, see Generating ruleset statistics.
Debug trace and configuration: By using the XU debug trace, you can see whether the XU configuration is working optimally. You can configure the trace to different levels depending on the amount of detail that is required. For more information, see Viewing execution unit (XU) debug traces.
To debug a Client Project for RuleApps, use the debug launch configuration for a remote Java application for rules.
Memory usage: You can retrieve the XU memory usage using the API. For more information, see Retrieving the execution unit (XU) memory usage.
Interceptors: You can also implement a ruleset interceptor and activate an execution trace from within the client. For more information, see Ruleset interceptors.