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 Editor, Overview, Source, and Data Objects tabs.

Editor tab

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

Figure 6.1. The Asset Editor - Edit tab

A screen shot of the asset editor - edit tab

Overview tab

The Overview 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.

Figure 6.2. The Asset Editor - Overview tab

A screen shot of the asset editor - Overview tab

Source tab

Source tab shows the DRL source for a selected asset.

Figure 6.3. The Asset Editor - Source tab

A screen shot of the asset editor - source tab

Data Objects Tab

The Data Objects 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.

Figure 6.4. The Asset Editor - Data Objects tab

A screen shot of the asset editor - config 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

You can narrow down the facts available during rule creation and modification by using a file called package-names-white-list. This file allows you to narrow down a group of facts that are loaded and are visible. This helps to speed up the loading of these facts while creating new rules.

When you create a new project in the root directory, an empty package-names-white-list file is automatically created along with the pom.xml and project.imports project files. For existing projects, you need to create this file manually. In Business Central, you can view this file through the repository view of a project in the Project Explorer.

By default (when the file is empty), all the facts within the project itself are visible while those from the project’s dependencies are restricted.

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.

You can include specific packages from a dependency by adding appropriate entries into the package-names-white-list file. You can also include or remove all packages from specific dependencies. For more information, see Adding Dependencies.

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: 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: 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 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 Red Hat JBoss BRMS user interface. The DRL editor provides syntax highlighting for Java, DRL, and XML.

Figure 6.5. Technical Rule (DRL)

A screenshot of a DRL rule in the Red Hat JBoss BRMS user interface.