| Samples > Rule Engine Integration > How to Handle Multiple Projects |
How to Handle Multiple Projects |
PREVIOUS NEXT |
This sample shows how to handle multiple projects within Rule Studio. This can be useful where development teams in different departments work independently to author and test their own business rules, and where a corporate development team is in charge of defining the global data model of the company, and integrating, testing and deploying the whole application.
By assigning dedicated development teams, each rule project can be developed and tested independently of the others. This kind of modular architecture makes it easier to reuse rule projects in other internal applications.
This sample is based on the following scenario:
A loan company has decided to automate their loan validation process, including validating data from input forms, determining the eligibility of a borrower, and calculating the financial and insurance elements of the loan.
The loan company is organized into four business units:
A corporate development team, acting as a system integrator, is in charge of defining the global data model, integrating, testing and deploying the whole application. Categories and rule template features have been used to assist with rule authoring, since the Business Object Model (BOM) is shared across all departments.
Each department has its own development team in charge of packaging and testing the part of the application that they are in charge of. Each rule project has a corresponding Java project (generated with the New Java Project for Rules Wizard) for local testing purposes.
Key features include:
To import the multipleprojects sample:
samples > architecture > multipleprojects.
You can run each of the projects independently, or you can launch the complete application by running the loanvalidation-orchestration project which uses the other projects. You can test each of the sample projects using either a Java Applications with Rules launcher or a JUnit launcher.
To run the projects individually:
Java Application with Rules section in the list of launch configurations:
Output is displayed in the Console view.
To run the full application:
Java Application with Rules > loanvalidation-orchestration launch configuration, then click Run.
A unit test project is provided for each rule project. Each unit test project has the same name as the project to which it refers, with the suffix -test so that they are easy to locate in Rule Studio's Rule Explorer.
To run an individual project:
JUnit Launcher section in the list of launch configurations:
Output is displayed in the Console view.
To run the full application:
JUnit Launcher > loanvalidation-orchestration-test launch configuration, then click Run.
The highlights of this sample is as follows:
The following image shows you how projects are structured and how they relate to each other.
This project contains the BOM, which defines the actions and entities that can be used in rule artifacts. Before you can start creating and editing rule artifacts, you need to define a BOM containing the classes and methods that rule artifacts act on. In this application, the BOM is shared among all rule projects and contains three entries:
This project also defines the categories used by all other projects. The categories reflect the organization of the project. Members of a particular project team should have access only to a restricted set of BOM elements. For example, the members of the Insurance team should see only insurance related data, and not the loan scoring elements. The categories are listed in the Categories section of the loanvalidation-bom project properties
This project also defines the business rule templates for all projects. A business rule template is a partially written business rule that can be used as a starting point for creating multiple rules with a similar structure. Business rule templates simplify the task of writing business rules and are useful for:
The templates are listed in the Templates section of the loanvalidation-bom project properties.
This project contains rules created with the personalCheck and loanCheck templates. It has loanvalidation-bom as rule project reference. For testing purposes, we included a test ruleflow (rules > validation > test > evaluation). The unit test can be run using the loanvalidation-validation-test project. The project has its own ruleset parameters.
loanvalidation-validation ruleset parameters and corresponding objects referenced in the BOM
Parameter Name |
References |
|---|---|
validation_borrower | loan.Borrower |
validation_loan | loan.Loan |
validation_report | loan.Report |
This project contains rules that use categories to limit which business objects can be used when creating and editing rules. It has loanvalidation-bom as rule project reference. For testing purposes, we included a test ruleflow (rules > computation > test > evaluation). The unit test can be run using the loanvalidation-computation-test project. The project has its own ruleset parameters.
loanvalidation-computation ruleset parameters and corresponding objects referenced in the BOM
Parameter Name |
References |
|---|---|
computation_borrower | loan.Borrower |
computation_loan | loan.Loan |
computation_report | loan.Report |
This project contains rules that use categories to limit which business objects can be used when creating and editing rules. It has loanvalidation-bom and loanvalidation-computation as rule project references. It contains a ruleflow which uses a subflow coming from the loanvalidation-computation project. For testing purposes, we included a test ruleflow (rules > eligibility > test > evaluation). The unit test can be run using the loanvalidation-eligibility-test project. The project has its own ruleset parameters.
loanvalidation-eligibility ruleset ruleset parameters and corresponding objects referenced in the BOM
Parameter Name |
References |
|---|---|
eligibility_borrower | loan.Borrower |
eligibility_loan | loan.Loan |
eligibility_loans | financial.AggregateLoan |
eligibility_report | loan.Report |
This project contains rules created with the insurance template. It has loanvalidation-bom as rule project reference. For testing purposes, we included a test ruleflow (rules > insurance > test > evaluation). The unit test can be run using the loanvalidation-insurance-test project. The project has its own ruleset parameters.
Parameter Name |
References |
|---|---|
insurance_borrower | loan.Borrower |
insurance_loan | loan.Loan |
insurance_report | loan.Report |
The main project is loanvalidation-orchestration. This project contains the main ruleflow for the application. It is built on top of the four other projects.
Each of the projects in our example has its own life cycle and can be used as a stand-alone module. Therefore, each project has its own set of ruleset parameters. Table 9, Summary of ruleset parameters for all projects provides a summary of these parameters:
When we run the application, all parameters must be initialized before executing the loanvalidation-orchestration > rules > orchestration ruleflow. The initialize function task does this using the ParametersHook helper class. This class contains a method that copies parameter values. For example, when calling ParametersHook.assign(?context,"insurance","orchestration"):
insurance_borrower is initialized with the value of orchestration_borrower
insurance_loan is initialized with the value of orchestration_loan
insurance_report is initialized with the value of orchestration_report
A unit test project is provided for each rule project. Each unit test project has the same name as the project to which it refers, with the suffix -test so that it is easy to locate and filter them in the Rule Explorer.
You can test each of the sample projects using either a JUnit launcher or a Java Applications with Rules launcher.
Running a project using the JUnit launcher enables you to create a JUnit test report.
| Note |
Each unit test expects an archive called ruleArchive1.jar to be located in the JUnit project directory.
|
Before running a unit test, you must export the ruleset archive manually from Rule Studio to the JUnit project directory (see Rule Studio User Interface > Wizards > Export Ruleset Archive Wizard). This step would normally be automated in a real development environment, where unit tests are run from a build framework such as Ant (see Samples > Rule Studio Business Rule Management Extensions > How to Extract a Ruleset from a Rule Project).
By running a unit test with a Java Application with Rules launcher, you can declare an extractor that generates the archive ruleset each time you run the test. You can also create a debug session with breakpoints in the ruleflows or in the rules.
See Running and Debugging > Tasks > Creating a Debugger Launch Configuration > Creating a Debugger Launch Configuration for a Java Application with Rules or RuleApps for more information. A main method that runs the test has been added to the generated test class.
To exploit this application once development is complete, we would deploy it to Rule Team Server. A detailed description of the deployment process is outside the scope of this sample but is mentioned here for the sake of completeness and to illustrate how the modular architecture of the project is maintained by Rule Team Server after deployment.
ILOG Rule Team Server is a highly scalable rule management server and repository with a collaborative web environment for authoring, managing, validating, and deploying business rules. Rule Team Server stores rule projects in repositories integrated with the database layer of a Java EE application server. Developers synchronize the rules stored on Rule Team Server with the rules stored in Rule Studio using wizards in Rule Studio.
In the fictitious organization used in our sample, several business user groups are responsible for authoring rules. Depending on their business, they focus on different parts of the application. For example, scoring experts work on the computation of the corporate score of the borrower, so they contribute only to the computation part of the application. The application's different modules reflect this organization.
See Publishing to Rule Team Server for more information about publishing these projects to Rule Team Server.
Rule Team Server helps to protect your projects by restricting access to projects based on user groups. Without security enforcement, any Rule Team Server user can create/update/view/delete any of the elements of a project. Defining user groups within Rule Team Server and applying access permissions to your projects enables you to separate each workgroup, while still leveraging collaborative work.
See the Permission Setup tutorial in the Rule Team Server Online Help for more information about applying security policies to projects in Rule Team Server.
| Copyright © 1987-2008 ILOG S.A. All rights reserved. Legal terms. Documentation homepage. | PREVIOUS NEXT |