Tuesday, October 30, 2007

Drools BRMS version two design and ideas

Hi folks

After delivering 4.0.3 Michael and I had some conversations about adding more features and a complete re-design of the BRMS web interface. Basically we are looking at how to break things up into "perspectives" kind of like eclipse has (but simpler), just to make it easier to present the user with the information they need for their current work example:
  1. BA type users (no package configuration, follow templates, read only sometimes etc)
  2. Developers (configure stuff - eventually should only need eclipse so this doesn't have to be too strong on the web side)
  3. Admins/operator types (migrate, security setup etc).

Nothing that complex, but we do need to have it scale up and down to these skill levels.

I think we can do something like merging the previous BRMS organization with the new tree feature. We do like the tree/explorer motif, fairly familiar to most people and easy to make it filterable based on both server side and user settings. Also, its more like ideas that the jboss web console is moving to.


The new package feature



Categorization



Administration


Also with this refactory we will enable I18n internationalization then people can easily edit the bundle file/config to add they own language setting. Other key features like rule based authorization and custom queries are also some of the new features.

We are messing around with a few designs and also very receptive on ideas and feature requests you can find our task list on Jira and suggest something, also you can ping the dev mailing list on rules-dev@lists.jboss.org

The new BRMS design concept

1 comment:

  1. I told mike I'd post some more thoughts. Here it is in no particular order. Not all of them will make sense and may not apply to most cases.

    1. be able to provide a new skin for the BRMS web interface. I've seen this atleast 3 times. Most business want the rule editor to have their look and feel.

    2. be able to embed the BRMS application within another webapp. I've seen this several times since 2000. Often writing rules is part of a larger process. One example of this from recent experience. Say I have a tool for authoring questionnaires, where users can create questions, and answers. If we need rules to control complex flow logic, it would be "nice" if the rule editor is integrated with the questionnaire configuration tool. Another example is from compliance. Say i have a compliance tool which allows me to search stock by ticker, cusip or business name. When the compliance officer writes a rule, they select the account from the database, and the find the ticker. They then create a new rule from those entities. If the BRMS can't be embedded, the user would have to open up 2 tools and copy the values from to the other. Providing the ability to embed the BRMS into an existing application makes life easier for the end user and reduces manual copy/paste errors. It also makes it easier to do "what if" testing, since the application is integrated.

    In the past, I've built custom rule editor, since most commercial products don't provide these kinds of capabilities.

    ReplyDelete