Eric D. Schabell: JBoss BPM Suite 6.2 - Data models, white list and imports

Friday, December 11, 2015

JBoss BPM Suite 6.2 - Data models, white list and imports

Now that the final product has been released in the form of JBoss BPM Suite 6.2, we thought we might share some insights with you.

When you first take this product for a spin and create a new project, you might be caught by a subtle change. It got me to thinking that I could point out a few of these tips and tricks to your as the product approaches delivery to the public.
Figure 1: 


Data models, white lists and imports

When you initially setup a project, you define the group and artifact id that translates for a developer into the package naming to be used for any data types you add for your data model. 

What you don't see happening in the project is that it automatically generates a package-names-white-list file with an entry that omits all package paths except for the complete group and artifact ids. 

For example, in our JBoss Cool Store project, we have defined the project group id as com.redhat and the artifact id as coolstore, see figure 1.  

The auto generated package-names-white-list file appears as shown in figure 2, containing an entry of com.redhat.coolstore.**. 

Figure 2: auto generated white list file.

The product documentation describes its function as:

"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."

Figure 3: the data model and package layout.
This means that only data types from our data model that are given the full package name will be available in the list for use in rules, decision tables and other artifacts we want to create.

To explain what this means you have to look at what you are capable of doing when designing a rule and need to import part or all of your data model. 

We will walk you though this using an example where we are building the Cool Store with just a two object data model and a rule that needs to import the entire model.

Default out of the box we have create the project as described above, the package-names-white-list file contains the filtering entry as described above and the data model is as follows (shown in figure 3):
  • com.redhat.coolstore.Product
  • com.redhat.ShoppingCart
  • Figure 4: entire data model is now available for import.
  • com.TestObject
We then create a guided rule and check what is available for import and see that there is but one element of our data model available, com.redhat.coolstore.Product. 

This is conform expectations, but we have a problem as our business user happened to create part of the model in different packaging areas. 

This could also be due to the data model being uploaded from a different project, putting it outside the filtered com.redhat.coolstore location.

The question is how can we make the rest of our data model available in the import lists?

Looking to Automate your business?
In this case we need access to all of the data model so we remove the filter line in package-names-white-list file and see in figure 4 that all of our data model is now being made available for import.

This article should provide good insight into the default filtering of your data models when importing into your rules, events and process project artifacts during design time.

No comments:

Post a Comment

Note: Only a member of this blog may post a comment.