JBoss.orgCommunity Documentation

Chapter 9. Workbench

9.1. Installation
9.1.1. War installation
9.1.2. Workbench data
9.1.3. System properties
9.2. Quick Start
9.2.1. Add repository
9.2.2. Add project
9.2.3. Define Data Model
9.2.4. Define Rule
9.2.5. Build and Deploy
9.3. Configuration
9.3.1. User management
9.3.2. Roles
9.3.3. Command line config tool
9.4. Administration
9.4.1. Administration overview
9.4.2. Organizational unit
9.4.3. VFS repository
9.5. Introduction
9.5.1. Log in and log out
9.5.2. Home screen
9.5.3. Workbench concepts
9.5.4. Initial layout
9.6. Changing the layout
9.6.1. Resizing
9.6.2. Repositioning
9.7. Authoring
9.7.1. Artifact Repository
9.7.2. Asset Editor
9.7.3. Project Explorer
9.7.4. Project Editor
9.7.5. Validation
9.7.6. Data Modeller
9.7.7. Categories Editor

Here's a list of all system properties:

To change one of these system properties in a WildFly or JBoss EAP cluster:

These steps help you get started with minimum of effort.

They should not be a substitute for reading the documentation in full.

Provides capabilites to manage the system repository from command line.

The default layout may not be suitable for a user. Panels can therefore be either resized or repositoned.

This, for example, could be useful when running tests; as the test defintion and rule can be repositioned side-by-side.

Projects often need external artifacts in their classpath in order to build, for example a domain model jars. The artifact repository holds those artifacts.

The Artifact Repository is a full blown Maven repository. It follows the semantics of a Maven remote repository: all snapshots are timestamped. But it is often stored on the local hard drive.

By default the artifact repository is stored under $WORKING_DIRECTORY/repositories/kie, but it can be overridden with the system property -Dorg.guvnor.m2repo.dir. There is only 1 Maven repository per installation.

The Artifact Repository screen shows a list of the artifacts in the Maven repository:

To add a new artifact to that maven repository, either:

  • Use the upload button and select a jar. If the jar contains a pom file under META-INF/maven (which every jar build by Maven has), no further information is needed. Otherwise, a groupId, artifactId and version need be given too.

  • Using Maven, mvn deploy to that Maven repository. Refresh the list to make it show up.


This remote Maven repository is relatively simple. It does not support proxying, mirroring, ... like Nexus or Archiva.

The Asset Editor is the principle component of Guvnor's User-Interface. It consists of two main views Edit and Metadata.

The Project Explorer provides the ability to browse diffeent Organizational Units, Repositories, Projects and their files.

The Project Editor screen can be accessed from the Project menu. Project menu shows the settings for the currently active project.

Unlike most of the workbench editors, project editor edits more than one file. Showing everything that is needed for configuring the KIE project in one place.

By default, a data model is always constrained to the context of a project. For the purpose of this tutorial, we will assume that a correctly configured project already exists.

To start the creation of a data model inside a project, take the following steps:

This will start up the Data Modeller tool, which has the following general aspect:

The Data Modeller panel is divided into the following sections:

A data model consists of data entities which are a logical representation of some real-world data. Such data entities have a fixed set of modeller (or application-owned) properties, such as its internal identifier, a label, description, package etc. Besides those, an entity also has a variable set of user-defined fields, which are an abstraction of a real-world property of the type of data that this logical entity represents.

Creating a data entity can be achieved either by clicking the "Create" button in the model browser section (see fig. "The data model browser" above), or by clicking the one in the top data modeller menu:

This will pop up the new object screen:

Some initial information needs to be provided before creating the new object:

  • The object's internal identifier (mandatory). The value of this field must be unique per package, i.e. if the object's proposed identifier already exists in the selected package, an error message will be displayed.

  • A label (optional): this field allows the user to define a user-friendly label for the data entity about to be created. This is purely conceptual info that has no further influence on how objects of this entity will be treated. If a label is defined, then this is how the entity will be displayed throughout the data modeller tool.

  • A package (mandatory): a data entity must always be created within a package (or name space, in which this entity will be unique at a platform level). By default, the option for selecting an already existing package will be activated, in which case the corresponding drop-down shows all the packages that are currently defined. If a new package needs to be defined for this entity, then the "New package" option should be selected. In this case the new to be created package should be input into the corresponding text-field. The format for defining new packages is the same as the one for standard Java packages.

  • A superclass (optional): this will indicate that this entity extends from another already existing one. Since the data modeller entities are translated into standard Java classes, indicating a superclass implies normal Java object extension at the generated-code level.

