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)

The Integrated Development Environment (IDE) provides an environment to edit and test rules in various formats, then integrate them with applications.
The JBoss Rules IDE is delivered as an Eclipse plug-in, which allows you to author and manage rules from within Eclipse, as well as integrate rules with your application. This is an optional tool. The JBoss Rules IDE is also a part of the Red Hat Developer Studio (formerly known as JBoss IDE).

21.2. Rules IDE Features

The rules IDE has the following features:
  1. Textual/graphical rule editor
    1. An editor that is aware of DRL syntax, and provides content assistance (including an outline view)
    2. An editor that is aware of DSL (domain specific language) extensions, and provides content assistance.
  2. RuleFlow graphical editor
    You 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.
  3. Wizards for fast creation of
    1. a "rules" project
    2. a rule resource, (a DRL file)
    3. a Domain Specific language
    4. a decision table
    5. a ruleflow
  4. A domain specific language editor
    1. Create and manage mappings from your user's language to the rule language
  5. Rule validation
    1. 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

A JBoss Rules runtime is a collection of jar files that represents one specific release of the JBoss Rules project jars. To create a runtime, you must point the IDE to the release of your choice. You can also create a new runtime based on the latest JBoss Rules project jars included in the plugin itself. You are required to specify a default JBoss Rules runtime for your Eclipse workspace, but each individual project can override the default and select the appropriate runtime for that project specifically.

21.4. Defining a JBoss Rules Runtime

Procedure 21.1. Task

  1. Create a new session in JBoss Rules.
  2. Select Window Preferences. A "Preferences" dialog will appear.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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

  1. Use the New JBoss Rules Project wizard to create a new JBoss Rules Project.
  2. 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.
  3. Optionally, on the last page of the New JBoss Rules Project wizard you can choose to have a project-specific runtime. Uncheck the Use default JBoss Rules runtime checkbox and select the appropriate runtime in the drop-down box.
  4. To access the preferences and add runtimes, go to the workspace preferences and click Configure workspace settings ....
  5. 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.
  6. 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 the Enable project specific settings checkbox, it will use the default runtime as defined in your global preferences.

21.6. Example Rule Files

A newly created project contains an example rule file (Sample.drl) in the src/rules directory and an example Java file (DroolsTest.java) that can be used to execute the rules in a JBoss Rules engine. This is in the folder src/java, in the com.sample package. All the other jars that are necessary during execution are added to the classpath in a custom classpath container called JBoss Rules Library.

21.7. The JBoss Rules Builder

The JBoss Rules plug-in adds a JBoss Rules Builder capability to your Eclipse instance. This means you can enable a builder on any project that will build and validate your rules when resources change. This happens automatically with the Rule Project Wizard, but you can also enable it manually on any project. To fully validate the rules you will need to run them in a unit test of course.

Note

If you have rule files with more than 500 rules per file, it may result in a slower performance. To counter this, turn off the builder or put the large rules into .rule files where you can still use the rule editor, but it won't build them in the background.

21.8. Creating a New Rule

Procedure 21.3. Task

  1. Create an empty text .drl file.
  2. Copy and paste your rule into it.
  3. Save and exit.
  4. Alternatively, use the Rules Wizard to create a rule but pressing Ctrl+N or by choosing it from the toolbar.
  5. 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.)
  6. Select the options that suit you and click Finish.
Result

You now have a rule skeleton which you can expand upon.

21.9. The Rule Editor

The rule editor is where rule managers and developers are modified. The rule editor follows the pattern of a normal text editor in Eclipse. It provides pop-up content assistance. You can invoke pop-up content assistance by pressing Ctrl+Space.
The rule editor works on files that have a .drl (or .rule) extension. Usually these contain related rules, but it would also be possible to have rules in individual files, grouped by being in the same package namespace. These DRL files are plain text files.

21.10. JBoss Rules Views

You can alternate between these views when modifying rules:
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

  1. 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.
  2. 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

The Show Logical Structure is used with JBoss Rules views. It can toggle showing the logical structure of elements in the working memory or agenda items. Logical structures allow for example visualizing sets of elements in a more obvious way.

21.13. Creating Audit Logs

Procedure 21.5. Task

  1. To create an audit log, execute the rules engine. You will be given the option of creating a new audit log.
  2. 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();
  3. 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

If an event occurs when executing an activation, it is shown as a child of the activation's execution event. You can retrieve the cause in the following events::
  1. 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.
  2. The cause of an activation canceled or executed event is the corresponding activation created event.

Note

When selecting an event, the cause is shown in green in the audit view. You can right-click the action and select the "Show Cause" menu item. This will scroll you to the cause of the selected event.

21.16. The DSL Editor

The DSL editor provides a tabular view of the mapping of Language to Rule Expressions. The Language Expression feeds the content assistance for the rule editor so that it can suggest Language Expressions from the DSL configuration. (The rule editor loads the DSL configuration when the rule resource is loaded for editing.

21.17. Rule Language Mapping

Rule language mapping defines the way which a language expression will be compiled by the rule engine compiler. The form of this rule language expression depends on whether it is intended for the condition or the action part of a rule. (For instance, in the RHS it may be a snippet of Java.) The 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

  1. Open the DSL editor and select the mapping tab.
  2. Select a mapping item (a row in the table) to see the expression and mapping in the text fields below the table.
  3. Double click or press the edit button to open the edit dialog.
  4. 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

If you do not wish to use a language mapping for a particular rule in a drl, prefix the expression with > and the compiler will not try to translate it according to the language definition. Also note that Domain Specific Languages are optional. When the rule is compiled, the .dsl file will also need to be available.

21.20. Tips for Working with Large DRL Files

  1. 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
  2. Rulesets of 4000 rules or greater should have the permanent generation set to at least 128Mb.
  3. 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

  1. To create breakpoints for easier debugging of rules, open the DRL editor and load the DRL file you wish to use.
  2. 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.
  3. 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.
  4. 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

  1. Open the DRL Editor.
  2. Select the main class of your application.
  3. Right-click on it and select the Debug As > sub-menu and select JBoss Rules Application.
    Alternatively, you can also select the Debug ... menu item to open a new dialog for creating, managing and running debug configurations.
  4. Select the Drools Application item in the left tree and click the New 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.
  5. Change the name of your debug configuration to something meaningful. You can accept the defaults for all other properties.
  6. 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.
Result

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

The rules IDE comes with a set of customizable preferences that allow you to configure the following options:
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.