Knowledge Based Runtime UIs Requirements

Drools and jBPM5 conform a Business Logic Integration Platform. This means that the Rules & the Process Engines will share their runtime. If you take a look at the Knowledge Based APIs that the platform provides you will see that the StatefulKnowledgeSession interface is the main entry point to access both engines.  For this reason a need for a unified Assets Repository and a unified set of Runtime UIs is required. This posts describe from a very high level perspective, what in my opinion is a set of Panels (UI Screens) that allows us interact with our session runtimes, no matter where they are located. This post is a follow up to my previous post about Human Task Interactions that you can find here.


Our analysis will start with the assumption that there will be a set of User Interface that will allows us to model/design our Knowledge Assets. We will also asume that we have a centralized repository that allows us to store and organize our Knowledge Assets. Topics like how the assets are organized, stored, indexed and maintained inside the repository are out of the scope for this post.

I will be describing each block of functionality as a decoupled entity, how we mix and match these blocks will depend on the Users needs and requirements. I will provide a default set of perspectives (set of panels together with a predefined layout) just to demonstrate how the usage could be. Several perspective and more use case specific panels can be defined for different scenarios, the important thing here is to understand what information is available and how it can be organized.

Key Concepts

Before starting with the UIs let’s review quickly the main concepts that we want to expose via the application screens:

  • Knowledge Assets: each piece of Business Knowledge that we can model and store inside our business repository. Common examples about Knowledge Assets are: Rules, Processes, Models, Decision Tables, Ontologies, etc
  • Knowledge Base: Selecting a group of Knowledge Assets we can conform a Knowledge Base which will contain all the knowledge required to support a business situation. Usually we will create a Knowledge Base with a well scoped set of Assets (that can be organized in packages or any other logical structure) to solve specific topics. Depending on the business requirements we will decide how many Knowledge Based do we need per Business Unit or Department in our organization.
  • Knowledge Runtime / Session: From one defined Knowledge Base we can create multiple Knowledge Runtimes. Depending on the problem that we are trying to solve and how the knowledge was modeled and designed is how many runtimes we will need to spawn.
  • Knowledge Project: a set of Knowledge Sessions that conforms a logical group of functionality.

Defining Our Runtimes

Based on the previous concepts we can start defining our UI from the Knowledge Project concept:

Knowledge Projects List

As starting point we will have a list of the current projects that we have. This list can be filtered by the status of the project, the period when the project is relevant and also by a higher level concept, like for example the Organization that is running the project.

When we want to start a new project we will need to define the Knowledge Assets and the Runtimes that will be used:

Project Configuration

The Knowledge Bases will be defined based on the content of the repository and it will be composed by Rules, Processes, Models, Etc.

In order to add more assets to a Knowledge Base we will need to upload the assets to a certain path into the repository. The Knowledge Asset explorer reflects the content of the repository and it allows us to access to the Assets Modeling Tools like: The Process Designer, The Guided Rule Editor, The Decision Tables Editor, etc.

Knowledge Asset Explorer

Once we have our Knowledge Base defined, we can quickly create new Runtimes/Sessions to use that Knowledge Base.

From both Knowledge Bases and Knowledge Runtimes we wil have their own Configuration Panels:

KBase & KRuntime Configurations

The following mock up shows the Session Runtime Details view which gives us some statistics about the internal data of the selected session.

Knowledge Runtime Details

Once we have our Sessions defined and running we will need a different set of views to interact with them. The different views will be defined based on the end users roles interested in interacting with them.

Process Views

From the process perspective we will want to create new Process Instances and browse the current ones.

Global Process Instances Explorer

Because now we can have multiple Sessions running different Process Instances, we will need to filter and select the sessions in which are we interested. If we really don’t care where our process instances are running we can just select all the available sessions and hide the Ksession filter.

We can drill down into a selected Process Instance to see in detail what’s the status of that specific instance:

Process Runtime Detail

As you can see, in the previous figure, a set of specific views can be created to interact and browse the Process Instance Details. All these views will include links to the authoring tools, like for example the Process Designer.

A similar set of panels should be also provided for the user that wants to instantiate a fresh process instance. A set of filters based on the available Knowledge Bases should be provided for the user to Select the specific process and the Runtime where it should be instantiated.

Process Definition Explorer & Instantiation

Get Involved

As usual, this is a proposal trying to cover most of the aspect required to interact with Knowledge Runtimes and with a set of views oriented to Business Processes. In the same way, we can provide a different set of panels to handle all the interactions with Rules and Events.

If you think that all the features described here are important, or if you are planning to adopt a solution like the one described in this post please get involved and share your thoughts and extra requirements that you may need. I will start sharing my personal experiments on the basic components exposed in this post. This is a very good opportunity to join forces and help in the creation of these components. If you wanna help and learn in the process please write a comment here or contact me via the public jBPM5 channels. The more requirements that we can gather, more re-usable will be the end results.


This post cover what I believe are the most important bits that Knowledge Based Platform UI should provide. I’m not saying that these features are enough but this post will serve as the starting point for more advanced mechanisms to improve how the work is being done. I’ve intentionally left out of this post several important topics like: the BAM module, The Knowledge Authoring Tools Task Statistics, the Knowledge Repository Organization and Reporting. All these topics will be covered in future posts. Now that you reach the end of the post please read again the“Get Involved” section and drop us a line with your comments/suggestions.


3 thoughts on “Knowledge Based Runtime UIs Requirements”

  1. Great Post Mauricio, clean & simple. I’ve read several times and I think there’s an issue to consider: In large organizations Knowledge Assets are distributed and each area are jealous of his knowledge. Think in an “oracle” with all knowledge stored in a unique repository not apply. “Share is must simple that take”. For example, is insurance area can expose your “knowledge” represented in a “standard” we can take and used (and release). This area will continue to be responsible and owner of knowledge. This facilitates the implementation without being invasive.

    Another issue to consider is roles and visibility (summary: security) because this tools should be used by non-programmers or used by business experts (ie. risk analysts) and at this moment is good to keep in mind “God does not exist in organizations and roles (and permissions) are distributed”.

    Finally (I promise that is the last), I would add the event handling with more emphasis. Give the ability to model events regardless of origin ( event, syslog event, database trigger or a simple twit).

    Think about it, if a single user can model any event and take knowledge or behavior is encouraged remote repositories reusability.

    Mauricio, with great pleasure would contribute in any projects which seek to give more governance to the end user.

    Congrats Friend!


    1. Hi Leonardo, Sorry for the delay in my answer.
      A key point that wasn’t mentioned in my post and it was left out on purpose is the Repository. All the asset organization and administration will be in charge of the repository layer. The main idea is to be able to have multiple repositories that can be merged in the view based on things like you mention: Departments, Business Units, set of experts, etc. Most of the security things can also be solved at the repository level (branches, tags for different environments, and for access control).

      About Events, you are right, I didn’t had time to go deep in that direction, but I’m sure that as soon as we solve the basics Events will be smoothly integrated with the rest.

      We are always open to contributions, so stay in touch and let us know how you can collaborate with the project 🙂


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s