Once the user has provided at least the mandatory information, by pushing the "Ok" button at the bottom of the screen the new data entity will be created. It will be added to the model browser's entity listing.

It will also appear automatically selected, to make it easy for the user to complete the definition of the newly created entity, by completing the entity's properties in the Data Object Properties browser, or by adding new fields.


As can be seen in the above figure, after performing changes to the data model, the model name will appear with an '*' to alert the user of the existence of un-persisted changes to the model.

In the Data Modeller's object browsing section, an entity can be deleted by clicking upon the 'x' icon to the right of each entity. If an entity is being referenced from within another entity (as a field type), then the modeller tool will not allow it to be deleted, and an error message will appear on the screen.

Once the data entity has been created, it now has to be completed by adding user-defined properties to its definition. This can be achieved by providing the required information in the "Create new field" section (see fig. "New field creation"), and clicking on the "Create" button when finished. The following fields can (or must) be filled out:

When finished introducing the initial information for a new field, clicking the 'Create' button will add the newly created field to the end of the entity's fields table below:

The new field will also automatically be selected in the entity's field list, and its properties will be shown in the Field tab of the Property editor. The latter facilitates completion of some additional properties of the new field by the user (see below).

At any time, any field (without restrictions) can be deleted from an entity definition by clicking on the corresponding 'x' icon in the entity's fields table.

As stated before, both entities as well as entity fields require some of their initial properties to be set upon creation. These are by no means the only properties entities and fields have. Below we will give a detailed description of the additional entity and field properties.

The data model in itself is merely a visual tool that allows the user to define high-level data structures, for them to interact with the Drools Engine on the one hand, and the jBPM platform on the other. In order for this to become possible, these high-level visual structures have to be transformed into low-level artifacts that can effectively be consumed by these platforms. These artifacts are Java POJOs (Plain Old Java Objects), and they are generated every time the data model is saved, by pressing the "Save" button in the top Data Modeller Menu.

At this time each entity that has been defined in the model will be translated into a Java class, according to the following transformation rules:

  • The entity's identifier property will become the Java class's name. It therefore needs to be a valid Java identifier.

  • The entity's package property becomes the Java class's package declaration.

  • The entity's superclass property (if present) becomes the Java class's extension declaration.

  • The entity's label and description properties will translate into the Java annotations "@org.kie.workbench.common.services.datamodeller.annotations.Label" and "@org.kie.workbench.common.services.datamodeller.annotations.Description", respectively. These annotations are merely a way of preserving the associated information, and as yet are not processed any further.

  • The entity's role property (if present) will be translated into the "@org.kie.api.definition.type.Role" Java annotation, that IS interpreted by the application platform, in the sense that it marks this Java class as a Drools Event Fact-Type.

A standard Java default (or no parameter) constructor is generated, as well as a full parameter constructor, i.e. a constructor that accepts as parameters a value for each of the entity's user-defined fields.

The entity's user-defined fields are translated into Java class fields, each one of them with its own getter and setter method, according to the following transformation rules:

  • The entity field's identifier will become the Java field identifier. It therefore needs to be a valid Java identifier.

  • The entity field's type is directly translated into the Java class's field type. In case the entity field was declared to be multiple (i.e. '[0..N]'), then the generated field is of the "java.util.List" type.

  • The equals property: when it is set for a specific field, then this class property will be annotated with the "@org.kie.api.definition.type.Key" annotation, which is interpreted by the Drools Engine, and it will 'participate' in the generated equals() method, which overwrites the equals() method of the Object class. The latter implies that if the field is a 'primitive' type, the equals method will simply compares its value with the value of the corresponding field in another instance of the class. If the field is a sub-entity or a collection type, then the equals method will make a method-call to the equals method of the corresponding entity's Java class, or of the java.util.List standard Java class, respectively.

    If the equals property is checked for ANY of the entity's user defined fields, then this also implies that in addition to the default generated constructors another constructor is generated, accepting as parameters all of the fields that were marked with Equals. Furthermore, generation of the equals() method also implies that also the Object class's hashCode() method is overwritten, in such a manner that it will call the hashCode() methods of the corresponding Java class types (be it 'primitive' or user-defined types) for all the fields that were marked with Equals in the Data Model.

  • The position property: this field property is automatically set for all user-defined fields, starting from 0, and incrementing by 1 for each subsequent new field. However the user can freely changes the position among the fields. At code generation time this property is translated into the "@org.kie.api.definition.type.Position" annotation, which can be interpreted by the Drools Engine. Also, the established property order determines the order of the constructor parameters in the generated Java class.

  • The entity's role property (if present) will be translated into the "@org.kie.api.definition.type.Role" Java annotation, that IS interpreted by the application platform, in the sense that it marks this Java class as a Drools Event Fact-Type.

