Show Table of Contents
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.
Figure 6.1. The asset editor - Edit tab
Source tab
Source tab shows the DRL source for a selected asset.
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.
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.
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
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:
- WhenThe 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.
- ThenThe 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.
- OptionalOptional 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
- 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.
- 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.
- 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
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.Add the Field
Expand the fact type by clicking the plus sign next to it and select Add Field.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.
Figure 6.5. Technical Rule (DRL)
Where did the comment section go?
Red Hat's documentation publication system recently went through an upgrade to enable speedier, more mobile-friendly content. We decided to re-evaluate our commenting platform to ensure that it meets your expectations and serves as an optimal feedback mechanism. During this redesign, we invite your input on providing feedback on Red Hat documentation via the discussion platform.