Red Hat Training
A Red Hat training course is available for JBoss Enterprise SOA Platform
Chapter 21. JBoss Developer Studio
21.1. The Rules Integrated Development Environment (IDE)
21.2. Rules IDE Features
- Textual/graphical rule editor
- An editor that is aware of DRL syntax, and provides content assistance (including an outline view)
- An editor that is aware of DSL (domain specific language) extensions, and provides content assistance.
- RuleFlow graphical editorYou can edit visual graphs which represent a process (a rule flow). The RuleFlow can then be applied to your rule package to have imperative control.
- Wizards for fast creation of
- a "rules" project
- a rule resource, (a DRL file)
- a Domain Specific language
- a decision table
- a ruleflow
- A domain specific language editor
- Create and manage mappings from your user's language to the rule language
- Rule validation
- As rules are entered, the rule is "built" in the background and errors reported via the problem view where possible
21.3. JBoss Rules Runtimes
21.4. Defining a JBoss Rules Runtime
Procedure 21.1. Task
- Create a new session in JBoss Rules.
- Select Window Preferences. A "Preferences" dialog will appear.
- On the left side of this dialog, under the JBoss Rules category, select "Installed JBoss Rules runtimes". The panel on the right should then show the currently defined JBoss Rules runtimes.
- Click on the add button. A dialog will pop up asking for the name of your runtime and the location on your file system where it can be found.
- To use the default jar files from the JBoss Rules Eclipse plugin, create a new JBoss Rules runtime automatically by clicking the Create a new Drools 5 runtime ... button. A file browser will appear, asking you to select the folder on your file system where you want this runtime to be created. The plugin will then automatically copy all required dependencies to the specified folder.
- To use one specific release of the JBoss Rules project, create a folder on your file system that contains all the necessary JBoss Rules libraries and dependencies. Give your runtime a name and select the location of this folder containing all the required jars. Click OK.
- The runtime will appear in your table of installed JBoss Rules runtimes. Click on checkbox in front of the newly created runtime to make it the default JBoss Rules runtime. The default JBoss Rules runtime will be used as the runtime of all your JBoss Rules projects that have not selected a project-specific runtime.
- Restart Eclipse if you changed the default runtime and you want to make sure that all the projects that are using the default runtime update their classpath accordingly.
21.5. Selecting a Runtime for JBoss Rules Projects
Procedure 21.2. Task
- Use the
New JBoss Rules Project
wizard to create a new JBoss Rules Project. - Alternatively, convert an existing Java project to a JBoss Rules project using the action by right-clicking on a Java object then clicking the
Convert to JBoss Rules Project
dialogue. The plugin will automatically add all the required jars to the classpath of your project. - Optionally, on the last page of the
New JBoss Rules Project
wizard you can choose to have a project-specific runtime. Uncheck theUse default JBoss Rules runtime
checkbox and select the appropriate runtime in the drop-down box. - To access the preferences and add runtimes, go to the workspace preferences and click
Configure workspace settings ...
. - You can change the runtime of a JBoss Rules project at any time by opening the project properties and selecting the JBoss Rules category. Mark the
Enable project specific settings
checkbox and select the appropriate runtime from the drop-down box. - Click the
Configure workspace settings ...
link. This opens the workspace preferences showing the currently installed runtimes. Use the menu to add new runtimes in this space. If you deselect theEnable project specific settings
checkbox, it will use the default runtime as defined in your global preferences.
21.6. Example Rule Files
21.7. The JBoss Rules Builder
Note
21.8. Creating a New Rule
Procedure 21.3. Task
- Create an empty text .drl file.
- Copy and paste your rule into it.
- Save and exit.
- Alternatively, use the Rules Wizard to create a rule but pressing
Ctrl+N
or by choosing it from the toolbar. - The wizard will ask for some basic options for generating a rule resource. For storing rule files you would typically create a directory src/rules and create suitably named subdirectories. The package name is mandatory, and is similar to a package name in Java. (That is, it establishes a namespace for grouping related rules.)
- Select the options that suit you and click
Finish
.
You now have a rule skeleton which you can expand upon.
21.9. The Rule Editor
Ctrl+Space
.
21.10. JBoss Rules Views
- Working Memory View
- Shows all elements in the JBoss Rules working memory.
- Agenda View
- Shows all elements on the agenda. For each rule on the agenda, the rule name and bound variables are shown.
- Global Data View
- Shows all global data currently defined in the JBoss Rules working memory.
- Audit View
- Can be used to display audit logs containing events that were logged during the execution of a rules engine, in tree form.
- Rete View
- This shows you the current Rete Network for your DRL file. You display it by clicking on the tab "Rete Tree" at the bottom of the DRL Editor window. With the Rete Network visualization being open, you can use drag-and-drop on individual nodes to arrange optimal network overview. You may also select multiple nodes by dragging a rectangle over them so the entire group can be moved around.
Note
The Rete view works only in projects where the JBoss Rules Builder is set in the project´s properties. For other projects, you can use a workaround. Set up a JBoss Rule Project next to your current project and transfer the libraries and the DRLs you want to inspect with the Rete view. Click on the right tab below in the DRL Editor, then click "Generate Rete View".
21.11. Using JBoss Rules Views
Procedure 21.4. Task
- To be able to use JBoss Rules views, create breakpoints in your code by invoking the working memory. For example, the line where you call
workingMemory.fireAllRules()
is an ideal place to place a break. - If the debugger halts at a joinpoint, select the working memory variable in the debug variables view. The available views can then be used to show the details of the selected working memory.
21.12. The Show Logical Structure
21.13. Creating Audit Logs
Procedure 21.5. Task
- To create an audit log, execute the rules engine. You will be given the option of creating a new audit log.
- Enter the following code:
StatefulKnowledgeSession ksession = kbase.newStatefulKnowledgeSession(); // Create a new Knowledge Runtime Logger, that logs to file. // An event.log file is created in the subdirectory log dir (which must exist) of the working directory KnowledgeRuntimeLogger logger = KnowledgeRuntimeLoggerFactory.newFileLogger( ksession, "log/event"); ksession.insert(...); ksession.fireAllRules(); // stop logging logger.close();
- Open the log by clicking the Open Log action, the first icon in the Audit View, and select the file. The Audit View now shows all events that where logged during the executing of the rules.
21.14. Event Icons in Audit View
Table 21.1. Event Icons in Audit View
Icon | Description |
---|---|
Green square | Object has been inserted. |
Yellow square | Object has been updated. |
Red square | Object has been removed. |
Right arrow | Activation has been created. |
Left arrow | Activation has been canceled. |
Blue diamond | Activation has been executed. |
Process icon | Ruleflow has started or ended. |
Activity icon | Ruleflow-group activation or deactivation. |
JBoss Rules icon | Rule or rule package has been added or removed. |
21.15. Methods for Retrieving Causes
- The cause of an object modified or retracted event is the last object event for that object. This is either the object asserted event, or the last object modified event for that object.
- The cause of an activation canceled or executed event is the corresponding activation created event.
Note
21.16. The DSL Editor
21.17. Rule Language Mapping
scope
item indicates where the expression belongs, the when
item indicates the LHS, then the RHS, and the *
item means it can go anywhere. It's also possible to create aliases for keywords.
21.18. Working with Rule Language Mapping
Procedure 21.6. Task
- Open the DSL editor and select the mapping tab.
- Select a mapping item (a row in the table) to see the expression and mapping in the text fields below the table.
- Double click or press the edit button to open the edit dialog.
- Other buttons let you remove and add mappings. Don't remove mappings while they are still in use.
21.19. DSL Translation Components
Table 21.2. DSL Translation Components
Name | Duty |
---|---|
Parser | The parser reads the rule text in a DSL line by line and tries to match some of the Language Expression. After a match, the values that correspond to a placeholder between curly braces (for example, {age}) are extracted from the rule source. |
Placeholders | The placeholders in the corresponding rule expression are replaced by their corresponding value. For example, a natural language expression maps to two constraints on a fact of type Person based on the fields age and location. The {age} and {location} values are then extracted from the original rule text. |
Note
21.20. Tips for Working with Large DRL Files
- Depending on the JDK you use,you can increase the maximum size of the permanent generation. Do this by starting Eclipse with
-XX:MaxPermSize=###m
- Rulesets of 4000 rules or greater should have the permanent generation set to at least 128Mb.
- You can put rules in a file with the
.rule
extension. The background builder will not try to compile them every time there is a change which will help the IDE run faster.
21.21. Creating Breakpoints
Procedure 21.7. Task
- To create breakpoints for easier debugging of rules, open the DRL editor and load the DRL file you wish to use.
- Double-click the ruler of the DRL editor at the line where you want to add a breakpoint. Note that rule breakpoints can only be created in the consequence of a rule. Double-clicking on a line where no breakpoint is allowed will do nothing. A breakpoint can be removed by double-clicking the ruler once more.
- Right-click the ruler. A popup menu will show up, containing the
Toggle breakpoint
action. Note that rule breakpoints can only be created in the consequence of a rule. The action is automatically disabled if no rule breakpoint is allowed at that line. - Click the action to add a breakpoint at the selected line, or remove it if there was one already.
Note
The Debug Perspective contains a Breakpoints view which can be used to see all defined breakpoints, get their properties, enable/disable or remove them, and so on.
21.22. Debugging as a JBoss Rules Application
Procedure 21.8. Task
- Open the DRL Editor.
- Select the main class of your application.
- Right-click on it and select the
Debug As >
sub-menu and selectJBoss Rules Application
.Alternatively, you can also select theDebug ...
menu item to open a new dialog for creating, managing and running debug configurations. - Select the
Drools Application
item in the left tree and click theNew launch configuration
button (leftmost icon in the toolbar above the tree). This will create a new configuration with some of the properties already filled in based on the main class you selected in the beginning. - Change the name of your debug configuration to something meaningful. You can accept the defaults for all other properties.
- Click the
Debug
button on the bottom to start debugging your application. You only have to define your debug configuration once. The next time you run your JBoss Rules application, you can select the previously defined configuration in the tree as a sub-element of the JBoss Rules tree node, and then click the JBoss Rules button. The Eclipse toolbar also contains shortcut buttons to quickly re-execute one of your previous configurations.
After clicking the Debug
button, the application starts executing and will halt if any breakpoint is encountered. Whenever a JBoss Rules breakpoint is encountered, the corresponding DRL file is opened and the active line is highlighted. The Variables view also contains all rule parameters and their value. You can then use the default Java debug actions to decide what to do next: resume, terminate, step over, and so on. The debug view can also be used to inspect the contents of the Working Memory and the Agenda at that time as well. You don't have to select a Working Memory as the current executing working memory is automatically shown.
21.23. Rules IDE Preferences
- Automatically reparse all rules if a Java resource is changed
- Triggers a rebuilding of all the rules when a Java class is modified.
- Allow cross reference in DRL files
- Makes it possible to have a resource in a DRL file reference another resource defined in a different file. For example you could have a rule in a file using a type declared in another file. By enabling this option it will no longer possible to declare the same resource (that is, two rule with the same name in the same package) in two different DRL files.
- Internal Drools classes use
- Allows, disallows or discourages (generating warning) the use of JBoss Rules classes not exposed in the public API.