As an example, the generated Java class code for the Purchase Order entity, corresponding to its definition as shown in the following figure purchase_example.jpg is visualized in the figure at the bottom of this chapter. Note that the two of the entity's fields, namely 'header' and 'lines' were marked with Equals, and have been assigned with the positions 2 and 1, respectively).

    package org.jbpm.examples.purchases;
    * This class was automatically generated by the data modeler tool.
    @org.kie.api.definition.type.Role(value =
    @org.kie.workbench.common.services.datamodeller.annotations.Label(value =
    "Purchase Order")
    @org.kie.workbench.common.services.datamodeller.annotations.Description(value =
    "This entity models the client purchase orders.")
    public class PurchaseOrder extends org.jbpm.examples.purchases.parent
    implements java.io.Serializable {
    static final long serialVersionUID = 1L;
    @org.kie.workbench.common.services.datamodeller.annotations.Label(value =
    @org.kie.api.definition.type.Position(value = 0)
    @org.kie.workbench.common.services.datamodeller.annotations.Description(value =
    "A description for this purchase order.")
    private java.lang.String description;
    @org.kie.workbench.common.services.datamodeller.annotations.Label(value =
    @org.kie.api.definition.type.Position(value = 1)
    @org.kie.workbench.common.services.datamodeller.annotations.Description(value =
    "The purchase order items (collection of Purchase Order Line sub-entities).")
    private java.util.List<org.jbpm.examples.purchases.PurchaseOrderLine> lines;
    @org.kie.workbench.common.services.datamodeller.annotations.Label(value =
    @org.kie.api.definition.type.Position(value = 2)
    @org.kie.workbench.common.services.datamodeller.annotations.Description(value =
    "The purchase order header (Purchase Order Header sub-entity).")
    private org.jbpm.examples.purchases.PurchaseOrderHeader header;
    public PurchaseOrder() {}
    public PurchaseOrder(
    java.lang.String description,
    java.util.List<org.jbpm.examples.purchases.PurchaseOrderLine> lines,
    org.jbpm.examples.purchases.PurchaseOrderHeader header )
    this.description = description;
    this.lines = lines;
    this.header = header;
    public PurchaseOrder(
    java.util.List<org.jbpm.examples.purchases.PurchaseOrderLine> lines,
    org.jbpm.examples.purchases.PurchaseOrderHeader header )
    this.lines = lines;
    this.header = header;
    public java.lang.String getDescription() {
    return this.description;
    public void setDescription( java.lang.String description ) {
    this.description = description;
    public java.util.List<org.jbpm.examples.purchases.PurchaseOrderLine>
    return this.lines;
    public void setLines(
    java.util.List<org.jbpm.examples.purchases.PurchaseOrderLine> lines )
    this.lines = lines;
    public org.jbpm.examples.purchases.PurchaseOrderHeader getHeader() {
    return this.header;
    public void setHeader( org.jbpm.examples.purchases.PurchaseOrderHeader
    header )
    this.header = header;
    public boolean equals(Object o) {
    if (this == o) return true;
    if (== null || getClass() != o.getClass()) return false;
    org.jbpm.examples.purchases.PurchaseOrder that =
    if (lines != null ? !lines.equals(that.lines) : that.lines != null)
    return false;
    if (header != null ? !header.equals(that.header) : that.header != null)
    return false;
    return true;
    public int hashCode() {
    int result = 17;
    result = 13 * result + (lines != null ? lines.hashCode() : 0);
    result = 13 * result + (header != null ? header.hashCode() : 0);
    return result;

Using an external model means the ability to use a set for already defined POJOs in current project context. In order to make those POJOs available a dependency to the given JAR should be added. Once the dependency has been added the external POJOs can be referenced from current project data model.

There are two ways to add a dependency to an external JAR file:

It is possible to modify a project's assets externally, i.e. accessing them directly through the project's repository. While NOT a recommended practice, it is important to be aware of the implications this entails.

From an application context's perspective, we can basically identify two different scenarios:

The application user has made changes to the data model. Meanwhile, another user simultaneously modifies the data model from outside the application context.

In this alternative scenario, immediately after the external user commits his changes to the asset repository, a warning is issued to the application user:

As with the previous scenario, the user can choose to either:

Categories allow assets to be labelled (or tagged) with any number of categories that you define. Assets can belong to any number of categories. In the below diagram, you can see this can in effect create a folder/explorer like view of categories. The names can be anything you want, and are defined by the Workbench administrator (you can also remove/add new categories).