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
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
Source tab
Source tab shows the DRL source for a selected asset.
Figure 6.3. 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
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
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.Personandcom.redhat.finance.Salaryare allowed, butcom.redhat.finance.senior.Managementare not allowed. -
com.redhat.finance.*: allows facts from the sub-packages of the com.redhat.finance package only. Thus,
com.redhat.finance.senior.Managementandcom.redhat.finance.junior.Managementare allowed, but notcom.redhat.finance.Person. -
com.redhat.finance.**: this is a combination of the above two rules. Allows
com.redhat.finance.Personandcom.redhat.finance.senior.Managementand even,com.redhat.finance.really.senior.Managementclasses.
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
- 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: 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 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)
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.