6.2. The asset editor

6.2.1. The asset editor

The asset editor provides access to information about assets and gives users the ability to edit assets.
The editor contains Edit, Source, Config and metadata tabs.
Edit tab

The edit tab is where assets can be edited. The available options in the edit tab will depend on the type of asset being edited.

A screen shot of the asset editor - edit tab

Figure 6.1. The asset editor - Edit tab

Source tab

Source tab shows the DRL source for a selected asset.

A screen shot of the asset editor - source tab

Figure 6.2. The asset editor - Source tab

Config tab

The config tab suggests the set of imports used in the project. Each asset has its own imports and suggest fact types that the user might want to use.

A screen shot of the asset editor - config tab

Figure 6.3. The asset editor - Config tab

Metadata tab

The Metadata screen displays the generic data and version history of an asset. It allows a user to edit other metadata details, add descriptions and discussions which are specific to a selected asset.

A screen shot of the asset editor - metadata tab

Figure 6.4. The asset editor - Metadata tab

6.2.2. Business rules with the guided editor

Business rules are edited in the guided editor. Rules edited in the guided editor use the Business Rules Language (BRL) format. The guided editor prompts users for input based on the object model of the rule being edited.
A package must exist for assets to be added to before rules can be created. Package access must be configured before users can use the BRL guided editor.

Example 6.1. The guided editor

A screen shot of the guided editor

6.2.3. Narrowing Facts Using Package White List

Starting with 6.1, the facts available during rule creation and modification can be narrowed down using a file called the package-names-white-list.
The use of this file allows a developer to narrow down the group of facts that are loaded and are therefore, visible. This helps in speeding up the loading of these facts while creating new rules.
This file is created automatically on the creation of a new project in the root directory, along with the pom.xml and project.imports project files. For existing projects, you may create this file manually.
In Business Central, you can view this file by opening up the repository view of a project in the Project Explorer. As expected, the default file that is automatically created is empty. An empty file doesn't restrict any facts.

Rules for Defining Packages

The package-names-white-list file is a text file that accepts single package names on each line. Packages can contain wildcards as defined below:
com.redhat.finance: allows facts from only the com.redhat.finance package. Thus, com.redhat.finance.Person and com.redhat.finance.Salary are allowed, but com.redhat.finance.senior.Management are not allowed.
com.redhat.finance.*: allows facts from the sub-packages of the com.redhat.finance package only. Thus, com.redhat.finance.senior.Management and com.redhat.finance.junior.Management are allowed, but not com.redhat.finance.Person.
com.redhat.finance.**: this is a combination of the above two rules. Allows com.redhat.finance.Person and com.redhat.finance.senior.Management and even, com.redhat.finance.really.senior.Management classes.

6.2.4. The Anatomy of a Rule

A rule consists of multiple parts:
  • When
    The When part of the rule is the condition that must be met. For instance, a bank providing credit in the form of a loan may specify that customers must be over twenty-one years of age. This would be represented by using when to determine if the customer is over twenty-one years of age.
  • Then
    The Then part of the rule is the action to be performed when the conditional part of the rule has been met. For instance, when the customer is under twenty-one years of age, then decline the loan because the applicant is under age.
  • Optional
    Optional attributes such as salience can be defined on rules.
With the guided editor, it is possible to add more conditions to the When (or conditional) part of the rule and more actions to the Then (or action) part of the rule. For instance, if an applicant under the age of 21 had a guarantor for a loan application, the bank may decide to approve the loan application.

6.2.5. Salience

Each rule has a salience value which is an integer value that defaults to zero. The salience value represents the priority of the rule with higher salience values representing higher priority. Salience values can be positive or negative.

6.2.6. Adding Conditions or Actions to Rules

Procedure 6.2. Adding Conditions or Actions to Rules

  1. Click the plus icon in the When section of the guided editor to add a condition, or click the plus icon in the Then section of the guided editor to add an action.
  2. Select the condition or action from the menu and click Ok. If the package the rule belongs to has been configured to include DSL (Domain Specific Language) sentences, DSL sentences can be chosen from the menu.
  3. If the condition or action requires input, i.e., a date, true or false, am integer, or other input type, enter the required value.

6.2.7. Adding a Field to a Fact Type

With the guided editor, it is possible to add more conditions to the 'when' (or conditional) part of the rule and more actions to the 'then' (or action) part of the rule. For instance, if a loan applicant under the age of 21 had a guarantor for a loan application, the bank may decide to approve the loan application.
To add the guarantor to the condition, it is first necessary to add the guarantor field to the application fact type for the mortgage model.

Procedure 6.3. Adding a Field to a Fact Type

  1. Select the Model

    From the Project Explorer, select the Project and expand the package that contains the model.
    Select and Open the model from the list by clicking over it.
  2. Add the Field

    Expand the fact type by clicking the plus sign next to it and select Add Field.
  3. Enter the Field Details

    Add the details to the pop up dialogue. In this case, enter the name guarantor in the Field name field and select True or False from the Type drop down menu.
    Save the changes made to the model by selecting File and Save changes.
With the guarantor field now added to the applicant fact type, it is possible to modify the rule to include a guarantor.

6.2.8. Technical Rules (DRL)

Technical (DRL) rules are stored as text and can be managed in the Red Hat JBoss BRMS user interface. A DRL file can contain one or more rules. If the file contains only a single rule, then the package, imports and rule statements are not required. The condition and the action of the rule can be marked with "when" and "then" respectively.
Red Hat JBoss Developer Studio provides tools for creating, editing, and debugging DRL files, and it should be used for these purposes. However, DRL rules can be managed within the JBoss BRMS user interface.
A screenshot of a DRL rule in the JBoss BRMS user interface.

Figure 6.5. Technical Rule (DRL)